Although this interview should really be accompanied by a little more contextual content (as a case study) Tarn Adams was such an eloquent respondent that the interview itself covers most of the points I wanted to address. Dwarf Fortress is a emergent world sim built on the heritage of rogue-likes. The graphical interface is a pimitive mix of ASCII art and DOS style menus, harking back to nethack and ZZT. However, this initial visual impression belies the internal complexity of the project. Under the blocky ASCII interface lies one of the most complex simulation systems in modern games. Both procedural world building and realtime emergent behaviour are core elements of the game itself. To this end, the depth of simulation in Dwarf Fortress is extensive, ranging from narrative and historical texts constructed in realtime to procedures that model animal migration and npcs emotional states. In addition to such autonomous functions the in-world mechanical tools are so modular and flexible that players have built functioning calculators and simple computing systems with them. This range of possible utility demonstrates the complexity of the game world and the near ‘turing complete’ nature of Dwarf Fortresses simulation. Tarn Adams is the sole programmer for the project, working alongside his brother (who concentrates on the narrative and descriptive details). He earns a small wage from player support and is dedicated to the long term development of the project, adding new simulation elements with each build. The following interview was carried out with him on the 1st July 2010.
An annotated fortress
How much do you feel that the mathematical basis of Dwarf Fortress’ world-building influences the aesthetics of your game? (and is it at all important for you that players realise the ‘science’ behind these game design processes)
The algorithms you choose impact the outcome. You can control it with a lot of work, but oftentimes that isn’t even desirable. In world generation, for example, a mid-point displacement algorithm gives you horizontal and vertical artifacts, which can be mitigated by the diamond-square algorithm, and basic perlin noise looks fluffy and rounded. You can adjust things, but eventually good enough is good enough and then you have your final output with that character. I think it’s better in a way if the players don’t focus on the science behind the processes, because the main idea is to become immersed in the game and not think so much about the nuts and bolts. That said, it’s cool to try to understand things as well — people approach the game from different directions. I suppose it’s important donation-wise that people know I put a lot of work into the guts of the project, but that won’t have so much influence as long as they enjoy the game.
If the advancement of storage, memory and bandwidth has eliminated some of the historical reasons for using procedural technology what do you see as its key advantages today?
Procedural generation can make a game more replayable and add to the variety even within a single play (and it makes it more playable for the developers!). Even if you are in a situation where you’d prefer to have stuff hand-made, using procedural generation can reduce costs. It can be used to fill in less important gaps quickly and thereby expand the overall scope of a project. If you have a method to make something procedurally, it might as well be the method you go with *unless* the lack of an artist’s touch has enough of a negative aesthetic impact to outweigh the positives (using the word artist broadly — level designers, writers, etc. are included). It’s also possible to guide procedural processes with enough artistry that they can work well together, though it’s an ongoing process in general, as far as quality goes.
A fan-made 3d visualiser
How important are generative /procedural systems as ‘active’ gameplay elements rather than pre-production content creation tools.
Virtually all of DF’s procedural systems happen during play, so they are incredibly important to me that way. The only procedural generation that happened to generate content not generated on the fly was the first pass on the language dictionaries, as far as I can remember. I guess the world map generation occupies a sort of middle ground, depending on how you interpret it. Generally, a lot of procedural content is pre-production (as with procedurally generated forests, say, in a fixed-map RPG, assuming they are the same every time). Starflight worked that way as well, with its planet maps kind of prepackaged as far as I know as good seeds in their generator. AI with any degree of adaptivity could be considered active procedural content, and that’s becoming fairly common.
When using generative systems how do you isolate/guide the desired result (ie. do you start from a wide chaotic range and refine or determine the outcome more tightly from the beginnning)?
It’s highly dependent on what the particular problem is. I tend to make a best guess and refine, when it comes to the code itself. With some experience you can kind of tell how things are going to work out to some extent, but even in controlled cases there are happy accidents and unhappy accidents that you run with. There’s also the notion in world gen of rejecting worlds that fail to meet parameters (this is shown to the player simply because the process would be too time-consuming and static otherwise) — that’s sort of a final test on the chaos in the system, where attempting too much control early on could kill the best keepers.
A detailed fortress interior
How frequently does the result of your procedural content surprise, shock or disappoint you? (do you ever feel out of control)
Equal measures of all of them, especially when I’m hoping something will work and am not quite sure precisely how it will play out. For instance, the first time I mixed simple fractal elevation, rainfall, temperature and drainage maps to produce a biome map, I knew that it would give me biomes in roughly the percentages I wanted without the boundary problems of some other methods, but I had no idea what the actual character of the 4-layer overlap would be, and it was really cool to see the maps sitting there. At the same time, I was disappointed with my mountains, even after I did the erosion simulation. Some kind of tectonic simulation will probably be needed to make them look great. I don’t generally feel really out of control, but it’s important to take on projects you understand somewhat or you’ll never be able to massage them into shape without getting lucky. That’s said within the context of a single procedure for generation. When we take many of them together, there are more and more moving parts (often with rough edges), and then you get into the related buzzword to “procedural generation”, which is “emergent gameplay”. By its nature, this should be surprising at first, or it probably doesn’t qualify. It does make me feel more out of control sometimes, and at that time I fall back to other design principles than trying to strictly control generation or removing generation — the one I’ve been going for most in DF is “if you attempt to model real world behavior, you can work to get real world results”. Real-world results are fine in a world simulator, so when I’m not sure how a new mechanism will work out, I try to approximate the real world analog as best I can. Problems can then be sorted out by identifying what is causing it to deviate from real world behavior. It’s possible this kind of thinking will break down as DF moves from physical to psychological models, because it’s harder to do good models there even at a vague macro level, but we’ll see how that turns out as I put more of those mechanics it. Right now AI is highly controlled.
Who are the ‘authors’ in a typical DF game? How much of this role is held by you, the system and the players?
My brother and I create the systems (including some fixed content), and the choices made at that stage are influenced by our preferences, worldviews, talents and flaws, and then the system creates the content. The players are exposed to the content and can manipulate it using the tools we (and others) create for them. How they use the tools is up to them, and how the content reacts is up to our systems. There’s a common happening in computer games where a player’s mind will fill in the gaps in mechanics with stories of their own, either consciously embellishing or by assuming mechanics are more complicated than they actually are. This is something that a game designer can be aware of, and it influences how I do things. It is one of the cool things about computer games that I can’t find an exact analog for in other more traditional creative endeavors — perhaps magic shows or similar theater, though it isn’t about misdirection so much as it is about providing enough raw material for the imagination to work with.
Star Flight
Who or what has influenced you in your approach to programming/developing DF?
Several games I played in the 80s (Star Flight, various Roguelikes) relied on procedural generation. I’ve been programming as far back as I can remember, writing little games and things, and the idea that things can be created as the game goes along was an early concept that has colored pretty much every project I’ve worked on seriously.
Why did you choose such a simple ascii based GUI and Visualisation?
It’s faster to develop in ASCII. I’m also not an artist and have no resources for hiring one, but even if I did, the development speed would be reason enough to not get too far into graphics territory.
Is process more important than product (both as a player and a designer)?
The DF journey doesn’t seem to have an ending, so I’m not sure we’ll ever know, he he he. I’ve been writing the games long enough now that it’s hard for me to separate playing my own games from writing them. My brother and I started wanting to write games that we would want to play, and it’s fun to sit down and play them, but development is always there in my mind when I do that. In general, development cycles are loose on some projects, and there’s no real end point, but there are releases, so you can play, enjoy, hope for improvements and follow development all at the same time. If you are player of a project with a single release and fairly closed development, like many games, the end product is all that matters (except maybe for the process of patching!)