Shifting paradigms

A while back I had an idea to use procedural functions in otherwise OOP code. It's not that bad idea in itself, but I went too far and now backtracking some of those routines back to classes. The other paradigm I've struggled with is the modular thing, which is much harder than I thought. Sometimes you don't want to force classes into a thematic module, because it's easier to keep it separated from others with the possibility to open the namespace in that particular file. Opening namespaces with more than one namespace is sometimes not possible without duplicate names. The distrubution of modules is the hard part in modular design, but it's better than just have tons of classes each in a separate file, because then you have endless include race going on.

I think it's going to be fine, after massive amount of work of course. A weird thing happening at the moment is Teemu's development which is in many ways doubling the amount of work, because I'm using similar kind of re-arrangement of code into more logical compositions and I can't just copy-paste between projects. In some cases I have developed things I can use in other projects, but it's quite rare. However  I do benefit from actually figuring out how to do some things, which then can be rewritten for another project. Still, I really could do without having to manage two roguelike projects at the same time.

External data

Three most important things I'm working on at the moment are:

1. Moving some data from source code to data files. The way data is handled in this project is kind of a problem, but even you have all text data etc. in C++ files it's doable. However I'm moving plain text data to files, because I'm planning to release the source code without data files during the development process, before the first playable beta. I think it's going to be the best way to proceed, because it makes no sense to be able to run the project in this state, before there is something to play. I suspect people could just get confused and it also pretty much prevents random "release" versions leaking to the internet which is not a very likely scenario, but possible.

2. The modular design, this is one of the most important things, because it will make management of the project a little bit easier and also it will be better with less changes in the project structure for github. Maybe there will be more source files in the future, but it's ok.

3. Continue removing dumb comments from .cpp files which really has given me a new kind of idea how big this project is. While not as big as some of the major roguelike projects when counting lines of code, comparing raw lines of code is not the whole truth.

Dumb comments

The first step in source code release is removal of "dumb" comments. It's probably the best to remove them, because unneccessary comments actually makes the source code a bit more harder to read and they don't give any meaningful clues to what the source code is trying to do. The "classic" example I guess is

int Get_Item(); //gets item

Things like that actually are in the source code as we speak and the reason is the long span of time the project has seen. Since then my programming skills have improved in some way.

Comments in C++ are sometimes needed, but often it's the matter of giving readable names to variables and functions after which comments are not required. So those are also things I'm probably fixing as I'm going through the source code. I have started with header files, because they are the easy ones to fix. I think header files should not need comments, with a big exception to classes, I think it's useful to comment in few words what the class is doing. The name of the class may tell it, but it's not always that clear.