In the sewers

Sewers are a great example of how crazy roguelike development is. I added sewers I think couple of decades ago, but only now I'm starting to implement them... Until now a sewer has just been an object type with a pit and a lid. The lid is actually a door, it's just on top of the sewer. So now I have to figure out stuff like if the lid is closed then the character wont fall in the sewer and so on. Another thing I finally have to add is how to get up from a sewer. I think there will be a climb command which changes the action mode of a creature to climbing. There are a bunch of action modes and none of them are working at the moment, but it's getting there.

Sewers will store objects like containers, so you could in theory use them as a stash. An unreliable one. One of the craziest idea I have is that you could enter a sewer which would be a mini-sized level of maybe a maze type, but the current engine does not support this kind of wacky idea. It's so bananas to think about how much there is still to do, even on basic level like this, just to get game objects to work. Then again, maybe sewers are a special case, because I think they just were left unfinished. After all the game does have working doors, containers and that kind of stuff.

I'm going to post again when I get out of the sewers.

Scene refactoring

New year begins with refactoring. This is an "old" problem, because for a longest time I did not understand how double buffering works in SDL until it became hardware "forced" in SDL3 that shows it. The way you are supposed to draw stuff is just draw everything for each frame. This doesn't work in Kaduria as expected, because there are stuff like menus which have their own drawing loop and they only draw their own window and text, nothing else.

To fix this you can do a lot of things, but one way is to create "scenes" which show everything for that screen. So when you are in a menu loop, it's showing the current scene on the background, then draws the menu window and text. Problem fixed, right. In most cases yes, but in some cases you need to figure out how drawing works inside the Scene class.

Then again, this refactoring is a minor problem when compared to lack of content. I still have to create most level themes, try to make the RPG system etc. I've been reluctant to even think about level themes, but they should not be that difficult. Most pieces needed for level themes are ready to use, although I'm not sure how to implement town type levels.

Difficult stuff

Working on "difficult" stuff which are features or bugs that you write down but never fix. I've noted these in the source code with a comment starting "note:", this is what I do in all my projects. I do also have a list for bugs, and also separate notes in the project management spreadsheet. I think fixing these things is mainly what is required to finish the game... Some of them are purely technical source code issues, but others can be logic problems like the infamous "pit problem" where it's uncertain what happens if you push a movable object into a pit. In games like Nethack a boulder plugs the hole completely, but in Kaduria it would maybe look funny if something like a potted plant would plug a hole and make it a solid floor. Even if the movable falls into the pit, what happens if you try to push another object on top of it? Maybe it just...

Some of these difficult features are not that hard after you think about them for a while, but it's the idea of them being hard that can be the difficult part itself. I guess life is full of situations like these. Something seems to be so hard that you give up even thinking about it. The annoying thing is that it could be possible if you just did something about it. If you just asked her. But doing so could make you look like a creep and you could lose your self respect.

Manifesting a workflow

Trying to use a calendar for planning, I think this is the second time. I got a really nice looking and also practical calendar for this and also other projects or stuff I need to plan. This kind of "manifesting" actually does work, because when you write something down it's easier to follow that plan. Planning a whole day before doesn't seem to work for me, so I'm trying to make it easy.

Working on the project itself is not a big problem actually, because I know more or less what I have to do. I have the project management system ready, so I can just search for a module to work on and get to it. Lately I've been programming room generation and there is work left to do in dungeon generation. The "engine" is somewhat ready so there are low level tools I can use in generation, without having to do everything from the scratch for each level theme.

I've mentioned this many times before, but I'm always so astonished of how much there is still to do, even after all these years.

Open source Kaduria?

Being in a vulnerable state I thought about making Kaduria open source. Then people would be able to follow the development and get an idea how it works. The only downside is that it would reveal all the secrets of the gameplay. Then again, I could release the source only to a certain point in the development, because believe it or not the content is seriously lacking at the moment, there is not much of it yet.

There is also a possibility of "variants" emerging, but it's extremely unlikely. Managing source code and project of this type and size just isn't that fun or productive, I know it best myself. I have thought about open source many times over the years, but maybe the time is right now. Still, I would first like to create a minimum amount of content and at least a version of the role-playing system, so people could actually play the game already.

I wonder if this would be a good idea or not.

Obvious invention

Previously I thought that some classes just become large and complex, but I was maybe wrong. You can create complex classes and implement stuff that way, but once again I find myself refactoring the code to detach complex "stuff" from classes and moving it elsewhere, usually in functions.

The big reason to do it this way is that you can create modules (files in C++) with themes which in turn makes project management much easier. As an example I'm moving everything that has to do with creating plants to one module. That way, even if you have more complex C-style function parameter interface, it's still better than distributing that stuff into classes or even one dedicated class. I have some dedicated classes for some operations, but strangely classes don't work well in that role. Classes work when they have (store) associated data and only have one task to do.

