For any of you who enjoyed the recent series on the Unangband Monster AI, and wanted further reading on how AI has been implemented in various games, have a look at gameai.com. It has an excellent overview of various AI algorithms and how they are applied to 'current' games.

I use the quotes, because the site still uses frames and the games section doesn't look like it has been updated in a little while. Nonetheless still worth a read.

Thursday, 29 November 2007

In the spirit of everyone else doing '20 game clichés we thought we'd repeat for you' lists at the moment, I've written a 20 under-used game mechanics list that'll hopefully at least give you some game design suggestions. No pictures - I don't want to pad out the reading time unnecessarily. Feel free to digg this, irregardless of that fact.

1. Asymmetric Co-op: The game has a playable co-op mode, but the second player has different abilities from the first. Whether it's collecting star fragments, shooting colour drops or rising out of the ground to bust heads, allowing a second player to drop in for some lighter entertainment without needing the l33t skillz of the main gamer in the room is a sure-fire winner.

Idea from: Wizball. Druid. Super Mario Galaxy.

2. Bad-Ass Boss Fight: You want to know how tough the bad guy is? Play as him, before you fight him. Then you can really justify your inability to beat him.

Idea from: Marvel Nemesis: The Rise of the Imperfects.

3. Design Your Own: Design the dungeon, then play through it. You can't blame anyone else for the problems with the architecture.

4. Not Re-Using Mini-bosses: You've all had those games when you get to the mini-boss, and have to pull out the stops to beat them. Then, on the next level, the same mini-boss is back. Multiple times. The idea is as old as Ghosts'n'Goblins. Well here's another idea. Don't.

5. Letting You Fight Fights You're Intended to Lose: You've been betrayed by Athena and shrunk back from god-like dimensions to normal size. Then Zeus sucks the rest of your power out of you by tricking you into channelling it into a sword. You're left weak and bleeding, unable to even move faster than a stagger. And still you have to fight.

6. Interactive Cut-Scenes (But not Quick Time Events): If you're going to be stuck in cut-scenes telling part of the story, you may as well make them interactive. And I'm not talking about hiding unimplemented game-play behind a Quick Time Event - I'm talking about looking down Eva's top in Metal Gear Solid 3, or completely changing the outcome of the final cut scene in Soul Calibur.

Idea from: Soul Calibur.

7. Breaking the Fourth Wall: Whether it was showing you the Game Over screen prematurely, or telling you that you've been playing long enough, there's not enough games that break the fourth wall and talk to you the player, as opposed to the character you're playing. Or for that matter, deceive gamers about which character they'll end up playing.

8. Moving the Controller: And if there was one way to really break the fourth wall, it was for a computer game to reach out and cause your controller to move without you touching it. A heart-stopping moment for many a game-player. Not enough games make you look on the jewel case for clues these days either.

9. Upwards Preference: Get the player to look up early in the game. Use it to figure out whether they prefer regular or inverted mouse-look. It's not a hard thing to do. So why do so few games do it? (I know this is an Xbox console setting now. Hiding the option elsewhere in the user interface still doesn't solve it though.)Idea from: King Kong.10. Vengeance is Mine: First you sneak past them, then you kill them. It could be a Tyrannosaurus Rex in King Kong, or a gang of Outlaws in Call of Juarez. The opportunity to turn the tables and lay the smack down is not one to be missed.

11. Seeing the Consequences: Re-encountering the same scene as from a different point of view suddenly gives you a whole new perspective on events. Half-Life gives you the opportunity to go back to the Xen teleport chamber in both expansions, while Fahrenheit and Call of Juarez allow you to see the same scenes as both the pursued and the pursuers.

Idea from: Fahrenheit. Who raved about it: Michael Filby from Jolt.co.uk.12. Setting the Environment on Fire: Sure, physics engines are great. And destructible environments will be 'teh next-gen' as soon as they catch technology up with the likes of X-Com. And you can set fire to enemies in lots of games. But nothing goes better with marshmallows than watching half a hillside go up in smoke from a single match. Games should bring the pyromaniac out in all of us. There needs to be more first-person shooters in burning buildings as well.

13. Playing with Scale: There's nothing quite like scaling tall buildings, crushing people beneath your feet and watching the screaming multitudes fleeing in front of you. Psychonauts? King Kong? Katamari Darmacy? The end of God of War? Pick one - they're all good at it. The re-use of the sword level in God of War is a particular standout - arguably one of the best level designs ever.

14. Better Level Themes: You've played games with the lava level. The ice level. The sewer level. Well how about a game with the Milkman level? The disco level. The Escher level. The Meat Circus level. Welcome to Psychonauts.

15. Designing the Level to Let You Use Your Toys: Bridge littered with the debris of cars moved into make-shift blockades. Check. Concrete barriers behind which terrorists are cowering. Check. An M203 grenade launcher and enough ammunition to take all of them out. Check. Survival horrors and low ammunition be damned. If you give me something shiny, I want to be able to play with it to my hearts content. Shame on those games that give you sniper rifles without suitable draw distances, or rocket launchers in twisty corridors.

16. Adding Things to Photographs: The photograph collection mechanic has been used well - arguably over-used in some games. But the photographs tend to turn up - well, just like you took them. What you really want is a game where the photos you take, and the resulting pictures have disparate elements - ghosts in the background, missing objects, weird aliens like in They Live. It could be a whole mechanic in itself, but sadly, just a nice Easter egg in the example below.

Idea from: Metal Gear Solid 2.

17. Economy of Design: Stop using a game-mechanic when it stops being interesting. We've played with the toys - it's time to put them back in the pram and move on. The whole of Portal is an exercise in economy of design - once you've learnt how to do something, you're only ever asked a few times to expand on it. I mean, the weighted companion cube appears on one freakin' level and already has its own fan clubs. So is some of the mechanics in Half-Life 2 - in particular the pheropod.

Idea from: PortalWho raved about it: Every game journalist this year.

