After a week of hard work, I have released a small game (or a prototype and proof of concept if I act further on the idea).
The game is a puzzle/strategy hybrid, revolving around the player directing units in an efficient and ordered way to defeat the enemy. The game doesn’t have a title, so feel free to call it whatever you’d like.
The following is my post mortem of the project – an overview of what went right and what went wrong. If I expand the project or continue to explore some of the game’s mechanics and concepts, addressing the grievances below will be my starting point.
What Didn’t Work
Balance between the different unit specs was broken.
Although Armour and Attachment Level were directly related (the balance between these two worked fine), I made little attempt to relate Speed and Range to these specs, or each other.
This would result in players generally deploying units in a ‘1 speed, 1 range, 3 armour, 3 attachment level’ configuration.
Given that enemies would never autonomously path Speed was generally useless, with the exception of one puzzle, and for attempting to improve completion times.
Range, although having practical implications, generally played a very small role.
The UI was horrendous.
Entering the Unit Deployment screen for the first time presented the player with a wall of tutorial text that was very difficult to scale. Generally, the UI had very little work put into it.
Level content was rushed, and suffered for it.
Creation of level content didn’t begin until midnight the final day – which explains the delay in release.
After revising my schedule and requirements, I had planned the entire 7th day for content creation. This was continually pushed back by the appearance of major code bugs, as well as some complications with the ‘Zapper’ Attachment Type behaviour – which ended up being cut 4 hours prior to release.
Rushed level content resulted in a small number of levels, created at an inconsistent level of quality. I failed to achieve sufficient difficulty scaling and concept introduction through the progression of the levels.
What Worked
Unit creation and modification, and visual design system.
The unit creation system was the first developed, primarily because it was something fun and visual, allowing me to remain easily motivated when starting off. The original concept called for a higher number of discrete upgrade levels and a rewards system that tied into this. The player was to be awarded additional upgrade points at the conclusion of each level, penned as a way to give meaningful gameplay rewards to the player based on their progress.
In the final release this system had been simplified to just three levels for each stat, capable of being tweaked on a per unit basis. This scaled back version both limits the player’s options and creates greater distinction between each specification level – making the system better suited to the decisive nature of a puzzle game.
I had initial concerns that giving the player only indirect information about their opponents – via the units’ visual profile – would be frustrating. To an extent it is, the player must use observation both visually and through experimentation in interaction, to determine the strengths of their enemies, in turn, determining the units the player must deploy to defeat them. It requires a level of investment on the player’s behalf to learn these systems – but as this game is based on the interaction between units driven by abstract rules that the player must work to understand – building that investment early was important.
Having the player rely on the units’ visual profiles conveys to the player that the game deals with ambiguity and obfuscation, and that use of observation and experimentation skills are required to succeed at the game. This obfuscation creates room for the player to genuinely learn and empower themselves as their understand of rules of the game world increases.
Just as an enemy unit’s specifications are not displayed, the solution to a puzzle is not displayed – the player must rely on their accrued knowledge to deduce the solution.
Changes in Direction from Initial Pitch
On Day 5 I approached having functional game systems. This allowed me to play around with unit interactions, and get a feel for the player experience. Getting to this stage allowed me to take stock of what I had created, and adjust my expectations for the outcome in scope and direction of the project.
One of my biggest disappointments was to not change directions sooner, allowing me more time to focus on features and functionality directly complimenting the core experience. I have doubts this could have been assessed prior to having the game in a functional state, although I believe by taking some more time earlier I could have eased the process.
One contributing factor to these difficulties is that of the brief time I put into designing the concept. The entire concept from start to finish was conceptualised in less than a day – in fact no actual programming or ‘game creating’ took place on Day 1, this was reserved for conceptualising and documenting the game.
Although this was ample time to come up with and flesh out a simple concept, this tight time-frame did not allow for much exploration of parallel or alternate ideas – which is what I would describe the final product in relation to the original design document (which is available to read here, for those interested).
Improvements to the Concept
The following is a very brief list of some additions to the game I would have liked to see, had I been given more time.
The introduction of autonomously pathing enemies.
This would have made the Speed and Range specifications far more valuable, as well as improved the usefulness of the Cannon’s ability to continue pathing even when being attacked. Complex puzzles to do with timing and movement could be created, adding variety without venturing from the existing mechanics.
The introduction of environmental obstacles that can either help or hinder the player.
Traps, or areas that damage units when entered could be used to restrict or add strategic weight to player unit movement, while also having the potential of being manipulated and used against the enemy.
The introduction of additional enemy units, with strange or extreme behaviours.
Much care needs to be taken when introducing new player units, but a variety of enemy units could be created that follow strange rules. These could have large strategic consequences for the player in levels they are placed within, creating additional variety and giving the player new scenarios to use the existing knowledge and understanding of the game.
