General information:

Why blobs?
Blobs are easier to draw and animate than humans, because people have fewer expectations about “normal” movement.
Why threads?
I wasn’t using threads at first, and then I tried them. I found that the multithreading makes the game much more responsive. Input events can occur while the simulation is running; the window can be painted while other things are going on. Once you take care of synchronization, threads are easier to program than non-threaded code, because you don’t have to handle extra “housekeeping” for saving and restoring your current operation when something more urgent (like a mouse click) occurs. I have another page describing the threads I use in SimBlob.
Why OS/2?
I’m writing this for myself first, and for others second. I have programmed for DOS, Mac, Win 3.1, Windows 95, Windows NT, OS/2, and various flavors of Unix. I enjoy OS/2 programming the most, so that’s where I prefer to develop SimBlob.

I suspect that if I had a chance to write programs for BeOS, I’d like that much more than OS/2 GUI programming. I also wanted to write a Linux(Gtk) version but did not have time.

Why the boring overhead view?
I am more interested in the simulation than the graphics, and I didn’t want to spend my time writing an isometric view. It’s something I could add later; I have kept the “view” code separate from the “simulation” code so that multiple views or different kinds of views can be added later.
Will there be network play?
I’d like to have network play, but I don’t have any current plans to add it. I don’t know how to solve many of the latency problems with Internet play, and I don’t have much of an interest in IPX or modem play.
Will the game require DIVE?
I have developed routines that will allow the use of DIVE, non-DIVE, or a combination. At the moment, they are controlled through the use of command line parameters. Someday I hope to have a dialog box up. These routines also allow me to add support for graphics libraries (such as DirectX) on other platforms.
Where did you get the bitmaps?
I drew a few of the bitmaps myself (small blobs, trees, and fires).
  • The gates and canals were hand-drawn hexagons, with textures placed on top.
  • I wrote a program to generate roads and walls; I found spline formulas and used them to make the roads curve. There are 64 road bitmaps and 64 wall bitmaps; they are indexed by a bitvector representing which hexagonal neighbors have roads (or walls). The road bitmaps have a stripe down the middle; the wall bitmaps are textured using the same texture as the gates.
  • The terrain bitmaps are generated semi-randomly. The colors are chosen from a list of colors associated with the altitude of the land. From the five closest colors, the frequency of color use is determined by using Gaussian distributions. Once the frequencies of color occurrances are determined, a random function is set up that uses those frequencies. Pixel colors are chosen according to the random function.
  • The water bitmaps are also generated randomly; the colors are based on a random offset from a color based on the depth of the water.
  • I wrote a very simple sphere renderer to generate the houses. The empty houses are small gray spheres, and the occupied houses are larger colored spheres.
  • A single farm bitmap was originally hand-drawn, and then I wrote a program to generate it, with different shadings representing various stages (planting, harvesting, etc.).
  • The farms are generated by filling a polygon with colors. Diagonal lines are added for a more textured look.
  • The three-D effect of the walls and farms is added by looking at the bitmap two pixels at a time. If the left pixel is blank and the right pixel is not, the right pixel is made brighter. If the right pixel is blank and the left pixel is not, the left pixel is made darker.
  • The bitmaps that are generated by programs are anti-aliased; they are all generated at 3 times the normal width and height, and then shrunk down. By doing this, I can determine which pixels should be partial: when rendered, they are mixed with the pixel already on the screen. This blending produces nice smooth graphics -- jaggies are reduced significantly.
Will the game be sold commercially?
For some time, I thought that perhaps I could turn this into a commercial game. However, as time went on I realized that I was doing this for myself and not for money, and I decided to release the source code after I was done working on it. I have put a generous license on the source, allowing someone to use the SimBlob code to make a commercial game.
What about using OpenGL to have 3-D rendered graphics?
When I play some of my favorite games, like SimCity (classic), Civilization, or Railroad Tycoon, I see that the game designer concentrated on the essence of the game and not the graphics or object technology. In fact, the graphics aren’t that good on any of those games. The graphics didn’t make the game. They just sell it! I am far more interested in making a game that I would want to play for many years than in making a game that will sell well but not last long.
What about OpenDoc or WPS object technology?
This might be nice, but I don’t think it would enhance the game significantly. If you have some ideas of ways that these object technologies could add to the game, please let me know.

Information about the simulation:

How do you work with hexagons?
I have a hex coordinate struct which contains coordinates for hexes. I use an offset rectangular grid for hex coordinates, which is simpler to work with but not mathematically / aesthetically pleasing.
How do you generate a map?
I start out with a fractal landscape, and then I use erosion, add random hills and depression, use more erosion, rescale, simulate volcanic eruptions (to smooth out valleys), simulate a global flood (to create erosion channels), find good places for rivers, dig channels for the rivers, smooth out the map a little, and place forests on the areas that had volcanic activity.
How do you handle movement of the blobs?
I am currently using the A* algorithm to find “good” paths for the blobs. In addition to this, if an obstacle is found, a path is computed to get around the obstacle; if this path is too long, a new path to the final destination is calculated. This seems to work well for destinations that are not impossible to reach.
How do you handle the water flow?
Each hexagon has a variable storing the amount of water there. If the water plus the altitude of one hex is higher than the water plus altitude of a neighboring hex, water flows from one to the other. See an email message I wrote for more details.
How do you make erosion?
I have two kinds of erosion. Soil erosion just smooths out the bumps on the map. Water erosion occurs when water flows from one hex to the next; the water pulls silt along with it, and deposits it downstream.
How do you simulate jobs?
I’m using a simplification of network flow algorithms. These algorithms allow you to specify “sources” and “sinks”, and then simulate the flow of some substance from the sources to the sinks. I use “people” as the source, and “jobs” as the sinks, and I simulate the flow of people to work. Along the way, I can find out how much traffic is at each point on the map. The algorithms also tell me how many people are getting to each place of work, and how many people at each house find a job. The algorithm is incremental, so changes to the map don’t immediately result in new flow information, but rather get propagated through the map as time goes on. This is perfect for a game, since exact information is not needed immediately; it can take a little bit of time to get it.