Archive for the ‘game development’ Category

Dredmor Skill Icons


I’ve just finished the latest round of revisions to the entire pile of spell icons. This is just one task which is part of the massive spell overhaul we’re doing for Dredmor’s beta 0.92 (when I’m not getting distracted drawing the disembodied heads of founding members of Gaslamp Games).

Man, there are a lot of these buggers, but they do get easier (and better) every time I redraw them. Telling you anything about them would ruin the fun*, so I’ve just thrown together a collection of some of my favorite spell and skill icons for your enjoyment:

dungeons of dredmor skill and spell icons

Still have to draw animated effects for most of these. Urrgh.

* whereas “the fun” refers to how much fun I have as people try to guess what the hell some of these skills do.

[Originally written for the Gaslamp Games blog]

Dungeons of Dredmor Trailer #4 & Release date announcement


[Incredibly, this sat in my draft pile for ten days before I noticed that I forgot to post it. Oh well. All the action is going on at the Gaslamp Games blog anyway.]

Alright, I’ve been slaving in the pixel mines on this one for years and now the end is truly in sight. The release date for Dungeons of Dredmor is set for April of 2011!

Here’s a lovely trailer that Nicholas put together:

Be sure to view it in high quality so that you can appreciate our awesome resolution jump. Yes, 800×600 just isn’t good enough for the year 2011.

Also: Gaslamp Games has also finally picked up on using that Twitter thing, so check out our twitter page here.

The last … long time, but the last week in particular, has been exhausting as we’ve just pushed out beta 0.90 which is our first beta build with completely revised game mechanics and increased resolution.
Yeah, this is happening for real.

Starfarer: Pew Pew!


Or: Weapon design & graphics modularity in Starfarer

A game which revolves around combat in space naturally places great importance on the weapons uses in said space. In short: They must look really cool. Here’s a picture to show how I’ve been going about this:

Click to view full size. You see here the process of taking a weapon design from concept art to pixel-art sprite to in-game screenshot. The barrels of the Heavy Autocannon — a nice standard warship cannon — recoil individually upon firing.

And how about some background on what influenced this outlook on displaying weapons?

Read the rest of this entry on the Starfarer blog

Commitment Anxiety in Skill Selection


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?


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]

Starfarer Ship Design


This is from a series of posts I’m writing to promote the space combat sandbox/rpg game Starfarer by Fractal Softworks.

Ahoy there! My name is David and I’m what passes for an artist around here. But enough about me; I’d like to talk a little about how the graphics of Starfarer come to be, starting with the Onslaught-class battleship which we have already featured from a standpoint of gameplay and game fiction. I’d like to show you my process of creating the visual design of the Onslaught from concept sketch to final sprite.

The Onslaught-class Battleship from concept to sprite:

Read the rest of this entry on the Starfarer blog

Starfarer by Fractal Softworks


The game “Starfarer” by Fractal Softworks has just been publicly announced! It’s a sandboxy spaceship combat/strategy/roleplaying game and is still in production.

Oh, by the way – all the graphics are by me! (And the lovely background is by NASA, I should add.)

Art for this have been a ton of fun to draw. It’s been really hard to keep quiet about this but now I can spill the beans, so count on me writing more posts about how I approached the ship and weapon designs, drawing planets, and everything else graphical.

Starfarer will be released sometime in 2011; be sure to follow development and release news at the Fractal Softworks webpage.

Dredmor Design Dialog


At Gaslamp Games, I’ve long since learned that it’s far better to present Nicholas with a fait accompli which he finds amusing to implement rather than a rational argument for a feature. Allow me to demonstrate.

NV: What am I supposed to do with ingots, herbs, and fruit?
DB: *shrug*
NV: You do this just to tempt me, don’t you.
NV: …Fine, I’ll play your little game.

NV: Fuck you for making me add smelting.
DB: You didn’t have to.

NV: What’s the coal for?
DB: The iron needs a carbon source to be turned into steel.

Just another day at Gaslamp Games.

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


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.]

Pop-up icons are awful!


This might seem negative, but I found that I have a visceral reaction against the subject of this post and upon being confronted to explain myself I believe that there are good justifications for my feelings. So let’s hear ’em!

(I’ll even apply this to UI design in Dungeons of Dredmor at the end.)

While redesigning the Gaslamp Games blog, our web dev’r found a plugin for WordPress to give a viewer the ability to share a post on social media sites (which is the cool thing that The Kids do these days, I hear). This plugin is SexyBookmarks. Here it is on the Gaslamp site; my mouse cursor was over the icon:

You get a row of social media icons that pop-up on mouseover. Yes, it’s cute. But I hate it.

The point of an icon is to be a sign for what it represents which is identifiable at a glance. It is the symbol of the thing condensed and simplified as much as possible. This plugin cuts the icon in half, hiding much of the visible space, making it less identifiable. This defeats the purpose of having a full icon.

Is it about saving space? It doesn’t: In the half-hidden mode, the icon is shifted down 10 pixels and upon mouseover the icon is shifted up 10 pixels. These 10 pixels for the icon to move into are left blank anyway, so no space is saved. Why not just use fully visible but slightly smaller icons so that they are more readily identified at a glance, so that they use the full visible area given to them as the designers of the icons intended?

If this is not about saving space then the purpose that remains is using a hidden/unhidden visual cue to designate the mouseover state. Though as said, this conflicts with the design of the icons in the first place because it obscures their quick identification.

In the end it is a gimmick because its outstanding feature interferes with its function. Yes, it’s a cute trick, but it does not make a useful plugin.

… also the web2.0-looking shadow effect doesn’t fit at all with the Gaslamp webpage’s aesthetic.

How does this apply to Dredmor?

A long, long time ago we tooled around with having the quick-slot item bar be hidden slightly behind the UI to give the main game area more viewable space. It would pop-up the item bar to show the full item icons when the mouse go closer to the bottom of the screen, where the items lived. We decided against this design in the end because you couldn’t really tell at a glance what items you had unless you went to mouseover them, which defeats the purpose of having an easily accessible row of icons on the main screen. And it didn’t even save very much space, maybe 16 pixels in all. And it was annoying.

Moral: If you use icons, show the icons. The only information which should be hidden should be information that is not needed at a glance.