So, how does this change the project's development? I would like to think it does make a difference, because when modules are distinct you can concentrate on some specific task without searching stuff from several files and classes, and possibly also creating duplicate code or algorithms. Functional or procedural action code is easier to understand and I'm still using game object classes in them which means they do implement virtual functions and inheritance, which itself is making complexity easier to handle.

Landing objects

The project management system was a great idea, one of the best ideas I've had for ages. It's easy to open the project file and check out what modules need fixing and what is the problem in that module.

Lately I've been working on how objects interact with the environment. If you only had a floor it would be easy, but I made it much more difficult with different types of terrain the object can sink or fall into. In this problem I've had success with good old functions (or procedures which they are in C++ I guess.) For some strange reasons it's easier to detach actions from classes and make them into one monolithic function, something like land_object() which is checking what happens if the object falls on ground (terrain), which can happen in several different situations.

If the object doesn't drown it's added into a list of "floaters" and processed per turn until it drowns or something else happens. It's kind of unsafe routine probably going to fail some way, but I have no idea how to implement that better way. What gets me is how I have not thought about object landing before? I'm reading the code and finding several unfinished routines for dropping items on water, but that's it. As usual I didn't follow through it. Now it feels like I'm implementing it the first time.

Managing the project

I think IDEs are missing some project management tools that would make it easier to keep track of stuff. At least the community version of Visual Studio and also Code::Blocks, although I'm using mainly VS to code. I'm so desperate that I'm probably just going to list the files and put them into a spreadsheet, so I can mark them with different colors depending on what state it is. That way you could fix files from least to most important, at least that's the plan.

When I get back to this project I'm always astonished by it, because it should not be that difficult to handle, really. But for some reason it is. It must be just the amount of files and places that need fixing, there is always something to fix, mostly a result of bad planning. Then again, you can't create good plans if you don't know how to plan something that works.

I see this problem in other roguelike source codes I'm working on, like Legend of Saladir. You can just see how the developer got deeper into problems of everything falling apart and then gave up. I believe firm project management would help, but the tools that we have for that are surprisingly primitive. Or maybe I have missed some great, possibly free, project management software. Most likely.

The new old gui

Forcing the gui to the main font size (12 x 24 pixels) was a great idea I think. When everything falls to that "text based" grid it's easier to place stuff on the screen. In fact this is what I partly did earlier with menus having only text based locations, but now everything is locked into the grid, except for smaller font size, but it's also placed "inside" the grid.

The new gui refactoring has been quite easy, no big problems there. Since the medication has been kicking in I've been wondering now what the google terms of service I've been doing with the gui before. It's like I had no idea how to finish those features, so they were simply left unfinished for a long time. Weird stuff, but then again I certainly had a problem with that brain fog.

Other than gui I've realized that pretty much everything is important, so there is no special order I have to get stuff in "somewhat" finished state. It's disheartening to understand how much there is still to do in areas like dungeon generation, but I don't find this situation hopeless. Things can proceed fast especially in procedural generation.

Graphics conundrum

Since I'm off the development until Teemu is ready I have been thinking about tile graphics. The problem is that tiles are small and it's difficult to make them look clean. Besides the last scaling from 24x24 to 32x32 made tiles look smudgy which has to be fixed.

I have two options and both of them are bad. I can clean up the tiles manually or recreate them in 3D. So I've given more thought to 3D option the more I think about it. The good thing about 3D is that you can scale the tile to pretty much any usable size and always get a sharp result. The downside is that it probably requires more work and creating 3D models for small tile size is not that simple. You can't just create a detailed or even "realistic" model and assume it looks good in 32x32 pixel size, because the details are lost. The model has to emphasize the shapes you want to see in the object clearly. Also, any kind of detailed textures are waste of time, it has to be a coarse approximation of a material.

I can try and see how long it takes to create a small subset of objects. Either way tiles are going to be a huge amount of work and I'm not happy about the current quality or even style of graphics in Kaduria. However I could even release the game with the current tiles and then slowly remake them.

Messages redesign

Messages system is giving me a lot of trouble, because the plan for it was not great. It does "work" in that you can output messages, but it's such a mess. I only realized this after writing a debug routine to view messages in a test environment. The issue here is again complexity, as in every difficult part in a roguelike project. You need all kinds of stuff for messages, who is doing and what, is the place near or far, can the player see the event etc. With rigid planning this would have been prevented, but also you need to know special cases which can be difficult to predict.

So what are the options. Maybe a complete redesign is not that smart, because in theory it works, but I think I need to make it more generic so that message data is working for different object types. The "classic" example is you vs. enemy: "You hit the orc." and "The orc hits you." You need only one message id if you can use "you", "the orc" and "hit/hits" properly in each case.

