What is a moment?

A moment is an atomic unit of time. If two things happen in the same moment, then neither thing happens before or after the other.

This is a very useful semantic tool in the day-to-day thinking of the human mind, but it is surprisingly lacking in the domain of programming.

In this context, a “moment” is a set of instructions in which order does not matter. That is, in a moment:

a = 10;
b = a;

has precisely the same result as:

b = a;
a = 10;

Unlike the norm in sequential programming paradigms, that a statement comes before or after another statement in a moment is irrelevant. After the above moment (either version) is executed, the result will be that both a and b have a value of 10.

The problems this will solve

The problem that inspired me to start looking into this tool is the initialization phase of game logic. In complicated games with dozens of systems, it is incredibly common to find bugs that occur because one system does not get initialized until after another system that depends on it already being initialized. What this costs the programmer (and this is especially costly if you are new to the project) is search time: when adding initialization logic to the program, you must search through the existing initialization logic for the right “time” to add your logic. Even though conceptually, there is no “time” passing in the game yet — it hasn’t even started!

This search time grows as the code base does, as there is more to sort through. And this problem doesn’t just happen during initialization; it can happen every frame. Games generally have an update loop, where things that happen every frame get calculated. Player input will be processed, physics calculations will be applied, the characters and objects in the world will be moved around, and the game state will be rendered (among other things). If these things do not happen in the correct order, bugs will occur. For example, the camera needs to be pushed outside of static meshes, or when it comes time to render the world you will see the insides of your geometry. This means the camera’s collision resolution must happen before the render phase uses the camera position and orientation to render the scene. Another example is if the player character has something attached to them, like a weapon in their hand. If this weapon is updating its position every frame to keep it lined up with the player’s hand, then this update must happen after the player has moved, otherwise the weapon will lag behind the player and seem to be floating in space, always one frame behind where it should be.

This is because in sequential logic,

player->position += player->velocity;
weapon->position = player->position + offset;
...
render();

is remarkabley different from

weapon->position = player->position + offset;
player->position += player->velocity;
...
render();

In the first code snippet, the player gets moved properly (leaving the weapon behind), then the weapon gets moved back into the player’s hand, then the game is rendered and all is well. In the second snippet, the weapon gets moved to the player’s hand first (where it should have been last frame), then the player gets moved to wherever they want to be, leaving the weapon behind, and then the game state is rendered, with the weapon constantly trailing behind where it should be. This is trivial to spot and fix in the above example, because all the code is treated as if it is in the same place, but in a real game such update logic would be scattered in many different files, and in order to understand the order of operations you will have to trace the call tree spread through all of these files.

“Scattering”, a term made popular by the Aspect Oriented Programming movement, is when a programming concern gets separated into several locations among several source files. This is considered bad, as it requires programmers modifying the system to have to search in many places to make sure the logic still holds after their modification. If I may be so liberal as to consider “updating the game” as a single high level concern, then the update loop is likely the most scattered concern I consistently see in game code. Every game object needs its own update method, and every system does too. There are countless ways the order of updating can go wrong, and they aren’t always intuitive or easy to spot even when looking at the bug.

The solution

Imagine if, upon creating a new updateable object for your game, you didn’t have to spend the time figuring out where in the sequence of steps the call to your update method should go. What if you could just write it, and the compiler could figure out precisely when it needs to get called.

The paradigm I am proposing will solve the issue of human error messing up sequential logic. It does this by treating such a scenario as “update” as not a sequence of events, but as a “moment”; just like how I argue we think of it. Of course, the computer can still execute its low level instructions sequentially, this is just a paradigm to remove some of the clutter from the high level domain in which the programmer is working.

Formally speaking, if a “sequence” is a set of ordered instructions, then a “moment” is a set of unordered  instructions. In this context, “unordered” means that the instructions can appear in any order in the source code and still produce the same executable (and runtime behavior). Of course, order of execution is still important (for correctness and cache optimizations). The key here is to improve human productivity by giving the responsibility of ordering to the compiler.

How does the compiler do this? Let’s consider our previous example (the wrong version):

weapon->position = player->position + offset;
player->position += player->velocity;
...
render();

