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.
Tuesday, 26 February 2019
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.
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.
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.
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.
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.
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.
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).
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).
Subscribe to:
Posts (Atom)