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.