Making of Iron Harvest: Flying (too) Close to the Sun

Justin Zwack grants insights into the boss design of Iron Harvest.

Since the early days of video games, boss battles have played a special part in the player’s journey through their favorite games — most of the time serving as intense and challenging ­encounters that push players to their ­limits. Boss fights and their design have become a really good tool for game designers to shape special encounters that stand out from the rest of the game and will eventually be remembered by a lot of players. You can use a boss in a video game to control the pacing and play around with the overall gameplay. There are several purposes it can fulfill based on the intentions of the designer. It can simply be a narrative ­conclusion and reward at the end of a ­section, or it is a final skill test that serves as a gate blocking the player’s progress. It can also be used as a storytelling device that gives the plot more context and the enemy more ­personality.

For Iron Harvest we decided for a final boss that should finish the main campaign in a big spectacle and offers players something different from the other missions in the game.

Key ingredients for an interesting boss

We had to think about what makes such an enemy interesting in a classic RTS with dieselpunk mechs early on. Obviously, big mechs and their destructive powers are key elements of our game, and therefore it was not a hard decision to focus on that and create an even bigger mech with an even bigger focus on destruction. Additionally, there was this narrative that Tesla created automated war machines that are valuable for all factions, which created a great plot point allowing us to gather characters from all nations at one spot. With a paranoid and isolated scientist having control over ­extremely powerful mechs, that could turn the tides in the ongoing war, Project Icarus was born.

We decided Project Icarus is Tesla’s last resort. It is a final protocol to defend his ­inventions and technology from the outside and, if activated, would automatically load energy into a bomb to destroy everything around it. This topic of an enemy that is not controlled by a human following strict rules, gave us a clear first concept of what the boss encounter could look like.

Before going into the details on how the boss fight was shaped let’s take a quick look at the final result. The boss fight’s premise in Iron Harvest is rather simple. It is about destroying Icarus before it gathered enough energy and can detonate its bomb. To charge the EMP bomb to full capacity, the mech must walk to several power ­supplies one after another.

While charging the energy at those ­locations, Icarus needs to lower its defenses, creating a window of opportunity for the player to inflict damage. Once Icarus is done with a power supply, it starts to shield itself again and walks to the next one, while players can’t inflict any damage. This behavior based on two distinct states creates a gameplay loop that is simple enough to understand at a glance but provides enough opportunities to control the pacing.

Additionally, there are several smaller enemy units constantly fighting against the player. We wanted the player to split their focus and use their units for multiple targets always shifting priorities. For these so called “minion” units we use different mechs created by Tesla that all have their own role within the boss fight. To escalate the encounter over time we not only increase the number of enemies but also unlock different attacks for Icarus and ­additional behaviors for minion units, e.g., repairing Icarus. All of this puts the player under constant pressure while still creating an objective that is easy to understand. Now with the overall fight summarized, we can go in more detail how we got there.

Making use of successful action game concepts

While working on the boss design for Iron Harvest, I also finished my bachelor ­thesis, which explored characteristics of a universally applicable framework for boss ­encounters. It focused on finding common elements from boss fights in action games that can be transferred to other genres like in the case of Iron Harvest a classic RTS.

The most significant difference between boss encounters in action and RTS games is the focus of the player. In action games, it is way more common to have a narrow focus on a few enemies or even just one dangerous threat such as a single boss. In contrast, it is the complete opposite in the core gameplay of RTS games. As most ­offer big fights with many units fighting each other at the same time. Several elements of an encounter are splitting the focus and attention of the player. In addition to that, the indirect control of issuing commands to specific units slows down the combat’s pacing.

So even though there are quite some differences there are still specific principles that can be analyzed and isolated which help designers to make informed decisions about the design of a boss encounter. Throughout my thesis I established a framework that lists several of these principles that serve as a guide and foundation for designing a boss.

The elements can be constructed under four major themes, which go from high-­level to low-level:

• constraints: limit the possible gameplay
• purpose: defines what you want to achieve
• pillars: set the main vision and communicate the goals
• components: show possibilities and guide the player’s experience and fun

Building up the concept

The next section might be design heavy so bear with me when I dive deeper into the first 3 parts of that framework and what they meant for the concept of Project Icarus.

Constraints

At first, we analyzed the core loop and player actions, looked at our target ­audience and decided on the focus for our boss fight as well as the intended difficulty. We also took other constraints into account like scope, story, or time. In Iron Harvest, the gameplay is particularly focusing on unit management and strategy building. The macro-management of how players are using their units is essential, but the micro-management of special abilities and the infantry’s cover system is also important. Even though building structures and units are also part of the core, we excluded it from the boss fight as the resource management would draw away the attention of the player. We decided on a more straightforward approach with a simple objective.

Purpose

To define the purpose of the boss fight we elaborated the mechanical intent and ­clarified to what degree it should block progress, test skills, add variation, or resolve the narrative. We also established a general experience to aim for.

On a mechanical level, the boss fight is about testing the players’ skill of using and managing the hero units and their abilities. As it is the last mission in the campaign, the encounter is the last progress block to resolve the narrative. Because the previous mission was the final test of skill in terms of core RTS gameplay the final boss fight may not be the most difficult mission but should still provide an escalating experience with a lot of spectacle. The boss fight should feel dramatic and intense putting the player under constant pressure. It should highlight the joined force of all factions and display the urgency to destroy the huge mech ­before it can fire its bomb. The success of preventing the explosion needs to feel like a close call and a great payoff.

Pillars

