Searching

In order to search you need to have something hidden. Traps and doors are obvious... wait, doors aren't obvious. I have problems trying to figure out how to hide the door. Will it look like a wall? How is this wall tile handled, is it a normal terrain map wall? What happens if X happens to that wall (which isn't a door). Stuff like that.

Then there is an issue with hidden items. At first they were in a special list in the level, but I realized that handling hidden items will be more logical when they are inside the object which is hiding them. So, in order to get hidden items feature I have to write (possibly) a virtual mechanism for them, adding another type of container for hidden items. It could be easy now when container ability is ready, but you never know.

I'm also planning a data type for the search routine. It will continue the style I've been using in data-driven types. I have developed a certain kind of routine in programming for them so the data type will be quite easy to do, but it's always a matter of how it will be used in the rest of the source code. Programming data types for stuff like that may sound strange, but I'm always trying to reduce switch-case programming, because modular data types are so much easier to extend when you need to add something new, and they are also modular, meaning that when you get that module ready you can pretty much forget it and focus on other parts of the source code.

Rooms again

I left plants for a while and returned to room problems. Back in January 2009 I was writing about connecting the interior and room structure in the same class. Well, it was something like a mistake. Now I realized that it could be easier to start with basic shape of the room, then add wall and floor data (room data in general) and then create the interior when everything else is done. Without that there would have been room types for all shapes and interior types for no particular reason, creating a long list of data for all possible combinations.

I also have had problems to create and connect the rooms, but I think I have a plan for that finally. I will let rooms be created in any place possible other than overlapping the room floors with another room. Then work out connections either by creating holes on walls or using corridors. I have already planned how corridors would always work perfectly without ruining the room structure, but at the moment it's only a theory.

I have found room placement so hard to do that I actually made the dungeon levels work entirely without rooms, using natural caves as the base of dungeon generation. Rooms are actually something extra carved to natural caves and it even feels realistic.

Let's hope everything will work this time. I don't want to look back in 2012 and say I was wrong (still refactoring the room and corridor generation).

Fertility factor

I made a simple routine to simulate ground plant growth. It's calculating the fertility factor for surrounding tiles and then growing a plant or if some type of growth exists it's growing it to the next stage. The result from such simple simulation is actually quite nice. Here is the situation after one iteration:

And this is the same place after ten iterations:

As you can see water gives better fertility factor in pretty much natural way. Now after this is done I can start to implement the plant object generation (these are just simple terrain tiles) on top of that. The great thing about this is that the routine can be run again and again. With large values everything will change to thick swamp, and with plant generation I'm already dreaming of forests that will be properly tuned for temperature conditions, creating jungle or cold/dry climate forest. All that without any kind of static or pre-determined routines. Just some rules for growth and iterations.

Bugs of Kaduria

The current version 0.4.9 has three known open bugs:

16. When throwing item against a wall, it hits the player (z-location problem in collision detection)
13. Top area flickering when message shown
3. When in fullscreen SDL aligns all open windows to right side of screen (remove fullscreen option?)

Each of them are kind of hard to fix. Z-location problem is related to how the game sees the z-direction (depth) and it's an issue that needs either manual fixing or a big rewrite of engine to actually support third dimension (even the gameview will stay 2-dimensional). Bug #13 is annoying, but could be easy to fix. Bug #3 is SDL related and can't be fixed by me. I noticed that when I exit fullscreen every open window is moved to right side of the screen. I hope there will be new SDL version to fix that one.

The total bug count is 28 for 0.4.9. I try to fix bugs when I find them and keep the bug count low. The release version will hopefully contain zero known bugs, just as in Teemu. I think it's doable and the current situation looks quite good. The engine seems to be stable and there haven't been crashes for a long time actually.

Level connections

The level connection routine is now ready. There was a confusion with connecting proper ids since stairs (or more like nodes) have their own special id unrelated to object id of stairs.

Each stairs have a sign that shows where you are now, but I think it could be useful to show where the stairs lead. Maybe even both in the same sign. There could be some variations like unclear signs or no sign at all with special stairs.

Environmental thinking

