Backup Spore Save Games

Since Spore save games seems to be driving traffic to this blog, you may find the following code useful to help you back up your existing Spore save game in Windows.

Copy and paste the following code into a file sporebackup.bat:

mkdir "%userprofile%\Spore Backups"
xcopy /e /y /i /r /h "%appdata%\spore\games\*.*" "%userprofile%\Spore Backups"

Then, when you double-click on the sporebackup.bat file, this will automatically backup your spore files to a Spore Backups directory in your user directory (one up from either My Documents or Documents). You may find this useful to schedule in Task Scheduler on your machine.

If Windows had a decent scheduling engine, or for that matter, an easy way to script actions on files being updated, I'd write something to do this automatically whenever you save your game.

This technique is relatively common to another game genre, roguelikes. You may find checking out the rest of this blog helps you understand the genre a little better.

The Berlin Interpretation

It sounds like the study of Roguelikes is getting academic. Jeff Lait announced on the newsgroup rec.games.roguelike.development:

This definition of "Roguelike" was created at the International Roguelike Development Conference 2008 and is the product of a discussion between all who attended. The definition at http://www.roguetemple.com/roguelike-definition/ was used as the starting point for the discussions. Most factors are newly phrased, new factors have been added, some factors have been removed.

You can join the discussion here. I believe a splinter group is working on a definition of Roguelike-likes called the Canberra Consensus.

Designing a Magic System - Part Eleven (Re: Choices)

