Devlog of July 2024

For this summer vacation I invested some serious dev time tackling big issues in my currently un-named game project. In this devlog post I’ll show what I tackled and how I solved them.

If you want to know more of what type of game it is, you can read my post: Making my next indie game. In short it’s a 3D strategy RTS where you control a character; exploring, gathering resources, crafting, building and fighting. All in different dimensions and with a companion.

Before I get into the juicy parts about the game itself, I need to start off with some management. If this doesn’t interest you, you are welcome to skip this next section, but this is a part all game developers will encounter and need to handle.

Starting over in new project

As I mentioned in a previous blog post; Unity UI Toolkit – is it a good fit for my game?, I have learned UI Toolkit and absolutely love it. It is such a good solution for a UI-heavy strategy-genre game. Unity UI Toolkit got some serious upgrades in version 2023.3+ and I decided to upgrade the game from LTS (Long-term support) 2022 to this version.

Along with this came the decision to start in a clean new project. Instead of upgrading and handling all the headaches that usually come with it, I would start a brand new project. And thus I could choose which scripts to include in the new one, and rewrite ones that were messy. And that was absolutely necessary as my old project had been filled to the brim with different experiments, concepts I later decided to drop, and even several generations of procedural generation.

When making a new Unity project I also decided to make a new Github repo for it. I use Github for planning (issues, milestones, Project views) which also brought along some work to transfer issues and clean up a bit.

OK, this has been a lot of management talk and not much gamedev. Let’s go back into the actual game.

Converted all uGUI into UI Toolkit

I won’t spend too much time talking about this – as I already have written a post endorsing UI Toolkit. There’s not much examples, tutorials or best practices available on this topic available. But I think I’ve established something solid.

I’m now using UI Toolkit for all dialogs as well as what I call “In-game-UI”, which is the UI or HUD you see otherwise. Such as the action bar, player healthbar, menu buttons, and pinned quests (more on that later in this post).

One disadvantage with UI Toolkit however, is the lack of support for world-space UI. I have not implemented enemies in the game yet, but I do want them to have healthbars above their heads. I did some tests and I think I might end up using uGUI just for this part. More info on this to come, when I get to this part!

Custom save-load system

All games need a save and load system. I needed to implement this pretty early as I generate the whole map in run-time, procedurally. I use the same scene for all dimensions, and it’s mostly empty, apart from the generation scripts. So when the player teleport to a new dimension, the scene is reloaded but with new data for map generation. If I didn’t have a save system in place, it would regenerate brand generations for all the visited dimensions whenever the player teleports to another dimension. All buildings placed are lost. Obviously that doesn’t make sense.

This was actually a fun challenge. As this game is mainly a grid-based RTS game, I need to save all coordinates – what was on them (builds or resources – with their rotations), as well as the biomes and the terrain details. The challenging part was having a good system for each build to save their custom data, utilizing SerializeReference. For example a Furnace building will need to store its current melting progress, fuel amount, input inventory, output inventory, and fuel inventory. And a Drill building harvesting ores would need to save its progress and output inventory. Each build in a RTS has their own custom state and values.

I figured out a good process and now I am able to save all of the map when going to a new dimension. This new dimension also gets saved, so when I teleport back again, I get to the exact same map – even though everything is dynamically generated in run-time.

Proof of concept of a different dimension

Now that I had a save system in place, it was time to make a quick proof of concept of having a different dimension. Each dimension will have their unique look, biomes, resources, and enemies. I have not yet established how many and what features each of them will have.

But I am now able to define different humidity and temperature rules for generating the biomes, as well as different resources and the spawning rules for each – per dimension. It will need more tweaking, especially when it comes to the visuals – I probably need to tweak the lighting and post processing per dimension. And actual textures and details when I have established the dimensions a bit more. But for now I know it works code-wise.

Reduced scope: Removed NPCs

This is a biggie. I always had an idea that I would have NPCs in the game, that would move between buildings, work in them, and go out and gather resources for you. I spent quite some time to develop a good command system for NPCs to follow – such as going from the lumber camp to a specific tree, interact with it and wait for it to complete, pick up the items, go back to the lumber camp, drop off the items, and report for another job.

However, when I implemented the save system, I realized that this would be too much for a single-person indie game. I would have to save each NPC’s position, rotation, and current path (in the A* pathfinding system). as well as their current command in the queue, and all info that follow. So I decided to remove them entirely from my game.

This decision had a lot of consequences. I had made several buildings that completely relied on NPCs doing their production work. There were whole mechanics that had to be redesigned. But in the end, I believe it was a good decision.

I will look into other ways to make the game feel more alive, and the player less alone. Of course the player will have its companion (more info to come soon!).

Quest system

Finally I started on a quest system. In the game there will be multiple quests – one main quest line and several side quests. I have not defined the quests specifically yet, but I’ve made the framework for showing up as available quests, different rewards, and of course keeping an eye out when the player completes a quest sub goal. There’s also events and options to define which quests become available when this quest is completed, or accepted even.

I made a quick proof-of-concept dialog where the player can see available quest, and the quest log. And quests can be pinned in the in-game-UI. This is far from the final design, for now it’s just proof of concept.