« GameSetLinks: Mole Mania - The Mania Of The Moles | Main | Reminder: Devs, Nominate Now For 2008 Game Developers Choice Awards »

COLUMN: The Amateur: Angband & The Game Development Arms Race

- ['The Amateur' is an irregular column from Australian-based IT manager Andrew Doull, discussing the perils and rewards of being an unabashed non-professional creating games. This installment deals with how making an Angband game variant can inform how all game developers look at game scope.]

I recently had the pleasure of meeting Nick McConnell, creator of First Age Angband, in the flesh and we talked at length about the ups and downs of maintaining an Angband Rogue-like freeware/shareware game variant (perhaps for too long).

One thing we agreed on was the unique challenge that writing Angband variants presents. In particular, the inherent risks of trying to adopt features developed in other branches of the Angband variant family, that appear very easy to port across. And the insanity of attempting to do so.

If you're doing game development, you may wish to take note.

I'm looking at the tentative feature list for the next version of Unangband, and this consists for the most part of game features that have already been implemented in other Angband variants. In particular, I want to implement the 256 colour code and extended Latin-1 character sets (with custom glyphs) that feature in several other variants. Now, at a surface level, you'd expect it to be easy to adapt this code across, due to the similar nature of the code bases (they all have a common ancestor, and the source in all Angband variants is open).

Instead, you end up porting the code across by hand, because the diffs will never merge successfully. You also port a whole class of very subtle bugs that occur because the set of assumptions in the original code base does not match the set of assumptions you have made in your game. For instance, Nick is currently feeling the pain in having adapted a in-game notes patch that features in the many variants to First Age Angband - he still hasn't squashed all the bugs with what consists of a benign user interface change.

This is why my policy for Unangband has been for the most part to 'go my own way' and write code from scratch, using the ideas that may have been generated elsewhere, but with my own hand-rolled code. I end up having to do more work up front, but this reduces the number of subtle bugs I have to deal with in the code base (but sadly not to zero). This hasn't always been the case - for instance, the dungeon generation and AI code is heavily indebted to other variants, but for the most part it seems to work.

But the problem is more serious than just the short term pain of having to adapt and debug someone else's code, or come up with your own version of someone else's ideas. As soon as you start down the path of writing an amateur game in an established genre, you are putting yourself in competition with every other amateur game writer in that genre. In fact, you're putting yourself in competition with all of them, cumulatively. You're (usually) only one developer, and, in the Angband case, at anyone time there are at least 5 or 6 other variants actively being developed, plus the core Angband development team. You have no chance of being able to produce more features in your game than all these other developers, and yet it feels at the same time that you have to, in order to 'keep-up-with-the-Joneses' and 'capture' part of the overall genre player base.

But it's not just the small pool of Angband and variant developers I have to deal with. There are freakish coding prodigies lurking at the edge of the boundaries of this relatively small inlet, working on rogue-likes that are spoken of with whispered breaths in the dim dark corners of the Angband forums. I will admit to being driven close to tears by one helpful newbie who suggested that 'Unangband was kind of a good start, but I should look at Incursion: Halls of the Goblin King, figure out what they're doing and copy it'. I'm an amateur game developer, working on a game in what little spare time I have. I don't have time to play any other Angband variants, let alone anything else... and forget adopting other people's ideas in addition to my own.

- Then there is Dwarf Fortress...