(You'll probably want to read parts one, two, three, four, five, six, seven, eight, nine and ten before starting this).

So with the principles I've discussed in the first ten parts of this article, by combining elements with shapes to create unique array of attacks, and increasing damage balanced by using the exponential curve, was I able to resolve the design problems of Angband and create a compelling magic system for UnAngband?

I don't believe I've achieved this. Because not every spell effect is amenable to the same type of analysis that you can do with attacks. Take the example of Phase Door. Phase door teleports the player a short distance (10 grid squares on average), allowing the player to get distance between him and enemies attempting to reach melee range. But increasing the range doesn't make the spell more useful - because Phase Door has two distinct uses.

The first is escaping: and increasing the distance travelled by Phase Door usually benefits the player. The benefit is not guaranteed - you could potentially teleport into an unexplored section of the dungeon filled with monsters more dangerous that you currently face, but in general greater distance is better.

But the second function of Phase Door is tactical: to continue allowing you to use ranged attacks against nearby enemies without risking their more powerful melee attacks. In this circumstance, the limited range is ideal - tailored to the Angband 'average room size'. Increasing the range diminishes the likelihood of staying within ranged attack distance of the enemies, and so increasing the 'damage' of Phase Door (the range you are teleported) is of limited benefit.

So it seems that it is not possible to provide more choice for Phase Door alternatives: the spell is as useful as it possibly can be, and any spell which attempts to supplant Phase Door must offer the same two functions, or do one of them significantly better. If this is the case, e.g. Phase Door alternate A and Phase Door alternate B, the first which escapes better, and the second which provides a better tactical alternative, can both be learned, superseding Phase Door completely.

The same problem occurs with being able to learn multiple attack spells: we're just able to dodge the bullet by providing more elemental types and shapes, so that all the attack spells of the same tier are useful in some set of circumstances.

So what functions does a mage need in Angband? The following spells are available in the Angband mage's first spell book:

Detect Monsters
Light Area
Magic Missile
Phase Door
Cure Light Wounds
Find Hidden Traps/Doors
Stinking Cloud
Confuse Monster

Detect Monsters detects all monsters, with the exception of invisible ones and is critically useful for the starting mage. Light Area allows the mage to light up rooms and engage monsters at range. Cure Light Wounds provides low level healing, Find Hidden Traps and Doors helps protect the mage from traps, which can be deadly to them at low levels. Stinking Cloud is the second tier of attack spells that the mage gets access to.

I can suggest alternatives for each of these spells, but making the alternatives equally available renders the designs less distinct. Take Detect Monsters. Because it is not universal detection - it has one distinct drawback, I could equally propose a number of monster detection spells, each of which detects all but a class of monsters - living monsters but not undead, intelligent monsters but not mindless ones, spell using monsters but not warriors and so on. Unfortunately, by providing these alternatives to the starting mage, the drawbacks are mitigated. By learning two spells, the mage can cover the detection holes of a single spell, and so on - unless they are fighting an invisible, undead, mindless, spell caster of course. This means I am forced to make universal monster detection for the mage available immediately - even if it is my intention to force the mage to proceed cautiously due to the detection holes I've designed in.

I've picked this example deliberately, because there is a way of overcoming this problem, one that Sangband adopts (and from which I shamelessly borrowed the alternate detection magics). There is no design problem if there is a separate decision for the magic user, that allows them to only learn only one of the detection spells. If this is the case: say the mage is limited to one detection type, two first tier attack spells, one Phase Door alternative and so on, I can be as creative as I want to be with the spell designs, while being assured that the overall progression of spell acquisition will leave the mage with the appropriate weaknesses I want designed into each spell.

So what does this decision look like?

Well, I'm embarrassed to say, it looks a lot choosing a player class.

I could choose to explicitly force the player to choose for each category. 'What monsters do you detect?' when choosing the detection spell, and so on. However, this feels like exposing too much of the bones of the design, without achieving the consistent suspension of disbelief that I wanted in part one. So instead, I design a thematically consistent set of spells, wrap them up in a catchy moniker, and ensure that the design requirements are fulfilled for each set of spells I allow the player to choose from. And I don't have a good word for this other than a class (I call it a school, but this is a class by another name).

Using classes to delimit choice about magical spells is the best reason I can see for supporting a class design over a skill design system (or the classless, skill-less design I had previously advocated). Even Sangband (A contraction of Skills Angband) does this - surely an indication that the class based approach is necessary for providing alternative magic choices. Remember, I am talking about providing a framework for enabling interesting spell choices, and I am open to suggestions for alternatives. Angband's spell books are too easily swapped in and out- and to provide at the alternatives at the start of play means that they could all be purchased early; the process of learning spells needs to be made both more flexible and strict to be interesting (perhaps allowing less spells to be learnt, while allowing them to be flexibly forgotten, with some drawback to prevent instant re-specing); and I've worked through spell pre-requisites and exclusions enough to not believe that a talent tree approach has the flexibility to incorporate all the different magical effects I want to include. Are there other mechanics out there that I could take advantage of?

I'll talk in more detail about the UnAngband spell classes in part twelve. [Edit: Now more probably part thirteen - I digress slightly in the next part].

Poll results for 'Which Spore phase did you find the most fun?'; new poll

I was a little surprised by the result - thanks to the 39 of you who voted. Suggestions for Spore: The Roguelike are welcome...

Cell / Tidepool	7 (17%)
Creature	5 (12%)
Tribes	2 (5%)
Civilisation	1 (2%)
Space	4 (10%)
Creature Creator	4 (10%)
Pre-release hype	6 (15%)
Post-release bitching	4 (10%)
Unwrapping the box	2 (5%)
Spore?	9 (23%)
Waiting for the roguelike	20 (51%)

Next up: I'm being lazy, and I'm the top Google result for 'Spore save games'; so I'm sticking with the theme a little longer...

LittleSporePlanet

I think it is fair to say that those of us disappointed in Spore were expecting the procedural equivalent of this. I guess a fully user customisable physics engine will be an adequate replacement...

Refactoring

My apologies if this blog has been a little bit quiet as of late. I'm in the process of refactoring a large amount of code: in fact, I'm in the middle of one of those big ugly patches that are impossible to land unless you are the only developer working on a particular branch. Luckily for me, this is the Unangband trunk.

I've got a mixed view of refactoring: I don't normally do it, unless I can transform code into data. In this particular instance, I'm part way through moving information about all the monster and spell blows out into an external file, which to date I have been calling blows.txt, but which I am likely to rename methods.txt (to avoid confusion with the individual monster and spell blow structures). This file is the UnAngband library of shapes that I was talking about in part ten of the Designing a Magic System series of articles, and which I will expand on more in the Unangband Edit Files series of articles.

UnAngband over time has grown into a large loosely held together patchwork of code, which has a solid core, but plenty of exceptions. The solid core, for the most part, is held together by the edit files, and the logic to implement these edit files, and the exceptions grow in the code and periodically get shorn into the edit files, usually by adding a flag to note the particular exception.

I think there's light at the end of the tunnel for this development work, but its going to take me a bit longer to finish than I expected.

Interview with Jeff Lait

Temple of the Roguelike has put up an interview with Jeff Lait, author of POWDER and several well thought out 7 Day Roguelikes. My favourite comment:

S: What do you like about the genre, why did you become a roguedev?
J: I like the replayability. The fact it is about little vignettes - difficult situations that you escape by the skin of your teeth. My playstyle thus tends to focus to creating those exciting moments rather than long term survivability.

which is an inspired observation about the roguelike genre, and to a lesser extent what procedurally generated games in general should strive for. Have a read.

Designing a Magic System - Part Ten (Introduction to Angband)

(You'll probably want to read parts one, two, three, four, five, six, seven, eight and nine before starting this).

Angband and variants are primarily risk management games: and the vast majority of risk minimisation strategies resolve around management of the inventory. The Angband inventory consists of 23 slots, plus 10 equipment slots for items that are worn or otherwise wielded. Each slot can have up to 99 items of a particular type – the equipment only 1. Examples of types include rings of Slow Digestion, amulets of Adornment and potions of Water. (There is a more complex stacking algorithm to allow e.g. amulets of Adornment which have been given different store discounts to stack together, for instance).

This makes no sense from a realism point of view: it is possible to carry 99 potions of water in a slot, but 1 potion and one ring takes up two separate slots. However, from a game balance point of view it makes perfect sense. If you use the analogy of item types being equivalent to functions, or in this instance magical abilities, the Angband player can carry up to 23 different types of abilities to help them in the dungeon. (Actually 22 – the 23rd slot is for handling the inventory overflowing).

There are a number of mandatory abilities: food to prevent the player from starving to death, and light, to allow the player to see in unlit rooms and corridors being the two most essential. Other optional abilities are equally useful: ways to recover hit points (heals), reset status effects (cures), remove enemies from the immediate vicinity (teleport away, banish, destruction) or move the player away from the enemies (teleport, teleport level). These are essential because of the random nature of level design and placement and power of monsters in the dungeon it is easy to end up in a situation where the player can be killed in one turn: even on the first turn entering a new dungeon level.

The slot is the primary unit of magic ability use, and slots are easily interchangeable when new more useful equipment is found, allowing the player to re-spec their character at any point in the game. The exception to this rule is for spell casting characters.

For spell casters, one slot can be used to hold one book. A book contains a number of spells and there are nine different spell books, the first four purchasable in the shops, the remainder found in increasing depth and rarity in the dungeon.

This spellbook design means that a spell caster gets access to far more abilities than a typical Angband character. To restrict this so that the game is as challenging for spell casters, they are limited in a number of ways – they can only choose to learn a limited number of new spells from any spell book they find per level gained (usually one or two per level), they rely on a central pool of mana from which casting spells costs mana, and which only slowly regenerates, and spell books weigh a lot more than most items which grant abilities. (The total weight that any player can carry is also limited).

Angband spell casters have a number of problems that I wanted to address in Unangband. Firstly, and most paradoxically, the damage output for spell casters is too low, which means they end up relying on other attacks than their spell books, and spells primarily to provide heals, teleports, cures and so on. Secondly, the mana stat is too inflexible a restriction, particularly at low levels – once a character runs out of mana, they have to run away and rest (until they find rare and powerful mana granting items deep in the dungeon). And finally, every spell caster can learn all the spells they have available to them – there is no opportunity for specialisation at the cost of available spells.

The answer, it seemed to me, was to add more spells – by adding new spell books, and by adding new spells to existing spell books. I could add various mana recovery spells to spell casters – allowing them to sacrifice time, an important commodity in a game where every action could spell the difference between life and death, in return for flexibility. I could add additional and useful attack spells, particularly at a high level, to increase the overall damage output. And in order to get these spells, the trade off would be which spell books would the player carry – remembering that they had to choose to which spell to learn, so that spells learnt in books they weren’t carrying at the moment were wasted.

In true UnAngband fashion, I designed ‘a few’ additional spell books: 17 for mages, and 6 for priests, and filled them with spells – books of Fire Magic had fire spells, Acid Magic the same spells but with elemental flavours and so on – between 200 and 300 new spells approximately, on top of the 100 or so spells Angband has. I added the additional spells back into the standard 9 books, so it was possible to learn a spell in one book and find a copy of that spell in another. I include spells that had no casting cost and regenerated mana for the caster, perhaps at the cost of some hit points. And I developed new spells and modified existing spells to have higher damage output and utility. (This describes an early iteration of the UnAngband magic system: there are now over 600 spells, 60 mage spell books and a planned 58 priest spell books).

The attack spells that the player can learn at first level, which all have a mana cost of two, are shown below:

First Tier Spells
Spell Name	Damage	Element	Shape
Magic Missile	3d4+(1d4)/5 levels	Mana (unresistable)	Bolt (unlimited range; affects one target; cannot skip over intermediate monsters)
Lightning Spark	3d5+(1d5)/5 levels	Electricity (resisted by skeletons, which are also hard to kill with sharp weapons)	Hands (range 3; affects all targets in a line from caster to max range)
Light Area	1 damage/level	‘Weak’ light (only damages targets hurt by light, status effect of short term blindness)	Area (affects all targets adjacent to caster; radius gets 1 larger every 10 levels without damage dissipating at further ranges)
Torch	2d6+(1d6)/4 levels	Fire (resisted by fire monsters, which are dangerous at range)	Minor bolt (range 6; affects 1 target; cannot skip over intermediate targets)
Acid Splash	4d6+(1d6)/4 levels	Acid (partially resisted by armoured monsters, which are hard to kill with archery)	Minor aura (affects all adjacent monsters only)
Chill	3d5+(1d5)/4 levels	Cold (resisted by cold monsters, which damage useful equipment if you get too close)	Strike (unlimited range; affects one target; can skip over intermediate monsters)
Sting	2d6+(1d6)/4 levels	Poison (commonly resisted, monsters which don’t resist take the same damage again delivered over time)	Touch (affect one adjacent monster)
Mind Thrust	3d5+(1d5)/5 levels	Mental (mindless monsters are immune, which are common starting out but less common deeper in the dungeon)	Aim (unlimited range; affects one target; can skip over intermediate monsters and only requires line of sight, not line of fire)

This is not an exhaustive list of first tier attacks – just a representative selection.

The average damage for each of the above spells for the first 10 levels is shown below using a pseudo average, which assumes the damage increases with each level as opposed to the actual stepwise damage progression to emphasise the relative line slopes. Note that the shape determines the maximum damage output – sting for instance does effectively double damage over time, lightning spark can do up to triple damage as it affects up to 3 targets and acid splash potentially up to eight times the listed damage if the spell caster is completely surrounded. Light Area, which only affects monsters vulnerable to light, has the steepest slope as well as the maximum potential damage output at 50 level, where it has a radius of 6 grids, with 50 damage per grid. (These graphs have damage on the vertical and caster level on the horizontal. Click for a larger view).


Implicit in this idea of progressing tiers of attacks is an exponential damage curve. All attack spells in Angband gain damage as the caster increases by level: usually spell damage is determined as a multiple of player level. But the average slope of this linear relationship should increase from tier to tier, resulting in an approximation of an exponential growth in damage output on a round by round basis as the player gained levels and learns new spells, as shown below:


The cost for each tier is reflected in increased mana cost and chance of failing to cast the spell.

More to come in part eleven.

Designing a Magic System - Part Nine (Shapes and Behaviours)

(You'll probably want to read parts one, two, three, four, five, six, seven and eight before starting this).

If we are limited in the number of status effects and elements based on user interface considerations, how many different ways are there of defining damage shapes and behaviours? (By shape, I mean the volume damaged by an attack, and by behaviour I mean how this volume changes over time).

It turns out part of the answer depends on your point of view.

In a first person game, you are limited to shapes that are unique from your point of view: and damage effects that are closer to you obscure the shape of damage further away from you. In particular, a line projected from your perspective can appear the same as a number of conic shapes - which is why it is hard to judge the area covered by the flame from a Pyro's flamethrower. So for FPS games, the behaviour of a damaging attack is much more import than its shape, because attack shapes are difficult to convey.

In first person shooters, there are 4 different types of common weapon behaviours: hitscan weapons, projectiles, physics weapons and placements.

Hitscan weapons are weapons that when fired, immediately hit whatever the weapon is aimed at. They are called hitscan, because they trace, or scan, a line from the weapon to determine what is hit, and immediately apply the damage (latency considerations in multi-player games aside).

Projectiles instead model the movement of one or more projectiles leaving the gun and travelling ballistically in the direction aimed. The projectile has a defined velocity, so that it takes game time to travel to the target. Bullet drop may or may not be modelled with a projectile. Physics weapons extend the projectile concept to include more variables modelled, such as grenade bounce, penetration, particle effects and ricochets - usually using the in game physics engine. Physics weapons may have defined conditions under which they explode.

Placements are thrown or placed weapons which are detonated later: either using a remote control, trigger or proximity sensor of some kind. Finally, all of the above weapon types may model splash damage, where damage has an area effect that drops off with range from the impact point.

This is not an exhaustive list: remote control drones, target seeking weapons, and combinations of the above are all possible - but it is important to notes that the weapon behaviour is the primary determinate of how most first person weapons work, and that the shape of the projectile, hitscan and so on usually limited to a single point, perhaps including a random or predictable deviation from the intended target to mimic weapon recoil, or splash damage.

However, when you have a perspective removed from the players point of view, such as an overhead or side on perspective, you can vary the attack shape to a much greater degree. In fact, you can generate attacks which have pretty much any shape that is sufficiently memorable for the player, from a single point, to lines, cones, lines radiating out from a point, circles - affecting either the edge or the whole enclosed area, all targets in line of sight, or more complex shapes: in roguelike games even ASCII art can be used to define an attack shape. There are fighting games and shoot em ups that have attacks which fill the whole scene with a wonderful palette of unusual shapes and projectiles - there is little limit but your imagination when it comes to designing interesting attack shapes.

And the behaviour of these attacks can be complicated as well: vortexes of energy which chase after nearby targets, blasting rays that rotate around a single point, attacks which swell up to enclose much larger spaces than they initially occupied or mimic natural phenomena such as thunderstorms, volcanoes, waves or lightning bolts. You could have attacks which require you touch the target, then manipulate a voodoo doll from a safe distance, stand still while you control a illusory monster, move around to push out waves of damage on a much larger scale in the direction you step.

There are still important considerations when designing shapes for non-first person games however. The first of which is the interaction between the attack and parts of the map which normally block line of fire. For large and unusual shapes, you may either choose to allow the attack to pass through blocking grids in order to maintain the integrity of the shape, or to project the attack from a central point or points, not drawing parts of the shape which would fall outside of the line of fire of these points.

The second is the interaction between line of sight and line of fire. Depending on the algorithms you use for each, you may end up in a position where line of sight and line of fire do not coincide. This might be because you apply looser constraints to determine whether a grid is visible or not, to the constraints required to pass the projectile through intervening grids to reach the final target. You need to intuitively convey the differences, either through the targetting user interface, or by clearly showing the projectile failing to reach the target when fired. What is worse, that some times a grid may appear to be untargettable when aiming directly at it, but by aiming at a nearby or further away grid, the projectile algorithm may determine that it moves through the targetted grid as a part of the projection.

The final consideration is symmetry between player and enemy attacks. With complex attacks which do not necessarily require line of fire over the lifetime of the attack behaviour, it is possible for the player to repeatedly hit an opponent without exposing themselves for retaliation in return. This can also occur when opponents are unable to return fire at the range the player is at, or if line of fire itself is not symmetrical (possible in some grid-based line of fire implementations). In this case, the enemy AI needs to be programmed to avoid indirect attack by the player, which is a lot more difficult than simply avoiding direct attack, as all possible types of indirect fire need to be considered. Otherwise the player will be able to trap opponents using indirect attacks so that they can be killed without exposing the player themselves.

It is possible with shapes to come up with a hierarchy of less to more effective shapes. The most effective shapes are those that don't expose the player to counter-attack - as a result, these should be encumbered with drawbacks such as a limit on the number of placements, or forcing the player to stay in relative proximity to the attack, or within a proscribed area.

The least to most useful shapes affect:

1. The player
2. One target adjacent to the player
3. Multiple targets adjacent to the player
4. One target in a limited range, in line of fire
5. One target, at unlimited range, in line of fire
6. One target, ignoring some or all line of fire restrictions
7. Multiple targets in a limited range, in line of fire
8. Multiple targets, at unlimited range in line of fire
9. Multiple targets, ignoring some or all line of fire restrictions

The above hierachy is not absolute in any sense, and as pointed out in the comments and by Craig Perko in landscapes and level design, the layout of the level strongly interacts with the shapes of attacks. But thinking about a hierachy will allow you to judge whether to increase or decrease the relative power and effectiveness of attacks against the shape they damage.

For shapes where multiple grids are affected, shapes which which are closer to the player, such as a cone with the player at one terminus, are lower in the hierarchy, than shapes that are unbound; shapes which can inadvertently affect useful targets, such as the player, allies or collectible items less than shapes which can be controlled or have no drawbacks. Finally, as noted, shapes which affect grids out of line of fire of the player are the most effective.

Behaviours are simply shapes which persist for multiple game ticks - potentially transforming shape, damage and/or element over the course of the behaviour lifetime. Note that behaviours are different to timed damage: timed damage once applied can be removed as a status effect, the behaviour instead must be avoided by the target. This suggests that behaviours are preferrable to timed damage where possible.

Shapes are where your imagination can run wild, and where balancing game play is the most critical. It is possible to create interesting, vivid games with only using damage per second and damage shapes to control the game space: Team Fortress 2 and to a lesser extent the Half-Life 2 mod Dystopia are excellent examples of how the shape of the damage defines the characters in the game. Shape design interacts with map design, forcing you to think holistically about how your magic system interacts with the game spaces you build for players in your game - are corridors short or long, wide or twisty, rooms clear or filled with obstacles? These factors will determine the utility of shapes in the game, and often only extensive play testing and statistical analysis of game play will reveal the relative strengths of each shape. One of the greatest games ever made, Chess, depends entirely on the library of attack shapes of the pieces in the game, and your game should as well.

In part ten, I start to bring all the design concerns I've raised in parts one to nine together, using Angband and variants as specific examples of magic implementation, and start to consider what changes I need to make to the UnAngband magic system, and my way of thinking about game-design in general.

Hard Core Spore: Civilisation Phase

(You might want to read parts one and two before starting this).

Save file bitching aside, the Civilisation phase plays like a complete game, which is why people seem to have tolerated it more. This involves capturing spice rigs to generate cash, organising the 3 possible building types in your city to maximum income while managing happiness, and building and spamming up to 9 different types of unit (land, sea, air flavours of military, economic and religious units) to attack other cities and capture their rigs. Graphically it impresses, particularly when you qualify for air units where it reminds me a lot of the space battles in Babylon 5 - in fact the vehicle builds seem almost directly inspired by the Babylon 5 style Amiga generated ship graphics.

I did encounter what appeared to be actual bugs, however. It seemed relatively random whether or not I could replace turrets when I opened the City Planner - sometimes I could pick them up and dispose of them, other times I could not. And off-shore rigs appear to be completely impossible to destroy using military naval units. I left a small armada bombing a rig for approximately 20 minutes to no effect.

The Civilisation phase plays nothing like the Civilisation series, however - which is a good thing. I really enjoy the technology tree aspect of the Civilisation series, but find the turn based combat painful and unit micromanagement unnecessarily complicated. The combat in this Spore phase plays more like a 3d version of Defcon. Which is a crying shame, because Defcon is far easier to manage, and built by an independent gaming studio without the entire resources and best minds of Electronic Arts behind it.

Having played with the Spore prototypes and been criticised in the comments thread for not realising the game is designed to be simple enough for non-gamers to pick up, I think it is fair to say if that were truly the case, the Spore team should have spent a lot more time on the camera controls and unit selection in the game. Making a game 3d, as Soren Johnson pointed out with Civilisation IV, adds a huge amount of design overhead to the overall game. While he was probably referring to the art assets required, it is easy to forget how complex a good 3d camera design system is. And from the Creature phase onwards, the camera design in Spore is inferior to most 3d games.

This points to a real problem for anyone designing procedural content in 3 dimensions: you have to account for all the possible edge cases: such as moving through vegetation, standing on the edge of a cliff and trying to target things while you are on an uphill slope. This last case was the first time I had real camera problems in the Creature phase (as opposed to just losing my allies off-camera). I was trying to recruit creatures from a nest which stood on the edge of a slope: when I was on the slope, the camera could not show me the creatures, which meant I had no way of determining what action they were performing in order to reply.

The fact that the camera is free-roaming, and not, for example, locked to true north at the top of the screen is part of the problem. I don't believe this is necessary, but it may have been done to allow the player to work around some of the complexity problems caused by allowing units to appear in front and behind buildings. In which case, why does it appear to be impossible to pan rotate the view while you are in the City Planner. This makes it painful to try to decommission vehicle units, as this is the only screen you can do it on.

Note that this is compounded by the fact that it is not actually possible to lock the camera to free-roaming only. Instead you end up with a partially free roaming camera, which when you lose control such as while trying to recruit creatures or use a planner, ends up reorienting itself to spoil whatever position you last went to. The massive sweeping pans, which are intriguing in the Tribal phase, and initially impressive in the Civilisation phase, complicate the camera by causing massive latency when moving from one part of the map to another.

Selecting units, particular when units are seperated on the z-axis such as a mix of air and ground units, is also painful. An initial improvement would be to differentiate Ctrl clicking for individual units and Shift clicking for selecting a range of units. Ctrl key grouping is almost a convention in the RTS genre, and it would not hurt at all to support this, without complicating the user interface. But the real fix would be a top down view, allowing quick selection and dispatch of individual unit types.

These problems just don't occur in two dimensional games. And Spore type strategy games, such as Defcon and the Spore prototypes, can clearly be played as two-dimensional, as the z axis on the planet surface only serves as a height map. Of course, a 2 dimensional Spore would never have sold.

The Civilisation phase game play is fine. But that is not enough for a game with the unbridled ambition of Spore. And I think that is the real cause of the disappointment felt by gamers about this game. We don't just want the ability to cutomise our unit appearance - we want the ability to completely customise our units. Having three sliders: speed, health and power, just isn't enough - especially after the choices available in the Creature phase. I want to be able to customize the range, firepower and rate of fire of my weapons. I want to design stealth and detector units, troop and vehicle carriers, in short: I want to have the ability to recreate Starcraft in the Civilisation phase. And I don't believe it would have been that hard to do.

Have a read of the Designing a Magic System series of articles I've been writing. You should start to get a feel for what I'm talking about: in the next few parts of the series I'll be going into more detail about how to build ability systems. Imagine this translated into the Civilisation phase, with different building types needed to build new units and acquire new technologies. This would not be the meh feeling that you get when you currently play through the game: this would raise the hair on the back of your neck as you unlock the possibilities. Starcraft already has an elemental system as I define it: small, medium and large vehicles take differing levels of damage from explosion and concussive attacks. Imagine starting the game with only spice harvester units, then building different turret types, then finally different small, then medium, then large vehicles as you spread out across your planet while you encounter and have to counter different units built by other players and downloaded from the Sporepedia.

Imagine building your own huge machines, the mechanical equivalent of Epics to rain death down on your opponents. Have tens or hundreds of your individual creatures swarming the enemy with small arms designed and built by yourself. That is another of the real crimes of the Civilisation phase: taking your creatures out of the game and replacing them only with vehicles, a crime to be rehabilitated by playing lots of Darwinia.

But if the Civilisation phase is the real Starcraft - just misnamed - then what should the Tribal phase haven been? I'm going to suggest the Sims. Your tribesmen have individual names, a village that they can build and decorate, other tribes that they can go out to encounter. Replace tribes with the social cliques of the Sims, and the ability to evolve the social structures - an aspect missing from the game as Stephen Totilo has pointed out and an intriguing game concept results - Sims: The Aliens - if you will.

And rumour has it, that Will Wright might be able to organise some sort of cross-licensing deal between the two.

Spore Save Games

Hi Mr Wright,

I'm a frustrated game designer. What particularly frustrates me is the single save slot in Spore. I can understand why you do it - you want to create a persistent universe where changes carry on from one game to the next. But I want to have the freedom to experiment from a fixed base line; to see what choices I make at each stage of evolution to carry on to the next.

More importantly, if your game keeps losing save files: as it has just done for me; and appears to have done for other people playing the game on the net - I want the reassurance that you will have auto-saved when I finished the Civilisation level after grinding my way through city after city of unenjoyable game play for the previous two hours.

That is all.

Regards,

Andrew D.

PS: While you're here, you might want to read some design suggestions I have for Spore... and how to backup your Spore games.

Design Language: Designer Derivations

There is an excellent nostalgia piece over at Gamasutra called Designer Derivations looking at the early years of game design. That is, game design juvenalia - those games you put together as a kid from cardboard, pen and paper. I still have a manila folder or four full of game design notes from the many Dungeons & Dragons campaigns I ran as a teenager, and the massive plans for computer games - primarily BBS games at the time - that appear to be slowly gaining traction in my adult years (The Dungeoneer game I designed appears in part in UnAngband).

The game design art included with the article is beautiful as well. I've included a small section of one of the submissions to the left, but I should really scan in and show some of the work I did as opposed to borrowing bits from someone elses' efforts. Its not until you look back at the crazy scrawls that inspired you that you realise just how valuable it is to keep your early efforts at game design.

Ironically, given it appears to be Spore week this week on the blog, I categorised my computer game designs into groups not dissimilar from the phases of Spore game play.

I was lucky, in many ways, to role play alongside some people who founded a game company and went on to write at least one gaming supplement that achieved commercial success: GURPS Goblins.

Results for 'Which articles have you found the most interesting/useful?'; new poll

Thanks to the 31 of you who voted - I always find the feedback to these polls interesting. I think this is telling me to stick to my core speciality (roguelikes) and not branch out too much into other areas... feel free to discuss.

A Technology Bird's Nest	5 (16%)
Being Diplomatic	3 (9%)
Designing a Magic System	27 (87%)
Games are Not Art	5 (16%)
Prince Charming	3 (9%)
Prototype Theory	5 (16%)
Spore: The New Cambrian	4 (12%)
The Democratisation of Game Design	6 (19%)
The Search for Citizen Kane	3 (9%)
Unangband Edit Files	14 (45%)
What is Wrong with Fun?	8 (25%)

Next up: it's more Spore week voting.

Hard Core Spore: The Tribal Phase

(You may want to start with part one of this article).

In contrast to many commentators, and my experience with the Creature phase – I didn’t find anything particularly broken with the Tribes phase – in fact, I enjoyed it. The tribal persuasion mini game works a lot better: it turns out playing a simple rhythm game is a lot more interesting while you’re simultaneously worrying about an imminent attack on your home village. The creature game mechanics tie in nicely: both on the surface, as well as implicitly. I never stopped enjoying watching my creatures stealth up before rushing into attack, and I imagine creatures with spit, strike and other creature mechanics are a lot more effective in tribes combat. The capture the village mechanic shapes the game nicely, and up until the mid game the experience works well. The only problem with the Tribes game is that it lacks scale: you only have to capture 5 villages in order to win.

Unfortunately, while the Cell phase is unique, and the Creature phase brings a number of interesting twists on the single player MMO genre, the Tribe phase makes the mistake of coming up against the juggernaut in the room: Starcraft. Pacman and Diablo, the inspiration for the first two parts of Spore are great, memorable games that influenced a generation of gamers. Starcraft is perhaps one of the greatest four or five games ever designed – including non-computer games such as Chess and Go. To compete, designing RTS-lite game play just doesn’t cut it.
The challenge then: design a game worthy of associating itself with the RTS genre using the existing Tribe phase assets. I’m not expecting Starcraft 1.5 – just something that has a passing resemblance to the mechanics that made that game great.

It’s always worthwhile listing the assets we have to play with:
• A home building which breeds units and gets bigger as the player advances through the game
• A fireplace and food store from which units can eat to recover
• Fruit and meat, two different sources of food which are collected in two different ways – from fruit trees and hunting animals respectively
• A number of different technology buildings which the player can use to equip their units with musical instruments, weapons and improved food gathering techniques
• The ability to befriend, fight or give things to other tribes
• The ability to heal by either being at home base, or equipping healing rods
• The ability to capture wild animals as pets (a mechanic I was not even aware of)
• A variety of different verbs (collect food, attack, play musical instruments, stand around and talk)
• The ability to design outfits and clothing
• A number of different special abilities inherited from earlier phases of the game

The early game in Starcraft is a unique balance of three different strategies: turtle (defend), rush (zerg) and tech. A turtling player will get an advantage against a rushing player, a rushing player will beat a teching player, and a tech should be able to win the game provided they survive the early game – implicitly getting a victory over a turtle player. The next strategic decision beyond building units and either attacking immediately (rushing) or defending (turtling) is when to expand to a second base / resource gathering point: do it too early and get caught doing it, and you’ll lose. Do it successfully and you’ll get a massive head start. The end game is built up on the balance of early successes and a steady attrition of units: with an escalating game of whomever is able to build the best counterstrategy to the opponent’s unit mix. At all points of play, having intelligence about what the enemy is doing is critical – in a single player game, this is less important and may not end up being a consideration.

The first mistake that the Tribes phase makes is to tie expansion with technology. Capturing a village not only gives you a long term strategic advantage of less competition: but you also capture the enemy’s technologies – in fact, this is the only way to tech up.

It is tempting to associate the Starcraft strategies with Spore tribe types: there are three – social (arising from herbivores), military (arising from carnivores) and industrious (from omnivores) which form a natural fit for the playing styles. Life for the military is nasty, brutal and short: rush tactics to the core. Social meanwhile are turtlers, and industrious are technology based. But at the same time, each Tribe type has different attack strategies: recruiting an enemy village for a social type requires a large number of relatively defenceless units including the village leader – whereas a military attack is less resource intense. There is actually a third ‘attack’ type: which I’ll associate with industrious tribes. It is possible to give gifts to villages to sway them your way. Industrious villages are omnivores so have more food sources, so more likely to be able to give these away – gifting is a natural fit, but not emphasised enough as an alternative in the existing Tribes game. It is this industrious gift game and the way technology is developed that I’ll use to work into a fuller Tribe game design.

It is important to note that you cannot recruit enemy villages: you can only attack them. Gift giving then can become a ‘diplomacy game’. As a rule change, any creature bearing gifts will not be attacked, regardless of village attitude to you: once you give a gift. A gift should be able to do one of two things, either make the village view you more positively, or to make the village view another species more negatively. To expand this, it should never be possible to completely ally a village through give giving: you should only be able to make them neutral at best. This allows the industrious player to tech up, while playing his enemies against each other.

So how to discover technology in the first place? There are two options: spying and research. Spying is the natural second half of the gift giving – once you have placated an enemy with a gift, you can get a number of research points towards a particular technology they have which you lack. This should simply be based on proximity to the enemy village. Once your spy stands there long enough: they get an ‘idea’ of what the enemy is doing. Returning to your village with the idea either grants you a piece of clothing, or a partial contribution to which ever current technology you are researching. The speech bubbles that two otherwise unoccupied villagers talk to each other with is used to represent this idea.

As for research: this is going to be key to balance the tech / turtle / rush mechanic. In the early game, a carnivore will be hunting animals, a herbivore gathering fruit and an omnivore doing both. Units will be sent out to spy and locate other villages. Having two guys standing around doing nothing but talking: the research mechanic for this game, needs to be sufficiently expensive foodwise so that the tech is disadvantaged against a rush that a turtle is not.

So what does an early game rush without weapons look like? To me, it feels a lot like stealing food. In fact, carnivores with their natural tendency to kill nearby animals are naturally going to reduce the number of wild animals stealing food from the player, omnivores and herbivores meanwhile need to be pressed enough gathering food and/or researching, that the cost of food being stolen by wild animals has to be high. In fact, I’d suggest that it should be impossible to prevent wild animals from stealing your food and that this mechanic should be a lot more frequent and pressing a problem in the early game: the only solution should be to predate nearby wild animal populations until they are reduced to zero. So the carnivore rush is actually a counter rush: at the initial stages of the game it is enough to have them deplete the wild life nearby to reduce the frequency of theft.

The start of the Tribes game therefore is one where you don’t interact with other tribes at all: the local challenges are getting enough food and keeping it, and building your first technology through research. There should be a variety of challenges at this stage: fighting wildlife or domesticating it, balancing research vs. food gathering, which do not to require any initial interaction with other tribes.

But it should be about now: having used up and exhausted local resources, that you start to naturally spread your area of occupation. This will happen for carnivores first: who consume a slower regenerating resource, then herbivores and finally omnivores. What will these first interactions look like?

At this stage, we’ll make the assumption that we still don’t have any technology, and see where that leads. Again, food theft points the way. If it is impossible to stop wild animals, it should be much harder to stop wily enemy tribesmen. The payoff for theft needs to be higher as well: I’d suggest a hierarchy of gifts > food theft > meat > fruit as a balance mechanic, given that the distances travelled for stealing food are much greater than harvesting local resources. Implicitly, we don’t have enemy tribes at this point – only strangers who are less or more willing to steal from us. We can use gifts to influence this decision, spying to try to get an edge in technology development, and food theft to get ahead in the food race.

Finally technology comes into play: the development of either the first weapons, musical instruments or food gathering tools. Those who have achieved the most in the technology race: presumably omnivores, will get there first. Weapons allow a declaration of war; allowing warring tribes to fight (regardless of which side has the weaponry) – musical instruments allow you to influence and ultimately recruit other tribes – fishing and food gathering to get more food and correspondingly get ahead in the technology race. The decision at this point becomes how to expand: take on another tribe through charming or killing them, or to use food gifts to play tribes off against each other while you go up the tech tree.

One further refinement of the Tribes phase: equipping weapons corresponds to unit types. Therefore the tribe designer should be able to design separate costumes for each tech type they research. I was surprised that this functionality wasn’t in the initial game – it makes sense to dress musicians differently to torch-bearers to spear throwers to diplomats (units carrying food gifts); and of course save the best and most elabourate custom for the tribal chief.

The end game for the revised Tribe design plays out not dissimilarly from the current game: but separating out the technology component from the village capture mechanic to force a trade off between each. There is, however, one important difference - the enemy AI. And this is where I fudge the above design. I stated that the Tribes phase redesign should be done with existing assets. This is the one exception. At the moment, the Tribes phase AI is horribly flawed: your opponents start with an early rush to build the tension, and then fail to replenish their resources – leaving undefended villages behind. They ignore villages you have allied with instead of raiding them, never expand beyond their starting technology and never conquer or enslave other tribes. The Tribe villages are as passive as the nests you find in the Creature phase, leading me to wonder if the Spore team know how to write an AI capable of handling a procedural world. I was left wondering this for the first few minutes of the Civilization phase, until I noticed the nearest civilisation to me conquer half the continent and then bear down on me bringing a barrage of bloody death.

Have I made any mistakes? Can you make a more interesting design? Use or abuse any of the assets I missed out?

I believe there will be a part 3 shortly.

Too Much Time

If you wonder why I've been quieter recently, it is not because I've been playing Spore. Instead I was at Tech Ed.

It turns out that I have way too much time on my hands: I've been playing Spore and Team Fortress 2 with reckless abandon, blogging on Ascii Dreams, programming Unangband albeit intermittently, working on the PCG Wiki to make sure there is a steady stream of updates coming through, working a job that has an 80 minute commute each way, clocking 40-60 hours per week, spending valuable time with my wife and her family, looking after the new house...

Then there is Google reader. From my 210 subscriptions, over the last 30 days I read 9,627 items, starred 8 items and shared 39 items.

Despite not spending much time on it recently, Unangband is still the 27th most active project on Berlios. The PCG Wiki is in the top 50 wikis on wikidot in terms of overall activity.

So what do I do?

I'm starting up a new blog on technology issues, called IT Futurology. As an IT manager, I think I have a bit to say on the subject. I've put up the first few posts: feel free to link across and have a read.

Hard Core Spore: The Tide Pool & Creature Phases

It appears to be fashionable to bash Spore's difficulty and complexity as of late. Will Wright has defended the difficulty curve, while various commentators have called out the cell, or tide pool phase, as the most immediately enjoyable, while criticising other phases as perhaps too simple: particularly the Tribal phase.

You can expect no less from me than bandwagon jumping and general game-design grumpiness. I tried to hold off buying Spore on account of the initial reviews and general drift of dissatisfaction: I knew I'd end up writing something along the lines of what you see below - with little to no chance of any suggestions ever being adopted. I'm going to defend my position as taking advice from the best: I started playing Spore on hard, and have no intention of dropping the difficulty level. That choice is the best argument I have against Will Wright's difficulty defense - hard should be hard, exposing the sharp edges of the game design and allow me to impale myself on them.

And I incredibly enjoyed the Cell phase as a result.

On hard, your rapidly evolving critter is battered and blown about by creatures of a scale and difficulty well above what you have earned. The scale mechanic works brilliantly: especially when emphasised by the floating plant masses in the tide pool which you feed from as a herbivore. One minute they are too big too bite into, forcing you to nibble the frond ends while avoiding fellow browsers: the next, you grow to a size when you can swallow the entire plant whole. The Cell phase forced me to think and feed like a herbivore, run instead of fight, retreat instead of threaten.

That is the Cell phase is not without some design problems.

It is too easy to call for a mate and use the temporary invulnerability given due to the mating dance to avoid attack. This works well because you do not have to get in contact with your mate: moving in proximity for a few seconds – even half a screen away – initiates the dance. The sensitivity of this should be increased on the hard difficulty: so that you have to effectively ‘dock’ with your mate to initiate mating. For less mobile mates you should have to instead protect your mate from attack until you drift together.

There is also no directional bias that I could see: you can effectively swim in any direction without advantage or disadvantage. On hard, this usually isn’t a problem – certainly my experience was you spend a large proportion of time simply avoiding attack. The solution: make eyes useful. At the moment these don’t seem to contribute much. A simple edge of screen green glow for food – sensitivity dependent on the number of eyes you have – would contribute a directional imperative. I suspect you could extend this to the faster currents you occasionally find as well – indicated by a soft blow glow. The tactic would be to search for faster currents and use these to sweep an area quickly for food.

But the cell phase (or tide pool, as Spore seems to prefer calling it) is a charming game that doesn’t outlive its welcome. My experience of the Creature game on the other hand, was less impressive.

Much initial criticism seems to be around the friendship game that is the herbivores primary DNA acquisition mechanism. This involves the player locating other herbivore nests, and recruiting them using a simple mini-game, where the two species interact using Singing, Dancing, Charming and Posing. Both species need to have one of these recruitment mechanisms in common in order to interact effectively. Higher levels of a particular skill allow you to effectively ‘win’ the game quickly – until you encounter an equally skilled opponent. The mini game involves some pattern matching: you have to meet in the middle of a bar graph, where more skilled practitioners fill their side of the bar more, at the expense of slowing the amount you fill on the bar – and you are most effective when you match whichever technique your opponent uses, and time the process so that you start your turn filling when their bar reaches the peak, and before it reverses and quickly empties.

There are a number of problems with the mini game: rhythm games typically do poorly on the PC, but better on the console, there is a lack of feedback at which point the opponent’s bar has reached its peak, and the Hard difficulty seems to make it harder to fill the bars – making exact timing more important and possible to fail the game completely on the first round of play.

It also appears impossible to ‘lose’ the game – in the sense that you are free to repeat the recruitment with only a slight loss of face instead of the species you are attempting to persuade, instead becoming your enemy. I would rather a more sophisticated mini game mechanic: maybe a match 3 type game (more appropriate for a PC), which penalizes you more heavily for a loss on higher difficulty levels, but making the game slightly harder to lose. Higher levels of a recruitment skill are too useful – lower levels not useful enough – and there are distinct advantages to being a generalist as opposed to a specialist.

But the problems with the recruitment mini-game are outweighed by the lack of time pressure on a herbivore to interact with these allies in the first place. A herbivore should have a feeling of constantly being hunted – conveyed brilliantly in the cell game, but lost in much of the creature phase.

The migration portion of the Creature game works well for this: there is a constant feeling of being under threat, sneaking around enemy nests, and staying on the run, leaving your less quick or stealthy allies behind to be rend limb from limb while you escape. (It is such a shame that combat works as badly as it does: poor camera control makes distance almost impossible to judge in the midst of melee, and frequently loses your allies behind you).

But once you have migrated, there is this indeterminable period during which you are free to wander the landscape, under minimal threat unless you stupidly stray too close to a carnivore nest, and at little sense of competition or nature red in tooth and maw. There is no pressure to survive: the food timer that pressures a carnivore into seeking out other nests and hunting, requires only you occasionally side trek to a nearby marked fruit grove and snack on some apples. The occasional Epic keeps you on your toes, but not frequently enough.

I would like to see much more pressure on herbivores than currently in the creature phase, and competition, not just cooperation between herbivores, would be a good place to start. Unfortunately, the only mechanics I can see, start to introduce RTS elements into the Creature phase. My suggestion follows:

At the moment, your nest starts surrounded by a number of fruit groves. These should become a resource for herbivores to control and contest. As you feed on a fruit grove, near your nest, you should ‘capture’ the grove, marking it green and start to encourage your nest mates to travel between the nest and the grove to feed. This increases the total number of creatures of your species, which starts to collect DNA points. Other herbivores do likewise: if two sets of herbivores browse at the same grove it becomes contested, and marked with a red.

Contested groves are resolved in a number of ways: competing herbivores fight each other at contested groves – the winner captures the grove. Equally, you can recruit the contesting herbivore, which recaptures the grove for you. Or you can go straight to the herbivores nest, and attempt to charm them there – capturing all their groves in addition to allying them. The number of contested groves determines the level of ill-will between the two species: dropping by one rank for each contested grove, until war breaks out and the herbivore starts attacking your species on sight. Competitive herbivores should be able to recruitment your groves back off you, either at the grove or through having a delegation travel to your nest – should you neglect your recruitment attributes.

Carnivores, meanwhile, don't seem to interact much outside their nest. Instead, they should prey on herbivores at nearby groves. When a carnivore has killed enough herbivores, they will discover the herbivore nest, and start attacking it. It should be possible for you to train carnivores, that is have them spot and follow you, allowing you to lead them to attack other carnivore or competing herbivore nests.

Note that these mechanics only have to kick in on the hard difficulty, if required, and deliberately provide mechanics to minimise the amount of nest-defending you have to do – allowing you to still explore the environment as you currently do. Detecting and killing or training nearby carnivore nests becomes important, for which there is little incentive currently, and there is competitive pressure between nearby herbivores for resources that you need to exploit. Ultimately the way to defeat herbivores is the same as present. And migration provides a handy reset mechanic, allowing you to start out in another area, should you end up in a position surrounded by enemies.

How is your experience of the game so far? Do you agree or disagree with what I've seen? Have I missed anything? Comments welcome.

(It turns out I got annoyed with the Tribes phase as well, in part two of this article).