Terrain data needs to be refactored, because there are duplicated stuff for it. I probably need only main type for terrains and data associated to different things related to terrain actions. Terrain part has been difficult in Kaduria, because terrains used to be a lot more complex. Now they are just piece of dirt or water etc. But you can't underestimate the complexity of terrain actions since they play such a big role in the gameplay.

If I ever make another roguelike of this magnitude I will certainly make terrain tiles objects that are derived from base class just like all other object types. That would have made things much easier from the beginning. The distinction between objects and terrains cause a lot of extra work.

I need to clear the confusion in terrain part of the source code once and for all. I think it's good to start from the main type data and see what can be included in that, then move to terrain type class. I think this is the task for this weekend.

The cheese hits Shamino

That's the message I got when I threw a cheese while standing next to wall. So it's not yet there, but almost! I'm happy that I can now navigate through the dungeon, although the level saving doesn't work yet so the game is creating a new level every time. And rooms are taken off momentarily so it's only caverns and corridors.

May sound funny, but I'm excited when I get simple things done like entering a new level or throwing an item. Well, "done" in a way that you can see something happen. The final routines are always much more complex but I'm not thinking about that now. I want to get simple working versions. When I get most of basic functions like throwing, kicking and basic combat I want to make a Youtube video from Kaduria's gameplay. I think that will give people some idea and prepare them for not being too disappointed.

Level node connections

I now have a registered VS 2010 Express and it's cool. I really like the real time error check which shows errors in red underline. You don't have to compile the file to see obvious errors.

I used same kind of level connection routine that I made for Teemu, but instead of connecting themes I used level nodes which I actually programmed earlier. I wasn't just sure how to do the connecting until now. It may sound odd, but this thing was bothering me for a long time and I was unable to navigate through the dungeon, but now it's quite close. I still have to write a complete save and load routines for Level class, because there is going to be only one level in memory. I made that kind of decision, because then I don't have to worry about the size of the dungeon which is going to be gigantic. Of course modern computers could in theory keep all levels in memory, but why stress the computer with that, when the game is going to use one level at a time anyway.

I'm really happy with the current situation. The source code is becoming cleaner and I know what to do. Just wait and see, it's going to be an end of damerelling me about this game.

Project recovered

I think I found all files of Kaduria. There were of course more than just tiles, like fonts and misc. graphics. I remember that there was external data only for the precalculated light maps. The latest source files were recovered from a single source, that was exciting. The previous sources were stored month earlier. I don't know what I was doing, but now I'm going to make backups to everywhere I can. I think the latest source was really the latest and I don't have to do anything again, like I have to do with Stile where I was able to recover only the release version (0.82) sources while I had continued it later.

Now I have to wait what happens with VC++ registering which failed, because M$ registering message doesn't get through. They should fucking mail it as a real paper letter. I just need the registering code. Meanwhile I installed Code::Blocks but it's a temporary solution. It's a beta/alpha project and even years older DevC++ seems to be more stable. One of the great mysteries is why they didn't continue the development of DevC++? Just couple of tweaks (better search options like 'find by reference' and internal book keeping of source files) and it would be a great IDE. What the hell  have the developers been doing all these years?

Tiles recovered

I always make backups from the source code, but in case of Kaduria I didn't make frequent backups from tiles unless I changed them. Luckily I had just recently copied all tiles on my workplace's computer for some minor adjustments so the latest tile set was recoved from there. Also, I didn't make backups from static data, but that also remained unchanged and can be found from somewhere, I think...

Refactoring dungeon generator

I have a new idea how to create good navigation options in the dungeon layout. Navigation logic is important when you create something more sophisticated than just random rooms. I'm also starting to have an idea how to combine all types of dungeon features seamlessly together. Not all features are needed in all level thems so it must be possible to remove a feature without confusing the level generator.

When I get that working it's time to add plants which are the next logical step in the dungeon generation. I already created a system for plants that are used both in creation and real time plant reproduction. The idea is let plants grow and take their place, possibly struggling with other plants. Light conditions and the type of soil would affect the plant growth. I'm interested to see if it actually works.

Load and save

Now when Actor class is refactored out I can continue writing save and load routines. Most of object types already can save and load, but some of them still missing. I'm using my world famous Tar_Ball system (developed for Teemu) in save/load. It's not beautiful, but it gets the job done.

