seven day project – day two

Day two down, and still close enough on schedule to claim I am.

Today has been all about developing units, and considering the focus of the game is on units and the interactions between them, that seems like a reasonable place to start.

We’ll take a look at how some of the systems I’ve been using to implement units, and I’ll offer some commentary on the decisions I’ve made.

 

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.

Between the Specification and Attachment systems, the hope is to allow enough variation and customisation as to allow players to specialise units for their own strategies, while retaining a enough familiarity and predictability to facilitate in the player’s understanding of the interactions taking place.

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