Game Designer | Thomas Silverthorn | Thomas@silverthorndesigns.com
OWLET
Genre:
Real-time Strategy
Role:
Technical Designer
Engine:
Custom
Owlet is a real-time strategy game where players expand and upgrade their town while defending from an endless horde of creatures. Owlet's design pillars were beginner friendly, combat focussed and decision making.
​
I was responsible for designing the game's systems (economy, units, buildings) while adhering to the design pillars and working collaboratively with the other disciplines.
Team size:
14
Project length:
8 weeks
Released:
PROJECT CONTRIBUTIONS
DESIGNING THE ECONOMY
Every system in a real-time strategy game is intrinsically linked to the economy. By first designing the economy, I was able to design a high-level overview of the game itself. I used diagrams and spreadsheets while working on the economy as this allowed me to prototype and iterate rapidly based on the play testing data.
A beginner friendly economy
Per the design pillars, it was important that the economy was simple and easy to understand, particularly by players who are unfamiliar with the genre.
My research showed me that the traditional RTS concepts such as production units (e.g., villagers), production buildings (e.g., windmills) and many resource types were all too complex for a beginner. Instead I found my inspiration in the tower defence genre and designed the economy to revolve around killing enemy units. Testing showed that this system was much more intuitive.
​
It also had the upside of requiring fewer art assets and since our team only had 3 visual artists, I designed the game around this project constraint.
Allowing for decision making
Although the economy was designed to be beginner friendly and intuitive, real-time strategy games require players to make meaningful decisions. In the case of an economy, the decision to be made is "how to spend the resources you've gathered?".
Given that the game was combat focussed, each decision allows the player to increase their combat strength in slightly different ways. Spawning new units has an immediate short-term effect, building a new building has a mid-term effect and upgrading an existing building has a long-term effect. These three decisions were balanced to be optimal in different stages of the game in a way that avoids becoming solved and stale.
Adjusting to playtest feedback and data
Originally, killing an enemy unit dropped a physical item on the battlefield that needed to be picked up by the player units. The intention behind this was to teach the players the importance of unit positioning, to give the player a secondary objective once they had survived the wave of enemies and to give the economy a physical presence in the game to help new players.
We found during playtests that the players struggled to pick up the resources as they were overwhelmed by having too much to worry about. This was accidentally punishing beginner players as the resources would disappear before they were able to collect them.
My bias as an experienced RTS player hindered my ability to recognise that this design was detrimental to the beginner friendly design pillar. After testing a few other options of collecting resources, we decided to make it automatic and let the players focus on the rest of the game. This was a well received change and served as a valuable reminder of the importance of playtesting.
The final draft of my game economy diagram​​
Enemies dropping collectable resources​​
Resources being collected automatically
DESIGNING THE UNITS
AND WAVE SYSTEM
How players interact with RTS games is through controllable units. In Owlet, these are warrior owls who either fight with a sword or with a staff. The enemy units the owls must fight are tree and stone golems. The wave system controls how the enemy units spawn. I designed these systems on paper and in a spreadsheet to quickly balance the combat.
Designing beginner friendly units
Owlet being combat focussed meant the combat was the most important system in the game, however it still needed to be intuitive to beginners. To do so, I limited the number of unit types to two, a swordsman (melee) and a mage (ranged). I mirrored this in the design of the enemies by having a tree golem (melee) and a stone golem (melee). I also limited the unit attributes down to a list of five: health, attack, movement speed, attack cooldown and attack range. With this foundation in place, I was able to design and balance the combat.
​
The next step was to define the design goals and intended player experience for each unit. For example, the goal of the swordsman owl is to be the player's most common unit, cheap to spawn but quick to die. I designed it in this way because I noticed that players feel strong when having many units to control, even if the units are relatively weak. On the other hand, the mage owl is designed to be expensive but much stronger. This allowed the players to have quantity and quality in their armies. This dynamic was reflected in the unit attributes as well as in the economy design.
​​
Once I had the design goals for each unit, I started looking at the exact attribute values. In order for the values to make sense, I decided to rank the units based on their strengths and weaknesses. This allowed me to balance the attribute values while referring the design goals.
Using the rankings, I chose an anchor point to revolve around. This ended up being the stone golem as they were the strongest unit in the game. Once I had used some base values, I was able to experiment with attribute values for each unit and match them to the design goals. The attack and attack cooldown values allowed me to calculate each unit's damage per second and from there, how many seconds and hits the units required to kill each other.
I then was able to implement them into the engine and start testing the values. Following the design goals I stated and playtesting data, I estimated how many hits per unit would feel fair to the player. Using this, I modified the attribute values until they matched the intended design.
​
​As the person responsible for the design and balance of the combat, the game's core, it was very important that I followed a logical progression in my design and that the rest of the team could understand the design intent without any extra explanation. With the occasional complications that arose regarding the custom engine, having my work documented in such a way was extremely beneficial to the development of Owlet.
Diagram ranking the units from strongest to weakest per attribute
Screenshot of my balancing sheet showing the unit values
How do enemies spawn?
With the units implemented into the engine, designing how the enemies spawn was the next step. We decided early on that we wanted the game to revolve around endless waves of enemies using the waves as a score. This meant that players could play against themselves and try to beat their own high scores. The game only ends when the player's cathedral is destroyed, which happens when the player makes a mistake. This would foster a player behaviour of wanting to try again, perfect for beginners to learn how to improve.
​
To make the replay ability of the game appetising to players, some randomness was required. That randomness was chosen to be where the enemy units spawn as this was a system unaffected by player actions. We also decided to randomise the number of units in each wave, however they were weighted to be of similar difficulties. This had the desired effect of keeping each game unique. The number and type of enemy units that spawn also directly correlates to the economy system which I had to balance accordingly. The type and the amount of resources was therefore also randomised, within a range, meaning that players had to adapt to each playthrough and make decisions accordingly.
​​
A subsequent effect of the weighted randomness was that the first few waves had little room to be randomised. This resulted in the first waves being less random, allowing beginners who did not survive the beginning of the game to not be overwhelmed by the constantly changing gameplay. The randomness became more significant the longer the player survived, giving the more experienced players an added challenge.
​
Designing an RTS game for a beginner, while keeping it enjoyable for somebody with experience in the genre was a reoccurring problem I faced throughout development. The design and implementation of the wave system was an elegant solution to this problem.
Unit steering features
Playtesting revealed that the player units were not enjoyable or reliable to control. The AI system was custom made, like the engine, and navigating this issue had some extra difficulties.
I researched the way other RTS games control their units and how they avoid grouping them together in one space. This led me to researching steering behaviours and creating a detailed design spec for the programmer in charge of the feature to follow. I defined the desired behaviour when units collide with each other and which forces to apply to the units to make them move together as a cohesive group.
I helped him throughout the development, giving feedback and requesting changes so that it was closer to the design. The final product was not perfect due to time constraints and problems with the engine, however it vastly improved the user experience for the players.
Enemies spawning in random positions
Random types of enemies spawning
DESIGNING THE BUILDINGS
Buildings in RTS games are the secondary way that players interact with the game. They give the player access to new actions and a safe space in the map that they must defend. In Owlet, the central cathedral serves as the lose condition of the game. I designed the buildings using paper and spreadsheets to allow for rapid prototyping.
Simple and intuitive buildings
As with the rest of the game, the designs for the buildings were simplified to be accessible to beginners. There are only 5 types of buildings and they each have a single use, making their utility simple to grasp. Two unit production buildings, two defensive buildings that slow down enemies and the cathedral which ends the game when destroyed.
​
Similarly to the unit designs, I defined each building's design goal and used these to balance the attributes of the buildings. I decided to separate the unit production buildings and defensive buildings so that I could balance the costs for each building to be relative to their respective resources. This allowed the wood based buildings to be cheap but weak and the stone buildings to be strong but expensive, matching the design of the units and economy system.
​
One of the most iconic RTS buildings is the outpost, a building that attacks enemies automatically to defend the town as a last resort. I decided not to implement this building into the design of Owlet because it's design goal did not fit the game's intended gameplay. Owlet is about protecting the cathedral with your army of owls. There is no incentive for the player to position their armies aggressively (e.g., attacking another player) and adding an outpost style building to the combat design was an added complication that added little benefit.
​
Instead of the outpost building, I instead explored the possibility of having buildings that increased the nearby owl's stats. The buff towers would improve a chosen attribute for all owls within a specific range (e.g., increased health). This was designed to give the players access to another choice when spending resources to improve their defences while only amplifying the existing combat system. It was also designed to teach the importance of building and unit positioning to players by punishing players who don't strategise effectively.
​
When building a buff tower, the player could choose which attribute they wanted to increase, further increasing the decision making and importance of the building's placement. Ultimately, the buff buildings were cut from the game after testing revealed that they were only interesting to experienced players and inexperienced players ignored them. It also allowed us to reduce our scope and polish the rest of the gameplay.
Adding complexity and player choice
The ability for buildings to be upgraded was designed so that players had a long-term strategic choice where they could invest their resources to improve the existing buildings. Upgrading the cathedral not only increased the building's health, it also unlocked the upgrades for the other buildings. This limitation pushed players towards upgrading all their buildings at the same time, instead of upgrading one to the max level, allowing the progression to be more balanced and for the whole town to improve visually together.
​
The unit production buildings can be upgraded to reduce the cost of recruiting a unit and the time it takes to spawn said unit. This was designed to allow players to recuperate the money they invested by simply not spending as much in future purchases, allowing for more troops to be spawned. This results in the same number of resources equalling more units, which had repercussions on the economy and wave system balance. This allowed for the progression to become more exponential, which solved the issue of having a boring linear progression.
​
The defensive buildings (fences and walls) did not need upgrades as they were in effect already upgrades of each other. The fences were designed to be plentiful but easy to destroy whereas the walls were more expensive but much sturdier. This dynamic did not need expanding upon.
Limiting the number of units
While testing, we noticed a dominant strategy appearing, only buying units. Despite the design of the buildings and upgrades trying to avoid this from happening, an extra step that would limit this strategy was missing. The chosen solution was to add a population limit to the units which could only be increased by interacting with buildings.
​
Players now had to build new buildings or upgrade the existing ones if they wanted to spawn more units. At first I was concerned that players would ignore the upgrades and simply build dozens of buildings instead, however the level design halted this strategy.
​
I decided to divide the population resource into swordsmen owls and mage owls to avoid damaging the design goals for each unit. If the number of swordsmen towers affected the available number of mage owls, it would have ramifications on the combat. The unit populations also gave me another lever to pull while balancing the combat and I had to adjust the wave and economy systems accordingly.
All 4 upgrade versions of the swordsmen tower
All 4 upgrade versions of the mage tower
Levels 1 & 2 of the cathedral building
Levels 3 & 4 of the cathedral building
POLISHING THE USER EXPERIENCE
In a genre like RTS where there are many actions happening at once, the importance of gameplay readability is unmatched. This means that the user interface, the opening sequence, the instructions, the feedforward and feedback, and the audio design all need to be as well polished as they can be.
User Interface in a custom engine
We understood the importance of the user interface immediately, however the limitations of the custom engine hindered our progress significantly. The engine could only handle hard coded UI, which did not allow for rapid prototyping or iterations.
While the UI tool was being built from scratch, I created some mock-ups based on the research I did for the artist to follow. Unfortunately due to delays with the UI tool and the UI art, the implementation happened later than planned, reducing the amount of time for feedback and the time available to polish the user interface.
Making a tutorial for an RTS
Since our target audience were players new to the genre, the opening sequence and tutorial were crucial in getting the players to start learning. Early on, I wrote down the intended order to introduce the mechanics to the player and we were able to make decisions around this.
For example, we decided to have the game start with a ruined version of the cathedral and the player was tasked with restoring it. This allowed us to introduce upgrading buildings without needing to pause the gameplay.
​
A point of learning that I encountered during the process of working on the tutorial was to avoid my biases from deciding what should or shouldn't be explained. I initially expected not requiring to teach players how to control the camera and how to select units but testing soon pointed out that this was necessary to teach players.
​
To explain the game, I designed pop-up messages for the player to read. I made these skippable for experienced players however this ended up being a mistake. During testing, several inexperienced players skipped the tutorial before reading a single word and when their attempt to figure the game out on their own failed, they had to ask for help. This was shocked me and gave me first hand experience in player psychology and tutorial design.