Disco is back!

Filler - Splat

Yup, still totally stuck!

In an attempt to get a few things done I will try to regroup, focus on a few things, simplify and cut corners everywhere and reuse existing code and features from whatever resources I can find.

Terrain is very dependent on texturing, not just because of how it will end up looking, but because the kind of terrain you have determines what you can do with texturing, thus forming a vicious circle.

And the tile based texture atlas terrain does not mix well with what I want to do with the terrain. Plus is it ugly.

To make up for lost time and to make implementing terrain easier I am going with a much more streamlined vertex structure: as easy as it gets, with the minimum possible vertices and an index list. This in contrast to the more complex terrain I had implemented. Stretching a single texture (or multiple large ones) over such a simple mesh will end up looking bad any time you view it from even normal distances. Only when viewing it from far will it look not blurry.

So I learned texture splatting:

The idea is to take the stretched out blurry texture and splat on top of it a few other highly tiled textures. This is done on the fly by a pixel shader. The only input this shader takes is a special bitmap that gives information about where and how much to splat and the textures that are going to be blended together. In the above video both the heightmap and the splatter-alpha map are only 256x256, while the textured that are used for detail are higher resolution.

In theory this is a simple process and I have fully understood the shader. In practice things are far from smooth. Irrlicht has a 4 texture limit. I think you can get it to support 8 somehow, probably by recompiling. So one texture is the alpha map, and 3 textures used for detail. There is no room for the master stretched out terrain texture, so the above video uses only the detail textures without a master texture. Great, more obstacles!

Also, because I am using a custom shader, built in lighting does not work, so I'll have to merge my terrain splatting shader with my lighting shader.

In the spirit of code reuse, I have used the built in terrain class from Irrlicht, rather than simply my vertex setup model and implement terrain LOD switching. While not really visible in the video, the terrain switches dynamically in complexity based on distance. And it is a good thing that you can't notice that it does this. A slight modification was done to the terrain behavior from that class in order to not apply the default detail mapping but use a shader.

I'll use that class as a learning tool, maybe even adopt parts of it into my code.

Screens of the day 24 - One light to rule them all

I must confess I am kind of stuck on the caves. There are at least half a dozen ways to do it and none of them is without any disadvantages or easy to implement. Caves are the hardest task I have encountered up to this moment. Path-finding is hard, but I am not at the stage where it becomes tricky because I still limit it to 2D. Lighting is hard, but this comes down mostly to my inexperience with it. The real technical challenge is coding around the hardware limits on the number of lights. This will probably be the biggest issue that I will ever encounter, but for now that spot is resolved for caves.

I also read a lot about the marching cubes/tetrahedrons method. It is a very interesting method that mostly comes up in research projects and looking extremely promising yet meanwhile abandoned projects. It is also almost always either poorly documented or using a far too scientific language. Let's face it: with the wealth of information out there, if you are having serious and lasting problems with midpoint-displacement or Perlin noise terrain, then one probable cause could be that you are not cut out for programming (or are just a beginner). But not so for marching cubes. While the basics are fairly simple, solving the very common ambiguity problem and making seamless LOD switching is hard as ******** *** ******* ****.

So while I am not done yet with caves, terrain has been improved. Selection works again, there is a single cell focus "cursor" and mouse movement now tracks the top of the surface, whatever that is, making it a lot easier to navigate and select stuff.

Until I manage to do something meaningful with the caves, I need to write about something, so it's filler time again. This time: shaders!

I get the impression that Irrlicht's support for shaders is not the best in the world. Here are some observations:

• Still can't get global variables to take on the value they are initialized with. I have to set these values manually from C++ code. Not a big issue, but I see code out there that does not need to do this. Today we live in pretty XNA dominated era: the C# game centered library for Windows and Xbox.  From what I saw, I really like XNA. It is like DirectX on crack (the positive interpretation of that statement; not the addicted to drugs one)! You can find a ton of XNA resources out there and a lot of what I have learned about shaders comes from there.
• There is no support for the "technique" section in the shader sources. This is quite problematic because you can't just use a shader file to create post processing effects, deferred rendering and other composition techniques.
• You set shader variables (actually they are called constants) on a shader type basis, that is you need tot specify the name and know if the variable is a vertex shader or a pixel shader one. Setting a pixel shader variable as a vertex shader one (and vice-versa) generates an error and wrong rendering. But what if the variable is shared between the two shaders? Experimentally I found that I need to set them both for it to render correctly. Again, there is little to no indication found in Internet samples about having to do this.

