Only two roguelikes came close to challenging the winner and runner up, and these were the revisioning of a golden oldie and a relatively new entrant which is already proving exceptionally popular.
Dungeon Crawl Stone Soup is a variant of Linley's Dungeon Crawl that's openly developed and invites participation from the Crawl community. It features tactical choice rich game-play and well-thought out game mechanics and skill system.
Incursion: Halls of the Goblin King is a D20 based fantasy roguelike by Julian Mensch that features deep game mechanics and a 'next-gen' religion system. It's possible to win this game as everything from a warrior or summoner or assassin or even a diplomat, and starting characters are considerably more powerful than many other roguelikes.
I'll be posting the full poll results tomorrow, as well as a new poll for the New Year. I promise to be a little better organised and publicise this more widely next year, for those of you who missed out on this years voting window.
Monday, 31 December 2007
Only two roguelikes came close to challenging the winner and runner up, and these were the revisioning of a golden oldie and a relatively new entrant which is already proving exceptionally popular.
Well, what a contrast. The runner up to Dwarf Fortress is a self-described 'fast and furious coffee-break' of a game, not so much inspired by Doom as an overhead ASCII remake of the original game. DoomRL comes complete with the original Doom MIDI files for that authentic experience (pending ID Software suing the author for copyright violation) and features everything you'd want from the original game minus John Carmack's graphical programming skills.
Again, DoomRL only featured a few releases in 2007 in order to qualify, but a positive review by John Harris in April was one of the highlights of the year. John said at the outset 'DoomRL is a game I did not expect to like.' and proceeded to heap praise on it for precisely failing to follow the conventions of the roguelike genre. Kornel Kisielewicz of Chaos Forge has chosen to follow-up the success of the original game with others from the same template: with AliensRL and updates to Berserk! this year in addition to DiabloRL and the Valkyrie library from which most of these games are built.
To learn more about DoomRL, you can read the wikipedia entry, visit the DoomRL wiki and join the forums. You can download DoomRL here.
Firstly, a big thanks to everyone who voted. I have to say, this is an intriguing choice.
Dwarf Fortress has had a great year - or at least an interesting one. From January to the end of October, DF fans had to go without any new releases, except an ever growing change log to sate their rapid appetites for complex game play. In March, the epic re visitation of Boatmurdered, Dwarf Fortress's most well known and beloved fortress concluded with a whimper, rather than a bang - but leaving horrific legends of elephanticide in its wake. And the October 29 release of version 0.27.169.33a forced long time fans to deal with the dreaded z-axis - a monster only rarely unleashed on roguelike players, except through the abstraction of a nice set of stairs.
But at the same time, Dwarf Fortress has become the critical darling of the 'mainstream' games media, and set a new bar for what indie and amateur game developers can deliver. And midway through December, the release of a 3rd party graphic visualisation software suggests even those averse to ASCII graphics may have a graphical option to play with at some future date.
To learn more about Dwarf Fortress, you can read the wikipedia entry, visit the Dwarf Fortress wiki, and join the forums. You can download Dwarf Fortress here.
Sunday, 30 December 2007
My latest column for GameSetWatch has just been put online. It's a little more 'Angbandy' than I would normally write for them. Have a read and let me know what you think.
In related news, it looks like Thomas Biskup, the author of ADOM, may be releasing his next roguelike in 2008. Because we need more competition.
In a follow-up to my musings about the relative sizes of roguelike game communities, I've just queried Google trends for a quick analysis. The results speak for themselves.
What I don't understand is why Finland tops the query list on all three. Could someone Finnish explain the resonance between that republic and roguelikes?
Saturday, 29 December 2007
If you've been enjoying the articles on the Unangband dungeon generation algorithm, you may want to have a look at the Writing Kode blog, which has a much more in-depth look at a dungeon generation algorithm, along with complete code examples.
I tend to not include code in my articles, simply because I'm trying to explain stuff at a 'higher-level' without necessarily getting implementation specific, and because the entire Unangband code base is browsable online, and hopefully reasonably well commented. And the 'why' is always more interesting than the 'how'.
In other roguelike development news, Ed Ropple first posts on rgrd with a SDL based roguelike rendering engine using the Mono and .NET frameworks.
Thursday, 27 December 2007
Wednesday, 26 December 2007
I rashly criticised a few games recently for having unwieldy names. This is coming from an author of a game called Unangband: The Unnamed Angband: It Doesn't Have a Strapline Either.
What's your favourite game names? Your least favourite?
I'd have to go with S.T.A.L.K.E.R.: Shadow of Chernobyl for not only being impossible to type and forcing me to look up how to spell Chernobyl every time I want to, but having the goddamn spawn of Cthulhu combination of two differing forms of punctuation sitting next to each other. It's an abomination for your eyes and Microsoft grammar checker.
(You probably want to start with part one, then read parts two, three, four and five).
Implementing the terrain features in Unangband is what drove me to create an Angband variant in the first place. My initial attempts were to limited to adding acid, lava, water, chasms and ice, but the feature set has grown to over 950 different terrain types and keeps expanding all the time. What sorts of features are currently available? Well, everything from chests, wall decorations, traps, levers, machines, boiling acid, hidden vents, waterfalls, chasms, poisonous waters, vine-choked corridors, and mud-filled bogs.
The link between features and objects is a subtle one. In fact, there is arguably a continuum between between features and objects. In Angband and variants, both features and objects are laid out in the dungeon in a rectangle grid array. Objects however are allowed to stack in a pile, and can be picked up by monsters and the player. Features are not - only one feature can exist per cave grid (exactly one in fact). But many other tile-based games allow up to three features to exist on a grid, particularly for games with an isometric display (the three features are usually a floor type, a wall type and a wall decoration).
So whether a 'thing' is a feature or object is plastic, and very much subject to differing points of view. For instance, where does a chest lie on this continuum?
In Angband, the argument is a chest is an object. It can be picked up by the player, and sold. But in Unangband, a chest is a feature. The reasoning is that this simplifies the open and closing code, and allows chests to use the feature trap selection code. Traps are similarly a mixed proposition, and Angband itself has had versions that treated traps as objects, and more recently as terrain features. Unangband does both. Traps that the player finds within the dungeon are features. But traps that the player sets themselves consist of both a trap feature, and an object. Each object type has a corresponding trap type, so that, for instance, trip wires are associated with wands, and dragon armour can be set as strange visages. Many variants hold traps in a separate structure completely, and this may ultimately be what Unangband does.
Whether a 'thing' in Unangband is a feature or an object depends as much on how features and objects are defined. In Unangband, features can obstruct player movement, line of sight and line of fire, whereas objects cannot. Features can also 'transition' from one feature type to another. Much like most things in Unangband, features are defined through a data-centric approach and loaded from a text file (lib/edit/terraint.txt) at the start of the game.
A few example features are given below:
#$# wooden deck over chasm
F:LOS | PROJECT | REMEMBER |
F:HURT_FIRE | CAN_CLIMB | CAN_FLY | CAN_PASS | CAN_OOZE |
F:ALLOC | GET_FEAT | EASY_CLIMB | ATTR_LITE |
#$# magma vein
#$# lava fall
#$# deep lava under a magma crust
#$# deep lava under a stone bridge
F:LOS | PROJECT | MOVE | PLACE | REMEMBER |
F:BRIDGE | RIVER | LAKE | GLOW | LAVA | SHALLOW | HURT_FIRE | CAN_FLY |
F:HURT_WATER | OUTSIDE | ATTR_LITE | TIMED |
N:956:the hut of Radagast the Brown
F:LOS | PROJECT | MOVE | NOTICE | REMEMBER | ENTER | PERMANENT |
F:GLOW | CAN_FLY |
F:OUTSIDE | ATTR_LITE |
D:A note on the door says 'Refugees welcome. Back soon. Radagast'.
The N: line defines the feature index and feature name. The G: line defines the graphic and colour of the feature (colours are encoded as various letters). The O: line defines an object associated with the feature, which may be recoverable from the feature if it has a GET_FEAT flag set, or allows the feature to act like an object if it has the USE_FEAT flag set.
The W: line defines the frequency which the feature appears in the dungeon, and priority when displaying it on the mini-map. The K: lines define the state transitions for the feature - to help I've included comments under each transition as to what the feature it turns into, when affected by a particular transition.
The F: lines define various flags associated with the feature. There are 96 possible flags in all (but should really be increased), ranging from what the player and monsters can do to the feature (such as OPEN it), how the feature can be moved through (CAN_FLY, CAN_OOZE), how the feature affects objects in the grid (if HIDE_ITEM, it causes them to disappear from view) and so on.
And the D: line provides a description if stepping on the feature.
The list of features in Unangband has grown large because features serve a number of different functions:
1. They define the dungeon topology.
This can be as simple as dividing up the dungeon into rooms and impassable locations. This is done by attaching properties to various feature types such as allows line of sight, allows movement, and so on, to directly affect the ability of the player and monsters to traverse the feature types. Similarly, the topology can be manipulated through the player (or monsters) interacting with the terrain. A simple example is doors, which can be opened, or closed, or spiked shut or bashed through.
2. Features are associated with various monster types.
The relationship between monster types and features is defined in the room description code outlined earlier. With a large variety of feature types, a large number of different associations can be made.
3. Features provide a reason to explore the dungeon.
Much like chests can contain objects, many other terrain features require interaction with the player to release their contents. Mineral veins can contain buried gold. Similarly rubble can contain buried objects, fountains, middens and basins can hide items inside them, and painted walls must occasionally be bashed down to reveal hidden treasures.
4. Different features are used to distinguish degree as well as kind.
Instead of creating additional data structures to represent information that may only be relevant for particular feature types, several feature types can be used to encode these values. For instance, there are 8 doors types in Angband that are used only to distinguish the difficulty for picking the lock on the door. A scalar quantity like this could be encoded with a separate cave_power array for each grid, but this would be useless for 99% of other feature types. In fact, eight different door types is probably too many: it's only really work distinguishing three or four different difficulty levels from the player's point of view.
5. Different features are used to distinguish different terrain 'states'.
If you have a feature set that contains water, sooner or later you'll make waves. One of the earliest decisions I made around the implementation of features in Unangband was to define feature transitions as a finite state automata. Each feature has a list of transition types such as OPEN, CLOSE, SPIKE, HURT_FIRE, HURT_ACID and so on, which when a particular event occurs. This allows, for instance, wooden features to catch fire, metal features to dissolve through acid, and so on, by defining the results of each of these in data, as opposed to code.
But not all transitions have to be player activated. Five transitions are time dependent and independent of player or monster interaction. These transitions occur either all of the time (INSTANT, ADJACENT) or randomly (ERUPT, STRIKE, TIMED). The difference between each of these transitions is the way it applies the feature 'blow type', while transitioning. Adjacent affects all adjacent squares with the 'blow type', erupt out to radius 2, strike looks like a lightning bolt.
Because these transitions occur on a regular grid, it becomes possible to define Game of Life -like and machine-like behaviour. There is a set of features that through opening and closing adjacent features, can be used to link together complex on map behaviours. These include chains, valves, gates and so on.
And with these combinations, it becomes possible to make dynamic waves in water. Any water terrain hit by water damage (HURT_WATER) turns into the crest of a wave. The crest of water hits all adjacent grids with water damage, and transitions into a wave. The wave transitions the following turn into 'rough water'. And the rough water does nothing, but transition the following turn into normal water. This double-transition is designed to create the trailing edge of the wave, as a 'buffer' zone to prevent the crest advancing back against itself.
Similar transitions are used to create pools of lava which dynamically heat and cool to allow a safe crust traversable by the player, some of the time, and glacier-filled lakes, which feature blocks of ice crashing from the ceiling, and ice growing up from the floor. The dynamic terrain also allows clouds of smoke, acid and steam to swirl around cave floors, without having to specify a separate cave_air structure, and fires to burn across grass or through forests.
6. Features are easy to build in a 'data-centric' design
I've mentioned previously that the Unangband approach has been to take a data-centric design approach. This often results in me designing the data file structure first, including some samples of what I want to achieve, then writing a parser for the data file, and finally implementing the code required to implement the attributes that this data has.
This data-centric approach allows rapid development of additional feature types. In fact, what has driven most of the terrain development has been combining ASCII characters and the fifteen colours that Angband currently supports, and trying to figure out what the result may be. (Hmmm... light green asterisk. What could a light green asterisk in the game be? The answer ended up being a vine-covered granite wall.)
But as important as a data-centric approach has been merging the possible game spaces. What do I mean by this? You'll have to read part seven.
Are you actually playing the game in 'Adventurer' mode? Or are you trying to stretch the definition of roguelike to encompass a turn-based strategy game that uses pseudo-ASCII graphics?
I'm genuinely interested to hear people's experiences with Adventurer mode. As far as I am aware, it's a great way to interact with abandoned fortresses, but at this stage is not necessarily a fully fleshed game.
I've just replied to a query about Unangband on the angband.oook.cz forums, that I'll expand on a little here as it's relevant to game design.
Another, when traveling in the wilderness, would it be possible to automatically, or something like that, eat something that is in your pack. Instead of arriving at your destination weak from hunger when you have food in your pack. I am sure there are others, but don't see much of a point in bringing up too much since the game isn't really complete yet and I don't know what is coming.This is the old 'I don't want to have to think about x so can the game do it for me?' argument.
I'm actually a fan of this particular argument. As a game designer, I'm never able to make my mind up about which features work, and which don't, and which choices are interesting and which are not. For any designer shocked by that statement, consider that you really don't know the answers either: you're just guessing. Only user testing can tell you whether you've made the right choices (Play testing is a good substitute, but may just tell you that you find yourself interesting - not the most productive of strategies).
There's always a risk in balancing any changes that automate player actions, as you can end up with a game that gets played automatically for you. Don't be discouraged if this occurs. The popularity of Final Fantasy XII, Progress Quest and the Angband Borg screen saver suggests that automatically played games are a great untapped genre. Although Dungeon Siege is a great counter example of what not to do. (I mean, the whole point Diablo was to see how fast you could wear out your mouse and/or development Occupational Overuse Syndrome. Automating the clicking just misses the mark).
I've tentatively sketched out a 'gambit system' design for a future verison of Unangband. Although I've borrowed the name, I have no idea how similar it is to Final Fantasy XII as I've never played it before. I'll acknowledge that Unangband has a heck of a lot of different things to do and remember, and the more time you get to devote to choices about how to fight monsters and not which flavour of food to eat, the better. So the 'gambit system' will allow you to 'programmatically' enhance game play through allowing you to specify automatic player actions using a 'if in this state' --> 'do this action' mechanism.
But ultimately, you want to replace a 'way of automating uninteresting decisions' with more intelligent game mechanics. For instance, Angband has various resistance spells, which run out after a short time. It makes a lot of sense to allow the player to automatically recast these, provided that you're in a place where you can do so safely. But the annoyingly named Incursion: Halls of the Goblin King makes even a smarter design decision, which is to allow the player to have the spell cast permanently, in return for sacrificing some of your maximum mana amount.
The mini-game is another way of enlivening otherwise uninteresting decisions. I'm in the midst of even worse named The Legend of Zelda: The Phantom Hourglass (two 'The's in the title being almost as bad as two colons), which still features atmospheric/dreary (delete one) sailing around islands from Wind Waker, but replaces the 'gee I have to watch the same unskippable animation' feature of hauling treasure up from the sea floor, with a 'guide the salvage arm' to the treasure mini-game. Much like Okami's mining game, it's not all that great, but at least you get to do something.
For the record, the only worthwhile in-game mini-game I've played is the hacking subgame from Paradroid. And that is as central a mechanic to the whole game as running around shooting droids. I suspect that the puzzle mini-games of Puzzle Quest are just as fundamental to the game play (The DS version of Puzzle Quest wasn't in stock, which is how I ended up with Zelda).
Monday, 24 December 2007
A seven day roguelike is a programming challenge to yourself wherein you write a complete roguelike in 7 days. The 7DRL events are run on rec.games.roguelike.development on an annual or biannual basis, and were inspired by Joseph Hewitt's Dungeon Monkey. Not only are they are a great opportunity to test your coding skill, but they allow you to quickly prototype or explore a particular game mechanic.
A quick sampler of six follows:
You Only Live Once: The central game mechanic turns a prototypical roguelike into a poignant meditation on life and death. To say more would give away the delightful surprise at inevitable failure.
Letter Hunt: Spelling hurts in a labyrinth of letters where you must overcome 52 different monster types in order to write words.
Save Scummer: Makes Progress Quest look progressive.
Bone to Be Wild: Summoning Gone Wrong: Two bad puns by a Dark God reveals a tech demo gone right.
ChessRogue: Mate in 3.
2DRL in 2K: In Fuerst, review longer than game source code.
This is a work in progress (and moreover interim, by Bandobras) release, so please save often and report bugs. Savefiles are compatible, unless the level you are on has fallen out of the levels range of the current dungeon, so it's safest to upgrade when in Rivendell, Bree, Hobbiton or Bucklebury (their depths are unchanged).
I just want to thank Bandobras for making this release while I've been otherwise engaged. To get it, go to the Unangband homepage.
Voting is open for 'Ascii Dreams Roguelike of the Year 2007'.
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 24th 2007.
What about 'x'?
Make sure you announced your roguelike on Rogue Basin for next year. In particular, NetHack didn't make it in, and Angband nearly didn't. A few Angband variants (Furyband, Hellband, NPPAngband etc) also didn't make the cut because they weren't announced there.
What about the 7 day roguelikes?
I decided to exclude any 7 day roguelikes that weren't announced separately. I mean, look at the list - it's huge. I could have kept typing for much longer.
What's the prize?
Pride. If I get enough people voting, I may make up some kind of logo and 'give it' to the winning recipient.
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.
I really enjoyed coming up with ideas for this poll, and I'm glad to see so many (77) of you enjoyed responding to it.
The results were:
Hard science fiction
Giant robot combat
I'd love to know what the 'Other' responses were out there.
I also cross-posted the results early on to rec.games.roguelike.development, where you can read the responses if you want.
This poll was a deliberate clarion call to existing or wannabe roguelike developers who are writing yet another fantasy roguelike (YAFR). In particular, there looks like a 'huge' pent up demand for a post-apocalyptic or hard science fiction roguelike out there. If you are not worried about having to come up with your magnum opus as a first game, but just want to get something out there and have other people play it, consider setting it in one of the above scenarios instead, to make it stand out from the 'crowd'.
Next poll: 'What was your roguelike of the year 2007?' Candidates must have had a release in 2007 to date - hopefully that'll cut down on the list I have to assemble.
Well, this is the 200th post in Ascii Dreams. I never expected to make it this far.
(It's actually the 201st post, but that's because Blogspot doesn't quite have the flexibility of Moveable Type, so articles I'm still working on count towards the total).
I'd like to thank everyone who's provided feedback so far and who've been generous enough to link to me. I think I have the mix of original articles about roguelikes and game design / game mechanics about right, as well as the various 'link-to' posts that point out what other people in the world of game design, and specifically roguelikes, are writing about.
I'm a little worried that starting this blog has taken actual development time away from Unangband. This is undoubtedly true: but then I read a ladder post where someone discusses the difficulty of a particular level ecology, and I realise that maintaining this blog is as much value towards developing the game, as actually writing code.
(At least, you should always write code first, then write about it.)
I've got a large list of article ideas still: that fall into two camps - specific to rogue-likes and general game design. What will happen moving forward, is that the rogue-like and Unangband articles will continue on this blog, and the more general game-design articles will end up at my column 'The Amateur' on GameSetWatch.
Hopefully this will address a criticism that this blog is less of a roguelike developers diary and becoming more of a general chatting about games blog. I can see why that criticism is being made, but I'd argue that there is a huge potential for cross-pollination of ideas in games design and that writing a roguelike is a great way to learn about game design in general.
Thanks also for putting up with me learning when to place the apostrophe in it's, and watch me still making up my mind whether it's roguelikes or rogue-likes.
Now I'd like to hear from you about what you want from this blog. More polls, more game reviews, more articles about Unangband, or roguelikes in general? What were your favourite articles, and what did you find less than useful? Should I stop or keep going for another year?
I was going to write a larger article on the penalties for failure in various games, but someone seems to have beaten me to the idea. I'll probably still go ahead, as the article is focused on MMORPGs and doesn't really cover the full scope of what is possible.
I'm also still trying to track down an article on heroism in games I remember reading - which discussed heroism in computer games with reference to Red Orchestra. If someone could point me in the right direction, it'd be much appreciated.
Wednesday, 19 December 2007
Monday, 10 December 2007
Psychochild's blog (RSS) sets a weekly game design challenge, which is a great exercise for thinking about possible game systems and game mechanics. This week's exercise is coming up with a successful PvP design. I've commented on his blog, but it's worth repeating here as PvP games with advancement are fundamentally broken. As David Sirlin points out, it's like a grandmaster getting two queens instead of bishops because he's been playing longer than his opponent. If you disagree, he's written an excellent article criticising World of Warcraft for this reason, among others.
So the challenge for anyone doing a PvP design where they want to allow advancement is to come up with a fundamentally unbroken version of advancement.
My suggestion follows:
[Edit: You'll probably want to read 'How to make a game with PvP Done Right'.]
If you are going to do PvP with advancement, I'd recommending taking a leaf out of the Call of Cthulhu RPG design and have a learn through failure approach. The loser gets to pick one ability that the winner has used, which they don't know. The winner improves the ability picked, and the loser learns it.
That immediately makes the advancement through PvP technique have it's own tactical component in terms of which opponents you select. By restricting the ability chosen to only something that the loser doesn't know, you also encourage people to go out and find enemies that they haven't fought before. They may even be encouraged to set up 'dojo' like systems, in order to train as many beginners in the ability they want to improve.
Great. Make a throwaway comment in the vein of High Fidelity about the Top 5 Games Journalists, and not only do I get linked to by one of them, but I only have a list of 4. That and I cheekily linked the New Games Journalism reference straight back to my review of Minerva, which is my pastiche of said writing style, as opposed to something credible explaining what the heck New Games Journalism actually is.
Talk about getting caught with your pants down.
In all seriousness though, who's your top five?
Joel Spolsky on the success of Joel on Software:
It was successful because I used a slightly larger font than the average website, making it easy to read. It’s always hard to figure out how many people read the site, especially when you don’t bother counting them, but typical articles on that site get read by somewhere between 100,000 and a million people, depending on how popular the topic is.Let me know if the new font size is painfully big.
The perceptive of you will notice that the latest poll is just a proxy for the endless Pirates vs Robots vs Ninjas vs Zombies debate. I appear to have neglected a Monkeys option however. Suggestions for monkey-based roguelikes are welcome.
FYI This blog isn't turning into Facebook. Yet.
Posted by Andrew Doull at 10:25 AM
The results were:
Playstation Portable (PSP)
Game Boy Advance
Nokia S60 series phone
Any Java capable cellphone
Other Linux-based portable
Other (answer in comments)
The clear winner was the Nintendo DS, with Java capable cellphones following up.
Those of you with Nintendo DS's may want to refer to John Harris' excellent overview of playing 'Homebrew Roguelikes on the Nintendo DS'. And for those of you with Java capable cellphones, you'll probably want to have a look at Dweller, the roguelike for cellphones.
Next poll: 'Which roguelike settings would you like to see more of?'
Sunday, 9 December 2007
Not so with Steamband.
Under the brim of a stiffened top hat and the tweed of a well-tailored waistcoat stirs the mind and beats the heart of a true Victorian gentleman. The only artistic complexity that such a gentleman would concern himself with is the diagrammatic dissection of the latest Lepidoptera, and as for alt geek gamers, why the description of such a man could only fit the widely lauded and well-established figures of Edison, Wells and Twain. And so this game prizes literary flair over graphical pomp, and tactical thinking over cheap penny arcade thrills.
Your quest begins in the Centre of the Earth and you must ascend 50 levels of the dungeon and defeat the inscrutable Fu Manchu, who resides on the surface of this dangerous world. Standing between you and your ultimate enemy are a challenging and carefully crafted army of Martians, Morlocks, dinosaurs, Freemasons, steam-powered automatons, mechanical chickens and a plethora of other beasties as well as the well-researched and fantastically rendered figures of literary and pulp traditions. This game follows in the footsteps of Rogue, Nethack and Angband and while it could be described as an Angband variant, it is best to think of it as a total conversion as no trace of that game's setting still exists.
You can play as a stiff-upper-lipped British Officer, a brash American Engineer or a fine-dining Russian Aesthete, or stranger figures such as an Automaton, a Steam-Mecha or an Unseelie Fae and your choices extend to a fine selection of guns, tonics and mechanisms, headwear and trousers, as well as a deep and rewarding skill system. You may find the selection of races and impact they have on game-play somewhat controversial but it is very much in the spirit of a pro-abolitionist-but-still-paternalistic Victorian world-view. If you are offended by this, blame the game's fidelity to it's source material rather than any malicious intent on the part of the developers.
The game design addresses many of the criticisms that could be directed towards it's Angband ancestry, such as overly long game-play and a profligacy of unnecessary treasure types, and replaces it with a delightfully paced romp through a Vernian journey, while still maintaining the ASCII user interface of these types of games. But I strongly urge you to look beyond the typeface and into the steely-eyed monocle of a game that wears it's fictional inspirations pinned to the arm of it's satin smoking jacket, while reaching for a derringer and brushing the tendrils of an alien weed from it's sleeve.
(Sketch by Finish Steamband fan ponpoko. You can see more character art here).
I've just had a quick look through more of the Lost Garden, and there's a few more free tile sets available.
A set of 2D Zelda-like RPG tiles which includes wilderness, village and building interior tiles (pictured left). Danc provides a link to another developer's flash game that incorporates these tiles in the 'How to Bootstrap Your Indie Art Needs' article I talked about earlier.
A set of 250 hand-drawn textures.
In a genre thirsty for bitmap tiles, there are very few great pixel artists working in roguelikes. Virtually all the Angband variants use the tile sets from just three artists: Adam Bolt, David Gervais and the original 8x8 tile set which is uncredited but has recently been supplemented by Dawnmist.
I strongly urge you to have a look at the pixel art from Danc at Lost Garden (RSS). He's just released a Planet Cute tile set that looks beautiful. It includes vector art, so should be scalable to whatever size tile set you are looking to create.
Not only that but along with the release, he discusses 'How to Bootstrap Your Indie Art Needs'. Have a read.
Saturday, 8 December 2007
The active size of the Angband community, excluding the top 3 variants, is approximately 100 members. I base this number on the number of active members of the angband.oook.cz forums, which is a conservative figure but not unrealistic. Looking at the Angband variants with the most active forums: it appears Furyband is maybe four times larger, Portralis probably a third smaller, and Tales of Middle Earth possibly twice the size. I'm having to guess here based on the number of simultaneous users online for those forum stats - it would be good to know a break down of active users vs. people who haven't logged onto the forums in the last three months.
So perhaps a total community size of 500 users all up, which is undoubtedly an over-estimate. I'd like to know how many people who download Angband who don't 'contribute' further by joining one of these online web forums. Given my experience with Unangband, it's probably a 10:1 to 50:1 ratio. Berlios, who host Unangband, make the download stats available for each Unangband release, which you can have a look at.
You may well have objections to the way I'm restricting 'community' to those people I can count. Well, I could well have been harsher, and just restricted it to the number of people who post to the forums, or Angband ladder, or newsgroups. This would be a more laborious process, but it would give me numbers that would be a lot smaller. And a closer sense of what I'm trying to define community as.
Why am I discussing this? Well, for one, there has been a mini-furor on the Angband Usenet group rec.games.roguelike.angband about the utility of web forums vs. Usenet. I have little time for this sort of discussion. Firstly, Usenet is a great resource, but one that is increasingly become restricted from general access, mostly by ISPs who are not offering nntp as a service anymore. It's also not the first port of call of Internet users anymore, like it was in the days that I attended university (And my dad was running the Commodore 64 BBS for the Auckland C=64 club and excited about getting Fidonet feeds in).
I don't buy most of the arguments for just using the newsgroup because the Internet has always been heterogeneous. I've cut back on a lot of the links I listed on this blog, but if you look to the right and scroll down a little, you'll see the number of Angband related links that I feel confident will allow me to capture any discussion about Unangband. Then I still have to subscribe to Technorati. Then I still have to check which traffic is coming to this blog and the Unangband home page on Google Analytics, and notice that one of my main traffic sources du jour happens to have the blog link in a very light grey against a white background and still manages to redirect more traffic to me than sites that have featured this blog relatively prominently. And then I still search Google for Unangband every month, just to see if anything else has come up.
Secondly, it's because I get frustrated by seeing amateur software developers like myself making despondent posts about whether or not it is worth spending the time trying to develop code, or whether they should continue working on an idea that they had. I'm no stranger to this feeling, and I'm fortunate enough to have been rolled a really good hand in life and have a loving wife who actually understands my need to sit down and write code for six hours at a time.
I'll put this in black and white. If you enjoy playing roguelikes, or any other games that are put together by people who are not employed full time by the game industry, you have the power to transform their lives.
- Give the author feedback on their blog or on web forums or email or whatever means of communicating with them that you have.
- Contribute what you can back in the form of being an active community member. Help out others, write reviews of the game, set up your own blog and link to the game.
- Become an advocate for the game. Pester game reviewers that you know or like, link to the game on related forums, submit articles about the game to Slashdot, Digg it, Reddit.
- Be a hedgehog about it. Don't just promote the game once, but keep doing it.
So why do this? It's simple really. The more feedback an amateur software developer gets, the better they feel about the game, and the more they'll code. Positive feedback helps, but even constructive criticism is good.
I challenge you to pick a game, any game that you like that you feel is unappreciated, go out and become an advocate for it for a week. Write a review and submit it to Play This Thing. If you can't do that, at least post five times to the forums of five separate games within a week. Be more than a passive reader. Get a Digg account, search for roguelikes and digg every article you find. File some bug reports, using whatever bug reporting tool the game has. I love to get bug reports, even though I reserve the right to ignore fixing them (I'll write more on this another time).
If you do that, I guarantee that you'll get more game written in return for a fraction of your total time invested. Not only that, but you create a small chance that something magical will happen. If enough people start to love the game that you love, there is the distinct possibility that the software developer will be able to make the biggest transition of all, to working on their game full-time. Few will achieve it, but I think most dream of being able to do so.
Think about it. Through spending a little of your time, you could end up with a professionally written version of the game that you love. But you've got to make it worth the investment. And becoming part of the community, or better yet, an advocate for the community, is the best way to start making this happen.
There was a brief mention of Kieron Gillen, arguably one of games journalism's top five writers (Quick - name the other four*), who invented this thing called New Games Journalism, in an Independent Games Summit panel called 'Building the Future of Independent Games'. The article they're referring to is a piece he wrote called 'How to Use and Abuse the Gaming Press'. It's a case study of how Introversion successfully got out of the bedroom and into the boardroom, by building relationships with the UK game press in order to publicise Hacker and Darwinia.
If you have any aspirations at all about getting the game you're designing out there, you need to stop what you're doing and read it.
[*] I'd pick: Leigh Alexander, N'Gai Croal and Stephen Totilo aka Big Dog and that other guy from Rock, Paper, Shotgun (What'dya mean there's more than two ;).
[Edit: I attempt to cover-up my dignity in a follow-up post.] [Double edit: In a shocking piece of revisionism, I decide Quinns is the fifth guy, conveniently allowing me to link to him instead of a gag about how I couldn't come up with five journalists to link to].
Friday, 7 December 2007
John Harris continues in his series of interesting and subversive Game Design Essentials column with 20 Unusual Control Schemes. Why do I say subversive?
Well, he's also the author of @ play and so clearly interested in slipping in as many references to roguelikes (half-way down the page) in otherwise straightforward looking columns. And the final page, while talking about Progress Quest, could equally be taken as a discussion about the Rogue-o-matic or Angband Borg (not to mention the obligatory Dwarf Fortress reference).
Additionally Temple of the Roguelike is credited as a resource.
Angband has a long tradition of inspiring web-comics, one of which is Tales of the Pit. I wasn't aware but it looks like it's still running: you can get the RSS feed here if you want.
It just featured possibly the worst pun of 2007 that I've seen.
And I've just noticed that Penance, another roguelike inspired comic appears to have started up again as well. The art is slightly better in Penance (graphic novel style) and is producing about a page a week at the moment. I recommend you start at the prologue and read forward (RSS Feed).
Thursday, 6 December 2007
Got up this morning. Noticed Stephen Tortilo of MTV Multiplayer gave Desktop Tower Defense 'Game of the Year'. Think, oh, should check it out. Notice about 4 pm that it was a sunny day outside. Eat dinner.
I can reliably get 800 or so on Hard mode. But not the 10,000+ high scores that people are getting... you can play it here.
Wednesday, 5 December 2007
Q: Is there any benefit to password protecting your home Wifi network? I have IT friends that say the only real benefit is that multiple users can slow down the connection, but they state that there is no security reason. Is this correct?
A: I run an open wireless network at home. There’s no password, and there’s no encryption. Honestly, I think it’s just polite. Why should I care if someone on the block steals wireless access from me? When my wireless router broke last month, I used a neighbor’s access until I replaced it.
Tuesday, 4 December 2007
We're roughly half-way through the current Angband competition with an Unangband save-file. The deepest unique killed so far is Smaug, a level 55 monster. However, the character doing so has just passed away due to an unfortunate spell casting accident, opening up the game to anyone who is able to surpass their efforts.
You can keep following the competition, or submit your own success and/or failure stories to the Unangband ladder. Remember, the point of the competition is participation and challenging yourself. Of course, the glory of submitting a winning entry is quite a nice icing on the cake.
In a brief followup to my earlier analysis of shopping in Angband, I've found a source of inspiration for the Unangband money game here in an article about Freshly Picked: Tingle’s Rosy Rupeeland. From the article:
In most adventure games the cost of items is clearly established. Need to buy a shield? Some armor? A golden chicken? A village merchant or town elder tells you what you must give to get what they’ve got. In “Tingle” the non-player characters will rip you off. Want a 10-ingredient pot in “Tingle”? Don’t know how much it costs, because the lady cook won’t tell you? Well, make an offer. In a miserable twist to classic bartering, most of the game’s character to whom you make a lowball offer will pocket the money you offer them. And then they will start negotiations over from scratch. So when I found a character who promised a great secret if only I could pay him “four figures,” I made a mental note (only possessing three figures of rupees at the time). I came back to him later in the game when I had about 3000, offered him 1000 , got laughed at and left with just 2000. Did anyone else know that Nintendo published games this mean?There's more money game goodness if you read the rest.
Monday, 3 December 2007
The power of C brings you my first roguelike. More importantly, there's a link to the Literate Programming version of the Adventure source code.
This is brilliant, because I needed this for a super-secret roguelike concept I only just thought of.
[Edit: While on the subject of C programming, a big thanks to Keith H Duggar for providing the solution to a problem that I'd spent far too much time staring at to see the answer].
Sunday, 2 December 2007
Results are in for 'when did you first start playing roguelikes'. One short of 100 votes. It's good to see that people are still discovering the genre at a regular rate. I'd like to know who was playing prior to 1981 - Rogue was released in 1980. Speak up now - I'd like to get a feel for the impact of the game when it first came out (I was 6).
The full results are:
Haven't tried them before
Next poll is 'What portable devices would you play roguelikes on?'
As mentioned elsewhere, Angband and variants (specifically FAAngband) are progressing well towards a keyboard-light / keyboard-free implementation, and it'd be good to know what platforms to focus on.
Even though I am writing a computer RPG for OCD obsessives, face-to-face old skool table-top role playing is my first love. When I first came back from the UK for a holiday in New Zealand, I had to give all the RPG material I had accumulated over many years, because I couldn't justify paying for the cost of a storage unit. 2300 AD - I miss you.
And here are some love letters from other people so touched.
Care to share your love letters?
Saturday, 1 December 2007
It is with tired hands and a weary brow that I have to admit to you that, in fact, I have spent the last ten or so years, working on a game about shopping.
Angband, as I have mentioned numerous times, is focused on inventory management. And a big part of that inventory management is the art of purchasing goods from the 7 stores in the town precariously perched above Morgoth's iron prison.
Let us not forget the absolute suspension of disbelief that having the fantasy equivalent of a small arcade directly above the bastion of all that is evil requires. Or the fact that the jaded and world weary shopkeepers will not cut you a discount, even when you have felled that ultimate enemy of light and heft the weight of his mighty hammer in your hand. The recent discussions on the impact on Charisma in the game point to the pithy contrast of absurdity and game balance requirements that having shops in the game entails. Of course, you can get rid of them completely, but in designing a variant which has multiple towns as waypoints onto the same final destination, I'd like to find a suitable half-way house in which they can be maintained.
Well, for a start, lets have a brief discussion about what tools that the current shop system avails us, and then look at where it might take us.
Shops in Angband consist of an inventory, a stock list of items that could be potentially generated in that inventory (with a fixed probability for each) and a shopkeeper with various racial preferences and a maximum purse from which he can purchase goods. Of particular note is the black market, which as opposed to having a fixed stock list, instead stocks items as if generated from a certain depth in the dungeon.
The player buys from the stores inventory, and buying up the entire inventory causes it to be generated anew. Periodically the inventory is refreshed, which results in some items being removed from the inventory, and others being added. This may also result in the shop keeper being replaced by one that is either less or more generous, and has a different purse size.
The player can also sell equipment that is found in the dungeon to the appropriate store. In this instance, the shopkeepers purse is the maximum sale value that the player can get for a single item. The sale price is guaranteed to be no more than the purchase price, and the black market is not worth selling to. Obviously the player can only make a sale if the store inventory is not full.
The disadvantages of this mechanic have already been discussed in Andrew Sidwell's analysis of Charisma, with particular reference to the impact that Charisma has on shop prices. It should be worth noting that various variants have tried to fix parts of this design, by creating store services, which allow the player to spend money in store in return for having their weapons enchanted, items identified and so on, and on allowing shops to stock better items than their original inventory, sometimes requiring an investment of funds for this to be the case.
As is always the case, it is worthwhile going back to first principles to analyse why we would potentially want shops at all. They serve the following functions:
1. To justify the function of money.
2. To allow low-level players to get additional cash by selling items found in the dungeon to the shops. This is useful up to a point, beyond which money stops being important.
3. To allow players of all power levels to get various essential supplies - food, light, magical healing, escape magic, ammunition for their current weapon, and so on.
4. To allow players to upgrade their existing equipment through purchasing scrolls of Enchant Weapon and Armour.
5. To sometimes allow players to spend a larger amount of money in return for a useful item.
Point 1 could be substituted for the original purpose of money in Rogue, which was a measure of score. This works well, but I'm not sure that game players these days are as focused on score as they may have been previously.
Point 2 works well, as mentioned, up to a point. There is definitely a tipping point where the amount of money recoverable from selling items exceeds the ability of the player to spend it. This actually occurs in several stages: the first can be exploited through a quick descent to level 3 in the game, where the first wands start occurring. Wands are problematic in that they are light and valuable, and reaching wand depth is usually results in you can afford all the basics. The next major boost is usually when you start finding enough ego-items to be able to haul them up and sell them. Very quickly after that, money stops being an issue and the actual contents of the store inventories becomes your limiting factor.
Point 3 is usually frustrated by the actual selection of required consumables in the stores. If you are out of something 'essential', you have little choice but to descend to level 1, and rest it out until the shop stock rotates, at which point you can have a chance of finding the item again, although it is not guaranteed. Of course, the definition of what is 'essential' differs from character to character.
Point 4 is the most effective money sink in the game, because of the diminishing returns on investment of the various enchantment spells. At the same time, this results in much game-balance breakage, resulting in warriors wielding (+9, +9) daggers instead of long swords, because they've been able to enchant the lower powered weapons up, and the poorly thought out combat design encourages lighter weight weapons.
Point 5 is a great money sink, very occasionally. Usually what happens is 75% of the stores are filled with 'useless' non-consumables, such as 3 Morning Stars, or 7 Maces, piles of which are less than useful for just about anyone.
Rectifying the situation will have to be done very carefully. Just making money useful again by allowing more appropriate purchases will have the unbalancing effect when money stops being a problem to acquire.
So what are my recommendations? I'll discuss what is best suited for Unangband, since that is where my interest primarily lies.
1. To address point 2, you want the shop keepers to scale down the amount of money they'll be prepared to offer the player for equipment. I'd do this by adjusting the shop keepers purse directly. If they buy stuff off the player, decrease the purse size by the value of the purchase - if they sell stuff to the player, increase the purse size. That way, the purse becomes a direct measure of how 'profitable' the shopkeeper is.
So what happens when a shop keeper runs out of purse. Well, to avoid this happening, I'd scale down the amount the shopkeeper is prepared to offer, as their purse size drops, and treat some of the scale down as future 'profit' which the shopkeeper realises the purchase by selling it to some other
suckercustomer. And as their purse increases, increase the chance that shopkeeper will rotate out, by retiring, so that the player can't recoup their 'losses' through a big sale.
Alternately, you could periodically reduce the value of a high purse shopkeeper, and in return add to the selection of consumables that they stock, as discussed in point 2 below.
2. Point 3, the selection of consumables, is too random at the moment. The list of consumables should be a list of fixed items available, which is regenerated with each shop refresh.
However, the actions of the player should be allowed to change the consumable list. I'd recommend the following sequence of events.
a. The player sells an item to the store that the shopkeeper hasn't seen before.
b. The shopkeeper gives the player a quest to find x of these items, so that he can analyse them to work out how they are made.
c. The player completes the quest. The shopkeeper gives the player a quest to find a set of ingredients in order to make the items. These happen to be made from a monster.
d. The shopkeeper starts stocking the item in question.
e. Periodically, the shopkeeper runs out of ingredients for a consumable item that the player has purchased. This means that the shopkeeper cannot restock the consumable, until the player completes a similar ingredient quest.
3. Point 4 has been 'fixed' in Unangband, by adjusting the weapon enchantment routines. I can only recommend something similar for Angband.
4. To address point 5, and deal with the problems Andrew discusses around Charisma, I recommend making stores stock one or two high level items each, and have those rotate frequently. The 'level' at which the item occurs should be based on a number of factors: Charisma being the most important one. If you drop Charisma's impact on prices, and make high Charisma result in better 'special' equipment available, Charisma will still have a much needed impact on shopping, without affecting the overall money supply. In fact, higher Charisma will result in the player having less money, as shops will create 'more appropriate' items for him.
This is the most complex recommendation, because you still want to have the player able to have most of the equipment come from the dungeon, while encouraging him to spend money where ever possible. So tuning the nature of the items is critically important. Ideally, you want the shops to generate '2nd-tier' alternatives for the player: say items about 80% of the power of what he is finding in the dungeon. I suspect you'll want to cheat, and pick item abilities directly based on what items the player currently has. If you make Charisma work on the 'appropriateness' match as well, that'll encourage the player to focus on Charisma further.
Of course, the brokeness of the stat-gain mechanic is food for thought and potential discussion in another article.
[Edit: I've followed this up with a brief post-script.]
I've come up with a complete design for a Co-op Portal level (see part one for some of the initial thinking around this). Now I need help.
If you're a Half-Life 2 mapper, I'd like to hear from you. Co-op Portal will be a single map consisting of 7 rooms. It will be be built on the existing Half-Life 2 Death match engine using only existing design elements from Portal (plus rocket launchers, which I've found a better use for). I'm quite happy to work on the scripting side, but I have no experience with Hammer.
It's important that you realise that Co-op Portal does not and will not be using the Portal gun.
If I don't hear from anyone, I'll start working on this myself, but obviously it'll take a lot longer.
Also I'd like to spruce up the design document before presenting it, by including the various visual elements. Does anyone have a good recommendation for design software (preferrably freeware) that could be used to get the same visual look as the Portal in-game artwork? I'd prefer to use isometric projection if possible. And does someone have the Weighted Companion Cube in a Visio template form?
[Edit: Looks like you can't put up help wanted on the Valve Developer Community without a mod, and they recommend you don't create your mod page until you have screen shots. Hmm... a little Catch-22. Besides which Portal is probably a registered trademark. Let's call the mod Lab Rats from now on].
He's the guy who wrote Braid. He recently talked at MIGS 2007 about game design, in particular being highly critical of current game design practise, and has thoughtfully made available some slides and audio from his presentation.
Annoyingly, I had queued up an article idea myself along the same lines. I'll have to figure out if I have anything left to say beyond what he has covered.
Review appears.So it looks like my previous statement may have been an over-reaction. My apologies Ian. It looks like the entire industry has ethical problems, not just yourself.
PR or someone similar phones up and go apeshit. Really apeshit. This is par for course. A major game getting sub average reviews is something which PR *have* to phone up about. It’s what their bosses expect. Better PRs and Editors all know that it’s part of the game they play with each other, and roll with it.
Problem in this case, is whoever above Greg isn’t a good editor or manager. They’re someone who actually takes the threats seriously instead of something that’ll blow over by the next game. The panic, cave and sack the guy.
Now, this is the last thing any experienced PR would expect. I dare say Eidos are as surprised as everyone else at the sacking - and horrified, as a sacking over a review score is the worst publicity they could ever recieve if it got out (And, of course, being the internet it WOULD get out).
The reason why I say this, is that the
However, the power of game advertising has grown proportionately. When you are giving away your content for free, as opposed to retail or subscription models, the revenue from advertising is your only source of income. For the independents, this is not a huge problem, because you get a name for yourself, and write where ever you can get the work. But for in-house journalists, such as those employed by Game Spot, it is a delicate line between integrity and income. As a journalist, you rely on your editors to protect you. As a Game Spot, you rely on taking an hit on the income in the event someone pushes too far, and the kudos you get for saying no.
But as a major games publisher, you should recognise the serious conflict of interest integral to the industry. In 'the real world', what you'd do is develop a code of conduct at the board level to ensure that situations such as what is currently developing don't occur. And then you push the code of conduct out at all levels within your organisation, to ensure you don't have PR ringing up and going apeshit on people.
You do this because you have a fiduciary duty to your share holders to maximise return, while minimising the risk of failure or legal misadventure. And clearly this hasn't happened.
Eidos has already gone into damage control mode. Maybe when they pull their head back out of the sand, they'll realise the problem and ensure that such a document gets developed. I'd like to see some heads roll on the Eidos side at a senior management level first. You just don't make mistakes like this.
[Edit: Kevin Grifford at GameSetWatch has another great take on this, from a slightly different angle.]