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.

PCG Wiki Membership Drive

I'm probably not doing enough to promote it, but the Procedural Content Generation wiki has been growing in leaps and bounds. It has over 600 pages relating to procedural generation created by a hard working team of individuals dedicated to the vision of procedural content generation. It's also the number two spot for the search term 'procedural generation' in Google - with only the entry on procedural generation in Wikipedia ahead of it - with over 1600 visitors and over 6000 page views in the last 30 days. That's excluding any peaks caused by getting mentioned on aggregator sites like Metafilter, Digg, Slashdot or Boing Boing

And I want you to be part of the team.

Well, actually part of the community. One thing that hasn't taken off is the PCG forums - they're a little barren at the moment, and I really need to jump start this part of the site. So I was wondering if you could help out by doing the following:

1. Creating a wikidot account.
2. Joining the site.
3. Introducing yourself on the introduction thread in the forums.

Much appreciate in advance.

Ascii Dreams Non-Roguelike Game of the Year

It appears traditional to offer an end of year analysis of the best games of the year in preparation of the famine of the early months of the New Year. Prolific journalists and enthusiastic amateurs will provide well considered advice on which games they played provided the highs and lows, while developers and studios prepare the resolutions for 2009.

You too are being offered the choice of the best at my table – voting for the plenitude that is the 75 roguelikes which saw a release in 2008. Many of you reading this site on a regular basis will note that I also play games in other genres, perhaps skipping over the articles where I have boldy proposed designs and redesigns of what I have played in 2008. Based on these experiences, I would like to like to suggest a game of the year which falls outside the roguelike genre. But I have a confession to make. (With apologies to southern hemisphere readers).

In this grasshopper season rich with autumn’s bounties, I’ve played the ant.

I sit in my lounge, glancing briefly over the PS2 and Game Cube gathering dust under the widescreen LCD - calling it a television, when I’ve watched perhaps five hours of broadcast television all year would be a disservice – and over to the stacks of jewel cases of my gaming collection, stacked high with second hand gems of yesteryear like Half Life: GOTY edition, S.T.A.L.K.E.R., Company of Heroes and recent acquisitions, like Spore and...

Well, only Spore.

I noticed, and still contemplate, a distressing trend in my purchases, which has completely changed my buying behaviour this year. I would get a game, open and install the CD once, and play a while. Then I’d have to re-image my laptop – for a variety of reasons, discussed previously – and never touch the game again. The sheer inertia of having to wait for the install, perhaps swapping CD or DVD , disc after disc, then finding and installing all the patches, only to have to repeat the process a few months later, would exhaust me far before the euphoria of actually playing would hit. Not to mention the inconvenience of having to pack for the road, a frequent experience recently.

And so the game would sit discarded in its case – while I played Left4Dead, or Team Fortress 2, or World of Goo, because it was far easier to back the Steam cache up to hard drive, and faster to restore it than install a game from optical media.

To rub salt on the raw wound, a few weeks later, the now forgotten game would arrive on Steam, where I'd be left with the unpleasant choice of repurchasing it, or relying on the sundered shell of its former fragile, imperfect physicality.

So to confess my New Years resolution last year: I swore to only buy games this as they were digitally released.

I cracked, but once. Buying Spore was a calculated risk that Electronic Arts would be unable or unwilling to distribute their tent pole games on a third party platform – one which has just been proved wrong, spectacularly so when you consider the Steam version doesn’t require SecureROM.

Which is why my game of the year is a platform, Steam, not a game.

Because Steam is really the only game in town.

Stolen from elsewhere

In Google Reader, input:

up,up,down,down,left,right,left,right,b,a.

Dedication

I believe we should be supporting this man on principle.

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.

Asserting a Coding Style: An Answer

Stu in the comments thread pointed me in the direction of Design By Contract in C, which points out the disadvantages of assert() or require() style of coding and offers an alternative. Have a read of the article, and then download the latest version, if you're interested.

Now, before I adopt this, I just have to persuade any other Angband variant that I'm likely to steal code from to adopt this standard as well...

Asserting a Coding Style

There are two schools of thought regards how your code should fail: either it should try to keep going as best it can, or it should hard stop.

After many years in IT, I'm firmly in the hard stop school. It makes it far easier to debug, if your program fails at the point at which an exception occurs, even if it is a less pleasant experience for your users. (And trust me, trying to talk someone on Windows through setting up a debugger is not easy - I mean, I can't even do it for myself at the moment).

The 'try to keep going as best it can' is often a euphemism for silently corrupt something, violate the assumptions we've got in the code and then fail inexplicably further down the track.

Luckily for people playing the game, Unangband, like Windows, is written to the silently corrupt and experience weird errors standard. Which is why I have in the back of my mind, the intention to adopt a coding standard that promogulates hard failure when it detects an exception.

The easiest way to do this is have an ASSERT() macro which if false, does something that'll cause general program fault, like dividing by zero. ASSERT is used in a couple of places in the Unangband source, where my more disciplined co-developer has attempted to impose some kind of rigor in the codebase.

What has piqued my interest and led me to discuss this, is a new dungeon generation algorithm posted on rec.games.roguelike.angband. This algorithm has been kindly put into the public domain by it's developer Kusigrosz, and you'll be seeing it at some point in Unangband as a new room type, nest and as a new dungeon theme. (Screen shot of the output either at the link or the start of this article).

The C source for this algorithm uses another macro REQUIRE() which if false, immediately exits the program and dumps the source code line at which the fault occurs. REQUIRE() is like ASSERT() in that it lends itself naturally to specifying the pre-requisites and post-requisites for a function. You can for instance add a line REQUIRE(x>0); which intuitively indicates that at this point in the code we expect x>0.*

What I ideally would like, is REQUIRE() but with the ability to set a failure level at compile time or run time. That way I could have a number of differing levels of failure, allowing the user or distribution to select how hard they want the program to fall over. The levels would be:

0. REQUIRE() compiles out completely, used on systems with limited memory or performance.
1. Silently return from the function.
2. Write a warning to a log file, and silently return from the function.
3. Write an error to standard out, including the line number of the source code and exit.
4. Dump the stack to a file, including the line number of a source code and exit, useful for a debug build for users who don't have the technical skill to set up a debugger.
5. ASSERT().

I'm quite happy to be able to bloat the source doing this in the long term, but I want to make sure I'm doing so with a robust mechanism.

So my questions are:

1. Is there any other mechanism out there that better supports this hard, flexible fail over?
2. What is the best C constructions to ensure levels 0 and 1 work in a platform independent manner? Remember, I don't know necessarily whether the function is intended to return anything at all.
3. Is there any macros or public domain code that supports dumping the stack at runtime? This would also need to be relatively platform independent. Note that Windows is the only platform where this is currently a major problem.

Thoughts and feedback welcome.

* The Unangband form of this, adopted from Angband, is as follows:

/* Paranoia */
if (x < 0) return;

which is very much of the form 'silently fail and keep going'. [Edit: And you'll see here, prone to failure. Of course, I meant if (x <= 0). But then out by one errors are always fun]. [Edit 2: And it also looks like I reversed the conditionality of the assert() statement, in which case assert() and require() are equivalent. Article amended. And I should read assert.h].

Similarly, the TRY {} CATCH construction is mostly focused on trying to recover from exceptions.

Refactoring Hell

If there is some kind of coding hell, then refactoring is in the centre of the ninth circle of it.

I'm in the process of redesigning the Angband projection function, I dunno, for the fourth time in order to avoid unnecessary code duplication when it comes to applying magical effects to regions. I'm going to end up with a wrapper called project() which calls project_shape() to define a list of grids to affect, and then project_effect() which takes a list of grids and an effect, and applies that effect to the grids. This will allow me to take another list of grids - say a region - and use project_effect() directly to affect them.*

The problem I have with refactoring, is that you inevitably take a lot of hard won lessons and throw them away as a part of the refactor, and expose a lot of assumptions about how the code works to fundamentally different processes. And it's boring in the sense that at the end of it, the player doesn't notice any changes in the game, except more bugs.

So I'm tempted just to duplicate the code instead and move on. Especially as, having completed the refactor, I can get Unangband to reliably crash on my Windows box, which I can't get the mingw32 debugging environment working on for some reason - which means I'll have to debug on the Macbook instead. And do a sneakernet sync of the code repository to avoid polluting SVN with the offending code.

Ugh.

* The reason I have to take this approach, and can't do a single 'apply magic effect to a single grid' routine instead is quite subtle. One of the things magical effects can do is move you around e.g. teleport, waves, wind, gravity etc. But these effects can also potentially do damage. And I have to be careful that I don't move the player into another affected grid, and consequently double-hit them with a single magical attack (because of how important hit points are in a permadeath game, it'd be unfair to the player). So I've adopted the Sangband solution, which is to apply all the movement effects last, after all the other spell effects have occurred.

The Angband projection function already has this layering approach, applying effects to all the terrain first, then monsters, then the player. Sangband adds teleportation effects. And Unangband adds item breaking effects at the end, as items can explode to recursively create further projections, and I take advantage of tail recursion to ensure this happens in a safe manner. This means there is quite a bit of code to duplicate, which is why refactoring is a tempting trap to fall into.

The Symposium

There is only one symposium worth reading at the moment - games journalists on games journalism gathered into a herd by Shawn Elliot. I'm an interested outsider: as a potential review target at some future point, the only game reviews which I seem to learn stuff about the game from seem to be gaming diaries. Case in point is Tom Chick, who specialises in this kind of writing: he's just started writing about Fall From Heaven II, a Civilisation IV modification, in this mod. I expect to come away from this with a much greater understanding of the game, than any review I could care to name.

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.

Request for votes: Ascii Dreams Roguelike of the Year 2008

Voting is open for 'Ascii Dreams Roguelike of the Year 2008'.

How did the roguelikes qualify?

The list was taken from the roguelike releases announced on the Rogue Basin news section between January 1st and December 17th 2008 and from the list of Actively Developing Roguelikes maintained by Jeff Lait. There are a record 75 entries this year.

What about 'x'?

Make sure you announced your roguelike on Rogue Basin for next year. In particular, NetHack didn't make it in, again.

What about the 7 day roguelikes?

I decided to exclude any 7 day roguelikes that weren't announced separately.

What's the prize?

Pride. And a sexy logo. You can see the winning 2007 logo on the Dwarf Fortress links page. Logo designs for this year are welcome.

Having a competition is a dumb idea/offensive/stupid when you can't police the results.

Yep. Doesn't stop it being fun. You can vote for multiple different roguelikes. The idea here is that you will be encouraged to go out and download a roguelike that other people consider interesting, not that there is any kind of real competition element involved.

Results for 'Which Unangband School do you prefer?'

Thanks to the 29 of you who voted. I'm surprised about the lack of popularity for the Druid... The results were:

Wizard	9 (31%)
Druid	3 (10%)
Master	5 (17%)
Sorcerer	9 (31%)
Thaumaturgist	6 (20%)

You'll have another opportunity to vote shortly - it's that time of year again.

Design Re-Engineering

Valve is on the hunt again for upgrade advice - in this instance, for the Scout.

Unfortunately, I have little advice to offer here. I’m not a great scout player.*

But luckily, they’ve also recently released a patch that greatly improves playing the Engineer – by allowing the engineer to upgrade their dispensers and teleporters to level 3, with a consequent improvement in dispensing and teleporting speed. Here I am qualified to offer suggestions; the engineer is my first and foremost love and anything that allows the engi to fuss around their buildings and move around the battlefield more is an improvement in my book. So here are my engineering upgrade ideas:

The Quik-R-Ratchet: The Quik-R-Ratchet immediately (on one hit) builds any building to level 1. It allows buildings to be upgraded to level 2 at the normal pace, but cannot be used to upgrade a building to level 3.

Because running up and deploying buildings quickly is what engineers should do. It also helps two engineers work together much more efficiently, one with the Ratchet and one with the w’regular Wrench. Engineers should be encouraged to drop an annoying level 1 turret on the front line, or to move their turrets following an attack to confound the opposition.

The I-Spy-Shooter: The I-Spy-Shooter is a shotgun which immediately decloaks any spy, preventing them from cloaking for 5 seconds, and otherwise does half the damage of a normal shotgun.

There is nothing as frustrating as knowing there is a cloaked spy around, and not being able to do anything about it. You have to squat on your kit, back to the wall and pray. At least with the I-Spy, you’ve got a fighting chance. Of course, a disguise isn’t going to be stopped by this.

The Big Red Button: The BRB replaces the pistol, and allows the Engineer to teleport back to his teleport exit, provided both the exit and entrance are built and fully charged. Doing so discharges the exit, but requires the engineer stand still (in taunt mode) for several seconds to activate. ‘I said B...R...B...’

And this should allow Engineers to wander the battlefield, helping out others with their shotgun, while letting them get back to their equipment in a jiffy (provided a Spy hasn’t sapped it, of course). This may encourage engineers to build entrances in useless positions: if that is the case, it should be tweaked to teleport back to the entrance, or exit, depending on a left or right mouse click.

*I lied. At least about the advice thing. I might be able to come up with some scout solutions:

The Short Order Book: The Short Order Book replaces the pistol and can be used on any player on your team. Once you get an order from the player, by hitting them with the order book (at close range - a short taunt animation shows the scout writing up the order), the scout must collect a health and an ammunition pick up (or refill from a supply closet) to fill the order. Once the order is filled, the instant you touch a player of the same class as the order you took, you dispense them 25% of their ammunition, 25 health, 40 metal for an engineer and for a medic or spy, a 25% uber or cloaking charge. You can also part fill orders, with just either health or ammunition, but the class specific benefits will not apply.

This gives Scouts stuck behind the front line something to do, and helps speed up the game play for those teams stuck attacking or defending near their spawn point. And for once, a scout will be giving you health and ammunition instead of taking it. Understanding the game play for this is complicated, so the order book should take the form of a big checklist that gets filled in as the Scout completes the required actions:
[] Get health
[] Get ammunition
[] Give to _________

Once the scout has filled the first two steps, they automatically shout out as they move around the map e.g. 'I got an order for an engineer!'.

The Brooklyn Bridge: The Brooklyn Bridge, a fence board with a nail in it, as opposed to a regulation baseball bat, fixes any turret it hits in position until the Scout is killed, preventing the turret from turning, but still allowing it to fire in the direction it is pointing. It takes twice as long to attack with the Brooklyn as the regular bat.

Ah... the mythical anti-turret scout weapon. What rage and anger fills the Valve forums, discussing the pros and cons of various ways of the scout countering his ‘hard counter’ and the means by which he should do it. By whacking it, of course... the gun effect is far less useful than a Spy's sapper, and it is far harder to for the scout to get in position to use it, but against an undefended gun, the Bridge should provide a way past.

The Soar’n’Off Shotgun: The ‘shortie’ as it is affectionately known, does critical damage while the scout is in the air. It otherwise is incapable of criticals.

Because running around a target is more boring than running over it.

Pathfinding Redux

There is an ongoing discussion in the comments of the recent pathfinding post I did that you may want to read. Or contribute to for that matter.

The point I was making was that there can be so many complications to try to get pathfinding right, that you are probably better off coming up with a simple solution that works most of the time (such as making monsters always advance) than trying to capture all of the complexity aiming for a perfect algorithm. Your time can be more valuably spent elsewhere.

Violation of Contract

I'm about to violate a core tenant of Angband's user interface contract, and I'd like your advice.

Up until now, Unangband has followed Angband with regards to what can be in a single grid. In Angband, a single grid can hold:

1. a monster
2. either a trap or one or more objects or 'interesting' feature
3. if not an interesting feature or trap, then the grid must be a floor which is safe to walk on

This is a very important contract between the game and the player. That is, if there is an object in the grid, it is safe to walk on. You can actually use this to determine where traps are, by throwing objects around a room and see where they don't drop. More importantly, it allows you to interact with stacks of objects, by moving around the room, picking them up.

I'm in the process of implementing ranged traps. Ranged traps will have a region that they target, which triggers the trap when you move into it. This violates the above constraint, because you will end up with a grid that holds an object, and then a ranged trap where the region it targets includes the grids with the object.

I want to include the trap regions in the map display, to help the player avoid them. This leads to a second violation of the above contract: it's now possible to end up with a grid which is in the region of multiple traps. So I'm stuck with a user interface dilemma.

How do I display multiple trap regions, so that the player can most usefully determine which region is safe or unsafe, and the area effects of multiple regions? In Unangband, you can display up to 256 colours (more like 28 legible differences) and one ASCII character in each grid. There is no reverse video or stacking of multiple characters in a grid.

I want to be able to distinguish between the traps themselves, which you can disarm, and the trapped regions, which you can't disarm. The trap character is ^, and for historical reasons, I'd like to display the regions using x to indicate the trapped area - using the same colour as the particular trap type. I may have to use another character though, as x is already used for bridges of various kinds.

Suggestions welcome.

The Trap of Perfect Pathfinding

I'm firmly of the belief that there is no such thing as a perfect pathfinding algorithm. I've mentioned this during the article series on Unangband AI, but I'm working on improving traps in Unangband at the moment (a corrollory to getting druidic ongoing spell effects working), and it's very clear that in order to handle the complexity I want traps to have will overly complicate any attempt to build a 'correct' pathfinding algorithm.

I've just added the ability to avoid traps, as well as disarm them. Avoiding traps will become a more important requirement when I added ranged traps to the game (using a different implementation to NPPAngband ranged traps), but for the moment, think of it as particular trap types will not trigger if the player is in a particular state. If you are flying, you won't trigger pits or trap doors. If you are invisible, you won't trigger silent watchers. If you are in darkness, you won't trigger shafts of light. And so on.

My favourite is surreal paintings: you won't trigger these traps if you can see the painting. Which is just the kind of mess with your head weirdness that a magical scene that comes to life when you aren't looking should convey.

An important part of this concept is ensuring that the player can learn the various ways of avoiding traps. To do this, I try to make many of the trap types result in the game condition that then allows you to avoid the trap. This allows you to learn the associated way of avoiding the trap. For instance, one effect shafts of light can do is darken the room - which brings on the condition of darkness that prevents them from working. Similarly, magical symbols don't affect you if you have run out (or nearly run out) of mana. And an early magical symbol effect will be to drain you of mana.

Here's where the complication comes in: I want to make monsters avoid traps under the same scenarios as the player - to help the player learn these associations further. But this means that correct pathfinding will not only require knowing about the monster's permanent abilities, but their temporary ones. Which complicates pathfinding, because I need to model future effects. In particular, magical symbols will mean I'll need to model the monster's regeneration of mana, to determine whether they can safely cross an area filled with magical symbols (or more importantly, a single magical symbol with an area effect).

I've always had this problem, of course, because of dynamic terrain. Consider the following scenario and tell me how to design a pathfinding algorithm to handle it:

A monster runs into the room to attack the player standing in the doorway. Half way across, the player pulls a lever that floods the floor of the room with oil, then pulls out a match. Should the monster: a) keep advancing, b) retreat or c) stand still waiting for the player's next move? What other factors need to be considered?

