Sunday, 29 March 2009

I always enjoy the coverage of the Game Developers Conference every year - I have made a promise to myself that I will attend next year - but this piece from the Experimental Game Sessions caught my eye:

Derek Yu’s closing session was an exploration of roguelikes—procedurally generated dungeon exploration games. “The most exciting things about these games is that each time you play them they are different,” explained Yu, but he found it disappointing that so many roguelikes somehow offer similar experiences, relying on traditional fantasy settings and turn-based, top-down gameplay.

1. Test and finish region code for trap implementations.2. Runic tattoos.3. Create fake objects for shape and racial abilities.4. Replace existing earthquake / destruction code with projection based code (mostly done).5. Allow auto-activation of artifacts and coatings when the player is struck.6. End of game dungeons.7. Release work in progress release.8. Play test.

To do list for 0.6.4:

1. Implement persistent levels.2. Algorithmic balancing of spells including thuamaturgic randomised spells and randomised object and artifact activations.3. Revise load/save code.4. Start implementing gui based code including gui to term glue.5. Support for buttons and context menus.6. Platform support for Nintendo DS.7. Investigate the use of LLVM.

Wednesday, 25 March 2009

As a part of a discussion on resurrecting the Tcl + TK port of Angband, darke mentioned briefly that he's ported Unangband to the Ogre engine. This leads into a discussion about the use of #ifdefs vs if(), C89 vs C99 and plug-ins vs abstraction. Interested? You'll have to read the growing angband.oook.cz thread.

Oh, and for those of you expecting renders - porting to an engine is a little different from 3d modelling...

Saturday, 14 March 2009

I promised I'd post my 8PRL design in the article discussing what an 8 pixel roguelike is. You'll want to refer back to that article to see what the colour abbreviations below mean.

Visual Display

The following colour values represent elements in the game:

d – Floor – the player and monsters can move on this.

w – Wall – this blocks the player and some monsters

g – Player

r – Monster – there are a number of monster types. Each level has a different monster behaviour that the player must overcome.

o – Spell – some monsters throws spell attacks at the player. The player can also find spell attacks to use.

y – Item – there are a number of item types. The player picks up items automatically. When a player picks up an item, the screen temporarily changes to a picture of the item in yellow pixels.

v – Exit – the player must get to the exit on each level. Some exits are locked – a picture of the item required to unlock the exit is displayed when the player steps on the exit.

B – Door – the player can walk through doors, but it blocks (some) monsters, as well as spells.

b – Water. Each step a player takes through water costs them one life.

t – The player in water

g – The player affected by a potion.

Monsters

Each level has 8 monsters of the same monster type. Monster behaviours varies from level to level. The player can kill any monster by bumping into it, except some monsters require two bumps to kill. If a monster bumps into a player, it does one damage to the player’s life.

Monster behaviours are:

Exits encountered

Monster

Dungeon generator

0

Monster moves randomly two steps per player turn, choosing from any available adjacent direction

Open rooms with some corridors

1

Monster moves towards the grid occupied by the player, moving one step per player turn. If it is not possible to move towards the player, it stands still.

Open rooms with some corridors.

2

Monster sits still. If the player is in line of sight of the monster for two turns or more, the monster fires a spell at the player’s position the turn before, which does one damage.

Cave like maze with pillars

3

Monster moves two steps per player turn, always turning right when it gets to an intersection. This monster requires two hits to kill.

Maze with loops

4

Monster moves towards the player one step every two player turns. The monster can pass through walls and doors, but not over water. This monster requires two hits to kill.

Open rooms with some corridors. Some rooms are filled with water; except for a width 1 border around the room which is floor.

6

Monster moves one turn per player turn. If closer than 4 grids, the monster moves away from the player; otherwise the monster moves towards the player. If the player is in line of sight of the monster for two turns or more, the monster fires a spell at the player’s position the turn before, which does one damage. This monster can pass through doors.

Open rooms with some corridors.

Higher level monsters combine the effects of existing monster abilities to make them tougher.

Inventory

The player can select to use items from their inventory by using the second button, which displays the item in yellow pixels on the screen momentarily. Repeatedly pressing the second button scrolls through the available items. Pressing the first button uses the item selected.

Items are automatically picked up when stepped on if the player can carry them – the player can only carry 3 items and must use an item to carry more. If no use is for the item is specified in the table below then using the item drops it to an adjacent grid with the player specifying the direction to drop the item.

Item

Use

Key

The key opens the exit. The player must find and pick up the key to open one exit on the level. If other exits exist, they require the player sacrifice another item. The player can only carry one key.

Potion

The potion heals three life when used, and prevents the player from being hurt by monsters, spells or water for three turns.

Mushroom

The mushroom heals one life when picked up. The mushroom is not carried.

Wand

The wand fires a spell in one direction, which affects all grids in that direction up to a wall or door. The wand is then destroyed.

Staff

The staff fires a spell at every grid adjacent to the player, which affects all adjacent monsters. The staff is then destroyed.

Arrow

The arrow fires a spell in one direction, which affects the first monster it hits, or stops one grid before an obstacle (door or wall). If the monster is killed, they are replaced by another arrow dropped at the grid the monster is hit; if the spell is stopped by a wall or door then the arrow drops to the grid before it – however if this grid is not a floor then the arrow is lost.

Scroll

Using the scroll causes the player to teleport to a random floor grid on the same level.

Occasionally people want to email me questions about games and game design, writing and so on. If you do, my email address is firstnamelastname@gmail.com with the appropriate substitutions. Please try to avoid the gmail spam filter as I receive enough spam to make it not worthwhile checking the spam traps.