These caveats not withstanding, I managed to get per-pixel Blinn-Phong lighting working, but only with one light:

Above you can see a sample. Bottom left is a shaded table. Bottom right a shaded table with transparency. flying higher you have a non-shaded non-lit model. You can't see it here very well, so let's take a look at the same scene from another view-point:

It is not really fair to compare a non-shaded non-lit model to a shaded one, but you saw how these models look with fixed pipeline lighting in the past, either using a two or tree lights setup. BrewStew suggested to make the table more bright for outside lighting conditions, and this is as bright as it gets:

Now this is per pixel lighting, meaning that every single visible pixel should be effected by lighting. In the future front-to-back ordering for rendering should be implemented to speed up the rendering. Light can be directional, point or spotlight shaped, and have ambient, diffuse, specular and emissive components (emissive is ignored for now because I don't need it and no use slowing down rendering even more). Materials also have diffuse, specular and ambient reaction values, together with a global ambient color. So the lighting model should be compatible with both the fixed pipeline lighting system of the GPU and things you can get in a 3D modeling program. I tested the values a lot. Global ambient is a little bit weird and so is specular. Specular not only creates those very shinny highlights that everybody want from specularity, but also globally shades the object based on the direction of lighting. This means that you can't put shininess to zero if you want no highlights, but instead need to set also the specular parameter of the material zero too or risk having the object rendered incorrectly. Playing around with the parameters I managed to get this very ugly and hard pseudo-self-shadowing to render:

Very ugly, but it is free, as in it does not take more time to render like this.

The problem is that this is an one light setup. Having object textured helps reduce the problems with such a setup and some shapes are better suited than others. But take a look at this untextured column to see the problems with a one light setup:

The side that faces the light has shading, but the shadowy areas are completely "flat".

I played a lot around with the parameters and got a lot of results, like this one:

Except for the one light limit there is one more problem: vertex colors are too washed out. Let's try and use a pure red vertex coloring and see how it looks:

The unshaded object is very open about its coloring, blasting away with its very explicit red coloring. The shaded object only takes a hint about its reddishness, becoming slightly pink. You can improve this with lowering the ambient material parameters:

The problem is that this makes the unlit areas of the object too dark:

A solution is to modify the color of the light and make it red:

Now you can play around with brightness:

This approach has one serious disadvantage: performance! This engine has been about one think from day one, and one thing only: huge amount of objects in scene with smooth performance. My engine does not care about coloring: it is free. You can have all objects in the scene have a single color or all a random color (from a limited pool of available colors). Even if you distribute colors with the worst possible mathematical probability to maximize color change, the engine doesn't care. Now, if I were to shine a different light on each object to color it using pixel shader the rendering performance would become dependent on the color distribution. Having just a few colors with large chunks colored the same would have a minor impact. Using the above mentioned worse case distribution would reduce performance. And I am not talking about 2-3 times lower performance. More like 30-100 times lower framerate. And this if we consider that rendering per-pixel lighting is free. Just having a large number of colors with worst case distribution and zero cost shaders would drop the performance a lot.

So instead I'll try to implement a dual light shader and see if we can get vertex colors to shine though like that. Let's see how that works out first.

But still, I managed to get some interesting results. Here is a metal shader I created:

And seen from above:

So... yeah... filler...

81 – Dig(gity)

I had this post so long on mind that I forgot half what I was going to say, so abridged version recapping the week:

I started working on caves and managed to implement a very powerful but very complicated solution. Any convex surface without an underside could be used to create caves underneath if it was high enough. Increase the complexity a little and I'm sure I would have wound up with full boolean mesh operations. Early on I realized that this is far too complicated for what I need but I still finished the implementation, tested it, saw that it was great and immediately deleted it.

I think that a simpler design and terrain overall would benefit my game. I scaled back a lot on the complexity until I reached a fair compromise between ease of creation and what can be done with terrain. The time spent creating the complex solution means that Snapshot 9 will be a little bit behind feature wise: no level switching, no slicing and no caves.

The first good reason to have relatively simple terrain is that terrain is often just eye-candy. You take a look at it, go "WOOOOOOOOOW" and then you spend 99.99% of your time staring either at a horizontal section though the landscape or and underground level.

The second good reason is that complicated terrain requires complicated tools. I could create a full on set of terrain editing tools for the GUI, but this is not really the scope for the game.

Instead my focus was to create an accesible terrain that looks good and is very natural, both initially and after you interact with it. In my last video I have shown and early digging prototype and that had very straight edges around the part that was removed. I don't like that because it brings back memories of the cubes. MUST... AVOID... PUBES... JOKE... I want softer surfaces and I'll show what I came up with at the end of this post, but first something has to be done about the way the landscape looks.

While there is plenty of detail in the map, because of the flat shading you can barely tell what is going on. Using Irrlicht's built in normal calculator I tried to add definition to the landscape. The result did not turn out too great. I obviously needed something more powerful, a solution implemented by me, but by using this first I learned a ton about normals, Irrlicht implementation for them, how Blender exports them and why using flat shading requires more vertices that smooth shading. Here is the result of the Irrlicht solution:

This solution, while far from perfect gave the required detail to the landscape. It also highlighted some problems with terrain creation. When I learned midpoint displacement I remember reading about rectangular artifacts that get carried up and create undesired pyramidal structures. I knew about this bug but for a cube world it was never a problem.

So the next step was to write a powerful terrain generator class to handle all these tasks, using the same algorithm as the above one, but replacing square midpoint-displacement with diamond-square midpoint displacement. And since I needed normal calculations, I made the class provide these too. The class not only works for discrete values, i.e. each point in the heigh-map, but can provide the correct values for height and normals for any floating point coordinate using interpolation. Currently the class only supports discrete and interpolated height and normal operations, but on a need by need basis I'll add support for other useful values for a 3D engine, like tangents, binormals, bitangents and bisexuals.

The next step was to improve lighting. Correct normals and bad lighting does not a pretty map make. I learned a ton about lighting in general. How did I do that? By trying to learn shaders. This is how you learn shaders: you start of with a "neutral" shader, one that simply converts from logical 3D coordinates to coordinates the GPU can use using the world-view-projection matrix and fill the areas with a single hard coded color. This is the most basic shader that you really need to fully understand. Then you start expanding upon it, adding ambient color, texture, directional lighting, specular highlights, normal mapping, etc. I am not ready yet to write my shader lessons, but I'll get there. First I need to solve a problem: out there on the Internet people often write shaders that have global variables initialized with some value. Pretty straightforward. Yet when I use those shaders, the initial value is never assigned and is instead zero, resulting in incorrect rendering. I need to figure out first why these values work for other people and not for me.

Using my new knowledge I created a new lighting model that only uses two lights. This might solve the problems with Irrlicht's default PS 1 shaders that only support two lights for some effects. The new model is far from perfect, and I am still iterating upon it, but this was a good result:

I further tweaked terrain generation, digging softness and lighting.

Terrain generation is done. As in the shape of it. I will not improve upon it more. Not all randoms maps are equally good, but I haven't found a single bad one yet. The difference between them comes down to subjectivity. I like hilly/rocky landscapes, but some might enjoy smoother ones. The random terrain generator creates both.

Lighting for terrain is also done, at least until I switch from fixed pipeline lighting to a terrain shader.

The only thing left is texturing. A new texturing scheme will come creating more realistic and modern looking landscapes, but not now.

The terrain generator has a resolution. It creates an amount of discrete points in concordance with that resolution. Increasing the resolution does not simply create a good looking terrain with twice the size and useful data. It creates a terrain with twice the size but half the detail. Every time I change resolution a new set of parameters for the terrain generator must be manually and experimentally determined. It is similar to a picture. Scaling it up won't give you any more detail. You may use some filtering, but eventually you'll need a higher resolution image. So I am going with a fixed resolution terrain.

So I implemented strectching. The terrain data can now be used to create terrain at any scale. Currently the unit borders are aligned with the heightmap to create the best looking map. I have not yet investigated how this looks if they are not aligned.

The terrain is also seedable, as in there are a few values that when reused always create the same terrain. Useful, this way I can always play around with my favorite maps.

Putting it all together we get this:

There are some coloring bugs that I have intentionally left in for terrain. While examining the physics and terrain model you can easily prove that these values are wrong, but I actually like it this way because it gives the terrain a little bit of personality and outlandishness. The texture stretching bugs are not intentional and will get fixed!

Overall this was a great first week for March's experiment-a-thon. A smashing success even. There is absolutely no way I am going back to cubes! Or a 2D engine!

Now just let's hope that I can hack together a Snapshot 9 out of all this stuff!

80 – Bumpy ride

I uploaded Snapshot 8. This time it is a real snapshot. The point of the snapshot systems was to get version out there. Release early, release often. But taking 1-3 days before a release to polish up a weekly snapshot kind of defeats the purpose of it all. So I took the best version I had at the moment, did 30 minutes of testing and labeled it Snapshot 8. I'm hoping I will do this for all future snapshots. Once in a while a super stable version will be releases. Then it is OK to super polish it.

With the freed up time I gained from not extensively polishing the last snapshot I added tree cutting, plant harvesting, food stockpiles and sacks. And maybe a few questionable interface choices :).

