Friday, 20 July 2018

Modular style

So what I have discovered lately is a sort of modular programming style where classes and functions of same theme are placed in one source file. This doesn't sound like very interesting news, but at least in my experience it may solve some problems resulting from C++ "class per file" rule we have been told to follow.

The problem with "class per file" is the physical size and complexity of the project: the more files it has the more difficult it becomes to maintain. C++ doesn't help, because you have to remember to include headers and also keep track of headers that are no longer needed. With large, over 300+ files project it starts to become a hassle.

Modular style has also other benefits like keeping better track of similar types of classes/routines and possibly making them more generic with inheritance etc. If your classes are in a single file you may actually forget(!) something similar exists. It's easier to find stuff, too, when similar type of code is in one file.

In C++ the downside is naming, sometimes there are issues when some namespace has been opened. But it's quite simple to remedy it by not making your names too generic even it is possible with namespaces, or use nested namespaces when possible. With modules the amount of namespaces seem to drop as well, with logical solution to use namespace per module, possibly even using the same name as the filename to keep things tidy.

For me at least modular programming used to be split to classes in a way, because classes are kind of modules by themselves. But using larger thematic modules may actually prove to be very important in this project and in the way I'm able to maintain and develop it.

Wednesday, 30 May 2018

Object-oriented news

I have a plan to put related classes into one file. This idea came from The Prowler's Datatype module and when I was programming similar type of stuff in Brick Atelier. I noticed that it's somehow easier to manage code and even design inheritance when there are less source files. It's maybe something we were not told to do, but I'm doing it anyway.

It's not a big refactoring which is something I try to avoid these days. It's more like re-arranging code into bigger pieces. This works with small classes, but not so much with bigger classes where actually splitting the class is a better option as mentioned earlier with the Level class saga.

I also try to use more inheritance which sounds quite obvious with a C++ project, but it's something I guess many programmers try to avoid (for no good reason). If you have a class-based code it's almost better use inheritance, because then you are going to remove some similar, repeating code for sure.

With content I try to design level themes from basic terrain topology first and then moving into details. I have some new ideas and tools to create difficult level themes so let's try it and see what happens.

Thursday, 8 February 2018

Plans for 2018

The account problem with VS was fixed, but I've also made a project for new Code::Blocks with virtual folders trying to make some kind of sense to it. The Cornucopia system I made for Teemu is going to be in Kaduria too. I think it will work well in town generation which is a missing piece in dungeon generation algorithms.

Something happened to me during last year, I don't remember I mentioned it before, but I became more aware of problems in my source code and programming style. In a way I became a better programmer almost overnight. It was a strange thing to happen, because it came out from nowhere. Maybe brains sometimes work that way, they get information from a long period of time and then make a decision to step into a new level.

The plan is simple: detect and work on problem areas of this project. There aren't that many left I think and they are mostly fine tuning some system like dungeon generation, in which I'm going to follow my experiences in Teemu and use more or less individual level theme generation for the basic structure of a level theme and then add more generic routines which create objects etc.