Effective Game Coding #2: "Ya Ain't Gonna Need It"

This is the second of a series of articles featuring an in-depth discussion of programming principles, as they pertain to Video Game programming.  The topic this time is a very important principle - "Ya Ain't Gonna Need It" or YAGNI.

If you find you learn better via video, I have one (where my facial expression captured in the auto generated thumbnail turned out pretty hilarious) below.

What is YAGNI?

This principle comes into play when you're programming something that you're guessing you might need at some point in the future. The basic premise is that generally speaking, you aren't going to need it, and time spent writing this code was a waste of effort.

On the whole, this is a time management principle, and one that I find comes up commonly in games, a field of programming that frequently suffers from the project management holy trinity of feature creep, competition anxiety, and short deadlines.

This actually happens?

Like many of these principles, it sounds obvious. Why would you ever write something that you might never use? But in practice, this is a very common problem that can cause enormous inefficiencies and can be more difficult to solve than you might initially think.

Further, it is sometimes difficult to identify when you're violating this principle. If you're busy slaving away at your desk while some other programmer is spending half the day playing ping pong and eating office snacks, you clearly feel like the more efficient employee.  However if the code you are writing will never be used, then sadly, that slacking programmer is potentially vastly more productive than you.

There are two ways this problem usually manifests. One is simple to resolve, the other is more difficult.

The easy case

The more obvious case is when you are developing a new feature that you don't really have a current use for.  You're doing this on the presumption that you might use it at some point in the future.

For example, say you're busy making a first person game. You read some article with a great technique on how to implement a third person camera, and you decide to implement it despite that your game doesn't really need this functionality.

You'll start to justify your decision.

They all sound like good reasons! Quite convincing really! And lo you will have just talked yourself into what's most likely going to be a waste of time and effort.

Why is it a waste of time?

Only the last two reasons from the above list are valid. Writing code for fun and education is an excellent pastime that I thoroughly endorse. You might even argue that writing some code for fun is worthwhile as an occasional sojourn that reinvigorates your spirits and boosts productivity in the long run. Of course, do this too much and a looming deadline will begin to disagree with you.

The other reasons, the ones you likely told your project manager, are patently ridiculous. I've seen projects become extremely derailed in situations where unchecked programmers have been spinning their wheels with seemingly zero friction.

What's wrong with the other reasons?

In addition to the time sink,
 

Solution to the easy case?

I said it was easy - and it is. Just defer working on unnecessary features until you actually need them. Let's move on to the more difficult case.

The hard case

The harder case is when you're working on a feature that you know you need, but it's not clear how much of the logic should be hardcoded versus architecting some more robust system that affords huge customizability for the game designer.

It is typically more time consuming to write a highly architected system than hard-coding some basic logic, but there are cases where architecture provides a much more graceful solution and gives a net benefit to efficiency.  So how do you decide what to do?

Obviously each game is different and there is no single solution for all situations. Nonetheless, this article is about overarching principles, and YAGNI gives us a solid ground rule to follow: Start with hardcoding, and scale up from there.

Let's take a look at some examples to see why this is effective.

Examples

The most common area of game code where I encounter this problem is Artificial Intelligence. Having seen many AI systems for a variety of games big and small, I've encountered varying levels of robustness producing similarly varying degrees of success. 

When I say Artificial Intelligence I'm referring to behaviour of enemies, NPCs and the like. Consider this example archetype from a cover shooter:

The enemy runs to a cover point in range of the player, takes cover, shoots periodically, and retreats to a cover point farther away if the player gets too close.

You can break this into two chunks:

The actions are simple. These are usually hardcoded with certain variables customizable by a game designer such as movespeed or attack range.

Behaviours

Behaviours are where things start to get fuzzy. You can imagine some example hardcoded implementation (that you really shouldn't take too seriously because it's just an example and no real AI code would ever actually look like this):

