Friday, 10 May 2019

Class hierarchy of game objects

The structure of game object classes is something I'm going to rewrite, maybe before source code release. The problem was that I believed the "common" knowledge that you should avoid inheritance and especially multiple inheritance in C++, and use components, not only as in component based approach but as datatypes inside the class. But if you are using classes and OOP, then what is the point of that? There is no point and not only that it has made the game object tree quite difficult to maintain.

But what about things like the dreaded diamond? It is a silly thing to dread, because any advanced programmer can't make that kind of simple mistake in inheritance. The real difficult thing is the class hierarchy itself, because you need to make independent branches that don't rely on some base class data if the class is not inherited from "main" branch.

How you split classes is part of the hierarchy problem. For example if you have fountains should they be a separate class that has water contain ability or should they be a part of some more generic container type class? The way objects behave is I think a good way to split, but even then some features are more generic than others. It's not easy to create a well behaving class hierarchy, but it's certainly not impossible or something you should avoid.

I think when people go for solutions like component based design it's a solution to problem that never existed. The way OOP works is just one way to do things, that's it. If you want to do something else, that's ok, but it's irresponsible to create assumptions about OOP that are not true.

Thursday, 2 May 2019

Descriptions

Every object in Kaduria has some kind of description of what it is. Some games have descriptions for monsters, but often not much else. I think descriptions are a nice way to clarify what the object is, because it's not always obvious. I know this myself, because I'm not a native speaker of english which is the de facto language for most roguelikes.

It's a good guess that descriptions are also a problem, because it's surprisingly hard to write good descriptions if you have a large number of objects in the game. I've mostly tackled that with kind of comical output, because it's the easiest approach in my mind. This is also something roguelikes tend to have, maybe for that same reason.

Item descriptions have been a stark reminder why it's a bad idea to create large amount of items before cementing their data structure. Kaduria doesn't have a impossible amount of items, "only" 233, but it gives plenty of work when something changes. In this case copy-pasting descriptions from C++ files to external text file. It's not even 233 copy-pastes (you can try that line by line from some random text file and get an idea) but also cleaning the source code's struct data after that. Lot's of selecting by mouse and deleting with backspace.

Some of the descriptions aren't yet written, so it's even slower than that. If there is something "technical" in the description it also has to match the game's features. Which in some cases is not yet there. Both items and monsters are a great example of overdoing and lack of planning skills. What you should do is start from a small number of items from each item/monster class and work with that before adding lots of them.

Sunday, 28 April 2019

Source code release plan update 2

Most of the text data is moved to external text files, but item descriptions are one of the larger parts not yet done. The modular design is also not yet decided and I guess there will be changes even after the project is in github.

I'm now unemployed, have been for couple of weeks. It's more time for projects like this, but somehow I feel there is strangely less time, because I have other stuff to do as well. I don't know how long I will be unemployed and in fact I'm not yet even technically unemployed, because I packed my vacation days in the end of the contract time. If you don't know what that means we get I think two days each month paid vacation which is mandatory, you can't avoid it. If you don't take days off from work those days will pack in the end of the contract. I never take vacation so I had 20 days extra time to be on vacation before I'm unemployed. I don't know what happens then, the last time I got a phone call to get in work.

Also, I'm in a middle of probably long process to get a new computer after using this Acer PC for almost 8 years I think. I could continue working with this, but it's started to run hot and getting a faster PC is better anyways, because Windows 10 and many programs require more power. I'm still keeping it quite slow and hopefully reliable rather than getting latest and fastest gear. Still seems like it's going to cost somewhere around 800-900€ when I'm building it myself. I don't know if it's a good idea, but this is the first time I'm building a PC myself. One of the reasons is that I didn't really find a good tower PC for a reasonable price. These days they are either ugly "gaming" PCs or small form factor "professional" PCs without a video card.

As I estimated in January preparing for source code release will take several months and even then there will be some old parts of the source code that are going to look funny, but they give a realistic picture how it can be difficult to keep the source code maintained even in this 50-60K range which I think is a middle sized roguelike in terms of lines of code.

Wednesday, 3 April 2019

Game design doc

Today I learned there is something called a "design doc" and I was browsing some examples of them. Some of them are "pitch" docs which are way too simple to accurately describe a game, but there were some that were more detailed. I've never made a design doc, maybe that's why Kaduria and my other projects took so much time to finish.

Maybe I could still write a design doc for Kaduria? I just don't see that much reason for it, but it could be something to try at least. I guess it is good to know what your game is going to have in terms of places, items, monsters etc. but why not just put them in the game without a doc? Maybe I'm missing something here.

I'm in a weird kind of situation right now, because all my projects are in state where I'm not sure what to do next, in a way. Obviously there is so much to fix that I can just start doing it and worry about those more generic things later.

Working on Banana Rogue (a derived project from Advanced Rogue) has actually given me some hope for my own programming style and source code. It makes everything look much simpler, even this huge project. The source code as technical aspect doesn't have too many problems to solve, it's more like content. Well, it's almost always the content. I don't know, maybe a design doc for content or more specific for game world could help me determine how to create the entire game world, not just some level themes.

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.