Sunday, 19 April 2009

This is a pre-release of 0.6.3. It should be stable, and just requires extensive playing to sanity check all the changes and find weird edge cases. Unfortunately, I had to cut trap regions before release, as this would otherwise extend an already late release unnecessarily.

Saturday, 18 April 2009

I almost never use linked lists (I think there is one place in all of LOVE), and instead I try to use arrays, they are faster, smaller and more cash coherent.

[Edit: Reading the article, I believe Eskil is primarily referring to linked lists where each member of the list is dynamically allocated and pointer referenced. It's possible to do an array based implementation of linked lists which avoids the issues highlighted in the comments, and then to infrequently expand the array using realloc in the event the array fills up. Angband uses the same approach, but usually has a hard limit on the size of each array, instead of dynamically expanding it].

Saturday, 11 April 2009

This is the 500th blog post on Ascii Dreams - an achievement I've been waiting to reach for a little while now. I hope you'll excuse a little self-indulgence at this milestone.

I started Ascii Dreams following the advice of a number of people on rec.games.roguelike.development that I should post my 'design diary' notes in a blog, instead of spamming the newsgroup with posts. My first article generated what I feel was a positive, albeit long thread, spamming the news group with posts discussing classes versus skills, with my position opposed to both. I would also like to think it indirectly inspired Ironband, an Angband variant by Antoine - the first person to reply in the thread:

There are no classes in Ironband - all characters can fight, shoot, sneak and cast spells. You can specialise by raising the appropriate stats (e.g. Intelligence and Wisdom for casters). The other stats are Strength, Dexterity, Constitution, Agility, Stealth, Perception and Luck.

It seems inevitable at some point as a blogger, you begin to worry more about traffic stastics than the quality of your writing. I achieved some early infamy through blogging, with articles being linked to by notable games journalists, up and coming games journalists and getting Slashdotted. But the Ascii Dreams traffic has remained consistent at around 150-400 visitors per day as opposed to experiencing the exponential growth which would support a web based advertising model - much to the disappointment of my wife. Unsurprisingly, the top read article is The Death of the Level Designer - a title I only partly regret choosing. More surprising, or perhaps not depending on your understanding of the human condition, is the popularity of the article on how to play different region DVDs on your Macbook:

Anyone who starts a web blog on an obscure game genre from the 80s and expects to become a celebrity has delusions of grandeur. Which is why I'd like to thank Simon Carless for giving me a writing platform for thinking outside of my comfort zone over at GameSetWatch. Simon is one of those people that you cannot overstate his generosity - he has provided unfailing support, kind advice and allowed me to express my delusions on a public platform shared by far more respectable games writers than myself.

The experience of interacting with the wider games journalism community has been similar to my experience with any cultural subgroup - as long as you're polite and have something interesting to say without offending anyone while keeping them entertained, you can very quickly meet the core influencers; which I've done so just long enough to realise that the motivation behind and issues underlying any clique remain basically the same: outsider vs insider, public vs private, person worth knowing vs object of interest. To reiterate: you're not missing out on anything if you're blogging in quiet, writing for yourself, with a small group of appreciative readers.

It still appears early days, but I have high hopes for the Procedural Content Generation wiki. I think my first mistake in expectations in creating the wiki was that programmers who were lazy enough not to generate game content by hand, would some how roll up their shirt sleeves and throw aside the same principles to write a wiki full of web content. Nonetheless there is a small but dedicated community of contributors who are building up a useful link repository to other procedural resources, and acting as a central collection of all things procedural. It's no aigamedev.net, but the procedural generation field feels in its infancy - and may yet remain just a curiosity instead of powerful set of tools that are widely used by the game industry.

What has been the most gratifying, and I hope an indication of the usefulness of this blog, has been the feedback from the wider roguelike community - both directly, and indirectly. I always appreciate whenever someone on rec.games.roguelike.development references an article here, or another roguelike blogger, of which there are a few now, links to this blog to agree with or refute a point I have made. I won't pretend that I'm a great programmer or game designer, but I've spent a long time developing Unangband - over 10 years - and I will continue to share the lessons I've learned and problems I'm having while working on the game.

Will Unangband ever be finished? I believe so, and I have a firm idea in my head of what the game will play like - at least for version 1.0. I'm at the point of development now where I'm more comfortable discarding bad game play ideas, instead of putting in everything I could possibly implement, and more work is spent 'modernising' and tidying up the code base than implementing new features. There are still plenty of hurdles to clear, and ongoing motivation will always remain an issue for an amateur developer such as myself but the end is in site: sometime in the next 5 years, of course.

As for blogging, I still have a number of large themes to explore in the same extended multi-article form that I've been using. While the total volume of content has fallen, and frequency of posting slowed a little, that has as much the increased incidence of real life instead of any change in the idealised game blogging savant personality I try to maintain here. I'm not someone project my personal hopes, fears and stories in blogging form: it's not your business what I'm doing in the real world, and I won't be someone who tries to foist their personal or political views on you - except on the very rare occasion where they intersect with the gaming sphere. I realise who I am as a person will inevitably leak onto the page - just remember that I'm not the person you think I am, so try to avoid idealising or denigrating me based on what small part of me you see here.

I've really enjoyed writing the last 500 posts. Please use this opportunity to request anything you want to me to discuss in more detail: I've had a request for more writing about my table top gaming experience which I'm sure to bore you with at some point. Comments, criticism and baseless praise are welcome - and we'll be back to a regular, more faceless, less fanciful service shortly.

Sunday, 5 April 2009

Too many game developers fall into the trap of making warriors re-skinned wizards: that is, the warrior class ends up have a list of special moves that in most respects acts identically to a magic user's spell book. There may be some overt themeing: the warrior may end up using themselves as a weapon, with more of an emphasis on buffing, but in all other respects, the abilities fall into the same categories that I talked about in the Designing a Magic System series of articles - the chief culprit of which is a screen or menu showing a list of abilities to pick from.

There are several ways around this. I've talked previously about using positional game play to trigger warrior abilities - by having special moves activate when a warrior moves twice in a single direction (charging), moves laterally (dodging) or stands still (blocking). Flend's DDRogue, reviewed by John Harris in his latest @ Play column extends this concept to a host of different special moves which are triggered by a combination of single moves. The weakness of this approach, as John points out, is that it is very hard to convey where in a move the player is currently using the user interface of a roguelike. In a fighting game, 'subcell stance' - such as whether a fighter is standing, crouching or jumping, is intuitively conveyed using graphics. A roguelike designer does not have this luxury.

Another key issue is a warrior's limited ability to flee a fight. Mages are given an automatic out in the form of teleport spells, which allow them a variety of tactical options for moving around the battlefield. To duplicate this in Unangband, a warrior ends up carrying a large number of different items - as highlighted by Bandobras in a recent Unangband ladder dump - which drags them back into the pick items from a list camp of game play.

I've tried several approaches to this. My initial thoughts were around letting the player manipulate whether they wanted a half-cost move versus a full cost move. A half-cost move - to reflect running around the battlefield - would allow the warrior to move around dynamically but incur a movement debt which would have to be paid off later. This movement debt appears in Unangband currently as fatigue, which slowly accumulates if the player is moving unusually (through water, mud or other terrain; highly encumbered; hasted) and encourages the player to periodically rest by causing them to eventually faint if they do not do so.

The problem with half-cost moves is the user interface overhead in order to be able to take advantage of them. I initially went with a modal approach, where the player would always prefer half-cost moves unless searching, which made the mental book keeping required to move far too high - you'd have to rest far too frequently while simply moving around the dungeon if you were in the wrong mode. A bucky key approach, where a modifier key such as Ctrl or Shift is used to indicate a half-cost move, overloads the user input requirements.

I like the semi-realtime approach that Wayfarer uses, simply because it emphasises mashing the keys to move quickly. From this post on rec.games.roguelike.development:

Basically yes -- it "feels" real time because different speeds areshown as different npc-slide-rates, and they complete their currentmove if you idle. So you can outrun a glormbeast if you're holdingthe movement key down, but if you're doing a tap-think tap-thinkprocess it will stay at your heels.

Unfortunately, messing with timings in a roguelike is something that has to be done very carefully, as time sequence is something core to the balance of the game.

The other option is to allow the player to push monsters and terrain around. Dark Messiah of Might and Magic has a kick option which, although horrendously overpowered, allowed you to kick your enemies into nearby terrain. Similar cinematic inspiration suggests that letting a certain class of martial artist warriors leap acrobatically around the terrain as in Crouching Tiger, Hidden Dragon.

But both these options require a command based interaction system, as opposed to a simple bump, which starts to stretch warriors back into the pick from a list mode of gaming that I'm trying to avoid.