Data design for Civilisation games

I seem to have Civilisation on the brain at the moment; and with the recent 0.6.4 release of Unangband out the door have been spending some time looking at the Freeciv project. If you're looking for roguelike game design, you might want to stick around though, because I'm going to be discussing data file design in some detail.

Freeciv is a Civilisation clone, written originally as an exercise in client server programming (There's a nice history summary at the bottom of this AI discussion). Its implementation of the various Civilisation games falls somewhere between Civilisation 1 & 2 as Alex Mayfield points out the last time I mentioned my Civilisation Revolution house rules. Luckily for me, much of the unit design is very similar to Civilisation Revolution so it seems quite possible that I may be able to get away with limited amounts of source code changes.

The mod system that Freeciv uses is quite similar to the Angband edit file system - with the exception of the format which is seems influenced by the Windows .ini file format. A mod in Freeciv consists of a number of rulesets which are used to initialize data structures with values and flags which impact the game play for that unit. A typical Freeciv unit may have the following format in the units.ruleset file:

[unit_warriors]
name = _("Warriors")
class = "Land"
tech_req = "None"
obsolete_by = "Pikemen"
graphic = "u.warriors"
graphic_alt = "-"
sound_move = "m_warriors"
sound_move_alt = "m_generic"
sound_fight = "f_warriors"
sound_fight_alt = "f_generic"
build_cost = 10
pop_cost = 0
attack = 1
defense = 1
hitpoints = 10
firepower = 1
move_rate = 1
vision_radius_sq = 2
transport_cap = 0
fuel = 0
uk_happy = 1
uk_shield = 1
uk_food = 0
uk_gold = 0
flags = ""
roles = "DefendOk", "FirstBuild"
helptext = _("\
This unit may be built from the start of the game. It is the\
weakest unit.\
")

Contrast this with an Unangband monster entry, and you'll see there is not a lot of difference, other than the format which defines how the values are read in:

N:24:Small goblin
G:k:y
I:110:8:20:16:10
W:2:1:0:4
M:0:0:1:0
B:HIT:HURT:1d5
F:DROP_60 |
F:OPEN_DOOR |
F:ORC | EVIL | IM_POIS |
F:HAS_SKULL | HAS_SKELETON | HAS_TEETH | HAS_CORPSE | HAS_HEAD | HAS_HAND |
F:HAS_ARM | HAS_LEG | HAS_BLOOD | DROP_MISSILE | DROP_TOOL | DROP_WEAPON |
F:DROP_CLOTHES | DROP_ARMOR | DROP_FOOD | DROP_JUNK |
F:SCENT | DWARF |
D:It is a squat and ugly humanoid figure.

One initial observation is the Unangband file format encodes a lot more information in much less space. We could reduce the total length of the Freeciv warriors entry to about half the current length by adopting a similar context-dependent format, as opposed to the more context-free format that Freeciv uses. We know every Freeciv unit has to have an attack/defense/move/vision/firepower and upkeep values, so there is no need to have each of these defined on a separate line: and the user interface itself can be used as a guide for how we can lay out the values more compactly in the ruleset file format.

This may not sound especially important, but from the perspective of quickly editting multiple entries - for someone trying to mod the game - screen real estate is a valuable commodity.

The second observation is that the Roles in the warriors unit in Freeciv are not intuitive, in the same way the Unangband flags are. You can guess straight away from looking at the goblin entry the ways that HAS_HAND and DROP_WEAPON might be used in the game. DefendOK may make sense, but FirstBuild? In some ways, this may be an issue with the fact we're dealing with an agglomeration of multiple individuals rather than a single entity, but it is worth bearing in mind that defined roles (and flags) may not 'natural' and may be worth redesigning.

There is a significant difference between the way roguelikes and Civilisation games play that is not reflected correctly in the similarity between the two file formats. Roguelikes rely on your ability to learn and understand special abilities and unique effects and which one to use at any point in time. The fact that small goblins are immune to poison makes a significant difference only if you are facing a small goblin, and have a choice between a poisonous and non-poisonous attack. So a binary flag is an appropriate way to reflect the criticality of this decision.

Civilisation games on the other hand, rely on the aggregation of small differences over a large number of units, and so scalar values are much more important than binary flags. The fact that a warrior can defend a city is much less important than the attack and defense values of that warrior: a difference of only 1 in attack strength is the difference between success and failure of a particular combat, but that combat may be played out multiple times in a single game, which converges towards an average result in a way that a roguelike does not. If you want to think about it another way, most roguelikes allow you to reset to your starting position of full health at any point during the game with a single item - Civilisation games don't allow you to reset to your full complement of warrior untis.

So while the Freeciv file format is undoubtedly a natural evolution from moving hard-coded game data to an external file the same way that Angband does, I believe there is significantly more value to be gained by extending the file format of Civilisation in interesting ways.

If you look at my Civilisation house rules, you'll see a lot of rules of the format 'with technology/civic/building', unit X gets Y, where Y is often a modification to an existing scalar value of some kind. Or more importantly, the set of units of type Z get this change, where Z could be all units, mounted units, pre-gunpowder units and so on. It would be extremely useful and flexible if we could encode this into the Freeciv ruleset without having to have flags refer to hard coded bonuses in the game code.

There's a couple of ways of considering how to do this. We could go with a full blown scripting model, where each unit runs a script to determine which modifiers apply to it's basic values, and the avaible technologies, civics, buildings and so on are exposed to the script system to check. However, I'm uncomfortable with a full scripting system, and I think we can do this in a simpler fashion.

Imagine a unit as a collection of scalar values and properties. Some properties are intrinsic to the unit ('on-foot'), some properties are dependent on the civilisation ('the-wheel-technology', 'democracy-government'), some are global ('nuclear-winter','global-warming') and some are positional ('attacking-city', 'defending-forest') or modal ('fortified'). A unit type then defines a set of rules where the unit having the matching property modifies either a scalar value through setting the value, addition, multiplication or scaled by percentage, or through the addition or removal of a property for that unit. We can use properties to also indicate that the unit is a member of another unit type, which also has a set of rules which further define the unit and so on.

We can then determine the unit scalar values by starting with the base unit type, and matching rules from that unit type and the rules from its properties, applying the effects of each rule exactly once.

For instance, one unit type might be as follows:

military-unit = {
can-attack;
can-defend;
fundamentalism-government:+1 attack;
...
}

We can also evaluate scalar values instead of properties.

military-unit = {
...
experience>=3:veteran;
veteran:+50% attack;
veteran: +50% defence;
...
}

One important extension to this is that the units have to be able to affect other unit types. For instance, aircraft cannot be attacked by ground units.

aircraft = {
*ground-unit:-can-attack;
...
}

And we have to be able to override this:

anti-aircraft =
{
*aircraft:ignore;
...
}

where ignore is a reserved value that prevents the associated property from being processed.

I'm still in the early days of sketching this out, but I hope this will be an improvement on the existing Freeciv rulesets. The implementation of this design will, of course, be another complication.

My question for you is whether I'm reinventing the wheel here? I believe this is a design pattern that multiple games must have confronted before, and there should be something that already does this work for me, short of going to a full scripting system like Lua.

Re: Engineering

I've came up with suggestions some time ago about what alternate weapons the Team Fortress 2 Engineer should have. But since then, Valve have released several subsequent updates which have considerably changed how the Sniper, Soldier and especially the Demoman play and a beautiful crafted fan page has suggested some alternate turret weapons. And, in case you've missed it, the last major update to Team Fortress 2 added a chocolate bar for the Heavy and several melee weapons (One for the Pyro and one shared between the Demoman and Soldier).

So the scope is there for the Engineer to have more than a few additional items added: either as a part of the update, or in further releases.

Looking back at the suggestions I made: the Quik-R-Ratchet, or a variant thereof has already been tested in beta as the PDQ; the Scout order book suggestion existed at one point as a backpack but was not adopted; the I-Spy-Shooter is fine, but not amazing - and having played my first 35 point Spy game yesterday, I now feel qualified to state its hard enough already to sneak up on an engineer that I think there are better alternatives; and the BRB still feels distinct enough to be useful - perhaps also allowing the engineer to teleport even if his exit is sapped.

I'm still not convinced that the engineer needs alternate buildings - the only one from the fan page that feels 'right' is the multi-mode flying turret - and Valve themselves have pretty much ruled out replacing the teleporter or dispenser. Buildings that provide various buffs (kritz, minicrits, invulnerability) make the buffs that other classes provide less special, and similarly turrets that provide alternate attacks lessen the uniqueness of class weapons. And anything that affects the small window of opportunity between backstabbing an engineer and having the turret turn and shoot you while you try to sap it, is going to affect the balance of Spy vs Engineer encounters - which of the ways of taking out turret emplacements is the most interesting and least frustrating for the Engineer.

Here are some more Engineer item suggestions:

Gone Again Guitar: While playing the Gone Again, the engineer and all nearby friendly buildings become invisible and do not have any effect or attack enemy players. The Gone Again plays as a taunt animation for a fixed duration with a cooldown. Why: There needs to be a guitar based weapon for the Engineer, and something which allows the Engineer to build in an open location and then draw in the opposition should be fun. Especially since you'll be able to hear him play, but not know where he necessarily is. Replaces the Shotgun.

Ranch Home Rivetgun: The Rivetgun is a ranged weapon similar to the medic's primary weapon, but with a slower rate of fire, much smaller magazine capacity and more damage per shot (about 25% more DPS than the medic). However, the Rivetgun also repairs friendly buildings it hits - at approximately the same rate as hitting it with a wrench. Why: this allows the engineer to repair their buildings while not necessarily next to them - letting them roam with confidence. Since the repair depends on ammunition, it should be a shorter term improvement, and this is balanced against wrenching because the Rivetgun doesn't resupply buildings or remove saps. Replaces the Shotgun.

The Cowpoke: The Cowpoke is a crossbow with a barbwire drawstring and a red hot poker for a bolt. The Cowpoke has better range than the Sniper's bow, but does less damage, and has a much slower reload. Friendly turrets turn twice as quickly when tracking targets branded by the Cowpoke. The Cowpoke replaces the Shotgun. I had planned on making this a melee weapon but realized that a) hitting a building with a branding iron doesn't make a huge amount of sense and b) making this a ranged weapon encourages the engineer to run forward and tag upcoming targets. Note that this doesn't prevent a Spy from disguising or turning invisible - just when the Spy becomes a valid target they get tracked that much quicker.

