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

Thursday, September 23, 2010

08 – Santa Claus is coming tonight

It seems that the number of prerequirements before I can get to the meat of the game never seems to get any smaller. With the ability to harvest plants the world needs to be able to regenerate these plants. From here to implementing basic seasons is just a small step. Which I took. So I wanted to upload a video of seasons changing to show how the world progressively is covered by snow and then in spring the snow melts and plants show up. But on this computer I was no able to capture video with the required frame rate and most of the phasing from grass to snow was lost. This may be due to the fact that DwarvesH is eating up most of my processing power. Oh well, a picture can say a thousand words or something like that.

Let us start with winter. The fairly typical scenery is covered by patches of snow:

As time passes, more and more snow is able to get a hold of the surroundings and plants start to die. If you don’t have enough supplies this would be the perfect moment for a desperate harvesting spree:

And here we ore in the 23rd of December, with snow cowering everything and bowing down to no one except the infinite power of Santa Claus (I know that it should be the 24th, but I’m not retaking the screenshot only for that):

But here comes early spring:

…followed by the total melting of snow and the first plants:

With one month of development approaching fast, I would like to have at least the ability to harvest plants, cut down trees and designate stockpiles. Oh yeah, and digging! (about done with that)

Statistics S14:
3087 lines of code in 23 files
80.0 KiB of code

Wednesday, September 22, 2010

07 – Time & time compression

When implementing the passage of time, the most important aspect that must be decided is the scale. A unit of time in real life equals to how many units of time in the game?

For starters one can implement a time scale that is uniform. Time always flows at the same pace. For some games this is the best choice. For something like simulating dwarves building an epic fortress underground, figuring out the scale is very difficult. Digging and building should take a lot of time in the game. You want your dwarves to slave away for years before they have a truly awesome fortress. A small encampment should be built in a few days, but you want at least to dig out some tunnels, plant some crops, wait for them to grow and harvest them. This process should take roughly a month and a half. But for the person that is playing the game time will flow like normal and the months that have passed for your dwarves will be only minutes or hours of real time. And here lies the problem. If you want to give a brisk pace to the game, you end up with all short actions taking far too long or not being visible on screen. Take walking across a tile. In real life it would take your dwarves a couple of seconds at most to walk such a small distance. Such small intervals would not be visible when animating the game. Or you can make the interval longer, so you have time to display the dwarves as they are moving along. But these long intervals will wind up far too long. To illustrate this problem, according to the Dwarf Fortress Wiki it takes 13 minutes for an average dwarf to walk a tile. You can try to compromise, but I was not able to come up with a scale where fast actions moved fast enough and a month of game time was under 5-6 hours of real time.

Then there are non-uniform time scales. For my implementation I have chosen time-compression. When all your dwarves are idle or moving along on their path, time in game will run like normal, with a speed somewhat faster than in The Sims™ series. A second of real time is roughly one minute in game (a little more or less, but I don’t want or need to figure out the exact amount, especially since this amount will fluctuate slightly based on the FPS of the game). The game will always run at this speed or faster. Actually, it will run at a speed where it can finish the shortest task in one cycle. So when all your dwarves are busy digging out a piece of wall, time will pass at a speed of roughly two hours per cycle. For now, it takes a dwarf two hours to cut out a tile from the mountain. With time compression, in one minute of real time when everybody is idle or walking, in game only minutes will pass and in the next minute, when all are busy chipping away a few days will pass. The time scale is adjusted on the fly. So if all seven dwarves are working and time is in super fast mode and one needs to walk over to somewhere else, while he is moving time will slow down. I hope I managed to explain this correctly. It is quite strange to see time fluctuate like this, but once you get used to it I think it is a good system.

Another subtle advantage of dynamic time compression is that you can reward the players who are careful to optimize paths and not waste a lot of time walking around with their dwarves with convenience bonuses. These players will be able to do more in the same amount of real time than someone who has very long and crowded walk ways or who places key industries that rely on each other at great distances. For your dwarves it will not make any difference, because walking a step only takes one second for them. A few extra steps are a few extra minutes for them, but for players these are moments when time compression is not working. One must be very careful though to not impose a much too harsh penalty, because eventually even a very good fortress may get cursed with perpetual slow passage of time when its complexity reaches over a yet unknown threshold.

This post was full of rambling…

So new features: the above mentioned time compression, a display for you clock showing the date and time and a very useful pause button also accessible by the letter P on your keyboard.