Angband portable update

It looks like First Age Angband on the Nintendo DS is coming along strong: you'll probably want to look at the thread on the angband.oook.cz forums, which includes some good screenshots (and some terrible ones: Nick, what were you thinking?) and then head off to the download page, provided of course you have the right hardware to allow you to play homebrew games.

This comes hot on the heels of the original Rogue being ported to the iPhone. To port Angband to the iPhone will require moving or recreating the Mac port from the Carbon to Cocoa API as pointed out in this thread. Luckily, there is one Cocoa port already available.

The real challenges as Nick McConnell points out are handling the reduced screen size and alternate interface. He's handled most of the issues in FAAngband, which along with the Windows CE port is the best place to get your Angband portable gaming fix at the moment.

Game On

I just had the pleasure of attending Game On, an exhibition at the State Library of Queensland on gaming - containing if I'm not mistaken virtually every piece of hardware ever used to play computer games on, including the likes of the Magnavox and a DEC PDP-11 running Space War. While I was not able to lose myself playing as long as I wanted due to family commitments, I'm looking forward to returning in early January for a fuller exploration of the exhibits: that is unlimited cabinet and console gaming from a wide selection of arcade and home console systems.

If you're a gamer in Australia or New Zealand, you should make the trek. It's on until the 15th of February.

