Engine programming

Another three weeks off, but now back in the saddle. I have now a better idea how to proceed thanks to the master todo list I did earlier. First I have to finish some parts of the engine, which at the moment is the new save/load game scheme with the idea of keeping everything in memory rather than saving temp level files. I actually don't know how much the game will spend memory once every level is constructed, but I guess it can be monitored with a crude debug routine telling how much one level requires memory.

I'm also changing the "old school" way of loading game when you enter the character name and replace that with slots for save games. There is a limit for slots, but I doubt people will run out of slots, because usually there are only few open games.

The new save and load is actually going to be quite easy to do, because the "level node" structure is already stored in the world class. It may be as easy as adding a level handle to each node and when that node is entered the level is created. Each class can more or less save and load itself so that wont be a problem.

Graves & Tombs

Let's make this clear. Grave is a game object that contains buried grave items. It's either mound type or a tomb. Sign class can be a sign, but it can also contain a Grave_Stone class which has extra information about the grave in a form of cross or tombstone and it's a separate object created next to grave. When Sign class is a plain sign, it has a Scroll class data. And finally Item class can have a Scroll component if the item is a readable one.

Now the only (hopefully) thing left is how to determine the grave type. I think it could be easier to do by using monster type as the main data and determine grave and gravestone styles from that information. Then you can create graves using monster type as a parameter and everything else will be determined from that. Only that there may be problems with so called ancient graves where the monster type can be something strange, but maybe that monster type could be actually created as a monster never seen in the gameplay.

It's possible to go detailed about graves and what items there are buried, but I try to avoid that in the first version and try to keep things simple.

Scroll in the grave

Grave texts were earlier in a Scroll class. It's not that confusing, because texts of scrolls and graves work pretty much the same way, they only have a different kind of graphics background. What I wanted to do is get rid of extra data for graves in the Scroll class, since scrolls only have relatively simple text in them.

When I was refactoring I realized it would be useful to have a basic class for handling text pieces needed in scrolls, graves etc. with several display options and parsing routines depending on the data.

I guess it was the only good thing that followed this refactoring, because in the end I realized that I had only shifted the problem of gravestones from Scroll to Sign class. Signs on the other hand have also simple text data as scrolls, but they also include graves. Of course, I could create a new class for gravestones only, but adding a new game object type is anything else than trivial. The game object system is quite unwieldy and requires another set of features in Level class. I doubt it will be worth the trouble.

The solution is include gravestone data as an extra member of Sign class, just as it was in Scroll class. I guess it's anyway better than gravestones being 'scrolls' as they were before. Signs and gravestones are similar enough that they can share the same game object type, but it's a bit annoying to have that extra member which is 'empty' when the sign is not a gravestone type. I don't want to think about a tomb which is a Grave object type, but also a Sign, or rather gravestone. Or is it just a grave?

The curious case of a feature

I've fixed couple of features and it's as awful as I assumed. Yesterday I was able to partially rewrite a new lighting routine for static lights (that don't move). The light falloff is linear which can be fixed later, but the main routine for lights is ok I guess.

Sometimes fixing a feature will introduce new features to fix which in this case is a peculiar problem related to facing of walls. The lighting routine can lit the wall from the "wrong" direction (depending on where the player is), making it lit without visible evidence of a light source. This is somewhat common problem in tile-based games with more sophisticated lighting scheme and I have to find some kind of solution for it.

The plan is to stay with technical features and when they are done everything that is left is the RPG system.