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...

That pesky content - part 2

There has been a subtle but important change from engine programming to content creation in this project. A common misconception is that roguelikes don't require that much content, because they are random(ly generated). It's not that simple. Sometimes they do require a lot of content and randomness is only an extra layer on top of it.

An example is creating equipment for creatures. Today I started with helmets or headgear. For them the race and profession both determine the type of headgear. It's mostly the profession. Fighters and knights could wear a metal helmet, but wizards should wear a pointy hat. But if you always have the same decisions the gameplay becomes dull and predictable. There should be some kind of random variation, but in some kind of context. A knight could be wearing a crude helmet if he has lost his metal helmet and a wizard could be wearing a studded leather helmet. Helmets itself could have an importance value what comes to the decision how often they are created, because they were in reality the most important piece of armour.

The details of decisions can be complex and decisions or their "engine" itself are hand-picked content. More intelligent races and professions means more decisions. I already regret I made goblins an intelligent race like dwarves. Maybe they are removed or the amount of professions reduced.

Cloth armour fashion

Yesterday (Sunday) I had a headache that lasted the whole day. I took two regular ibuprofen pills, but they didn't help a lot so I took that day off. I tried hard to do nothing and almost succeeded in that. Today I feel much better, like almost sharp.

I've been reading about bronze age armour from the Bronze Age Military Equipment book and it has given me many ideas about how to use armour in more realistic way. Scale armours were probably most popular armour, because it allowed good mobility, enough protection and wasn't too heavy. Scales were made of almost any hard material. There were even bone scales and scales made of leather. It was also easy to fix a damaged scale mail by replacing damaged scales.

What I didn't realize before was that cloth armours were also very popular. They were usually made from linen that was layered even 14 times to create thick armour. You couldn't have endless amount of layers, because then moving became harder. Surprisingly, also felt was used as armour or more likely as pads.

Because I'm using more "realistic" physics I can use all those differences in armours to get trade-offs between mobility, weight and protection.

Bronze age style

I'm reading "Bronze Age Military Equipment" by Dan Howard. It's a cool book, because not only it tells about weapons of that age, but also how they were used and tactics involved in warfare. I was always thinking Kaduria will be low fantasy, but now I'm more convinced that it could be even lower!

Bronze weapons could be the main stuff used in combat, or even stone age weapons. The setting could be in between fantasy style bronze and iron age, making iron weapons extremely rare and efficient. This was the case in real life when metal weapons were invented. First they were used by only few, rulers and their elite troops. This historical fact could be a source of interesting weapon distribution where a simple iron sword is hard to find.

In fantasy context low fantasy doesn't mean there is no magic. In fact magic could be a noticeable part of the gameplay, possibly making it even more important than in regular role-playing games.