Archive for the ‘game design’ Category

The simple trick to making good game AI

2011/03/06

Contention: Stardock’s Brad Wardell (Or is it Brad Wardell’s Stardock?) is often upheld as a good AI programmer, and Stardock games as containing good AI.

But from all I could ever see, neither was shockingly exceptional (and I’m not just saying this to be catty, though the Galactic Civilizations series, from the beta of the first game I played on OS/2 back in the day, was always something I wanted to like more than I ever actually did).

Good AI is like good Art Direction. You choose your battles to fight on your own terms so you can easily make yourself look good. Art design sets player expectations: VVVVVV isn’t criticized for its poor character modeling or voice acting because the game very intentionally sets its aesthetic limits at about the level of Atari games. Wii Sports avoids the expectations of any sort of detailed character animations or normal-mapped textures or environmental destruction and all such noise by utilizing a simple stylized aesthetic.

The visual experience of these games is designed so that asset creation is not an overwhelmingly complex and expensive job. And they manage to meet the requirements of player expectations without too much trouble. It’s good design.

Likewise, the gameplay of various Galactic Civilizations games happens to be designed in such a way that it’s easy for the AI to act meaningfully and responsively within its framework. (I don’t particularly enjoy this game design as a player, but that’s in the details.) Now: if a realtime chat interface was added to Galciv so that you could do diplomatic negotiations with AI opponents in real-time, as you would would a human, the game would fall on its face because it’s really, really hard to fight that particular battle.

The trick is to set expectations that you can fulfill, and fulfill well. This is why you won’t see me making an AAA-style 3d game.

Update:

There’s a great thread on Quarter to Three on the very subject of game AI and mechanics design scope with figures like Paradox‘s Johan Andersson, Vic Davis, and Civ V’s (now Stardock’s) John Shafer weighing in. Go there. The topic is discussed with far more depth.

Commitment Anxiety in Skill Selection

2010/12/21

In the current revision pass on Dungeons of Dredmor we’ve finally had to make some hard choices about what skills mean to a player’s character. Thus far, all skills have been more or less freely available to select from any point for testing purposes. But if every skill is always available then by the time a player earns a few levels they shall have had the chance to buy a completely new set of skills which would render the importance of their initial choices mostly meaningless. We want every playthrough of Dredmor to be about an experience which is meaningfully different from a playthrough with different starting selections — so far as we are able to make it so.

Which will you choose?

To restate our assumptions: At the start of a game of Dredmor, you must select seven skills to create your character. Yep, just seven. True, some skills are probably more useful than others, for how can ‘mushroom farming’ compare to ‘fire magic’? – Ah, but appearances may be deceptive, and I hope to make mushroom farming a skill to be feared; The fungi from Yuggoth compel me. (But that madness shall come in the crafting skills iteration…)

Why seven skills? I don’t know. Maybe it felt like a good number. It could reflect influence from Dwarf Fortress (whose use of seven dwarves has an obvious folklore connection), except that the foundation of skill selection was implemented before DF was released, if I recall correctly. I’ll have to ask Nicholas about it … and he says: “Oh, I just picked it at random”.

Ah. Lovely.

Let me briefly consider some other games’ approaches:

An old favorite of mine, Ultima Online, had a dynamic advance-through-use system of skills rated from 0 to 100 with a total skill point cap of 700. Once your skills added up to 700, you just shuffled that set number of points around. The downside of UO was that the system promoted rampant macroing; Raph Koster explains this (and more!) in his writing on UO’s use-based system. The capped dynamic skill system fits the theme of an open world and I really like how it is a radical difference compared to the lineage of MUDs that revolve around grossly linear advancement, the influence of which we see today is most MMORPGs (read: WoW). In UO, player power relative to one another was kept within a reasonable range – a new player would start with 1/10th to 1/2th the hitpoints of a maxed out player. Five or six fresh noobs could conceivably fight a veteran character and win (though no Red worth their black pearl would be taken by a pack of noobs).

Dredmor, however, is not an open world sandbox game, nor does relative player power matter because it is a single player game. Roguelikes as a genre tend to be about making a few important choices at the start of a game and then exploring how those choices affect a playthrough which requires relatively little investment compared to an MMO character. What I’m getting at is that I think almost the entire point of starting a roguelike character lies in those choices at creation being a meaningful statement of how you intend to explore the rest of that playthrough – or at least a shot in the dark that will give you a unique experience. This suggests to me that we should be unforgiving about changing skills, as in: you can’t.