The rest of the time I worked on the new model for the world. The short blocks were cute, but I realized I want more than that. In the end I did not go with either the voxel/DF model or the multi-heightmap model. I am using something in between.

The world can now have any shape. You still interact with it using a grid based system, so a few mechanics might turn out to be a little bit awkward, at first at least. I am also constraining the world to have a fairly large flat-ish surface where you can act. This is level zero. Level zero is special because it is tightly linked to the above levels. These levels can not be represented in isolation. Level 0 and the above landscape constitutes the "overlevel". This is the first type of level. The second type of level are the underground levels. These can be represented in isolation, and you can just place two on top of each other and they will look good. 

Free-form shape worlds also mean ramps. Ramps are a huge pain in the butt and I hated implementing them from day one. How do you solve this? By making everything a ramp!

Since the world is free-form, I ended up with a system that takes the height of the land in a small rectangular area, interprets it and makes some judgement. We wind up with the following classes of mini height-maps:

• 0: here elevation is very mild. You can freely walk on top of it and you can place items on it.
• 1: you can still walk on it, but elevation is unregulated enough that you can't place items. There are not many such cases, this is mostly a transition block so you'll often ignore them, and if you really need to place an item there you'll flatten it first.
• 2: here elevation change is so abrupt that normally you won't be walking up or down there. This seems a little bit strange because clearly a dwarf could walk on that zone. But dwarves are all about changing the environment and traversal optimization. They don't want to climb even a medium incline with a backpack and while caring stuff, so they would rather flatten it first. But the area is not high enough to allow you dig a cave in it. This is another transition tile and the most awkward of them all. This is somewhat compensated by the fact that you'll only need to dig out a few such tiles before you get to the good stuff:
• 3: very high blocks! Here you can dig caves. You can have an elevation level at great height and under that a lower elevation level defining the cave

