Jump to content
  • Advertisement
  • entries
    134
  • comments
    273
  • views
    174976

Design Dialectic: Dwarf Fortress & Goblin Camp

Sign in to follow this  
dbaumgart

958 views

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.
Sign in to follow this  


5 Comments


Recommended Comments

Kurt and I used to call it "automated tedium". That term was coined in reference to a different game series (SSI's Gold Box AD&D games), but it stuck as a "what not to do" piece of advice. We constantly try to think of ways to make a game more fun and less work to play.

Share this comment


Link to comment
Kurt and I used to call it "automated tedium". That term was coined in reference to a different game series (SSI's Gold Box AD&D games), but it stuck as a "what not to do" piece of advice. We constantly try to think of ways to make a game more fun and less work to play.

Share this comment


Link to comment
Nice write up.

Quote:

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.

To be honest, I think that Tarn is making a game, not an engine, backed up by great community (take a look at the number of post in the DF forums). The game lives from emergent gameplay only possible in a complex simulation.

On the other hand I think that open source is not the holy grail the world has waited for. Don't missunderstand me, I'm using lot of open source tools (gimp,blender,open office,eclipse ..). From my experiences open source is
- free
- inconsistent (behaviour changes the preferences of the according developer)
- mid-quality (80%)
- freak-ware (you need to configure X and install Y , seldom out of the box use)

Before you start to stone me, what paint tool are you using ? Photoshop or gimp ? That's it, open source is 80% of what you want for free, but the last 20% is quite a p... i. the a.. .

I have taken a look at goblin camp and the first which comes to mind is: you need to install VC++ 2010 runtime (freak-ware). They have some basic stuff running, but nothing complex yet. As sole developer you are ridiculous efficent, in open source team you need to have really good developers at hand, else you will end in hunting down bugs. A game is not a tool, balancing might be the death of any complex open source game.

Yeah. I would like to see some visual interface to DF, but Tarn has done an incredible job sofar and in my opinion golbin camp "could" end like all those open source games which will be updated in the first year, then die the silent death of
inactivity.

Btw. this would be a nice dicussion topic in the forums :-)

Share this comment


Link to comment
Quote:
Original post by Ashaman73
Nice write up.

Quote:

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.

To be honest, I think that Tarn is making a game, not an engine, backed up by great community (take a look at the number of post in the DF forums). The game lives from emergent gameplay only possible in a complex simulation.

On the other hand I think that open source is not the holy grail the world has waited for. Don't missunderstand me, I'm using lot of open source tools (gimp,blender,open office,eclipse ..). From my experiences open source is
- free
- inconsistent (behaviour changes by the preferences of the according developer)
- mid-quality (80%)
- freak-ware (you need to configure X and install Y , seldom out of the box use)

Before you start to stone me, what paint tool are you using ? Photoshop or gimp ? That's it, open source is 80% of what you want for free, but the last 20% is quite a p... i. the a.. .

I have taken a look at goblin camp and the first which comes to mind is: you need to install VC++ 2010 runtime (freak-ware). They have some basic stuff running, but nothing complex yet. As sole developer you are ridiculous efficent, in open source team you need to have really good developers at hand, else you will end in hunting down bugs. A game is not a tool, balancing might be the death of any complex open source game.

Yeah. I would like to see some visual interface to DF, but Tarn has done an incredible job sofar and in my opinion golbin camp "could" end up like all those open source games which will be updated in the first year, then die the silent death of
inactivity.

Btw. this would be a nice dicussion topic in the forums :-)

Share this comment


Link to comment
Merlin
Oh, definitely. Once I noticed myself reproducing the same tasks again and again, like running huge parts of the game according to some optimal algorithm, I tend to get pretty fed up. This brings to mind this thing Bruce Geryk wrote on wargames* from which I'll quote copiously because I think it's a great couple observations about games:

"I've always been of the opinion that games have to give players choices. If there is only one best move, then it isn't a game - it's a puzzle. Figure out the puzzle and you're done. That's fine, I guess, for puzzles. But not for games. If there is part of your "game" that is obvious and has only one possible solution, it shouldn't be in the game. Unless you made a puzzle by accident."

"...anything that has one and only one solution should be omitted. If you are making a game of World War II and there is one single best way to invade France, you should just start the game after the invasion of France. Or quit game design entirely.

Instead, computer wargame designers seem to have embraced the idea that because the computer can make things infinitely complex, all you really have to do is bury your game in so much detail that the answer to whatever puzzle you've created takes so long to figure out that you get the necessary replayability simply out of trying to deduce the solution."


... and it is kinda fun for a while to explore how a simulation works, but at some point when there's only one real choice for any given set of problems, it all breaks down. It's less a problem in multiplayer of course because at least you can gloat about winning ;)

Oh, and I remember another aspect of this: When you have to micromanage to get an optimal solution. Sure, Medieval 2: Total War gives you the ability to auto-resolve the more tedious battles, but the computer always buggers it up and either loses or loses way more troops than it has to. Given the choice between loses battles and having the micromanage, there's no real choice!


*And later in that article he goes on to bemoan players' obsession with making games more detailed. Reminds me very much of weaknesses of DF for detail over playability. (Though a game *can* be made from its details, and DF is a strong argument for it ... )

And in a (slightly) more conventional game like Hearts of Iron 3; from HOI2 to HOI3 the game went from division-level control to brigade-level detail, and now some players say they want the game to give them control over the company-level composition of units! Happily, most fans of the game realize that it'd be an insane micromanagement problem to run all of World War 2 on the company level.)

Ashaman
Game vs. Engine:
Oh I agree - 'course he's making a game, and it's only made possible by a strong, insanely dedicated community. (And I wish I could be doing what Tarn does!)

What I mean by referencing the game vs. engine thing is that he seems to be laying groundwork for further simulation details rather than making the thing playable in very straightforward and important ways.

But I see now that it's a rather inverted analogy! JPetrie's article is about coding for too much generalization, of the production of a playable game suffering for focus on developing generic systems. But Tarn is working on systems that are far too specialized - albeit in service of the general system of the sim - and so causing the playability of the game to suffer. So specificity in service of general systems causing the game to suffer. Maybe it works. Uh.

I have to concede that it's an awkward and rather indirect connection. Heh! I just have to say that "Make a game, not an engine" is a mantra I repeat to myself as I find my mind drifting toward thinking about how to make a tool or mechanic or asset applicable to anything, all kinds of digression that gets in the way of just finishing the thing.

Open Source as holy grail:
Oh, I'm totally a slave of Photoshop; It's amazing.

I should say that I don't think I'd want to idealize Open Source, but (I may use some oft-abused buzzwords here for which I apologize), what I was getting at is that whatever is going on with Goblin Camp seems to be of that whole zeitgeist of "crowd sourcing", of having many individual volunteer enthusiasts create and evaluate the content of a project rather than there being a single authority. Doubtless 90%, 99% of what will be made for Goblin Camp (or which has been modded into DF) is crap - or crappy because it isn't finished, or appeals to too specialized an audience for me to appreciate it, etc, but sometimes a community organizes large sets of "best of" content into a sort of required-mod pack; I remember such examples for Sim City 4, Morrowind, and ... something else, probably.

And yeah, from a realistic perspective, it is most likely that Goblin Camp will die off. But I see it example of a trend for games spinning of mechanics found in DF. Minecraft is another example (and by a sole developer).


Jeez, I should probably just write another post from these replies ;)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!