I know that modern games like Titan Quest and World of Warcraft are rather forgiving about letting you undo skill selection decisions — in TQ, you may change skill choices for increasing gold cost, in WoW, likewise for picks in the ‘talent’ tree. I see these design choices as a result of wanting to play nice with more casual gamers, alleviating the pain of character optimization mistakes in games that both take more time investment and revolve quite centrally around number crunching. Dredmor certainly has numbers and crunching, but I hope that the spirit of the game comes through: that it’s more about exploring interesting choices within given systems than linearly optimizing DPS numbers and threat/tank mechanics.

A rather poorly organized skill design spreadsheet. We try not to pay too much attention to it.

(Can you defeat Lord Dredmor with just crafting skills? A shiny goat figurine to whoever does it first!)

Funny thing, Diablo 2 was not so forgiving with skill re-allocation while I’m certain that Diablo 3 will have some mechanic for it.

To ramble on tangentially, an interesting point from Diablo 1 is that you read spellbooks to learn spells rather than gaining them via experience; And this is more properly Roguelike, if I recall correctly. Remnants of this book-advancement exist in having to purchase spells in something like WoW, though that’s entirely functioning as a money-sink rather than being loot-based. It’s an interesting thought, with books as spell advancement: This means that a mage’s spell power is attached to item acquisition rather than experience advancement. This gives a Wizard goodies to find in all the piles of loot which are generally armour and weapons and item-based character focused.

At that, learning from books was how spells were originally acquired in Dredmor. And there was this awful system where you had to roll to see if you succeeded learning the spell, otherwise the book crumbles – it seems to arbitrary and punitive, so I argued to have it cut. (Some people just like pain, of course, and maybe that’s why they play Roguelikes.)

… What to do with all these old spellbook graphics …

Right, so to bring this back on topic: We’re having player’s choose seven Uberskills at game start. An Uberskill is a skill category (eg. Swordplay, Fire Magic, Fungus Mastery, Veganism) which has between three and eight sub-skills (Unterskills, if you like) which you may advance linearly with skill points earned through leveling. Swordplay sub-skills, for instance, grant bonuses to combat — especially when using swords — then starts giving special attacks that have status effects and more damage or area effects to give some tactical depth to work with.

I’m not really sure what we’re going to do when someone maxes out the paths on all the skills they’ve chosen. We’ll think of something cool.

[Written for the Gaslamp Games blog]

Dredmor: What is a Warrior to do?

2010/12/01

Combat RPGs don’t traditionally offer much active choice to a warrior character: Do you attack? Do you not attack?

Maybe you get to quaff (but never “drink”) a potion every so often. A player’s agency comes more from the set-up to combat through having a much more equipment-driven character than, say, a wizard. It is compelling to collect and use equipment, but a warrior really ought to have something to do in combat aside from clicking “attack”.

But this is a known problem, and it has been dealt before, and cleverly.

I must mention Blizzard’s evolving solutions to the problem: The Diablo 1 warrior had barely anything to do but hit ‘attack’, quaff potions, and collect loot. Diablo 2 gave the Barbarian class piles of both passive and spell-like skills which used mana as a limiting resource (though perhaps mana is thematically inconsistent for the class). Titan Quest did similarly, and with mana. Now take World of Warcraft as an example – it’s been quite some time since I’ve played, but from what I recall, Warriors build up and use “rage” to execute special attacks along with using skills that use timed cool-down periods per-skill as a limiting factor. Or maybe it was Rogues that build up skill to do neat attacks. Regardless, there were also talent trees which gave specialized skills, attacks, etc – The latest D&D even seems to have taken up MMO-influenced abilities for warrior-type classes with gusto.

The necessity of giving pure-combat classes more gameplay/agency has generally been recognized so, in all, games give warrior characters many more choices to make than they once did. One hopes that these are always interesting and meaningful choices, of course.

Dredmor takes up a few approaches to giving warriors the love they deserve: Naturally, we have piles upon piles of ridiculous items to wield, consume, quaff, and wear upon one’s head and/or other extremities. Said items shall have sundry absurd powers and unique odours. We are also giving the warrior a number of pre-combat passive specialization skills and silly special abilities along with in-combat spell-like combat powers.

Between the item collecting, booze drinking, weapon swinging, carrot hunting, area attacking, face mashing, health stealing, and hat wearing, if you really can’t find enough to do as a warrior, you can always effectively multiclass because Dredmor is an entirely skill based game (read: no classes) and is made to be friendly toward combinations of skills across class archetypes.

[written for the Gaslamp Games blog]

