pre-alpha-3 – Day 1

Since I just posted post number 50, I am only a few post away from the next pre-alpha and today is August the 1st, I decided to get started on the pre-alpha a little-bit early. I will also add a few new features, but in pre-alpha posts I'll just refine existing features and in normal post I'll add new ones. There is also going to be extensive testing. This is the final pre-alpha before 0.1, so by the end of it everything needs to be perfect. Or at least as perfect as a huge ham.

These posts may not seem that interesting, since a lot of the content is going to be a slightly detailed change log.

One thing that may be more interesting is that I am redesigning the old API from the support library. DwarvesH consists off three projects: a library, the game and the editor. The library was designed to only be used by myself and not to be made visible. The new design dictates that the library should be written as to allow any client to use its features. I'll try and make it public in the future. With this library anyone (with talent, skill and a lot of time on their hands) could implement a lot of features that are present in my game and the two would be compatible. And third party tools would have the advantage of never falling behind the official game, since all that would be needed is a recompilation once a new version of the library comes out. So the library must be very well designed, but at the same time must never sacrifice performance, even if it has to sacrifice readability.

The above paragraph for people familiar with Dwarf Fortress and the tools from that community: you do not need to reverse engineer the map format or write a tool like DFHack. DwarvesH will provide these for you though an API. The plan is to make this API public and write very little documentation for it. But C++ is very readable so you'll have no problems there. I may change my mind if a good reason comes up not to make it public (legal, hackers, greed, etc.). No deadline for the public API.

Changelog:

• Map size is the same as advertised. If you are a programmer and are used to working with matrices, you may be familiar with the concept of bounding borders. The idea is to insert a dummy border with invalid data around you matrix, so you can compact bound and validity checks for points that are adjacent to your current point. It is both a performance, robustness and quality of life thing. The problem is that your matrix is a little bigger. Or in my case, a little smaller, since my 300x300 maps had an effective usable area of 298x298. This is corrected now and maps are created to compensate for this border with a plus 2 to each dimension.
• The map is not dynamically allocated and structured as planes. Believe it or not, the map used to be statically allocated. The map is accessed so often that the only viable solution was to make it a global statically allocated entity. A new API has been introduced to give access to cells and floors. The whole game now uses the new API. The API uses natural coordinate orders, so we have x, y and respectively z, rather then the hardware memory layout dictated order of z, y and x. This was a huge change, and while things seem stable right now, there is a good chance I broke something. A positive side effect of this is that clients of the library, like the editor, no longer consume memory in order to store a map (unless they ask to), so the memory consumption of the editor has been drastically reduced.
• Removed some outdated non-OOP style methods from the map handling API: TileIsEmpty, TileIsWalkable, FloorIsValid and FloorIsGrass. Proper OOP API is available.
• In order to better prepare for beta testing and better simulate computationally intense maps, the map is always allocated as 700x700x100 (7002x702x102), even if you choose a smaller size. You can only use the size you selected (you do not know how much was actually allocated). This way I can test the game using a lot more RAM than needed. If it runs well while using a lot of RAM, it will run well when it uses less too. New RAM consumption for test phase is 320 MiB.
• Rule set serialization code cleanup. -49 LoC.
• The internal namespace that I was using was called "World". Now that the API is changing its format, the new namespace is called "DH". This may seem problematic, since I am changing the name of the game, but the engine is still called DwarvesH, DH for short.
• Reachability cache moved into DH namespace.
• MapGen class that stores the map creation parameters chosen by the user has been improved, moved to DH namespace, has its own source files and supports serialization. Once the overhauled save system is done, world creation parameters will be also saved into the savegame, even though they offer no practical purpose.
• Removed extremely outdated snow code. Snow and snow remove operations have been removed from version 0.1. Initial biomes won't have appropriate temperature during winter to trigger snow fall.
• Misc stuff moved to "util" module.