Hey everyone,
It's Felix again! I wanted to dive deeper into one of our game pillars today, but I kept struggling with how to best describe it. Our approach to game design and development might be familiar to those in the games industry since it’s based on conventional agile software development methods. However, it can be a bit complicated to describe future features because it’s not always clear how much of the original concept will be implemented.
We’re calling our version of agile development the tiered approach, and I think this image that stuck with me from back in my uni days describes it best:
Basically, when we design a feature for the game, we first write down what the best possible version of the feature would be if we had infinite resources and time (The sports car in the example).
We call this Tier 4 or 5, depending on the complexity of the feature. From there, we go back to Tier 1 and imagine the most basic version of the feature that does the same in spirit but without any bells and whistles, and is the fastest to implement (The skateboard is also a wheeled vehicle that takes you faster from A to B). Tiers 2 and 3 are then used to fill the gap by spreading the development amount as evenly as possible. All tiers must enable their game mechanic in the game, just with increasing complexity and, hopefully, fun. (Some people find motorbikes more fun than cars if we stick with the analogy.)
When we develop, we go through all features and implement the first tier. We’re more or less at this stage now. The big advantage is that we can get a clear picture of the game and what it will be at the end very early, and we get to play and test it internally very fast. Actually, we’ve been playing the game weekly since the first month of development—something I’ve never been able to do before.
From there, we’ll develop higher and higher tiers for each feature, focusing on improving the tiers of core features and those that suffer the most in terms of fun at lower tiers.
This approach gives us many advantages. We’ll have a playable game out to you much faster, we can make adjustments along the way more easily, and overall the development is much safer, meaning there will be a game at the end of all this for sure.
Of course, there are always drawbacks: this approach probably requires more effort overall as we will end up reworking features repeatedly. This is more of a non-drawback, however, since the reworks will be in favor of better overall quality.
The second big drawback is that it makes it very difficult to talk about features early. Should we talk about Tier 5 with the risk of changing it completely until we get there or—worst case scenario—only getting to Tier 3 during development? Or should we play it safe and talk about lower tiers with the risk of sounding more generic?
Now that I’ve explained our process, I feel more confident about taking a third approach: transparently discussing the tiers of the features we’re currently considering with the knowledge that we’re mostly at Tier 1 and that a lot of things might change on the way to Tier 5. ^^
I’m looking forward to telling you more about features with this in mind. As always, I’m excited to hear your thoughts! For now, though, it's back to the pixel mines for me. See you next week!
Cheers, Felix