The vagaries of the internet’s attention: More Dwarf Fortress design/dev commentary

2010/08/12

I checked my blog stats one morning a few weeks ago and saw this:

Apparently my post on Dwarf Fortress and Goblin Camp got reddited by someone and things kinda took off.

It is a strange thing to suddenly get a whole lot of attention when I’ve mostly just been shooting my mouth off about random things for the sake of itself. I saw people who read my post commenting on points I raised, and I saw people who misread my post comment on points I didn’t even make. Others commented on points I somewhat unintentionally made due to lazy and unclear writing. Others picked up on an exaggerated sense of urgency and conflict between Dwarf Fortress and Goblin Camp that I put into the writing to make it more interesting (presumably, mostly to myself and a couple readers of this blog).

It’s all a bit overwhelming, and it’s always upsetting when it looks to me like someone is wrong on the internet. No wonder writers can get frustrated with their words being mis/re/interpreted!

Right, so there are a few points raised in various comments that I’d like to specifically address now that time has made mild all heated feelings. I’ll uncharitably paraphrase a comment or criticism then address it.

1. “Learn to use the interface/keyboard commands/job manager, noob!”

I assure ya’all that I am familiar with the job manager and that I’ve learned the keyboard commands of DF inside and out. I am indeed not just some noob who can’t be bothered to learn the system and who should go back to playing Farmville or Bejeweled. In my post I left out detailed explanation and critique of the particulars of DF’s user interface for the sake of brevity. It still stands that the systems are esoteric, unwieldy, and – the real kicker – may interact very poorly with the game systems (eg. “Job cancelled by Urist McUrist. Need this or that material!” x1000). Results of supply chain breakdowns are occasionally disastrous, which may or may not be as fun as advertised, depending on your attitude. This last point is where Goblin Camp’s “pull” job orders work very nicely (if things still work as they were described) compared to Dwarf Fortresses “push” job orders.

Let me explain: To make high-level things in DF, a slew of materials need to be processed through various steps, and I need to give the order for each step either by-hand or through the job manager of them. To make a steel item I would need to designate the mining of coal, an iron ore, and a flux material, then order the smelting of the ore into pig iron, order the processing of pig iron with flux into steel, then order a steel goblet to be crafted. I have to push each material and process from the bottom up. Consider an alternative: What if I could just order a steel goblet from the workshop and the workshop sent an order for steel to the smelter which would, in turn, send out an order for iron ore, flux, and coal to be mined from active veins of each? This is “pull” versus “push”. It’s one action from me vs. a whole list of actions.

In the end, it’s about whether the decisions the player has to make are meaningful or meaningless; I don’t want a game to treat me as a mindless automaton. It is largely irrelevant if I mine iron ore square 1 vs. iron ore square 2 (unless square 2 opens on to a cavern full of giant cave spiders, but them’s the breaks). As I was saying, there is a difference between meaningless micromanagement (eg. hand-designating every square to mine out in DF) and meaningful micromanagement (eg. unit ability control in StarCraft).

If I am micromanaging actions that can be handled just as meaningfully by the computer, if it is a problem that has only one reasonable solution that I have to provide over and over, then I feel like I’m wasting my time, and that is the core of my objection to the intense micro of DF.

A couple quick counter-counter arguments:

  • Yes, the “more is more” design philosophy of Dwarf Fortress is indeed its particular charm and I love finding diorite, gabbro, rhyolite and so on even if they could all be summed up as “rock”. However, this quality of excessive detail in DF  is not mutually exclusive with non-tedious micromanagement or a transparent UI/game interaction scheme.
  • Yes, Tarn is ‘working on it’. I certainly respect the problems he is dealing with and I respect him as a game creator — this does not mean it is illegitimate to critique his creation. Which brings me to my second point…

2. “Dwarf Fortress is still in alpha, you can’t expect too much from it.”

Well, yes and no.

It is an alpha in the sense of not being done, but it isn’t in the sense that tons of people are playing it right now as a game. This is not an “alpha” in the usual sense of a linear software development process with an alpha, beta, and final release (and then some followup patches and expansions). Dwarf Fortress has an ongoing, responsive, and open-ended donation-driven development model which is quite unlike the thinking surrounding a traditional commercial game. The effect of this is that DF is a process, not a product.

I contend that it is quite legitimate to comment on the process of DF’s creation as it is ongoing.

There were probably more comments that I should address, but that’ll have to wait for another time. (I will say that I do find all the interest and discussion around Dwarf Fortress completely fascinating.)

I’ve got one final point for this post:

Based off everything Tarn has said in interviews and his dev log, I am struck by the thought that what he wants Dwarf Fortress to be is not the same as the game that most people are playing. Tarn is making Slaves to Armok 2; Most fans are playing Dwarf Fortress. Tarn is making a fantasy world simulator that is focused more on creating a Roguelike/RPG experience than on the Dwarf-themed city-builder which everyone else cares much more about. This is reflected in what development has been focused on: extreme detail for creatures and combat versus streamlining the interface and usability of the city-building game.

And I think that’s really the answer: Tarn is not (deeply and ultimately) in it for fortress mode. Other people, other projects – like Goblin Camp – are in it primarily for fortress mode, for the fantasy city-building simulation game. [To clarify, I wouldn’t say that Tarn is not interested in fortress mode, just that it is not the primary objective of the whole project of creating a fantasy world simulation to serve as a medium for genre narratives. In other words, it’s not his goal to make the best fantasy city-sim it could be, so it is somewhat nonsensical to expect it. With that observed, all this nattering about the design and development of DF is purely academic. I can live with that because it’s fun to write about what DF is, isn’t, could be, and should be. ]

ps: “If you think you’re so smart, why don’t you make your own game?”

Sure! I’ll, uh, keep you posted on how that works out. [More: I really want to do this. I did have a number of months free a few years ago, but I didn’t get as far as creating an actual playable game. It was, however, an intense learning experience. I’d love to do the game-auteur thing again when I’m in a financial position to do so.]

Video Games Podcasts I Listen To

2010/07/23

Or:  Why I listen to people talk about playing games instead of actually playing games.

Mostly.

I’m an artist, right? Right. I draw using my computer pretty much all the time. It’s what I do. Drawing (or ‘digital painting’ or ‘pixeling’ or whatever it is) doesn’t particularly engage the part of my brain that involves language unless I’m actually doing higher-level design. A lot of it is just painting away at something or pushing a lot of pixels. Oftentimes it’s not supremely engaging stuff like drawing lots and lots of bricks or painting lots and lots of clouds – all good and necessary things, yes, but the mind tends to wander. So I listen to stuff. Music works oftentimes, and the emotional content of the music often finds its way in to my art. Other times I want to listen to something I can think about, something relevant to what I’d like to be doing: game design.

I listen to internet audio shows about games. For some reason Apple has convinced us that these audio shows are to be called podcasts, and just as I eventually gave in to using the word “blog”, so too shall I adopt use of the word “podcast”.

These are the podcasts to which I continue to listen, with some of my thoughts.

Three Moves Ahead by Troy Goodfellow (of Flash of Steel, a site I recommend for strategy gamers) with one or more of Tom Chick (of Quarter to Three and GameShark), Bruce Geryk, Julian Murdoch (from Gamers with Jobs), and Rob Zacny

The shows are low-key and honest, almost always excellent, and the commentators are intelligent, well-spoken, funny, and clearly experienced critics. I can’t recommend it enough to anyone interested in strategy games.

I’d love to have a future Gaslamp game featured on there if we end up doing something with strategy; I can dream, right?

Quarter To Three Games Podcast by the aforementioned Tom Chick with various guests from the Quarter to Three forums

In this show Tom Chick talks to a sort of “regular gamer” from his site’s forums in an interview format first about their job, life, and/or interesting life experiences, then about a game they’ve chosen to discuss. I appreciate the down-to-earth tone Tom Chick uses, and the shows often spend a lot of time talking about random things aside from the game being discussed. It may be a bit unfocused, but I appreciate the slice-of-life range of topics.

(There’s also a Quarter To Three movie podcast which is hilarious and insightful. I definitely recommend it to anyone interested in movies.)

Gamers With Jobs Conference Call with Shawn Andrich, Julian Murdoch, and uh, some other guys I don’t remember…

This is basically a “have a bunch of guys sit around and bullshit about games for a while” sort of podcast, though they do have actual subjects of discussion and guests sometimes, even Real Game Designers. Tends to go on for a while, but it gives a good sort of “state of games” impression about a lot of things I’d never find the time (or motivation) to play myself.

Jumping the Shark, “the official podcast of GameShark.com

This is mostly a “sit around and bullshit about games”, albeit from the perspective of a pack of game journalists, with a discussion topic per-show following a what-games-are-you-playing segment. Provides insight into the world of video games journalism (which the participants don’t, I think, promote any illusions about), but mostly it’s a “state of games” show to me.

The Brainy Gamer Podcast by Michael Abbott