18. Annotating Maps: The in-game map - an abused and reviled mechanic if there ever was one. The only way to pep it up is to let you draw on it like you used to as a kid. And if you're really lucky, mum will let you put it in the oven afterwards so it can curl up and look, like, really old...

19. Telling the End of the Story First: Kratos stands at the edge of a cliff. He is heavy with despair. He slumps forward, taking a final step and tumbling into the abyss towards the rocks below. Sure, they cheated in the end with a deus ex machina. But you want to find out how such a kick-ass character wanted to top himself. Hell, build a game where you're forced to fail a scenario, go back three years earlier, and then have to replay the events, with additional information that'll help you beat it the second time around.

20. Falling Action / Playable Denouement: You've saved the world. Just seen the biggest explosion ever. Fled out of the castle as it crumbles around you. And the credits roll. Well, howabout for once, let you actually enjoy the moment. Kratos gets to run up to the steps to Mount Olympus. Call of Duty 4 goes all slow-mo on you. Grand Theft Auto - well, it never gets dull.

While we're at it, every so often one of the game blogs I read discovers the 300 Game Mechanics website, and trumpets it as a great set of ideas - which it is. The latest was Raph Koster, last week it was Rock, Paper, Shotgun. Unfortunately, the designer, Sean Howard, stopped at number 59, for various reasons.

