Game object systems

While designing a small engine for C# roguelike I've tried to figure out how to implement the object system. ECS (entity component system) is a typical way to handle it, but I don't like it. It's "simple" only from the surface, because the structure of code doesn't have to reflect the object hierarchy. You can add components (I would rather call them properties) to a base object class and that's it. No need to think about complex class hierarchy etc.

But, it's actually modeling the same amount of complexity anyway. There are people who always parrot the meme "use composition over inheritance" which I find quite annoying. If you think about a component, let's say a container. You would add it to a class and use it something like object.container.PutItem(); Yet, if you inherit from a container class and then use it like object.PutItemInContainer(); it's in practice the same thing. The only difference is that when you use inheritance you need to create larger and more rigid class hierarchy. I bet those parroting people never actually created a full class hierarchy for game objects, they just assume it's "ridiculous" etc. even it's simply modeling the same amount of complexity.

My guess is that it makes sense to use class hierarchy for things that don't change in the game object, and property/component list for external things that can be added and removed from the object. The roadblock in this design is that C# only implements single inheritance. Although you could somehow create such a simple class hierarchy that it doesn't need multiple inheritance by adding some things as components. It's a shame that Microsoft didn't include multiple inheritance to C#, because in my mind it is one of the core principles of object-oriented programming. It's like removing GOTO from BASIC language, because they think it's bad. C# does have interface, but I'm still trying to understand how it could replace multiple inheritance, because just by reading about it I don't get the concept.

I think it's a tempting idea to use a simple object class with component model, but I would rather accept the fact that it's a complex system and try to approach it that way. In OO languages it's quite silly to avoid actual object-oriented style, but that's what many people are doing. Then they complain that object-oriented languages are bad (C++ obviously the worst). Even though we have much less success from using something like pure functional languages in game programming.

Thinking everything

I'm in a middle of checking out gear use in Teemu. At first my plan was to remove items from inventory when they are in use, but then I went back to "Nethack" style where the item tells what use it's in. The difference is that you can do stuff like throw away your weapon and then you need to check out if it was part of a wardrobe etc. It's not as complicated as it seems, because you "only" need to check this in routines that discard items or change armour etc.

This falls in a category of "thinking everything" which sometimes is a part of roguelike programming. Rather than trying to understand how the code works you practically have to try out everything and see what happens. In Teemu it's even possible to eat away your armour. Creating a system like this can be both fun and a bit challenging, but I think it fits better in the style of this game.

Roguelike games in 2019

During the long span of development of my both roguelike projects I've been waiting for some great roguelike to appear, but it has not happened yet. It is a bit weird if you ask me, even there are many reasons why we don't have more roguelikes.

I think the numero uno reason is that they are difficult to create. I should know it, and I actually do. Even to have any kind of hope to release a major roguelike you need to grow up as a programmer if you already are not a good one. You need consistent planning and results that don't break up later.

But surely there are plenty of good programmers in indie scene? Well, my opinion is no. Open source and indie developers are in fact often even worse than professional programmers, who in most cases don't waste their time to roguelike game development anyway.

Another important reason is money. It is possible to make nice amount of money from game development, but it's easier to do with game genres that require way less time and work. Most game types are much easier to create compared to roguelikes or even traditional role-playing games (which are also quite hard). Some people are developing commercial roguelites which are light-weight roguelikes, because there is a market sector for them, but obviously they are not roguelikes.

Even after all these things I'm still puzzled about the small number of modern roguelike games, because I surely am one of the guys who would like to play a good roguelike game. There is ADOM, but it's a boring game with way too much grinding. DCSS is difficult and the developers seem to make it worse all the time which is quite hilarious, but then again it was never their own project as far as I know. The mindblowing thing is that we have games like Nethack as a great legacy, but building on top of that it would be possible to create far better roguelikes.

Code metrics tools for C++

This issue makes me somewhat annoyed when I think about it. Visual Studio doesn't have code metrics for "unmanaged" code which is C and C++ in particular. The reason must be that Microsoft doesn't really care about C++. They have to keep it for the vast amount of programs still written in C++ including game development, but there is less effort to include tools like metrics.

As far as I have searched there isn't a simple, free metrics plugin for Visual Studio, so there is that, too. There are some external metrics tools, but they seem like total overkill for what I'm looking for. I just would like to know how many lines of code the project has without running some external program. Visual Studio already knows how many lines an individual file has and how many classes etc. are in the project. It would be quite simple to collect that information and display it.

Programming a code metrics tool isn't impossible, but it takes some time and parsing C++ can be difficult sometimes, if you want to extract anything else than physical lines of code. I have written a parser that can find classes from a C++ file, so it would be a start. Maybe if I already didn't have tons of more important projects to do.

How about writing a plugin for Visual Studio? I don't know anything about it. How it's done etc. It can't be too easy, otherwise there would be a plugin to display C++ metrics I guess. Then again, maybe this is a non-issue in a sense that why would you want to know about the metrics of the project?

New workflow

I made a small change in my workflow and it seems to work like magic. First I moved all "note:" comments I had written in the source code (to find them "later") into a list of issues, so now the two most important lists are issues and bugs. Then I began to put a date in a fixed item to keep track of development pace. An actual example of a fixed bug from Teemu's bug list:

127. Sidestats drawing is not dynamic, has static locations (changed to offsets) [21.9.2019]

For some reason, doing it this way, is making me really focus on a single problem like a bug or issue. And when these issues were comments in the source code it was difficult to figure out what to do next. I guess in a list they make a bit more sense, because you can pick them in some kind of order. I try to fix major issues and bugs first, then less important. Also, keeping track of development pace by date on a fix gives a sense of progress, however small. If you can fix at least one thing per day it's still going to lead into something eventually. It seems like my pace is about 5 items per day which is quite nice, because there aren't really that many of them. Of course, the number of bugs and issues is growing when you test the game, but that's to be expected.

Dragonet

Taking off some time from my other projects and starting a new one. With this I'm going to follow different rules than before. It's a traditional RPG rather than a roguelike, but it's going to have some random things. The actual idea is in the implementation with these rules:

1. Completely class-based without public data (only public interface).
2. Inheritance first design.
3. Everything is programmed as a function to a required gameplay feature.
4. External data with parsed dynamic instances.

I think rule 1 is going to be broken in some places, but not inside classes. Mostly in global instances I guess. I think 3 will be an interesting one, because it's the opposite I've done this far. I've always added features without planning them that much and maybe it's one of the reasons I've spent a lot of time wondering how to put everything together.

Class design tool

I learned today that there is a class design tool in Visual Studio which took some years to figure out. It's not a built-in part of VS2019 but should be. Seeing the class hierarchy in visual level shows "problems" in inheritance very clearly. Although the class hierarchy can be anything you want, but often a tree-like hierarchy is better, from simple to more complex classes.

There are huge stacks of single use classes in both Kaduria and Teemu which looks kind of funny. I think with this new tool it's easier to fix class hierarchy and it's going to be my short term life goal for sure.

I don't yet know what to do with Teemu's github adventure. I actually hate github and source control, because as we saw anything can happen. I feel it's also unneccessarily complex system, but that's typical in the linux/open source scene. Everything is super complex and obfuscated for no clear reason.