It’s not updated often, but as the title suggests, the show is intelligent and has some good interviews/discussions with experienced game designers talking seriously about the subject.

Game Design Advance Podcast by Charles Pratt

New York indie game design; Content full and utterly academic. Having taken some philosophy courses and going to art school means I can totally take anything this podcast dishes, but it’s probably not for everyone.

Experience Points Podcast by Jorge Albor and Scott Juster

Sometimes I’m a bit torn on this one, but I keep listening to it. They don’t necessarily get too deep into discussion and seem to have less to say than more experienced critics and writers (I believe they’re just a touch younger than myself, even), and they tend to talk about more mainstream console games than my tastes run, but it is important for me to find out what such games are all about and they deliver with admirable regularity. They’re earnest in approaching mainstream games with a mind for actual discussion, so I appreciate what they try to get out of it. I think they’re getting better as they go along and get used to the medium.

Aside from these I make forays into other genres; For a while I listened to a huge backlog of short science-fiction stories read in audio form in a podcast called Escape Pod, which I believe has a fantasy and horror equivalent, and a number of tabletop RPG design podcasts (eg. Master Plan, Open Design Podcast) which, though fascinating for a different take on game design, I burned through pretty quickly.

Still, I run out of things to listen to.

Do you have any good game podcasts to recommend?

Game Design Dialectic: Dwarf Fortress and Goblin Camp

2010/07/16

This is only the beginning of a story, but it could prove to be a very interesting story if it bears out. I think it already contains instructive lessons for game development and design.

On the left, Dwarf Fortress. On the right, Goblin Camp.

I hope you know about Dwarf Fortress, the very complex roguelike-lookinglike fantasy world sim / citybuilder. From a development perspective,  DF is a very long-running obsessive project coded by one guy, Tarn Adams, who makes more money than I do (not difficult) entirely by donations from his fans. I admire Tarn’s goals and his creative freedom which lets him indulge his whims – I wish I could do that. I even had fun playing some Dwarf Fortress until I explored most of what there was to explore. It was sweet while it lasted, but I grew tired with the tedium of a very rough user interface and tedious gameplay.

This brings me to a common criticism of Dwarf Fortress: development over the last year, year and a half has focused on revising very low level details about the game’s simulation of how materials interact, particularly how creatures bodies are built with layers of bone and muscle and hair, what properties these each have, etc. It is true that part of the charm of Dwarf Fortress is about the ridiculous level of detail. But it has been over a year and I still have to press a series of awkward keyboard shortcuts to build things, I need to hand-designate every square of ore to be mined, I need to tell each workshop exactly what to make. Frankly, the user interface achieves mind-blowing levels of confusion and  unnecessarily repeated actions which lead to a sense of tedium and frustration that overwhelms my interest in continuing the play the game – so I don’t. Many people don’t even manage to fully learn to use the interface (or don’t want to)  due to – I’ll say it – how bad it is. And further, most new players are overcome by the sheer detail and volume of information that needs to be processed and managed by hand: To speak for my own experience (to those of the DF community that hold in high regard their ability to manage an extraordinarily complex game), it’s not that I am incapable of running a complex Dwarf Fortress game, it’s just that I don’t want to because it’s boring to have to hand-tweak every little thing to keep the place running, and worse still, it actually hurts my hands to press the same keys again and again and again as is required.

I love what this game could be and reading the development page it is full of admirable, sky-high aspirations. But I can’t bring myself to play it. It’s a beautiful idea but an extremely flawed game.

To get the Dwarf Fortress Experience, you’re better off reading the stories people write about their games in forums, eg. the classic Boatmurdered. This removes the frustration of playing the game itself and gives you the high points of amusement at the absurd details and situations which arise during gameplay (which inspired a good deal of the silliness we have in Dungeons of Dredmor, I should add).

And then, if the post’s timestamp is correct, just two days ago on July 14, Ilkka Halila announced Goblin Camp in the SomethingAwful forums.

Now things are getting interesting.