Statistics S13:
2968 lines of code in 23 files
76.8 KiB of code

Tuesday, September 21, 2010

06 – Polish is the mother of all… c’mon, do some 3D!!!!

This post was supposed to be about how important is polish, even at such an early stage. I had a couple of polishing runs, one where I changed the scheduling and path finding so that now it looks a lot better, with less random jumping around. I have some great ideas for the final form of the algorithm based on some profiling and a little fooling around with it. In another session I did some general cleanup.

But my third session was cancelled. Unfortunately, even these primitive 2D graphics were too much for my very powerful development machine. I tried it also on an average machine with a comparatively very poor graphics card, and the result was similar. The performance of the rendering engine was capped by whatever (probably software rendering) the graphical toolkit was using to do the rendering. On my machine I had between 10-20 FPS and on the other machine even lower. It is even visible in the previous post’s video: there is some serious mouse lag.

But now everything is better. I ported my rendering engine over to Irrlicht. Now I have 84 FPS on the poor machine. The porting was very easy. I’m not sure if Irrlicht is the final way to go because Ogre3D is also a strong contender, but there is one lesson to be learned here: do not cheap out on using a third party tool that can offer hardware acceleration, platform independence, abstraction and simplification of common tasks, even if what you are programming is very simple at this stage and you may or may not wish to extend upon it. You can use anything from SDL to something you find on the net, but using something with a strong user base will make things easier for you.

I won’t post a screenshot because everything looks the same. Now there is no way I’m using something with the capabilities of Irrlicht to draw 2D tiles forever. With this change, switching to 3D tiles & perspective is up on the table for the near future.

Statistics S12:
With the introduction of Irrlicht image data is no longer included in the resulting executable and has no impact on the number of lines of code in the project like it did before. I will also exclude image data from the size of the code:
2922 line of code in 23 files
75.3 KiB of code

Wednesday, September 15, 2010

05 - 3000

Oh yeah, it is digging time!

Well with a video capturing my efforts for posterity, I think I am officially past the "guy doing stuff in paint and pretending to be a programer" phase. Am I right?

In the above video I start with a barely visible command to harvest a bush. Then the fun parts starts. I am designating some areas for digging. A nice fractal pattern should do for starters. Areas are marked with the right mouse button presses and by dragging the mouse. Nice and intuitive. I'll keep such an interface. The first thing you right click will determine the action for your selection when you release a mouse button. Clicking on a wall? Well, probably you want to designate it for digging. Clicking on a designation for digging? Remove the designation.

While I am drawing along, nothing is happening. The game is not paused. The pause button is not implemented yet. In the future you are going to want to pause when designing something more complex because the clock is ticking away, but for simple actions you won't have to pause. The dwarves are not working because the areas designated are not accessible. Once I designate a corridor that will connect these areas to the outside, one single dwarf begins working. As soon as other points are accessible, other dwarfs start working. Eventually all of them are busy chipping away.

The algorithms involved are not yet perfect but they do a fine job and I am not going to improve them yet. I actually like the little peculiarities in movement and scheduling. Dwarves consume huge quantities of alcohol. They should choose strange work patterns in consequence.

Also time passage is not accurate yet. Digging is almost instant. With time, I'll figure out the durations so everything feels right and is also challenging.

Uploading to YouTube was pretty simple. But I have a crap capture program. Not only did it manage to extend the duration of my capture, but it saved almost 800 MiB on disk. I had some fun uploading for 40 minutes.

So why the tile of the post? Because I have exactly 3000 lines of code. I did not try to achieve this round number for this post, but I guess it must be a sign.

With a minimum of features, it is time to implement saving and loading of games. I don't want to have to start all over every time I boot up DwarvesH.

Statistics S10:
3000 lines of code in 23 files
94,9 KiB (including 23,3 KiB image data)

Monday, September 13, 2010

04 - ...and Life

This is going to be a relatively short post based on how late it has arrived. And while the number of lines may have not increased in such a steady rhythm as before, I have invested a comparable time to tweaking the new scheduling system.

With a a very simple map populated by plants that don't do that much yet, I needed to add something more dynamic. The first step was to add movement. For my movement related needs I used the good old A* algorithm. It is fast and very easy to implement once you understand the way it works. There is no good reason not to use it.

