Tuesday, 24 March 2020

Bullet journal

I started a bullet journal over a week ago. It's not for planning, but in practice a diary with one liner explanations of mostly "important" stuff done, including game project entries for each time I'm working on them. I can't plan for the future, but bujo is making decisions easier to do, because each of them is a branch that takes you closer to some goal, or not.

It has already revealed that my life is quite boring. I knew that, but when you look at the entries back in time it strangely becomes more tangible. The way you can "plan" is change things, create new type of entries with activity that is somehow different than before. It's also forcing me to do at least something each day, rather than fall into my default mode which is watching youtube videos.

I think this is really nice tool for roguelike developers for sure, and it's something I wish I had figured out much earlier. Like most of the things anyway. I guess you can write journal to a text file, but my bullet journal is an actual physical notebook.

Tuesday, 25 February 2020

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.