This is like in real life, if you would dig a cave though a hill. You start of on a relatively straight piece of land. The first few meters you did the highest point you had to remove dirt from is probably a lot shorter than you. As you continue, the dirt levels around you rise and rise, until you can't dig from the highest point to level zero, but instead start digging caves. In real life everything would cave in upon you! But this is dwarf world! Get me Keanu Reeves!

I implemented all this except for the last part, cave digging:

Surprisingly almost nothing got broken by this change. Quite a few systems needed minor adjustments. Items are no longer placed on high elevation tiles. I could place them inclined, but this is very dangerous. At the slightest provocation I'll start implementing physics and then I'll never finish the game! The problem is that this way hills look to barren. Some plants will still be placed there in the future and I probably need to add clutter/detail objects here and there. Trees needed to be adjusted to be placed at correct height and so did dwarves for walking purposes.

And don't get me started on how bland the elevation looks! I still have no clue how I could possibly shade that. Oh lighting, you so whack!

I found plenty of advanced solutions for terrain. I need something simple in the first stages. So please don't link me to that awesome pixel shader 3 terrain implementation that does height maps with GPU and what not. I need "baby's first terrain" shading solution. And things like "take the normal, multiply it with the direction of the sun and recite a poem" won't help yet, because I am not generating normals for the terrain. So much to learn!!!

