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.