Friday, December 17, 2010

21 – Hollow Earth, part two

After the lengthy explanation from last time let us jump right in, and only draw front-left and front-right sides for floors only when they are needed. The world becomes quite black:

Turning on multi-level rendering we can see how few tiles need to get rendered. Keep in mind that there is on layer that covers everything like a sheet on a bed that is not visible right now:

Then, for the first time ever, we draw the top side of floors:

And then of walls:

Dwarftastic!!! Everything looks like it looked before and the frame rate is pretty much the same. But, if we turn on multi-layer rendering and scroll to the side of the map where it is the thickest, we get this result:

The thing to note is the FPS in the title bar: 91! This used to be around 20. And with single-layer rendering, we get 108. The actual numbers are not important, since they change a little based on the content of the map and a lot based on the hardware that you are running it on. What is important is the relative difference between them. Going from 100 to 20 is very bad. Going from 100 to 90 is negligible. So it seems that all the effort put into this algorithm has paid off.
One thing that you will notice is that there are black squares where I dug out the floor. This is because in the past, it was only an illusion that we are not on level 0 but on level 1. I used some tricks and faked and extra level when needed so that I didn’t have to render another floor. Now I removed this hack and we are on level zero, so there is nothing below it when digging.
Since we now have this great engine that is capable of drawing multiple levels fast, let us change from level zero to level 10 for now. That is 10 extra levels. The problem is that I have hard-coded zeroes everywhere in code. After changing that in a long and arduous process that I am not going to talk about any more, we get this:

Perfect! And this is with levels zero through 10 drawn. There is no longer the distinction between single- layer and multi-layer rendering. Now you can choose between levels 0 and your current level and rendering of the full height of the map. This also means that you can lower your current level to underground, and become completely lost because everything is uniform rock. This is also a problem in Dwarf Fortress. You can get lost so bad that you need to zoom over to your expedition drop point. You do know the keyboard shortcut for that, don’t you? Fun times...
So let us scroll over to the side of the map, enable full-map rendering and check it out:

Pretty thick. That’s what she said! The new rendering engine is not quite map height agnostic, but it is lot faster than before. And there are a lot of performance tweaks to be made yet, especially since I was quite in a hurry with the implementation. Anyway, this is not a game in which you will need hundreds of FPS. Going up to you screen refresh rate is fine, but there isn’t a lot of benefit in going further than that. The tricky part is getting the required FPS on old hardware. Right now I am only rendering worlds of 300x300x20. I would like to increase that if possible. Horizontal dimensions are easy to increase, they only eat up memory. Vertical dimension increases have negative effects on FPS.
This concludes my two part mini-feature on the new rendering engine. The code is written in such a way that later I can replace the drawing of a side with the placement of four vertexes in a vertex buffer and I already have all the visibility factors computed for a relatively painless transition to a true 3D engine when the time calls for it.

Thursday, December 16, 2010

20 – Hollow Earth, part one

As said last time, the only way to speed up rendering still left is to draw fewer tiles. But in a multi-layered 2D isometric game, where a wall tile is a single sprite, determining when something covers something is both difficult and costly in CPU power.
So let us suppose that we have a 3D world. While this world is not made up entirely by cubes, floors and walls are made up by rectangular 3D shapes that we can abstract as cubes. So how would we proceed in a 3D game? We would use one of the well-used and documented methods, like octrees. Octrees are basically cubes that are divided recursively into 8 cubes. These have interesting properties that are useful in 3D rendering engines. Or so I’m told. I never used them and I can’t write an octree implementation of the top of my head. I could with a little bit of study. But let us try something different.
Coming back to our 2D game, the idea is to split up the single tile of the walls into multiple “polygons” like you would do in 3D, and only draw the ones that are adjacent to a free space. We only draw the “borders” of the world. Hollow out the world. This should greatly speed up full multi-layer rendering, where all Z levels are drawn and which currently is unplayable, having with all optimizations a FPS of less than 20 while on the same computer single layer rendering is well over 100.
I’ll proceed and visually walk you through the process since this is not a technical blog. So let us start with a normal world, where walls are drawn by a single sprite:

Now, since the “camera angle” is fixed, we don’t have to worry about all sides of our cubes. At most, only three sides are visible, that is the ones in the front. We have one on the left, on the right and one on the top. So let us draw only all the ones on the left: 

