Update areas rewrite

There are rectangle areas dividing screen in parts and update each of them when their flag is set. At least with software mode of SDL this is a good idea, because it certainly does speed up the game compared to full screen update. Besides not only updates, the background graphics are also re-drawn when something happens in that area.

I've been refactoring those areas, because I needed to change message output to 5 lines and scrolling mode. The ancient nature of GUI was revealed when I noticed that almost all actual output to those areas were hard wired with another set of coordinates. So.. this is how it looks now:

Those purple dotted lines show the areas as debug method to actually see where they are. I already fixed the small map, but as you can see the gameview is in wrong place and stats also (and some areas itself), displaying only the last line: Water. This is a minor fix however. From now on the content coordinates are retrieved from the area data only and in future I can easily change the locations of areas if needed. One possible option I can think of already is switching the places of location (bottom line) and messages.

When it's done

The first item of 10 hour todo list was easy. Then I realized before doing anything else I have to fix the message routine, just like I did for Teemu. This time of course I can use new parts of Teemu's routine, but even then there are work to do with Kaduria's message system. Like with level generation I once thought it would be nice to create a complete engine for messages, but it became too complex and unwieldy for what it was supposed to do. So, rather than trying to make the system work in one way I'm using several different ways that all ultimately use the core routine.

People often ask when Kaduria is ready. It's getting annoying. For a long time I've planned to release the game without telling anyone. Just download the first version in the homepage of Kaduria and let it be there until someone finds it. Let people keep asking when it's released and all the time it's there.

News

I have a new plan for Kaduria which is choose some items in todo-list and give them an id and estimated development time. Then follow that order and try to implement them. It should be easy and I already chose ten hours of programming for nine items.

Some items can't be implemented without knowing stuff related to them. It's the difficult part of game programming when you don't have a detailed plan or you don't yet know how stuff is going work with other stuff. It's also something I have to concentrate on better.

Those 9 items are about 20% of all unfinished items in the list, not counting level themes. The reason for that is that level themes are too big to be in todo list anyway, first they have to be broken into smaller pieces, because many level generation techniques are reused in other themes. That 20% is not accurate also because there are more "todos" written in the source code directly.

This new plan should be better than just looking at the source code puzzled what to do next.

Quest for Avatar

Avatar, or the player class, is derived from Creature class. Then many functions can be used by the Avatar, but sometimes or more like usually it needs a check if the Creature is the player and do something strictly limited to player character.

It's a perfectly valid option, because it can work without problems. Still, I wonder if it could be possible to use Creature class "component" of the Avatar without Creature knowing about the derived Avatar. I guess what is often done is a common class where both Creature and Avatar derive, but it seems a bit difficult to implement. You can also use more generic Creature functions that return information to Avatar class which then decides how to process the data or whatever.

It may sound like this is irrelevant in game programming, but I have noticed that when I improve OOP features of my source code it also becomes easier to understand for me. And sometimes the result contains improved gameplay features as well.

I'm also more experienced as programmer to handle that kind of thing now.

X marks the spot

The question of terrain or level topology is easy as it is hard. I can make a level theme incredibly fast with the current data-driven engine, but somehow those themes don't satisfy me as they are. Levels need more details and also variations that should be difficult to predict. The slightly predictable level themes in Nethack (and other roguelikes) was something I wanted to fix with this game. But creating such levels is not easy.

Back a while I let go of strict data-driven approach and added special level themes, but at the same time I feel the data-driven code can do more and it already does when I added a special-ish level theme containing lots of lava. If however the data-driven system can't create all stuff needed in a level theme it has to be removed and used a manual generation instead. Hopefully most level themes can be created with the engine.

Even getting all level themes in some kind of physical form seems to be difficult, but it's something that should be done now, because you need levels to navigate in the game world and interact with game objects and since climate and other features play such an important role there must be different kind of themes to try out to see how easy or hard they are simply as terrain.

Refactoring Menu class

Menu class itself was surprisingly easy to change from raw text data to std::list. Item menu was rewritten earlier so I skipped checking it and moved on to refactor "regular" menus with simple text as items. It took a day to change all menus, because the constructor parameters changed and now you didn't pass a text buffer to menu but items one by one as const char data.

The data for menu items was available in data structures of most data-driven stuff so it made the source code better, because all those temporary text buffers were removed. The game doesn't actually have a lot of menus and most of them were mainly in debug routines.

I had a good feeling when I programmed today and hope it continues. I also think the best way for me to manage this project is to make a focused plan of something and then try to concentrate on it hard. It gives good results fast when I know what to do.

Refactoring Window class

As a part of quite important menu refactoring Windows class had to be refactored. There were two classes, with regular and small fonts. They were merged into one. The resulted class was easy to refactor per se, but several windows initializations had to be refactored.

It's done, but something went wrong (as usual):

The window displaying help of option went bananas. I'm sure it's quite easy to fix.

The important refactoring is in the Menu class. It's going to be harder than this, but it has to be done. You would think there can't be anything left to refactor in a project like this, but you are wrong. The current Menu class is using simple text data with hard-set amount of items and a pointer to char* buffer. It's bad in several ways. What I need is ability to display each line of text in different colors (sometimes) and to do that you need a list of objects with text data and font color.

Fortunately I already have it, the Display_Message class that Message is now using to show a message. It's not designed for this, but later it can be replaced with any other class of same type.

Sometimes the menu list is changed, for example if you drop an item from inventory and that also is improved with list where only the selected item can be removed. With static char* buffer you need a complete re-build when the list is changed.

Later it could be also possible to create direct item menus (simply a list of items) without using a text based copy.

Let's hope I get it right this time...