(Let's just say I stared deeply into my own soul after seeing its layers of features upon features and the abyss didn't answer... I'm sure peers to James Joyce felt the same way after reading Ulysses)

Attempting to adopt other game's features is the first dangerous step on the path to a mad game development arms race, where you try and include every feature from every other possible game that might apply to yours. You may, through insane acts of desperate endurance, somehow succeed at this - look at the huge 'feature count' for Unangband for an example of this. Having done so, you'll realise that during the time you took to do it, so much more has improved in every other game you were comparing yourself with, that the work outstanding will have grown exponentially. And even if you're strong enough resist the urge to try to feature add and not to compare your 'feature list' to other games in the genre, your player base will.

It's not just Angband variants, or other amateur game developers, who are vulnerable to this problem. Anyone considering creating a first person shooter should read Dsylexci's Tactical Gaming Done Right before proceeding. And then figure out if they're willing to write Operation Armed Flashassault III. I can't go back to Grand Theft Autos earlier than San Andreas, simply because having no climb or swim mechanic sours the taste in my mouth - I've been given better free-roaming and to take a step backwards is like throwing away the keys to my cell door. I'm sure people who played Crackdown feel the same way.

I suspect that this arms race which can only result in mutually assured destruction will be survived in one of three ways:

1. Collaborative worlds big enough to contain every possible game feature anyway (Because no single player game could justify the development budget).
2. Self-contained mini-games with a simple enough rule set that adding features will detract from the game play.
3. Games with a strong narrative drive that only require a feature set large enough to move the narrative forward.

But the inexorable pull of large collaborative worlds, with the gravity of massive budgets and huge player base will draw types 2 and 3 closer to them. The only thing holding back total collapse will be the difficulty of integrating 'pick-up-and-play' into the overall world space - and when Blizzard realises that they already have a segmented player base, and they could just sell levels 1-30 Dranei start as a stand alone game in itself, you'll find the likes of World of All Possible Games Craft taking over.

[Andrew Doull is an IT manager from New Zealand who spent the last 5 and a half years working in the United Kingdom. He's just emigrated to Sydney, Australia, and spends his free time developing Unangband, a rogue-like game, and blogging at Ascii Dreams. He recently covered the Edinburgh Interactive Festival for Gamasutra magazine and has just started an irregular column for GameSetWatch.]

Comments

Very nice article. I definitely have had the same abyss-staring experience as the developer of POWDER. The very early writing was mostly "Clone Nethack's features" but I pulled back from that path when I realized it led to just this sort of useless armsrace. Nethack already exists, so why write it again?

The trick is to abandon features as a goal. Instead, focus on a "gameplay" or overall "theme" and drive your features by what fits in your world rather than what fit in other worlds. Write a one paragraph summary of what your particular variant *means* and only consider features that match that meaning.

This is a lot harder for Angband variant maintainers that are starting from a huge hodgepodge of features - it almost should be the first step of a variant maintainer to aggressively delete features to pare Angband down to something that matches their vision. I was "lucky" in POWDER to be working entirely from scratch which meant I merely have to resist adding things rather than actively remove things that distract from the goal.

As Ray Dillinger says:
"It's like paint. The more different colors of paint you mix, the more the result is just brown."

He was talking about monster types, but the same applies to features in general.

This is an excellent point from Jeff. Thematic consistency is the first hurdle any new feature needs to jump to get into FAangband. After that come maintaining gameplay balance, and making the game more fun. Then how hard it is to code...

As an example, monster shape-changing got in, despite being tricky to code, because it was such a good fit thematically. Quests did not get in, because (much as they can be fun in other Angband variants) they don't seem to me to be in theme.

Of course, UI features are in a different category; this is where the arms race is hard to avoid.

I think when you start to worry about the development arms race, it's time to take a step back and look at the larger picture. Roguelike games make up an amazingly complex tree. Variants build upon variants who's better features are ported to distantly related cousin variants. There are hundreds of individual games involved in a unique evolutionary struggle dating back to 1980.

In the long run almost every variant dies. Rogue and Moria come right to mind, and look at Zangband, last updated in 2003. At one time it was the biggest angband successor out there. But IIRC Tome can trace its lineage through Zangband, so that variation from the angband codebase lives on.

There have been lots of angband forks that never garnered a meaningful player base. Some of them were one trick horses with a single great feature patched over the code base. But even if that variant died a swift death, the feature was often taken up by other variants. The best features get incorporated into the popular variants, and those become the forking point for later variants. It's a surprisingly complex phenomenon that passes the really fun parts of the previous generation on to the next one.

My point? It's easy to get caught up in your own variant (and essential to get anything done), but your game is just part of a much larger, much more interesting genre of games that predates the instance of Unangband and will continue on after you've hung up your developer's hat. If you can add a really cool feature to the development landscape, players will enjoy it indefinitely. Sure, you can fight tooth and nail for the player base, killing yourself to match the best in every roguelike. But only one or two mass-feature variants are needed to condense the best of one generation so the next can fork from it and not deal with the issues you brought up of porting from dozens of other variants. It's great to the be the Angband or Tome, but if you entertain a handful of players with something really unique, and manage to pass on the best idea you have, I wouldn't worry about the Joneses or the comments of a few dissatisfied players.

Perhaps rather than new "features" or new variants, what's needed is a robust, standardized framework on which people can build new features and variants. Not as fun as building a game, but it could be infinitely more valuable and have a profound effect on roguelike development

For example, look at the "development environment" created for the mega-budget game Oblivion. Obviously that's a bit much for small-time developers to do, but it serves as a good model for the style of development that roguelikes could follow.

Create a basic framework that has essentially no "features" or content itself, but is very amenable to being added on to in a modular way. The result would not really be a game itself, but if it was easy to develop on it would attract a great many independent developers to use it for their creations.

The advantage would be that since each individual game builder's creations were built on this framework, they could be easily ported to other games - in fact, if Oblivion is any example, rather than building entire new worlds, many modders would focus just on developing some new feature, which could then be plugged into any author's creation and tweaked as needed, with minimal compatibility issues, thanks to the shared framework.

When incompatibility and non-standard code is a problem, standardized frameworks are the answer, almost always. They also tend to have a snowballing effect. The more people who participate, the more features are available, which makes more people want to participate.

So far, roguelikes are the domain of solitary dedicated programmers who seemingly do their work in isolation. Creating a more open source style model of development would open up many more possibilities for such developers to benefit from each other's labor without forcing them into a collaborative, group-run project where they lose the ability to build their game exactly as they like.

Post a comment



If you enjoy reading GameSetWatch.com, you might also want to check out these CMP Game Group sites:

Gamasutra (the 'art and business of games'.)

Game Career Guide (for student game developers.)

Games On Deck (serving mobile game developers.)

Indie Games (for independent game players/developers.)

GamerBytes (for the latest console digital download news.)

Worlds In Motion (discussing the business of online worlds.)


Weekly Archive

GameSetWatch is an alt.video game weblog from the people who run:



Copyright © 2008 Think Services