Regaining motivation

I took couple of weeks off from programming, partly because I was a bit depressed during the process when I knew I was becoming unemployed. But somehow programming is my "safe place", it makes me enter a state of mind, just like when I'm painting. So it's easy to return even I wouldn't care so much about other aspects of game development.

I have mainly tweaked the source code, trying to improve some technical things. I think it's important to maintain the source code in language level, because it then makes easier to create the actual game content. One thing I've noticed is that I don't use inheritance as much as would be possible. I realized it could be used relatively safely in type classes of game objects. They all share common functionality which could be put into a base class without breaking anything. The problem with inheritance is when it actually requires large scale changes. Then it may be a lot of work for no actual reason other than to improve OOP paradigm which in itself doesn't mean anything in context of game design. No one knows or cares what kind of paradigm was used to create the game.

Mental note

The development of Kaduria has long been reduced to problem areas. There is a list of missing features and bugs, but also source code comments starting with note: as a reminder for later coding sessions. Which may come after a long, long time.

Fixing problem areas is often extremely tedious, but something you have to do. I spend way too much just looking at the problem and trying to think a solution when better approach is simply hack it as fast as possible. Things get worse if you have a mind of a perfectionist. Maybe the biggest philosophical lesson I've gained from roguelike development is trying to let it go and make something working. You can always improve it later when the basic stuff works.

Development is sure going to be "faster" in context of Kaduria now that I'm again unemployed. Maybe something will actually happen, because even I am getting a bit tired of this project.

Procedural degeneration

I've degenerated back to procedural programming! Well, not entirely, but while I was reading stuff about functional programming it made me rethink some things in C++ and OOP. Classes are ok, but sometimes there are clumsy situations where you simply create a class without member variables (data) and use it as "empty" instance, then access functions to do something. It took some time for me to realize that these strange functions are actually... functions. Or "procedures" as in procedural paradigm.

Of course "pure" functions have been always lurking in C++ in form of the standard library (functions like printf etc.). But you can also write your own functions and use them in classes without breaking OOP principles. Functions that are good candidates are generic and algorithmic, they take in simple parameters and return simple values. It's possible to go further than that, but then it starts to be too much like traditional C with all problems it has.

In C++ context it's great to reduce some of burden from classes and also avoid copying source code in member functions when you could use external pure function in all similar places. If those functions are generic enough they can also be reused in other projects really easily, because they don't have any dependencies to the current project. So I've started to create a small function library for Kaduria (rather than creating any game content..) and already removed one of those clumsy empty classes. C++ has the neat feature of closing stuff in a namespace. I've named it "Function" so functions are called as Function::do_something(); which is not only clearly showing that the function library is used, but also protects from name clashes.

I think the function library will stay rather small, because OOP doesn't easily become functional, because member functions work closely with class data and if you try to make it generic function style it probably wont look nice.