Patrols – Milestone 1

Time, as always, has been a limiting factor lately. Still I’ve been determined to work on something tangible. As such, the brief has been to create something that is both simple to develop (development time currently sits at around 20 hours) and would offer a decent amount of gameplay (unlike my other recent efforts). I’m attempting to achieve these goal by focusing on simple wave-based gameplay with challenging mechanics, and score based replayability.

And I’m calling it Patrols.


Doesn’t look confusing at all.

Continue reading ‘Patrols – Milestone 1’


Rollback: Hydra

Okay! Time to write a post so I can consider this wrapped up and move on to the next thing.

It’s been closer to a month than it has a week, but my recent game making efforts have borne fruit.

I present you Rollback: Hydra, or: a Proof-of-Concept and Exercise in Polish.

I spent the initial 10 days working on core mechanics, with the plan to release at that point. Arriving at day ten, I had a couple of solid mechanics and a few more half implemented ones.

The decision was made to take what I had completed, spend a little time polish it up, and release that. When working on side projects it isn’t often that I’m afforded the chance to polishing something (generally you have to create said something first), so I was looking forward to the combined challenge of attempting to go ‘pencils down’ on feature implementation, working within the small set of mechanics I had adequately completed, while also stretching those infrequently exercised polishing muscles.

Continue reading ‘Rollback: Hydra’


Rollback – Day 6

It’s been a few days. I last updated after having developed a simple city generator, designed to create a place for the enemy faction to propagate.

With the city in place, I have spent the last four days and 1600 lines of code working on developing systems for the faction. I find writing AI to be a difficult task. I have no trouble thinking logically about the interactions I want to occur, but the complexity always blows out, and with complexity comes bugs.

That said, I am relieved to say that the heavy lifting is done and my enemy AI is all but complete.

I have attached a work in progress build below. I suggest skimming the following post as it will frame your understanding of what is happening.

The goal from day one has been to allow a faction to grow organically within the city rather than be hand created.

In real life I am sure the complexities of operating an underground resistance movement are staggering. This creates a challenge, as I must distill this complexity into simple components – while retaining behaviour that is representative of reality. I have taken some liberties.

Continue reading ‘Rollback – Day 6’


Rollback – Day 1

Phew, I’m winding down day one on Rollback and already I’ve learned a valuable lesson – do not scope out and commit to creating a game while drunk.

Regardless, my vision of the game is a lot clearer today and I am happy with the progress made.

Rollback is one part detective work – the player must identify enemy infrastructure – and one part warfare – the player then must crush this infrastructure, that they have hopefully been observent enough to locate. This creates a unique design challenge in that the enemy needs a place to hide.

If I could point to any one thing that has driven me to work on this particular project, I would have to say that it is one small piece of news that came out of the recent Israel offensive on Gaza – that of the airstrike on a Hamas media centre, situated in an apartment building that also housed prominent foreign news outlets.

Despite the very real risk of high profile casualties, a human being made the call to strike that infrastructure. I want to position my player in that situation.

Reading the above news story from a game designer’s perspective, we deduce that:

  • Hamas integrates their infrastructure into the existing city, rather than build it from scratch.
  • Hamas does in fact operate communication and media outlets.
  • These outlets are worth striking, despite the very real consequence of civilian loss of life.

Taking that reading, it seems obvious that the place to start is the creation of a civilian city, one which the faction can assemble and obfuscate their material assets within.

Today’s labour has been focused entirely on this endeavour, and below I share with you the results.

Continue reading ‘Rollback – Day 1’


Rollback – Day 0

I’ve stumbled upon a week or so of free time. With that time I plan to develop and release a small game of questionable quality. Reference my previous attempt for an idea of what to expect. The game will be of prototype quality with limited art assets, and I will likely lose focus and disregard the ever important polish.

I’m excited to undertake this challenge again, and I’m interested to see the result – and how that reflects on the progress I have made as a designer, and coder in the last year and a half.

So, the game. This time it has a name. I’m calling it Rollback.

Anyone who has even met me knows two things. That I have a strong interest in strategy games, and an even stronger interest in geopolitics. It will come as no surprise then, that this game will be a strategy game, based loosely around the recent Israel/Gaza conflict.

