Dev Diary [#27]

hʌnz.rx
World of Kráka
Published in
8 min readJul 13, 2024

Internally, I call this “The biggest revamp I’ve ever done”. At least for this game.

On the 4th of July, I decided to overhaul the equipment system because I needed a better solution for scalability and to prepare the system for equipping gear—headgear, accessories, unique items, etc. When equipped, these will give the player some bonuses—like a proper RPG.

I soon realized this change would affect everything, and my freshly created development branch, called Equip 2.0, was suddenly much broader in its scope than its name suggested. Oh, dear.

So here we go. Changes were made, systems were impacted, code malfunctioned, and my brain hurt. But it’s for a better future. Right? RIGHT?

Some nerdy stats:

  • 10 days
  • 55+ coding hours
  • 104 commits
  • 441 files changed

Progress Report

Let’s start with Equip 2.0, as this triggered all of that.

Equip 2.0

Firstly, I removed the hotbar, which you could see in previous recordings and screenshots. Why? It sucked.

Secondly, I added a whole new section into the inventory for equipment (gear and weapons, tools, and other items)

From now there are new slots in the inventory:

  • Headgear
  • Melee weapon
  • Ranged weapon
  • Mining tool
  • Watering tool
  • (will be more later)
Yes, yes, the UI must be overhauled too.

Once equipped, the game will use this item as the default one for the action. In the case of headgear, this will do the cosmetic part and add your specific bonuses or increase some stats. Confused? Good. Please continue reading. It will make sense at the end. I promise.

Player Actions

That brings us to another huge change in the gameplay: You don’t need to switch weapons and tools manually from the toolbar. Switching weapons/tools is now automatic, based on the player's action. If you have equipped a weapon or a tool (as seen above in the screenshot), the game will use it by default; otherwise, it will tell you you don't have such an item available.

Notice the predictive “action bar” in the following recording. It shows you the action, or better say, an item you have equipped for that action. It shows when your mouse goes over the resource, enemy, etc, and the game will use it automatically when you press the respective button.

[No SFX]

Water guns are no longer used to water crops. While they were fun in theory, they were dull in reality. They didn’t feel right when you had to water 10+ crops; everything was too slow, and they missed the target too often. Frustrating.

On the other hand, I kind of liked them. I need to tweak them and make them better. They will return at some point. In a different form. Not for watering, though.

I also had to completely redesign how the collisions between an item and your target are calculated. From this version, it should not happen that if you want to chop down a tree, you accidentally hit the nearest mushroom instead or something entirely different. That was frustrating, but not anymore. I’m pretty happy with the result.

These changes have made using the tools much more enjoyable and mature.

Combat Changes

As you can imagine, the new Equip 2.0 also heavily impacted our combat system. So, I took that as an opportunity and decided to revamp it entirely. If I was looking for a headline for this diary, it could be THE RETURN OF MELEE ATTACK. Yes, the melee attack is back! It makes total sense since you can have one default weapon for melee AND ranged attack. And let me tell you something: just by testing it, it’s sooo much fun and gives you cool variability. And that’s not even the final version.

The left mouse button is for melee attacks, while the right triggers ranged attacks. Easy and natural. You can use both attacks at any point in the combat; for example, you can pull an enemy with your crossbow and smash it with the sword when he gets closer.

Some types of melee attacks can move the player a bit in the direction of the attack, so it’s not that static. Imagine charge, but slower. The current implementation has two basic melee attacks; one includes a more significant “charge”, and the other moves you only slightly.

They’re randomly (50/50) selected when you hit the attack button. The concept is here; animations and player movement during these attacks will be tweaked over time.

[No SFX]

I also made some other structural changes in the system, worth mentioning are probably these:

  • Separated tools and weapons from each other - it makes sense since tools will not deal damage anymore
  • Redesigned how the projectile’s damage is calculated — this prevents us from random crashes in cases where projectiles lost their connection with the original weapon
  • Redesigned how weapon’s stats and bonuses are handled — basically a preparation for other types of equipment, like helmets and rings and so on

The Player Art

The more I draw, the more I like the pixel art I’ve created, but somewhere back in my head is a voice saying: try something new, something crazier. So I did. Yes, again. I tested a new style. First, it was for the player and then for the other game assets, but it didn’t turn out well; judge for yourself.

The Concept Art

So, I quickly returned to the original art, tweaked it more, and animated the player for all his current actions.

But I like this concept art, its style, and its simplicity, and I will use it for a smaller future project. It wasn’t just great for this game.

To sum it up:

  • Slightly enhanced the player design
  • Walking animation now feels more natural and nicer (hopefully)
  • Added the second variation for an idle animation (there’s some logic behind it; it means to be played rarely)
  • Added animation when shooting from guns
  • Added new animation for mining
  • Added new animation for watering
  • Added new animations for melee attacks

At this moment, I’m keeping it simple. It’s only 2–3 frames per animation, except for walking, which is 4. I like this basic animation style. Yes, it would feel smoother if it was 6 or 8 frames or even more, but I'm unsure if I want that for the game. I’ll test it in the future so that we can see and decide.

Items (Spawning)

I wrote an entirely new component for item spawning. Why? To streamline the code and make it universal. As the game expanded, the old solution became a mess.

First of all, let’s talk about items in general. Until now, the situation was way too complicated. For each item, I had several scenes and resources. It was the easiest way for me when I started with Godot. We had one resource for the inventory, one scene for the item spawned on the ground so you could pick it up, and one separate scene for the item if it was a piece of equipment so you could equip that. Just imagine how much work it would be if I wanted to add just one sword in the game. Not anymore.

I have created a universal scene for collectibles; if any component needs to use it and spawn an item, it can. The spawning is managed by a single function, receiving all necessary variables from the other part of the game.

This is not only if you want to throw something out of the inventory but also for:

  • crafting components, dropping newly created crafts on the ground
  • farming components, when you harvest crops
  • loot-generating components, when you kill a boss, and he drops a reward
  • mining, when you cut down trees or mine stones, and you’ll get the resource
  • and much more in the future

This new spawner is responsible for every item that appears on the ground, so you can pick it up.

Save and Load

This will likely be part of the diaries for a long time. There’s still a lot to do and optimize. In this version, I added auto-saving every (in-game) morning, so you won’t lose a whole day of doing stuff.

Plus, we have some new additions:

  • Saves, which dungeons are locked, and for how long
  • Update to the Player’s last location — we only save it within “normal” zones, not dungeons or similar, as dungeons only save when you complete them

Save and load, previously implemented:

  • Player’s inventory (items, quantity, item position)
  • Player’s hotbar (items, quantity, item position)
  • Player’s current health
  • Player’s buffs (effects, duration left)
  • Player’s debuffs (effects, duration left)
  • Player’s last location (position, zone/area/scene/world/dungeon, etc.)
  • Trees (position, current state, time to re-grow)
  • Mushrooms (position, current state, time to re-grow)
  • Fences and gates (position)
  • Day and time
  • Farming crops (position, state, if it’s watered already or not)

I also implemented UI feedback for the player: a little “saving icon” so you know when it’s happening and won’t quit the game or so.

The saving process is really quick—just a couple of milliseconds. The icon stays there for 1 second after the save process is finished so that you can even notice.

It's a proper old-school floppy disc.

Bugs

I hate to say it, but they will always be there. As in any game or software in general. Fixed these:

  • bug-fix: occasional situation when you could place duplicate seeds on the same tile
  • bug-fix: player rotation when using ranged weapons

Godot 4.3 beta 3

Upgraded from beta 2 to beta 3. Absolutely no issues at all, and it took only about 2 minutes + testing. If you are a developer reading this while considering the same Godot upgrade, feel free to go.

Conclusion

It was pretty extensive this time, but I think the game is in better shape. The affected code is lighter and reusable, and the gameplay feels quite different from the past. Maybe it’s not visible in the videos, but trust me, it’s a huge step forward when you play the game.

/wen next diary?

I’ll try to post Diaries as I add a new feature or finish one whole part. Some will be shorter, some longer. Some will take one week, some two weeks, or two days.

I’ll be changing the Git structure for that to track it more easily.

Currently, I have:

Main version > Dev version > all the other partial branches, if needed.

I merge the dev to the main immediately after I’m satisfied with the newly created functionality.

The new model will be:

Main version > DevDiary[xx] > Dev version > all the other partial branches, if needed.

I will only merge to the main once the new diary is posted and live. This allows me to track precisely my development progress from the last diary. Basically, the diary #number will become the number of the game development build. Starting now.

That’s it, frens. Thank you for stopping by, and see you next time!

--

--