But the hard part was the scheduling algorithm. It is bare bones, but after a lot of tweaking it is capable of looking though the list of available tasks and the list of available dwarfs and tries to match them, plot a course, compute the durations and then "animate" the dwarves so that they move with a good speed and an OK feel to it. And all this while the user can still input some basic commands without pausing the game; in this case one can add new plants to the task list. Here we can see it in action:

Dwarves that are doing something are marked with red. The bottom left dwarf has already picked his assigned plant and is blue again signaling that he is available for other tasks. If I add new plants, he will be the first to work, followed by the rest of the dwarves:

This could have been the perfect opportunity to introduce some videos. Pictured will have a hard time showing you that those five dwarves are walking around and making plants disappear (they claim that they are picking them up and preparing them for stockpiling, but I saw no new food reserves – not implemented yet). Alas, I don't have a video capture program on hand and I'm far too lazy to find a free one on Google at this hour and then mess around with video upload. But it is something for the future.

As you can see in one of the screen shots, there is little panel around the bottom informing you on what you have selected with the mouse. For plants it now has two buttons. I'm thinking to introduce a single "Do it" button for a lot of simple tasks. Naturally, dwarves and buildings will have a lot of options, but for things like plants, trees and cave walls I'll try a default action buttons which designates them for gathering, cutting down or digging.

For the next post, I'll do my best and add the second dwarf related element (the first being the dwarves themselves): digable cave walls. I hope they will enjoy it!

Statistics S009:

2655 lines of code in 22 files (including data editor)

84.2 KiB (including 20.4 KiB image data)

Tuesday, September 7, 2010

03 - Let there be... graphics?

While I may have not implemented everything that I've bragged about in my last post due to reasons that I'll get into later, I managed to get a basic game screen working. And it has graphics. The ugliest graphics you have ever seen! Please do not click on the image bellow. I even made it small so you won't be tempted to click on it:

Wait, wait! I'm only joking. Please do not run away. Actually, I looks quite good considering that I've spent a maximum of 30 minutes searching on Google for random tiles that resembled what I was looking for and added them to the tile list. I can foresee a bright future for the graphics in this game. Right now you can notice the grass that forms quite a pleasant and not overly repetitive pattern. A lot to improve on it, but I can imagine dozens of such pattern for grass, soil, ice, etc.. And variations based on climate. And you can see a few tiles for the plants that right now are placed randomly. I don't have enough tiles right now, but imagine that every game will look different (if the starting climate and conditions are different) and you can instantly tell by the graphics what is a pig tail plant and what is an angry lion. Great for your enjoyment and survivability and great for new players. New players might not know that it is a pig tail, but they will still know that it is a plant like thing and not an overly friendly and useful cat.

And you can see your seven starting dwarves. The tile is obviously a poor fit. The dwarf is to small and the shadow is not needed or at least is darker than it should be. With larger and color-coded-for-your-convenience dwarves and a rich tileset maybe it is possible to convey the inherent life and atmosphere of a dwarven fortress set inside an inhospitable mountain in a more visually compelling way. It sure gives me a lot to rant about.

As you can probably tell by reading the above paragraphs, I am not going to include support (at least for the foreseeable future) for "legacy" systems, i.e. console character based display. It is 2010 and we have cheap smart phones more powerful than anything that is implied by ASCII displays. Cheap netbooks should and will be powerful enough to run this thing, but that is as low as it will go. If you look at this game and say "1996" then a machine from "1996" should run it. More or less.

As for the "look at thing" mechanism, I haven't gotten around to it yet because all the other stuff I had to implement first. But I have a new and better idea so I would have ended up scratching the old way anyway. But you can click on stuff to get an awesome highlighting effect (this time with full size picture):

So let's talk trees. And plants. The first draft of the plant editor is here:

It is strong enough to assign most of the properties for the plants and it is easy to use. I have covered the plants I wanted for now. And here is a similar window, this time allowing you to define your trees:

Meanwhile, I've become unhappy with the design of these dialogs. They are good enough, but lack overview capabilities. I'll use a new design for future such dialogs which will be a lot better.

In the biome sections you have a button labeled "Choose" which brings up this atrocity:

Ohhhh God!!! What was I thinking? I must have been drunk when I thought that this would be a good design for a biome configuration window. Or for anything with so many items. I promise to never let it happen again.