Before I dive into an explanation of the game, allow me to offer my reading of those recent events.

In the three and a half years since Israel last undertook overt operations in the occupied Gaza territory, Hamas had rebuilt their infrastructure, and developed closer strategic alliances with other external parties, most notably, Iran. With the rebuilding of their tunnel network and these new closer ties, Hamas had been able to smuggle Iranian built Fajr 5 rockets into Gaza. Israel’s response was that of house cleaning – attacking Gaza in order to cripple this infrastructure, and destroy these newly acquired weapon caches, diminishing Hamas’ capabilities for at least another election cycle. Interestingly, international pressure forced Israel from undertaking a ground invasion – guaranteeing that they could not decisively meet these goals.

This is a simple, high level reading of the situation, and one I admit is likely flawed. Regardless it is the one I subscribe to, and one that I feel lends itself to some simple and contained mechanics that I will hopefully be able to tackle to completion within a week or so.
Continue reading ‘Rollback – Day 0’


seven day project – Post Mortem

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.

Download for Windows
Download for Mac

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.


seven day project – day 7

What a week it’s been. Some purists may try to tell you I missed my deadline to complete the project within 7 Days, but I hold firm that while I remain awake, it remains Sunday.
So given that I haven’t slept in 36 hours, I’m going to keep this brief.

The game, proof of concept, prototype or whatever you are determined to call it, is now ready for consumption.

You can download if for windows by clicking right here, or download it for mac by clicking over here instead.

Anyway, I’m starting to shake uncontrollably, so I’ll wrap this up with just a couple of points.

I’m pleased with my progress over the week, although there were a lot of issues I encountered that gave me trouble and a few things I would definitely try to approach differently.
The game that you will play differs in a lot of ways from the originally pitch – on day 5 it became fairly obvious that the requirements I had outlined weren’t entirely feasible given the timeframe (and some unexpected complications), so something had to change.
The game is simpler and more puzzle based than initially pitched, but I think it works quiet well and seems like a concept that with some more time and energy, could have legs. If one thing disappoints me it is that I didn’t evaluate my position and make this change in direction earlier. I could have given myself more time for content creation, and maybe an opportunity to explore a little more of the territory opened up by the new direction.

That’s all for now, but I’d love to hear thoughts from anyone who decides to click the link, and tomorrow I should have a post mortem together where I’ll detail what went right and what went wrong, and give some insight as to where I would like to take the concept, if I ever were to decide to expand on it.


seven day project – day five

Any progress made today has been hard won, but I guess that’s Friday for you. I feel like I’ve spent the day tinkering with existing code, it’s difficult to see what has improved since yesterday. Apart from some preliminary UI stuff and the introduction of zones into the gameplay mix (more on that below), I don’t know what actually has.
Looking at the list of things still to be done, I am falling behind – and I can’t find the time to update my documentation, which frustrates me. I have a few ideas to get me back on track, hopefully without sacrificing too much.
The procedural level/round generation system will be cut – but after having playing around with the units and really starting to get a feel for how things work, I’m certain it wont be missed. The game has a real puzzle vibe just below the surface, and I think with hand crafted scenarios it could really shine.
This apparent puzzle feel brings some new challenges, but we’ll discuss that another time. Some features are sure to undergo changes, and I’ll actively be looking for simpler and less time consuming alternatives.Anyway, enough doom and gloom. I’m going to keep this incredibly brief, but I can offer some simple explanation of a few of the gameplay concepts, as well as a screenshot or two of the game in action.

Play Area

Gameplay takes place on a 4:3 area (currently locked at 1024 x 768) known as the play area.
The play area is completely bare, with the exception of zones and player units and their range indicators.

Range Indicators

Although I enjoy the ambiguity and uncertainty resulting from displaying unit information to the player only through the visual design of the units, unit ranges will be displayed on the play area.
This decision was made based on the reactive nature of the unit interaction, and so much of that weighs on the order or units spotting each other. Due to the nature of the ‘commitment’ mechanic associated with attacking and being attacked, being able to see enemy range limits represents territorial borders in a way. By encroaching into this territory, the unit will be engaged, and depending on attachment type and the rules dictating it, may become committed to the skirmish unable to retreat.
If range indicators overlap at any point, the player’s indicators take precedence.
Units utilising the Stealth Attachment are granted a unique range indicator colour in order to more clearly identify their cloaking range (as visible in the image below).