But otherwise pretty good. It took me a few hours to implement this.

Next step is to make caves work again. And get Snapshot 9 ready with this new terrain, while hopefully not losing or diminishing a single feature.

79 – So natural

I managed to crate a good release candidate so Snapshot 8 will be uploaded later today. It is still buggy as hell and I might be able to iron out a few bugs here and there, but most of the bugs are not something you discover in 5 minutes. You really need to be looking for them.

Other than the general fine tuning and performance adjustments (I am comfortable again having vertical sync on; when your map is super busy it is still not 100% smooth to scroll, but getting there) this is the first version that theoretically supports multi-threading. I say theoretically because I don't like the feel of multi-threading in the game. Something is off when I use it. Can't really describe what, just a feeling. And it crashes. A short google search lead me to believe that Irrlicht is not thread safe, so that is probably the cause for it. So Snapshot 8 will still use a single thread, but if I can fix the crashes until 9 then we'll get a first MT release. I am also starting to suspect that Irrlicht is partially responsible for the monstrous difficulty of creating an engine that supports so many items. And my total n00bishness with creating 3D engines that prevented me from realizing this fact. I am not 100% sure yet, going by what I found on google with other people having problems, but if this turns out to be true I am going to be extraordinarily angry. It took me about 3 months to get item population working and I am just about to add another extreme optimization because I am starting to hit a wall again.

This is the last snapshot for February. Like I said, I am at a big crossroads with the design of the game and I am going to dedicate March to testing and evaluating multiple paths before I choose which one to pursue.

The first model is the Dwarf Fortress model. This has nothing to do with the content of the game, it is just the world structure model. What do I mean by this? Let's take a simple example: Minecraft. Minceraft uses a model where the entire world (except for falling water and lava) is made out of cubes. There are a few things that are not cubes, but they still live under the constrains of the cube.  Minecraft also uses the voxel model, which means that cube/non cube boundaries are efficiently represented, there are no constrains on cube diversity and at any given position in a potentially "infinite" world a cube can be placed. Well, if a full voxel model is used. Minecraft may or may not have aditional rules and deviations from this model, this is not important here.

The Dwarf Fortress model can again be considered a voxel. You have a 3D matrix of walls, floor and objects to explore and interact with. There are not limits on what you can place where, but you are constrained at interacting with a single level at a time.

And this is very awkward, especially in 3D. Think about the situation where you are interacting with some items on level 51. You are standing on the walls that are on level 50. But in a few positions in level 50 there are no walls. There is an empty space. You would like to put something in that empty space. You can see that that space is empty from level 51, but before you can interact with it you need to switch to level 50. This system is clunky. No mater how good I make the interface, a new player will need a lot of explanation, a fair amount of practice to get the feel of it and even then is going to need a lot of time to get used to it and don't be bothered by the system. In 3D and first person mode things are even worse. You are sitting exactly at the edge of the empty space from level 50 and the position right next to it on level 51 where your character is. You can very easily see the empty space and realize what it is. But you mouse is helplessly stuck in the plane of level 51. You need to change levels. But what happens if you change levels without moving first/jumping down into the empty space. You new position after the level change would put you right in the middle of the wall, so the engine will have to compensate for this and put you somewhere else. And again the system will confuse you, because there is big chance that you'll need a second or two to realize where you are. And after you change back to 51 you probably won't be in the place you started from.