if (distanceToPlayer < FLEE_RANGE) { 

    moveToCover(FAR)

} else if (inCover() && distaceToPlayer < FIRING_RANGE) { 

    shootAtPlayer()

} else {

    moveToCover(NEAR)

}

As the YAGNI principle suggests, this is probably a good starting point, and can even scale to many different enemy archetypes through appropriate use of inheritance and composition. 

But when you have a huge number of enemies and want to afford greater flexibility to your game designer, more of this logic will need to be driven by data. You can start to imagine how such a system would look. Games like Dragon Age have even exposed such a system to the player.

class Rule {

   Attribute attribute

   float value

   Action action

   Operator operator

   boolean evaluate() {

       boolean success = false

       switch (operator) { 

           case LESS: success = mAttributes[attribute] < value 

           case GREATER: success = mAttributes[attribute] > value 

           case EQUAL: success = mAttributes[attribute] == value 

           //.. etc.

       }

       if (success) { 

          performAction(action) 

       }

       return success

   }

}

You would then define some rules to govern behaviour on a given enemy through data in a priority list.

NormalEnemy {

    RULE(ATR_HEALTH, LESS, 0.35, ACTION_RETREAT)

    RULE(ATR_RANGE, LESS, 50, ACTION_RETREAT)

    RULE(ATR_RANGE, LESS, 100, ACTION_ATTACK)

    RULE(ATR_RANGE, LESS, Infinite, ACTION_TAKECOVER)

}

Looks pretty graceful, doesn't it? Until of course you add your boss battle that needs ATR_IS_HOLDING_SPEAR_OF_TRIUMPH, and ACTION_PIERCE_ROCK_OF_DESTINY_WITH_TRIUMPH_SPEAR_FOR_GREAT_JUSTICE_AND_VICTORY.

All joking aside, a system like this can be very useful and has its place. Deciding to make a system like this could potentially save you large amounts of time. What I recommend as a general rule however - don't start here.  Scale up to it.

Why scale up?

Some games, like Dragon Age, the AI tactics are part of the design and you will likely jump right into making a robust system like the one above.  But when you're unsure, it's a safer bet to start hardcoding and scale up from there if necessary. This has several advantages:

An Important Caveat

It may be tempting to use the YAGNI principle as a justification to avoid writing clean code. Your argument might be that it will take so much longer to write my code cleanly and we aren't going to need it, so therefore I shouldn't bother.

Unfortunately this logic is predicated on the false assumption that writing unclean code is somehow faster than just writing it cleanly to begin with.  Don't use YAGNI as an excuse to copy/paste your code or violate other various clean programming practices. Use it to avoid unnecessary features or overarchitected systems.
 

To Summarize

For new features you should be doing a cost benefit analysis wherein you ask yourself:
 

Usually, the answer is no - you should deferring the work. 

And for architected systems, a good rule of thumb is to err on the side of simpler code with the intent to scale up later if necessary.

Optimization

I wanted to touch on one more subject as it is closely related to the YAGNI principle, and that's optimization. You've surely heard the phrase "premature optimization is the root of all evil" and it's absolutely true in many cases. 

(the full quote is: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%" - Donald Knuth, Computer Programming as an art, 1974)

The basic premise is that it is a waste of time optimizing something that may ultimately be deleted, or turns out to be not a huge consumer of performance in the end. Premature optimization also suffers from the other problems I already mentioned of potentially reducing clarity, introducing bugs, or increasing complexity, for little if any benefit.

However, there are real cases where it makes sense to optimize as you're writing, and deciding whether you should be optimizing or not is a big subject that deserves its own article.  That being said it's still related to the YAGNI principle so I wanted to at least mention it here briefly.

Conclusion

That's all folks - this is a pretty broad subject that rears its head frequently, has potentially huge efficiency consequences, and of course offers many angles for further discussion.  Hopefully this introduction will at least familiarize you with the concept and give you some ground rules that can put you in a good position to make effective decisions regarding YAGNI, worst acronym ever.