Zones come in two varieties, deployment zones and capture zones.

Deployment Zones

Deployment zones are small zones that determine the position the player can spawn their units at the start of the round. Each zone allows one unit to be deployed, effectively allowing the level designer to place limitations on the size of the player’s force to ensure balance within the round. By limiting the player’s force to different sizes (and different positions), the designer can create varied and challenging scenarios, rather than having to achieve progression through simply throwing more and more powerful enemies at the player.

Capture Zones

The player’s goal is to have a unit placed on each capture zone simultaneously, and defeat all units on the playing field.
Placing a unit on a capture zone raises a red flag for the enemy – if the closest capture zone to an enemy unit is being captured, the unit will attempt to path directly there and defeat the unit attempting the capture.
The screenshot below shows a player unit on a capture zone (the green circle), and three enemy units en-route to destroy it.
And for your viewing pleasure, here’s an image of a unit sporting the improved Shield Attachment being harassed by an excessively powerful rocket launcher unit. The little dude looks a bit worried.

seven day project – day four

Hump day!
Today was spent nailing down combat rules and developing a balance between the different Unit Specifications and the different Unit Attachments.
The game isn’t playable yet in the sense that there are no goals and no way to achieve victory, but it can handle spawning units and having them interact and battle it out, which is actually pretty entertaining to see.

Specification Balance

The unit specification system works on the principle that all specification types are balanced and equal in value. When the player is given the opportunity to upgrade a specification, there should be no optimal choice – no one specification should be overpowered, and none should be useless. When the player spends currency to upgrade a unit specification, the decision should be driven by their strategic agenda for that unit.
To tackle this problem Unit Specifications are paired, and balanced to complement each other.
The Armour and Attachment Level specifications are paired – with Armour acting to make the unit more resilient to attack, and Attachment Level actively improving the effectiveness of the unit’s weapon.
Likewise, the Speed and Range specifications are paired – increased Range offers a unit the opportunity to get the slip on a target, with Speed working to limit that range advantage.
These relationships between the specifications compound the importance of each, and give some much needed relevance and a point of comparison.

Attachment Balance

After determining the relationship between specifications, balancing the attachment abilities was straightforward, although there were some balance issue inherent in the attachment ability design. Specifically the Shield Attachment, which required a major rethink.

Due to the nature of the shield attachments ability – blocking projectiles and attacks – the range specification was useless, armour played only a minor role, and the intended motivation for improving the attachment level was extremely weak. Seriously, it’s disgustingly sloppy design.
This had implications on balance in two ways. Firstly, the mitigating effects on the usefulness of the aforementioned specs knocked the Specification system off balance – a player could effectively ignore range and attachment level specifications, focusing those points elsewhere without feeling the corresponding trade offs – and secondly, much the same as Specifications, all Attachments share the same ‘cost’, meaning that their abilities need to be comparable for the attachments to remain balanced.

Shield Attachment Revisions

As appose to blocking all attacks, the Shield Attachment is now only effective against rockets, and is no longer guaranteed to deflect attacks with 100% proficiently. The shield’s effectiveness is determined by Attachment Level – the details of which are included in the chart below.
The unit is no longer limited to deflecting attacks from a specific unit or direction, and can now deflect rockets from any number of units. The (what would have been functionally useless) ability to shield additional units has been removed.

To balance this reduction in the unit’s primary ability – and to make use of the Range specification – the shield attachment is now capable of ‘cloaking’ friendly units within it’s range radius.
A cloaked unit will not be fired upon automatically, and can be attacked only after first engaging an enemy. These revisions make the unit far more strategic and supportive, effective use of the cloak ability can allow units with short ranged attacks to safely move within range of dangerous long range enemies.

The following table displays the scaling of attachment abilities as the Attachment Level specification is increased. For comparison, the Armour value for the corresponding armour specification level is also displayed. Below the table you’ll find a brief explanation of each attachment’s offensive ability.

