The Dwarf Fortress Interview: Part Two
Thanks to all of you who submitted questions for Tarn and Zach Adams, creators of Dwarf Fortress. Here are their responses. Oh, and if you missed part one of the interview, it's here.The number one question has been about a 2D graphics engine. I see that you're supporting user-imported 2D tilesets now. Are there any plans to increase the level of support for those kinds of user mods, or does that question even make sense? (this is my question, as a summary of a bunch of user questions into one).
Plus, have you tried any of the user-created tilesets, and if so, what has been your general impression on how effective they are?
Eventually I'd like to allow 2D tiles to be used optionally for all of the game objects and remove the requirement that the viewport be 80x25. This gives rise to text that isn't the same width as the tiles, which allows more text to be displayed. There are some associated hassles, so I haven't been in a rush. The same goes for mouse support. Once you've got a 2D engine running independent of the 80x25 tiled viewport, there are a lot of interface options that open up, but that's something I'm not thinking about right now, since all of the interface is still subject to change in general.
I can play with my own "miner only" default graphics set that turns the rest of the dwarves into colorful blobs without discomfort... I guess I've been working with the game too long, so it's not something I think about while I'm playtesting. My main concern with the tilesets I've seen posted is being able to distinguish the different dwarven profession types, although I haven't tried one, so it might not be a problem. As you draw more and more humanoids, you have to increase the resolution to be able to distinguish them, and since DF is locked down with 80x25 tiles on the screen, there isn't a lot of room left to both represent and differentiate, though people are certainly doing a better job than I would have been able to do. It's good to have the options though. People can even create tilesets that don't attempt to depict the objects in question, but expand and improve upon what's available in the original text tileset.
What language is Dwarf Fortress programmed in? Would you ever switch to or develop another project in a language like OCaml(pronounced o-camel)? (Aaron Ogden)
I wrote DF in C with some C++ sprinkled in as I've learned it. I certainly can't move DF to another language at this point without burning a lot of time, and I can probably develop other projects faster using C given the amount of code I have laying around. I wouldn't rule anything out, but I'm more interested in making progress on games than in worrying about the technical details, even though I miss out on some benefits from picking up all of those things. I don't really consider myself much of a programmer. People occasionally try to introduce me to this or that, but unless there's an obvious practical gain, I'd rather use the time for writing games or less painful diversions. It reminds me of when my father always tried to get me to build AM radios when I was growing up. I don't remember even opening one of the little kits up.
You allude to this in the first part of the interview, but just to address this specifically; it seems that a major part of your design is based around the player feel like they accomplished something important in the game. What are the methods that you like to use to increase the emotional investment of the player and why do you think they work? (Thomas Moyles)
In both dwarf mode and adventure mode, permanent death/loss is important. This thinking comes from our experiences with arcade games, roguelikes and pen-and-paper roleplaying games (at least how we used to play them, he he he). If one of your dwarves dies and you can just reload, it wouldn't matter so much. A player can still backup their save folder (and this is recommend since things can go wrong technically with the game), but you can't just reload ten times to reattempt a challenge without some hassles. Permanent death doesn't work as well in games without random elements though, and features like the legends/history or just a decent high score list are necessary to preserve something of the character that has been lost, I think, or permanent death can just be depressing.
I think all of the little details that make the game more immersive, even the butterflies and rivers and those worms you can dig up in adventure mode, also get the player more involved in general, which can help them identify with the fortress or adventurer they are playing. The same is true of the quirks the dwarves have, and their various thoughts and emotions, as well as their names and properties like their skills. When creatures are individualized, it helps the player associate with them, and if something happens to the creature later on, good or bad, the player will be invested in it. They might even feel responsible for something tragic, but it's part of the game. It's not a given that this will happen, but the opportunity is there, and it's something we'd like to build on.
The legends screen is supposed to help with the player's sense of accomplishment and their investment in the world -- I don't think the legends screen is as powerful as it could be, but that's because it's still in progress, though I think the game history is most powerful when it comes up in-game during subsequent plays. For a simple example, consider the speeches made by opponents that have killed a previous adventurer -- they are a bit repetitive now, but it helps to get you to really dislike the opponent in question when your previous death is highlighted. You also know that each victory over such an opponent will be saved as a legend. It'll be better when you can find books and songs written about such things, and in the future we want to further individualize these opponents. Dwarf mode legends are really sparse right now, but it won't take much work to get more information recorded. The feature where you can see some fortress events played out on the stone and in item artwork really received a positive response from people, and there will definitely be more elements like that coming in over time. The appearance of parts of the previous games in subsequent games is the high score list for DF in a sense.
A lot of this implies that players need to invest quite a bit of time in a world to get the most out of the game, and a lot of our planning relies on this notion that players will be able to play multiple times in the same world. As it stands, people need to invest a few hours just to figure out what's going on, but even as the interface and documentation problems are worked out, DF will continue to require a time investment to get the most out of the game. DF can't work for everybody, though I think more casual gamers or gamers with limited time can still enjoy it, especially when it takes less time to learn the ropes. This might be more true of adventure mode in the end, once there's a bit more to do there, since it will always be easier to get started with a single character to control.
You've mentioned the importance of myth as an influence in your work. Is there any chance that Gods will affect or interact with any of the characters in Dwarf Fortress?
In the original Armok dev notes, which apply here, there's this notion we had of a "force", such as the "Spirit of the Shrouded Forest". A force could have goals in terms of the game world and ways to work toward them, through particular natural disasters, influencing associated wildlife, and so on, much as a civilization will work toward its goals with its armies, diplomats and merchants. A god was planned to work like a force but would often also have an associated personification that gives it some of the properties of a historical figure (like the civilians in the town or a dragon in a cave). The personification might manifest optionally or be permanent, and one god could have several of these forms. The extent to which a given god can work toward its goals in the world is roughly the extent to which it can interact with characters in the game. Once DF gets up to this point, we had in mind that there would be customization options that would allow you to preclude gods from having effects on the world, or you could play something more Greek where they are causing all kinds of trouble. Of course there are many other models, and I'd like to put in whatever we find time for.
Dwarf Fortress has been referred to as part of the "roguelike" family of games, probably because it has what appears to be ASCII graphics and has a lot of randomly generated content (plus Adventure Mode is certainly a canonical roguelike). You mentioned that you had played Hack somewhat before designing DF, what other experiences have you had with roguelikes and how do you feel about DF being designated as one? (Thomas Moyles)
The early ones we played were Epyx Rogue, Hack 1.03 and Larn, then Moria, and Ragnarok after that. I don't think I played any of the *bands, ADOM or Crawl until our own fantasy games were well underway, so they weren't as influential, but I played all of them at one point or another. The first three were the only ones we played when we were really in our formative years, and along with the games I mentioned before and the arcade games that were at the Goldmine and Scandia in the '80s, they were our primary video game influences. Later on, there were other roguelikes that I messed around with. I remember Omega... maybe Diablo counts too, though that might lead to arguments. I don't play roguelikes at all anymore, pretty much, but it's hard to make time for games in general these days.
As far as DF goes, I think it's a stretch to call it a roguelike. Rogue was a very simple game, so it leads to a very broad category, but the city building, caravans, sieges and most everything else from DF would render the term roguelike meaningless if the umbrella were made that large. Just being text, fantasy and randomly generated isn't enough -- I remember playing an old text game kind of like Master of Magic that nobody would call roguelike even though it has these elements. There's something spatial about @ signs moving around that evokes "roguelike" perhaps -- it's not the properties I often hear mentioned that really count. It's probably fair to call the adventure mode roguelike if you want to convey what it's like right now. As armies and some other aspects of the game come in which start to pull adventure mode toward dwarf mode, I'm not sure the label will work as well, though there will still be some aspect of @-moving permdeath ASCII hack-and-slash in random dungeons that fits the bill.
With two major modes (dwarf and adventure) that are very different from each other and the possibility of additional modes, are you worried about people not knowing what Dwarf Fortress "is" or getting overwhelmed by the multiple options? (Thomas Moyles)
I don't think it's a problem if you think of Dwarf Fortress as an aspiring fantasy world simulator, but since the dwarf mode is so dominant right now, it's not even necessary to keep that perspective as a player. Most people probably think of the game now in terms of the title, as a dwarven fortress simulator, with adventure mode as an occasional diversion. As the game grows and allows other methods of play, and you can even have two different users that almost never play in each other's preferred modes, I hope that they can still share some common experience through the underlying features that unify all the modes, since the community that has grown up around the game is important to a lot of the players and to us as developers. I don't anticipate a huge problem with this, though there will probably be some people that can't really talk to each other and some tensions as to which way development should go when the current development direction neglects one mode or another. The game can be overwhelming in general, but most of the issues we're having with that are correctable (like the interface and documentation). A lot of people just start with the dwarf mode, since it's what they expect to be playing (from the title if anything), and they don't even move on to adventure mode. I'd definitely consider alternatives to just dropping a laundry list of modes from the title screen as that list grows longer, and if some people have trouble with the lack of direction that having a lot of options can cause, this would also be correctable through some simple settings that provide more structure.
It seems like the development of Dwarf Fortress is extremely organized, with plenty of design documents and the like to lay out future development on the project. How helpful would you say it's been to have most things laid out in advance prior to actually sitting down and coding? (Thomas Moyles)
I think for a large project, where you can't keep every detail in your head, it's important to know what you are planning to do, so that your code can absorb everything that will eventually be fit into it without having to constantly rework things. The plans we've written up let us more easily choose the order in which features are added so that they can be coded more quickly with fewer things stepping on each other. Still, I can't say I've always been the best at careful preparations -- I've mostly been winging it for the past 20 years, and I picked up a lot of small habits that help to keep the game resilient even when it's not clear what's coming next, but there are still fairly major rewrites occasionally.
In part the development documents arose because it's fun to sit down and plan out features for the game, and once we plan something out, we want to be able to remember it, so we write it down. At that point we share the plans, so that when people are wondering about where the game is going or they'd like to make a suggestion, they have something to look at.
As a related question, how long did it take you to develop the list of development priorities that you have on the website? Was that all done before you began coding the game, or is it constantly evolving?
There was a large skeletal plan in place, with some fleshed out portions, mainly through the Armok I planning that came before DF was started, and that has been in the works for many years. We still work things out as the game progresses, and our priorities change quite often, so parts of the game without detailed plans or features weren't going to be as deep might suddenly receive a lot of attention, while other parts with detailed plans might not be implemented for a long time. The actual posted list of DF plans in terms of Core/Reqs/Bloats is only a few years old and has been growing out of the planning notes that have been changing with the game and absorbing Armok I ideas as I described earlier. The game was certainly not planned out completely in advance, and I can't really imagine that lasting if it were, since we'd always want to change something as the game came into being.
Is there any thought to supplying an API for events in the system so 3rd parties could graft on a graphics system (similar to what's been done for nethack)? While I have tremendous respect for the incredible ASCII work, I miss the ability to have things like click-n-drag and context sensitive menus. (Chris Kessel)
I have no idea how that works. I'm not really knowledgeable about programming and computers and all of those acronyms. I had to look up API on Wikipedia. In any case, it sounds like a large project--not necessarily the sort of thing that would happen any time soon. Thinking about these things might be easier once some of the 2D graphics and mouse work has been handled. At that point if somebody explains to me what they'd like to be able to do, I might be able to support it more easily.
Tarn, now that Kobold Quest has been ported by some of your forum contributors to use SDL/OpenGL instead of DirectX, when can we expect a Mac OS X port and/or a Linux port?
On a related question: how much money would I have to raise in contributions to convince you to make a Mac OS X port a priority? Please note that this is not a rhetorical question, or a joke. (peterb)
The KQ forum thread is ongoing. As of Jan 9, I'm wondering what sort of system would be the most cost efficient to build the SDL port on, given the various people requesting ports for various operating systems. I'm willing to try out the KQ ports myself immediately once that's sorted out and I can get a hold of something to test it on.
I'm not going to set my priorities based on contributions, so you don't have to raise anything. People have worked to get the KQ ports done, and I've said from the beginning that I'd like to give everybody that wants to a chance to play the game. I have a lot on my plate, so things don't move very rapidly sometimes. As far as the donations themselves go, the ports might pay for themselves over time if I end up having to spend money on a computer, but I have no way of knowing that, and I'm not going to worry about it. Specific feedback regarding systems is appreciated on the Kobold Quest port thread.
<< Home