Class hierarchy of game objects

The structure of game object classes is something I'm going to rewrite, maybe before source code release. The problem was that I believed the "common" knowledge that you should avoid inheritance and especially multiple inheritance in C++, and use components, not only as in component based approach but as datatypes inside the class. But if you are using classes and OOP, then what is the point of that? There is no point and not only that it has made the game object tree quite difficult to maintain.

But what about things like the dreaded diamond? It is a silly thing to dread, because any advanced programmer can't make that kind of simple mistake in inheritance. The real difficult thing is the class hierarchy itself, because you need to make independent branches that don't rely on some base class data if the class is not inherited from "main" branch.

How you split classes is part of the hierarchy problem. For example if you have fountains should they be a separate class that has water contain ability or should they be a part of some more generic container type class? The way objects behave is I think a good way to split, but even then some features are more generic than others. It's not easy to create a well behaving class hierarchy, but it's certainly not impossible or something you should avoid.

I think when people go for solutions like component based design it's a solution to problem that never existed. The way OOP works is just one way to do things, that's it. If you want to do something else, that's ok, but it's irresponsible to create assumptions about OOP that are not true.

Descriptions

Every object in Kaduria has some kind of description of what it is. Some games have descriptions for monsters, but often not much else. I think descriptions are a nice way to clarify what the object is, because it's not always obvious. I know this myself, because I'm not a native speaker of english which is the de facto language for most roguelikes.

It's a good guess that descriptions are also a problem, because it's surprisingly hard to write good descriptions if you have a large number of objects in the game. I've mostly tackled that with kind of comical output, because it's the easiest approach in my mind. This is also something roguelikes tend to have, maybe for that same reason.

Item descriptions have been a stark reminder why it's a bad idea to create large amount of items before cementing their data structure. Kaduria doesn't have a impossible amount of items, "only" 233, but it gives plenty of work when something changes. In this case copy-pasting descriptions from C++ files to external text file. It's not even 233 copy-pastes (you can try that line by line from some random text file and get an idea) but also cleaning the source code's struct data after that. Lot's of selecting by mouse and deleting with backspace.

Some of the descriptions aren't yet written, so it's even slower than that. If there is something "technical" in the description it also has to match the game's features. Which in some cases is not yet there. Both items and monsters are a great example of overdoing and lack of planning skills. What you should do is start from a small number of items from each item/monster class and work with that before adding lots of them.