The great SDL2 adventure part 2

After working for about a week it's not yet over. The core graphics routines are quite ok, but there are lots of external routines calling gui routines that were largely rewritten. I try to keep perfectionist thoughts away and concentrate on replacing 1.2 stuff with 2.0. There are some annoying stuff like data types of SDL mixed with C++ data types of Kaduria. SDL has a rectangle "class" SDL_Rect which is less useful than C++ (OOP) rectangle class of Kaduria. Yet maybe I should have had pixel rectangles as SDL ones in the first place to avoid confusion and conversion routines.

It's quite depressing to remove and rewrite parts of the source code you thought were ok, but that kind of stuff happens when some external library is changed.

Updating to SDL2

This is a good time to update from 1.2 to 2.0. It's not a dramatic change, but the GUI is refactored in a way that there is a new class Graphics_Engine which has low level graphics routines which then are used by high level gui class. It's not required to have it this way, but I think it's much cleaner. Only "atomic" graphic display routines are in Graphics_Engine, such as displaying fonts, pieces of static graphics, tiles and other simple elements. Then the higher level gui is taking care of displaying windows, tombstones, stats and stuff like that.

I guess it could have been possible to continue with SDL 1.2, but I think SDL2 is better. It has better support for alpha channel, full screen and graphics rescaling (which may or may not look cool..).

The story of level theme

Many roguelikes have static levels that have something I call the story. In fact even random levels have their own "story", but it's less obvious. Static levels or places have an important role to bring something special to the basic random dungeon generation style, but they themselves can become rather boring, because they are always the same.

Some games try to solve this by randomly selecting different elements for the static level. Sokoban in Nethack has couple of variations for each level of the sokoban branch and I think the artifact can also be either bag of holding or amulet of reflection.

In Sokoban's case the next level would be changing parts of levels to create even more variations of the sokoban puzzle, but I don't know if it's even possible. The hard core solution would be a random sokoban puzzle generator that would create the level and solution using no static parts whatsoever. It could be possible to write such a routine, but I'm guessing it's quite difficult to do.

The story is an essential part of a level theme and more detailed story is more interesting one in theory. Sometimes the story can be as simple as some special type of monster(s) that live in some location. There may be also some treasure you can find either by killing the monster or the treasure is hidden and guarded by the monster. Without a story the level is just a bunch of rooms and corridors you have to explore. Well, nothing wrong with that either, it's just not that exciting.

Trying to find the way to the next level of storytelling is difficult, because you want to avoid static elements but at the same time try to create them using some kind of random or semi-random technique. Quests, artifacts and special monsters are ok I guess, but there could be other type of stories as well, it's just a matter of trying to think hard what could happen in a dungeon other than that.

Build style

I have started this year with a critical revisit to level generation from the ground up. First thing to check out was the overall style of level themes and other elements. Each theme has information about natural rock types of walls, floors etc. and then a build style which determines tiles for rooms and many other things.

I had already made a distinction between natural and build styles, but some build styles were removed, because they were actually just the natural style of the level which means rooms don't have artificial walls, they are only carved into the bedrock of the level. Also an important change is the ability to mix build styles so not everything is made with the same style per level. There will be a secondary style for most themes and also possibly random styles which still fit into the current style.

The idea of styles is that they make the dungeon generation abstract. Then there is no need to think about individual tiles and their roles in the dungeon generation. Everything is reduced to abstract walls and floors, artificial versions of those and other things needed in the creation. You can then add a style/theme and the new level theme is done just like that, at least what comes to the style of tiles.

Rooms also have their own type, because some rooms are special. Still, even room data could be retrieved from the build style and it's probably something I'm going to do, at least for some room types. The difficult part in "generic" room styles is that many rooms are quite special and would probably require some heavy data so that each room type looks different depending on the build style or even the level theme. It's probably much easier to plan what room types each theme has and then design room creation only for those types.

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.

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.

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.