14 – Slowly getting there

I did a massive cleanup round on the code. I am not going to bore you with talking about that, but while reorganizing code, I also found myself reorganizing and sometimes setting in stone for the first time the rules of the world. So, without further a due, here are a few key points:

1.       Climate determines the general rules

Every single map, and thus every single game, will have a single climate that does not change during game play. At first, you will select it from a list, but later I’m hoping in having and over world map generator that allows you to visually pick a sub region to your liking, part of a larger and believable world.

Climate influences the flora, fauna, temperature, water evaporation and other aspects that I’ll determine as things progress. Anyway, maps with different climate should play differently. The biggest change is that you will have access to different sets of plants. Maybe in one climate you will not have any edible plants (except the ones you grow in caves), but you will use them to set up an industry and import other kinds of plants. Or the other way around, having an abundance of food, but nothing that can be used in the industry. Or very rich resources, but full of wild and dangerous mega-cats that will eat you up. Yumm!!!!

2.       There are four seasons

Every climate has four seasons, even if there is little difference between them for some climates. Seasons will change at a fixed date and their effect will be felt instantly. Plants will appear and die govern by these dates. Having dynamic dates for season change is not planned for the near future.

3.       There is a maximum number of plants that will inhabit the world naturally

Think of it as having a hidden variable that governs fertility.  An area that is left untouched by civilization for a long time will be quite a wild place where nature rules, but there is a natural limit.

4.       Plants grow in larger surges

Plants will not appear one by one, but will appear in larger groups. This usually happens at a season change, when the temperature rises and seeds from within the soil give life to new plants. Or if the plants thrive for multiple seasons, they will cause another surge, simulating a surge of multiplication after an extended period of time when conditions where good for supporting life.

Surges are not big enough to reach the plant limit too soon. So if you do massive harvesting operations, leaving the world barren, I will take multiple years for all the plants to multiply and reach the levels you found them. Harvesting small numbers of plants will allow them to grow and maintain a relative balance in their number.

5.       Trees will grow out of tree stumps if available

Trees follow the same rules as the rest of the plants, but they have a much slower growing rate. Cutting them down will leave stumps, and new sprouts can appear from here. Or maybe the trees will appear in other new spots.

This is the first patch of rules that governs flora. This is mostly implemented, but I still need a session or two to give it the last touches. And it sure loves to be touched! Let me add a picture or two to distract you from the block of text. Here are a few tree stumps left by cutting them down:

And here we can see a very ugly bluish effect in winter on plants just after the snow has set. This is supposed to be the snow that has set on the plants:

You may also notice that some trees have changed between the first and the second screenshot. These are deciduous trees:

The split into three packages of the project is also done, so here are the statistics in a new format:

Statistics S30:

DHCore: 1354 lines / 33.3 KiB / 6 files

DH: 2065 lines / 56.4 KiB / 12 files

DHEditor: 518 lines / 13.7 KiB / 11 files

Total: 3937 lines / 103.4 / 29 files

13 – Less plants than promised

It has been quite some time since my last post but I have been terribly busy. I didn't have time to yet alone fire up the IDE, not to mention anything about writing actual code. Luckily, I was busy with fun stuff so I don't really mind!

Last time I promised more plant stuff, but this post is less about plants and more about the interface, and more precisely the editor. As I said, I was no completely happy with it. So I have redone it:

This is more like it! I is a lot better if you want to have a good overview when you are designing your whole set of items. It also allows for easy in-place editing of items:

It also has a nifty right click menu:

The second tab allows for the definition of the tree data:

...while the third allows you to edit animals:

The animal editor will feature a light redesign since animals are more complicated than I have anticipated. While the editor is by no means perfect and a little bit rushed, it is a step in the right direction. Unfortunately, the animals are only featured in the editor and are not present in-game yet.

The biome editor is also broken, but I don't need it right now and don't really know what to do with it.

Something else that is not visible is that the editor now creates the tile set images from a lot of small files from the disk. I used to have a tile set created by hand, with every image placed individually and a border around each tile to make the editing easier. But this approach proved to be quite cumbersome when trying to insert an image in the middle.

