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.