Goblin Camp looks like Dwarf Fortress, uses the same ASCII-graphics, and starts from a foundation of the same sort of gameplay built upon semi-autonomous agents collecting and processing resources in a world build of tiles, but it makes several important departures in terms of project development and design philosophy.

  1. The code of Goblin Camp is released open source. In interviews, Tarn Adams has expressed concern about releasing DF’s code because he could lose control over the focus of the project, lose financial support, and he is not interested in supporting other people modifying (and breaking) the code. Goblin Camp has already been extended by coders other than Ilkka – if the initial interest maintains its present momentum, the game could develop at an extraordinarily rapid pace. I must observe though that GC’s appeal is somewhat cannibalistic on DF’s – It is frustrated DF fans that are excited about CG.
  2. Goblin Camp streamlines play. For example, there is a central depository of craft goods in GC which the player gives orders like “Maintain a stock of 500 wood planks”. Workers are automatically assigned tasks to fulfill this requests, they are sent out in the woods to cut logs which are returned to a carpenters shop to be processed. In DF, one would have to designate a single worker as a lumberjack, scroll out into the map, designate an area of trees for chopping (using the keyboard, by the way), then queue tasks in a carpenters shop by-hand. When designated trees run out, the player has to re-designate more trees – and the player is not told when they run out of designated trees. GC handles the minutiae for the player, reducing the hand-interaction required from perhaps 10 actions to one action, at least. To be frank, this design ethos of streamlining interaction blows DF out of the water in terms of playability already (Dwarf Fortress was released four years ago, by the way).
  3. Goblin Camp abstracts details. While DF has spent a year of development time simulating the material properties required to properly model the penetration of an iron bolt through leather armor, flesh, and bone, as appropriate to the details of a given creature’s anatomy, GC was coded in its entirety in two months and uses simple die rolls for attack skill and damage. The resulting playability of each game’s combat is not a radically different experience: guys swarm each other and people get chopped to bits. The idea of abstracting small details to implement fun features more quickly appears to lay behind every aspect of GC’s development. Further, the mod-friendly and open source nature of the game allows other people to fill in small details at their whim while the primary developer concentrates on the more general framework of gameplay.

Goblin Camp was made, to paraphrase Ilkka, because he loved the sort of game that is Dwarf Fortress but he is impatient and wants to play the game DF could be, that he wants DF to be, now rather than waiting for Tarn to add certain features to Dwarf Fortress – if he ever does. A game like Goblin Camp was bound to happen in response to Dwarf Fortress, and I think Tarn and many others knew it would come. I’m pretty sure similar attempts have been made (there was an Elf Forest joke-game, I believe), but none seem to have really taken off. Maybe Goblin Camp will.

Goblin Camp, as a game and an approach to development, is a critical response to weaknesses in the game and development of Dwarf Fortress. Maybe Tarn will have to react to Goblin Camp out of a need to save his source of income, maybe he will re-focus on making Dwarf Fortress a playable game rather than a complex simulation lost in it’s own obsessive detail, accessible only to an extremely dedicated few. It’s like Josh Petrie’s advice to beginning game developers: “Write Games, Not Engines” mixed with the ethos and methodology of Open Source software, Wiki-style content, and the absurd power of the internet.

I can’t wait to see what happens next.

Dungeon Creation and Beautification

2010/07/08

With most of the foundational art assets completed I’m shifted my focus on Dredmor toward producing content for the game. In particular I’m polishing the dungeon tilesets and creating new dungeon objects (as the game items have actually been finished for a long, long time).

Tilesets

Let me take a moment to explain how Dredmor tilesets work (and used to work, and how they will work). Here’s a cut from the first dungeon’s tileset:

(more…)

The Insane Vortex of UI Redesign

2010/06/17

[Posted to the Gaslamp Games blog.]

This wouldn’t be Gaslamp if we didn’t completely redo a major game system once a week.
And this wouldn’t be the ongoing Dungeons of Dredmor beta if we didn’t completely redo between three and five major game systems every week!

Let’s talk about UI redesign.

Here’s the main game UI in Dredmor 0.4:

(Click on any of these images to view at full size.)

Not so bad, right? Rather archaic and clunky, perhaps. But the clunky UI has what we might call character.

I think that the defining feature of Dredmor is not elegant gameplay, great graphics, or cutting-edge technology — it is character: zaniness, a weird ‘take’ on everything. We reference Doom, Diablo, and Ultima with the UI, and I imagine people who understand Dredmor are people who have nostalgia for those old games. And this old thing is finally getting to a useful place with the auto-loading of starting skills and the keyboard hotkey number implemented.

Still, the UI has been problematic and it does look old. I’m quite torn on the issue of revising it, but we’ve had some ideas kicking around and after arguing with Daniel which ended with me coming around to possibly trying a new model for the UI, we started in on The Madness. They key idea is to improve skills interactivity, to make them easy and intuitive to use by having skills act more like items and, at the same time, to have items act a little more rationally. (For example, if you’re standing back and merrily shooting a cluster of enemies with a crossbow and you fail to notice that you’ve run out of bolts, your next click on an enemy will cause you to walk over into the group of enemies … which is exactly where you don’t want to be, presumably because you were off with a crossbow doing crossbow things because you’ve wanted to avoid melee combat.)