Stand Tall Spurs: The stand tall spurs allow the Engineer to pick up and move his buildings. If the engineer is hit while moving a building, the building takes damage as well as the engineer. The Stand Tall Spurs replaces the Shotgun - left click to pick up, and then place the building using the original building placement commands. There is a short set up time when the building is placed again (2 seconds) before it comes fully active.

Well-done Arc Welder: The Well-done allows you to buff all nearby buildings temporarily which reduces damage to them by 50% for explosives and 25% for all other damage types, but means you take twice as long to upgrade your buildings. The buff lasts for 15 seconds with a 45 second cool down and appears to be a shower of sparks coming off the affected buildings. Why: an invulnerability buff is tempting, but would completely stop an ubercharge against a building in it's tracks. Whereas a buff may tempt both the attacker and defender to hang around. By biasing the damage reduction against explosives, it reduces the effectiveness of classes the most which don't have to expose them to direct line of fire of the turret to destroy it. Replaces the Wrench.

Good 'ol Grappling Hook: I've waxed lyrical about the next for a grappling hook in Team Fortress 2 long enough - hit a building or map section and you are pulled towards it, hit an enemy player and they are pulled towards you. This would completely unbalance the Engineer, allowing them to aggressively move forward and put turrets in unexpected locations, as well as drag an opponent into their turret's line of fire. I think the craziness would be worth it though - especially after the fun I had with the Demoman replacement weapons. To balance it: the grappling hook prevents you upgrading any building or speeding up construction because it replaces the Wrench. I'd hate to have to contend with a level 3 turret somewhere I hadn't planned on looking.

