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.

Wednesday, 24 June 2020

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.

Tuesday, 19 May 2020

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.

Saturday, 2 May 2020

User interface stuff

I feel that this project is going to be somewhere between old school ascii and "modern" graphical styles in the way how information is shown on screen in the main gameview. In traditional roguelikes you often have information packed in various status lines etc. which I guess become easier to understand once you get used to it. However it feels like mirroring that to a graphical roguelike isn't the best, or having packed information at all.

Graphical games can have icons to replace text, but in many cases it's worse. In any case, how much and what information is directly on screen is a matter of design which is harder than it seems. User interface design is difficult in all programs, not just in games. Luckily I've learned from my past mistakes and now adding something only if it's easier to have on screen all the time. But it's also a design decision, especially now when you have the space, assuming the gameview is small enough that space for stats etc. is available.

The design of "off-screen" information is just as important, and making it easy to access can remove the need for on-screen information.

Thursday, 16 April 2020

Plant simulation

It looks like I have to rethink plant growth simulation, because it was too simple to work properly. If you can set up plant simulation it's one of the only places in roguelike development where you can then reduce the work in random generation by some dramatic amount. But for that to work the simulation needs data which is consistent with the dungeon layout, everything that contributes to growth of plants.

That's actually all I have to say about it. Well, other than in Kaduria the plant simulation is going to be quite detailed, because the amount of data the environment has. I'm not looking forward in clearing the mess I made, but when it's done at least something should work in this project.