A lot of that is about the coded interactivity of the objects. Weird things are happening in the next patch; it takes some getting used to the new metaphor for interacting with skills, objects, and the new, combined quick-use bar, but I think it’s working. And I’m getting ahead of myself.

Back to the visuals: How could we redo the UI to be sleek and efficient, to use the new skills-as-items model? I drew some quick sketches.

I must admit, I actually drew these in reverse order, from 5 to 1, and 1 is based on a very rough sketch that Daniel sent me (by taking a picture of a drawing on paper, of all things). I rather like the top one with the Diablo-style health and mana orbs because it retains the character portrait box and goes with the rather radical move of making major UI elements like the quests, inventory, and skills accessible only through items (which we’d make very, very sure the player could not lose.)

As either a conservative or intermediate step, who knows, I quickly adapted the old UI to the one quickbar model, based on a charming sketch by our dashing lead programmer, Nicholas. [He’ll probably hate me for showing the world his drawing, but I thought it was so adorable that I had to save it … with multiple backups.]

I quite like how the statue on the left has grown a beard in his interpretation.

Here, then, is a mockup of the new minimalistic game UI and then a first draft’s implementation which is in the working code and will likely be released in some form or another with beta version 0.6. This is just the visuals; Interaction is changing a lot as well, but implementation of that is more Daniel’s domain.

It’s quite a change, and it does lose something of the character of the old UI — and the portrait is cut entirely out, but then I didn’t look forward to drawing 28 of those. Hopefully we make up for this loss with some very interesting gains in other areas of the game … which is a subject that shall have to wait to be discussion until another day.

Experimental Perspectives on Tilesetting

2010/06/10

[Originally posted to the Gaslamp Games Blog]

We’ve got a little design problem in Dredmor that Daniel has named “fighting arrows”. See the little arrow at the bottom of the screenshot on the left? It points to a blobby-monster just poking its little eyes out from behind a wall that otherwise covers it up. The arrow is a helper icon to make sure you notice that there’s a monster.

No, this is not elegant. We’ve also got issues with doors being difficult to see behind walls. Well then, how do games deal with the problem of stuff hiding behind walls?

One solution which came up was that of Zelda: A Link to the Past — they made it so that there is no ‘behind’ walls. See the right screenshot: everything has a rather subjective take on perspective. The player sees the face of all of the walls, no matter what direction they face! One column is seen from the front, another is seen from the right, and there is even some weird overlapping balcony thing. The world of A Link to the Past has a take on perspective that would make Escher proud, and the game manages to get away with it.

Could we?

I threw together some test graphics last night.

It would be painful to redraw all the tilesets, but it could be done, and a couple could be cheesily re-colored or something to cover all the dungeon levels. But what it comes down to is that the perspective our player character and monsters are drawn in is way too much looking like a strong front-view. All the characters in Zelda are, if you notice, rather squat, like they’re being viewed largely from above. And they’re smaller, just a bit more stylized, visually contextualized in a looser manner that lets them exist in an environment with a fantastic interpretation of perspective.

From talking it over with Nicholas, it sound like we could have gotten away with it if we’d designed the game this way from the very beginning (which was what, six years ago? And I’ve only been around for nearly two. Oh, and how many things I would change if I could have been there to help design the visuals of this game from the start!) Alas, we’re locked into a certain direction with only so much room to maneuver. Re-writing the rendering and dungeon-building code and redrawing all the tilesets is a bit too extreme a maneuver, I’m sorry to say. And before anyone suggests it, I think Nicholas would go into some kind of coffee-fueled berserker rage if we suggested he re-write the rendering code to support transparency masks or wall opacity when we’re halfway(?) through the game’s beta.

Don’t worry, we’ve still got tricks up our wizard’s sleeve.

Two and a half perspectives on Game Design

2010/01/17

(above, a concept sketch for one of many game designs I’ve been kicking around)

Mechanics Dynamics Aesthetics

First, the paper with the above title by Robin Hunicke, Marc LeBlanc, Robert Zubek : http://www.cs.northwestern.edu/~hunicke/MDA.pdf

To quote two analogous flows from the paper:

Rules -> System -> “Fun”*

Mechanics -> Dynamics -> Aesthetics

Now I’m going to paraphrase and rough over a lot of what the authors surely intended, so read the (short) paper if you have a minute.

