Tuesday, 4 January 2022

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.

Sunday, 31 October 2021

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.

Sunday, 9 May 2021

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.

Saturday, 13 March 2021

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.

Saturday, 12 December 2020

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.

Sunday, 22 November 2020

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.

Friday, 14 August 2020

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.