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.

Friday, 30 November 2018

Control scheme

I'm rewriting keyboard input code for both Teemu and Kaduria. This is again one of those things where the lesson was not learned. The thing is that you want to decouple raw (static) keyboard commands/data from "game commands" so later it's possible to change keyboard commands. It's quite simple concept, but also a place for failure.

Rewriting the control scheme is not hard, but it takes anything between 10 to 20 hours (rough estimation) in this project, because keyboard commands are all over the place. SDL2 is not helping the situation, because it has some strange (I guess) features with foreign keyboard layouts, but when keyboard routines are decoupled from the actual game then it becomes much easier to fix those problems as well.

The icing on the cake is that routines in Teemu and Kaduria are very similar, but it's often not possible to copy-paste between these two projects so I'm like putting double the work in these which is always nice when you think about the massive amount of work these suckers require.

Sunday, 21 October 2018

Visual Studio C++ code metrics issue

Before I say this I want to point out that I'm not ungrateful about the fact that Visual Studio has a free version (it was called Express, now it's Community or something else). VS is a great IDE, in fact I think it's the best IDE at the moment. Yet there are some features which are weird. One of them is the missing code metrics option for C++ (unmanaged/actual) language.

Not getting some kind of project summary in lines of code, number of files etc. is not the end of world for me, but it would be a nice feature. They have it for managed code (like C#) which makes one wonder what was the reason to drop it from C++. Is there some kind of technical problem we the users don't know? When I read questions about that the "support" of Microsoft is the usual outsourced cut-paste answer that makes no sense. I really wonder why they even bother answering, I guess they get paid to cut-paste.

VS has extensions that could do the trick, but it should be a built-in feature (it is for managed code!) in my opinion and trying to find free extensions for that particular task is a real hassle. The extension/plugin system of VS is quite annoying, because most of the plugins are listed in several categories which itself are somewhat confusing and there is no clear indication of the price.

VS does have a static analyzer for C++ which is like way more complex feature than code metrics, so it's not like it would be impossible to do. Then again the static analyzer and Visual C++ compiler are both a bit "random" at reporting issues. If you don't believe me check your code with GCC and be enlightened. (Remember to use the warning options you need.)

Code::Blocks, the other IDE I'm using quite a lot has another type of problem, namely being open source. It has a simple summary of the project (which for some reason tells that one of my files is missing (what file?)), but it's only a LOC counter. If you know anything about open source development then you know that asking for some feature is almost always useless. The open source developers are notorious for being stubborn to do things exactly the way they want. That being said I think Code::Blocks developers are surprisingly friendly, but any feature you want you just have to wait for, sometimes it takes years as we have seen in case of projects like Blender 3D (for example the legendary case of N-gon feature).

Sunday, 23 September 2018

Being simple

Finally solved the display map synchronization problem I had for a long time. The underlying problem was my inability to think the simplest possible solution. In programming almost always the simplest solution is also the best one, because it's going to reduce the number of places things can go wrong.

I solved this in Teemu where I was adding support for multiple items per tile. The solution was so simple it just came out from nowhere. It's sometimes difficult for a highly creative person like me to think in simple way, but it's something I'm trying to do when programming. I try to be a simple person and it's probably the most difficult thing to do for extremely intelligent people in my experience. Although even harder for me is how to get women. It seems to be impossible for me and sometimes it makes me sad.

I'm also going to import the "flight package" routine from Teemu. It adds flying items into a list and then throws them at the same time, rather than go through each creature and make them throw items one at a time. When items are flying at the same time they could even hit each other. For example you run into an archer who is about to shoot you, but you can throw a large item and intercept the flying arrow.

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.