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!