OWLET

DETAILS

Role

System Designer

Engine

Custom

Team size

Project length

8 Weeks

Genre

Real-Time Strategy

Platform

Itch.io

OVERVIEW

Summary

In this project, I concepted, designed and released a real-time strategy game made for beginners using a custom engine with a team of 14 developers.

My work

Concepted a beginner friendly RTS game that could be made in 8 weeks using a custom engine
Designed the game's systems (economy, units, buildings) and made them work together
Performed multiple play tests and iterated on my designs based on the data collected

GAME TRAILER

TIMELINE

CONCEPTING

What do we make, how and why?

Project Constraints

Like all projects, we faced constraints, mainly regarding time, team size and technology. As the representative for the game's design, I was heavily involved with defining these constraints so that we could work around them. I did this by analysing the project brief and communicating with the other disciplines so that we can avoid the pitfalls of our project.

Owlet's Project Constraints

Design Pillars

As the sole system designer in the project, I was responsible for defining the game's design pillars. I did so by taking into account the project constraints and considering the other discipline requirements. I followed these pillars when designing to ensure that my work was cohesive and feasible.

Owlet's Design Pillars

DESIGN & DEVELOPMENT

What did I do, how and why?

Game Economy

After concepting, I researched our reference games (Diplomacy Is Not An Option, Age of Empires III & Anno 1800) and was able to conclude that in RTS games the most central system is the economy and designing it should be the first step.

RTS economies very quickly become quite complex and there is a skill to managing them. The standard is to have units or buildings whose sole purpose is to generate resources. This did not fit two of our pillars: Beginner Friendly and Combat Focussed presenting the first design problem:

How do I Design a Simple Economy that is Directly Tied to Combat?

Since Owlet's economy could not follow the RTS conventions for an economy, I looked at a very similar genre, tower defence. In those games, it is very common to have the enemy units be the resources creating a simpler economy loop where combat and resources are directly tied together.

Simplified Economy Loop for a Tower Defence Game

For further investigation into the economies of tower defence games, I researched real-time tower defence games where the player controls unit(s) (Thronefall & Kingdom: Classic). With this research and some iterating, I created the following diagram:

Owlet's Game Economy Diagram

How Should Resources be Collected?

When I designed the economy, I made the decision that killing an enemy unit would drop a physical version of the resource for players to pick up, opting away from automatic collection. The reasoning was that it would add to the gameplay and teach beginners the basics of unit positioning by forcing them to move their units.

There were concerns that this would add too much complexity to the game and that the trade-off would not be worth it. We decided to A/B test the two options to make a data-driven decision. The playtesting showed that players did not intuitively pick up the resources and found it overwhelming. The decision was made to switch to automatic collection.

Enemies Dropping Collectable Resources

Resources Being Collected Automatically

The final design decision for the economy were the resource types. To match the game pillar of decision making, I chose to have two resources as this would expand the possible choices without overwhelming the player. This decision directly affected the design of the units and buildings.

Buildings

What Buildings Should be Available?

The final piece of the puzzle regarding the gameplay systems was the design of the buildings. Early on I decided to opt out of having traditional outpost buildings that defend your base because it would work against the design of the units. I instead wanted the buildings to prioritise the units as the source of DPS.

For this, I chose to have the main building be for spawning units and since each unit was linked to a different resource type, it made sense to separate the spawning into two buildings, a swordsmen tower and a mage tower.

To give the player more choice with how to spend their resources, it was important to have the buildings be upgradable offering unique benefits such as faster spawning time.

The Four Upgrade Versions of the Swordsmen Tower

The Four Upgrade Versions of the Mage Tower

How to Balance a Dominant Strategy?

While playtesting, a dominant strategy emerged, build one tower of each type and upgrade it to the max as soon as possible. There was no incentive to build multiple towers so I iterated on the design and added a unit spawning limit. This limit incentivised players to build new towers without removing the benefits of upgrading the towers.

Units

Following the design of the game's economy, the next step was to design the player and enemy units, especially considering the enemies are the source of resources in the economy. It was decided that we would have two resource types and for the sake of cohesion and simplicity, I decided to create symmetrical unit designs, both sides would have one melee unit and one ranged unit. It therefore felt natural to make each unit type linked to their own resource type.

How Should the Units Interact with Each Other?

Owlet Player Units High Level Design.jpg

Player Unit High Level Design

Enemy Unit High Level Design

Owlet Visualisation of Unit Strengths and Weaknesses.jpg

Overview of the Units from Strongest to Weakest Per Attribute

Having defined the high level design of the units, I created a spreadsheet to start inputting values that matched the goals and intentions of the unit designs. The spreadsheet is automated and colour coordinated to show whether the values are in line with the intended outcome. The formulas are explained via comments on the sheet for the team to understand my decision making.

Unit Balancing Sheet (Download Document)

Waves

As well as choosing a simpler economy loop inspired by tower defence games, I also elected to have a wave style AI manager instead of the more traditional RTS AI manager. This decision was made not only due to the game pillars but also because of the project constraints (custom engine, time, only 1 system designer).

How Should the Enemy Units Spawn?

To make every wave feel unique and challenging, as well as allowing for replayability, we decided to opt for weighted randomness on where enemies spawn and the types/number of enemies. When inputting the values for the weight scaling, it was very important to consider the subsequent resources that would be dropped by the enemies.

Enemies Spawning in Random Positions

Random Types of Enemies Spawning

Takeaways

Being the only system designer on a system heavy game was both challenging and rewarding. I had a lot of responsibilities on my shoulders and with more help/time I would have liked to delve deeper into the systems. However, the freedom to make my own decisions and be solely responsible for several features was very enjoyable and gave me a lot of confidence. It was a big undertaking and I believe that I thrived under the pressure. This project has convinced me that I would like to work on system design in the industry.

I joined this project partly to have the opportunity to work on a custom engine, in doing so I learned a lot about relying on tech and was able to explore the world of paper prototyping. Since I could not directly implement my own designs without help from one of the programmers, a lot of my work was done on paper. While this helped speed up the process of designing the various systems, the delay in implementation made it less possible to iterate on my designs. Having such a tight time constraint on a custom engine project was disruptive and for shorter projects, I would like to stick to commercial engines.

Throughout the whole project, cross-discipline communication was key to maintaining a feasible scope. During the process of designing the systems for the game, I was constantly talking to programmers and artists to get their input on how realistic my decisions were. This constant back and forth was really healthy for the project and I will always aim to replicate it in future.

Because I was slowed down by the technical constraints of the custom engine, I relied even more on play testing my designs to iterate on them as soon as possible. This made it especially frustrating when I had to cancel a playtesting session because there was a critical issue with the build. This project really reiterated to me the importance of playtesting early and frequently as well as maintaining a healthy build at all times.

Thomas Silverthorn | Technical Game Designer | Thomas@silverthorndesigns.com