So the system is clunky. It has its good sides too, like how it allows for deep gameplay and world interaction. Every single alternative model I though up reduces this depth. So the real challenge is to either create and alternative model that maintains the depth or one that reduces the depth in an unperceivable manner.

So as a first try for March I won't be using a voxel model, but a multiple (for starters 1) height-map model. A height map defines the surface of an object, in our case we'll have the surface of the world, the surface of an underground cave, the surface of a stream, etc. I'll start with on height-map and see how it goes and more importantly, how it feels. The multiple-height map model is very similar to the voxel one, with the main difference that two height maps can't touch or intersect. Theoretically they can, but implementing that is hard and not fitted for a first taste of the new model. There is also a difference in perception. Because of the way each model works, in Dwarf Fortress you have a tendency to expand horizontally. In a height-map model you have a tendency to expand vertically. You may win up with the exact same map, just how you got there may be different.

My third model is one specially designed for the mages. PEW PEW! UNLIMITED POWAAAAAAAAAAAAAAAAAAAAA!

The key in getting these models out there is to not reinvent the wheel. I need to implement them without changing the engine in non-minor ways, so the models can coexist. If I add tree cutting (the next thing on the agenda) to one, it should instantly work in all models.

I added some support to model switching to the engine. By changing only two lines of code and recompiling, we go from our standard model that I've demonstrated in the past to a more natural model illustrated in this video:

As you can see, there is no manual level switching. You just walk around like you would do in a first person shooter, with your cursor detecting the surface it is on and allowing you to interact. If a cave entrance was placed somewhere, you would just walk inside. Pretty natural, am I right? Ignore the jerky walking-up ledges animation and how with smoother elevation the borders don't seem to be contributing visually anymore to the scene. In top down view you would prably still use manual level switching, but only to control the postion of the cut-off plane. Without a cut-off plane (the world slice) you often wouldn't be able to see what is going on. But still, if your dwarf is on level 51 and you want him to interact with the item on level 50 that is visible, you would place the cursor over the item, the engine would figure out that there is a difference of level and position the cursor appropriately in 3D space and if a path between your dwarf and the item exists the dwarf would be able to interact with it, without a single level switch operation.

This is just an early prototype, but please tell me what you think!

78 – What What (In the stockpile)

You may have noticed in my last video that when dwarves dig though stone there are no usable boulders left on the floor like in the past. I'm not sure about boulders, but some stone, probably bricks should be left as a byproduct.

Next on the list is reimplementing tree cutting, so I also need multiple logs pilled up somewhere. So logs + bricks equals stockpiles.

Logs are boring so I start with bricks. But I don't have pictures, so I"ll show you a video first and then describe what you saw.

The first things I demonstrate is brick stockpiles. They can be manipulated directly in creation mode. Simply adding a brick somewhere changes that to a brick stockpile. Removing all the bricks destroys the stockpile. 

I was just going to add support for multiple brick types stockpiles, but then I realized that makes no sense. What if you need 3 native copper bricks, but they are under 300 bricks you don't care about. What is a dwarf supposed to do? Sort though 300 bricks? How? Using a temporary stockpile? What is this? The Towers of Hanoi problem? How is a dwarf even supposed to remember where the bricks are if they are not visible? So no multi-material stockpiles! Maybe for food. But not for bricks and logs.

So why are there so few maximum bricks in that stockpile. Why only 47? The short answer is that I want bricks to be put down in a logical and aesthetically pleasing manner, so all positions must be created individually and I go bored after 47 bricks. The long answer is than in the future I will have to optimize this, making sure that hidden bricks take no resources. So no use working a lot now on positioning since I'll have to redo that when I'll optimize it. I may even give it the "voxel" treatment, making sure that optimal face rendering is used.

The individual positions at which bricks are placed form a pattern. Currently only one pattern exists, but the next step is to add patterns for everything that can be reasonably created from bricks: walls, houses, bridges, towers, balconies, castles, dungeons, etc.

The final goal is to create a city of Elder Scrolls complexity, one brick and log at a time.

The final result of a pattern probably won't look that good. I will have to take that result, take its general shape, remodel it traditionally and break it into pieces to create a new pattern.