The big question remains whether to save per level or keep all levels in memory. Kaduria is going to be a graphical roguelike for modern computers which can handle the memory requirements, but then again it could be cool to keep memory use low. Levels are active one at a time so there would be no need to store all levels at once anyway. Saving a level for first time is revealing, it can be estimated there how much memory one level spends.

Game object rewrite

Placing a wrapper class Actor between the base and derived classes was not that clever after all. I wanted to give Opener and Container ability to some object types through Actor, but as usual when something may seem like a good solution it turns out to have unexpected problems.

The problem with Actor was that it didn't know about derived classes. In actions like opening something there is more involved than just the component data of Opener class. Different openers act different ways. So the rewrite is about removing Actor and moving Opener and Container classes as components of derived objects. With that approach you can't avoid copying code of virtual functions. Good thing is that the code is short, because of functionality of component classes. And more importantly you get to write individual opening code for each object type, checking out things that belong to the derived class.

Like for instance there are doors and sewers, both openers. But sewer is really a different thing, because the lid can be missing! So, using virtual Open() for both door and sewer have same type of code for Opener section, but there are special things that only certain object types have. Also, when you have virtual Open() it's going to be easier to handle, because you can use the base class handle for opening action.

I think the cost of using virtual functions is not that bad when compared to difficulties that follow with extra class in middle of the class hierarchy. I believe the rewrite can be done during this weekend, so it's not going be that hard, even though it is kind of a big change to the game object system.

Abstract base class

So, I finally made the base class of game objects abstract by making Get_Weight() and Get_Material() abstract. There was no problem in instance issues, because the class was already used like an abstract one. But I was surprised how many member functions of Get_Weight and Get_Material were missing from derived classes. Usually it's ok, because you just return some generic value for weight and material, but in this case the values were not good. You need the proper values from each object type. It was really good change, because at the same time I wrote missing data for some object types and now weight and material have correct (mostly) values for each object type.

The third essential value is size, but I have still problems to create a generic enough size table for objects. I decided to go with abstract sizes like small, huge, etc. instead of metric sizes. This was simply because it's incredibly time consuming and difficult to get (or imagine) proper metric sizes for objects. I can also use the size as least important factor in physics calculations, because I guess that's what it is in real life also.

I really need to compose myself and get the fundamental object data ready for action.

Level node connections

I had planned the structure of the game world on paper (that was a while ago) and finally wrote the data for level node connections. It took about one hour. It's not that the game world of Kaduria is big, it's actually not, but there were some number of level themes to connect so it didn't happen fast. It's not over though for the connections. I still have to write the actual entrance creation code based on that data. It's not easy, because there are special entrance types that need to be there in the level theme. I'm not talking about the stairs itself, but the places stairs or other entrance types are sometimes hidden.

Save and load

Implementing save and load routines for the level. I want to be able to move around in the dungeon and can't do that until the level can be saved and loaded, because there  is only one level in memory at a time. Reason for that is probably just my old fashioned thinking, but then again one level of Kaduria takes surprisingly lot of memory. I want to keep the memory footprint small just in case.

Programming save and load for Kaduria is more difficult than in Teemu, but I'm actually using Tar_Ball technology I made for Teemu. It might be ugly, but it's working and I have it ready for action. Someone might argue that I should use "real" serialization, but I want to keep some kind of control in save/load so I know exactly what goes in and out, and when.

To keep things simple I really need that initialization in U_Actor's constructor I was talking about earlier. It's really easier to properly initialize the object so you can then load the values, rather than go too shallow end in the class hierarchy. U_Actor is going to keep me busy for couple of days, then there are derived classes like monster, item and the player's class.

Other than object data should be a lot easier to save and load. I'm really happy if I can make this all in let's say three days or something like that. Then I can navigate through the dungeon and see how it looks.

Small rooms

The problem with passages was that it had another bug that made the passage routine exit before it had reached the destination. Now it should work. Added more round rooms and small rooms. Now we're getting somewhere:

I think it's something I wanted, but it's going to have some stuff added before it's ready. The important thing now is fix the corridor routine between actual rooms. I have no clue how it works at the moment. It's supposed to connect closest rooms, but look at that long corridor made across the level. Not what was planned. Looks like the connecting logic is broken. Also looks like one of the room is left without connection.

