Wednesday, 30 December 2015

Plans for year 2016

The coordinate saga is complete and I guess the results were worth it. At least now I know it's not that difficult to expand the class hierarchy.

It's always great to plan stuff for the next year and then not get them done. But anyway, I hope in 2016 there will be more content and less engine coding. Level themes require a lot of work, but maybe it's less difficult than I think, because the vast number of existing techniques to create levels. It's more like combining those to create different kind of themes. Although I need a good labyrinth and town generator routines.

Next big task is the RPG system. Thinking of approaching it by creating interactions between game objects and the game world itself first, then object vs. object interactions. Exactly how to combine pseudo-physics to more traditional RPG rules is still a mystery. If it fails, it's always possible to degenerate to a traditional system.

Friday, 25 December 2015

Why location is a great idea

So it turns out that I really need the location data in the base class to make life much, much easier with game object messages. And with other things as well.

Of course I did change quite a lot, but it's not that bad I guess. What I will keep is the Mover class, nothing wrong with that. It just makes moving possible to proper classes. Yet the base class should have the location data for above reasons. You don't have to save the location, it can be reproduced for objects that are only in the map.

I hope I get this mess resolved fast, because it's getting on my nerves.

Wednesday, 23 December 2015

Recovering from game object hierarchy change

The main problem in the reduction of base class from location data were all functions that were using location. I'm really glad that there aren't many of those. Mainly the way objects were able to set their map frame by themselves and in other miscellaneous routines such as traps that had built-in routines for triggerers while it should have been the other way round by the design which means the action happens in the triggerer's class and the trap is simply providing data for what happens.

Even the number of routines that need fixing is relatively small it still takes some days maybe to fix them all. Traps are also a special case, because they can be triggered by other moving objects than monsters but there are no routines to handle those other movers. It could be quite nice to give at least some degree of functionality to things like barrels pushed on trap and then the trap is making some stuff happen to the barrel.

The most complex and time consuming routines seem to be interactions between game objects. Traps are the easiest one to handle while digging seems to be extra hard when everything can be interacted with the pick-axe.

Still even with all this hassle I think I made a right decision to reduce the base class and make the inheritance chain contain more classes that handle their particular task. It's going to make things easier in the future when all things are more or less where they should be. And it's also going to reduce both memory consumption and save game size.

Friday, 18 December 2015

Refined game object class hierarchy

This is again a bit technical blog entry, but nothing new here. For long I have been cautious to not use inheritance as much as it would have been possible. A complex class hierarchy certainly has its own features to watch out, but now when the level map has become more of a owner of instances it was time to try something new.

The main problem with too simple hierarchy is that the base class may contain data not needed for all game object types. It's an easy way to handle objects, but with cost of having "empty" data for in fact most game object types.

I have learned to avoid big refactorings so I started to move routines from the base class to a new class one by one and then compiling to see what happens. The new class is called U_Mover and as name implicates it handles moving. It's sitting in between the base class and three derived object types: item, movable (objects that can be pushed) and monster(+player). Only these object types move so it's obvious that you don't need specific location data and move commands for other object types.

The surprising thing about this was how base class continues working as if nothing had happened. It's of course quite easy to explain by rigid use of the public interface. The biggest change was in a template routine that used to fetch the object from a list with Is_Here() function. Since it was moved to U_Mover it stopped working for all other object types. But it was about to change anyway, because the tile class will own objects that don't move. Even moving objects have a pointer in the tile class for finding them quickly without having to browse through a list of objects. It's still uncertain which object types should be stored in a list and which ones could be owned by the tile class, but it will be decided later.

Sometimes a list is better or even required, but it doesn't have to own the objects. It can be a quick way to scan through objects without having to visit each map tile of the level.