DF/Tutorial/1

1. Laying Out the Game

Introduction

A lot of ink has been spilled talking about the proper way to design software. I have my own opinions, opinions which seemed to have served me well in the past.

I write software much like I write English. I start with a general idea. Then I draw out specific concepts from that idea. Then I flesh out those concepts as far as I can. Sometimes I jump from one concept to another. Eventually, I fill in the blanks and the project is in a "done" state, at least until I get more ideas.

The Idea

The "Big" Idea is to write a "better" Dwarf Fortress. I believe I can do a better job of making dwarves behave.

Some of the big differences I want to see is I want to have a much more complicated economy. In order to make this manageable, the dwarves are going to use a rudimentary "kanban" style process. This works by dwarves asking each other for the things they need to complete their job. For instance, if I tell the dwarves to make 10 steel breastplates, then the dwarves will set a goal to make 30 steel bars for those 10 breastplates and a forge. 30 steel bars requires 30 iron bars, 30 coke, 30 flux stone, and 30 pig iron bars, and 30 fuel and a regular smelter or a magma smelter. 30 iron bars requires 30 fuel and a regular smelter or a magma smelter, and 8 iron ore. 30 pig iron bars require 30 iron bars and so on and so forth. There will need to be some notion of priority, of course. Some stockpiles could be set up so that they have quotas rather than the way Dwarf Fortress simply allows or disallows products.

The above system greatly simplifies the management of making things, and it could free up the game so that many more items could be introduced.

I also had the idea of introducing new races to manage. Each of these races will derive happiness in different ways. For instance, orcs might like a good hearty brawl from time to time, and so seeing orcs fight and kill each other every once in a while is a sign of a healthy fortress. Dwarves might have a need to hoard precious jewelry and fancy clothing. The possibilities are varied.

Mining need not be so micro-managed. I foresee the possibility of telling miners to do exploratory mining in certain regions. They will first dig out some areas, and then poke around until they have mapped it all. You could also tell the dwarves you need 10 iron ore, for instance, and they will find the nearest vein, mine out the ore, and be done.

I don't like the way Dwarf Fortress implements liquids. I have the feeling he tried to get a physically accurate system going, but there are obvious problems with the algorithm. Perhaps I could improve upon it and make a better, more realistic system.

Anyways, it would take some time to get to the level of complexity that Dwarf Fortress has. I don't know that I could even replicate most of the features he has. It doesn't matter. It's not uncommon to start off on one road and end up in a completely different place. Who knows whether it will be a good or a bad place?

Groundwork

Any project requires a sort of framework that supports the game proper. In our case, we need:

• A graphical UI of some sort.
• A model for how things exist.
• A way to specify the "business rules".
• An event-based universe.
• A model for the AI.

Graphical UI

I have played with a variety of systems. In this case, I want to stick closely to the retro look and feel of Dwarf Fortress. There's a good reason to use a simple UI: It frees up a lot of resources, both in terms of developer time and computer time and memory.

I'm going to go with a one-step better than Dwarf Fortress system. A simple, 2D tile system will suffice. I won't even use isometric tiles: There are a lot of details you need to get right. Dwarves and objects will be overlays on the tiles. I may even go so far as to introduce simple animations for water or dwarves.

Typically, you have a toolbar much like Dwarf Fortress. I don't know what I'll do there. Perhaps a status bar on the bottom, a dialogue bar to the right, a title bar with the game name, global status and "score".

Pyglet provides pretty much everything I need.

I experimented with a variety of systems. I think I am going to settle on an OpenGL orthographic projection with the camera looking straight down. I played with a blitting method, but smoothscaling for zooming in and out took way too long, and everyone has advanced GPUs nowadays anyway.

The bars will be simply overlaid to the side, above, and below the map.

Model

I always start my designs with the model. The reason why is because a good model will cause everything else to flow naturally.

The Map is a global object. It has many Layers. Each Layer has a TerrainTile. The TerrainTile describes what material it is made of (dirt, rock, etc...) as well as whether it has been dug out or smoothed. I'll need to decide on an exact size for the tiles. I think 1m squares are appropriate.

Items may be set on the ground, carried by a Dwarf, or installed in a tile or group of tiles. This will allow large items, which could be interesting.

Dwarves are MOBs, to use a term from the old MUD days. They can carry things, wear things, and have a position. If they are dead, they turn into a corpse item. They have a health status.

Business Rules

After we have a model, we can describe how the model interacts with itself. These are the "business rules" of sorts.

Note that many business rules have delayed actions or results, which leads us to the next design activity.

Event-based Universe

Throwing Einstein's Special Theory of Relativity out the window, there is a global clock. Each tick represents a certain, very small, unit of time, probably 1-10 seconds of game time.

The event queue has a sorted list of things that will happen at set times.

The event queue doesn't go very far in the future. It only contains things that are delayed actions.

Some things happen at regular intervals, regardless of the game state. For instance, the time of day will change from morning to mid-day to evening to night. The various levels of light may be reflected in the graphical display and may affect creature's behavior.

AI

I have never programmed an AI successfully. My imagination is that each MOB will have an action, a sort of "This is the goal I am working on right now". This is actually a stack. For instance, "Go to x,y,z and dig" is really "Go to x,y,z" followed by "dig".

Certain things may override, temporarily, their actions. For instance "run away from danger", "attack dangerous creature", "eat", "drink", "sleep", etc...

I have always imagined that you can build a system where each MOB has different information, and they can communicate one with another. For instance, if a dwarf is running away, and he runs past a militia dwarf, then the militia dwarf can ask the dwarf that is running away what he is running away from. If it is a creature that he thinks he can fight, he will gear up for battle and go fight. If he needs help, he will find his squad and attack together. Perhaps this is all too complicated. I don't know.

Wrapping Up The Design

With this, I write down my ideas so I don't forget them. Then I put together a plan of attack.

My general implementation process will be:

• Get a graphical UI working in its most primitive state.
• Get the map model and display it.
• Implement the first business rules and the event queue.
• Introduce one MOB and a rudimentary AI.
• Improve upon the above with incremental changes.

Next: Chapter 2