The Vietnamese feature jungle

The iterative approach is a go-to solution for developing 90% of modern games. Nowadays, no one really argues otherwise. Game development is creative, chaotic, and impossible to accurately plan upfront. Because of that, the first iteration is a fast, ugly prototype that explores given design ideas, possible tech, or gameplay solutions. That’s fine. This is the way. But what should be done after the first prototype is ready and provides the information it’s supposed to provide?

Trolls and bridges

Well, there are two ways. A more extreme approach preached by Fred Brooks’ acolytes says that the initial prototype should be completely discarded, deleted, and forgotten. As rapid prototyping allows for many shortcuts and the final quality is often very poor (and should be!), there is no point in extending it to a final product. There is, however, one issue with this approach. It’s easy to just delete the whole project, but it’s much harder to remove some feature that is prototyped in one of the later work iterations. When most of the game is already in proper production and only this new feature is being added and tested. The second approach, much more common, is to fix the most disgusting parts of the prototype. Put some band-aid on amputated limbs and try to somehow deliver it. Cross your fingers and hope for the best. What could go wrong?

The answer is: everything. The assumption is that you will improve the prototype and its capabilities as you add more “load” on top of it. The load can be more content, more code that depends on it, more performance requirements, more closely linked features. Anything that isn’t required from the prototype but is expected from the final product. But if you start adding load and forget to improve the underlying infrastructure... Well, try building a wooden footpath for kittens to cross a stream and then ask a troll to walk over it. First, someone gets wet, and then someone else gets smashed in the face. Of course, there are projects (especially very small ones) that can afford to go with the first prototype and somehow deliver a working game. But if the project you are working on is bigger, you can be sure that the troll will be too heavy for your bridge.

Problem breakdown

So let's assume that you are aware that refactors have to happen at some point, that most features are not 100% ready to be delivered, and you even allocated some time margins for that. In many studios developing bigger games, you could list tens and even hundreds of features big and small. No one can remember the state of all of them. And if you rely solely on the state visible in your daily build, you can fall into a trap of marking certain things as done. And then more content comes 2 months before the release and you realize that the whole huge feature needs to be completely redone. Spend 15 mins on any game dev portal, and you can find dozens of examples of such situations. Why does it even happen if everybody knows that tech debt isn’t in a pack with the yeti and Loch Ness monster? There are several reasons:

1. People responsible for particular features change during the project's lifetime. Information about the state isn’t properly passed.

2. People forget, especially when there are too many features they need to keep track of.

3. Sometimes it’s not clear who exactly is responsible for a given feature. Depending on the management model, it can be some PO or some engineer, but sometimes it's a collaborative effort and no one really feels like it’s their job. Responsibility for features will also have its separate post as it’s a huge topic.

4. Often features are marked ready as they are good enough at the given time, but later their quality doesn’t keep after the expectations change.

5. Decision about the state of the feature is based on the state visible in a build. That's especially common when producers, POs, or managers at any level try to make decisions without ever asking frontline devs about details.

6. Sometimes features get “sort of” finished for some events or presentations. So they look good but only from one angle and then everybody is surprised when the perspective changes.

7. Some features can’t be properly tested and finished unless some other big part of the project is done. So some version can be created, tested as well as possible at the current state, but in the end not working in the expected scenario.

8. In many bigger companies, lower and mid-management cares a lot about showing quick results, providing features that are half-baked. It’s the only mentioned case, where there can actually be someone aware of the problem, that because of the conflict of interest, hurts the final product. Again, it deserves a separate post.
   

As you can see, there can be many reasons for broken, stale features in the game. These are ticking bombs that can completely flop a release or force the whole studio to go on a deadly crunch path. Some people say that just a good backlog is enough to keep track of this and make informed decisions. I’m yet to see such a backlog.

Solution

One thing that can improve clarity and prevent unwanted explosions late in the project is a properly designed feature tracker. Here is my idea of how to create and maintain it. For sure it’s not 100% complete and won’t fit all the work models, but can be an inspiration for creating your own version of it.

1. Break features down into a list that you want to track. You can create it as a flat list or play a bit with some form of a tree (WBS or anything).

2. DON’T mix it with the backlog; these are supposed to be completely separate artifacts.

3. Specify feature types. You want to differentiate later steps for different types. Some examples of these types can be Gameplay System, Game Location, Character

4. For every type, specify several development stages. They can be things like: - Design draft / feature request - Prototype - Detailed implementation - Fully integrated - Shippable

5. For each of these stages, define progression conditions. They can be similar to DOD or acceptance criteria but from a larger perspective. Some examples: - Main goal definition - Implementation team / person assigned - Can be seen in the game - Has a full design doc - Is implemented using target tech - Implementation accepted by senior / lead (code architecture, art direction, key story points) - Integrated and tested with all related features (not only crafting system works, but it is tested and verified with the inventory system and economy system). - Tested in full load with a lot of content (crafting works with hundreds of recipes, character has been tested playing the whole scenario with different builds, level has been played with the max number of players and enemies on all intended difficulty levels). - Profiled and optimized As you can see, many of these points are more extensive than one task that can be assigned to a particular developer during a sprint. That's because they aren’t exactly tasks - more like state indicators.

6. Specify a person responsible for progressing each of these features through development stages. You should always know whom to ask what is blocking each feature from being progressed further.

7. Keep it up to date.
   

You can ask why you should bother adding another artifact to your process? First of all, it adds a lot of transparency and helps your studio make better decisions that aren’t based on “oh, I think it’s done” or “I just checked in the game, it works, we should move to sth else”. Second, if you define correct progression conditions it makes it easier to assure all the features work together. Third, it can be very helpful in improving your product backlog, task list, or whatever you use.

If you have any thoughts about this model, let me know; I’m curious how it could be improved.