Saturday, 9 March 2019

Class enum

I knew you can put enums inside a class (like pretty much everything) but I didn't realize you can then use the class name as outside access to that enum if it's public. What this means in my case I can remove some namespaces I've created for enums. In a large project any name that is introduced increases the complexity, so using class enums is in many cases a better option, because usually enums are used inside the class and sometimes outside. As added bonus the enum will be "open" (as with namespaces) inside the class, but always closed outside (requires the access name).

There is also something called enum class, not to confuse with class enum, but it seems to be too advanced to even look at it.

Namespaces are weird. They were designed for modular style I guess, but in reality they are used to replace old school "hungarian" notation where some letter or combination is used in front of the name, like iDagger or itmDagger or itemDagger for items, and replaced with item namespace with outside access style item::Dagger. But sometimes even I'm using namespaces for modules and they are really useful to avoid name clashing problems which eventually will become reality when the project is getting bigger.

Like I said before I've backtracked too modular style, because modules should be "natural" I guess, containing stuff that's actually related and possibly even working together as a.. well, module. I think in OOP style the most important thing is a good low level or datatype class foundation and then the actual code is built using those classes, rather than writing too much "low level" code everywhere. That way the source code becomes easier to maintain, which is not the case with Kaduria.

Tuesday, 26 February 2019

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.

Saturday, 16 February 2019

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.

Sunday, 3 February 2019

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.

Tuesday, 29 January 2019

Asset manager

Now that the source code is going to be released I realized it could be useful to talk about it even before release to explain my programming style and thinking. One of the newest module (I'm going to talk a lot about modules which are not a "built-in" feature in C++, yet very useful way to handle large projects) is asset manager. It's a collection of higher level routines for stuff like displaying some graphics and working with menu data etc.

The reason for asset manager is remove some of those higher level includes from "low" level modules. An example would be Add_Player_Races which, as the name says, adds playable races to a menu in character selection. This used to be in Monster Type module which is static data for creatures, but you kind of want to keep simpler modules clean from gui stuff or whatever. As clean as possible anyway.

A problem related to asset manager are procedural functions in nameplaces which in many cases belong to some type of class. So there will be a clean up of those, because I think I got a little bit too excited about "procedural" programming in some cases. It does work in generic cases though, when you create functions that can be accessed from anywhere without binding them to a specific class.

Wednesday, 23 January 2019

The plan for source code release

I made a decision to put the source code of Kaduria in git. What does it mean? Well. Nothing. It means nothing really. I'm not abandoning the project or anything like that. There may be some bad things about releasing a source code of a project, but in this case they are not that important. Some good things are:

1. It follows a tradition. Many classical roguelikes are open source.

2. The source code is different than anything I have seen before. It's mostly object-oriented C++ with some procedural style code. Unlike many roguelike source codes it's also quite easy to read.

3. The modular programming style in C++ could give ideas how to manage large projects.

4. Working with github for VS is nice, because I can track the changes myself.

5. Some people will stop complaining about the progress or if the game actually exists.

6. Feedback on source code, possibly ideas to implement or fix something.

Before the release I'm going to finish the modular design and also clean up the code as much as possible. The modular design is not an easy task (in this project, because it is a refactoring thing), so it will take maybe even months to do.

From a player's point of view this release is annoying, because the gameplay is not yet ready at all. But maybe some day there will be a game.

Thursday, 27 December 2018

Reflections of 2018

The new and important thing was the discovery that C++ can be modular, too. Modular in a way that each class doesn't have to be in its own file, but classes can form larger thematic files (modules). In large projects I feel it makes management of the source code easier.

I've tried to shift my thinking from technical details to content, but it's difficult. I like improving the source code and I've became sensitive to poor technical solutions of the past, but at the same time I know I can work with that rather than trying to "fix" everything.