However, unless you're pathologically shy, my recommendation is to post your question in one of the comments here. That way everyone reading this blog can benefit from your intelligent questions and my rambling, off-topic answers.

In that vein, I periodically wonder if I should have web forums for Ascii Dreams - because the comment section is so limiting in many senses. I usually decide against this, because Unangband players are well served by the forums at angband.oook.cz and roguelike developers by the rec.games.roguelike.development news group. My attempts at setting up forums for procedural game developers are a less than resounding success.

Sunday, 8 March 2009

So much of what I find myself doing these days with Unangband amounts to house keeping (I've called it refactoring previously - apparently incorrectly). That's a good sign, because it means the game is mostly working.

That's not to say there are still not significant changes going to happen between now and the version 1 release. The two most significant changes yet to come are persistent dungeons, and quests, with item creation code a short step behind.

Recently, I've been working on the region code, but the total impact on the player will be some additional druidic spells and more interesting traps. It won't fundamentally impact the game play but it has been months of code development (I don't have much spare time at the moment).

And I've been holding off adding some additional timed effects, such as timed feather fall, because I wanted to move across to Angband's new timed effect code (by timed effects, I'm talking about effects that apply persistently to the player). I did the jump yesterday - thinking it'd be a small change.

Six hours and what feels like thousands of LOC later, I've implemented this. The actual change wasn't that complex. But it turns out that timed effects are used throughout the code base. And the cascade effect was that it was often easier to rewrite other parts of the code at the same time than to manually go through and change that code as well. I've partially moved skills at the same time to the Angband skill implementation. I could have changed the code displaying timed effects on the screen at the same time - but I'm waiting on Angband to prove its new interface model before I do. I've still yet to update the self knowledge code to include the timed effects - simply because I was worried about making mistakes (most common coding errors seem to occur towards the end of a large coding period because I tire and lose focus).

One advantage that has come out of this development work is a game design error I've made can soon be removed from the code.

Some time ago, I added the ability for spells that the player cast to appear as objects in equipment slots. These objects would temporarily replace any existing equipment in that inventory slot - essentially allowing the caster some zero weight swap kit, at the cost of giving up an existing piece of equipment.

Unfortunately, it turns out the cost of sacrificing the use of existing equipment is always too high. Angband - as I've said many times - is a game of inventory management. And the spell ideas that I can come up with are always too weak or ill-matched with the players remaining equipment, and are almost always useless for most of the game.

This is even worse for shape change spells. When the player changes shape, in Unangband, one or more of their equipment slots has a spell item created in it, to reflect the shape of the monster that the player becomes. As a result, it's almost never worthwhile changing shape.

Both ideas are great concepts that just fail in practise. I should have known - because so much of the code is devoted to inventory management that these quick hacks would prove useless. I'll be amending the shape change code so that it doesn't create objects, and removing the timed equipment creation spells.

But both these features will be back - in particular it turns out the timed spells as objects has mileage.

I mentioned above that timed effects are used throughout the code base. It turns out that a large part of this is because Unangband often has checks of the form:

I could simplify this considerably if I change this to (player_has_flag) where that flag is set by either equipment or a timed effect. And one way of representing this is by allowing time effects to be specified like other objects, but allow an infinite number of them to be applied.

There are a number of complications. The main two are:

a) Angband has a tradition of allowing one flag from equipment to accumulate with one temporary effect, but no further. For instance, temporary resist acid is cumulative with permanent resist acid, but permanent resist acid from multiple pieces of equipment don't stack. I'd like to continue some of this tradition in Unangband (where resist acid on equpment stacks, but temporary resist acid behaves differently - by not protecting the player's kit, providing better protection against environmental effects and so on)

b) Unangband tracks which equipment could be providing a particular flag. Having temporary effects that could provide the same flag complicates this tracking. But I have to deal with this complication at the moment, and so a more general solution would help considerably.

Again, I had a long hard think about whether I should have included this in the original code changes - but it would have complicated and extended the implementation even further.

Wednesday, 4 March 2009

It's always a pleasure reading about people playing your game - and one of the more enjoyable players is HallucinationMushroom. Hallucination is a melee specialist - that is, he doesn't play the game using any tactics other than melee, so it was especially gratifying seeing Orcly the Gladiator figuring out one important Unangband melee tactic (see the link for details). The Angband ladder at angband.oook.cz allows you to upload your character and make regular progress reports and my co-developers and I are always quick to respond with advice and encouragement should you upload an Unangband character.

One thing Hallucination has highlighted is that there is not enough healing items for a warrior player in Unangband - or at least the frequency of drops needs to be adjusted. Unfortunately, this could affect game balance, because Unangband mages are well-balanced by not having a healing spell which allows them to recover more than 300 hit points at a time, and too readily obtained healing items would render this disadvantage meaningless.

I've written about healing in Angband before and one of the items I suggested be made a more powerful healing item was potions of Berserk Strength. In Unangband, these heal 30% of your hit points when quaffed, but prevent you from casting spells or using ranged attacks for a limited duration afterwards (it also alters your combat stats in various ways).

It seems to me that the best way to balance the additional healing items would make them similarly constricting for mages.

One idea would be to reduce the player's mana in return for some reasonably powerful healing effect (there are items which do the reverse already). Perhaps a scroll of Contingency which drains all mana in return for a teleport effect and 50% hit point recovery. Often times you want to both heal and teleport in the same turn - but the drawback is significant enough that you'll only use this as a last resort (unless you're a warrior, of course).

Another would be a timed healing effect, with a drawback that prevents you from casting spells until you are fully healed. I was thinking of a silence effect, perhaps calling it Solemnity, but it's equally tempting to create a mixed effect mushroom of Hallucinatory Healing.