36 – Extended Easter

So I haven't posted in over two weeks and what do my eyes see? Where are all the comments? Where is the outrage? Where is the lynch mob? The end-of-days-preachers? I blame it on that rabbit. No masses declaring me dead? I really need to hire Elmer Fudd or some other high profile hunter to solve this problem.

OK, enough fooling around. It was quite hectic getting my last post out, with finishing the pre-alpha, posting on the blog, Twitter, finishing the video, solving the annotation problems, etc. so I forgot to write the outro. In this outro I wanted to say that my next post or several were going to contain something "big", so I might refrain from posting screenshots until this new big thing was done.

Then the pre-holiday period came. I was on holiday for six days, and then I just din't have time to post or code the way I usually do it. Not to say that I didn't work. I worked, but not in an organized manner; I worked here and there, grabbing a few free windows. I actually roughly finished my big thing, and also made a lot of other changes. I wanted to post the small changes on Tuesday and the new thing on Friday, but because of the above mentioned delay, I'll post the small things today and the rest in a couple of days.

So first I started with some YAML support. Not as much support, as hacking the entire underlying XML API to enable it to load a YAML file and use the information from it to populate XML data structures. I managed to get it to load some simple but sufficiently complex YAML files (for the need of the game) and... that's about it. The next step would be to take XML data structures and save them as YAML and then transition all the data from the game automatically from XML to YAML. Why YAML? Silly programmers with their silly preferences vis-a-vis competing and sometimes interchangeable technologies. So no real reason. And I am no longer sure I'll follow this path, because YAML is deceptively complicated. But why hack the XML componenets to understand YAML, when I could be using a YAML library? Something like yaml-cpp. Or something else. Integrating such a library should be fairly easy. But here's the thing: hacking the XML component is fun, integrating an existing library is boring, and rewriting the entire serialization code for the game's data structures for a new library would be pure hell. Who enjoys writing serialization code? If you know such persons please do your best to avoid them! This has been a public service announcement brought to you by DwarvesH! In U++ it is very easy to write such code, both for normal serialization and marshaling (XML serialization), but still, I wouldn't like to rewrite it. With my hack, I wouldn't need to touch the serialization code. Not to insult anybody, but the situation would be different if I had a code monkey :).

Another thing I created is a new system for building tile sheets. There were some problems with the previous system. One of the big problems is that you need great flexibility, especially once I'll have a full featured modding system. In order to achieve this, I wrote a system that takes a random sized image and integrates it into the tilesheet system, calculating all indexes and coordinates so you don't have to. Here I stumbled again over the problem with hardware textures: their sizes must be powers of two. Forgetting about this, I lost over 50 FPS. It took me 10 minutes to figure out why. Not only that, but on my machines, a 512x256 texture is slower than a 512x512 one. So I ended up wasting a lot of space with filler space in textures. Then I discovered that also the number of textures is important, with less being better. Which did not fit with the increased number of textures due to the white space.

So my first system was doomed. My second system is a lot better. It still creates tilesheets automatically, but now it can do it without any white space. You define a number of smaller tilesheets and give some basic info. In the future I'll add a GUI component to the editor to do this. And another pending feature is to change indexes from absolute to small tilesheet specific. This will work great with mods, where each mod can add any number of tiles without disturbing other tiles, either adding new objects or modifying existing objects.

As you can see, these new features are highly experimental and took a short time to write the first time, but then it took a lot to rewrite them in a more appropriate manner using my new knowledge acquired experimentally. But there is one new feature that is intentional and a natural evolution of the game.

You see, most of the time you can't queue up more than one action on an object. As an example, you can only give the order to plant or harvest a plant. I am talking about the same plant. You can't queue up a plant operation and a harvest, because the plant will take months to grow. But some objects permit this. You can queue a wall smooth operation, followed by engraving and finally digging. You can then unpause the game (if you paused, but with the new scheduler pausing should be quite rare) and the actions will be executed in order. But this is a thing of the past. I modified designations so you can only have a single designation on an object at a time. Things are simpler this way and more intuitive. It also fits better with the new more forgiving scheduler. As an added bonus, this way you won't make mistakes where you designate a huge area and in a sub region you forget to add a designation, queuing up let's say 3 actions in the general area, but only 2 in the area where you miss-selected. So this is intentional, but I'm sure I'll have a few bug reports regarding this once I release. So be prepared to meet mister "not a bug, a feature".

I also made some changes to scheduling filters yet again, enough to fill half a post if I described them here. And some other changes, which I won't mention. OK, I'll mention one more: in the past I had multiple files which represented a single logical entity. This is confusing, so from now on I have one single XML file describing game data (i.e. that is a single logical entity). Every mod or content pack will have one single XML file and zero or more PNG files. But I can split it up if I wish, making one content pack for plants, one for animals, one for stone, etc. These will be self contained, but able to communicate.

So in my next post, I'll be presenting the new feature I have been working on. This should give you a fair overview of the final form (for now) of one of the game's features. So you've guessed it: the second presentation video/tutorial. Let's hope this brings more controversy than the first one! Everybody loves controversy! The features are done, all I need is to finish the script for the video. Yes, they do have scripts! In the past I also needed to practice my videos, but I am getting better and I only need 2-3 takes. You can mess up a video with one single miss click or longer moment of inactivity.