GameDev Diary: Bug Fixing, Improving, Coding

Andrew Lukes
5 min readOct 15, 2023

--

Latest improvements in My Video Game Project

Hi! As the project went along, a lot of serious bugs. appeared That is why I focused on fixing them in this new 0.5 update. On top of that, I also worked on improving the code structure using a simplified version of “State Machine”.

Let's dive in!

· Reworked moving and attacking
A bit about state machines
How I made it work
More Movement Component Changes
· Visual Improvements
Support Lines
Improved Unit Information Bar
Improved Buy Bar
Show And Hide Button
· Small Changes:
· Bug Fixes:
· Conclusion
· Demo

Reworked moving and attacking

A bit about state machines

When you code a video game object you usually face a situation, where your object can have multiple types of states, that all alter its main behavior. In the example of the units in my game, they can be either, idle, moving, attacking, or supporting (in the case of support class units). To avoid an if statement hell when deciding, what code to run, it is often useful to use this code pattern.

  • more info about state machines here

How I made it work

I decided to start small and implement a scaled-down one-file solution. Inside of the move component, I have added an enum variable with two states: Idle and Moving. And a variable current_state, that can equal one of these values. Later in the code, I just a code appropriate for the current_state. On top of that, I have created two functions for entering and exiting a movement state.

A very similar pattern was implemented in the action component, just with different state values here is how it looks:

enum States {
Idle,
TakingAction
}
var current_state = States.Idle


func enter_action_state():
print("ENTERING ACTION STATE")
entering_action_state.emit()
current_state = States.TakingAction
Globals.action_taking_unit = owner
highlight_units_in_range()
Globals.attacking_component = self
$AttackRangeCircle.show()
func exit_action_state():
print("EXITING ACTION STATE")
exiting_action_state.emit()
unhighlight_units_in_range()
current_state = States.Idle
Globals.action_taking_unit = null
Globals.attacking_component = null
$AttackRangeCircle.hide()

More Movement Component Changes

In the previous version, when a movement component calculated a movement position it just returned for the parent to work with it. I didn't like that, because this forced me to put a code for moving even inside the parent, which defeated the point of using the component in the first place. Now the component is more independent and can set the position of the parent on its own.

This part was in the unit script
this part was in the movement component
New Code

Visual Improvements

Support Lines

Every support unit now has its own color for support lines to help it differentiate from others

observer supporting a musketeer

Improved Unit Information Bar

The information bar now contains icons instead of text and has a higher contrast. On top of that, it shows over other units thanks to increased z_index.

improved appearance

Improved Buy Bar

the buy bar now also shows the amount of money each unit costs. In terms of code, I saved on some lines by using export variables for the buy bar buttons

Show And Hide Button

You can now toggle the visibility of the units, to see only their outlines, this is useful when you want to know what type of terrain the unit is standing on.

hidden units

Small Changes:

  • The maximal number of rivers was decreased to 5, due to the better battlefield generation
  • Every unit now has a custom cost, movement, and attack range. Support units also have unique colors for support lines.
  • Reworked town spawning function ensures, that the towns are spawned in the game based on the rules when it is possible to give them enough distance from each other. (the rest of the time they aren't spawned at all to prevent overlap)
  • When highlighting units within reach of a support unit, they are colored pink

Bug Fixes:

  • Melee unit slash animation is again visible (had to make sure to keep the z_index under 4096, which is the maximum allowed in Godot)
  • Supply depots again dispense ammo to nearby units (updated an old function)
  • Units cant spawn on rivers (added an enlarged collision area for the river segment, and checked if the position of a new unit, was inside of it)
  • Ending the game and regenerating a new battleground doesn't crash the game (this was caused because the unit _ready fc was calling a freed scene)
  • Fixed Calculation of movement modifiers (realized that when I set a value in a dictionary, it doesn't call the set() function connected to that variable
  • supply depots now don't spawn out of the map (I added some margin from the edge of the screen when choosing a position to place them on)
  • Units can not be placed on enemy units (Added one more check in the handling of the placement of units)
  • Fixed compilation of my project (Caused probably by exporting a new version into the path of an older version)

Conclusion

I hope that these improvements will make the game more playable and enjoyable for you. I think that in its current state, it almost resembles a real game and I am excited about the new paths the project might be taking me along. Stay tuned for more updates!

Demo

Download BattleForge 0.5 here: BattleForge 0.5

Photo by Matt Artz on Unsplash

--

--

Andrew Lukes

Introducing Andrew Lukes: a Prague web dev & language enthusiast who shares his ideas on Medium. You can visit andrewebdev.online to see some of my projects