Every editor you just saw is fully functional. They load and save data, and the game uses this data to populate the world. Right now it ignores biome information and there is nothing really to this "populate world" nonsense because for now I will only be placing plants. Without trees. I need to find some unique placeholder graphics for every plant and add options to the game so you can choose the environment. And then simulate plant growth.

See you next time!

Statistics S006:

2132 lines of code in 22 files (including data editor)

67.5 KiB (including 14.5 KiB image data)

Sunday, September 5, 2010

02 - Dwarves have stuff

I have added some finishing touches to the expedition customization window:

Now you can see how many points every dwarf has. Also, there is now a point total. And you can give a nickname to your dwarf. Let's give it a try and and create a nice starting expedition:

The first 5 dwarves have each points in one important skill like mining, carpentry and growing. 'f' Ooxk is a proficient mason, but also a fighter:

Together with my last dwarf who only has 8 points put into fighting, they could hold of an early attack on your fortress. Maybe.

This screen is mostly done. There are a lot of tiny interface improvements that I could apply, but I'm going to focus on some features first so that soon one could call this a game, rather than a tool for extremely interesting people.

On the bottom there are some new buttons and one of them actually works!

Clicking "Items" will lead you to this screen, where you can add items to your expedition. This is not fully implemented, but on the top-right you have your category selector. Again, I think it is important to see all the categories at once without having to scroll. And your items are organized in 44 categories. I barely added some items in the first two categories, and I am well over 100 items. It feels strange calling animals and food items, but I'll go with it for now.

Now you can add all items that you need for your first fortress:

That about does it! Two horses and some horse meat just to be on the safe side.

As for development, even as early in this project the code is starting to become table-happy. I have a table for everything and a large portion of the new code is dedicated to procedurally generating the list of animals and food and make it display correctly in the list. There are a lot of complicated distinction. It is not enough to mark an animal as "young", because a young dog is called a puppy and cows have cow calves and bull calves. And you can have meal made out of horse brain, but not rat brain, probably because the rat brain is to small and you would need a lot of rats just for one serving. Why bother when you can eat the whole rat for a much more nutritious meal!? I went overboard again with implementing the list again as in Dwarf Fortress, but I'll try to not do it again.

This approach with tables is not working. I'll leave everything as is for now, but for future items, I'll create and editor which loads up an external file and allows you to edit any object. This seems a good idea. Why have only one world with one set of fauna, flora and rules when you can have an editor that maybe you distribute to see what other people can create with it?

For my next post, I'll show you how it looks when your dwarves have arrived at destination, introduce the new "look at things" mechanism, and maybe talk a little bit about trees.

Statistics: 1050 lines of code in 14 files totaling 27.7 KiB of code

Friday, September 3, 2010

01 - DwarvesH: That's a $%^$^$@@@@!!# lot of skills

89!!!!!!!!!!!!!!!!!!!!!!!!!! ZOMG LOL $$&&%*&*!!!!

Dwarf Fortress has 89 skills! I knew that these games tend to be quite complex (and difficult), but oh boy! Not only does every single dwarf have 89 skills, they also have a series of extra jobs that they can perform. There is no skill linked to taking out the garbage or delivering goods to their respective stockpile.

When starting up Dwarf Fortress, you generate a persistent world. It is this world in which you will try to create a series of doomed thriving fortresses. But all journeys start the same way. You get an expedition of seven dwarves with different skills and equipment. You can choose to manually customize your expedition, and if you do you are greeted with the following screen:

This may seem daunting to a new players, but it is actually easy to use once you learn it. You press "F" to customize the name of your fortress. Press "G" to customize the name of your group. The rest of the screen is divided as following: the left part is the list of your seven dwarves and on the right you can see the list of skills for your currently selected dwarf. And then some other useful options. With this current screen size, I can only see 19 of the 89 skills.

Now let us see how my early prototype looks:

Wonderful. Spreadsheet: The Game! Now in 2D!

We got two input fields for fortress name and group name. Next to the input fields we can find two buttons with a "new file" icon. These buttons will randomize the names. I'll change that icon to something nice: dice rolls. Under you will find the list with your dwarves. As you can see, the names are both random and gibberish. I'll change the random name generator to something more dwarf like somewhere in the (near) future, but for now they are fully random.

On the right we have the skill sets for the current dwarf. All 89 of them. The game seems a lot more daunting when you can see all the skills at once. A new player will probably have no idea what to choose. I created small panels where I group similar skills together. There are also a few panels that I consolidate skills even if they are not directly related, like putting Alchemist together with metallurgy skills. It was really hard to compress the whole skill set in such a limited space.