To get everybody on board we communicated the high-level design pillars and combined the different gameplay concepts to a simple but coherent experience. Whereby the two most important gameplay pillars were constant pressure and clear communication. These were shaping the general structure, including distinct phases but also clear states and attacks of the boss. We set the pacing curve that should describe the constant tension rise through challenge and spectacle leading up to a climax and satisfying conclusion.

The aesthetic is also influenced by the constraints, purpose, and gameplay ­pillars. We set rules and themes which should ­support communication and make use of established expectations like the impressive size of a boss or the visual implications of its parts. In our case, Icarus is way bigger than regular units. However, the size is ­limited by the camera view and the size of the map. Like other inventions of Tesla, it signifies an electrical affinity due to its visual design. To further support the communication, special moves and attacks are telegraphed early and the states of ­vulnerability and invulnerability have been designed with different shapes and effects. We were even able to make use of the classical trope of glowing weak spots as it fits the overall theme of electricity.

Boss Design Framework

• Constraints: Core Mechanics, Target Audience, Others
• Purpose: Mechanical Intent, Aimed Experience
• Pillars: Gameplay, Pacing, Narrative, Aesthetic
• Components: Actors, Environment, Phases and Escalation, Move Set, Dealing Damage, Surviving, Windows of Opportunity, Coup de Grace, Reward

The challenges along the way

As strong as the first ideas might have been the journey to the final version was quite long and had its own challenges. When I started to work on the different components of the boss encounter, I ­began with a quick pitch that allowed me to convey the overall structure and order of events. This provided a visual anchor while we talked about the different phases and gameplay systems that should support our pillars and fit within the purpose of the boss fight. Due to its very nature, a boss encounter needs expertise from every field. Therefore, it was important to get everybody on board. That meant many meetings with a lot of people from all departments and ­naturally some back and forth to find the best possible ­solutions. One challenge was to find the right roles for the additional enemies that we wanted to include in the fight.

The individual roles of these ­“minion” mechs should force the players to shift their focus and change priorities. In the ­beginning, we had different constellations of abilities and mechs, but besides Icarus, we ended up with three ­additional mechs:

• The smaller “Sluga” mechs are fast short-range units and are easy to destroy but come in big numbers at the player, allowing the player to feel powerful by destroying several units at once. They can also repair the boss throughout the fight, as repairing and supporting Tesla in his work was their main purpose before they were used for the fight.
• The other small “Baterija” mechs are not able to fight but are walking energy ­containers charging Icarus’ bomb ­without it being at a power supply. ­Similar to the “Sluga” mechs, they are easy to destroy but create big explosions that can damage nearby units.
• The bigger “Cuvar” mechs are way stronger and sturdier medium-range units and serve as smaller mini bosses in between which need to be tackled with bigger guns and abilities. They are the guardians of Tesla’s Factory and were made to defend it.

Because we needed to adjust how many enemies are fighting against the player to control the pacing and difficulty, we ­needed a way to spawn them whenever we need from multiple positions. For that we designed shafts that allowed those minion mechs to be spawned over and over again. It supported the narrative of a huge ­factory as it indicates there is even more under the surface and underlined the theme of the smaller mechs that crawl out of these shafts just like an army of spiders.

The biggest scripting challenge was to control the pacing in a way that creates tension and pushes the whole experience to feel like a race against time. We did not want to give the player a sense of security, but rather keep them engaged up until the very end. To do that, we needed to tweak the time to charge the energy for the bomb and how long Icarus stays vulnerable. Therefore, the charging speed is adjusted on the fly based on the difference between health and energy. This means, if the player needs to catch up, Icarus stays vulnerable for a bit longer than usual. Most players who understood the general mechanics can still finish the final mission on a high note rather than not win because they may have missed to time some abilities or because one of their heroes died in the beginning. During development we needed to find the right balance between too much or too little control behind the curtains as it should not feel like the player has no active role but still provide enough buffer zones.

As game development can throw some unexpected hurdles along your way, this custom scripting needed a lot of maintenance as bugs got fixed and new abilities or features got introduced. Especially as many boss features came in pretty late in production, tests and evaluations ­happened very quickly. The introduction of hero leveling and adjustments to the difficulty settings led to very different results on easy and hard difficulty. So, I ensured that the custom feedback loops are still working regardless of which difficulty ­setting the player chooses. The final version still ­creates the feeling of a close call, but we did not manage to get it on the same tension level for every difficulty setting.

Looking back on the battlefield

Even though we started with the first concept quite early, most features came in rather late, which led to a lot of adjustments and cuts at the later part of the production. For example, in one of the earlier concepts, players were able to control a small ­selection of different units from all factions and even a squad of Teslas’ “Setac” exo-skeleton units to fight against Icarus and its minions. However, we chose to focus on the heroes and created a narrative moment that allowed for reinforcements from all factions to come in and save the day by helping the player. These reinforcements are controlled by an AI and fight against the countless minions, so they do not interfere with the player’s actions against Icarus. We lost a potentially cool feature to play around with but, in return, got a more ­focused experience that was highlighting the narrative theme of working together.

Another big feature that we needed to simplify was the design of the power supplies. In the first concepts, there were ­multiple ways of dealing damage to Icarus or reducing its energy gain, which should play more into the macro management and discovery aspect of the game. For instance, the power supplies were designed to have individually targetable parts that when ­attacked or destroyed would influence how much energy the boss could collect. Again, this might have been interesting for different reasons but with the current system of players being able to only damage Icarus directly, we created a more streamlined version that helped to guide the focus of the encounter.

So even though we needed to adjust and cut some features from the first ­concepts I am still very proud on what we achieved with Project Icarus. Having such a boss fight in an RTS offers a great final beat to the game and allowed us to end the story with a bang. Overall, it was a huge team effort and we created something very ­special.