The first step is to tag each instruction based on what it modifers, and what it depends on.

weapon->position = player->position + offset;

// modifies: weapon->position depends on: player->position, offset

player->position += player->velocity;

// modifies: player->position depends on: player->position(previous), player->velocity

render();

// modifies: (nothing) depends on: weapon->position, player->position

The next step is to sort the instructions such that no instruction that depends on a variable appears before an instruction that modifies that variable. In this example, the instruction that modifies player->position will be moved to occur before the instruction that modifies weapon-position. This seems like a trivial accomplishment with just a few lines of code, but the kinds of bugs that this can move to compile time can be hard to track down at runtime. Also, I see no reason why dependency analysis can’t be done from one method to another — for example, if the render() call above modifies player->position, but also depends on weapon->position, which itself depends on player->position, then we have a dependency loop. This dependency loop is not obvious to a human reading this section of code since part of it lies in the encapsulated call to render() (which may very well be in a compiled library), but the compiler can quickly identify this and point it out. In this manner, moments can take away some of the hassle of scattering.

As long as there are no dependency loops, and as long as no variable gets assigned twice in the same moment, then this method should work flawlessly. I believe that dependency loops (such as a = b; b = a;) and multiple assignments (a = 5; a = 10;) inside of a moment should be treated as compile time errors. Dependency loops are bad because they leave no unquestionably ideal ordering for the compiler to work with, and multiple assignments are bad because no variable can have multiple values in the same moment (what would this mean?).

The syntax I propose for this feature is:

moment <label> {
    moment-safe instructions
}

This consists of the moment keyword and a set of moment-safe (dependently-safe, and singly assigned) instructions wrapped in a standard brace block. The label is optional. In the uses this article scrutinizes, there is no need to label a moment. However, I have some ideas with moments that I will discuss in future articles where referring to a moment from a distant point in code will occur, at which point labeling moments becomes a necessity. It can also be useful to label moments for programmer readability.

Regarding AOP

My experience with Aspect Oriented Programming is only academic, and limited to AspectJ. And very limited at that. I know very little about AOP, or even AspectJ. As such, I welcome an expert insight into the matter.

AOP attempts to solve similar problems to Moments, namely by making code easier to manage with regards to the natural difficulties that arise from scattering and tangling. From what I understand, aspects tackle the issue of scattering by allowing a programmer to add what would be a copy-paste job spread throughout the code base to a single location, and aspects also tackle the issue of tangling by allowing a programmer to separate concerns (such as logging) from the actual method call to keep the method clean. However, they do not remove the responsibility of sequential reasoning from the programmer’s already busy mind. AspectJ has three kinds of advice: before, after, and around. “Before” advice gets executed before the join point it is assigned to, while “after” advice gets executed after the join point. Neither of these escape sequential reasoning. The third type of advice is “around”, which is similar to method overriding in OOP in that it can either replace or augment the join point’s code. Even if you choose to augment the join point, you must specify when the original join point gets called (via the proceed() call). Moments, on the other hand, have no “when” to answer to — or, more accurately, moments have precisely one “when”, for they are temporally atomic. Anything happening at the same moment neither happens before nor after anything else in that moment.

I believe that there is a lot to be taken from AOP though. I have some AOP-like thoughts on modifying moments from distant places in code, but that topic should be an article of its own.

Summary

To summarize:

Moments are sets of instructions where order does not need to be specified by the programmer. Moments must be dependently safe: there can be no dependency cycles among the statements. Moments must also limit assignments to one per variable per moment: a variable can not equal two or more different values at the same moment. Any violations of these rules will be caught at compile time.

Moments make life easier for the programmer by deferring the determination of instruction order to the compiler for a well-defined set of instructions. On top of freeing up programmer brain cycles to focus on the problem at a higher level, this can have other benefits as an IDE could be made that sorts statements in a moment based on the programmer’s desire, independent of the original order the statements were added.

Please note that moments are a proposed language feature, not a ubiquitous necessity. It is perfectly fine to have sequential logic in the code that does not fall into a moment, just like it is perfectly fine to have procedural libraries in an OOP language, or vanilla Java in AspectJ.