Having this new and improved editor makes me want to share it with other people, so I am hopping that in the near future I can polish it a little and make it public. I will be able to publish the editor a lot sooner than the first version of the game.

And since I want the editor to be full featured, I will be separating it from the rest of the game. It will be a stand alone executable. This will involve me separating the project into three packages: DHCore, which offers basic functionality and world modeling, DH, which offers the interface and game mechanics, and DHEditor. So this is the last time I will be posting statistics for the whole project. I will rather post them for every single package.

Statistics S26:

3801 loc/ 100.0 KiB/ 28 files

12 – More plants

Yes, I am going to talk about plants again! Deal with it! These plants are taking up some serious development time. I bet I'll have to say this about every single element of the game.

But just to take a little break from plants, I also did something else: I improved the performance of the rendering. With the help of the ever popular INI file format, one can now change the rendering back end. DirectX is going to be default, but on a few systems DirectX doesn't seems to work as good as software rendering, so you'll have the choice to use it. I usually test in software rendering mode and on modern computers you can get 80-100 FPS. But with the new optimization, I counted exactly 12 extra frames. Not meaningful for fast computers, but I guess I just enabled DwarvesH to run on a few extra computers. Still, text rendering is very slow for some reason and when I bring up some text heavy screen, there is actually a FPS drop. Got to investigate why.

So, back to plants. There is a new screen which allows you to inspect your harvested plants stockpiles:

Right now it is empty, but after harvesting a screen's full of bushes we can see our stockpiles changing live:

There are also a few basic tooltips giving you a little information about what you have harvested. This window need a lot of extra features, but it will do for now:

I would like to add here some useful icons, like if the plant can be grown in your current climate, if it is edible and also allow you to queue up the products that can be made from them. As for actually doing something with the plants, that is something for the next post. So next post is about plants...

There is also a similar view for your tree stockpiles:

Statistics S26:

3841 loc/ 102.7 KiB/ 24 files

11 – (Dragon) Plants and Z (level)

So, let us see how the world looks today:

A few changes can be seen, the biggest being the elevation. There are only two levels for now, but with the change to an isometric perspective, there won’t be hundreds of levels above ground because levels tend to be quite high. Visibility would be severely impacted. But this doesn’t cause troubles for underground levels. There are also a few trees visible. And the plant diversity is seemingly reduced. I’ll explain why latter. But first, let us look and the generalized selection mechanism:

A few patches of land have been selected. On the right side you can see the available actions for your selection. Pressing “3” will trigger the plants in all selected areas to be added to the harvesting designation. The plants are highlighted with green:

The selection mechanism is Z-level aware. You can see how the above levels block the view of your selection:

This is a good feature, but sometimes you just want to see your current level. Let us enable only the current level for rendering:

Aha!!! So this is where the missing plants have gone to. Nasty little buggers! Got to disable the “legs” option in the editor for all plants. Plants now take into account biome options and cave plants grow in cave areas. And yes, that is an extremely rectangular cave!

Statistics S23:

3604 lines of code in 24 files

96.2 KiB code

10 - Who's a good little toolkit?

*claps* What's up world? It's... *stares at wrist* FRIIIIDAY!!!

OK, maybe it is Wednesday. I’ve been done with the features related to this post on the mental outline of the post since Friday, but only now have I gotten around to post. Oh well, it can happen to the best of us…

You know what is fun? Creating a world and tweaking it until it comes alive right before your eyes.  What else is fun? All the other things that are fun. But wasting days trying to make two toolkits work together well is not fun.