Where is the gain in this? Well, first we need to only draw the sides that would actually be visible, not all of them. If we do that, everything will disappear. While all other sides are not drawn yet, they still would cover the ones on the left. So I cut out a small corner where two of these sides are seen:

Actually, let us cut out a few tunnels, so we can get a better look. All black parts are not rendered and should be invisible since they are covered by top layers. When enabling single layer rendering, the top sides of walls will be forced to render, but we’ll talk about that another time. This is the result:

Something you may notice is that floors seem to be drawn in a strange manner. This is due to a previous optimization in the rendering engine, which would enable some floor tiles that are covered to not be rendered. So don’t mind these. Now let us enable all right sides of the walls:

Then we will do the same thing, that is draw only the ones that should be visible. To better illustrate this, I managed to cut out a few extra tunnels:

If it is not clear what I am doing, maybe it will become clear when I apply the same process to top sides of walls and floors. Basically, the black part is and should be invisible. Theoretically no processing power is wasted on them. This only applies to multi-level rendering, but single level is fast enough.
But this post is way too long. I even broke the five pictures per post rule J. So I’ll split up this post…

Wednesday, December 15, 2010

19 – Not dead

Good news everybody. I am not dead and neither is this project. The huge break in posting is due to me having a busy period right now. It is December and in December you spend half the month on holyday and the other half preparing to go on holyday. Also, there was a launch of a high profile game that I am not going to name here that had occupied a lot of my free time.
But the main reason for having a hard time getting work done on the project is that I’ve gotten stuck on the scheduler. In the beginning it was simple but it got very complicated. I could stop here and formulate the entire task in a formal language so you can see how complicated this was, but that would take a lot of space and I am way behind. Enough to say that I hate it when a game is perfectly fine, but it has some serious but not game breaking flaws. A lot of games have camera problems for example. Why did not the developers fix it? More often than not the answer is that it was very hard. There is not a fixed formula that you can apply and have a perfect game camera that never obstructs your view. Making it perfect would require maybe huge resources. But still, I’ll have a perfect scheduler and I am getting close.
So now let us talk about the new features that were almost done at the beginning of December, but yada yada yada things written above.
So workshops? Yes! Quite a few of them:

Selecting a building type will result in a marking on your map. Here your building will be built. As with stockpiles, these markers are not physical objects. They are just something to help you in the game:

After that, a single dwarf will go and build the workshop tile by tile. While the process is animated and scheduled fully, the resulting building is underwhelming:

In the future you will be able to tell all building apart. Right now only the frame is placed. As this will be only a cosmetic feature, I will not rush to implement it.
This is all I promised for next post last time, but luckily I have more given the huge break. Now, when harvesting plants they will appear on the map in a small sack. These sacks are free. Just consider that your dwarves love sacks and brought 3000 of them on this expedition:

Creating food stockpiles will result in your dwarves hauling them there, like they do with logs, only this time their movement speed will not be affected. Logs are big and heavy, but a sack of food is not that much for a sturdy dwarf. Here they’ll combine the content of sacks so they take up less place and left over empty sacks will magically disappear only to reappear when needed. Here you can se the dwarves as they haul food and fill the stockpile: 

So let us say this is two posts worth of features? Not really…
Luckily, I have one more: map saving and loading. This is way over due. Now I can continue to develop the same map and I am not forced to start from scratch each time. It is maybe a little bit buggy, but I’ll fix it. Saved maps are huge, almost 3 MiB, so I use Z compression to get them down to a few KiB.
And there was also the last round of rendering speed improvements. This is it. Things can’t get any faster than this. The only way is to draw less. I have some ideas about “hallowing” out the map, ideas that could lead nicely to a future 3D engine.
For the rest of December, I am not going to have so much time, but I’ll still squeeze out a post or two. But in January everything should get back to normal.

Statistics S45:
DHCore:  1875 lines / 44.8 KiB / 11 files
DH:  2533 lines / 63.8 KiB / 13 files
DHEditor: 612 lines / 16.1 KiB / 13 files
Total: 5020 lines / 127.4 / 37 files

Wednesday, November 24, 2010

18 - Stockpile overload

What is a good use for stockpiles? Drawing it seems. I’ve added the general stockpile categories when creating a new stockpile:

There is going to be some tweaking to these categories, but you can use it to draw stuff:

