Abura Tan SM

This is an old roguelike project by Michael Blackney from 20 years ago. I refactored this in 2009 to SDL (1.0 version), but I think it's time to take a look at this again. It took couple of days to make changes for SDL2 which does have more differences than I remembered. Also for the join-macros I had to turn on "standard" macro property from Visual Studio and replace file finding with std::filesystem.

It does run, but I can't see anything. Possibly the font routine doesn't work properly, because if I replace the data with some random fill color you can see blocks of them on screen. The source code is the kind of C++ you never want to see. It's overly complex object-oriented style and has some annoying features like returning from each case label, leaving out breaks and the last return from end of the function. I think there are also user-made list and string classes which is always great fun.

As I remember it also has a bug which displays the level over the message area, but when the font routine is fixed we'll see if SDL2 fixes anything (the screen update works different way compared to SDL). But if I get this to run properly it might be an interesting project. This I'm going to upload to my Github which at the moment is empty. I need to use an external Git gui rather than Visual Studio, because I don't want git to mess up my projects. Git is awful to be honest.

The Object Class

I'm working on a new project which is going to be more like a traditional role-playing game. The nice thing about this is that I'm starting from zero and this time I'm able to think about how to implement things in a simple way. The programming language is still going to be C++, but I try to avoid complex classes and also use procedural style for "action" code.

I was reading about game objects and noticed an interesting comment in which the idea of generic "object" base class should be removed. With that you should consider different game objects as their own base classes - in this case movables, items and creatures. This idea is something I want to try, because it doesn't sound that bad and it will certainly remove some problems I've had with that type of implementation in both Teemu and Kaduria which are complexity and large amount of virtual functions.

If it does work I've been "wrong" about object base class for a long time. However object base class does work better (I guess) in situations where you need to write generic routines for game objects, because the virtual system can decide what to do with some type of object and you only need the base class for parameters etc. Then again, routines for creatures and items tend to be different, so it's interesting to see what happens.