For some reason messages have always been a difficult part and the reason is probably just not planning it hard enough. I would really like to use as generic routine as possible, so there are no checks for visibility etc. in the calling routines, because it will increase the size of source code a lot. Also, the usual mistake to make is just go with the routine even if you have a feeling it will not work properly and then you have a bunch of confusing message entries in the data.

The plan for 2022

The "plan" for this year is the complete design of gui. As boring as it sounds, it's still a part of the game and I've had a lot of trouble with it as well. It mostly follows the rest of development which has been the inability to choose, in this case what to display and how. But as long as I focus on actual stuff rather than source code level implementation it's going to get done some way or another.

I sincerely hope the gui isn't going to take this year so I can also do some other stuff like dungeon generation (town type levels are still just a dream) and the RPG system. If there is some kind of change in this year it's the knowledge of my shortcoming in focusing on something. I am more aware that it's a real problem and it may even be something like ADHD even though I have not been diagnosed and I'm not willing to get a diagnosis for that type of stuff anyway. What I need to do is to follow through and get things finished, no matter how much they would suck at first.

Forest update

Previously I had a class called "Area" to create almost anything from regular caverns to forests, but it was simply too generic, because the generation was tied to a cavern. I created a new class Forest that is only creating forests. It has a new type of generation logic based on flood fill which I think works better than just placing trees in a roughly circular area.

It's quite important to avoid generic routines, because they will become too complicated and for some features may not even work in the end. However the parts should be mostly reusable, like in this context the flood fill routine itself will be reused in other routines that require filling an area.

Since cavern routine was also using the flood fill which was kind of weirdly modified flood fill it no longer works. This is why you should plan "low level" routines so that they wont break, but offer a true generic way to do something right from the beginning. The division to specific and generic is the main problem in roguelike projects I think, and probably in most projects ever.

I think a modified flood fill should be ok for a cavern routine, because that's what you want. You want to fill an area but not make it a perfect linear fill, but deviate it to generate irregular shape which still detects the proximity of other features like rooms etc. The proximity value will be a great way to create something like lakes inside a cavern.

Feature review

They often say you shouldn't have too many features in a roguelike, because they are hard to implement. It is very true, but large scale roguelikes require features and complexity that they give. I went through the source code and listed most major features that are distinctive. There are 64 features and I don't know how it even compares to other roguelikes. The startling or depressing thing is that most of the features are more or less concepts with often minimum amount of implementation. This isn't a surprise, because my inability to decide how features work in detail has been a monumental theme in this project.

I feel like this is a major problem in many roguelike projects. The design is too simple if you just decide to have some feature like fountains. It doesn't stop there, you need to decide how exactly fountains work and what sub-features they have. Do they dry when you drink from them? Do they spawn monsters? Are there hidden items in them? What happens if you kick a fountain? Is the water always healthy? Etc.

The sub-features are often linked to the engine thinking, where features either require lots of special code or they should be supported by the engine which then requires more from the engine. Everything adds to the total amount of code which can already feel overwhelming just with the core of the game.

I think the list of features is going to be my next goal where getting at least the basics working would help get the project to the next level.

Dungeon update

Or is it an update from a dungeon. The terrain rewrite was not that difficult after all, but the terrain object spawning doesn't work yet. However the engine is good enough to not care about that. I think the rewrite was worth it, because everything seems to work better just like that.

While the RPG system is still causing problems I've decided to at least finish the dungeon generation. The main problem is the unorganized complexity which I'm cleaning up. Then after that it's simply the design: what stuff to put in what level themes. You would think that roguelikes as "randomly" generated games don't need level design, but nothing could be less true than that. In a way there is more work and more design thought put into a level than in static level design.

My current day job is only three days a week so it's giving me extra two days to work on my projects. And the way I was kicked out from now-SJWarriorized roguelike "scene" has given me more motivation to show what real roguelikes are when you know exactly what you are doing. This SJW/woke thing is also happening in commercial game development scene which is causing really funny things to happen like companies hiring so crappy developers they can't even create anything. Companies end up losing tons of money and I'm just watching it and eating popcorns.

Terrain map rewrite

Some time ago I had an idea to create a game object for terrain tiles as well, because it was easier to handle game messages, damage to terrain etc. But it was kind of a mistake which I'm now going to fix with another rewrite (or refactoring, how you want to call it). At this point even rewriting doesn't feel like a problem, because it's mostly rearranging source code to more logical units.

The new plan is a terrain map with Tile class tiles which is a more complex way to use an integer to show which terrain tile is in that place. With that you also need fov and automap data and so on. Then, when a terrain is changed (most often when damaged) a terrain game object is created in that place. This is going to solve another mistake I made when I removed location data from some game objects. It became incredibly annoying to work with objects that had a location and others which didn't.

