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.

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.

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

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.

Zapper

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.

Shield

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.

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

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).

Zapper

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.

Shield

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.

Unit Specifications

Unit Specifications is a term coined that refers to the statistics of a unit, roughly analogous to an RPG character’s stats. Within this project (I really should give this thing a title), all units are built from the same DNA. There are no tanks, no jeeps, no motorcycles – but simply units of different spec, each with their own strengths and weaknesses, derived from the combination of specifications that define them.

This system allows a player to develop their own ‘unit types’, and gear them specifically for any strategy they would like to explore. Want a fast unit capable of rushing in and damaging enemies with a powerful short range attack – or would you prefer a slow moving unit with heavy armour, ready to soak up enemy damage? The player is free to experiment and come up with combinations that work for them.

Unit Specifications are used in this same way to populate enemy forces, and I’m looking forward to implementing this in the next few days.

 

Unit Attachments

Unit Attachments play a large role in determining how a unit behaves and reacts to other units, and what actions it is capable of executing. Simply put, a unit’s ‘attachment’ is the unit’s weapon.
Each attachment has certain ‘rules’ associated with it, for example, a rocket launcher attachment will have the unit automatically attack a enemy unit within range, as well as automatically move into range and counter-attack a unit firing upon it. A unit with a rocket launcher attachment must be stationary before attacking.
As such, selecting different attachments is more than just selecting different sized guns – attachments determine how a unit will behave in a situation.
The Unit Attachment system is also utilised by enemy units.

 

Unit Visual Design

Now, it’s all well and good to suggest that the player create a faster unit, or a more heavily armoured unit than that of the enemy – but without a language to convey the strength or weaknesses of enemy units, it’s an impossible task.
The Visual Design for units uses a procedural process, taking advantage of the fact that all units are based on the same initial structure, and the inherently programmatic nature of unit specifications.
The design of a given unit consists of a number of components, the dimensions of each related directly to various unit specs. The player is able to determine roughly, a unit’s specifications based on the unit’s appearance alone.
The following diagram (which is about 16 hours out of date) depicts a typical unit. The unit is displayed side and front on, and each component has been labelled.

The standard unit structure somewhat resembles that of a tank.

The following diagram contains the same depiction of a unit, this time with the addition of labelled outlining the relation between component dimensions, and a unit’s various specifications.

To demonstrate some of the variation possible, the following are images of a number of example unit types (displayed without attachments). Listed next to each is a breakdown of the unit’s specifications.

(It’s a quarter past four in the morning and wordpress doesn’t want the following table centred. WordPress wins this round)

	Speed: 3 Armour: 3 Range: 3
	Speed: 6 Armour: 2 Range: 1
	Speed: 2 Armour: 5 Range: 2
	Speed: 3 Armour: 2 Range: 4

The values assigned to specifications for each of the above units add up to nine, which is the base value I’m currently working with. As the player progresses and is given the opportunity to further develop their unit types, variation between unit appearances will greater increase.

To summarise, there are three pillars driving the design behind the units.

• Unit Specs – determining unit strengths and weaknesses.
• Unit Attachments – determining unit behaviour.
• Unit Visual Design – communicating this to the player.

Feel free to browse my design document for more structured coverage of unit specifications and attachments.

There is no right way to reach this lofty goal, and each developer aspires to their own ideal on how this should be achieved. There are numerous hurdles to overcome, some of which will require a dramatic rethink of the core mechanics we take for granted.

We’re in the midst of a video game arms race as developers push forward to realise this vision.

One issue at the forefront of my mind that must be overcome is crafting and reinforcing meaningful relationships between the player and in-game characters.

Grand Theft Auto 4 introduces each character and we follow their interaction with Niko. Some of these relationships last forever, some end at point blank range. My point is, there isn’t a single throwaway character in the game. As for the ones that appear to be, well we’re simply seeing the bookend of their story. It’s obvious Rockstar have gone to effort to really introduce each character as a meaningful addition and allot the player the greatest opportunity to connect, no matter how brief a role the character may play. From a narrative standpoint Rockstar have achieved their goal, but believable characters alone are not enough to create a meaningful connection with the player.

So how do we create a meaningful connection between two people? Well, the best place to start looking for clues is our own world.

 In our daily lives, we surround ourselves with the people we care about, because the people we care about add something to our lives. But what exactly do they add? Friendship, company, love? What are these things and how do we define them; how do you translate love into 0s and 1s?

Follow along as I define some things I know about relationships.

• When you meet someone you begin a relationship.
• The more you interact with that person, the greater impact they have on your life.
• When you lose someone you care about, you feel loss.

Now obviously this is an incredible simplification. There are plenty of wildcards – sometimes that girl at the store counter you shared a brief conversation with manages to stick in your mind for days – and it will take a lot more than three assumptions to paint an accurate picture of the mechanics of relationships.

But hey, it’s a start.

Lets look at how we can implement emotion in our game, by attempting to emulate this ruleset in a purely logically way.

• By spending time with an entity, the player builds a relationship.
• A relationship acts as a stat buff/debuf to the player, and as the relationship grows so does the stat effect.
• The influenced stats are determined by the type of relationship (friendship, love etc).

By implementing stat effects, the player is given incentive to create and maintain positive relationships. It is up to the player to decide which relationships to pursue and how far, and the player is also free to direct the relationship (should they remain just friends, or become more intimate?), therefore direct the stat effects tied to the relationship.

Our player is given the motivation and freedom to invest time with the characters of their choice.