The great part is that you can easily see and compare the skill of different dwarves. I'll be using the same dialog layout for inspecting the skills and job assignments for your dwarves during the game. Then it will hopefully be useful to see everything. When you have more than seven dwarves. 300.

Now let us assign a few points:

My first dwarf (I am not typing his name here) will be Proficient Miner, an Adequate Mason and a Competent Carpenter.

My second dwarf will be a Proficient Grower. Now I can switch on the fly between them and see what roles they each have. The point system that governs both your skill assignments and starting inventory is no where to be seen in this build, so you can bet that my third dwarf will be the life of every party (and work session):

There is a still a lot to be done. The life saving ability of giving nicknames to you dwarves is missing. The whole inventory and skill cap system is missing. But these are tasks for another day.

As for what direction am I going to take that is different from Dwarf Fortress, I will probably consolidate some skills to reduce their number. 69 seems better than 89. If I find that the depth of the game and the simulation has been harmed by this removal, I'll add a perk system. E.G. you are a sculptor. During character creation you assign level 10 to your general skill, and you can choose a single specialization. Like "Wood Sculptor". You can sculpt stone and bone, but you won't be that skilled. As you keep sculpting different materials, you will eventually get a second and maybe a third perk and you can sculpt everything with the same skill. I'm thinking that 12-20 perks would be enough.

And now for the statistics: I have 491 lines of code in 10 files totaling 12.8 KiB of code. This also includes image data, but said data is zero for now and graphical GUI data.

DwarvesH Development has started


And welcome to my new blog.

I will be using this blog as a development tracking tool for my new project, DwarvesH. The name is probably not going to stick.

I have a small problem: after starting a project, once all the fun and challenge of developing it is gone, so is my motivation of finishing it. I have dozens of projects which will never ever be finished. So this is one of the reasons for this blog, besides documenting the progress of the development: to keep me motivated.

DwarvesH is the direct started from scratch sequel to one of my previous projects, which was a browser based MMO game. My original idea was IMO good, but it lacked longevity and I’m allergic to long time HTML & CSS & JS exposure. So I’ll try to implement something similar to Dwarf Fortress: a city simulator with rogue like elements tossed in there for good measure. At first the two games will probably be very similar but I would like to give its own vision and mechanics. Maybe even replace the dwarves with something else. Like *shudder* not dwarves.

Anyway, Dwarf Fortress is great. I’m a sucker for these kinds of games. Minecraft also looks like great fun, and I still have multiple versions of ADOM somewhere on the disk (versions I never boot up anymore). So basically I love extremely complex games that offer a sandbox environment for you to explore. These games tend to be so complex that it would be very hard to implement them with modern graphics. But that doesn’t bother me. They also tend to have a very steep learning curve and generally lack on the ease of use department. I’ll make this the primary point of early development: make it as easy to learn and use as possible. Mouse support is also a must. So at first I’ll probably implement stuff exactly as I see it in Dwarf Fortress, but changing the interface a lot.

On important aspect is that this is a personal project. I am coding for myself right now, with no intention to sell anything or release the project under any form. For now. Maybe later I’ll try something. Maybe I’ll release it as freeware. Maybe I’ll charge huge amounts of money and never makes one single dime from it. Maybe I’ll release the source code and make it open source. But right now, I’ll be only developing once in a while and post on this blog about my progress. I would like to thank the developers of Dwarf Fortress, not only for entertaining me, but for giving me the inspiration to try my teeth on something like this. Also, if the developers of Dwarf Fortress feel that my personal little project (that could evolve in any possible direction) makes it harder for them to promote their own work, I'm open for discussion. But I think there is room in the world for more than one city/cave builder with dwarves inside.

As for the tools I’ll be using for developments, I’m thinking something like C++/C#/Flex. I’m not sure yet. I’ll start off with C++ and if I don’t like the direction things go, change to something else. Yes, there is going to be random rewriting of the whole thing. Or less random. Or even justified rewriting. But that is not that fun.

So I’ll leave now saying that this is just a big experiment. I hate writing documentation, but blogging about development is different. I hope I’ll enjoy it.

Maybe someone reads this later and finds something interesting. Maybe you were always curios on how something like this goes. Maybe you have your own little rogue like which you abandoned, or which you only work on once a year.

I’ll post later today the first post about the actual code that I have written (today).