Armour Points

Armour is analogous to health. As attacks are launched against a unit, armour points are deducted from the unit’s pool. The unit is destroyed when its armour points are depleted. The damage values on the above chart are equal one-to-one with armour points.

Rocket Launcher

The Rocket Launcher attachment is capable of firing rapid rocket volleys as the attachment level is improved. Each rocket has a payload of 1 damage, and as such, the values on the chart can also be read as damage per second.

Machine Gun

The Machine Gun attachment maintains it’s rate of fire, but increases it’s damage output as the attachment level is increased.


The Zapper Attachment deals a flat 1 damage per second. The Zapper is able to engage multiple enemies simultaneously, sharing this damage evenly between each.
The figures for the Zapper detail the total percentage of the damage available to be spread between all targets. For example, at level 8 (400%), if the Zapper were to engage four enemies simultaneously, it could deal the full 1 damage per second to each.
The Zapper is never able to deal more than 100% damage (1 damage per second) to a single target.


The shield attachment is capable of deflecting a number of rockets each second. An advanced rocket enemy is able to engage and overwhelm a low level shield unit, dealing damage to the unit with any rockets the shield is unable to deflect. Likewise, a shielded unit can be overwhelmed by multiple rocket enemies engaging it simultaneously.

Examining the Chart

Examining the chart reveals the relationship between Armour and Attachment levels.
Armour and damage values scale linearly, allowing armour and attachment levels to effectively cancel each other out.
For example, a unit with a level 2 rocket launcher attachment will take the same amount of time to destroy a unit with level 2 armour as a unit with a level 6 rocket launcher will take to destroy a unit with level 6 armour.

The chart also allows us to examine the relationships between different attachment types.

  • A rocket launcher unit can destroy two machine gun units of the same level.
  • A shield unit is capable of deflecting rockets from two rocket units of the same level.

Pairing this information with other rules and abilities (for example, we know that a machine gun unit is capable of easily destroying a shield unit) reveals a scissor/paper/rock relationship between the attachments, help to build a strong profile of each attachment that will resonate with the player.
The player is able to grasp the strategic functions of different attachment types, and with the unit specification system, is empowered to capitalise on these functions.

The information displayed in the above chart is only one aspect to the balance and function of attachments. Speed and Range specifications are free to be modified to handicap and further  improve balance, and unique abilities offering strategic advantages – like the Zapper’s ability to attack multiple enemies at once – also play a major role in defining each attachment’s strengths and weaknesses.

We’ll pick up from here tomorrow, taking a look at how these special abilities and strategic functions come into play during gameplay.


seven day project – day three

Day three, otherwise known as Wednesday, or the day I fall hideously off schedule, is complete.
I certainly have some work ahead of me if I wish to have this project finished by Monday, and sleep deprivation is beginning to take its toll. I’m weak, I know.Today I have focused on completing the code for unit generation, and have written the code for generating art for Unit Attachments utilising a system similar to that used to change unit component dimensions in relation to a unit’s specifications.

Unit Attachments

To recap, a Unit Attachment is basically the weapon attached to the unit. The attachment defines the abilities of the unit (allowing the unit to attack with, for example, rockets or machine gun fire), as well as specifies a number of rules which the unit must respect.
Attachments play a major role determining the way units interact with each other. The number of different attachment types has been limited to four, ensuring the player can easily learn the function of each attachment, retain this knowledge, and be able to use this information during gameplay to determine and predict how units will interact.
The following is a breakdown of each attachment, with an image displaying a typical unit with attachment.
The units shown have values of 3 for the speed, armour and range Unit Specifications. For those just joining us, Unit Specifications were discussed in yesterday’s post.

Rocket Launcher

The rocket launcher attachment allows a unit to fire volleys of rockets at an enemy. The rocket launcher is the most powerful weapon attachment available and allows the unit to deal heavy damage to a target.
Despite being the strongest direct attack, units with the rocket launcher attachment are prone to becoming “committed” to a target. If a unit with a rocket launcher engages an enemy, the unit becomes unable to take additional commands or resume pathing until either itself, or the enemy is destroyed. This has strategic implications and players must be careful how they deploy their rocket launcher units, or risk having them become unwillingly committed to a target, unable to pursue other goals.
While a rocket launcher unit is committed to a target it will remain stationary and unable to attack another target, making it extremely vulnerable.
A rocket launcher unit will automatically engage enemies within range, and will automatically counter-attack an enemy (moving within range, if required).
Increasing the unit types attachment level improves the rocket launcher’s rate of fire.