I think it's important to rewrite when you feel something is not right. The irony in this case is that I got it almost right the first time, but then made a decision to rewrite it because the strange problems I had (and still have) with the game message routine. Game messages shouldn't affect the way terrain map routines are implemented at all and it's an important lesson. Each part of the system should work more or less independently at the internal level and external connections should not rely on that.

300 Days

The latest development idea I have applied to all my main projects is extremely simple but it seems to work in its own way. I've created a five-step rating for source files, which in C++'s case is usually the combination of header and .cpp file. The ratings are: ready, works, test, unfinished and sketchy. For example if the contents of file (usually a single class per file) require testing, I'm adding a line to the header file with #. Then I can search and list all files with that rating.

What I have noticed with #test files is that testing is way too underrated in development, at least in my experience. The "usual" way to test is I guess play the game and see if it seems to work ok. But I think it's more useful to test individual classes and see if everything works as it should. It's much more work, but when it's done you can move from the test level to "works" level, narrowing down the development size of the project.

Another good thing with this approach is that it gives a focus on things you need to implement and improve. You can't leave things "for later" if you want to move on the next level. Also with this you can have an estimate of how long it takes to move all files to let's say works level. In Kaduria the starting point with the rating was 309 days, if you give each level one day of development time which is reasonable. It underlines how the size of the project itself makes it difficult to finish a large scale roguelike in short amount of time and why games are usually created by a group of people.

Those pesky mazes

Creating a maze or labyrinth routine is harder than you would think. At least when you go rogue from "homogenic" maze routine to more free style. The way I'm doing it is first create rooms that are special locations you need to find within the maze, then the maze system itself which is kind of corridors connecting those rooms. The problem is that maze can stop creating itself when it runs into a dead end created by itself. Currently I'm trying to solve this by creating several maze pieces that continue from current maze tiles, making sure everything is connected. However sometimes the maze simply doesn't reach all rooms, but it's possible to fix that by checking out if a room has a connection and then creating a "tunnel", which looks like someone had tunneled through the room walls and everything. It's the simplest solution, although you could create more sophisticated corridor routine as well. In this screenshot green corridors connect rogue rooms to the rest of the maze:

So it seems like everything is ok and there is often even room for additional features. But of course there is a special condition where maze creation fails, which I guess could be easy to fix. It happens when the maze begins from a room close to wall and stops short, then fails to find another starting point from the piece of short maze. Not yet certain why this happens, but even it does the level "kind of" works with tunnels connecting everything else, like in this example:

It could be possible to add Cornucopia system on top of this and still get a level, but it would not be a maze. I need to fix this last bug and then move on. My recent development strategy is simply go through each issue and keep fixing it until it's decent. That way I'm no longer pushing difficult problems to distant future.

Static code analysis report

With Kaduria I have not been consistent in checking code quality until now. I was thinking that it can be done "later" when the project is in testing phase and using code analysis on such a large project can be tedious. But I have since then began to run at least CppCheck on the whole project.

The nice feature of static code analysis is that you can find some bugs for free. There is no need to find them yourself and waste time on that. It also improves code quality when you can remove unused functions and other things like that. Some warnings like missing explicit and override keywords can be annoying, but adding them also is an improvement in code quality.

The tools I'm using are CppCheck, Visual Studio's W4 warning level and static code analysis with clang option (you can turn it on in project settings). There are some commercial tools which could be nice, but I don't have the money for those, at least in scope of money I'm getting from game development (which is 0.00€). GCC has also compiler settings for static analysis, but at the moment I don't have GCC installed and for that I would have to figure out a way to compile Kaduria in GCC in clean way.

Static analysis is good at finding errors in logic like comparisons which are always true or false, but more complex things would possibly require some kind of artificial intelligence to detect the problem. Maybe it is the future of analysis tools.

Progress and ideas

Something snapped in my brain a while ago and as the result I have almost completely stopped refactoring source code in all my projects. It means that the focus is now on the game design. I also figured out how to combine physics and traditional RPG system which also was a sudden realization.

Physics simulation in games is kind of weird subject, because games can never be completely physics based. If they were it would ruin "the hero" aspect of games, where the player character always seems to have some kind of special advantage over everything else. For example in most games the player never runs out of gas, but is always ready to do whatever it takes. Some games have a kind of stamina, but it's always limited to a certain level. The plan for Kaduria is not only have more realistic stamina effect but also long term fatigue which means you have to sleep to regain it.

There are lots of other ways I'm going to change the gameplay compared to a typical roguelike or a role-playing game. I'm not even sure if it's going to be a better gameplay, but I'm just so over the traditional style of roguelikes in particular where everything is based on getting tons of stuff (which in realistic terms you would never be able to carry anyway), killing thousands of monsters just like that etc. In Teemu I have deliberately chosen a traditional approach, because it's not a serious game, but Kaduria will be different.