[Edit: He actually appears to have restarted. The original challenge was one a day, and he's eased the pace. Some good analysis of the pros and cons of procedural generation of content round these off].

Ironband release 1 is out (actually a few days ago now). I don't normally announce Angband variant or roguelike releases. There's a couple of other places that track them better (Rogue Basin, rec.games.roguelike.announce, and Temple of the Roguelike has started to as well), and I'm working on the competition.

The reason I'm talking about this release, is that I've mentioned Ironband on this blog before. And I've also argued for one of its central mechanics: getting rid of classes and skills. That's right. Ironband has neither. How does it work? Well, you'll have to download it to find out.

Announcement (via angband.oook.cz's looking glass), source, windows. Once you start playing, you can compare your progress to other people on the Ironband ladder hosted at angband.oook.cz. Looks like there's already a winning character up there.

I've added graphics to part five of the Unangband Dungeon generation series of articles. These illustrate the various room types in the game. Even if you've read the article, I highly recommend going back and having a look.

Tuesday, 27 November 2007

(If you haven't been following this series of articles, you'll probably want to start with parts one, two, three and four).

If the room is too small a design element to properly handle delivery of monsters to the player, then it turns out that the level is too large. Actually, I'm getting ahead of myself here. What I mean by design elements, are the different elements that make up the Unangband dungeon generation, beyond placement of the individual entities (monsters, objects, traps and grid features). It is worthwhile introducing the design elements that I've added and changed in Unangband, in order to provide a framework around which the mechanism of 'delivering enemies to the player in an meaningful and consistent fashion' is hung.

1. Room Types

Room types were mentioned briefly in part four, and consist of different sets of algorithms for placing the edges and contents of a room on the map. Effectively, the room layouts are 'drawn' in different ways, depending on the algorithm selected. This is subdivided into normal sized, large sized and huge sized rooms - with larger rooms appearing deeper in the dungeon, and using up more of the total room count allowed on a level.

Most of the room types listed here are not unique to Unangband, but have been implemented first in other variants and copied into the Unangband code-base. The code in the original location is usually easier to understand and I recommend you refer to the generate.c file for each of the mentioned variants in the first instance to see the algorithm in more detail.

Lakes: large, huge

Lakes are placed ahead of any other room type, and can be overlapped by other rooms and each other. They are drawn using the starburst algorithm (see below), but are completely filled with a 'lake' terrain.

Waypoints

These are rooms that consistent of a 1x1 square, effectively providing a point of intersection for tunnels.

Overlapping rooms: normal, large and huge

These are the 'basic' room type in Unangband, and are created by selecting two random rectangles within the a larger rectangular space. Simple rectangular rooms occur when one of the rectangles is completely enclosed by the other. Rooms similar to Angband's cross-shaped rooms occur when the rectangles are identical when reflected by a mirror at 45º. A bias towards symmetry encourages more frequent cross-shaped rooms than otherwise expected.

Fig 1a: Examples of overlapping rooms (featuring a fountain in the north of the room)

Fig 1b: Examples of overlapping rooms (featuring a pile of feathers in the centre of the room)

Fig 2c: Examples of starburst rooms (featuring an object strewn midden in the centre of the room)

Fractal rooms: normal, large and huge

Fractal rooms are generated using Diego Gonzalez's fractal cave algorithm from NPPAngband. They are generated by using recursively selecting from a list of fractal templates, including 'pools' of terrain. Connectivity between all 'floor' and 'pool' squares is guaranteed or the generated fractal is rejected and tried again.

Fig 3b: Examples of fractal rooms (featuring a blood-stained altar in the centre of the room)

Fig 3c: Examples of fractal rooms (featuring a wet floor)

Maze rooms: normal, large and huge

Maze rooms are generated using a heavily modified version of Eric Bock's maze algorithm from Sangband, which generates acyclic or 'perfect' mazes from a passage carving algorithm (See Think Labyrinth for an explanation of maze terminology and an excellent overview of mazes). The modifications in Unangband attempt to match the maze design to the tunnel types allowed for the level (see below).

Multiple adjacent rooms either connected to each other by common doors or short tunnels. These are built from Leon Marrick's chambers algorithm in Sangband. Chamber complexes are filled with many monsters.

Fig 5: Example of chambers (click to enlarge).

Lairs

A lair is a set of chambers, surrounding by a lake of a particular terrain feature (with a guaranteed moat around the edge of the chambers). The lair then contains a unique monster or other set of monsters.

Vaults: lesser, greater and 'interesting rooms'

Rooms built from a text template, as discussed in part two. Currently vaults are generated using the Angband algorithm, but I will be moving to Sangband's implementation, after adjusting the Unangband tunnelling algorithm to handle width 2 walls.

Towers

Towers are handled as a special case of the vault algorithm, although they are 'ascended' as opposed to 'descended'. Towers about the surface are surrounded by open air.

Note that Unangband does not have the monster pits or nests that many other variants do.

2. Room Descriptions

Complementing the room types is a room description mechanism. I wanted each room to be uniquely distinguished by a passage of text that the player could read when they first entered the room, if it was lit, or when they successfully lit the room with a light spell.

The text passages are built up by using Markov chains of sentence fragments (actually not strict Markov chains, as the system supports conditionals), which also add trap, objects, monsters or terrain features to the room, which are defined in room.txt.

The first line says 'in state 152, transition to state 107 if this entry is selected, with a 25% chance of picking this entry normally (minimum 1% chance), between dungeon depths 1 to 128'. Entries 3 and 4 on the N: line act as a conditional 'if you got to state 3 after choosing this entry, transition to state 4 instead'. The A: and B: lines help provide the room name, built from an adjective (A:) and noun (B:), where the first word in encountered in the chain is used. The D: line gives the sentence fragment. The F: line provides information about features - in this case feature 2 (invisible trap) is placed around the room, which when a trap is selected turns into traps like feature 77 (trip wire).

The R: and G: lines (not shown) control the monster race flags and monster graphic char for monsters in the room. The K: line (not shown) control the item kinds that are placed in the room. The L: line (not shown) controls what levels the terrain appears on - if the level has a matching level flag, the higher percentage on the N: line is used; if the level does not have the matching flag, the lower percentage is used.

The S:SEEN flag indicates that the sentence fragment is part of the description when the room is lit and the player can see it. Descriptions can be displayed if the room is entered without being seen, consisting of tactile and auditory information, temperature and so on. It is also possible to have textual information such as writing which depends on the player understanding the language of the room inhabitants, using S:LANGUAGE.

And most importantly, the P: line controls the placement of the entities around the room. What I refer to as 'room descriptions v1', the room description would say 'In the west of the room' and the objects, traps etc. would be placed anywhere in the room. Not until version 0.6.2, did I successfully get the code to place these in the west of the room, and only for the overlapping room types. As a result, the other room types have restrictions on which room.txt entries can be chosen, based on the P: flags.

In this instance, the P: flag says now place all the entities which we have accumulated up until now, using a maze pattern, where the features form the walls of the maze. This could be ignored, if the room size is too small to support drawing a maze in it, and the features will just be scattered around instead. The fact there is an explicit 'PLACE' flag allows the separation of where and how in the room, from the what in the room, which allows much more flexibility in how room.txt entries can be combined.

3. Tunnel Types

I wanted more variety in the tunnel types that could be selected. In particular, I explicitly allow width 2 and width 3 tunnels, with support for pillars running down the centre or edges of these tunnels. In addition, I provided some persistent tunnel parameters, such as frequency of changing direction, so that the tunnels could appear to be very cave-like, or have inconsistent or consistent width and pillars over the course of the tunnel.

Tunnels can also support various decorations, such as a central pool running along the middle of a width 3 corridor, or one edge of a width 2 corridor. Other tunnels have decorations, such as torches, wooden supports or windows that appear with varying frequency along the length of the tunnel, and usually at dead ends. The nature of these decorations is determined by the room descriptions of the rooms at either end of the tunnel. The 'solid' walls at each end of the tunnel (see part two) will be turned into other terrain as well, if certain room descriptions are picked.

The basic tunnel path logic is from Sangband, although I haven't adopted all of its features yet. However, due to the presence of width 2 and width 3 tunnels, the Unangband tunnel generation has to be a lot more careful in ensuring that only the minimum number of tunnels are generated, lest the dungeon start to resemble swiss cheese. The tunnel algorithm also has to take account of lakes of terrain through which a tunnel can pass, without necessarily terminating in the terrain.

This complicated the algorithm enormously. Tunnels in Unangband either bridge or tunnel terrain, with bridges being narrower and bridge-like. The rooms are divided into partitions, initially one per room, and combined as the tunnels connect separate partitions. Tunnels are aborted if they intersect a destination room of the same partition as the source room, and as a result the source and destination selection algorithm starts very strict, to maximise the chance of connecting nearby rooms together, and ends up very permissive, and then desperately random, to try to connect any room to any other room, in the event of being unable to merge all partitions through connectivity.

4. Level Theme or 'architecture'

A problem with older versions of Zangband, was that the large number of room types in that variant could be thrown together in any mix, resulting in weird architectural combinations. I wanted to avoid that, which resulted in the decision to tie room types together at a higher level, using a level theme. The level theme is based on the first room type placed on the level, which is selected using the Sangband process of trying the largest, and therefore hardest to place, room types first, and then progressively smaller. The theme then restricts subsequent room types to only those consistent with the level theme.

Luckily, the room types, room descriptions and tunnel types conspired to form some consistent 'architectural patterns'. The following level themes are generated in Unangband.

Dungeons - dungeons are the most permissive and allow most room and tunnel typesStronghold - large and huge overlapping rooms, width 2 tunnels without pillars and width 3 tunnels with central pillars, tunnel shape consistent for length of the tunnelCrypt - pillar filled overlapping rooms with features on the edges of the room, width 2 and 3 tunnels with pillars on the edge of the tunnel, tunnel shape consistent for length of the tunnelMine - mix of fractal and smaller overlapping rooms without features and waypoints, width 1 tunnels that do not change direction oftenCave - mix of fractal and starburst rooms, width 1 tunnels that change direction highly frequentlyWild - large or huge lakes, no fractal or starburst rooms, the rest allowed as they look like buildings in the wilderness, width 1 tunnels that change direction moderately frequentlyLabyrinth - mix of various size mazes, some labyrinth levels mix in stronghold, crypt or cave level theme and make the mazes look like tunnels from that level themeSewers - large or huge starbursts, large or huge overlapping rooms with features in the centre of the room (which tends to be a pool), tunnels width 2 or 3 with a central 'pool' running down the tunnel, tunnel shape changes throughout the length of the tunnel

In addition, Vault and Chamber level themes are used to control the occurrence of other room types with these two room types, but may be deprecated at some point.

5. Terrain Features

There are enough terrain features in Unangband that they deserve a separate article in themselves (part five). But I'll at least discuss how they impact on the other design elements in this section.

Firstly, a percentage of dungeon levels are generated with a lake or river feature running through them. This could also be forced by the dungeon type that the character is exploring.

This may instead result in some 'flooded dungeons'. Flooded dungeons are special in that up to a third of rooms are generated as flooded with a particular terrain feature. In the instance of fractals, starbursts and overlapping rooms, the terrain feature fills the room. But in the case of chambers, vaults and mazes, the terrain feature surrounds the room, just as lairs are surrounded by a lake / moat of terrain (mazes also have some dead-ends filled with the lake of terrain). These rooms are not treated as flooded for tunnelling purposes.

Flooded rooms connect to other flooded rooms with tunnels that are full of the flooding terrain, while non-flooded rooms are connected normally. This proved to be the most effective way of ensuring monsters restricted to the flooded terrain could navigate between rooms, while ensuring that the character could navigate to any room that proves more interesting. The centre of sewer tunnels will preferentially use the flooding terrain where possible.

The type of terrain flooding the dungeon then restricts what terrain is generated as pools in starburst and fractal room types, through the use of water, lava, acid etc. flags. These flags also influence room descriptions - the L: flag matches in the room.txt entries include these flags. In particular, this is used to select auditory, temperature and wind room descriptions, which are generated for virtually all room types, and have an increased prevalence for room floor contents. So an acid level will not only have acid-filled rooms, but the remaining rooms may have clouds of acidic vapours, acid-damaged walls and pools of acid in the centre of the room.

At the room description stage, a terrain is selected as the level theme terrain, separate from the flooding terrain - usually from the first terrain generated. This is used to bias the room description selections and can be used in various ways to ensure different room types tend to match together. For instance, all rooms containing human-usable equipment tend to have shelves around there edges and a shelf themed level will have rooms filled with potions, books, and so on. And as mentioned in the tunnel types, room features influence what is placed along the tunnels, as well as at either end.

6. Monster Ecologies

I decided as a part of considering levels as an expendable resource, that I could readily limit the list of monsters on the level, as a way of letting the player select what type of challenge they wanted to face.

I reasoned that monsters would exist in various ecologies in the dungeon - I wouldn't have to model the ecology, just provide a reasoned enough a selection of ancillary minions for a major monster type (called the seed monster), and limit the generated monsters to that collection. Luckily, the way of relating a monster and his minions already existed, in the form of escorts and summoned monsters. In order for a summoning spell to be successful, I'd have to include at least one of the candidate monsters in the ecology, and so I built the ecology selection routines on this basis. Where a monster didn't summon anything, I created a hack_ecology technique where I randomly chose members of the ecology from a subset of summoning spells (in particular, kin, animals, classes, groups, and so on) as if the monster had that spell.

This required some tuning, in the sense that I still wanted to populate vaults with as random a selection as possible, so had to ensure a reasonable maximum size and range of monsters, and find a suitable minimum (which turned out to be 4), in order to ensure sufficient variety in monsters on a level. The monster ecology model, once debugged, turned out to be very useful.

7. Dungeon Types

Finally, for those playing the Middle-Earth campaign in Unangband (by far one of its most popular features), you'll have discovered that each dungeon has a particular set of restrictions on monsters used as seed monsters for the ecology (or even a specific monster guardian on certain levels), and fills or floods the dungeon with various terrain types.

So other than influencing each other, how do these design elements successfully deliver monsters to the player in a consistent and interesting way?

I deliberately missed an important detail in the discussion of room descriptions, that is particularly relevant to this. In version 1 of the room descriptions, the room.txt entry details relating to monsters (R: and G: lines) were used to select monsters to place in the room.

But in version 2 of the room descriptions, the those details were used to restrict which room entry to pick. I had decided at this point that room descriptions were going to be key to telling the player what the most powerful monster on the level was. So in addition to building the ecology, I recorded the most powerful monster in it. Then I restricted the room descriptions, so that the higher percentage chance was used if the deepest monster matched the R: or G: line, and the lower percentage chance if that line existed in the entry, and it did not match this most powerful monster.

Suddenly I was able match room descriptions and monster properties. This meant I could relate thrones, checkered floors and weapon racks to warriors. And magic circles, magic books and magical lights to wizards. And altars, prayer books and candles to priests. And so on.

And it still provided to be a failure. Levels became boring - the features were too tied to monsters, most powerful monsters were evil, and the feature theming meant that most levels ended up being filled with bloody walls and bloody altars (the two being related).

I tried to analyze what I was doing wrong, messed with the frequencies and got nowhere.

So I played around with monster ecologies, and stumbled on the solution by accident.

What I did was split up the ecologies into sub-ecologies. Remember, each ecology was based on a single seed monster, and his minions. Well, it made sense to associate each seed monster with a separate sub-ecology. Seed monster one had sub-ecology one, with his minions filling out the rest of the sub-ecology. Seed monster two had sub-ecology two, with his minions as the rest of the members. In fact, sub-ecologies came directly from the fact I had to have a minimum number of different monsters on the level, to stop the level being boring.

So in order to split the sub-ecologies up, I decided a simple relationship. First ecology with first room placed, second with second room placed and so on. It made sense that the largest, hardest to place rooms got separate ecologies. And then when I ran out of ecologies, I just assigned ecologies to rooms based on the nearest room which did have an ecology. But I didn't want the seed to be wandering outside his 'base' room, so only his minions get generated in these ancillary rooms.

But what about the most powerful monster for each room. Well, lets use the most powerful monster for each sub-ecology. And I'll allow this to spread to the ancillary rooms, so some consistency holds between nearby rooms.

And something magical happened.

Levels started to be interesting again. Because over here, you had the laboratories where the potion-dropping slimes hung out. And then on the other side of the level, the war loving orcs kept their weapon racks and wargs in kennels.

What I had built was a modified room-based monster delivery system. It still had the core room descriptions telling you what the most powerful monster for the main room. But each room also had this hinterland of ancillary rooms, which also told you the most powerful monster - but didn't have that monster in it (there was a high correlation between most powerful monster and seed monster).

And the significant difference between that and the level model, is that you could walk through the transition of two different hinterlands. So you associated monsters and their hinterlands in a dynamic, spatially associative way that travelling up and down a level didn't tell you.

In this particular layout, you had a much greater chance of encountering the hinterland before the most powerful monster. In fact, weaker monsters also served as the advanced warning, in a manner of speaking. You'd fight through a whole lot of orcs, before getting to the orc chieftain who led them.

I was lucky in a sense, that many of the design elements I had worked on previously had fortuitously come together, not just for the 'architectural' layout of the level, but also its 'ecological' layout.

And while we're on the Google Reader tips section, if you were wondering which 100 blogs you should be reading, here's the list. With mathematical proofs.

Having gone through the part of the list, it appears more to be a 'here's a list of blogs that will mention this as a news item.' I'm not sure who benefits more here: the blogs, or Carnegie Mellon.

[Edit: This is 2006 data, so probably not a good list to base your evidence from. But with a good understanding of Cascade theory and some more up to date samples, I'm sure you can reproduce your own list.]

As a (part time) game designer, you give yourself a problem, and immediately start thinking about solutions.

So, as soon as I finished the article about games I've not finished, I started thinking about how to fix the damn problem.

Here's a suggestion: Checkpoint your game regularly, and have a set number of lives for each check point. Give out an achievement for reaching each checkpoint without using up all the lives - you don't even have to tell the player how many is enough.

If the player uses up the lives before reaching the next checkpoint, not only do you offer to reduce the difficulty level, like God of War does (and other games), but you offer the option to skip through to the next checkpoint, minus the achievement. You can even make them suffer through a cut scene to get them up to speed on what's happened in between. Because it's a self-evaluation system, players will have an idea 'how close' they were to overcoming whatever obstacle is slowing them down.

That way, people can play the game, overcoming the difficulty humps they may experience (which may be wildly different from one person to the next), while still rewarding people who have the skill and perseverance to play the game well.

[Edit: I think I've read this suggestion somewhere before. My apologies for not being able to site the original source].

Portal seems to have kicked off a bit of a renaissance of the discussion about game length. This mainly revolves around the fact that Portal is a bit short, but finishes before it outstays its welcome, unlike many other games.

I've got a fair sized game collection, mostly supplemented by buying back catalog games out from Amazon while I was in the UK, inspired by various discussions on Eurogamer. I picked up Psychonauts that way, before it came out on Steam. And Deus Ex, before it came out on Steam. And System Shock 2, before it came out on Steam. Did I mention I occasionally have a bit of a timing problem? (Does anyone know if it'll ever be possible to re-register your non-Valve games on Steam - I doubt it).

And while I initially dismissed the discussion, I've just been thinking about exactly which games I have finished, out of about the 60 or 70 titles I own (more than a few of which are still in shrink wrap).

Games I've FinishedHalf-Life 2PortalMetal Gear Solid 2: The Sons of Liberty - Alternated lives with a friend. Treated it like a movie night.Halo 2 - I'm actually not sure whether I've finished this or not, now. It just dragged on into repetitive, badly designed levels, full of the same enemies. Over and over again.Nothing more to see here.

Oh, you wanted to know what I haven't finished and why...

Games I've not finishedHalf-Life - Read Xen was crap. Got to Xen. Decided it was crap.Half-Life 2: Episode Two - Got to the final level. I had problems coordinating looking up, because I'm gaming on a MacBook laptop using Cross-over in windowed mode at the moment. I could work through most of the times this caused problems, but not repeatedly looking up to shoot stuff at Striders with my gravity gun.God of War 2 - Just lost interest in Kronos. He just wasn't as interesting a character the second time around. And a lot of the same ideas got recycled.God of War - Got to the Blades of Hades. Broke the controller in frustration. Decided trying to balance on beams whilst jumping slowly spinning blades wasn't fun (There's a moment pushing a box on the first level that nearly stopped me as well).Zelda: The Wind Waker - Got to the final fight with Ganon. Figured out that 'yes, I had to bounce the light arrows off the shield'. Wasn't able to coordinate it and ended up firing my light arrows in random directions. Gave up.Metal Gear Solid 3: Snake-Eater - Stuck on the final Boss fight.Metroid Prime - Stuck on the first boss fight. I know what to do, but again, having to do it repeatedly under time pressure is stopping me.Grand Theft Auto: San Andreas - Stopped shortly after I left San Andreas. Actually, that's not quite true - the wilderness levels after it were entertaining. It was the 'learning to fly' mission that put me off.Grand Theft Auto: Vice City - Kept getting distracted by having fun doing little. Then San Andreas came out. Not being able to climb or swim suddenly seemed stupid.Oblivion - Got lost and trawled through random dungeons. Decided that it was fun, but at level 1, the dungeons weren't much of a challenge. Lost interest.Morrowind - Had a laugh when a wizard dropped out of the sky almost on top of me with a 'massive jump' spell in his inventory. Stopped immediately afterwards when I saw a game completion video that used the said spell to finish the game in a ridiculously short speed run.Psychonauts - Got to the Milkman level while giggling insanely most of the time (Except in the dull camp levels). Found a jump that required me think in non-Euclidean geometry. Did I mention I hate dying repeatedly on the same platform jump?Brain Training - Stopped when I finally got to age 20 ahead of my wife. While drunk.Trauma Centre: Under the Knife - Just as it gets interesting, this game hits a difficulty wall akin to attempting surgery after having cut through the major tendons in your hands with a scalpel.Okami - Thought something funny was up when I had to fight the main enemy really early in the game (Actually, ending Okami there would have been perfect). Went through another two boss fights that were just not as interesting, then read on Game Intestine that I'd have to repeat all the boss fights at a later point in the game. Twice. Gave up when I had to race a magical ticket through a series of timed puzzles. That's right - a magical ticket.I could go on, but I just decided to stick to the highlights. I'm talking about highly rated games that have attracted a huge following and great reviews. And while I'm by no means a brilliant gamer, I've got a lot more time on my hands, particularly at the moment, than say, someone with kids. Or a job, for that matter. So there is definitely an industry wide problem there, at least from my point of view. It doesn't help that I tend to spoiler myself silly.

Care to share your 'not finishing a game' experiences?

And if you're worried that this blog is heading away from talking about Unangband, this directly relates to problems in Unangband. The game is too long, and the difficulty curve too step later in the dungeon. I'll talk about that at a later date, but I have a hunch that games stop being interesting when you stop being given new toys, or being shown how to play with them in new ways.

Which implies that the Unangband should end when you reach level 40 (there are no mage/priest spells after that level), and dungeon depth 50 or so, just like the original Moria. Antoine, of Quickband and Ironband fame, is a great exponent of the shorter game, as is Steamband.

(Actually, I cheated slightly. I've also finished HL2: Episode One, and Minerva, and HL: Blue Shift and HL: Opposing Forces. And God of War, when I took a day off sick and spent 3 hours jumping those f&($!£ng Blades. Ironically, the level in Hades itself where you have to navigate spinning spines set with blades, I found easy to navigate by just jumping repeatedly. And I was used to dying senselessly by that point.)

Via the Irrlicht blog, I've discovered Ohloh. This looks like an interesting site for deriving various code metrics. You can register your public SVN in the site and it'll pull lots of information off. I'll pull some stats off of it for Unangband, once the registration process for the project has downloaded and analysed the project SVN. Of course, as always you can take the code metrics with a big pinch of salt.

A note for various Angband variant developers: I've added the Angband license by directly copying the contents of copying.txt from the Angband copying.txt. I hope this was the right thing to do.

“The game will also have a unique feature similar to Diablo’s random level generation system. This new system will generate a nearly endless (750,000+) number of item variations. According to the preview of the game in Game Informer magazine,

“We saw a ridiculous amount of guns, but perhaps the strangest was a revolver that fired shotgun shells. Gearbox is constantly surprised with what the system comes up with. They’ve seen rifles shoot everything from homing darts to rockets. ‘One of the guns tracks onto something and locks, and after three seconds, (the target) suddenly explodes,’ director Matthew Armstrong says.”

Ah bugger. There goes the genius business plan I’ve been nursing for the last five years… I was going to try to sell it to Valve as well…

I try not to mention web comics too often. I mean other than Concerned (which is no longer running) and xkcd. But trawling through someone else's blog, I came across a link to Dinosaur Comics, which is a good read if only because its another great example of web comics being a medium of ideas if not necessarily art.

Dinosaur Comics is environmentally friendly. In that the art is recycled. For. Every. Single. Comic.

Pure genius.

On a related note, does anyone have good suggestions for online graphic novels? I mean to read, as opposed to to write.

I would like to point out that while I raved about Google Reader in a recent post, I've just discovered the down side. Or at least the downside of living in Australia.

It's not so much of a case of you northern hemisphere types vs. us southern hemisphere types (which is what I can blame my lack of productivity in the NaNoWriMo, as we had superb weather yesterday - luckily today is properly rainy). It's you east of the Pacific Ocean timezones vs. west of the Pacific Ocean time zones.

I would have read maybe 10-15 articles yesterday in reader, during the day. And then I get up this morning and have to go through 100+ of the damn things, due to the beavering away of the Western hemisphere game industry journalism machines during our night. I can see the supposed 'time-efficiency wins' I talked about being eroded quickly by the necessity of getting up an hour earlier just to read everything. I mean, I still have 20 tabs open from where the article didn't have quite enough information shown in Reader, and I've been doing this for 45 minutes already.

[Edit: Blogspot is a little time-zone impaired. It was 8:15 am when I posted this.]

Monday, 26 November 2007

I mean, look at what he's done for you. Saying he's a pastiche of Thomas Pynchon and pointing out he likes to finish stories abruptly is like comparing Christopher Marlowe to Shakespeare and, besides, you know, he should have learned to knife fight.

Sure, you loved him when he came out with Snow Crash, and put him up on a geek-culture pedestal, but now you're just using him. I don't know whether it was the fact the Cryptonomicon was too much like Gravity's Rainbow, or theBaroquecycle meant you had to learn all these new words and brush up on your 18th century history of geekdom. Or maybe you discovered Iain M. Banks and Alistair Reynolds, and have ended up in the post-singularitycyberthulhuchick-lit that is Charles Stross. Sure, you bag on Iain M. Banks too: for not writing enoughCulturenovels - but you just say each book wasn't as good as the previous one, or that he's just ripping off Orion's Arm - and Alistair Reynolds is, you know, rewriting the same great novelagainand againand again. But nothing feels as good as kicking the big guy. Heck, you might just go deface his pretentious art house wiki again.

I've gone from 20+ links in my Firebox bookmarks bar to 10, a third of which are websites for my wife to check the current weather on and exchange rate on, and the rest short cuts to the various Google tools I use.

And I've started reading the Internet on one screen. What's more every time I find someone saying something intelligent, I'll add their blog to Google Reader. I'm up to 38 links and growing fast. And I'm so much more time efficient I end up having to write blog entries to fill up the rest of my day.

Just read a short piece and a great comments section on Zen of Design.

In particular the comment from Joe Ludwig:

I started out entirely neutral on the subject of designers writing scripts. Then I saw the production schedule and thought, “Holy crap! The only way we’re going to get all this done is for designers to write scripts.” Then I saw the scripts that designers write.

Now I would much rather provide data driven systems (with conditionals!) so the designers can do 95% of what they need to do without writing any scripts. Then over time you will end up adding new features to your data driven system and the designers will start thinking in terms of what they can do with the system they have.

That reassures me greatly when it comes to the design of Unangband. Whenever I come up with a new feature, I try to push as much as possible of it out to a data file, either in tables.c or a separate .txt file in the lib/edit directory. I'll prototype by writing a data file that contains the information I want. When I've come up with enough examples, I'll write a data structure and parser, based on the existing set up in init1.c.

Then I'll finally implement the feature in code.

It's proved remarkably effective and resilient. And it turns out others can do great things with simple designs.

While I'm working on other things, I thought I'd ask if anyone was interested in reviewing Unangband. A few of you have spoken positively about the variant, but I 'd like an overview if possible for someone coming to either here or the Unangband home page to get a 'feel' for how the game plays out, without necessarily having to download it themselves. It doesn't have to be all positive - feel free to point out any problems, flaws, quirks or just plain trash the whole game if you feel like it.

Either write the review on your own website, and put a link in the comments section below, or send me a copy of the review and give me permission to host it on your behalf. I'll accept most document formats, but I'll be changing the format to html if at all possible (e.g. if you send me a word document or PDF). My email address is on the splash screen when you start the game.

Well, I've just done some quick word counts. I've written approximately 14,000 words on my blog this month. And I wrote a 9,300 word short story last month in four days. The target is 50,000 words.

It's now the 25th (I'm ahead of the timezone that blogspot uses). So by the end of the 30th, I'm asking myself to write approximately 10,000 words per day, assuming I have a non-performing day (probably today).

Reading through the experiences of a few other users, it looks like a really good day, when they've hit their stride, consists of 5,000 words. But I'm assuming that most people have jobs. While I have to spend time looking for work, that is more like a 20+ hour a week activity, as opposed to 40+ hours.

For those of you interested in following the experience further, I've set up a separate blog, named after the first book of poetry I published. I'll double-post this post there, as a starter, and if you could comment on this insane scheme there, it'd be appreciated.

The plan is to take two story ideas I came up with in October, and write them simultaneously, working on one until I run out of ideas or motivation, and then the other. Both have enough 'high-concept' ideas to propel the story forward. It's a matter of ensuring that they're accompanied by captivating characters etc. And, of course, enough words.

For those of you who want to point out that two 25,000 word pieces does not constitute a novel, imagine I'm writing a pulp 'reversible book', which has a front cover either side, and you just turn to the back cover and read the second novel from there (I can't find the technical term for what I'm talking about at the moment - I hope you understand what I mean).

So at this stage, I'm going to say I might be able to make it. Wish me luck.

Saturday, 24 November 2007

I finished Minerva last night, a free single-player Half-Life 2 mod, just as my wife came through the door of the flat. I had been up waiting for her after deciding not to go into town to meet her journalist friend, and she was bubbly with enthusiasm after a few glasses of wine.

Actually, much like the narrator of the Minerva frequently does, I just lied to you. I finished Minerva about twenty minutes after she came back to the flat. I was annoyed with her, because she'd been late without telling me. It wasn't her fault, as I currently have the cell phone that we've been sharing since we arrived in Sydney, but I took it out on her anyway by ignoring her until I had killed the last of the zombines silhouetted in the evening sun, as they struggled in the downdraft of a helicopter gunship.

In the bigger scheme of things, it doesn't mean much. We're happily married, and despite my repeated failure to find work at the moment, moving to Sydney has been an exciting change of scene after five and a half years in London. So the happy moments outnumber the petty power plays. And because of her generosity of spirit, I know that this will never change.

But what unemployment has done is give me the opportunity to spend a lot more time thinking, and consequently writing. I've taken that opportunity out in anger on this blog, deferring as I am at the moment fixing the final few bugs in the latest Unangband release, and completely forgetting the promise I made to myself that if I hadn't found work in November I'd spend it writing a novel as a part of NaNoWriMo.

Writing is like programming in that there is no better advice you can give someone in the field than to spend as much time as possible doing the activity as opposed to thinking about doing it or talking about doing it. Jasmin's journalist friend is a great writer, but she says she's 'not disciplined enough' to write anything great. That is like saying you're a great climber but you're not ready to conquer Mt Everest, or you're a great pitcher but you're not ready to improve your season average, or you're a little lonely in a new city but you're not ready to go out and make new friends.

Developing a roguelike game is like writing, in that the you can spend forever planning, but until you write a line of code, you're not developing a roguelike game. I'm not sure what you're doing, but you could equally be sitting at a cocktail party asking a couple whether they know the length of time they could be detained under the anti-terrorism act, expecting that to somehow impact Australian foreign policy. Which is why once or twice a year, the roguelike community sits down and runs a competition that, like the NaNoWriMo, encourages you to sit down and devote time to doing nothing more complicated than coding. It's called the 7 day roguelike competition, and this year, one Glenn Wichman made himself a promise that he'd do it.

Glenn is now in the process of writing a novel in November. How do I know that? It's because having made the promise to write a roguelike, he started with one line of code, and added another, and then another, he ended finding himself in a position where he could say, I have done this thing. I have met this milestone and accomplished something. And he could tell his friends, last night, I finished writing a game (and you can play it online yourself to prove it). And he's also promised to finish the NaNoWriMo.

Glenn is a special case, because if you know your roguelike history, you'll know he wrote not just one roguelike, but two. The other is called Rogue.

Which is a roundabout way of saying, that you can start off on a journey of a line of code, or a sentence, or a footstep, and end up changing just a little piece of the world.

Last night, I finished playing Minerva. I finished playing it because one Adam Foster made a promise to himself, to write a Half-Life 2 mod. And he placed one brush after another in the Hammer editor until he was finished, and could tell his friends that last night, I finished doing something special.

Half-Life spawned many mods, single and multi-player, Half-Life 2, not so many at all. Adam believes the mod scene has had so many failures recently, because mod teams are trying to build too much, with too many people on board. I suspect he's right. Because it's easier to make a promise to other people, than it is to make a promise to yourself - you know when you're lying.

I started this wanting to write about the importance of having something to say, or at least thinking that you do. I used to think that writers are successful because they operate under this delusion. Deep down I know I'm just covering for the fact that's only part of the problem. You need to have something to say, and you have to say it well.

And that's a skill in itself: saying something well. Or I should say: saying something well is a craft in itself. A skill implies that you have an innate ability, a craft implies that you can work on something, over and over, honing it into shape with repeated work. And so that's why I'm writing this blog. I'm not sure if I have something to say still, but I know that if I don't write, one line after the other, when I find the things to say, I may not say it well.

(Edit: Part four just got eaten by a AJAX bug in Minefield - Firefox 3 prerelease. I'm rewriting it again and cursing.

If you haven't been following this series of articles, you'll probably want to start with parts one, two and three).

Angband levels are different to many games in that the levels are randomly generated with virtually no delay, and the once the player leaves a level, it is discarded and forever lost.

Contrast this with the many other roguelikes which feature 'persistent' levels. In many instances, in these the player will leave item stashes around the dungeon, in order to overcome their inventory limits. It is possible to have stashes on the current level in Angband, but the risk is high that they will be stolen or destroyed by monsters or nearby player activity, or wiped with the rest of the level if the player is forced to leave prematurely. Angband is a game focused around inventory management and the fixed number of equipment and inventory slots become a mechanism for determining when it is time to leave a level, sell valuable items in the shops and to refresh needed supplies.

Frequently the current level can become too dangerous for the player, and require that they abandon it to survive. Breeders can fill the level through a process of constant replication, and summoners can crowd with their minions. A player may release a powerful monster from a vault without being prepared enough to deal with it. If the level contains a unique item or monster that the player requires, persistent levels would mean that it would be gone for good. In Angband, the unique is discarded along with the rest of the level, and re-generated at a later point in a new level. It is possible to permanently lose unique items (artifacts) although the conditions for doing so regulated closely (and controlled by a 'preserve item' option). Also there are no ready mechanisms to bypass a particularly dangerous level.

(In fact not all Angband variants have this behaviour of discarding levels. AngbandTK allows you to move between the current dungeon level and the surface freely, only discarding the level should you move to the next one. And Entroband, formerly Hengband, has 'semi-persistent' levels, where the levels are only discarded if you should return to the surface, and it is possible to take two different sets of stairs down from the same level and end up on two different levels, allowing you to bypass a dangerous level. 'Semi-persistent' levels address the problem of stair scumming and is something I'll adopt at some point for Unangband).

So the level mechanic in Angband has functions other than just solving resource constraint issues that existed in the original Moria design. In fact, levels in Angband should be viewed as an inexhaustable resource. The player can continue to generate levels freely, until he finds a desired set of characteristics in which he wishes to play. This may be a poweful item near the stairs. Or a monster that can be killed without risk of retaliation. This is why the stair-scumming behaviour is so powerful and so rewarding.

But at the same time there is little to distinguish one level of Angband from the next except the types of rooms placed. Wandering monsters and the items they carry depend only on the player's current depth. There is no indication provided as to what the contents of a level are except an ill-defined 'feeling' which can easily be misinterpreted. It is possible to have a monster created on the far side of the level and the player have no idea whether it is a powerful new threat or a trifling nuisance. The only game mechanic for seeing what lies around the next corner is the detect monsters spell, which provides 100% information over a limited area. And this all-or-nothing solution handicaps interesting game-play choices.

Sangband attempts to overcome this by having 'interesting' rooms, which contain a particular type of monster and are built from a vault template. This attempts to link the dungeon layout at the types of monsters that you encounter, and so provide the player additional information and additional incentives to pay attention to his surroundings. For instance, early on you'll encounter a room containing felines and a large gold-bearing formation of rock. This is an attempt to link the two in your mind, so that the next time you encounter the room, you'll be prepared for felines.

Except that the information is provided the wrong way around. Felines are both fast, and detect the player at a considerable distance. As a result, you'll end up fighting your way through felines and then encounter the room containing the rock formation, which is otherwise empty. And the Kheldon Jones AI, which would ensure that the monsters stayed together and try to mob you in a room, only applies to group monsters (Turning cats into group monsters for the sake of this seems wrong somehow).

Troll pit on the level? You'll fight your way through a huge number of trolls, and then encounter a big empty space. Undead pit - the 'inner' walls that at least served to partially contain the trolls doesn't work as most undead can pass through walls and attack you, before you are even near the pit. A non-Angband example: a significant part of the design effort in the single player Half-Life mod Minerva was spent putting obstacles in the way of the Combine AI, in order to slow them down sufficiently so that they could be encountered at the correct time. In fact, as AI improves in-game I predict that this will become an increasingly prevalent problem.

A significant part of level design, as discussed in the Unity of Design section in part three, is the delivery of enemies to the player in a meaningful and consistent fashion. And the fact that monster AI allows monsters to move beyond a room is the fundamental failing of the room-based model of monster delivery. How Unangband overcomes this will be the focus of part five.

Thursday, 22 November 2007

(Just wanted to re-post a comment I left on the Slashdot article. As for the occurrence of the 'zonksucks' tag on the article - the story submission was submitted via the firehose and went 'hot' along with a story about a man-sized scorpion. Zonk had little involvement.)

I'm arguing for the existence of levels, not against. I apologise for not making it clear enough in the summary - I guess I expected more people to read the fine article. However, I'm setting out the reasons why the existence of levels in order to load additional parts of the game is no longer a requirement, and perhaps theming, pacing, narrative, learning curve and reward are much better reasons for the level structure (I missed out reward, and I'm kicking myself for not thinking of when I first wrote the article - ironically, there's a great review of Supreme Commander on Eurogamer at the moment arguing one of the frustrating issues in that gave is the reward for 'finishing a level' in that game is to expand the play area and make it harder).

A book has chapters and a movie has scenes because these are both (mostly) narrative mediums. A counter example of books without chapters which venture closer to the game space is the Fighting Fantasy series, where the chapter mechanism is thrown away in favour of the 'choose your own' mechanic. Similarly, cross-cutting two scenes in film is a way of mixing up the narrative structure. I would be interested to know if there are any Memento-like games out there.

A game has levels for - well, narrative is certainly a reason, but not the only one.