Pervasive Actions

Programming languages are often oriented around heirarchial structures. Modules nest Functions (or whatever [YOUR FAVORITE PARADIGM] prioritizes). Functions nest logic flows. Logic flows are made into nested structures. Conditional structures (if, switch, match, case, ...). Loop structures (for, while, recursion, ...).

These structures enable top-down control over you code and logic. They assist in managerial work. But they fumble when communicational work is needed. What communication structures exist for modules to share informaion, for objects to send information between each other? How can different parts of this tree talk?

Communication is a graph, but control is a heirarchy. They naturally conflict and cause friction and churn through-out software. Endless frameworks constructed in programming systems that have unstructured and unassisted tools of communication.

I always wish BEAM was wrapped inside a fleshed-out game engine. Sometimes I feel like the things I describe fit the shape that Erlang et al describe. I believe Elixir has Raylib bindings, but alas. My time is not in the same surplus it used to be.

Furthermore, structured programming crumbles under "pervasive actions". Wide sweeping actions and stateful task that do not conform to heirarchy. Or worse. Form independent extra-logical structures.

A Non-Exhaustive List of Such Things

The following is a short list of things that are "pervasive actions". These task often implicate the idea of a "Root Object" or "God Object". Each of these often needs some globally observiable piece of information that affects everything in the application.

State Transitions

One of the first things you will run head first into with game development is needing to refactor a small isolated test into an actual Game. The statement "lets add a menu, and a game over screen" sound simple. Just "add" them. But how do you transition from Menu to Gameplay to Game Over? Furthermore, Gameplay needs to be reset and possibly reset to different states between Menu and Game Over.

Additionally, what happens to the game state? Gameplay and Game Over may need to share state? Perhaps Menu effects settings in the Gameplay? Now, state needs to be hoisted and communication must be considered. This refactor is highly invasive and can be difficult to get right. Perhapse impossible as languages aren't optimized for this task.

I would argue, based on the principle of "where there is friction, there is a design pleading for you to not do this", languages actively hate you for this. Especially if there is suddenly shared state between Module A and Module B.

Totally didn't write this article to procrastinate on figuring this out...

Pausing

Pausing a game sounds simple. However, Godot has a dedicated feature to handle this. So clearly, it isn't. But, why? It's another pervasive action. One that forms it's own extra-logical heirarchy outside of you programming language.

Consider the following: have you ever thought about the fact the Pause Menu isn't effected by the Pause State? More accurently, the Pause Menu has an inverse reaction to being paused. When the Game World is paused, the Pause Menu is active. And vice versa. Entities in a game need to have a state transition between Paused and Active.

Many games have multi-level pausing. Consider something like a Timed Minigame to unlock a door. When the player enters this minigame, the Outside World is Paused. Now, the player has to take a piss. They pause the game. Now the Pause Menu is active the Timed Minigame is inactive and the Outside World is also in active. There is three levels of pausing.

This implies multiple piece of global state and state transitions for each entity. Gameplay Active, Minigame Active, Pause Menu Active. This can arguably stack indefinitely.

Saving

If you didn't design a game to be saved from the start. Good Luck. Saving is a pervasive and intrusive operation that has widespread design implications for every facit of your game. Everything gets involved with saving.

Saving is almost like a Garbage Collector. A Garbage Collector needs access to every node of memory in your program. Saving, requires the same. Regardless of the implement, you conceptually need a mechanism to broadcast a request to save and a mechanism for collecting that save information.

This implies some kind of "Root Object" in you game world. Either explicity or implicitly. The implicit case will give you hell. You will be ducktaping fixes for ever.

Seriously. You will lose sleep. You will hate yourself. And, there is a chance saves will be broken forever. And, you will likely give up your game. I recommend against it. Consider how you will seralize, centralize, and manage your game state ahead of time. Then sort out communicating changes arcross your game. You'll thank yourself.

Retro-flavored games that emulate a lack of memory safety have it relatively easy. The Root Object is simply the RAM of your program. Dump that to a bin file and then reload it. A lot easier than navigating a mess of Well Structured Code.

Input Events In General

Input events in general form a set of pervasive actions. A button triggers an action that sends a value from an input box to a label. How does that action happen? There must be something to 1) notice the button is pressed 2) extract state from the input box 3) move that value to the label.

These are not local interactions and thus must pass through the global space. They don't follow a clean nested heirarchy, but rather form an indpendent graph. This is especially true with bidirectional actions. This global space is substantiated by the abundance of frameworks, system, techniques, and "design principles" that exist to deal with this.

Unfortunately, the only languages oriented around these global spaces are database languages such as SQL. And you don't really build whole applications in SQL. Unless you are insane. Perhapse more languages should have first class support for a database? We seem to reinvent them a lot.

Implication of Pervasive Actions

Pervasive actions regularly present challenging problems for programmers. The tools on offer often want to pretend these situations don't exist. Heirarchy presents clean control structures, but communication is inherently messy. Programmable machines have always been a means of replacing human labor. The automatic loom ended (or critically wounded) a cottage industry. Modern computing descend from tools of war that replaced women in rooms. At the time of writing (2025), computing has been shaped by the structure and control systems of large enterprises.

It's no wonder there is endless churn trying to add free-form communication to stratified systems of logic. The tools we have are not design for communication. They are design for strict control. They are managerial systems not communication systems. And, we desperately need systems of communication.

Random Thoughts