DwarvesH is written with the help of two toolkits. For my GUI needs and general functionality I’m using U++. For hardware accelerated graphics I’m using Irrlicht. Why combine the two? Well, U++ is absolutely great for GUI work. One of the best I’ve seen. It also has an excellent standard library replacement. But it is has no features for hardware accelerated graphics. As said in a previous post, I needed a new toolkit for graphics because rendering performance has become unacceptable. This is where Irrlicht comes in. But Irrlicht also has a GUI component. But while the graphical capabilities of Irrlicht are great, its GUI component is kind of “meh”. It does a lot that previous GUI toolkits have done wrong and I mean the kind of things that make programmers sigh when hearing they need to do GUI work. It also uses the horribly outdated ID system for identifying widgets. Here is one of the golden rules that should be followed by everyone: a logical entity should not be represented by two different entities at the same when working with them, unless this is the nature of your given entity. So if you have a widgets and you are manipulating it through its instance variable you are not supposed to interact with it by other means, like by assigning every widget a unique ID. You already have the widget. There is no need for an ID system, IDs that are invariably constant integers and which fall under the responsibility of the programmer to keep track of them. Incidentally, all great GUI toolkits follow this rule and most not that great ones don’t and all horrible ones don’t. Coincidence? Who knows? As for the rest of Irrlicht, it is generally good, but it does have some other annoying factors. Like using reference counting as the general rule. I have nothing against garbage collection (but reference counting is the absolute worst kind of GC system and I have something against it) but not in C++. And not in 2010. C++ allows full automatic deterministic management of resource lifetimes (including memory) without the user having to write code for this by using RAII and the scoping rules of the language. You basically have the means to have the equivalent of a deterministic GC and all you need to do is follow a few coding conventions and have a library that plays nice with those coding conventions. And no, not with the use of smart pointers. Or dumb pointers. Or average intellect pointers who enjoy a wide array of musical genres without thinking about the musical merit of such pieces.

But enough ranting. So basically U++ gives a nice general purpose library and nice GUI toolkit and Irrlicht gives stellar performance for rendering. It also abstracts away the underlying system, so I don’t have to care about OpenGL or DirectX programming. Did I mention that it is also portable? So Linux version is in! So what could go wrong? Well, as it turns out, the two don’t really work together the way I hoped through no fault of their own. So I have the following choices:

1.       Go on. Use the same flow as before. This solution comes with a few caveats. I can’t have full screen resolution changing views as is customary for games. Also, I can’t write or draw widgets on top of the hardware accelerated views. So if I wish to put a widget on top of the view, I need to place it first in a new window.

2.       U++ is relatively pluggable. I could change the central point where drawing is handled to use Irrlicht devices instead and allow free mixing of the two. Not that hard but it takes some time and I’m not in the mood for it.

3.       Separate the central game view from the rest of the GUI. Maybe create a game executable and a world editor executable. Each with its own toolkit.

4.       Bite the bullet and use Irrlicht not only for graphics, but also for GUI. The amount of GUI in such a game is minimal, so it wouldn’t be that much work.

I chose something in the line of 4. Any smart person would make a choice (in my case 4) and go with it. But not me. I like my U++ work flow. I like my automatic resource management. I like my lack of pointers. In the entire application there are two cases where you can see “->”: in the A* implementation and in the core of Irrlicht integration. And “*” is used only for multiplication. Going full Irrlicht would bring these operators out of the closet and into my code! Can’t have that. So I wrote a U++/Irrlicht bridge/wrapper. It is very short and extremely hacky. I still fear its eventual explosion, but until then, I can pretty much take my existing U++ code, change the namespace of the widgets and recompile. Then do a few minor modifications which I hope to get rid of in the future and voila: I now have widgets that have U++ interfaces but behind the scenes are using “native” Irrlicht widgets. Porting from U++ to the bridge or vice-versa takes minutes. It is both an experiment and a failsafe. If in the future I somehow find Irrlicht not good anymore (very low chance; even with some negative stuff I said above it is an excellent library and I recommend it to others) I can “port” my application back to “native” U++ in a couple of hours.

I was going post some screenshots on Friday to show that no regression was caused by this massive change, but since then I continued working and no longer have a version of the application in that stage.  MUST… INSTALL…GIT… Also, I am skipping statistics for the same reason.

But the great news is that I have been working on the primordial form of the Z axis. It is time to give the land some elevation! Also trees are done! And they don’t die in winter like other plants do.

See you next time!