Iron Harvest
Game Designer
For almost 3 years I worked on Iron Harvest, a classic real time strategy game set in Jakub Rozalski's 1920+ world. I started at KING Art Games as a game design intern in September 2019 and graduated in July 2020. I continued working on Iron Harvest for almost 2 years, in the liveteam and on the two addons we released. I worked primarily on balancing, system design & metagame design.
I was also end responsible for the Playstation 5 and Xbox Series S/X version of Iron Harvest. To read more about that, click here.
I was also end responsible for the Playstation 5 and Xbox Series S/X version of Iron Harvest. To read more about that, click here.
My contribution
|
Balancing
I worked on game balance for Iron Harvest, from beta to the last patch. Player feedback and telemetry data were the key insights into the state of the game at any given point. While AAA RTS games have teams dedicated to game balance, KING Art’s limited resources in this field provided a great learning experience. Understanding what key elements drive the fairness of the game, which changes could cause instability, and looking at balance from both a context and value perspective became the key ways we could work effectively within our constraints while ensuring fairness. |
|
Resource system rebalancing
During development of Iron harvest, I investigated the in-match economy. We noticed that many matches seemed to progress very equally until suddenly one player was doing much better than the other. I created an Excel sheet to transfer match data into workable values, which tracked resource income at all points throughout the match. We could then adjust the income values to simulate what kinds of numbers would have lead to a different result. By doing this we gained deep insights into the weaknesses and strengths of our in-match economy. I did an overhaul of resource point income and unit costs to address the issues we found and ever since, the economy has been a much more stable part of the game. |
Graph showing how resource income differs between two players playing the same match against each other.
|
|
Autobattle
For Iron Harvest’s Worldmap mode we wanted to have an autobattle feature to allow players to skip fights from which the outcome is very likely already known (an easy win for example). The system is made up of two components, the evaluation of winchance and the generation of the outcome. The AI and player are evaluated differently: the player has an inherit advantage that is difficult to actually spot while playing. A key reason for this advantage is that actual randomness feels very unfair. The generation of the outcome (win/lose and army casualties) is based on a very complex formula that matches the outcome to an experience we think fits best to the game and feature. There is randomness in a range based on bell curves, to ensure very (un)lucky results happen infrequently. |
|
Metagame progression
A key issue with finding the right values for metagame progression is that the number of players interacting with that system in unique ways vastly outnumber testing capabilities. I used Excel to create a simulation of how different player profiles would play through the game. Based on the profiles partially random progression through the game was rolled out. The sheet could generate hundreds of playthroughs in very little time, allowing us to see how players with different interest would level up, acquire XP and gain rewards. |
|
Porting Iron Harvest to Playstation and Xbox
Iron Harvest was always designed with mouse and keyboard as primary input, and the Playstation and Xbox version were mostly an afterthought. I was responsible for making the game as playable with a controller as it was with mouse and keyboard. One of the most challenging parts was the lack of reference material for controller based RTS games. The other key challenge was that design decisions predating my start at Iron Harvest had major impact on the usability of Iron Harvest. My work on the console version has always been in the light of those two challenges.
|
Cursor
One such challenge was the selection of units. Whenever big fights occured, it would be super difficult to tell what unit you were about to select. The entities of different friendly and enemy units would overlap in ways that caused a lot of problems. We tried multiple cursor modes, such as the magnetic cursor. This variant snaps to the “key entity” within a unit. We iterated many times on the strength of the magnet and how exactly it behaves. Our internal ruleset for selection became very complicated to provide the most straightforward experience for the players. |
|
Difficulty
Throughout the frequent playtests, concerns about difficulty consistently popped up. While initially partially attributed to not having all controller features implemented yet, we soon realised we needed an actual systemic solution. Adjusting every map was not realistic for us, and likely a very expensive solution. Instead, we opted for a modifier based difficulty adjustments. These modifiers give the player an advantage by reducing the damage output and HP of enemy units. It allows the player more wiggle room within combat. And this is key for playing Iron Harvest with a controller: more forgiving gameplay to minimize/avoid frustration.
Throughout the frequent playtests, concerns about difficulty consistently popped up. While initially partially attributed to not having all controller features implemented yet, we soon realised we needed an actual systemic solution. Adjusting every map was not realistic for us, and likely a very expensive solution. Instead, we opted for a modifier based difficulty adjustments. These modifiers give the player an advantage by reducing the damage output and HP of enemy units. It allows the player more wiggle room within combat. And this is key for playing Iron Harvest with a controller: more forgiving gameplay to minimize/avoid frustration.
|
|
