Monday 12 February 2024

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.

Saturday 18 November 2023

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.

Tuesday 26 September 2023

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.

Wednesday 5 July 2023

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.

Wednesday 22 March 2023

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.

Wednesday 1 February 2023

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.

Thursday 27 October 2022

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.