Iron Line

About project

Iron Line is a tower defence with rogue-like elements, where the player is a train conductor, building and upgrading turrets to prevent the bugs from from reaching the engine.

This project has won the Best Student Game award at the Dutch Game awards, won the Best Design award at BUas (in house award) and was nominated for Best Game Design at the Dutch game awards.

On this project I was a technical designer responsible for the progression system, UI in-engine implementation, turret upgrades, weight system, balancing, documentation and pipeline creation.

Awards

Progression system

The progression system in Iron Line are contracts that the player chooses whenever they arrive at a station. These contracts give the player an extra car to their train and last for a set amount of stations. When the player goes through the set amount of stations the contract in completed and the player hands-in back the car that they received.

The primary reason for this kind of progression system was to introduce a rogue-lite element in the form of an everchanging map that is never the same and also give the player a bit of control over this map. The secondary reason was to help with replayability and player engagement, because the game would never play out the same way as before.

I created the contract menu in the most scalable way possible. The entire menu is a blank template with placeholders for the assets and whenever the player reaches a station, 3 contracts get picked from a data table and the template is filled with that data. Doing this gave our team an easy way to scale up the amount of contracts we had, without needing to change the contract menu. The contracts are not picked completely randomly, but a pool of contracts can be picked from based on the stage of the game.

Turret upgrades

Since upgrades are an essential part of any tower defense game, I spent a large amount of effort on making sure that they would be interesting for the player.

There are 2 tiers of upgrades, first are basic and same for every turret type, and the second ones are the interesting upgrades that change the behaviour and overall usage of the turret. The second tier is different for every turret type.

The reason for these 2 tiers of upgrades was to try to have the player specialize turrets in specific roles and also incentivize combining of different turrets close together. The upgrades are designed in a way that specific turret combinations are much more effective than if these turrets were placed separately.

Weight system

To create a softer fail state for the player I introduced a weight system to the game. Each turret and enemy has a set amount of weight that they add to the car and if that wight goes over the limit the car gets disconnected with all the enemies inside.

The design of the weight system was created by me, and the implementation was done by one of the programmers on our project.

Balancing

Balancing of the game was the work of me and one other designer. As a result of my communication with the programmers we had complete analytics of every stat in the game that we could have wished for.

The approach I took for balancing was to firstly analyse the data we had collected from the playtests and compare them with the notes we had taken from these playtest. Afterwards identify the areas that needed changes, example - low amount of cannons, but high damage contribution means that cannon damage might need adjustments. And lastly make those changes and repeat the playtesting process.

Pipeline creation

One of my responsibilities in the team was to create some of the pipelines that we would use (bug reporting, work reviewing and work submitting). Since the team was quite small (9 people), these pipelines were very straight forward and simple.

Take-aways

Creating fewer, but more complex systems is a great way of having depth in the game without overwhelming the player with mechanics
Balancing can either make or break the game completely, especially when you are going for a specific player experience.
Having detailed analytics greatly helps when it comes both to balancing and checking what exactly happened during the players run

UI

Because I was also in charge of building most of the features that had UI incorporated into them, I was the one that implemented the UI into the engine. The UI elements I created were the progression system, turret placement menu, turret upgrade menu, pause menu, mission screen, car weight and engine health.

Whenever possible I created diegetic UI, to try and bring the player more into the world of the game.

When creating the UI I worked very closely with an artist that made all of the textures for me. Our work pipeline was very simple and it consisted of me creating a mock-up of the UI, me giving it to the artist for adjustments, me receiving the textures and finally implementing them in the engine. Each UI element went through a couple iterations, following the same pipeline.