Visual refresh (again)

I've done another visual refresh. Please let me know what you think. I decided the old blue and pastel themes were not quite appropriate for a game development blog about hacking ASCII to death.

Hi Slashdot

(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.

Co-op Portal

It seems that we are never likely to get a multi-player version of Portal - or at least one with the Portal gun. I'm suggesting instead a multi-player game with Portal's sensibilities: think of it as a cross between Sven Co-op, Cube (the movie) and Paranoia.

Here's some design suggestions:

Room 1: A button, a door triggered open by the button, and an exit on the other side.

Solution: Straightforward. One person has to stay behind. The trick is persuading which volunteer to do so.

Room 2: A button, a door triggered open by the button, and an exit on the other side. A pile of pistols.

Solution: As per room 1. Alternately, you can kill whomever elects to stand on the button first. This solution is a little non-obvious - in the Source engine you cannot pick up or move bodies.

Room 3: A button, a corridor with two doors both trigged open by the button, and the exit on the other side of the second door. A timer button on a pedestal in the first room triggers a turret in the corridor which kills any one who has crossed through the first door and hasn't made it to the second door.

Solution: Again, as per room 1. The 'dumb sap' sitting on the button can get off at any point, trapping people between the two doors though. He can then wander over and activate the pedestal button and kill them at his leisure. Alternately, any one else can spam the corridor with turret fire. So, who do you trust?

Room 4: A button, a door triggered open by the button, and an exit on the other side. There's a weighted companion cube next to the exit. There's a rack of rocket launchers next to the cube.

Solution: Straightforward. One person has to stay behind. The trick is persuading which volunteer to do so. Usually you can do this by saying 'I'll bring the cube back for you' and then skipping by it, whistling, as you run out the exit. The rocket launchers are for killing anyone who is dumb enough to try to take the companion cube back.

Room 5: An impassable pit of water with a platform that moves backwards and forwards to allow you to cross it. The platform is stationary on your side. A button on your side moves the platform to the other side. A button on the other side moves it back.

Solution: Different tools. Same game.

Any other suggestions? I'm sure there are elements of the game that can be built up to set up Prisoner's Dilemma type solutions, which are a little more subtle than this straightforward killing off process I've outlined. I also like the idea of having a limited number of lives (Clones in Paranoia parlance) which you can come back as and take your revenge with.

[Edit: I've come up with a complete design. Now I need help. See part two for details.]

Why do games (still) have levels?

(If you are looking for articles on Unangband dungeon generation, you'll want to read parts one and two first. If you're just here to find out about why games still have levels, read on. Edit: For those of you coming from elsewhere, this story got Slashdotted yesterday. You may wish to join in the discussion fun there as well, perhaps after reading my follow up blogpost).

Elite, the Metroid series, Dungeon Siege, God of War I and II, Half-Life (but not Half-Life 2), Shadow of the Colossus, the Grand Theft Auto series; some of the best games ever (and Dungeon Siege) have done away with the level mechanic and created uninterrupted game spaces devoid of loading screens and artificial breaks between periods of play. Much like cut scenes, level loads are anathema to enjoyment of game play, and a throwback to the era of the Vic-20 and Commodore 64 when games were stored on cassette tapes, and memory was measured in kilobytes. So in this era of multi-megabyte and gigabyte memory and fast access storage devices why do we continue to have games that are dominated by the level structure, be they commercial (Halo 3, Portal, Team Fortress 2), independent (Darwinia) and amateur (Nethack, Angband)?

1. Resource constraints.

As memory and storage capacity got bigger, so did game size and complexity. In almost all instances, the fundamental limit of a level size is based on a resource constraint of the game-engine. This constraint may be due to total memory availability to store the game, due to performance limits on in-game resources such as textures or game elements (which is why Half-Life 2 has loading screens and Half-Life does not), or due to lack of cleverness (or time to implement) on the programmer's part.

Almost all the games mentioned at the start of this article overcome these constraints by streaming additional data off of the disk as the player reaches the edges of the in-memory map, and through various clever workarounds of engine performance such as converting visible geometry to bit maps when exceeding a specified draw distance (SotC). Elite and its successors such as Spore and Infinity: the Quest for Earth take the different route of procedurally generating content when it is required and discarding it when it has been used to provide a continuous play area.

So resource constraints are a feasible explanation, but not the only one. Valve has implemented streaming technology to improve the in-game performance of Half-Life 2 not once, but twice, for both the Xbox and Xbox 360 platforms. And yet on the PC, what is arguably one of the best games of the year, Portal, there are frequent interruptions in the form of elevator rides and loading screens, the two of which often coincide. And Source engine games are renowned for the corner/corridor/corner map design for separating two levels. Similarly, one of Mass Effects' biggest criticisms is the use of the elevator to hide poorly implemented level loading mechanisms.

(In the event that this degenerates into a semantic argument, I'll define a level as a 'discrete area of game-space interrupted by a either map load or noticeable period of lack of game-play'. What I mean by lack of game-play is limited or no ability to act inside the game, as opposed to the necessity of crouch-rolling through Hyrule field. But I'm basically relying on your smarts to know what a level is when you see it. Before you ask, yes, each game of chess is a separate level).

I would have expected to see games with levels less prevalent, as engines with suitable streaming technologies become more wide-spread. However this doesn't seem to be the cast. Indeed, the CryENGINE behind Crysis, and Id Software engines that support MegaTextures such as Quake Wars are now capable of containing huge game spaces. But both Crysis and Quake Wars still have multiple levels.

2. Design constraints

What I mean by design constraints is the ability for map design to be worked on by multiple designers. Certainly, game design technologies have lagged in a number of areas. It has only been very recently that multiple designers and graphic artists have had the ability to work on the same game-level at the same time. Perhaps the best examples of this is the Forge tool within Halo 3 and Sandbox mode within Crysis. But earlier examples include Cube and Sauerbraten, which allow play and editing of the level geometry with the same engine, as well as Gary's Mod, should anyone attempt to create playable games within that tool. And you could argue that games like Populous and Civilization are based on the mechanism of multiple players editing the game space at the same time.

Without these technologies, a level then becomes a mechanism for splitting up the design process amongst multiple people, turning the production of the game into a factory floor where game 'parts' are built individually before before being assembled into a final product. The assembly of these levels is done through well defined end points, such as the ubiquitous elevators, or even simply by picking up the player from one map location and dropping them into another. Any game that positions you in a helicopter before landing you in a drop-zone is taking this mechanic and making it literal.

Again, technology should improve the ability for game designers to work on multiple parts of the same map at the same time, and so we would expect to see levels decreasing in prevalence as these technologies become more wide spread.

3. Unity of design

You've played games with 'the lava level', 'the ice level', 'the sewer level' and the 'water level'. Unity of design originally arose as a resource constraint issue. Only so many tiles could be loaded in the game engine at once. So by designing multiple tile sets, one for each particular locale, and then only loading the relevant tile set for each level, the game could have a much greater variety of visual elements without hitting the original resource constraint issue.

However, the unity of visual elements in level design has persisted a lot longer than games have had separate tile sets to build a level. To an extent, replace tiles with textures, and it still becomes a resource constraint problem. But it is also as much a player perception issue. Map regions close to each other should look the same. And by having separate levels, each with their own visual look, the player can associate the underlying (abstract) level, with a physical place.

More importantly, the visual design (and sound design) is often linked to game-play elements, in particular the types of enemy that the player will encounter. This linkage is built up through association of visual elements and level geometry with certain enemy types, and then repeating the visual and aural space whenever the player re-encounters these enemies. Think of the association of radioactive waste and zombies, or sand and ant lions, or force fields and Combine in Half-Life 2, or military equipment and soldiers in Half-Life.

But neither a separate visual look, nor associating a game-space with a particular enemy is a requirement for having separate levels. In fact, Grand Theft Auto: San Andreas could be remade as a Half-Life 2 total conversion and through clever design, the association of enemies and visual look of certain areas could be maintained, provided a sufficiently high Combine citadel could be built (and then parachuted from).

4. Linear narrative constraints

First, I blew up the specimen in the test chamber, then I escaped the test chamber lab, then I wandered through the alien-infested offices, then I climbed up the abandoned rail facility to launch the satellite into space... if Gordon Freeman had been able to press a buzzer on the opening monorail sequence and got off one stop earlier, the outcome of the Black Mesa incident may have been a whole lot different. Having levels solves a complex narrative problem, in that through clever use of design, unlockable doors and chest high obstacles, and at last resort, invisible walls, the player is compelled to experience a sequence of events in a specific order.

As a counter-example, the narrative mess that is S.T.A.L.K.E.R. and to a lesser extent the Witcher and Oblivion, show the danger of attempting a linear narrative in an open world. Grand Theft Auto gets away with it because the characters of GTA are more than likely to take time out from an urgent task to steal a car and rob a takeaway. God of War I and II allow the player to navigate back at many points (unless Kratos jumps down a cliff that his bad-ass blades are not tough enough to help him scale again) but the wealth of enemies going forwards and empty ruins that lie behind him is usually good enough incentive to continue. And the constrained openness of the Metroid series is choked at points that require story-telling, by combining narrative events with rewards (Varia suit, freeze ray) that open up new areas to explore.

5. Escalation of skill

Portal is a brilliant study in game-design, because it's levels are not just laid out one after the other, but the actions required to progress within a level are also laid out one after other (until some of the later puzzle rooms). To progress to the next step, and ultimately the next level requires that the player learn a new technique, and master it. The dungeons in Zelda are similarly laid out, so that the tools that the player acquires (one half-way through each dungeon, and one near the end) must be mastered before the player is capable of beating the dungeon. Zelda is interesting in that it has a relatively open over world, explicitly opened up in the case of Windwaker, and then a succession of restricted dungeon levels. Similarly Super Mario World has a hub from which levels hang which may be beaten in any order.

The level mechanic provides guarantee of minimum skill, and similarly is an attempt to guarantee a level of maximum required skill. We've all played games that suddenly ramp up difficulty within a level (Blades of Hades, I name you), but imagine playing a game where you could arbitrarily wander into a zone of instant death (It's called Morrowind). And even in Morrowind's sucessor, Bethesda deemed it enough of a problem that they replaced it with the much hated difficulty scaling system which is loathed to this day.

Similarly, it can ensure that certain required power-ups are held before encountering a boss monster that requires these power ups, but not always. Numerous Metroid speed runs testify to the game-breaking moves that can be made to get power-ups out of order. But it could be game-breaking for a player to encounter a monster which is unbeatable by a power-up mechanic which they do not yet have (The smart designer will have the player rescued at the last second - but even this would look wrong if it was repeatable).

As the number of power-ups and the size of the game-space increases, the problem of ensuring the correct ordering of power-ups and quests takes on Traveling Salesman problem-like dimensions. This means even as computers advance, game complexity will always ramp up faster.

6. Player constraints

Closely related to skill, is the ability of the player to remember the total available options within the game. While geospatial memory can be improved, and studies suggest that game-playing can eradicate supposed gender differences in geospatial memory, it is not infinite. Similarly, the number of separate individuals that someone can know, Dunbar's number, is finite and based on the total brain weight of the species they belong to. Short term memory is even more limited, such that, for example, a player can only recall approximately 7 to 10 numbers without training.

As I suggest, it might be possible to improve all of the above through repeated training. But there are human limits, and the game-play is sure to provide diminishing rewards in return for improving these abilities. And similarly to the resource constraints experienced by computers, an open world is sure to hit the human side resource constraints on memory, and force the player to resort to game-play interrupting memory aids such as quest logs.

Levels provide a natural limit, particularly for multiplayer games, such as Team Fortress 2, which allow the player to memorize the total possible options, much like memorizing a book of openings for chess.

In addition, levels are a great mechanism for limiting the total number of options available to the player. Humans become confused when presented with too many choices, and will limit themselves only to an inefficient subset of the available choices or none at all. There is a natural 'choice limit' that we operate the most efficiency under, and this is a restricted as much player memory is.

7. Reset mechanism

Imagine, if at the end of a game of football, instead of celebrating victory and confronting a new opponent in the league, you woke up the next day, went out and played the game against the same team, starting at the same relative scores as you finished the previous game. While 5 day Test Cricket is interesting for some, the recent domination of the Australian team over all-comers arguably makes the sport less interesting overall.

The level mechanic provides a useful reset mechanism for games. In many instances, all players start a new level on the same footing. Similarly, for games where designers feel that sufficient challenge is required by withholding an auto-save mechanism, the end of a level is a natural point to provide save game facilities (as well as a quick rubdown and shot of Scotch).

Moreover, there are less obvious elements that need to be reset. From a resource constraint point of view, ragdolls and other in-game objects may need to be expired and freed up. In Dungeon Siege, which has a continuous game world, the fact that time was handled as a continuous variable became problematic, and required extensive debugging. Because time was represented by low precision FPU, if the game was played for long enough, time quantization effects would occur. Dungeon Siege also experienced significant problems trying to implement an in-game teleport system, as everything on the map was only located relative to the current game location. For more details, there is an excellent white paper available.

And some game positions can end up in an unwinnable situation for the player. A classic example is in Rogue, where demons can summon other demons in a pattern of exponential growth, forcing the player to escape the level to reset it or die due to the presence in the dungeon of 'too many demons'.

8. Pacing

The level mechanic provides a natural game-pacing mechanism, even if its only to rest briefly during a loading screen. The player cannot hope to continue playing a game at maximum skill and has a natural requirement for periods of lull. The next time you are in an elevator stuck at a loading screen, take the opportunity to stand up, stretch you legs and start the kettle brewing. And reflect on why it is there are still levels stuck in the way of you playing your game.

(More on how this relates to Unangband dungeon generation to come in part four).

Now with added pictures

I tend not to use pictures in my blog, because of the additional time cost of finding and/or generating the art. However, when you're talking dungeon generation, you really need to be able to show what you are talking about. If you've already read the parts one and two of the Unangband dungeon generation articles, have another look...

Unangband Dungeon Generation - Part Two (Vanilla Angband)

(I recommend you start with part one of this article).

The most charitable thing that can be said about the Angband dungeon generation system is that it works. It has survived a considerable length of time in its current state, and looks only now on the verge of being replaced. The algorithm is straight forward:

1. The dungeon is filled with granite (terrain is recorded in a byte size cave_feat array of up to 256x256 in size - the actual dimensions for each dungeon are constant).
2. The dungeon is divided into logical blocks of 11x11 grids.
3. A room type is picked - which fills up a rectangle of blocks (usually 33x11). A random top-left hand corner is picked in the dungeon and the blocks that the room would occupy are checked to see if a room has already been placed there.
4. If it has not, the room is drawn using the room generation algorithm for that particular room type, and the blocks marked as being occupied. In particular, each grid of the room has a flag set called CAVE_ROOM in a separate cave_info array and the 'outer walls' and 'corners' of the room are set to particular feature types to aid in later corridor placement.
5. The dungeon generator attempts to place 50 rooms this way. The edge of the dungeon is then surrounded by permanent rock (to prevent the corridors and player from tunnelling outside it).
6. Then the corridor generator attempts to connect each successfully placed room to each other in a great cycle: room 1 connects to 2, 3, 4... then room 2 connects to 3, 4, ... etc. The corridor generator maps out a single grid width corridor from the centre of the origin room which tries to move to the centre of the destination room (usually in the right direction but sometimes in a random direction). The corridor generator skips over walls 'inside' a room, puts doorways in walls 'outside' a room and moves around corners and the edges of already placed doorways. If the corridor overlaps another corridor outside a room (identified by the lack of CAVE_ROOM flag) it tries to put doors in the right place.
7. If the corridor generator is successful in navigating to the destination room centre, it tunnels out the path it has mapped out. Otherwise it aborts and does not place anything (including doorways and corridor intersections it identified).
8. Once all corridors have attempted to be placed, a random number of objects, monsters, traps and rubble are placed in the dungeon, allowed in either rooms, or corridors, or both. The allocation of objects and corridors is based on depth: usually objects and monsters up to a set depth are allowed, but some room types placed monsters or objects in set locations within the room in depths greater than the current level (Known as out of depth, or OOD).

Fig 1: A false colour image of the Angband dungeon. 'Basic' granite is white, the 'outer' walls of rooms are green and 'solid' walls on the edge of corridor entrances are purple. This is actually from the Sangband based version of the Angband code, which can be seen from lack of solid corners of the rooms and the additional solid walls next to corridor entrances. Note that the 'cupboard' at the top of the southern room is a bug in the tunelling code, caused by the tunnel penetrating exactly the outer wall of the room and no further, then turning around and exiting the room again out the east.
Fig 2: A false colour image of the Angband dungeon. The 'inner' walls of the room are yellow, and are not overwritten by the tunnelling code. The 'inner' walls of the room are placed by the room drawing code, in this instance, as pillars lining the edge of the room.

This algorithm is surprisingly effective. For instance, there is absolutely no guarantee of connectivity in the elements in the Angband dungeon. But the number of instances of Angband dungeons that I've seen with connectivity problems is less than 0.1%. The room types include simple rectangular rooms, rooms built by overlapping two simple rooms, rooms with an inner room, that may sometimes be filled with a set type of monsters (known as pits) and rooms built from a simple design template system called vaults, where various combinations of dungeon features, monsters and objects can be specified in a text file.
Fig 3: An example from the vault text file.

Unfortunately, the algorithm is not terribly robust. It has a number of places which can readily degenerate into infinite loops if the underlying assumptions break, due to the presence of loops with no guard variables. It relies on a number of assumptions that can be broken by vaults designed by someone without an intimate knowledge of the design system: for instance, the corridor algorithm can tunnel through width 1 walls correctly, but not width 2 walls, which are required if a designer wants to create diagonal or circular vaults. To avoid this, many vault designs require that the player manually tunnel through the last few grids because the corridor algorithm is incapable of this task. Pits are horrendously unbalancing in terms of the number of monsters produced in them, and can result in the maximum permitted monsters being reached, so are restricted with a 'crowded' boolean. And finally, the largest and most complicated vaults can only be placed if they are the first or second room type selected, which makes it very hard for a vault designer to specify the correct distribution for these monstrosities.
Fig 4: A false colour image of the Angband dungeon, featuring a troll pit. The trolls are surrounded by 'inner' walls as a hack to ensure they stay together, and the door to the right is placed by the room drawing algorithm. Also shown here are the streamers through the dungeon (% and *) which have be mentioned but not discussed in detail. These are placed after the corridors have been completed and replace existing granite.

But my biggest problem with the dungeon generator, is that it is boring. There is very little incentive to travel around the map. This encourages the tactic of repeatedly climbing up and down the stairs, in conjunction with detection spells or items, until excellent items can be found on the ground - called stair scumming. This is possible because Angband doesn't have 'persistent' dungeons. Each dungeon level is thrown away when the player leaves it, and a n
ew one is generated. To compensate for the dullness of the levels, and to try to discourage stair scumming, the player receives a 'feeling' when first entering a level, provide he has spent enough time on the previous level. But feelings are bandage on a broken system, and this is acknowledged by the presence of an auto-scum option, which automates the process of generating and throwing away levels until a sufficiently interesting one appears.

A number of Angband variants make improvements to the Angband system. The typical variant incorporates a number of additional, more 'interesting' room types, such as mazes, caves and fractal chasms, and usually incorporates a delayed level feeling mechanism, so that the level feeling is displayed only after searching the new level for a period of time. The variant usually incorporates some additional terrain types such as water and lava, which can appear as pools in various room types. Arguably the variant that addresses most of the Angband dungeon generator issues is Sangband, where Leon Marrick once again makes his presence felt. I mentioned previously that Angband was moving away from the existing generation method - it looks like a number of the Sangband dungeon generation routines will be adopted in its place.

But I want to move beyond just piece-meal improvements to the existing Angand dungeon generator, while keeping as many of its parts as possible - for compatibility, to allow me to adopt code from other variants, and to keep my player base familiar with a proven workhorse of a design. And to do that, I started asking some searching questions: What is a level and why do we have them? And why should we have them?

And to answer those, you'll have to wait for part three.

Unangband Dungeon Generation - Part One (History & Manifesto)

(This article series has nine parts: parts one, two, three, four, five, six, seven, eight and nine).

Back in 1992 (or perhaps 1993), a young university student first encountered the Angband source code. He had played Angband frog-knows previously on his father's Amiga 500, and achieved reasonable progress with a paladin at one stage: down to about 3,000 feet. But the source code afforded him new opportunities, and he fired up the Metrowerks compiler in the university lab, and added four terrain features to the Angband dungeon: ice, acid, water and lava. The design was simple; just a modification of the drunken walk algorithm already used to place streamers through the dungeon, and he spent endless hours generating dungeon levels and wandering through them, followed by countless nights of dungeon-infested sleep, dreaming of endless caverns and unlit seas. Never again would his adventures be as successful, as the world of Angband variant development lured him instead.

I'd like to say that that the roots of UnAngband's dungeon generation system can be traced back to that code, but it has been lost in time. Instead, very little survives. I recovered the design of several of the monstrous trees that I had in that proto-variant from a newsgroup post - I can no longer find that post, but there is definitely mention of it in a follow up discussion started by Ben Harrison (I also remember distinctly fighting 'killer bees' I had created, which was an orange 'I'). I also discussed the fact that I thought summoned monsters should surround the summoner, as opposed to the player, which was vigorously argued against, although history has proved me right. In fact, looking at that last link, it describes in detail, my early 'dungeon design manifesto', which I'll repeat here.

Basically, I would like to see a bigger variety of rooms and corridors espec-
ially at deeper levels, including:
* big pits, rooms which are filled with a big pit, bridges over pits etc.
* huge rooms, natural caverns, corridors which are 2 or 3 wide, long hallways,
pillars scattered about big rooms, big doors (if possible)
* statues, fountains, thrones, pedestals, gates, and other dungeon furnishings
* trapped doors, trapped furnishings, traps which activate for a wider variety
of effects (create traps anyone), hidden compartments which are handled as
traps but when disarmed create a GOOD or EXCELLENT drop
* more varieties of rooms within rooms, pits within rooms, rooms within pits,
to the point where some rooms will start to resemble the town level with LOTS
of monsters swarming around
* floor coverings, water, fog, mud, lava, creatures which are invisible in water
(ie SWIM)
* when monsters are generated on pits, they come from deeper levels ("It crawls
out of the pit.") and are not restricted to 25+ distance away. This restriction
shoud also be lifted for teleporting monsters.

Basically, I want the thrill of exploring to be heightened.

Fig 1: A typical Unangand dungeon. The chambers in the right hand side are surrounded by a grass-filled cavern with the occasional tree. Vines and mossy walls decorate the nearby tunnels. However, between the vines, some walls seep blood. Click for a more detailed view.

And lastly, I spent a lot of reprogramming that other Angband time sink: the Angband Borg. Again, this code has been lost. I can only suggest that Dr Andrew White has done a better job and more in the spirit of Ben Harrison's original intentions than I was ever capable of.

UnAngband proper appeared on or around December 2001. I can find a report of version 0.1.1 existing in a Angband variants FAQ and certainly I had progressed enough (in my mind) to advance the version number to 0.4.0 by mid-2001. My announcement post included a feature list that will seem familiar to the 'modern' Unangband player and long enough to impress Eric Bock, while accompanied by mild consternation by many that they couldn't access the website I was hosting it on nor download the executable from the ftp server. My, how things haven't changed. If anyone can locate a link to the original usenet posts where Robert Ruehlmann suggested that I call the variant UnAngband, that would be much appreciated (It may have actually been an IRC conversation, so don't search too hard).

Of particular relevance from that later announcement, is the description of UnAngband dungeon generation at the time:

Features added to the dungeon include new traps, water, ice, lava,
mud and chasms. These are detailled in f_info.txt and
defined using additional fields and flags documented in the same
file. Monsters should be able to traverse various terrain types
depending on additional flags in r_info.txt. Lakes and rivers
will be generated through some dungeon levels.

Room descriptions have been added. These are displayed when a
player lites up or enters a room. Room descriptions can also add
extra monsters, objects and features. See d_info.txt for details.

I can tell you that the dungeon lakes were still being generated at that point by a drunken walk algorithm, and rivers by a modified version of the streamer code.

If it's not clear to you why I'm discussing the history of the Unangband dungeon generation code, it's because I want to emphasize how long exactly I have been thinking about dungeon generation for, and how I have ended up with a monolithic 11,852 line generate.c file, 953 distinct feature types, 23 high-level room types, another 805 'room description' lines which may be combined in a number of ways, 64 separate dungeons in a linked wilderness, all of which together drives the Unangband dungeon generation routines. The Unangband dungeon generation code also has not existed in isolation: there has been considerable cross-pollination between it and other Angband variants - firstly with EyAngband adopting the Unangband room generation code, and then both Hengband (now Entroband) and NPPAngband adapted the Unangband feature types with considerable modification in both instances. I have also borrowed extensively from the NPPAngband and Sangband dungeon generation routines as well as spending more time than perhaps is healthy getting to understand the Zangband wilderness generation code.

And I'm finally in a position where I can confidently say that dungeon generation in Unangband is a 'solved' problem, and I am happy with the final result. I still want to completely rewrite wilderness generation, but that is a version 2 item, and one I'm happy to put aside for a while. I'll also steal FAAngband's 'full wilderness levels' at some point in the near future, but I don't feel a compelling argument for them, and without the FAAngband wilderness to go with it, those levels can seem empty and hard to explore.

So what does UnAngband dungeon generation deliver and how (and why)? Well, to understand that, you need to understand a little about Angband dungeon generation, and what the benefits and drawbacks of that are. And that is a discussion I'll be saving for part two.

Unangband 0.6.2-wip7c has been released

This release fixes some significant game-play logic bugs for the competition, as well as an overhaul of the wilderness map. I particular want to thank Mikolaj Konarski again for his beautiful ASCII art map, adapted from FAAngband's wilderness map designed by Nick McConnell. Mikolaj also reported the majority of bugs in this release, as well as fixing about half of them.

Please check the Unangband home page at http://unangband.blogspot.com

This is why you choose open source

My main co-developer of the moment has designed a beautiful ASCII art map of Middle Earth with the relevant Unangband locations. You can see it here. It's already got me thinking about how to expand on the mid-game locations more.

At the end of it all, it is a great time for video games

What are you playing at the moment?

Vs mode

I've just discovered the game critical geek overload that is Vs mode. Or at least, I discovered it yesterday courtesy of a link in GameSetWatch to a You Tube based screenings of the Meta Game and have only begun to surface my head from drinking from its depths.

There's probably a good half a day worth of reading in that first link, so steady yourself before you jump in.

And when you come back, feel free to share your 'most profoundly moving' moment in gaming here.

For me: the head camp bombing of the refugee encampment in Half-Life 2. Suddenly I wasn't in a game, I was in Halabjah, and people around me were dying. And there was nothing I could do so save them.

(If you can't remember it, it was one of those blink and you missed it moments of greatness in that game, towards the end of the Route Kanal chapter).

Poll results for 'What kills your characters the most?'; new poll

The results for 'What kills your characters the most?' are in. Less participants in this poll, I suspect because of the Angband-centric nature of it. The final results are:

Cave spiders	2 (10%)
AMHDs / Drolems / Dracolisks	1 (5%)
Stormcrows	0 (0%)
NPPAngband 0.4.x hydras	0 (0%)
Battle-scarred veterans	0 (0%)
Boredom	7 (35%)
The keyboard buffer	7 (35%)
Playing while drunk	1 (5%)
Playing after midnight... must... sleep... damnit...	8 (40%)
Retirement, 'Hi, I'm Timo/Neo'	0 (0%)
Other: I'll tell you in the comments section	1 (5%)

The next poll is 'Which articles have you most enjoyed/found useful?'. Just looking for some feedback on where I should be producing content. If you've got any specific requests, please add them to the comments below.

I'm tentatively thinking about producing another big article series on Unangband dungeon generation, as well as some smaller pieces. Also, would it be more helpful if I included more technical detail including e.g. diagrams, or am I writing at about the right level? Or would you rather I went back and extended on some of the existing stuff I've written?