Machine Gun

The machine gun attachment is less powerful than the rocket launcher attachment, but has the advantage of allowing the unit the freedom to continue pathing while attacking. If a machine gun unit were to, for example, attack a unit with a rocket launcher attachment, it would retain it’s ability to move – allowing strategic options such as forcing the committed rocket launcher unit to path within range of additional powerful units (by attempting to remain within attack range of the machine gun unit).
As the attachment level of the unit is increased, the machine gun attachment deals a higher level of damage.


Don’t let the uncreative title fool you – the Zapper attachment is a versatile and useful unit attachment.
The zapper is the only attachment capable of attacking multiple enemies simultaneously. While an enemy is within range, the zapper will target it with a sustained attack inflicting damage over time. If additional enemies enter the units range, the zapper will also engage those, spreading it’s damage load evenly between the targets.
The zapper attachment excels at defensive roles, and can be used by a player to engage and commit multiple enemies. When the zapper engages enemies, it is also committed, unable to path.
By improving the unit’s attachment level, the zapper is able to direct a higher percentage of the original damage amount to each targeted unit, making it a fearsome weapon.


The shield attachment is a defensive attachment, serving to deflect attacks launched against the unit. When a unit with the shield attachment is engaged, the unit becomes committed to deflecting fire from the attacking unit. The unit deploys a shield, blocking projectiles and attacks from the attacking unit’s direction. If the unit is attacked from a direction it is not shielding it will receive damage as per usual. Shield units are great for soaking enemy damage and committing dangerous enemies.

By upgrading the unit’s attachment level, the shield is projected further from the unit and wider, deflecting weapon fire from a wider range.

As each attachment has it’s own sets of rules, units with different attachments can be used to handle a situation in various ways, allowing the player to experiment with and develop their own strategies. Coupled with the Unit Specification system, the player (and enemy formations) will have freedom in creating and deploying units with varied abilities, while maintaining a core understanding of the rules dictating unit interaction.

Unit Demonstration Application

The following link will download a vary simple application that I have been using to develop and test the unit visual design system. The application will allow you to adjust a unit’s specifications and view the affect they have on the unit’s visual profile.

Download UnitDemonstrationWIN for windows – Unzip the files and run the executable.
Download UnitDemonstrationMAC for OSX – Unzip and run the file.

Playing on Playstation 3

Red Dead Revolver - I paid about $1000 for my launch model PS3, so I guess it's time I get some use out of that emotion chip crammed inside. I remember Red Dead Revolver looking rather good when it was released, and despite the low resolution and odd blurring (that I attribute to playing on a HD set) the game holds up well. It looks good despite these graphical limitations because the art direction is so precise and awesome. And it isn't just the art direction, the music, dialogue and set design (for some reason, set seems a more fitting word than level) all work in tandem to recreate an iconic Wild West atmosphere. Red Dead Revolver doesn’t aim to recreate life in the Wild West, it allows our imagination to take over and populates the locale with legendary men and their legendary stories.

Playing on iPhone

edge - Well I never thought I'd consider playing a game on iPhone as actually gaming, but edge has turned me around. The game is built for the iPhone. Sure, it could be ported, but the elegance of what has been created is astounding, it boggles the mind and makes me wonder what amazing gems we'd receive if current gen consoles weren't clones of eachother.

Playing on PC

Sins of a Solar Empire, Demigod, Generals - Zero Hour - It may be a temporary effect as I slowly reintroduce the PC into my gaming diet, but it seems every title I’m excited to play on the platform is either a strategy game, or a cheap indie game. PC gaming isn’t dead, it’s just restricted to titles that require complex input or a pointing device, and games that couldn't be developed or distributed on other platforms. I guess that’s part of the reason the AppStore is so far a success, there were a lot of indie devs stuck on PC for lack of a better alternative.


August 2020