Creating a real-time strategy game with the “Minimum Design” approach.
A Year Of Rain is an ambitious game – especially considering the maturity of the real-time strategy genre. As a small team of both passionate developers and players, we had to take a step back to capture the essence of the real-time strategy experience while operating within tight time and resource constraints.
What is Minimum Design?
When starting a new game from scratch – I mean literally from scratch – it always feels like sitting in front of a blank sheet of paper. In our case, it’s more like sitting in front of a black screen, trying to figure out what the game is all about.
I had the main idea for Minimum Design after listening to a game design talk by DICE back in 2013, when they were referring to an approach they had called the “onion model”: Start off with a solid gameplay core. Then, iterate by adding new layers of gameplay, and constantly challenge whether the overall experience has improved. If not, revert the changes and try something else. That approach leaves you with similar processes and results as SCRUM in classical software development, where you always have a shippable (read: fun) version of your product at hand.
Another take on that idea is that randomly adding new features to the game doesn’t necessarily improve it. Adding a day/night cycle won’t turn a bad game into a great one. However, if you’re working with a solid core, you’ll always end up with a fun experience.
In the first playable version of A Year Of Rain, there was just units & buildings, combat, production, and resource gathering – nothing else.
Minimum Design in A Year Of Rain
First, we took a look at the intersection of the feature sets of traditional real-time strategy games. This led to the idea that we most probably would have units & buildings, combat, production, resource gathering, and presumably limited vision. We challenged many other features immediately, even if they were quite common in the genre, such as upgrades, housings, or air units. Heroes were the only feature that was set from the very beginning: They were meant to be the core identity of the game, and one of the two major design pillars the game was about.
As a result, we started A Year Of Rain with the very basic real-time strategy features mentioned above. There was just a handful of different unit types with the basic stats health, damage, cooldown, range and speed – not even armor. There was literally no production cost or duration for units at the very beginning – although it didn’t take us long to learn that might be a good idea. We had a fixed unit limit to account for technical limitations, especially because A Year Of Rain is a multiplayer game. However, players weren’t required to construct any buildings to increase their unit limit. Heroes were limited to a single hero per player per match, and they spawned and re-spawned automatically at the main building after a short time, without players having to construct any special building or even pressing a button.
Every hero started with all abilities unlocked immediately, and leveling up the heroes automatically increased the power of the hero and all abilities. The three factions of the game had unique units from a visual and balancing perspective, and faction identity was mainly achieved and communicated through just the number and power level of units: For instance, House Rupah had about twice as many units on the battlefield than the Outcasts. Finally, we allowed a handful of map elements to increase the replay value of the game: Rocks were blocking paths but could be destroyed by players. Watchtowers granted nearby players vision across a large area. Workers could gather resources faster from rich Anorium mines, and healing wells could mend the wounds of nearby heroes and units. We didn’t even have neutral monsters on the map back then, but we added them pretty soon in order to allow players to come back from a lost fight which most probably resulted in an experience advantage for their opponent.
Then, we were playing the game and analyzing it closely for any problems. Whenever we identified a problem that we weren’t able to solve by existing means, we considered adding new gameplay for handling it. In the case of adding a new feature, we would follow a well-defined process for adding it to the game: The feature had to be approved with both the game and world design departments. After that, the game design document was updated, as well as asset lists, balancing sheets and localization kits. Finally, new tasks were added to our issue trackers, and the project plan was adjusted.
In conclusion, no feature was ever added to the game if it didn’t solve a problem with the game.
In an early version of the game, hero rushes were extremely powerful and always guaranteed to damage the economy of the defending player.
The Case for Upkeep
Ironically, one of the first additional features that found its way into A Year Of Rain was something you don’t find in many real-time strategy games. I had many discussions with Frank Furtwängler, one of our external game designers, about Upkeep.
Upkeep taxes resource gathering, automatically deducting from all Anorium a player gathers in our game. The more units a player controls, the higher the tax. Upkeep comes in three distinct levels, which makes it easier for players to understand and to step into and out from. The design goal of upkeep is keeping the number of units small in order to increase the relative importance of the hero. In addition, it helps to divide the match up into distinctive phases. Instead of just a hard limit like the one we had before, upkeep is player-induced and this puts agency in player hands: Its effect is reversible at (almost) any time for the players. Upkeep fosters more aggressive playstyles, forcing players to move out and expand on the map. Finally, upkeep mitigates slippery slope by imposing a higher tax on better players.
There aren’t too many games using this feature, although it has become more popular recently. Thus, it was definitely not on our initial list, especially not with our Minimum Design approach. In addition, it’s not the first one that comes to mind when thinking about how to make players happy. Still, Frank made a strong case, referring to the hero focus of the game, and it definitely made A Year Of Rain a better game.
Nick is working on the “less is more” approach daily.
Heroes & Ultimate Abilities
After roughly a year into development, our game was presented to a larger group of outside players for the first time. Our friends from TakeTV hosted a secret offline event with many seasoned and professional real-time strategy players to challenge our vision and current state. The feedback was surprisingly positive, and we were able to confirm some of our assumptions and prove others wrong.
One thing, in particular, was mentioned several times, and had been reported by our internal QA before: Hero progression didn’t feel tangible enough. With heroes leveling up to a maximum level of 20, starting with all abilities unlocked, and automatically increasing all ability levels, players sometimes weren’t even able to tell us their hero level after a match. Thus, we improved on our initial skill system step by step, until we reached at our current iteration that feels more in line with similar games: Heroes don’t start with any ability, but with a single ability point. They receive an additional ability point every time they gain a level. Players may either spend ability points to learn a new ability that starts at level 1, or to raise the level of an ability by 1. Clearly, these changes threw most of our heroes and units off-balance, with heroes being far less powerful, so we scaled up all abilities and introduced an ability level cap of 5. Now, as heroes would be able to raise a single ability to level 5 just by spending five consecutive ability points, they had access to an ability that was far too powerful for the current game phase. For that reason, we added a skill system that prevented players from leveling up the same ability multiple times consecutively. This is an excellent example of facing problems one by one, understanding them, and moving away from our initial Minimum Design towards a more sophisticated and fun solution.
In order to further improve the feeling of the hero progression, we finally opted to reduce the hero level cap to level 12 and introduce ultimate abilities. I had been reluctant to do so because I was afraid of slippery slope, but ultimate abilities turn out to provide a very graspable and gratifying goal for the player, something that’s worth collecting experience for. In addition, during later phases of the game, they are able to create an escalation moment, thus avoiding slow death of the player behind.
Rush Protection
Hero rushes are another great example for a problem in A Year Of Rain that made us add another feature. Originally, our Paladin hero was quite powerful, especially with the setup with all abilities unlocked at level 1. With the high sustainability and an ability to ignite her weapon in flames for a short duration, early hero rushes were almost guaranteed to kill multiple workers before she was driven off or killed.
For that reason, we added a rush protection mechanic that allowed players to defend against assaults in early stages of the game. Each faction has a different way of doing so, which improves faction identity as well, another thing we’ve been struggling with due to our Minimum Design approach.
Later, we even added another ability for boosting the economy for a short time. This ability shares a cooldown with the rush protection ability, introducing a new decision for the player, and decisions for players are rarely a bad idea.
However, as hero balancing has changed drastically since then, this leads us to another interesting aspect of our design approach: Strictly speaking, we’d need to challenge our rush protection feature again, as it might no longer be required – and in turn, the economy boost feature.
Each player role in A Year Of Rain comes with a unique set of upgrades, closely tied to the identity of the faction of the player.
Minimum Design vs. Identity
As already mentioned, the Minimum Design approach as applied by our team came with a drawback: Because we aren’t forging a new game mechanic or even an entire genre from scratch, it’s a challenge to infuse the game with identity without causing feature creep.
Making A Year Of Rain an entirely team-based real-time strategy game definitely helps by creating a unique position in the market, and as the second design pillar, it helps with the identity of the game from a design perspective as well. Other steps we took included the introduction of unit upgrades as mentioned at the beginning of this article, but with a twist: Instead of just adding plain old +1/+2/+3 damage upgrades for the whole army, we tied upgrades to factions. While House Rupah has exactly these plain damage upgrades, the Outcasts have three levels of attack speed upgrades instead. The overall effect stays the same – increasing the total damage output of the army – but these upgrades further emphasize the ferocious nature of the faction.
We are still experimenting with other means of making the factions more unique, without introducing new major features wherever possible.
Deviations & Future Work
If you’ve read this article carefully and know a few things about A Year Of Rain, you might ask why there are two different resources in the game. The original idea was to allow for more interesting player decisions, with limiting access to the second resource and forcing players to decide whether to construct additional production buildings or climbing the tech tree, for instance. However, there are strategy games out there that do just fine with a single resource, and in retrospect, I have to admit that this is a deviation from the Minimum Design approach. I don’t think it’s been hurting the game experience, though, so we might be okay without throwing them out again.
It is worth noting that Minimum Design just applies to the game design on system level. To match the very high standards in the real-time strategy genre, we had a sophisticated user interface and user experience design in place early on, and kept improving on it during the whole development period based on player feedback and our own game experience.
In any case, Minimum Design allowed our small team to create a fun game with a solid core and interesting, unique additional features. That doesn’t mean that there isn’t more on our roadmap: We’ve got many things we’d love to try out and add to the game, eventually. Traditional games have a slightly larger set of units per faction, including harass units and air units. Moreover, I’m still jealous of the beautiful elegance of Tiberium in Command & Conquer, which serves as a resource source, protects harvesters from early aggression by damaging specific unit types, and allows for endless world building opportunities. Perhaps we’ll add more units to our game in the future, or make resources themselves more interesting and versatile. But first, we’ll have to see if that solves another problem.
Nick Prühs
Nick is the Technical Director of Daedalic Entertainment, and Microsoft MVP. In 2009, he graduated as “Best Bachelor” in Computer Science at Kiel University. Two years later, he finished his master’s degree in Sound, Vision, Games at Hamburg University of Applied Sciences, founding Slash Games with Christian Oeing shortly after.