(I massively enjoyed the few minutes of Warning Forever, a freeware shooter featuring procedurally evolving bosses that I played - well worth a download).

Black Mesa Trailer

It's a day to get excited about a remake.

Designing a Magic System - Part Fifteen (On Hacks)

(You'll probably want to read parts one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve, thirteen and fourteen first).

The school spell lists as I designed them in part fourteen are intended to be a mix of banding tradition as well as an attempt to find new ways of making magic in Unangband interesting. I've been inspired here, as much elsewhere, by the design work in Sangband and elsewhere by Leon Marrick and although aided by many, this particular series of articles is dedicated to him and the insight and inspiration he has given me and many others.

Angband is a game of resources: and each magic school has a different way of handling the resources of light, food, escape, healing, mana (spell points) and item identification which help define them. Wizards have no reliable source of food at all, and no high level healing, but can readily concentrate mana to recover it and have the most flexible range of escape spells, and both the ability to light rooms as well as to use light as an attack, and to replace their fuel based light source with a magical spell which can be indefinitely powered provided that sufficient mana is available (and that the wizard is not plunged into darkness by letting this spell run out - spells require light to be read from their respective spellbooks). The Unangband Wizard has the ability to take advantage of magical items such as wands and staffs: both with a spell (gauge magic) which readily identifies the number of charges that the item has, and a recharge magic spell to replenish these charges as they are used.

I attempted to balance the flexibility and power of the wizard escape spells by limiting them significantly for the other magical schools. Druids can only teleport to and from water or natural areas (defined as being adjacent to plants), masters only to and from darkness, thaumaturgists require a nearby source of fire, and sorcerors can only teleport temporarily, returning to the location that they teleported from after a moderate amount of time passes. This was done to allow other escape spells, such as temporary hasting, and spells which shape and change nearby terrain, such as wizard lock and warp wood, to be preferred by these classes in various ways. However, the escape spells are much less flexible, perhaps too inflexible, to be reliably used, and since escape is of critical importance to magic using classes it may mean that the wizard ends up being the preferred class choice for Unangband players.

Druids are encouraged to manipulate their surroundings and many druid spells have been made synergistic with each other: while they can only teleport near nature, they can create trees to bring nature to them in the first place, and then these trees can be used to tangleroot opponents or recover health using the tree of life spell; similarly the mana pool spell draws mana from nearby sources of water. Once opponents are entangled, it becomes much easier to affect them with slow building natural attack spells which are their forte (a yet to be implemented forte at the moment unfortunately), and the ground can be further prepared by shaping the rock by turning it to mud. Food for a druid is trivially satiated with a single spell, light is randomly scattered around them as opposed to lighting up whole rooms (which encourages more preparation to 'fill the gaps'), and item identification through a useful but obscure system of runes which hint at a particular items function.

Masters summon monsters, and while the friendly monster AI is powerful and flexible enough for monstrous combat between the master's allies and enemies, I need to give the master more granular control for when they summon multiple differing types of monsters. To encourage the master to have more investment in their minions, I've added a Find Familiar spell, which summons a unique creature that the Master can tailor over the course of their career - but if this creature dies, it is lost forever.

One thing I've enjoyed doing with various master spells is monster design: in particular the Animate Dead spell requires I come up with undead versions of various body parts and creature types. I'll say more about hacks shortly, but I've implemented this as a blend of hacks of various kinds, instead of a 'purer' convert a monster to undead function. The sorceror's Animate Object has been similarly entertaining.

Masters relish darkness instead of light, attacking with it in various ways, teleporting to and from it, and consequently have a temporary infravision spell which allows them to detect warm blooded monsters in the darkness - I should also add a Night Sight spell which provides further visual acuity at a higher level. High level healing is acquired by draining the life from living enemies (or allies), which simultaneously feeds the Master, and mana can be acquired by sacrificing hit points in return - since Masters need mana to pay off summoning debt, it could be overpowered letting this be more readily recovered. Item identification provides a general hint as to whether an item is beneficial, and what approximate effect it has.

Sorcerors are a mix of traps, charm spells, mental attacks and shape-changing: charms being more effective than the master's abilities in summoning, and shape-changing very much a work in progress. I've probably gone overboard in terms of making shape shifting unfriendly for the player to use as it forces them to discard equipment in various inventory slots. I suspect I'll move back to the Oangband/Sangband style solution of making shape-shifting just affect player attributes. Sorcerors are almost as flexible as wizards in the ways they can escape, perhaps more so, but lack a pure 'get away and stay away' single turn spell. They are superior to other classes in their item identification magics, and instead a source of sustenance, they can readily slow their metabolism to prolong the effects of food they have consumed. Sorcerors lack any ready source of light, healing or mana however, so will be forced to scrounge for other methods of illuminating the dungeon and recovering from wounds and spellcasting.

Finally thaumaturgists are attack, attack, attack, with a mainline in randomly assigned elemental types (to be implemented) and a sideline in acid and fire magics. They can usefully renew their torch flame to allow unlimited light and step into flames to teleport and escape but otherwise lack any utility spells.

After spending fifteen parts discussing various design decisions to try to come up with a consistent and systematic method, I've yet to find a solution. In particular, my answers are variations on two themes. The first is a refutation of the argument I made in part one, that 'As a game designer, [...] flavour is all important, but ultimately distracting'. Designing classes is almost all about flavour and style: do these abilities fit a consistent theme, do they complement each other, and so on? We can take on principles of good design, and the importance of the language and grammar of design will be increasingly a requirement as our games continue to increase in complexity. But ultimately, we want to present the player with interesting choices, a set of hills or valleys in the possibility space of the game, and to avoid overwhelming the player with too much choice, we have to highlight certain highs and lows, while ignoring others.

The second theme is the importance of exceptions. As a programmer, your intuition is ultimately to try to re-use your code where ever possible. But as a game designer, of the magic systems, you want to ensure that each ability uses at least some unique code path. That is, each ability in your game must in some way be a hack. It can be a small hack (fire burns, cold freezes) or a large hack (the recent implementation of a Find Familiar spell required a complete monster progression system to be interesting), but it should ensure that each ability is different, and therefore affects the game play in some unique way. Extend the ability idea as far as you can (cold freezes water, allowing you to cross rivers and block swimming monsters from attacking you) and then push yourself a little to see where it takes you. Don't obsess with trying to make the code clean and regular: it's the abilities that the player has that keep them empowered and playing, and suspension of disbelief should trump any reduction in code complexity.

Normally I finish these design articles with a set of principles, but here I only have practise. It has taken me close to 7 months to list these practises and there are many more devils in the detail that only a close inspection of the code and asking me questions will do justice to (and please, ask me on the blog rather than via email so that the questions and answers are shared for all). I'm not throwing my hands up in the air: but this type of design requires iteration and playing, and decisions, and your decisions will not be the same as mine.

(You'll want to continue reading the follow article series Designing a Magic System Redux, where I address issues, such as status effects, magic items and summoning which I haven't discussed so far).

One Fist, Two Fist, Red Fist, Blue Fist

Yah! Dystopia, my favourite Half-Life 2 mod will be coming to Steam.

NaNoWriMo

Ah - once again, I've failed to even come close to the NaNoWriMo required total. I've still found it a useful exercise, as always, and I've written far more fiction than I would have written otherwise. My problem is I still found plenty of time to blog, program and celebrate my birthday, and various other functions.

Or at least, I shouldn't think of that as a problem. I mean, that's living, write. I'll argue that we just need a southern hemisphere timed writing event, perhaps in May.

For those of you who've been following this blog, I strongly encourage you to do one of the following two things:

1. Jeff Lait has published his 2005 NaNoWriMo. You may remember him as another roguelike developer and obviously a talented author as well. So please: buy his book.
2. Alternately, you can help donate to the NaNoWriMo to keep this event running. They've failed to cover costs again. Details on donations are here.

Take care. I'll be trying again next year.

Left4Dead Week: Failing is Fun

Left4Dead week will feature one short piece on Left4Dead each day this week to celebrate the full release of the game.

No other game celebrates the fun of failure like Left4Dead. (Except roguelikes. And Dwarf Fortress. Screw you Jonathan Blow for making failure impossible...) So it's time to second guess the designers and come up with some game 'improvements' to see if our hypothetical Left4Dead design can improve on the high standards set by the original.

And nothing says improving game play by adding stuff randomly without testing. So I'm going to suggest the addition of three more weapon types, and one more playable zombie. Ah... variety. The spice of life to cover up the stench of death.

Three additional weapons

These weapons are placed by the AI director - but instead of having a table from which you can pick 3 from, there's only a maximum of one per level, which comes with a fixed amount of ammunition which you can't refill. Think of these as a short term power up that one player gets to steal from everyone else. And fails with it.

The Chainsaw: How Valve released a zombie game without a featuring a chain saw beggars belief. Of course, they should really have included a lawnmower. But a chainsaw is close enough.

Primary fire: You saw through zombie flesh. It doesn't so much do damage, as carve up any regular zombie as soon as you hit it. Against special zombies, the shower of blood blocks your vision much as a Boomer's vomit does, but in a different colour.

Secondary fire: Melee attack like every other weapon which pushes zombies away. Occasionally your chainsaw will get stuck in a zombie while using primary fire and you'll have to clear it with the secondary fire.

How failing with it is fun: You'll notice that the primary fire doesn't push zombies away... so getting surrounded is just as bad as before. Plus: play a coop game, and take away someone's ability to use their primary weapon at range. Then see how everyone else feels.

Wait. Valve did that in Left4Dead with the Akimbo Assassin achievement. Nothing to see here then. Move along.

The Flamethrower: Lots of burning stuff. Check. Zombies on fire. Check. Ability to set zombies on fire using a flamethrower... didn't Valve watch the Thing?

Primary fire: Flame. Glorious flame. Watch how it burns. I'm waiting right now for a barbecue to get delivered. True story. I wonder what zombie flesh tastes like. I'm guess a chicken version of Spekekjøtt... mmm...

Secondary fire: Melee attack. Like everything else. Of course bashing the flaming end of a petrol tank against something hard is a low risk proposition. I wonder how often it'll blow up.

How failing with it is fun: Aside from the random petrol tank explosions - and how often have you accidentally shot a fuel canister in Left4Dead already without strapping one to your back and standing in front of your companions - the flamethrower doesn't have any stopping power. So instead of being rushed by zombies, you'll be rushed by zombies. On fire.

The RPG: Midtown USA features lots of military grade equipment. Like Russian made Rocket Propelled Grendade launchers. And General Purpose Machine Guns. I actually thought long and hard about suggesting a GPMG. Until I realised that you'd have to go prone to set it up. And as Counterstrike has shown, going prone just encourages tea bagging... can I point out that tea bagging an AI tank you've just taken down doesn't have quite the same emotional force as someone who is forced to watch you sit over them with the in-game camera? It's funny when someone tries it on a downed comrade in Left4Dead. Because your dual pistols beats their dual... no wait. Lets not go there with this analogy.

Primary fire: Great for busting tanks. And fixed emplacements. Except most tanks move reasonably slowly and you can get at the weak armour from behind. Not charge at you throwing chunks of concrete while on fire (if you're lucky).

Secondary fire: Me... I think you can guess by now.

How failure is fun: Slow loading weapon. Fast moving zombies. Hmmm...

One additional playable special zombie

I didn't quite intend this article to end up as a humour piece. How the best laid plans go awry. But that's what we're talking about here.

One of the best laid plans in Left4Dead is to hole up somewhere while you're getting rushed. If you've got good line of fire and disciplined players you can hold off the regular zombies, push Boomers and melee release your colleagues who get caught by Smokers. Ideally your position shouldn't even be accessible to the special zombies because you've closed the doors leading to it.

So that's what this zombie type does. Force you to move...

The Swarmer

Picture the Candyman. But with flies crawling out his eyeless sockets instead of bees. And pale, decayed flesh, with red raw scars. And no hook. Maybe just the stump of a hand. But you get the idea.

Primary Attack: Melee attacks. Roughly boomer strength. This guy wants to get reasonably close to the enemies. Not boomer close. But faster moving.

Secondary Attack: Fly strike.

The fly strike spits a decayed lump of flesh surrounded by a swarm of flies at slightly further a distance than Boomer vomit. The location the fly strike hits is immediately filled with a cloud of flies which lasts, say, 15 seconds. This has no initial impact, but if any survivor stays within the cloud of flies for more, say, than 5 seconds, they are affected by a denser swarm of flies.

The swarm of flies effect causes the survivor to continuously lose health until either they become incapacitated, or have another survivor remove the swarm of flies effect, using the E key for a short duration.

Fatality: Killing the Swarmer releases a cloud of flies, with the same impact as their secondary attack. (Maybe this guy plays too much like a Boomer).

Sounds: The Swarmer is identified by the sound of the buzzing of flies around it. A intense, angry buzzing as if drawn to a putrid corpse...

Mmm...

Left4Dead Week: The Befriendening

Left4Dead week will feature one short piece on Left4Dead each day this week to celebrate the full release of the game.

Several other bloggers, who shall remain nameless, are delaying playing Left4Dead until they can find some friends to play through with. The call for friends is pretty wide: if you've read any of these blogs, you'll see that they're asking for game tags in the comments post so that they can add their readers to their Steam or Xbox accounts.

I'd suggest that Left4Dead is best played with anonymous strangers. Not because griefing is fun, but because the game's cooperative mechanics brings out the best in people. You must keep everyone alive or you die. Horribly. And I've never had so many Steam friend requests as I have had with people I've played Left4Dead with.

(That's not to say I don't seem to end up taking the brunt of zombie abuse. I've yet to finish a 'movie' - a map sequence in Left4Dead parlance - without being killed between 6-10 seconds before rescue turns up. And everyone else getting away... for the greater good. If not achievements).

Left4Dead Week: The AI Director – Part Three – The Rise and Fall

Left4Dead week will feature one short piece on Left4Dead each day this week to celebrate the full release of the game.

A number of reviews have highlighted the sophistication of the spawn system, so that you never see the director spawning zombies directly - they always appear off screen and then rush you.

What reviewers don't seem to have mentioned as frequently is the way the level design aids and abets this. If you're in a wide open area, you can be sure the zombies will be clambering over a nearby fence, crashing through windows or running over a rooftop. And in enclosed areas, you'll find holes in the ceiling from which they'll pour. The most elegantly designed area for this is the start of the first map for No Mercy, which features in the demo.

An in a post 9/11 world, Valve can't be ignorant of the significance of watching bodies falling through space.

(No Mercy has the best opening area of any of the first maps. For the best opening sequence of a final map, you'll need to play through Dead Air. At which point one of my fellow players yelled Game Over man, Game Over! the second time we watched it through.)

Left4Dead Week: An Open Question for the former Turtle Rock Studios

Left4Dead week will feature one short piece on Left4Dead each day this week to celebrate the full release of the game.

I see Left4Dead has inherited what I like to think of as the ‘grenade problem’. What I mean by this is that the investment required to get the AI to use grenades correctly is too high to justify; and unlike many other AI problems, an intermediate implementation (that is getting the AI to pickup and throw grenades badly) is worse than no implementation at all.

Ironically, the friendly AI bots in Counter Strike seem to use grenades reasonably well, and Turtle Rock Studios implemented this as well. So I was wondering what the issue behind not doing the same in Left4Dead was? And I suspect it is a simple return on investment problem. Left4Dead is intended as a coop game and friendly AI using grenades was well down the list.

(Other than that, great job guys).

[Edit: Robin has suggested an interesting alternative in the comments].

Left4Dead Week: The AI Director – Part Two – The Zombies

Left4Dead week will feature one short piece on Left4Dead each day this week to celebrate the full release of the game.

The problem with the AI director is that I think the implementation works too well for zombies, and won’t be adaptable enough for anything else. The quiet, eerie moments of being unsure whether an area will be filled with mindless undead, crouched shivering in a corner, leaning helplessly against a wall or vomiting up raw chunks of flesh, or completely empty; the variation in threats from rushing hordes, against the lesser special zombies (boomer, smoker or hunter), the adrenal rush of fighting a tank or trying to creep past a witch.

Contrast this with Half-Life 2, where there is a similar variety in enemies, but all of which are pre-figured by the environment you are moving through: no mix of head crabs, combine and Ant Lions together would make as much sense. And the simplicity of the zombie AI will make it hard to have a similar flood, of say, Nazis en mass. Any more intelligence in the enemies than that which the zombies display would dilute the flood to a surge or trickle, as they found alternate routes, held back or hid within the level to wait for you. The techniques used by the ALife in S.T.A.L.K.E.R. makes more sense for the most games: where each enemy has a distinct personality and set of goals to move through large free roaming levels.

Left4Dead Week: The AI Director – Part One – The Musical

Left4Dead week will feature one short piece on Left4Dead each day this week to celebrate the full release of the game.

The AI director works well, especially in conjunction with the musical cues which are used to tell you when you are about to be swarmed with undead en mass. I suspect some of these cues will become repetitive over time – it would be good to mix them up a little with sound cues for the same effect (such as the sound of zombies crashing through a wall, or baying for blood in the distance). I also missed the sound of other people fighting the zombie apocalypse: surely the four survivors can’t be the only people trying to escape the city. The Miles Sound system API in Source works well for this as demonstrated by the sound of gunfire in the distance in Day of Defeat or Half-Life 2.

Left4Dead Week: Destructible Scenery

Left4Dead week will feature one short piece on Left4Dead each day this week to celebrate the full release of the game.

Left4Dead has a reasonably robust implementation of destructible scenery, without reaching the flexibility of Fracture or Red Faction. Elements of the level, notably windows, doors and some walls can be destroyed; mostly by the marauding undead who feature in the game. There’s several nice features of the way Valve has implemented this:

1. There’s no obvious seaming of destructible elements, or any other indicator to differentiate destructible or non-destructible. This means you can never be sure if a wall will be torn asunder as a zombie crashes through it. Some walls do get destroyed too frequently to be a surprise: such as the wall below the collapsed room in the apartments; but I bet you didn’t know that one of the upstairs room walls can similarly be blown apart by a Hunter coming down from the roof.

2. Closed doors block the undead from moving through them - instead they start to bash chunks out of the door in horror movie cliché style. This can be used tactically, such as to hold up a flood of zombies while you shoot them apart.

3. The tank can tear up chunks of concrete and throw them at you. These chunks don’t have any long term effects, but it sure looks good.

4. The fragments of the destroyed scenery end up as physics elements which can be pushed around further, such as when a boomer or pipe bomb explodes.

5. You’re not forced to progress through any destructible scenery yourself: there’s always a route around. This means you don’t have to figure out which part of the map the level designer was hinting you should blow up.

Results for 'What is your favourite element;'; new poll

I guess this new fangled electricity thing is more popular than old reliable fire; kids these days have it lucky. Why in my day I had to cast spells of gravel element, while walking backwards through snow element twenty mile elements to school elements...

Fire	26 (15%)
Water	24 (14%)
Earth	10 (6%)
Air	18 (10%)
Frost	21 (12%)
Poison	9 (5%)
Electricity	33 (19%)
Metal	13 (7%)
Wood	11 (6%)
Nether	15 (9%)
Ghost	10 (6%)
Grass	11 (6%)
Earwax	19 (11%)
Lithium	17 (10%)
Promethium	13 (7%)
Anchor	10 (6%)
Blink	11 (6%)

New poll: having read the description of Unangband schools, which Unangband school of magic would you choose?

The Saga of Bondas the Ironman

There is not enough roguelike poetry in this world.

(For those unfamiliar with the term, Ironman implies that you don't shop, and only ever descend in the dungeon. Extreme Ironman involves taking the first downwards stair you find at every opportunity.)

Designing a Magic System - Part Fourteen (Classes)

(You'll probably want to read parts one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve and thirteen).

In part eleven, I suggested that a class-based system was the most appropriate mechanism for provide alternative spell types. In Unangband I cheat this slightly, and term the choices between different spellbooks schools. When you choose a school, you are actually choosing which spell book you start with, and which spell books are stocked in the shops. Each school has 4 spell books in increasing order of difficulty, which you can learn spells from, and these shape the starting experience as a player.

What experience should different classes provide? This is as much about the significance of the choice of class in the game. In a multi-player game choosing a class is as much about complementing the choices of the team you are on (or all choosing Pyro and spamming the opposition with flamethrowers in Team Fortress 2); in a single player game with multiple avatars, it is about wish fulfillment - what kind of person are you to lead others; in a single player game, each class must be capable of surviving the game on their own. It is a delicate balancing act to ensure that class is not necessarily a proxy choice for difficulty level - although many standard class choices end up having different difficulty curves throughout the game. I believe classes should instead be a choice about playing style.

Roguelikes are uniquely replayable, and class choice can be as much about playing particularly challenging games. On one hand, harder class choices should not be made available to starting players; on the other hand, harder class choices are required to learn and understand various advanced strategies of play. In Angband and variants, mages typically have a hard start and mid game, warriors have a harder mid game, and priests have an easy mid game and potentially hard end game due to their lack of damage output. As further anecdotal evidence, you may want to refer to analysis of the character dumps on the Angband.oook.cz landder.

But I don't want to link spell choices to this implicit difficulty curve - and I have worked to ensure that the start game for mages is easier through increasing mana availability (although at the same time harder, because I have removed the link between mana gained and spells learned - these are now controlled by separate attributes, rather than Intelligence being a catch all for mages and Wisdom being the equivalent for priests). So to me, the playing style argument is the most compelling.

But what do I mean by playing style? Well in Angband, consider the difference in play mechanics between a mage, a warrior and a priest. The warrior is best bumping into monsters one at a time at melee distance, and built to endure frequent mistakes (the worst of which is holding down a direction key and filling the keyboard buffer); the priest is a weak warrior mage, with a ready supply of resets which makes their gameplay style very forgiving; the mage is a glass battleship, and plays more like a game of chess, where each choice has much greater impact and many more choices are available.

The function of schools in Unangband is primarily to facilitate spell choices, and secondarily to encourage different playing styles for mage-like classes. The schools I ended up creating are:

The school of Wizardry contains the most flexible spell selection for defense and a broad and powerful range of direct offensive spells. Wizardry has few weaknesses: no reliable method of
satisfying a wizard's hunger and few spells that can be used to attack an enemy without putting the wizard in harm's way. Wizards should be thoughtful in offense and quick to escape or evade an enemy that exhausts the resources at their disposal.

Aspiring Wizards start with the book of Cantrips.

The school of Druidry contains a wide variety of different spells, include a good low level offense, but is hampered by difficult to use defensive spells and offensive magic that takes a while to get
going and may leave the Druid in close proximity to harm should they fail to work. A Druid operates best when he is able to prepare the ground upon which he fights, and works best in open spaces: conjuring trees, calling forth lightning and fire and so on. This is also the Druid's weakness: he must operate in the open, and takes a while to prepare his magic, which means he can be overwhelmed before his magic can be used.

Novice Druids start with the book of Hedges.

The school of Mastery contains some useful low-level magics, but at higher levels is heavily reliant on the ability to summon and control minions for the great part of both offense and defense. This is a double-edged sword: while the minions are more than capable of providing the Master protection and dealing out damage, he has a heavy investment in them, and will have to pay a 'mana debt' or 'blood debt' should they be destroyed. This reliance on minions means that the tables can turn very quickly on the Master and get out of control.

Wouldbe Masters start with the book of Curses.

The school of Sorcery is both deceptively weak and strong. A Sorcerer lacks the immediate damage dealing capacity of the Wizard and the long term damage capability of the Druid, and does not have the same range of minions as the Master. The Sorcerer's spells and minions are useful in preparing the ground like the Druid, in particular with a range of traps and mimics, and enraging and drawing in the enemy. But his abilities to ensorcle perhaps any enemy, will give him opportunities and gambits far greater than the Master is capable of.

Neophyte Sorcerers start with the book of Glamours.

The school of Thaumaturgy contains the widest range of direct offensive spells, to allow a thaumaturgist to find and exploit the weakness of any opposition. The Thaumaturgical energies at his disposal randomly vary from individual to individual, and as a result, the exact spell selection will vary. The weakness of the Thaumaturgist is a distinct lack of flexibility in defense: with limited and hard to use escapes and utility magics.

Latent Thaumaturges start with the book of Fireworks.

In addition, there is a school for each semi-spell class, that is the Ranger, Artisan and Rogue classes who don't have access to attack magic, but do use a variety of utility spells. The Rangers prefer the Statecraft school, starting with the book of Trailcraft, Artisans prefer the Science school, starting with the book of Trades and Rogues prefer the Spellstealing school, starting with the book of Tricks.

The emphasis for Wizards and Thaumaturges is on spells that deliver damage to line of sight targets only, with the Wizard having the capability of evading or redirecting opponents that get too close, while the Thaumaturge tries to overwhelm them with greater variety of attacks. For Druids, Masters and Sorcers, the emphasis is on indirect damage, through devastating attack spells which take a while to take full effect for the Druid, through pets for the Master and through a combination of traps and usurping enemy assets for the Sorcerer. Indirect damage is lower risk and to compensate, these classes should require more complex set ups to get this damage delivered.

With these thematic ideas in place, and the base framework of spell choices to build it on, it becomes a matter of building the individual spell books for each class to implement these ideas. The spell books as they currently are designed are shown below:

Wizard	Druid	Master	Sorcerer	Thuamaturge
Detect Monsters Wizard Lock Light Area Magic Missile Phase Door Torch Cure Light Wounds Find Hidden Traps/Doors Stinking Cloud Confuse Monster	Detect Life Dryad's Embrace Lightning Spark Moonlight Sting Find Water Purify Self Warp Wood DUST OF SNEEZING	Darkness Chill Detect Evil Shadowstep Sting Blood Binding Infravision Detect Traps Stinking Cloud Find Familiar	Detect Minds Wizard Lock Flee Mind Thrust Temporary Displacement Ignore Pain Infravision Detect Doors/Stairs Ego Whip Force Bolt	Wizard Lock Acid Splash Firewalk Flee Torch Ignore Pain Infravision Thaumaturgic Missile Find Flame Fire Blast
Teleport Self Spear of Light Polymorph Other Trap/Door Dest-ruction Detect Power Fire Bolt Frost Bolt Gauge Magic Lightning Beam Minor Acid Ball Slow Poison Wizard Light Wonder	Sleep Monster TANGLEROOT CALL LIGHTNING Dryad's Tryst Ent's Song Satisfy Hunger Sleep Monsters Turn Stone to Mud Freeze Minor Frost Ball IGNITE BLAZE Snuff Small Life	Poison Missile Curse Monster Animate Dead Sticks to Snakes Change into Bat Slip into Shadows Sense Magic Air Spirit Curse Monsters Fire Spirit Darkness Bolt Fear Turn Undead Summon Lemure Create Golem	ACID TRAP FIRE TRAP FROST TRAP LIGHTNING TRAP Animate Object Change into Mouse CYROKINESIS Enrage Monster Probability Travel Value Magic Rune of Escape Slow Metabolism Gust of Wind PYROKINESIS Spider's Web	Thaumaturgic Minor Bolt Blind Monster ACID TRAP FIRE TRAP Phlogiston Minor Acid Ball Smoke and Mirrors Thaumaturgic Minor Beam Wonder Minor Fire Ball Thaumaturgic Bolt
Minor Lightning Ball Dispel Magic Acid Bolt Lightning Beam II Slow Monster Frost Bolt II Concentration Cone of Cold Frost Ball Recharge Item I	EARTHQUAKE Ent's Seeds Runic Magic MIASMA Ent's Draught Change into Goat	Earth Spirit Water Spirit Wizard Eye Sense Invisible Unseen Servant Dark Rituals Animate Elements Summon Insects Vampiric Drain	Charm Bird or Mammal Change into Cat Charm Person Confusion Charm Insect Charm Reptile Invisibility Mind over Body Mind's Eye Psychic Blast Psychometry	Alt Thaumaturgic Beam Thaumaturgic Beam Acid Ball Alt Thaumaturgic Minor Ball PYROTECHNICS Thaumaturgic Ball Thaumaturgic Minor Ball
Mass Sleep Teleport Other Haste Self Identify Wonder II CHAIN LIGHTNING Fire Ball Fire Swarm Melting Ray	Dryad's Kiss CREEPING DEATH BLIZZARD Mana Pool THUNDERHEAD Tree of Life TSUNAMI TWISTER VOLCANO	Swallowed by Shadow Bind Demon Mass Curse Darkness Ball Summon Spirit Phantasmal Force Banish Evil Release Curse Path of Blood	Domination Thrust Away Psychic Crown Change into Serpent Change into Wolf Charm Monster	Flame's Reach Test Magic Wonder II Arc of Thaumaturgy Fire Ball Thaumaturgic Ball II Thaumaturgic Bolt II Thaumaturgic Bolt III Thaumaturgic Major Ball Thaumaturgic Major Ball II

Key: Spell choices, where an equivalent spell exists for each class in italic

Summoning spells underlined

Direct damage spells in bold

INDIRECT DAMAGE IN CAPS

What is obvious from the above chart, is that the desire to use classes to keep equivalent spell choices separate is in conflict with trying to use classes to keep a consistent playing style. For instance, the thematic linking between Druids and frost spells, and Thuamaturgist and fire and acid spells encouraged me initially to spread the summon elemental spirit spells out to these classes. This of course runs counter to the reasoning that Masters should be the summoning class. But if all elementals are summoned by Masters, then I end up in the same design problem that I highlighted by making all elemental bolts available to the same spell caster.

Even with these constraints in place, I keep redesigning the spell layout for each school. Since designing the first version of chart, I've changed my mind again and moved all the summon elemental spells back to the Master class. I worry that I'll be perpetually rearranging the chairs on this game design Titanic, unable to get off and actually release a final version of the game.

In part fifteen, I'll discuss more design decisions that I made to come up with this list and try to point to a better solution.