The connection logic is more complicated than it appears, because you can't just connect all rooms from one to another. It will create a messy web of corridors. It's better try to connect closest rooms and then create additional connections which connect every room together in some way.

Passages

The slowness of cavern creation was actually a bug in passage routine (a simple corridor). Also fixed small room bug that gave wrong locations for rooms, now they are created again. There is just one problem with passages:

A rogue passage not connected to main dungeon. You would think this kind of routine is easy to do, but it looks like you can fail in that. I mean how hard it is to draw corridors between caverns?

Then there is that issue with round rooms and corridors that can't find a proper wall. Guess I need that pathfinding for corridors after all.

Caverns revisited

I'm refactoring cavern class to create more natural looking caverns. I tried to use Teemu's source code for that, but caverns in Kaduria are much bigger and needed other type of strategy. Then I noticed that I could use Area class to create caverns itself. It almost worked right away. The neat idea in flood filling was that I'm sometimes using 2x2 seeds to make the shape more irregular. Damn it's slow, but look at this:

The round things are actual rooms added after caverns. They don't have corridors yet. The passage routine between caverns is actually buggy, but I guess it could look ok after small rooms (to be added later), because small rooms attach themselves in free areas just like those loose corridor ends. I like the result, although those long straight corridors don't look that good. Maybe this theme needs more caverns after all.

Messages

The dungeon generator of Kaduria is such an entity that it's hard to keep it in condition. When something is changed the generator can go bananas. This is what I got today:

It's trying to create a room in bad location, but it can recover from that and doesn't crash. I've made the map routines check out of bounds internal so it can't fail that way, but there can be areas that are disconnected. There is still some serious stuff to do with corridors and how they are connected. Corridors are always the problem.

Actors

Solved the init problem with Actor class by using late initialization in derived classes. Actor is in a middle of class chain and has no information of derived objects until they are initialized. I don't know how bad that is, but I can't see any other solution for this. You have to know more than Actor knows to determine which object type is a container or opener. One other solution could be pass that information as constructor's parameter, but it's pretty much the same.

It's almost done now, the only thing missing is determine which monster types can carry items. It's already in monster data and for that I have to add one check to cover it.

Creatures

Lately been fixing artificial intelligence using data-driven building blocks. This is one of the areas that needs most work, because I had only basic moving for creatures in early versions. In fact I have disabled AI and creatures just sit there, waiting for the programmer to do something about them. I'm glad if I can fill all the missing information in about two weeks and then begin to write the executive AI routines that handle the vast archives of creature data.

Notes

I may have talked about this earlier, but I have special comments in the source code starting with word "note:". Those parts of source contain a problem I have left to solve later. There are now 74 notes. Most of them are hard to fix and today I pretty much fixed one of them, which involved adding stuff to Score class (which I was talking about in 2008 blog entry). Fixing "note:" problems is as important as anything else in the source code, but they have been difficult to handle, because of generic difficulty or that something is still missing, like serialization which I now can handle, thanks to important experience from Teemu's serialization.

Containers

It's almost month from last entry. I really feel I have now control over containers and there is not much to do with them anymore. Writing container code is hard, because of ownership issue which can be quite complicated in a large scale program. Well, actually it doesn't have to be complicated. I made the usual mistake with container class and tried to give it to too much responsibility. It's easy to think that giving class more functionality will make things easier, but it's not always the fact. It will work only if the class will  handle things that belong to it. Then it doesn't matter how simple or complex the class is.

The annual 7DRL madness is going on, but I have my own battle with Kaduria. They can lose the battle and retreat, but I have to push onward to victory.

Restoring the gameplay

I had a creativity boost when my internet connection was down couple of days. The development is shifting away from engine programming to gameplay programming. I'm restoring and re-inventing the basic gameplay functions like digging tunnels, eating food, harvesting crops and things like that. The engine is in good enough condition so I'm not that afraid to add functions that could be written in more generic way. I'm really tired of trying to create a perfect engine.

I guess it's fun to see that you can finally do things in the game and see what happens, and fix possible problems. There is still a lot of things to do in that area, but it feels like whatever I'm doing now really can be detected in the game as real playable content. In a way the development of Kaduria has just started. I would add a smiley here.