Strides Interactive

To Set or to Add?Filed Under: Weekly Tuesday Dose of goodness

Hi all,

Today I’ll talk about this interesting notion of Set and Add.

As we know in games development, there’re constants and variables. While constants can’t be modified, we can modify the variables. To that end, there’re at least 2 ways to modify these variables as mentioned in the post title.

In the past, older games used to use Set a lot more than Add. It’s only in the recent years where the Add methodolgy gets used a lot more.

So what the hell are these two? Let’s find out….

Introduction

When we were first taught about programming, one of the most basic elements was declare variables and set them to a value right?

Next, we’re taught that variables can be mutated into other values using mathematical operators.

At face value, which would be easier? Setting variables or mutating variables?

Of course, setting variables to a value would be the straightforward way of doing things. Why not mutation? The reason is because, by mutating, you’ll need to consider not just a single value, but rather a range of values that the variable can accomodate or supposed to accomodate.

Bring it forward, now we’re looking at several algorithms that will be used for our games.

How do we choose?

Basically, there’re 2 types of algorithms out there. The first type is algorithms that those that calculate, evaluate and decide based on the given inputs. The final outcome is then SET as the final value onto the affected variable.

The other type of algorithm is exactly the same thing with the exception of the last part. Instead of setting the final calculated value, it instead ADD the results to the affected variable.

The key difference between these 2 types of post processing is CONTROL.

What’s within control in this case? Predicitability & deterministic behavior. Naturally, algorithms that post processes using SET is predictable and deterministic compared to those using ADD.

As such we have 2 extreme possibilities if only 1 type of algorithm is used for game development. (Respectively)

1) Total control, predictability and deterministic outcomes but inflexible and stale or even unnatural.
2) No control, not predictable, not deterministic, very flexible and possibly very intriguing.

Now, we need to understand that games need both types of algorithms in order to be a balanced final product. The percentage between such algorithms can be split based on their genre.

Examples

Let’s take FSX (from Microsoft) for example. This is a simulator, much less of a game and since simulators are tied to force of nature (such as gravity, fricition, physics, weather, etc) and that nature AFFECTS the performance of the simulator’s playing craft, most of the algorithms in FSX would have been using ADD to modify their outcomes.

However, FSX also has a portion of its simulator that requires SET algorithms. For example, the flight path planner. You give a start point and destination point, it gives you a set of waypoints to follow. Its waypoints are calculated and its results are SET as nodes in a list for the plane to follow.

Beyond FSX, there’re many many examples of games using SET and ADD all the time.

Another example would be on screen animations shifts a picture from point A to point B. Even with acceleration, deceleration and max speed, the picture is updated by position using the position calculator (ie, disregarding friction, gravity and any other opposing forces) and the picture will reach point B since its movement trajectory has already been calculated.

Let’s say instead of moving from point A to point B, the use case would be - I push a box using my in-game character with a certain force and that this box can be influenced by multiple forces as well, not just by my own pushing force. In that case, ADD algorithms will be required to cross-increment/decrement the force inflicted upon the box and thus arrive at a final position which may not necessarily be the desired position.

Conclusions

In short, both types of algorithms have their advantages and disadvantages. You’ll need to balance which to use, when to use and how to use.

Do NOT mix these 2 types of post processing algorithms together.

Disadvantages in using SET post processing

1) Only 1 force can be applied, multiple forces will lead to a possible design-based memory leak.
2) Possibly unnatural appearance of game objects when applied to graphic representations

Disadvantages in using ADD post processing

1) Unable to predict final outcome
2) Might lead to unrestricted outcomes which may encourage abuse by gamers
3) Harder to implement properly and requires more tests

Advantages in using SET post processing

1) Predictable and controlled outcomes
2) Easy to implement

Advantages in using ADD post processing

1) Suitable for in-game object representations because it tends to look natural
2) Allows multiple forces to be inflicted on the same object (be in physics, color modulation, game status stacks, game status damage such as poison, immolation, etc)

Do note that in some SET algorithms, there’s actually a requirement to reach the designated point (be it color, position, values) known as the calculated destination, otherwise the algorithm will continue to run. This is the reason for the possible design-based leak I mentioned earlier.

A good example would be a for-loop which in this case, it’ll be an endless loop or stack overflow case.

for(int i = 0; i < 500; i++)
{
    if( i == 100 )
        i = 0; //that's it
}

All ADD algorithms have a calculated distance/force to be traversed as opposed to calculated destination. This means, while affecting the variable with the calculated value, it’ll stop affecting the variable the moment the calculated distance/force is reached and terminate, thus preventing itself from becoming a possible design-based leak.

Using a for-loop, we can roughly see how it works out:

int maxTraversals = 500;
int curTraversal = 0;
for(int i = 0; i < 500; ++i)
{
    if( i == 100 )
        i = 0; //that's it

    ++curTraversal;
    if(curTraversal == maxTraversals)
        break; //this ensures that the for-loop will NEVER be endless
}

* Note : this is really a rough example, not a real example

Again, this has been quite a mouthful as well. I’m going to just stop here for a while and let the dust settle.

Signing off,
Jeremy