And as always, lighting sucks on those bricks. If this where a AAA title you would have pre-calculated lighting and baked in ambient occlusion for each pattern. But you are stuck with me, so have some very shinny bricks! You are welcome!

The UI only allows to add or remove a single item at a time, but in the future this will be more flexible. I also textured the bricks, quite poorly.

Next in the video we have log stockpiles. I am using the high quality logs created by BrewStew which I textured myself, again quite poorly. The problem is that the logs are so distinctive that you immediately notice that there is one one log mesh. Maybe I have to go with a more simple cylindrical log to make it less apparent that there is a finite (1 right now) number of meshes. Maybe some random scaling and rotation in the future.

Optimizing logs is harder than bricks because they do not create patterns that fully cover underlying logs. So I might have to model each pattern separately so I can hide some extra faces. Anyway, I am not wasting time optimizing things right now. Add features today, optimize on a full moon during a lycan attack.

So in conclusion things are shaping up. Creation mode has most of the basic tools implemented. Normal mode is still lacking, but one of the next updates should add tree cutting now that log stockpiles work again. Adding food and harvesting back is trivial, but I am not clear on the design for the logistics: what do you do with the harvested plant? If you have no storage do you just leave it on the ground? Then I need to model harvested plants. Do I use the solution from the old 2D engine with magical sacks that appear out of nowhere? Do I create mixed solution where if you have no storage you leave it on the ground, if you have available sacks you use them? Or maybe I don't use sacks and instead use barrels?

Anyway, things are on feature freeze right now and Snapshot 8 will be uploaded on Monday. I will do my best, but expect to see a few bugs.

After Snapshot 8 I want to do a quick experiment. My plans and ambitions for this game are leading me in a different direction from the DF one. In March I will try to take the game in a slightly different direction. Have no fear, I'll be using the same engine and mechanics. Dwarves will do the same stuff and new actions that work both in the DF model and my model will be added as scheduled, so if the March experiment fails the game overall will have taken a few steps forward.

But the DF model can be quite confusing. You have a multi level map where you interact with it one level at a time. You need to change levels a lot. You don't see what is happening one level higher. And if you do, it can obstruct your view of the current level. Implementation wise the map eats a lot of RAM and there are extremely rigid data structure requirements to do path finding in such a map.

In March I'll try a model that is not level centric, but "view" centric. Your default view is to see the entire surface of the map. Elevation is smoother and dwarves walk all around the place. The surface of the view is deformable and a lot of actions change the shape of the map. Maps are larger. I'm thinking of eventually giving you a 3 square kilometer playground and see how that goes.

This will be just an experiment to see which perspective I like better. If the new model works out I have great plans for immigrants. I said before that the number of active dwarves will be a lot lower than in DF. Dwarves will be few and very valuable. One dying will be a huge disaster with profound implications on your productivity. If you have 200 dwarves, one dying is negligible. If you have 15 dwarves, one dying is more important. Maybe the one who died is the only one you had with a given skill, so now not only did your general productivity fall, you are no longer able to do a task you previously could. I am also thinking about making dwarves have only a limited number a skills they can perform. In DF all dwarves are novice at all skills. I'm thinking of giving them about 6 skills, with a starting dwarf being fairly skilled at 1-2 of them. They can't perform skills they are not trained for before they receive tutoring. And you will be able to buy skill books if a trainer is not available, but it will take weeks for a dwarf to learn a new skill from a book.

So what do you do with low number of dwarves but a big map? Immigrants! Wait, what? Did't I say that the number of dwarves will be low? Well there are going to be two kinds of immigrants: squad mates and civilians. Squad mates will be like your normal dwarves and under you command, while civilians will mind their own business, sometimes helping you with tasks, sometime just trying to survive, eating your food and blundering about during combat like Jar Jar in the final battle from Episode One.

So you'll have a large living city full of civilians that go by their daily routine and don't take direct commands and a small number a dwarves in your squad that you control. Civilians will be able to sometime perform tasks like hauling and digging, sometimes for free, sometimes with payment. Things your highly skilled dwarves are too good for. Because they are better than you!