Every stockpile has its own color. I could probably do a better job of picking the colors, but I use Microsoft Paint for my image editing needs and these are some of the default colors.

In the next image there is a lot going on. I have designated a large area for cutting down trees. As a new feature, every single log that has resulted from a cut down tree is visible by the tree trunk. They are removed one by one. Six dwarves are still busy chopping down trees while the last one is hauling logs from near tree trunks to the wood stockpile. You can see that he has a log in his hands and he has already placed two logs in the stockpile:

Once the cutting is done, everyone gets busy filling up that stockpile:

Alas, the stockpile is too small and I needed to add a second one so that all the logs could be placed:

This process took quite a while and I’m looking to speed it up. Generally, I am happy with the idea of time compression but not with the implementation. It is at the first iteration so no worries. You know what is not at the first iteration? The scheduling algorithm. I get the feeling that I rewrite the damn thing two times a day.
Besides the improved scheduler, there are some small performance tweaks. When enabling full map rendering you should get a few extra FPS (5 with software rendering at 720p on of my machines). Also some small interface improvements.
Next time: workshops!
Statistics S41:
DHCore: 1881 lines / 45.9 KiB / 10 files
DH: 2205 lines / 54.6 KiB / 12 files
DHEditor: 612 lines / 16.0 KiB / 13 files
Total: 4698 lines / 116.5 / 35 files

Thursday, November 18, 2010

Official Twitter account launched

I’ve created a Twitter account: Don’t worry, I am not going to be posting stuff like “It is raining”, “I like pizza”, “I am a dwarf”, “Buy my new t-shirt” or “I feel sad”.
But I will be announcing every post there. It is an easy way to post updates. It also has the advantage that sometimes I don’t have enough to say for an entire post but I could say a few words. Then you’ll get a short tweet. I wonder if there is a tool that allows you to combine and inspect your posting history from Blogger and Twitter as a common timeline.
In order to not have an empty Twitter, it would be easy to start spamming my backlog. But I won’t do that. Maybe.
Twitter widget is also available on the blog with the latest tweets.

17 - There is a Z in the title so I can has more views like last time? (Dragon)

The title of the post is a pun upon the fact that one of my posts, 11 – (Dragon) Plants and Z (level), got more views at the time than others. This could be due to the fact that the post was about a more interesting subject at least in theory, but maybe it somehow got associated to other subjects because of two keywords in the title. Dragon an Z. I’ll let you figure out the third key word.
I’m not ranting about titles just for fun. I managed to improve the Z layering, and now you can have multiple Z levels. Still only one level is playable, but I like the overall look and feel of the multiple levels. Of course, when turning on multi-level rendering FPS drops like a rock. Or a lazy dragon. Z! For now it is a mystery how people in the 2D isometric era of gaming managed to have such smooth framerates. Maybe they used really sophisticated algorithms. I have some in mind that would surely work very well, making the number of visible layers not count at all, but I get the feeling that I would be just reinventing what the GPU could do for me if I switch over to a polygon based engine.  Another new feature is the ability to have maps where the cliffs face at a different angle:

But Z level is not the big feature of this update. It is the new scheduler. Again! I just can’t leave it alone. But the new one is really great. It is a lot more powerful, faster and easier to use. It is really great quality piece code and there is little I can do to improve it in the future. Maybe adding LOS (line-of-sight) tie breakers to better simulate a way a sentient being would go on about these tasks.
The new algorithm is very general. Given a set of any tasks, it can choose a dwarf D and a task T that has the properties P. T will be heuristically the best (read most reachable) task from the set and there should be a path from D to T. If there is none, an action can be taken. In previous version of the algorithm, if you would choose a task that was not reachable, like a bush from a sealed off cave, the game would freeze. With this new algorithm, the task will be removed. The process is still very slow, but it is a lot better than freezing. Unfortunately, A* is a lot better at finding a path between two points than figuring out if a path exists (because you’ll end up exploring all reachable points). In the future I’ll add a constant time (and near zero) algorithm that can tell me if there is a path between the two points to know if it is safe to call A*.
Here is a video. At the end I also demonstrate the “remove floor” feature which I’ve never shown before. It is a little bit buggy, that’s why:

This video has been produced by using a version of DwarvesH and modifying it by applying the tiles form Stonesense (­­p?topic=43260.0) only for the purpose of creating an early demo video. DwarvesH is not available in any form with the tiles from Stonesense by default officially or unofficially and does not assume any right to use them. The process can be repeated by anyone by downloading both applications and using a simple image editing tool to selectively change the tiles from DwarvesH with those from Stonesense or the tiles from Stonesense with those from DwarvesH.

Statistics S38:
DHCore: 1755 lines / 43.1 KiB / 10 files
DH: 2055 lines / 50.3 KiB / 10 files
DHEditor: 612 lines / 16.0 KiB / 13 files
Total: 4422 lines / 109,4 / 33 files

Wednesday, November 10, 2010

16 – Is that wood in your stockpile?

As you saw from previous screenshots, I am going with a fixed key/function system. “1” is always digging. The keys are going to change maybe and it is going to be hard to add all actions to easily reachable keys without overwhelming the player, but it is a good system. I think I should get rid of the right panel and go with something that takes less place though.
So I have a new action, “5”: wood stockpile. This will designate your selection as an empty wood stockpile. I have a hidden cheat key that places a single log in an empty stockpile. No, you won’t get to use the cheat key. It is only available in super secret God mode. I will demonstrate this with a video. Next step that is not implemented yet is to place the logs as trees are being cut down.
This time I captured my video with Fraps. It was slightly problematic because the captured video was 2.5 GiB and YouTube only allows 2 GiB files. But I downloaded a conversion tool and got it down to 93 MiB so no problem! YouTube took a few hours to process my video, so I waited with the post until it was done. I am not completely happy with the quality yet. And as you can see, the resolution is different now. I have added support to the INI file for resolution and full screen flag. You can give any resolution if you are not running in full screen. Someday this will be available in game.
There is also a new mini feature. The editor now allows you to customize the names of you skill levels and also the maximum value for skills. They are no longer hardcoded:

So now, without further a due, the video:
Same as the last time, I have added a disclaimer because I am still using Stonesense tiles for demo purposes, but I do have some original graphics mixed in there.
This video has been produced by using a version of DwarvesH and modifying it by applying the tiles form Stonesense (­p?topic=43260.0) only for the purpose of creating an early demo video. DwarvesH is not available in any form with the tiles from Stonesense by default officially or unofficially and does not assume any right to use them. The process can be repeated by anyone by downloading both applications and using a simple image editing tool to selectively change the tiles from DwarvesH with those from Stonesense or the tiles from Stonesense with those from DwarvesH.

Statistics S34:
DHCore: 1522 lines / 37.0 KiB / 6 files
DH: 2034 lines / 52.2 KiB / 10 files
DHEditor: 613 lines / 16.1 KiB / 13 files
Total: 4169 lines / 105.3 / 29 files

Tuesday, November 9, 2010

September and October in review

Are you familiar with the concept of a release report? Well, I won’t do something as dire here, but once in a while, more precisely at the end of a month or two of development, I’ll put a few words on paper. I’ll try to be as short as a dwarf but less inebriated. Not because I am trying not to be, but there is just no alcohol around here right now.
I wanted to do this at the end of September, but that was when the change from 2D to isometric happened, so it was not a good moment. I also wanted to add a few tables, with features broken down and with percentages relative to their completion given. But how about I skip the bureaucratics? So I’ll use a short bulleted list with major things that are done:
·         Basic game engine that is capable of rendering and populating multiple Z levels, but movement is restricted to just one
·         Basic editor
·         Scheduling of digs, channeling, plant harvesting and wood cutting
·         Plants and trees
·         A few info screens
·         INI file support for multiple rendering backbends
·         Other things that I forget but are in previous posts
·         And XML support!!!
Oh gosh, I forgot about XML support in my previous post. Since I want to publish the editor ASAP, the very frequent change to the data that is serialized is not that advantageous. The serialization format is very fast and painless to use, but it is very sensitive to data changes. So for now both the editor and the game will use XML to try and obtain a minimum backwards compatibility. This was done in the same timeframe as the previous post, but I am not going to edit it.
Not short enough!
Features planned for November:
·         Food and wood stockpiles
·         Stone deposits while digging
·         Butchering of animals
·         And maybe a few wood products

15 – Will you shut up with the plants already? Sure!

