Here is another half new features half pre-alpha polish post.
Map renederer moved to its own widget
The map handling class was getting very cluttered, so I isolated all the map rendering, cursor management and mouse collision detection code into its own class and widget. This was done mostly with copy and pasting, but with a slight redesign of the interface for this widget, I will have a very good general map rendering component that can be dropped anywhere in the UI. This way I will be able to create multiple windows with different functionality and GUI, but which all show the same map, by simply inheriting from this base class. I will be creating an "AI Playground" mode soon with this facility.
Mining code given the final polish
I talked about how I finished the mining skill and mining task last post. I went in again and made sure that it is well designed and bug free. During this pre alpha all the skills that I have in the game will start to affect their associated jobs. The reason that I am bringing this up again is that I am going to show the code for this task again. I usually don't show code here because I want to keep the blog non technical, but I have already shown this part of the code once and this is good opportunity to show how its complexity has changed over time:Task scheduling is basically the most important part of a game like this (together with path-finding). Nevermind the performance. If your dwarves are doing something stupid you won't care that you have 300 FPS. Creating one task can be hard, and there are a lot of tasks, several of which interact and have multiple phases. So I came up with the above design to handle these complex tasks. Every tasks has such a class. The implementation is fairly simple for this task which defines the wall dig operation and all similarly complex tasks have such implementations. Other tasks like hauling and building of structures area lot more complex, but the idea is to have one centralized place where the task is defined and if something is wrong to know where to search for a bug. There is one more phase, tasks resolution, which must be defined for each task and is not visible in the screenshot, because it is not part of that class. Task resolution and task filter for each task is the only thing that separates one task from another and all tasks are handled 100% uniformly.
Let me explain in two words the task again. The constructor of the task tell it to use my own super smart task finding algorithm and bypass A* when the engine feels like this would be a benefit. Then we have "TestDwarf", which tells us if a dwarf is capable of doing this job. Other low level bookkeeping, things that are general for all tasks, like if a dwarf is idle or has enough energy and other conditions are handled outside of the task filter. In this case the test boils down to the mining skill having the mining labor enabled. Then we have "IsValidSource", which is called for each candidate task coordinate, to make sure that nothing unwanted slips in. We test and make sure we only dig walls, ramps and built walls. This check is mostly for the UI and also a failsafe. The final method, "OnSuccess" handles the actual adding of the task to the dwarf. It is only called if we have found a worthy dwarf and a task that he can reach. We test again the task type with an ASSERT this time. At this stage there is no way this test will fail. If it does, the entire scheduler had a big bug somewhere and the assertion will warn me about it. Needless to say, it never goes off. I am too good. We calculate the energy consumption and adjust it by the mining skill of the dwarf. We do the same for the duration of the task, taking into account the material we dig though and the skill of the dwarf. And we are done! In the task resolution section we have again simple things, like clearing out the cell and placing boulders if we dig though rock.
I promise not to have a lot of these code sections.
Skill system redesigned
I redesigned the skill system to be more flexible and rely lesson hard coding. Dwarves can have any number of skills and any skill can have any number of labors. In theory. In practice, the skill set is well established and created with the help of the editor:
You can use the editor to create a completely different set of skills, but the game won't function with them because I would have to also move the skill logic to the editor. But it is still a good tool to do all non-structural changes and maybe in the future provide internationalization. Together with the special tile editor, the skill editor is designed to be used only by people who know what they are doing. All other panels can be used by anyone and won't mess up the game too much.
Basic help system
This is the feature that gave the name for this post: I implemented a little hint system that will tell you why you don't have access to the task designation buttons if you have selected something wrong. I'll let the video do the explanation:
Nice help system, this kind of hint helps getting used to the game mechanics, because you know exactly what to do to execute the task. Just one curiosity, will it be possible to remove these "example" lower levels?
ReplyDeleteWhat do you mean by example lower levels?
ReplyDeleteHi...
ReplyDelete...Sorry for bothering...
I just watched almost all your videos (including stress tests) and there is obviously no problem in running few hundreds of dwarves working simultaneously, Nice work. But as you said: This is not Lemmings... and I agree fully. I would rather see few trained specialists than 50 cloned imps.
I also like the names of dwarves (have you considered some sort of syllable-based name generator? I used it in one of my games and it worked pretty sweet). ((No, I´m not game creator, I am 3D graphic designer but sometimes I like to watch my things in motion))
You mentioned turn-based mode. I can easily imagine turn-based gameplay in the game like this, it would help you really sort things out. But first you should consider the depth you want to accomplish in the game (nobody wants to wait 345 turns before all the Lemmings reach exit) but i would pesonaly prefer turn-based system for very detailed (complex) game.
One thing i noticed in vids (maybe I am wrong) is that all the dwarves (i think it was in "building dining room" video) are waiting for one more dwarf (idle?) to come and THEN they all start to dig together. Also Diggers do consume more energy than idle ones, but the difference is so little it is almost not noticable (imagine lying on the grass and watching someone digging out 2 cubic metres of dirt).
actually the whole engine looks pretty "wavy" right now, but I guess that will change in a time... (by that I mean that nothing is happening until you mark walls to dig and suddenly all dwarves start to dig, then nothing, until you set wood-collecting spot and all the dwarves go to collect wood...)
Are you planning something like specializations for you Dwarves (also auto-tasks like farming, food-collecting) so that you don´t have to point them everything out?
Please, none of above is ment in a bad way, I greatly appriciate what are you doing here...
Kidly (sorry for still being anonymous)
P.S.: that playable demo was a joke :)
To Kidly:
ReplyDeleteThis subject comes up every time someone new discovers the project. Sorry, I won't be explaining it here in detail yet again. Please search though the blog if you need more explanations, but in two words: nobody is waiting. The game uses time compression to speed up long tasks. The game moves at a speed so the shortest task can be seen on screen. In case of moving, this is always the shortest tasks because it only takes a second or so to walk a cell. Every time someone walks while the rest are working will cause the in game time to flow slower. This was the only solution I found that did not cause some ridiculous side effect, like taking a step being 13 minutes in game time and still being able to accomplish a lot in a few minutes of real time gameplay.
Check out the rate at which the in game clock in the corner advances.
The whole system is not that easy to wrap one's head around because human beings are used to linear time. But in this game the speed of time passage changes, often multiple times a second.
If you need a comparison, image the game is turn based and one turn is as long as a dwarf needs to take a step. The game automatically decides how many turns to do when you press "end turn" if it can determine that in those automatic turns there is little of importance happening because everyone is working.
Also, the whole thing is "wavy". If you would do some graphical mathematical representations of time compression, it would look like a compound sinus effect. In my case the graph would not be smooth, but jaggy, but still maintain the dynamics of the sinus.
PS: The random name generator I am using is very random. I did not have time to write a proper one.
Sorry...
ReplyDeleteAs I can see I wrote it all wrong. I totally understand compression of time and i think you managed that very nicely... the game is not looking boring even when "nothing happends right now" simply because is speed-upped.
The wavyness i mentioned was to point to "why noone digs while waiting for idle dwarf to come" but i re-watchedd the vids and its probably because diggin takes lot more time and it only looks like the dwarves are waiting.
Sorry again, I will try to not write pointless posts again, peace...
Kidly
wow
ReplyDeletei think this is my favorite post yet!
out of curiosity, what do you mean with "and maybe in the future provide internationalization" is this about different people changing the options in the editor and then potentially sharing their respective choices?
now i'm really excited about playing this :)
Hi simo!
ReplyDeleteGlad you liked it so much! The editor is all about providing a simple to use tool so that people can edit the game rules and create their own mods. I can't wait for the day I try my first mod created by a fan that changes up things a lot.
But I'm afraid that the "internationalization" part only refers to using the editor to translate most/all of the game into a different language.
Fyi, i would money for this $$$
ReplyDelete