So:  Mechanics are the encoded rules of the world; the most basic units of interaction the player has with the world and the world has with itself. Dynamics are the system that arise from the interactions of the rules — (And how beautiful this is! It explains the interest I had in doing A-life stuff in art school).  From Dynamics and a little artistic nudging come the aesthetics of the game, the experience evoked. Simple, yeah?

I’ve played Super Mario World recently. To try this out:

  • Mechanics: The player can jumping, move; There is a world that constrains and moves in particular ways; There are enemies that remove abilities from the player or end the level that move by set rules and timings.
  • Dynamics: The Player jumps off the backs of a row of flying turtles to cross a pit, grabbing coins in the air along the way.
  • Aesthetics: The thrill of success, the fear of falling, the narrative righteousness of fighting the bad guys, exploring the world and finding novelty in new elements.

MDA provides a framework for thinking about game design. Interesting.

* Regarding the word fun, I’m a huge fan of the Tom Chick school of never using the word “fun” when seriously discussing games. (Apologies if I paraphrased his intend incorrectly – I’m just taking a sentiment he’s expressed and running with it). “Fun” is a rhetorical escape, a vague and generic desirable quality that avoids discussion of what exactly it is that is supposed to be fun. It implies that interest and enjoyment (in the broad sense) of media is only about a “fun” feel-good quality. Surely people can also enjoy media that makes them sad, angry, wistful, whatever; there are any number of emotions and aesthetics that a game could evoke from its audience that are not at all easily contained in the word “fun”.

The MDA paper does indeed expand upon what it means by “fun”, so don’t take the above as leveled at them.

A Game Is Not A Story

MDA reminded me of an interview (by Tom Chick, actually) of Andrew Mayer, a designer of “social games” (think: Facebook games). If I recall correctly, Andrew Mayer observed that when people find out he makes games for a living they come to him with their ideas for games — but what they have are not game ideas but story ideas.

Perhaps the naïve approach is to the start thinking from the endpoint of game design, about the high level aesthetic/narrative. “I want to make a game about a guy who does really cool stuff in a neat place!”. As a game design, this forgets an awful lot of low level design that lies beneath the high level narrative.

(And I would say that a lot of major games miss this as well — they really ought to be making something more than an occasionally interactive movie. Or maybe I expect too much; A lot of big-budget games nowadays are, when compared to old SNES games, just as simple and likely much more forgiving in terms of difficulty. Maybe I expect too much sophistication because of the monstrously sophisticated media production that goes into these games.  But this digression is getting huge; This deserves more thought elsewhere.)

This is not to say that  my personal approach to design doesn’t begin with a vague idea of the finished game I’d like to make, of course. The trick to being a game designer is perhaps seeing all the little moving parts within the game, under the story and characters and aesthetics.

(Tangentially again, I have to say that I have a strange time playing games nowadays: Everywhere in games I see and “read” designer intentions rather than the world-narrative of the game. I game the game, and it’s so much harder than it used to be to find myself completely enveloped in the game’s fiction.)

Restraint, Rigor, Rationale

From Fullbright, Steve Gaynor discusses The Three R’s [of game design], which I simply must go on to compare with MDA.

Restraint is the act of resisting the urge to throw in every idea you have simply because it sounds cool, awesome, or hilarious.


Rigor is applied through the act of objectively and deeply considering the practical implications of an idea.  …Your job is to attack your design idea from all directions– technical and gameplay systems in equal measure– and find the holes in it before moving forward.


If Restraint questions the “what” of your idea, and Rigor questions the “how,” then Rationale questions the “why.” Does this idea fit into the broader experience– the identity of the gameworld, the conceits of the fiction?

Though the Three R’s post is worded in a more, um, imperative manner than MDA, it proposes a roughly analogous model of game design. Yeah, Mechanics and Dynamics are not distinguished, but Rationale fits with the notion of Aesthetics and further demands that the Mechanics and Dynamics (“ideas”) of a game support its Aesthetics.

And at that, Restraint and Rigor are fundamentally useful values to hold for creating elegant, efficient design — and a design, at that, which will ever be completed. (–Because, as those of us who’ve worked on making games know, games are intensely complex beasts that can grow in on themselves and out on new features forever if you don’t draw a line somewhere).

* * *

I think it will be fascinating to discuss Dungeons of Dredmor in terms of all the above, because wow, if one learns from mistakes then I’m learning a hell of a lot through making Dredmor. We’re kinda in the midst of pushing to beta so things are crazy. And the desire to ship is such that I think desire to ship a playable game is overcoming creative preciousness. But more on this another time.