Permadeath

There have been a number of intriguing articles written over the last few weeks about one of the key concepts, and most criticised features, of roguelikes: permanent death, often shortened to permadeath. This is the notion that should the game avatar die, the player should start from the beginning of the game. Permadeath is the reason why it can take years to beat certain roguelikes - in my case, I have never won a game of Angband or any variant of it in over ten years of playing - and why so many people initially turn away from the genre. But in a world of quick saves and regenerating health, permadeath is the one compelling design feature that you need to appreciate to understand the genre.

The challenge of playing Far Cry 2 with one life made by Ben Abraham of Sometimes Life Requires Consequence has been picked up and commented on by lead designer Clint Hocking, who goes on to explore the conflict between what Ben is attempting and the narrative losses that Clint designed into the game. (As an aside: the immediacy of playing the game and being responded to by the designer of that game plays to the strengths of the blogging medium, the dialog between auteur and audience. This was a triumph - I'm making a note here etc. - for the rise of the game critic/blogger.)

In Infinite Caves, Infinite Stories, Anthony Burch explores what makes Spelunky so compelling - a freeware mix of platformer and roguelike, one of the nascent roguelike-likes if you will - and identifies a mix of three elements: 'randomized [...] levels, emergent gameplay and permanent death'. Think of these as three legs of the roguelike game design triangle - each of which cannot stand unsupported without the others.

Randomized levels, built from procedural techniques or randomly chosen pre-assembled components, is what you immediately think of when talking about roguelikes. But randomized levels feature in the RTS genre without permadeath - but on reflection, the RTS genre does intra-level permadeath: it is possible to lose and restart on a single map while keeping progress between maps. It turns out many genres have permanent death and restart as a core component of the game - arcade fighters, horizontal and vertical scrolling shooters, strategy games - in fact, permanent death is only seen as a negative in narrative based games, especially those like RPGs that feature accumulation of resource over time, and it is roguelikes that are unique out of these types of games in continuing what started as an arcade tradition.

What almost all other genres featuring permanent death have in common is that there is a resource accumulated from game to game: player skill. Improved twitch resources required to dodge an ever increasing swarm of bullets or rote memorisation of the patterns of enemy waves, increased understanding or yomi of the opponent's mind - all of these attributes can be improved and reused in repeated play.

But with roguelikes, it's not obvious what skills are being developed. Certainly not reflexes, and with a single player game, no understanding of an opponent is required. Puzzle solving is closer to the process, but puzzle solving in an environment where the board is reset differently every time, and the pieces are sometimes unfairly tipped against you.

I'd argue that there are two important but distinct phases of skill development that in roguelikes: discovery of emergent game play and the trade off between exploitation of resources against evasion of risk.

Emergent Game Play

Emergent game play in most roguelikes rests on a foundation of the combinatorial explosion caused by designing verbs and objects to maximise the number of verbs which can interact with each object (and implicitly, through throwing, falling, collisions and other game 'physics', maximising the number of ways objects which can interact with each other). From Spelunky, it is possible to rescue a maiden by picking her up and carrying her to the exit, but also, by noticing carried objects can be thrown, a thrown maiden can be used to interact with targets in a number of different ways. Nethack and other roguelikes do this by expanding the number of verbs and ways those verbs can be used - which leads to that Nethack saying 'They thought of everything!'

The process of learning the emergent rules of a game with permadeath and randomized levels transforms the game play from a fixed author led narrative into a meta narrative about the experience of the player learning through repeated and hopefully interesting and unique failure. As the developer of Dwarf Fortress puts it 'failing is fun' - provided you don't have to repeat the same sequence of narrative events each time you do.

But why does this 'failing is fun' approach to learning not work in a game where the player's progress can be saved at any point?

The problem with save games is they capture the wrong sort of progress. The player may have made a critical error of judgement, and failed to acquire a necessary resource or game play skill, somewhere in playing the game prior to saving the game state - and neither the player nor the game designer has any way of knowing this. This is why so many games are designed with gated progression: discrete levels over which a player has to demonstrate supposed mastery of a particular skill. But if a skill is only significant for a subset of the total game, then why have that skill at all? Why not release a series of mini-games instead?

The only guaranteed point at which the player is open to all lessons is at a complete reset of the game state. This does not necessarily have to be a complete restart of the game: it is possible to save player progression provided that all players will end up in exactly the same game state at some point during play. This could be the start of a or new level in a puzzle game which resets all the pieces in play or a new map in an RTS which does not allow units to be kept from previous successes or failures.

Without randomized levels, it is possible for a player to progress simply through rote learning, without having improved the necessary skills. More importantly, repeating the same sequence of actions and narrative sequences is frustrating and ultimately unfulfilling. Think of each play through of a game as being set an exam with a pass or fail mark. If the levels are not randomized, it is possible to sit the same exam over and over, memorising the answers to fixed questions as a method of passing, but not an indication of underlying ability. The process of quick saving and reloading is akin to being able to guess every answer to each question and trying again if you get the wrong result.

Varying the rarity of objects, seen in genres such as MMOs and collectable card games as a callous way of manipulating players to endless grind, instead becomes a useful way of extending the player enjoyment of this learning process, ensuring that some learning situations occur less frequently than others and consequently remembered more vividly. The requirement to identify items through using them common to many roguelikes also helps extend learning, in that the player is not necessarily aware of what resources they hold at any time.

But - even despite my best efforts in Unangband - it is possible to discover all possible emergent properties in most games (not quite true in all cases: self-evolving systems like Galatic Arms Race will prevent this in the future, and the pimpest plays in Starcraft have continued to evolve over that game's lifespan) - and once learned, an emergent property is just another line in a FAQ.

Exploitation and Evasion

In an information complete game, where the player has complete knowledge of the rules, the processes of exploitation and evasion become primary. Take a typical game of Rogue. The player travels through a number of rooms spread across multiple dungeon levels, accumulating resources as they do so. But as the player descends in the dungeon, the level of threat from monsters increases, exponentially so, without a consequent increase in the rewards for defeating them, so that in the last few levels it is better for the player to evade encounters with monsters and conserve the resources he has accumulated earlier in the game, than attempt to stand his ground and fight.

This process can be modelled as follows, where the horizontal axis is the playing time, P indicates the overall accumulated power and R is the risk at any point:The exploitation phase of the game occurs when the player has more power than the risks they can encounter - the evasion phase of the game occurs when the opposite is true.

In reality, the both player power and risk change in step wise increments, and because resources can be lost as well as gained, it is not necessarily a consistently upwards progression. And most roguelikes have a combination of attacks by monsters which can only be avoided by the player having specific resources to resist these attacks. This complicates the picture, because at any point there is a multi-variable level of risk depending on the player's location, and known and unknown threats in the region the player is located.

The key player skill then becomes recognising when the player is in an exploitable situation and taking advantage of the opportunity to collect useful resources, versus an evasion situation, where the player should continue moving and avoid any imminent threats. This reaches a logical conclusion through the what is known in Angband as diving, where a player descends as quickly as possible through the dungeon, stopping only when exploits obviously present themselves - a technique very similar to speed running non-procedurally generated games. This works in Angband because the rewards deeper in the dungeon are progressively more valuable than earlier in the game and so it is always worthwhile going deeper even as the risks escalate. Similar behaviour occurs in Left4Dead, where quickly running through a level is almost always a more effective technique than going out of the way to find the limited additional resources hidden on the map.

On the face of it, exploiting is grinding like behaviour: techniques from Angband such as worm farming to quickly gain experience through killing a self-replicating monster strongly resemble grinding monsters for experience in MMORPGs. But what distinguishes exploiting from grinding is two-fold: limitation of exploitable resources and permadeath. Grinding in a game with permadeath still has an element of risk - that of dying through boredom or statistical happenstance. At any point in time, there should be a non-zero chance that the player will die, and lose all the effort accumulated through relatively safe resource accumulation. More importantly, any time spent grinding at an early phase of the game, is time wasted not playing at the maximum level of reward vs. risk later in the game.

This is a design balancing act: the player must be made aware that progression escalates reward as well as risk, as well as ensuring that the player is never able to accumulate all the necessary resources required to win the game through grinding. The balance in Angband is maintained by preventing the player from grinding unlimited resources for equipment, and ensuring that a player with maximum experience but no equipment will quickly die. (This is not quite true: the technique of stair scumming allows equipment grinding, but an honour system encourages the Angband community not to take advantage of this.) The use of explicit timers, such as food in Rogue, and the ghost in Spelunky, can also ensure that the player is pushed onwards instead of grinding any exploitable situation they find.

Permadeath adds another interesting facet of the exploitation vs. evasion and progression vs. grinding balance. Provided progression through the game brings greater rewards, and the player is able to evade threats at the current level of risk, there is no incentive not to progress to a higher risk area. The rewards are comparatively higher for same the time investment in the game, and the increased risk will either be successfully evaded or result in permadeath, which is the most time efficient way of highlighting the player has judged the level of risk incorrectly. So the design incentive appears to be to be to allow the player to progress through the game relatively easily, stopping off at points determined by the player to acquire the resources needed to survive at all in the next region of escalated risk. In Angband, this is summarised ironically as:

1. Visit general store
2. Buy Lantern
3. Kill Morgoth

because of the lack of fix requirements to complete the game.

Randomized levels require some form of grinding be present in order to guarantee the game is winnable. This is because the player may experience either a resource poor series of levels or a string of bad luck which depletes a high level of resource, through no fault of their own. The extent to which grinding allows the player to alleviate this bad luck is another design decision. It may be that some games are unwinnable is a viable choice here. At the same time, emergent game play through object interaction maximises the chance the player will have some resource available to counter any randomized situation that they find themselves in.

Primal Instincts

At any point in time, the player is faced with the decision of fight or run. This is answered by a careful weighing of the odds, what resources does the player currently have, what is known about those resources, and what threats are known and unknown. Information becomes a precious commodity in a game with randomized levels, and permadeath is used during the learning phase of the game to provide a final lesson in determining if the player understands all the variables of every situation they find themselves in. Once the player understands the game well enough to win it, permadeath is a final backstop to the ever tightening vice between progression and risk, one technique of ensuring that the player does not endlessly loop in a grind.

The question becomes, is this process of learning worthwhile? Is an intuitive understanding of multivariate analysis over a complex risk topology subsumed into a flight or fight instinct something worth playing? Whether this is true is beyond the scope of this article, but I would argue that this skill is something that makes us human.

John Harris is now taking mental steroids

Two articles in as many days. I nearly fell off my chair.

An @Play article on Nethack variants. Including some other game which features Un in the title.

And a well-received Game Design Essentials column on role-playing games.

Pathfinding Collaboration

For those of you obsessed with A* pathfinding, you'll appreciate the cold water poured on the idea this thread on rec.games.roguelike.development. And then take yourself straight to this collabourative diffusion example before you get obsessed by the trap of perfect pathfinding.

A rebalanced list of weapons for Unangband

No wonder everyone in Angband starts out wielding daggers. They are freakishly good.

Values that have been modified are in red (I've also hand modified the table after the fact, so a couple of calculations may be out):

Weapons
Description	Dam/AC	Wgt	Lev	Cost Info	Average Damage	Damage per wgt
Broken Dagger	1d1	0.5	0	1	1	2
Shovel	1d2	6	1	10	1.5	0.25
Gnomish Shovel	1d2	6	10	100	1.5	0.25
Broken Sword	1d2	3	0	2	1.5	0.5
Orcish Pick	1d3	18	15	300	2	0.111111111
Pick	1d3	15	5	50	2	0.133333333
Dwarven Shovel	1d3	12	20	200	2	0.166666667
Dart	1d3	1	0	10	2	2
Dwarven Pick	1d4	20	25	600	2.5	0.125
Whip	1d4	3	1	10	2.5	0.833333333
Dagger	1d4	1.2	0	15	2.5	2.083333333
Main Gauche	1d5	3	3	25	3	1
Javelin	1d6	5	5	36	3.5	0.7
Hatchet	1d6	4	3	30	3.5	0.875
Small Sword	1d6	3.5	5	48	3.5	1
Rapier	1d6	3	5	42	3.5	1.166666667
Spiked Club	1d7	13	1	10	4	0.307692308
Cutlass	1d7	5	5	35	4	0.8
Spear	1d7	7	0	30	4	0.571428571
Short Sword	1d7	4	5	60	4	1
Throwing Axe	2d3	2.5	30	80	4	1.6
Mattock	1d8	25	30	700	4.5	0.18
Awl-Pike	1d8	16	5	35	4.5	0.28125
Harpoon	1d8	6	5	120	4.5	0.75
Sabre	1d8	5	5	50	4.5	0.9
Ball-and-Chain	2d4	15	5	45	5	0.333333333
Quarterstaff	1d9	7.5	5	200	5	0.666666667
Mace	2d4	6	5	65	5	0.833333333
Throwing Hammer	2d4	3	40	125	5	1.666666667
Sacrificial Dagger	2d4	3.6	20	1000	5	1.388888889
Broad Sword	2d5	7.5	10	255	6	0.8
Long Sword	2d5	6.5	10	300	6	0.923076923
Glaive	2d6	19	15	363	7	0.368421053
Lucerne Hammer	3d4	12	5	180	7.5	0.625
Bastard Sword	3d4	9	10	350	7.5	0.833333333
Katana	3d4	6	20	400	7.5	1.25
War Hammer	4d3	9	10	225	8	0.888888889
Two-Handed Spear	2d8	20	10	230	9	0.45
Pike	3d5	16	10	120	9	0.5625
Broad Axe	3d5	12	10	304	9	0.75
Scimitar	3d5	10.5	10	250	9	0.857142857
Lead-Filled Mace	4d4	18	15	502	10	0.555555556
Trident	3d3	14	5	75	10	0.428571429
Scythe	5d3	12.5	15	400	10	0.8
Flail	2d9	12	15	353	10	0.833333333
Two-Handed Mace	4d4	12	15	450	10	0.833333333
Two-Handed Sword	3d6	12	20	775	10.5	0.875
Executioner's Sword	4d5	19.5	20	850	12	0.615384615
Halberd	4d5	19	20	430	12	0.631578947
Morning Star	6d3	15	20	396	12	0.8
Battle Axe	3d8	17	20	334	13.5	0.794117647
Great Axe	4d6	23	25	500	14	0.608695652
Beaked Axe	4d6	18	25	408	14	0.777777778
Two-Handed Flail	3d9	28	25	590	15	0.535714286
Executioner's Axe	4d8	25	25	750	18	0.72
Blade of Chaos	6d5	18	50	4000	18	1
Scythe of Slicing	8d4	25	45	3500	20	0.8
Mace of Disruption	5d8	40	55	8700	22.5	0.5625
Lance	3d8	33	25	460	18	0.818181818

The Movement Project

A big part of the frustration of Far Cry 2's movement problems I mentioned yesterday, is that these problems have been solved in other games. It's not like FC2 is the first first person shooter invented which has tree roots. But at the same time, the problems I experienced are a worrying indication that first person shooters featuring procedurally generated, wide open spaces, are going to have issues with movement when the terrain isn't smoothed out by a human hand.

Movement in military themed first person shooters is, as far as I am concerned, a solved problem. There is an excellent article series Dslyecxi's Tactical Gaming Done Right (warning: hours of reading at this link) describing exactly what movement grammar a military FPS should include, the main trade off being the time required to implement these movements. But instead first person shooters seem stuck in the WASD jump crouch moves of yore.

I would like to propose a partial solution to the mess of FPS designs: a military themed first person shooter movement standard, which describes a standardised grammar of moves that a first person game which matches the standard must support. There would ideally be a reference implementation in a number of the current engines (Source, Unreal etc), but this is not necessary to start with.

The important part would be the branding, so there would be a sales and marketing advantage to publishers in adhering to the standard, and so that you, the consumer, could quickly check that the game complied.

There will be an inevitable trade off between what features the game must support, against what are optional features - while a rush to the lowest standard is probably inevitable, the benefit in having a standardised design document to which the major companies to reference, as well as would be FPS designers learn from, should hopefully improve the current state of affairs.

Another aspect is reviewer education: and I'd be interested to hear from any game reviewers whether this would be of help. Even pointing game review sites at Dslyecxi's article series on a regular basis would be beneficial to start with.

The argument against this, is that the grammar of movement forms an important part of the game play, and well-written games should have a unique feel for the avatar's movement. I don't disagree, but note that, for instance, I can quickly slip into Valve's source engine games because of the common movement core between games, before having to learn about the exceptions. And this is not necessarily targetted at well written games - Far Cry 2 being a case in point, where care and attention has been paid to parts of the game other than movement, and where (I suspect) a reference to design against may have helped in this instance.

Thoughts?

Speaking at linux.conf.au on 'The Linux Gooey'

If you're in Hobart on January 20th, 2009, you'll be able to drop by and hear me speak at the 2009 linux.conf.au Gaming Miniconf. I'll be talking about the Linux Gooey - why Linux needs a Game Maker and the evolving language of games.

You can see the full days schedule here; you will need to get tickets to attend the miniconf.

Welsh rarebit

When I was fourteen, I learned to touch type - on a type writer. You may not be familiar with these: imagine a keyboard, but when you type, your key press directly moves a mechanical arm which strikes a sheet of paper through an ink covered ribbon, leaving an ink covered impression on the paper. The paper is moved through the feed, like a printer, but only one character at a time, and when you press the enter key, the sheet of paper moves up a line. And get this: there is no screen.

(Kids these days. Also adults, these days, feeling like they have to explain stuff to kids these days.)

The important thing to remember is that typing was an optional skill. Only secretaries needed to type - senior management would dictate information to them either directly, or by recording it on tape and having the secretary play it back and transcribe from this. This was back when the work force was still divided into higher paying and lower paying positions, mostly on whether you were male or female, and my school, despite being a liberal bastion which a few years later elected to have male and female co-principals, still divided the classes up into electives for typing, home economics, woodwork and technical drawing.

What was different to many other schools, is each of these optional electives was not optional. Every fourteen year old who attended my college studied all four 'electives' throughout their second year. This drove my father wild.

He could understand how woodwork and technical drawing could be useful - and he'd had to suffer enough through me making Welsh rarebit to realise that home economics aka cooking would be useful to me later in life and him immediately. But typing. In no conceivable future of his could he see how typing could be a useful skill - this coming from a man whose bookshelves are bowed with Asimov, Clarke and Heinlein. He complained vocally to the school, tried to withdraw me from typing class for more mathematics, and generally made a nuisance of himself to my teachers. Nonetheless, I enjoyed it, even excelled at it, and it was only two hours a week for three months of my academic career.

I've always wondered at the utility of game competitions - where you are given an inspiration, genre or platform to develop within a limited timeframe. My problem is not coming up with the ideas or making the time to code - it is limiting the output of my ideas to manageable chunks. I find programming easiest when I'm working under a tight set of restrictions: say, catching the train to work where I'll be seated for about 30 minutes, developing Unangband in Eclipse. And it's this realisation that helps me understand what is important about the competitions: it's not the starting that is important, it's the limiting yourself - knowing when to finish.

The delightfully detailled specifications that Dan Cook provides over at the Lost Garden are the pinnacle of this theory of game competition design: his Fishing Girl prototype provides concrete descriptions of every game mechanic, as well as the art assets so that all you have to do is develop the implementation from this design, and then tune how the game plays.

The devil is in the detail - how the implementation work, how it feels, how it plays.

Dan is an impartial critic. You get a gold medal if you can convince him to play your game for 15 minutes. And he's never handed one out. Until now.

What makes this especially significant for me is one detail that is often overlooked when designing games: the quality of the art that Dan provides. It was a little known fact that I started working as a graphic designer before changing jobs to the IT industry. I didn't have a skill that is surprisingly easy to avoid as a graphic designer starting out: I can't draw.

Because of this I knew I could do an adequate job, but I could never be good, let alone great, without this essential skill. I could have invested the time learning, but I did have a set of skills that I could use immediately, and information technology was the place that I could progress far more quickly.

Art, or more importantly, the representation of information visually, is a critical component in game play. It is something roguelikes do so well - a topic I'll explore more another time - despite not having any art assets per se. But allowing the player to understand complex information visually at a glance is key to developing a great game, and why Dan Cook's game competitions are so useful to help you understand game design.

Not many programmers are artists, which is why you see David Gervais' tile sets used over and over in roguelikes, and why free, re-usable art assets are so critically important to the development of an open source game community. I don't ever see the ability to draw, to divide space in pleasing, aesthetic, information rich segments separated, enclosed, captured by lines becoming redundant.

A few years ago, my father confessed to me that typing was perhaps the best thing that I ever did in school. And that's why I'll be encouraging my children to draw - a skill I never made the time for.

A method for implementing player-crewed sailing vessels in ASCII roguelikes

Another feature of the region code I’m developing is that it will allow me to implement moving platforms in Unangband. A platform overwrites the existing terrain with a new terrain type (say ‘wooden deck’) and records the old terrain type within the region code (a single scalar value can be stored for each grid in a region – this will record the terrain type originally underneath).

Then, when the platform moves, we rewrite the old terrain, translate the platform region one grid, and then overwrite the terrain in the destination location with the platform terrain type; recording the original terrain in the region data structure. It is important for this discussion to realise that we can’t stack multiple terrain types: each grid can have only one type of terrain.
Impassable terrain, monsters and objects complicate the algorithm. Impassable terrain is defined as any terrain through which the platform cannot pass. I’m still deciding how to define this flexibly: I suspect I’ll have a number of different platform types, capable of moving over floors, chasms, water, lava and so on – each of which is currently represented by a flag in the terrain data type.

To determine if the platform is going to move into impassable terrain, we’ll simply make a copy of it, translate it, and then fail to move the platform if the translated copy intersects any terrain it is not permitted to exist on.

For monsters (and the player), if they are standing on the platform, they’ll be translated along with the platform. If they are in the path of the platform, and capable of standing on the platform terrain, they’ll stay in their existing location (effectively stepping onto the platform as it moves over them); otherwise they’ll be pushed into an adjacent grid which is neither in the current platform location, or any grid of the translated copy.

Objects on the platform always move with it, if they are in the path of the platform they are always pushed: if no grid exists which the object can be pushed to, it is destroyed.

How do we get platforms to move in the first place? The fallback for many games is to have the platforms moving independently on a fixed path, and allow the player to jump on and off the platform at will. But this will massively complicate the level design – it may still be useful, but I have a smarter idea.

A key component of roguelike design is the ‘bump’ – that is allowing the player to interact with the game world by the process of attempting to move into it.

I’ll extend the concept of the bump to that of pushing. An terrain feature is push can be pushed by the player by having the player attempt to walk into a normally impassable piece of terrain, and the terrain feature is moved to an adjacent grid, allowing the player to pass. This process of moving requires that we make certain assumptions about what the underlying terrain is: for normally pushable terrain, we assume that the underlying terrain is an empty floor grid. In this instance, we can push terrain around as follows:

1. Choose an empty floor grid adjacent to the pushed terrain – first in the same direction as the player attempted to move, and then check another adjacent grid, alternating clockwise and counter-clockwise from the first grid considered.
2. If an empty floor grid is found, overwrite this grid with the terrain type.
3. Overwrite the pushed grid with empty floor terrain.
4. Move monsters, objects as described for moving platforms.
5. Allow the player to move into the now empty grid.

To handle recovering pushable terrain from impassable dead ends, we could potentially let the player stand on the terrain and push ‘downwards’, choosing a random direction as a result, or have a separate ‘pull’ command, which allows the player to specify a direction for any adjacent ‘pushable’ object to move.

By combining platforms, and this concept of pushing, I can allow the player to push platforms around by defining a second region which contains ‘pushable hotspots’ (shown on the irregularly shaped platform to the left as '*' symbols) that, instead of just pushing a single grid, moves the entire platform in the direction the player specifies.

In this instance, I have to specifically link multiple regions together. But I have to do that anyway, to handle the instance where I might have multiple intersecting platforms. Consider the case where a platform of ice is created over a wooden platform. The wooden platform stores the underlying terrain types in it’s data structure; the ice platform stores only those regions which don’t intersect the wooden platform, for the rest it stores the fact that there is a wooden platform terrain type under it.

If the wooden platform moves, I’ll suddenly overwrite parts of the ice platform. So I have to come up with an algorithm to allow both platforms to correctly move over each other. If I have to worry about this special case anyway, I can readily enough include the code to move both platforms at the same time if they are linked together.

I can even get trickier, and demand that my pushable hotspot(s) have more strict requirements for what terrain they sit on than the rest of the platform. Consider a wooden platform that is held up by a chain over a chasm. I want to allow the platform part to exist anywhere in the chasm, but the part that is connected to a chain to only move on terrain that has the chain in it.

So I make this part the pushable hotspot, and apply the more stringent requirement to the pushable region.

This is where things start to get interesting: up until now I’ve assumed that a platform is built of a single terrain type – plus a second for the pushable regions. But I could equally build a platform from an ASCII template and have a mix of terrain types, pushable regions and grids which expose the underlying terrain. And this lets me implement vehicles: like sailing ships, but drawing the ASCII template onto the map at the vessel location. Bear with me as we look at some ASCII art:

This sturdy rowboat has two pushable regions: the oars. I mark these regions ‘reversed’ so that by pushing at the oars (‘*’), you go in the opposite direction to that you pushed. By sitting between the oars you can steer the boat left and right, sitting in the prow you can propel the boat forwards.

This large galley is filled with the undead spirits of sailors. By beating on the drums (‘*’) you cause the undead on that side of the galley to row – again in the reverse direction to your beat. The large deck will lead to much combat and looting of treasure.









This sailboat has a single sail (‘<’) that you can push to slowly propel the boat along - ideally you need a gust of wind, perhaps from a spell, to move quicker. By pushing at the boom (‘'’) you can reflect the way the template is laid out, causing the sail to swing to the other side of the boat.

The complication with the templates, is that I need to be able to rotate the templates as well as translate them. I need a robust design to handle this – but using the Angband project_path function should allow me to rotate the vertical strips of the template to any angle of a fixed length. Although a flight of fancy at this stage, there is the real possibility that in a future version of Unangband, you’ll be able to take to the sea and avast the land lubbers in other roguelikes.