It’s been quite a while since I posted yet again, but I came down with a particularly nasty bug. Fallout: New Vegas!!! Good times! Great game, but extremely buggy. If I would remove half of my code base randomly ant the thing would still compile, there is a chance that I would have less weird bugs than in Fallout. For now, I have gotten my fix and maybe I can get some work done.
So I’m done with the plants. With the rules set in stone from last time and a few more tweaks, I have gotten plants to a respectable place that is not going to undergo major changes until somewhere after a release or two. I’ll still do small tweaks here and there, but nothing that would warrant more than a phrase in writing.
General cleanup is also done. I’ve done the reorganizing part and the code base is quite stable right now and I like the way things are set up. I’ve eliminated most of the dead code and parts left by the transition from 2D to isometric.
Another change is that this is the first version that properly compiles and links without CtrlCore and CtrlLib, two packages form U++ that provide the widgets and their framework. This is not important for you, but the executable has gotten smaller and linking is a little bit faster.
I also overhauled the rendering engine. I removed all computations from rendering loop giving between 7 and 10 FPS. Not much, but If you add all other improvements from previous versions, it seems that I should get DwarvesH going on a very old computer and see if it performs as well I think it should. I also optimized floor drawing. Now, if you can’t see it, it won’t be drawn. This causes a gain up to 50 FPS if you scroll the map to part completely covered by hills. Rendering hills is now even faster than rendering grass areas because you don’t have to render plants.
I also managed to do something about the very ugly font I had before, but I have encountered two problems. The font generator does not have an option to generate not antialized fonts, and everything turns out just a little it to blurry. And most important of all, saving the same font as a PNG instead of a BMP gives major performance penalties. I tried changing all textures to BMP to see, but I got a minor performance penalty. Congratulations Irrllich for being random!
Just a single screenshot. Is the font to wide?

Statistics S33:
DHCore: 1534 lines / 37.0 KiB / 6 files
DH: 2006 lines / 51.4 KiB / 12 files
DHEditor: 530 lines / 14.3 KiB / 11 files
Total: 4070 lines / 102.7 / 29 files

Wednesday, October 27, 2010

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

Tuesday, October 26, 2010

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

Monday, October 18, 2010

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

Tuesday, October 12, 2010

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

Wednesday, October 6, 2010

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!

Wednesday, September 29, 2010

09 – Isometric?

One of the goals of this project, besides creating a nice little sandbox game for myself, is to create something that anyone can pick up and have at least a slight idea of what is going on without prior preparation. But the past days, when I have shown someone my work, the universal answer was “WTF is going on here”. I have no problem with ASCII graphics and when a group of “d” letters is approaching menacingly I’m not thinking “hey, a d”, but “OMG, IT IS A BLINK DOG APOCALYPSE” (ADOM reference). And I know that people that are not familiar with such graphics have a steep learning curve. This is why I had some top down graphics, to lessen the impact and adaptation period that is necessary before picking up an ASCII game and before learning its specific mechanics. But I was not enough. So I tried isometric graphics.
Before I link to the video, there is a point to be made. I have my own hastily assembled tile set. It is not pretty, but I want to code right now, not mock around endlessly with graphics. Yet I need something good looking to illustrate the point that graphics play a large role in the ease of learning something. So for the purpose of a video I borrowed the awesome tiles from Stonesense ( I’ll proceed to let the people there know about me using their tiles for the purpose of the video, but until then I have included a disclaimer:
This video has been produced by using a version of DwarvesH and modifying it by applying the tiles form Stonesense ( only for the purpose of creating an early demo video. DwarvesH is not available in any form with the tiles from Stonesense by default officially or unofficially and does not assume any right to use them. The process can be repeated by anyone by downloading both applications and using a simple image editing tool to selectively change the tiles from DwarvesH with those from Stonesense or the tiles from Stonesense with those from DwarvesH.

Now this looks a lot better! The response that I’m getting is also better. In the video I dig a couple of simple caves and demonstrate the rather slow covering of the landscape with snow and dying of plants. Pressing “T” advances the time artificially with one day. For such a big change, I would have liked a longer video, preferably HD, but I still don’t have adequate capturing software. I’ll try FRAPS next.
Not much left to say. Feature wise everything is the same, a little bit of extra polish and nothing got lost in the transition to isometric. Smashing!

Statistics S17:
3162 lines of code in 23 files
82.2 KiB of code