If the player puts the time and effort into cultivating a strong relationship and the relationship disintegrates, the player will feel genuine, personal loss as the stat boost disappears.

Looking at the flip side, a character who may become the enemy of the player will reduce the player’s stats in a relevant way, giving the player their own motivation to take care of the problem, rather than require the game designer to script the event or fabricate a motive.

By integrating the mechanic deeper, networks of relationships can be created. For example, my friend is my enemy’s acquaintance. Having this enemy is a bane on my stats, and having this friend is a boost to certain stats. By eliminating the enemy I’ll eliminate the stat debuf, but I’ll also upset my friend – damaging our relationship and reducing the effect of that stat boost.

I’ll take a moment to note that the explicate value of each stat boost should remain vague. The player must be aware of the effect, but it is important that (just like real life) no tangible value can be placed on these ‘emotional’ boosts. When making the decision to act, the player need not know the exact outcome (ie; gain 15 from eliminating the enemy, but lose 10 by upsetting the friend), there must be a grey area and the player must make the decision for themself. 

I’m not suggesting that this is the right or only way to motivate the player to interact with the world’s characters, but the added weight of stat boosts does create a strong motive that works within traditional game design theory,  is a feature easily understood by players, and giving the designer additional leverage over the player that can be used to increase the significance of narrative events.

The obvious risk is that the opportunity for the player to greatly affect their own stats will overpower other areas of the game design and will place greater focus on the relationship mechanic than initially envisioned.

But in our world, you can’t get by without a little help from your friends – should our protagonists’ have it any different?

I have an unwarranted fondness for digital distribution, allow me to summarise.

I like to own things, and having disks and shit is nice – but having a hard drive packed with games is nicer – I prefer to navigate the XMB rather than the living room.

So how do I react when potentially given the opportunity to forgo a physical console? Sceptical, and a little scared.

I’m referring of course to OnLive, which might as well be called the future. This is cloud gaming  - no need for a console or gaming PC in front of you, simply log on to OnLive and their machines do all the work, and stream the audio/visual to you. Xbox, PS3, Mac, PC – doesn’t matter. Pick a game from whatever platform and play it on your low spec PC or television.

It sounds good if not a little fanciful, but I’ll reserve my judgement until I see it in action and see what they expect to charge for the service.

Now for news that inspired this post’s title, I’m happy to say some of my dreams came true this morning.

It’s not official yet, but the original Call of Duty is coming to PSN and Xbox Live. Nostalgia ahoy, I’d had some amazing time with that game and I can’t wait for the excuse to jump back into some multiplayer action.

I’ll admit I am a little concerned how the game will fare without a keyboard and mouse, and considering the scoped Mosin Nagant was my weapon of choice and I rolled with the handle Vasily Zaitsev, I may have trouble returning to my prior awesomeness – sniping with an analogue stick is a skill I’m yet to master.

Resident Evil began as a B Grade type horror story, and although the dialog has been smartened up a little, subsequent releases have still retained the simplism and slight absurdity the original title built it’s narrative around.

It’s a hallmark of the series, and it’s good to see it hasn’t been lost in the 5^th instalment.

Don’t get me wrong, I’m not giving the game cookies for it’s basic storyline – it’s just incredible to see what happens when you make a triple A title and put gameplay above storytelling. Yes, Video Games can challenge books and movies as far as crafting a mature, thoughtful, immersive story; Resident Evil 5 just shows you don’t have to – you can have massive boss fights and crazy locations instead.

Don’t pay too much attention to the storyline’s details, it just hurts your head. Instead, take a drink every time you see something Capcom have hand altered to remove any ammunition racists (you know, those ones who hate whites, wont get off our back about it and almost come off as colour envious) might have over the game.

I don’t know why Chris looks so worried, having white skin is your ticket to survival in RE5. No black character would dare to attack a while character – every time someone white gets attacked or dragged off it’s a white or random Hispanic dude that is the aggressor.

But you do have to giggle at one of Shiva’s early dialog lines, as she explains to Chris she’s accompanying him just to appease the Africans. Personally I would have removed that one, and because I don’t have a segue lets talk about Wesker. 

I guess Wesker’s steroids don’t shrink his balls, but his brain.

I should have killed you years ago Chris! He yells out as the finale begins to play out.

Yeah Wesker, years ago.. or last chapter where you had us owned but decided to just run off instead.

I could poke holes in Resident Evil 5’s story for a thousand more words, but I think I should stop now. Stop now, and begin explaining why despite it’s absolute disregard for storytelling, Resident Evil 5 may find it’s way into my top 5 games list.

RE5 offers the definitive co-operative experience. Sure, Dead Space 2 will attempt to topple it, and with hindsight and a couple of years over RE5 it should succeed, but until then I have hopes RE5 will be the go to game. What makes it so great? Well obviously Capcom’s risky decision to include co-op from the ground up plays a big part. I say risky, not because adding co-op is a risk per se, but limiting their access to many of the series fundamentals (scripted scares, feelings of isolation etc) is a big call. This decision was spring cleaning in a way, anything that doesn’t work with co-op is out, ready to be replaced with something that does. What we are left with is more simulation than game – the simulation of surviving this fucking bizarre scenario.

When you’re playing with a friend sitting beside you, the game’s narrative dissolves. What is left is two friends trading ammo and items, looking for the smartest way out and the most efficient way to survive. The weapons you have determine your situational strengths and weaknesses – instead of feeling like two players in a single player game, you’re both given a role, and a chance to shine. I guess there is a lot to be said for ineqality between co-operative players.