Home

What’s a game without an objective? Probably something, for sure, but my poorly-conceived question has a point (in my head)! Without any sort of goal, a game will lose its draw over time. Even if they’re self-given goals in a sandbox game, you as the player are always trying to accomplish something.

With that philosophical exercise out of the way, let’s get on with the blog post.

---

Quests

In Descent, each encounter has an objective for both the heroes and the overlord to accomplish. Whichever side accomplishes their goal first is the winner. Pretty standard stuff. We will need a way of defining these goals and then tracking the relevant game actions that will lead to accomplishing that goal in order to determine who wins the game (and when the game should end, for that matter).

For this post I’m going to keep things pretty simple and not try and overcomplicate quests, like I am wont to do with programming things. There are many actions that could define quest goals but we’ll just focus on a simple one today: kill count. How many monsters/heroes are you required to slay before you win? So let’s bust out a new script.

I’m going to name this script “quest.gd” and have it extend Resource so that we can create and save them within the editor and potentially use them for more than just one scenario.

# quest.gd
extends Resource

# Define a signal that we can emit when the quest has been completed
signal completed

class_name Quest

# Only define one quest type for now
enum QuestType { kill }

# Define the quest type
export(QuestType) var type := QuestType.kill

# How many of the quest type does the player need to do?
export(int) var amount := 0

# Which groups will the targets be a part of?
export(Array) var objective_groups := []

# Keep track of how many [kills] the player has made so far
var _current_count := 0

So we’ve defined the outward-facing variables of the Quest script, but as it stands they’re just numbers. They don’t do anything in and of themselves — that’s where scripting comes in.

For our kill quest type, we want to be notified whenever a unit dies (we’re not going to worry about how it died or who killed it). When that happens we need to check if the unit is within one of the groups defined by objective_groups, and if so, to increase the _current_count and check for quest completion.

func _on_unit_killed(unit: Unit):
	print("unit was killed: " + unit.name)
	if type != QuestType.kill:
		return

	var valid := false
	for group in objective_groups:
		if unit.is_in_group(group):
			valid = true
			break

	if valid:
		_update_count(1)


func _update_count(increase_by: int):
	_current_count += increase_by
	_check_objective_fulfilled()


func _check_objective_fulfilled():
	if _current_count >= amount:
		emit_signal("completed", self)

And badda-bing badda-boom, there we have it! A simple logic to update the Quest resource and check for completion.

Hooking it up

Of course, we still aren’t using the script anywhere so even if we create a Quest resource and define the fields, the game behavior isn’t going to change. Let’s fix that!

There are a couple of ways we could go about this, but in keeping with the simple-code strategy let’s just make a middle man script that can act as a sort of event emitter hub. We also need to define a generic Game Manager script to keep track of various game states, so I think it makes sense to combine those two for now.

# game_manager.gd
extends Node

var _hero_quest: Quest
var _overlord_quest: Quest

func set_hero_quest(quest: Quest):
	_hero_quest = quest
	Utils.connect_signal(_hero_quest, "completed", self, "_end_game", [true], CONNECT_ONESHOT)


func set_overlord_quest(quest: Quest):
	_overlord_quest = quest
	Utils.connect_signal(_overlord_quest, "completed", self, "_end_game", [false], CONNECT_ONESHOT)


func _end_game(quest, was_hero_quest: bool):
	var who = "hero" if was_hero_quest else "overlord"
	print("Game over, " + who + " player wins!")

We will want this script to be available for all other scripts so we’re going to turn to the tried-and-true AutoLoad feature again! Making this script an AutoLoaded script allows us to access its members and functions within any other script.

So we’ve completed half of this script’s purpose (holding game state), now let’s add some signals to act as a central event relay-er.

The reason we need an event relay is because when scripts want to listen for a certain signal, but that signal is only emitted by dynamic scripts that can be created and destroyed at any time, the would-be listener is unable to determine (easily) when to start and when to stop listening to script signals. By using a middle man event relay we add a level of abstraction to the process, allowing both the emitter and the listener to only care about the single static instance that will always be available.

It might make a little more sense in practice, so let’s do that. First let’s define a signal type in “game_manager.gd” that we know our quest wants to listen for.

signal unit_died(unit)

Then we can hook up both sides in their respective scripts.

# unit.gd

func _update_hp(newValue):
	# ... existing code ...
	if hp <= 0:
		GameManager.emit_signal("unit_died", self)

# quest.gd

func begin_tracking():
	_current_count = 0
	Utils.connect_signal(GameManager, "unit_died", self, "_on_unit_killed", [])

And just like that, whenever a unit’s HP drops to 0 or below, any active quests will be notified and will run their _on_unit_killed() function. Lastly we need to make sure that the quest’s begin_tracking() function gets called, so we can do that in the GameManager when setting the quests.

func set_hero_quest(quest: Quest):
	_hero_quest = quest
	Utils.connect_signal(_hero_quest, "completed", self, "_end_game", [true], CONNECT_ONESHOT)

	# ADD THIS LINE!
	_hero_quest.begin_tracking()


func set_overlord_quest(quest: Quest):
	_overlord_quest = quest
	Utils.connect_signal(_overlord_quest, "completed", self, "_end_game", [false], CONNECT_ONESHOT)

	# ADD THIS LINE!
	_overlord_quest.begin_tracking()

---

Game script

One last thing needs to happen before everything is set up and ready to play, and that is calling the set_hero_quest() and set_overlord_quest() functions! Where will those be called?

Up until now my main demo scene has been using a script called “demo_scene.gd.” I’m going to replace that with a new script I’ll just call “game.gd” since I anticipate this one to be more permanent. In that script I’ll create two exported variables for the hero quest and overlord quest respectively. Then in the _ready() lifecycle hook I’ll call the GameManager functions to set the quests. To get the game loop started, I’ll kick it off by calling the PhaseManager’s start_hero_turn().

extends Node

export(Resource) var hero_quest
export(Resource) var overlord_quest

onready var _phase_manager = $PhaseManager

func _ready():
	GameManager.set_hero_quest(hero_quest)
	GameManager.set_overlord_quest(overlord_quest)
	_phase_manager.call_deferred("start_hero_turn")

---

This has been a fairly simple example showing how one might go about defining and tracking quest objectives, feel free to expand on the idea! Some things to think about:

• Maybe the heroes & overlord can have more than 1 quest to accomplish each; how would you allow for that?
  • What if the quests should be sequential (one has to be completed before another)?
• How would you modify the hero quest to kill a full monster group instead of a single monster?
• Maybe there are optional side quests for each encounter; how would you acquire and accomplish those quests, and what reward would you get?
• Besides kill quests, what other quest types could you add?

The code for this post can be found here.

And here we are at the final of the wheel posts. In this one I’ll walk through how I created a scene to hold both wheels and instantiate the scene when a battle happens.

---

Scene Setup

As with so many of these posts, we’ll start by creating a new scene (I’ve named it “WheelBattle”). We’ll pick a CanvasLayer for the root node type, since we want this scene to be an overlay. It will be positioned in canvas space rather than in world space which allows it to be appropriately scaled depending on the screen size of the window the game is running in.

Directly under the root node, add a CanvasModulate node. That node will tint each of its children a specified color, which we can use to tint the alpha channel of all child nodes at the same time. This will come in handy for fading in/out the scene as a transition.

Then there are 4 nodes we’ll add as children to the CanvasModulate node: one for the background color, one for the screen separator (optional), and one for the attacking/defending wheels respectively. Because I want to have a fun dynamic intro animation whenever the scene pops up, I’m going to give each of these items their own Tween child. This will allow me to tween their properties independently of one another.

Finally, the last thing I want to add is a representation of which unit is attacking and which unit is defending. The easiest way to do that is to just use their sprite, so I’ll create a spot for those sprites to sit as well.

The final scene tree will look something like this:

---

Animating

I’ll try not to spend too long on this section since it’s not as important to this post. I won’t be providing the exact code within this post, but I’ll cover the overview of what I imagine will happen.

Firstly, I imagine that there will be a background that fades in on top of the game. It will remain a little transparent so you can still see the game through the overlay.

Then the screen separator will appear. I think a mask reveal from left to right would be fun, so I’ll write a simple shader to allow me to specify the amount of the image that will be visible from 0-1. My separator will go from the top left to the bottom right — the attacking unit & wheel will be on the left side of the separator, with the defending unit & wheel on the right.

Then the two wheels will animate in at the same time from offscreen towards the center. The attack wheel will come from the left side and the defense wheel from the right.

Finally the two unit sprites will fade in and the battle scene will be fully visible.

Here’s an example of what my intro animation looks like:

I encourage you to think up how you’d animate these items! Part of the reason I didn’t provide code for this part was because I’d like you to think about how you’d go about doing this. We’ve learned about animating with Tweens in the previous post, and shaders in the post before that. This scene will use both!

The exit animation will simply be a fade out, which we can easily do by tweening the CanvasModulate‘s color property’s alpha.

---

Battle Manager

And we’re back again with another manager script! Like the others, we want to be able to access this manager script from anywhere in the code, so I’m going to make it an Autoloaded script (you can refresh yourself on what that is in this post).

There are a few variables we want to keep track of within this script. Firstly, we want a reference to the scene we just created so that we can instantiate it whenever we need to.

var _wheel_battle_scene = preload("res://scenes/WheelBattle.tscn")

We should also probably define some signals so that other processes can listen for the results of the battle, in case some game effect needs to happen.

# I recently discovered you can tell Godot how many arguments to expect from
# a signal. It doesn't do anything, but it is nice for reference.
signal battle_started(attacker, defender)
signal battle_ended(attack_result, defend_result)

We’ll want a reference to the attacking and defending unit, and also the result of the battle.

var _attacker: Unit
var _defender: Unit
var _attack_result: WheelSectionData
var _defend_result: WheelSectionData

And lastly, I don’t know if we will need these or not, but I added them in anyway because I’m bad at following best coding practices and love to over-engineer things — two arrays that will contain hooks (callbacks) we can call before and after the battle. This may be unnecessary since we have the signals defined, but the advantage that these hooks can provide is that we can ensure all of them get run before the battle code continues. Signals can’t ensure that will be the case since they’re asynchronous.

var _before_spin_hooks := []
var _after_spin_hooks := []

Script functionality

We need some way to initialize our variables, so let’s create an initializer function.

func init_battle(attacker: Unit, defender: Unit):
	_attacker = attacker
	_defender = defender
	_attack_result = null
	_defend_result = null
	emit_signal("battle_started", _attacker, _defender)

You’ll notice that we’re emitting the battle_started signal in the initializer function. I decided to do it this way so that our actual battle execution function will only have to focus on the battle.

Let’s also create a cleanup function that we can call after the battle results are calculated.

func cleanup_battle():
	emit_signal("battle_ended", _attack_result, _defend_result)
	_before_spin_hooks.clear()
	_after_spin_hooks.clear()

Now let’s define the primary function that we will call. This call should take care of instantiating the battle scene, spinning the wheels, getting the results, and removing the battle scene.

func _battle_flow():
	var battle = _wheel_battle_scene.instance()

	# Add instantiated scene to current scene
	get_tree().current_scene.add_child(battle)

	battle.set_attacker(_attacker, _attacker.get_attack_wheel_sections())
	battle.set_defender(_defender, _defender.get_defense_wheel_sections())

	# Animate the scene in
	yield(battle.animate_in(1.25), "completed")

	# Wait a moment after animation completes
	yield(get_tree().create_timer(.5), "timeout")

	# Spin the wheels for X seconds and get the results [atk_result, def_result]
	var wheel_results = yield(battle.spin_wheels_for_duration(.75), "completed")

	_attack_result = wheel_results[0]
	_defend_result = wheel_results[1]

	# Wait a moment after spin completes
	yield(get_tree().create_timer(.75), "timeout")

	# Fade the scene out
	yield(battle.fade_out(), "completed")

	# Remove battle scene from current scene
	get_tree().current_scene.remove_child(battle)

I added some pauses during the flow so that the player(s) will be able to register what’s happening, instead of just running through the steps one by one; starting and finishing the battle before even realizing that something happened. Adding pauses also adds to the suspense of the result (though not too many pauses or else it just feels drawn out). Feel free to adjust these timings to your liking.

You may have noticed that I made this function private. That’s because I want to call those hook functions before and after this function gets run, so I’ll expose a different method that should be called which does all of that and returns the battle results.

func do_battle():
	yield(_run_before_spin_hooks(), "completed")
	yield(_battle_flow(), "completed")
	yield(_run_after_spin_hooks(), "completed")
	return [_attack_result, _defend_result]

Calling the hooks

The hook function arrays could be empty, so we can’t just assume the _run_before_spin_hooks() and _run_after_spin_hooks() are going to be yieldable unless we account for that case. We’ll add the following code to the start of both of those hook-calling methods.

if <hook_functions_array>.empty():
	yield(get_tree(), "idle_frame")
	return

Otherwise we can call the functions one by one.

# _run_before_spin_hooks()
for cb in _before_spin_hooks:
	yield(Utils.yield_for_result(cb.call_funcv([_attacker, _defender])), "completed")

# _run_after_spin_hooks()
for cb in _after_spin_hooks:
	var updated_results = yield(
	Utils.yield_for_result(cb.call_funcv([_attack_result, _defend_result])), "completed"
	)
	# We will allow these hooks to modify the result of the wheel spins
	_attack_result = updated_results[0]
	_defend_result = updated_results[1]

The Utils.yield_for_result() is a helper function I created in my Utils singleton script. All it does is ensure that the function result is a GDScriptFunctionState object. If not, it yields for one frame before returning, ensuring that any function wrapped within it can be yielded.

# utils.gd
func yield_for_result(result):
	if result is GDScriptFunctionState:
		result = yield(result, "completed")
	else:
		yield(get_tree(), "idle_frame")
	return result

Finally, one last piece to add to this manager script is the ability to register the hooks.

func register_before_spin_callback(cb: FuncRef):
	_before_spin_hooks.append(cb)

func register_after_spin_callback(cb: FuncRef):
	_after_spin_hooks.append(cb)

---

Using the Battle Manager

Now that we’ve completed all of the work of building the battle system, all that remains to do is plug it into the existing code! Fortunately this is a very simple matter, since our attack action code has already been set up previously. All we need to do is replace the logic of how the damage is calculated with the following:

# unit_actions.gd -> do_attack_action()
BattleManager.init_battle(unit, target_unit)
var results = yield(BattleManager.do_battle(), "completed")
BattleManager.cleanup_battle()

if results[0].miss:
	print("Attack missed!")
else:
	var dmg = results[0].attack_points - results[1].defense_points
	if dmg > 0:
		dmg = target_unit.take_damage(dmg)
		print(target_unit.name + " took " + str(dmg) + " damage from " + unit.name)
	else:
		print(target_unit.name + " took no damage")

Now let’s see this all in action!

---

I apologize if this post seemed somewhat rushed, I’ve been eager to get on with finishing up the project and this whole Project Delve series. There are other things I’d like to write about in the future too!

As with the previous two posts, the code for this section can be found here.

Continuing on with the previous post, today we’re going to be taking those wheel sections and putting them together in a scene. We’ll also create functions for spinning the wheel and getting the result it “lands on” (I put it in quotes because in the code it’s actually the other way around, but more on that later).

---

The scene

Let’s make a new 2D scene and name it “Wheel.” As the first child of the root node, make another 2D node. I’m going to name this one “Sections,” as it will be the container for holding all of the WheelSection scenes we instantiate. That’s enough for us to get started on the scene script, so let’s make one and attach it to the root.

This is another script that I’d like to be able to watch update in the editor when I change its properties, so I’m going to make it a tool script. Additionally I’m going to define some exported variables so we can make edits to the script in the inspector.

tool
extends Node2D

# This export isn't strictly necessary, since we could use a preload() function with
# the predefined path to the WheelSection scene, but I'll do it this way for example.
export(PackedScene) var wheel_section
export(Array) var wheel_sections
export(float, .1, 2) var stopping_time := 1.0
export(float, .1, 2) var startup_time := 1.0

Hopefully these variables are pretty self-explanatory with what they relate to, so I’ll continue on. Because this is a tool script, I’d like the code we set here get run in the editor, specifically when editing the wheel_sections variable (which will be an array of WheelSectionData). So I’m going to make a setget for that variable and define a setter function.

export(Array) var wheel_sections setget _set_wheel_sections

func _set_wheel_sections(sections):
	wheel_sections = sections
	_draw_wheel()

The _draw_wheel() function is the key function here — that’s the code I want to have run during edit-time, so let’s go over that.

Drawing the wheel

We need to first check that the wheel_section variable has been assigned. If not, we can’t instantiate the scene and so we’ll return early. We also want to make sure that our current node (i.e. the root) is within the scene tree. If it isn’t, then Godot will give us errors when we try to add child nodes. This part is only needed since this is a tool script and will be running in the editor.

func _draw_wheel():
	if not wheel_section or not is_inside_tree():
		return

Next, we want to erase/remove all children of the “Sections” node because we want to be working with a clean slate when we start instantiating.

# _draw_wheel()
for child in $Sections.get_children():
	child.queue_free()

Now we will get a reference to the edited_scene_root (which should be the same as the node we’re currently attached to, but for completeness’s sake we’ll treat it as though it was separate). We need this reference so that once we instantiate the child scene we can set its owner property to the root. What this does is allow the instantiated scene to appear in the scene tree in the Scene panel to the left of the viewport area. Without setting owner, the scene would still appear in the viewport, but not in the hierarchy.

We also want to keep track of what rotation we need to start these wheel sections at, so we’ll set a current_offset variable to start at 0.

# _draw_wheel()
var root = get_tree().edited_scene_root
var current_offset := 0

Now we can loop through all of the wheel_sections and instantiate them.

# _draw_wheel()
for section_data in wheel_sections:
	# Instantiate the PackedScene
	var scene = wheel_section.instance()

	# Attach the instantiated scene as a child to the $Sections node
	$Sections.add_child(scene)

	# Set the owner property of the scene to the edited_scene_root
	scene.owner = root

	# Assign the wheel_section_data
	# Because the WheelSection scene was also a tool script, the wheel_section_data
	# setget method will also be run within this tool script.
	scene.wheel_section_data = section_data

	# Rotate the scene current_offset degrees
	scene.rotate(deg2rad(current_offset))

	# Increment the current_offset by the size of the wheel_section_data
	current_offset += scene.wheel_section_data.percent_of_wheel * 360.0

And that’s it! Our _draw_wheel() function has been created! Now you should be able to assign an array of WheelSectionData in the scene’s editor and watch the wheel be drawn as you update it! (Don’t forget to also assign the wheel_section scene to the scene we created last time)

The final code for the _draw_wheel() function looks like this.

func _draw_wheel():
	if not wheel_section or not is_inside_tree():
		return

	for child in $Sections.get_children():
		child.queue_free()


	var root = get_tree().edited_scene_root
	var current_offset := 0
	for section_data in wheel_sections:
		var scene = wheel_section.instance()
		$Sections.add_child(scene)
		scene.owner = root
		scene.wheel_section_data = section_data
		scene.rotate(deg2rad(current_offset))
		current_offset += scene.wheel_section_data.percent_of_wheel * 360.0

---

Spinning the wheel

Now that we have the wheel assembly taken care of, we need to make it functional. There are two main things we want to be able to do with the wheel from other scripts: spin and stop. Additionally we want to receive the WheelSectionData of whatever segment of the wheel we landed on. So let’s start by adding a few things to our scene and script.

First, add a new Tween node to the scene (anywhere in the scene works — I just added it as a child of the root). This handy node lets you do tweening animations fairly easily.

Next we want to have a few script variables to help us keep track of where the wheel is in its process of spinning, so let’s define those.

var _wheel_started := false
var _wheel_spinning := false
var _startup_final_rot := 360
var _prev_deg := 0
var _deg_delta

I think the only two variables here that may need some explanation are the _startup_final_rot and _deg_delta. The _startup_final_rot variable is basically just the final rotation of where the wheel should be at the end of the “startup” phase of wheel spinning. The wheel spin animation will be broken up into three phases.

1. Wheel start spin (controlled by Tween node)
2. Wheel continue spin (controlled by _process() function)
3. Wheel end spin (controlled by Tween node)

The _deg_delta variable will keep the wheel spinning at the same rate as it was at the end of the first phase.

We also want to define a signal so that any script can listen for when the wheel stops and get the result.

signal wheel_stopped

Now let’s create the spin_wheel() function. This will be the method we can call from outside scripts to begin the spin process.

func spin_wheel():
	if _wheel_started:
		# If we've already started spinning the wheel, we don't want to
		# re-do the startup animation
		return
	_wheel_started = true

	# Because the rotation of a node isn't bound between 0 and 360, the
	# actual_rot variable will hold the node's full rotation, while current_rot
	# will hold the rotation between 0 and 360
	var actual_rot = $Sections.rotation_degrees
	var current_rot = int(actual_rot) % 360 + (actual_rot - int(actual_rot))


	# We will set the final rotation to be 1 full rotation past the current rotation
	# in the counter-clockwise direction (for a clockwise spin switch - to +)
	_startup_final_rot = current_rot - 360

Now that we’ve initialized the variables, we can start the tweening process to startup the wheel.

	$Tween.interpolate_property(
		$Sections,
		"rotation_degrees",
		current_rot,
		_startup_final_rot,
		startup_time,
		Tween.TRANS_QUINT,
		Tween.EASE_IN
	)
	$Tween.start()

	yield(get_tree().create_timer(startup_time), "timeout")

	_wheel_spinning = true

If you now were to run this function, you’d see that the wheel will do one full rotation in the given startup_time, but will abruptly stop after that time. That is when the _process() function will take over.

Continuing to spin

func _process(delta):
	# These checks make sure that we can spin the wheel. The Engine.editor_hint 
	# prevents this function running while in the editor (_process() runs every
	# frame so that wouldn't be good).
	if Engine.editor_hint or not is_inside_tree() or not _wheel_spinning:
		return

	# Otherwise, every frame rotate the wheel another _deg_delta
	$Sections.rotate(deg2rad(_deg_delta))

The observant among you may have realized that we haven’t ever set _deg_delta, and may be wondering how we do that. First off, way to think through it! Let’s address that now.

Back in the start_wheel() function when we use the Tween node to begin the wheel spinning, we can set the delta. Because “delta” just means “the amount of change,” we want to be able to measure the amount of rotational change that happens between two frames. Lucky for us, the Tween node emits a signal at each frame with some information about the interpolation currently happening called “tween_step”. We will hook into this function and calculate the amount of change that happens between each frame until the tween ends.

# spin_wheel()
...

# Before $Tween.start() is called, make sure to connect the signal to our function
$Tween.connect("tween_step", self, "_set_delta")

...

# After the yield statement of waiting for the timeout, disconnect the function
$Tween.disconnect("tween_step", self, "_set_delta")

...

The _set_delta() function will take 4 arguments (the number emitted from the “tween_step” signal), but the only one we really care about is the 4th, which is the value at the current frame. All we need to do is set the _deg_delta to the difference between the current value, and the value at the previous frame. Then we update the “previous” value to be the current value in anticipation of the next _set_delta() call.

func _set_delta(obj, key, elapsed, current_deg):
	# If current_deg is the _startup_final_rot, we are on the last frame of
	# the tween, and do not want to update the _deg_delta
	if current_deg == _startup_final_rot:
		return
	_deg_delta = current_deg - _prev_deg
	_prev_deg = current_deg

Stopping the wheel

Now that we have the wheel set up to start its spin and continue spinning at the same speed, we need a way to stop the wheel and determine which section it landed on. However, as I eluded to in the intro to this post, we’re actually going to do it an easier way. Instead of worrying about how the final angle lines up and doing math to figure out which section that lies in based on the angle of our “wheel section pointer” and the angle of the wheel (trust me, doing it this way is a nightmare — I’ve done it before on a project I did in the past), we’re going to first randomly select a value between 0 and 1 and find out which section that would fall under. Then we just make the wheel stop on the angle associated with the random value! Let’s see it in practice.

func stop_wheel():
	if not _wheel_spinning:
		# Like before, if we've already stopped the wheel, we don't want to
		# restart the stop animation
		return
	_wheel_spinning = false

	var actual_rot = $Sections.rotation_degrees
	var rand_value = rand_range(0, 1.0)

	# Get current rotation based off 0 degrees
	var ending_rot = actual_rot - int(actual_rot) % 360

	# Set end value to within 360 degrees. (Again, if a clockwise spin is desired,
	# change the -= to += on this and the next line)
	ending_rot -= rand_value * 360

	# Spin 2 extra times before stopping
	ending_rot -= 360 * 2

	$Tween.interpolate_property(
		_sections_container,
		"rotation_degrees",
		actual_rot,
		ending_rot,
		stopping_time,
		Tween.TRANS_SINE,
		Tween.EASE_OUT
	)
	$Tween.start()

	yield(get_tree().create_timer(stopping_time), "timeout")

	_wheel_started = false

Now that the wheel animation has stopped, we can emit the “wheel_stopped” signal with the WheelSectionData at the rand_value.

emit_signal("wheel_stopped", get_section_at(rand_value))

The get_section_at() function is pretty simple, we just return the first section we come across that has the rand_value less than the current percent_of_wheel summed with the previous percent_of_wheels.

func get_section_at(percent):
	var offset := 0.0
	for section in wheel_sections:
		if percent <= section.percent_of_wheel + offset:
			return section
		offset += section.percent_of_wheel

And just like that, the script is complete!

…Well, nearly complete. We would like the rand_range() to give us less predictable random values, so we need to call the randomize() function in the script’s _ready() function.

We also want to make sure that the wheel gets drawn when it first loads up, so we’ll add the _draw_wheel() function to the _ready() hook as well.

func _ready():
	randomize()
	_draw_wheel()

---

Testing it out!

Now that we’ve got the script fully fleshed out, let’s try loading up this bad boy and seeing if it works!

There will be one more post in this section before we move on, which is putting these battle wheels into a battle system, and using it when our units attack one another. Until then, au reviour!

The code up to this point in the project can be found here. (Same as previous post)

Hiya folks, I’m back.

As I mentioned in my previous post, I was starting to feel drained with the work I was putting into this project and was starting to lose motivation. Turns out that’s what we call “burnout” in the biz! But after a few months hiatus I’m feeling rejuvenated and ready to finish this bad boy.

---

Where was I?

Naturally after opening back up the project for the first time in months I had forgotten what I was working on exactly. Fortunately I keep a Trello board and a markdown file with my to-do list items and thoughts I have had along the way, so that was the first thing I checked. I also revisited my previous post and the initial Project Vision post to see where I was at and remembered that I was in the process of adding skills to the game.

After reading through my last post I feel reasonably comfortable with how I described the process of creating a new skill (at least as far as “action” skills go — I’ll be writing a post about “interrupt” and “passive” skills later), so today we’ll be looking at putting together a more engaging battle scene!

---

Making a Randomizer

Because Descent is a board game, it uses the simplest randomizer for outcomes that can have a defined number of results: dice. But since this game we’re making uses code we don’t need any physical apparatus, we can have the computer provide a random result for us! So because we’re not tied to “dice,” I don’t want to use any sort of dice in our game (for no reason other than I don’t want to). Thus we need to come up with a different way to visually achieve random results.

One idea I’m fairly fond of is a wheel — think of the big “clicky” wheels at carnivals that eventually land on a certain prize spot. I think it’d be fun to have a spinning wheel as the attack/defense randomizer! Plus it also comes with a few added benefits:

1. We’re not limited to exactly 6 outcomes. There can be fewer or there can be more!
2. We’re not limited to a 1/6 chance for every outcome. If you use dice you’re stuck with that. Unless the dice are loaded. In which case… I hope you’re only playing with friends with whom you don’t care about burning bridges.

My first thought was to create a “wheel segment” sprite that could be stitched together with other segments to create a full wheel. This had the drawback of not being able to resize the sections at will if we needed to do some balancing later on, or if we want to allow the players to customize their wheels and allow them to select the size of each section.

My second thought was to create a single wheel and use some sort of image mask to cover up the leftover part of the wheel (the inverse of the section size, thinking in terms of degrees). While researching this I came across people discussing how you could use a texture as a mask for another texture through some fancy sorcery called shaders. I’ve heard of shaders before and in my mind they’ve always been a ominous entity. When I think of shaders I think of incredible visual effects with gorgeous lighting and high-detailed scenery.

As it turns out though, a shader is simply a snippet of code that the GPU runs for every pixel on the screen. After reading the Godot documentation on shaders and watching a few YouTube videos (this one was especially helpful), I felt ready to create my own.

Creating the scene

I then created a new scene which I named WheelSection with a root node of Sprite, and I assigned my circle texture to the Sprite node.

Next I created a simple Control node as the single child of the root and named it “Pivot,” since it would act as the anchor around which the icons would rotate. Everything else in the scene will be a descendant of the Pivot node so that their transforms will inherit the rotation of Pivot. I set the initial rotation of Pivot to be 180 degrees and will update it with a script depending on the percent of the wheel that should be visible.

I next created a BoxContainer node as a child of Pivot that I named “Icons,” which is where we will dynamically add our icons to represent the value of the wheel section.

Finally I created a script to attach to the root which I named wheel_section.gd. This script will take care of dynamically updating our wheel section based on the data provided.

# wheel_section.gd
class_name WheelSection

onready var _pivot = $Pivot
onready var _icon_containers = $Pivot/Icons

export(Resource) var wheel_section_data setget _set_data

export(Texture) var sword_icon
export(Texture) var shield_icon
export(Texture) var lightning_icon
export(Texture) var heart_icon
export(Texture) var miss_icon

# This function ensures that when the wheel_section_data gets changed (described in the next section)
# we automatically update the scene values.
func _set_data(section_data):
	if wheel_section_data:
		wheel_section_data.disconnect("changed", self, "_update_wheel")
	wheel_section_data = section_data
	if wheel_section_data:
		wheel_section_data.connect("changed", self, "_update_wheel")
		if is_inside_tree():
			_update_wheel()

# We will break up the update into 3 steps, as shown here
func _update_wheel():
	if not wheel_section_data or not is_inside_tree():
		return

	_update_icons()
	_update_positioning()
	_update_visibility()

Icons

Updating the icons will be the most complex part, relatively speaking, so let’s start there.

As an explanation for what we want to do, when we read the wheel_section_data (explained in the next section) there will be different values for different types (attack, defense, special, etc.). I’d like to display each of these icons in a grid pattern, grouped with similar icons. Thus, the top-level _update_icons() function will look like this.

func _update_icons():
	if not _icon_containers:
		_icon_containers = $Pivot/Icons

	# For simplicity's sake, we will delete any existing icon groups and recreate them
	for child in _icon_containers.get_children():
		child.queue_free()

	if wheel_section_data.miss:
		_add_icon_grid(1, miss_icon, "Miss")
	else:
		_add_icon_grid(wheel_section_data.heal_points, heart_icon, "Heal")
		_add_icon_grid(wheel_section_data.attack_points, sword_icon, "Attack")
		_add_icon_grid(wheel_section_data.special_points, lightning_icon, "Special")
		_add_icon_grid(wheel_section_data.defense_points, shield_icon, "Defense")

For the _add_icon_grid() function, we will be creating a new GridContainer node and adjusting the amount of columns it has based on the value that gets passed in.

func _add_icon_grid(amount, texture, name):
	if amount <= 0:
		# We skip creating any element if there are no icons to add
		return

	var max_columns = 4
	var icon_grid := GridContainer.new()
	_icon_containers.add_child(icon_grid)
	icon_grid.name = name
	icon_grid.size_flags_horizontal = Control.SIZE_SHRINK_CENTER

	if amount < max_columns:
		icon_grid.columns = amount
	else:
		if amount / 2 < max_columns:
			icon_grid.columns = amount / 2
		else:
			icon_grid.columns = max_columns

	# This ensures we will see the updated scene elements in the editor's scene inspector
	icon_grid.owner = get_tree().edited_scene_root
	_add_icons(icon_grid, amount, texture, name)

Finally, the _add_icons() function takes care of creating the TextureRects and setting their properties to the provided values.

func _add_icons(container, amount, texture, node_prefix = "TexRect"):
	for i in range(0, amount):
		var tex_rect := TextureRect.new()
		tex_rect.texture = texture
		tex_rect.name = node_prefix + "_" + str(i + 1)
		tex_rect.stretch_mode = TextureRect.STRETCH_KEEP_ASPECT_CENTERED
		container.add_child(tex_rect)
		
		# Like before, this updates the editor's scene inspector
		tex_rect.owner = get_tree().edited_scene_root

Positioning

Next, in order to position the icons in an appropriate spot, we will update the rotation of the Pivot node.

func _update_positioning():
	if not _pivot:
		_pivot = $Pivot

	var default_rotation = PI  # 180 degrees
	_pivot.set_rotation(default_rotation * wheel_section_data.percent_of_wheel)

Visibility

Lastly, we will set a shader parameter that will set how much of the circle image is visible.

func _update_visibility():
	material.set_shader_param("visible_percent", wheel_section_data.percent_of_wheel)

Creating the data

Because we want to be able to have each instance of this scene have different properties, and because we want these properties to be defined purely as data, we will be making a new Resource script. I’ll call it wheel_section_data.gd.

# wheel_section_data.gd
extends Resource

class_name WheelSectionData

export(float, 0, 1) var percent_of_wheel := 1.0
export(int) var attack_points := 0
export(int) var defense_points := 0
export(int) var special_points := 0
export(int) var heal_points := 0
export(int, 0, 6) var range_points := 0
export(bool) var miss := false

This script will work just fine for holding the data we care about, but to make it a little easier for development, let’s make this a tool script (meaning it will run in the Godot editor) and add some setget functions to notify when a value of the resource changes.

tool
extends Resource

class_name WheelSectionData

export(float, 0, 1) var percent_of_wheel := 1.0 setget _set_percent
export(int) var attack_points := 0 setget _set_atk
export(int) var defense_points := 0 setget _set_def
export(int) var special_points := 0 setget _set_spec
export(int) var heal_points := 0 setget _set_heal
export(int, 0, 6) var range_points := 0 setget _set_range
export(bool) var miss := false setget _set_miss


func _set_percent(val):
	percent_of_wheel = val
	emit_changed()


func _set_atk(val):
	attack_points = val
	emit_changed()


func _set_def(val):
	defense_points = val
	emit_changed()


func _set_spec(val):
	special_points = val
	emit_changed()


func _set_heal(val):
	heal_points = val
	emit_changed()


func _set_range(val):
	range_points = val
	emit_changed()


func _set_miss(val):
	miss = val
	emit_changed()

Now when a value on the resource is changed, the wheel_section.gd script will register that it needs to call its _update_wheel() function because of the signal we connected to it! Once you provide sprites for each of the wheel icons you can test this out for yourself (though you’ll probably get an error about the material not having a shader parameter “visible_percent”). So let’s fix that now.

Creating the shader

Start by clicking the root of the scene (which should be the Sprite node) and finding the “Material” dropdown under the “CanvasItem” section in the Inspector. Expand that section, click on the value dropdown, and select “New ShaderMaterial.” Then there will be a new field that shows up directly below “Material” called “Shader.” Open up its value dropdown and select “New Shader.” This will open up a shader script editor section in Godot where you can code the shader.

As described in the docs and video I linked to earlier, each shader script must begin with the shader_type keyword with a certain type following it. Because our ShaderMaterial is part of a CanvasItem node, the shader_type will be canvas_item.

shader_type canvas_item;

As for the things we want to be able to control outside of the shader (like our export variables in the gdscripts) we need to define some uniform variables.

const float PI = 3.1415926535;

uniform vec4 wheel_color : hint_color = vec4(.33, .61, .97, 1);
uniform vec4 border_color : hint_color = vec4(1, 1, 1, 1);
uniform float visible_percent : hint_range(0, 1) = 1.0;

Because we want to modify the texture’s color value, we need to define the fragment() function. Within this function we’re provided with a few “global” variables: TEXTURE, UV, and COLOR.

• TEXTURE refers to the full texture attached to the material (i.e. our circle sprite)
• UV refers to the coordinates of the current pixel the fragment() function is operating on
• COLOR refers to the color value of the current pixel the fragment() function is operating on

Modifying COLOR is how we will update the color value of the pixel. The texture() function is a global function that takes a texture and coordinates and returns the color at that coordinate. The following fragment function will assign the color of the current pixel to the color of the texture at the current pixel’s coordinates. (In other words, does nothing to modify the result)

void fragment() {
	COLOR = texture(TEXTURE, UV);
}

Try experimenting with modifying COLOR in this function and watch how the sprite changes in the editor! For example, this would set the blue channel of the pixel to be 1 (scale is 0-1) for each pixel on the texture.

COLOR.b = 1;

With this knowledge alone we can do some pretty fun stuff, but let’s stick to just hiding the pixels we don’t want to see so we end up with a slice of the circle. For that we will simply set COLOR.a (the alpha channel) to 0 on any pixel we don’t want shown, so it will be fully transparent.

…but how can we tell which pixels we need to do that for versus the ones that should be shown? Let’s create a function to call that will tell us whether we should draw the pixel or not.

bool should_draw(vec2 uv) {
	if (visible_percent == 1.0) return true;
	if (visible_percent == 0.0) return false;
}

void fragment() {
	if (!should_draw(UV)) {
		COLOR.a = 0.0;
		return;
	}
	
	COLOR = texture(TEXTURE, UV);
}

These two use cases are easy to determine — if 100% of the wheel is visible, we can always return true. Likewise, if 0% of the wheel is visible we can always return false. But what about in the other instances? For this we’ll need to do a bit of trigonometry, since we want to hide the circle radially instead of linearly.

First let’s determine which angles define the “start” and “end” of the area we want to be shown. (We won’t actually use the start angle in the calculations since it’ll be 0, but I’m including it here for… reasons.)

float start_angle = 0.0;
float end_angle = visible_percent * PI;

Easy enough.

Now let’s ensure that anything outside of the radius of 1 will be hidden (this ensures the resulting sprite will always be cropped to a circular shape).

float radius = 1.0;
vec2 local_uv = uv - vec2(0.5, 0.5);
if (distance(vec2(0.0, 0.0), local_uv) > radius) {
	return false;
}

We’re subtracting the vec2(0.5, 0.5) from the provided uv coordinates since we want to check from the center of the texture instead of the top left (which is the default).

Finally let’s whip out those dusty old trig textbooks and find the chapter(s) on calculating the angle of a point.

What we want to discover is whether a point within a circle lies between two different angles. We’ve already tested that it is within the radius of the circle, so now we just need to calculate the angle of the point and determine whether that’s greater than our start_angle and less than our end_angle. If it is, we can draw it!

To find the angle of our point we will use the atan() function, which takes an x and y coordinate and returns the angle of the point.

float point_ang = atan(local_uv.x, local_uv.y);

We’re using the result local_uv since we want the origin at the center.

float cutoff_ang = atan(cos(end_angle), sin(end_angle)) * 2.0;

To determine the angle of the cutoff point, we need to take the arctangent of the x and y value of our end_angle, and then multiply that by 2, since… that’s what works. (I spent a long time experimenting with different ways to get the correct angle, and even longer trying to understand why that worked, but I ultimately don’t know and if anyone can explain to me why this works I’d love to hear it!)

Then we can round off the function by comparing the point_ang to the cutoff_ang.

return point_ang >= cutoff_ang;

All together the shader script looks like this.

shader_type canvas_item;

const float PI = 3.1415926535;
uniform vec4 wheel_color : hint_color = vec4(.33, .61, .97, 1);
uniform vec4 border_color : hint_color = vec4(1, 1, 1, 1);
uniform float visible_percent : hint_range(0, 1) = 1.0;

bool is_border(vec4 color) {
	if (color.r != 0.0 || color.b != 0.0) return false;
	return color.g >= 0.98 && color.a == 1.0;
}

bool should_draw(vec2 uv) {
	if (visible_percent == 1.0) return true;
	if (visible_percent == 0.0) return false;
	
	float start_angle = 0.0;
	float end_angle = visible_percent * PI;
	
	// center of circle at (0.5, 0.5)
	vec2 local_uv = uv - vec2(0.5, 0.5);
	if (distance(vec2(0.0, 0.0), local_uv) > 1.0) {
		return false;
	}
	
	float cutoff_ang = atan(cos(end_angle), sin(end_angle)) * 2.0;
	float point_ang = atan(local_uv.x, local_uv.y);
	
	return point_ang >= cutoff_ang;
}

void fragment() {
	if (!should_draw(UV)) {
		COLOR.a = 0.0;
		return;
	}
	
	COLOR = texture(TEXTURE, UV);
	if (is_border(COLOR)) {
		COLOR = border_color;
	} else if (COLOR.a == 1.0) {
		COLOR *= vec4(wheel_color.r, wheel_color.g, wheel_color.b, 1.0);
	} else {
		COLOR = vec4(border_color.r, border_color.g, border_color.b, COLOR.a);
	}
}

---

Wheel Section

So there we have it! A working shader for our wheel section object! This post was a lot longer than I originally anticipated, so the next post will be how we can fit this into a full wheel and from there, make a full Battle Scene. It may be one more post, it may be two. We’ll just have to see!

The code up to this point in the project can be found here.

Hiya again, I’m back with the next steps for making the Turn System! (Well, I suppose the actual turn system itself is already completed with the functioning state machine, but I want to fully flesh out the selecting and performing of each of the unit’s turns)

Today the focus is going to be on the Overlord and monster phases. The code for the MonsterActionPhase will look almost identical to the code for the HeroActionPhase, since monsters are people too.

…Okay, maybe not. But the code will still remain very similar. So similar in fact that I wonder whether I should combine the HeroActionPhase and the MonsterActionPhase into one base class. That would probably be the wise thing to do, but since when have I been wise? I’m going to not worry about that particular good-practice right now and just continue on, since I’m eager to keep up my momentum.

---

MonsterActionPhase

I’ll start by copying all of the contents of the hero_action_phase.gd script and pasting it into the monster_action_phase.gd script. Then I’ll rename a few variables and change the class_name value back to MonsterActionPhase so that the top of the script now looks like this.

extends State

class_name MonsterActionPhase

var monster: Unit
var action_points: int
var leftover_movement: int

func _init(sm: StateMachine, unit: Unit).(sm, "MonsterActionPhase"):
    monster = unit
    action_points = 2
    leftover_movement = 0

Now, the monsters don’t get as many action choices as the heroes do. Specifically, they aren’t able to do the Stand Up action or the Revive action, since when a monster is defeated they’re removed from the game. They also aren’t able to do the Rest action since they don’t have stamina points.

The other major difference between a hero’s turn and a monster’s turn is that monsters are only allowed to spend one action point on an attack during their turn, whereas heroes are allowed to use both action points on attacking, if they so choose.

So with all of that in mind, let’s modify the _get_available_actions() function to remove the unavailable action types, as well as make an additional check when determining whether to allow the Attack action.

var has_attacked: bool

func _init(sm: StateMachine, unit: Unit).(sm, "MonsterActionPhase"):
    # ...
    has_attacked = false

# ...

func _get_available_actions():
    var available = [UnitActions.Actions.end_turn]
    if action_points <= 0:
        if leftover_movement > 0 and UnitActions.can_do_move_action(monster):
            available.append(UnitActions.Actions.move_extra)
    else:
        if not has_attacked and UnitActions.can_do_attack_action(monster, null):
            available.append(UnitActions.Actions.attack)
        if UnitActions.can_do_move_action(monster):
            available.append(UnitActions.Actions.move)
        if UnitActions.can_do_interact_action(monster):
            available.append(UnitActions.Actions.interact)
        if UnitActions.can_do_skill_action(monster):
            available.append(UnitActions.Actions.skill)

As a side note, I moved the Actions enum to the UnitActions singleton since both the heroes and monsters will be using it.

Then all we need to do is modify the _action_selected() function to remove the actions that cannot be selected! We can also set the has_attacked variable in the UnitActions.Actions.attack block.

func _action_selected(action):
    # ...
    match action:
        # ...
        UnitActions.Actions.Attack:
            has_attacked = yield(UnitActions.do_attack_action(monster, "heroes"), "completed")

And that pretty much covers the modifications we need to make to the MonsterActionPhase!

---

GUI

In the last post we made a GUIManager with a HeroTurnGUI scene. Because the monster group phase will behave very similarly to the hero group phase I think we can repurpose that GUI to serve both the heroes and monsters! The only differences will be which actions are available, which we already covered in the last section.

Firstly, since this will now be used by both the heroes and the monsters I think it makes sense to rename it to something less hero-centric. I’ve opted to rename it to UnitTurnGUI, and I’ll accordingly change the function name in GUIManager to be get_unit_turn_gui() instead of get_hero_turn_gui(), as well as remove the “gui_type” metadata and instead just assign the scene to a group “unit_gui”.

The other change I thought to make for the UnitTurnGUI is to change the column count of the button row to match the number of visible buttons. That way we won’t get overflowing buttons like we saw in the demo last week.

The function now looks like this:

func enable_buttons(action_list: Array, hide_disabled_buttons = false):
    var count = 0
    for action in _btn_map.keys():
        var btn = _btn_map[action]
        if action_list.has(action):
            btn.disabled = false
            btn.visible = true
        else:
            btn.disabled = true
            btn.visible = (
                false
                if (
                    hide_disabled_buttons
                    or action == UnitActions.Actions.stand
                    or action == UnitActions.Actions.move_extra
                )
                else true
            )
        if btn.visible:
            count += 1
    _button_grid.columns = count

Unit activation order

Another key thing we’ll need to be able to do is select which units we want to activate when. Currently we’re just activating the units in the order they’re in within the scene tree, but part of the strategy of the game will be determining the order of operations for your units’ activations.

I think that selecting the unit’s avatar image might work, so let’s try that out.

Let’s create a new script and name it something like avatar_selection_gui.gd. This GUI will hold the list of CharacterAvatar scenes previously held by the UnitTurnGUI, so we can remove the reference to that from UnitTurnGUI and add it to the AvatarSelectionGUI. There are two ways to go about doing this, one would be to sub-class the UnitTurnGUI to the AvatarSelectionGUI. The other would be to create a new scene with the AvatarSelectionGUI as the scene root node. I like the second approach more since it keeps the UI responsibilities separate, so that’s what I’ll do.

We’re going to add three new functions to the AvatarSelectionGUI, one to enable selection, one to disable selection, and one to set which avatars should be shown in grayscale (indicating they’ve already been activated).

Let’s start with the enable_avatar_selection() and disable_avatar_selection() functions.

func enable_avatar_selection(disabled_options = []):
    for i in range(_avatar_list.avatars.size()):
        if disabled_options.has(_unit_list[i]):
            # If the avatar is disabled we don't want
            # to connect the following callbacks.
            continue

        var avatar = _avatar_list.avatars[i]

        # The "clicked" signal is a custom signal on character_avatar.gd
        # The mouse_entered and mouse_exited are signals provided by the Control node
        avatar.connect("clicked", self, "_on_clicked_avatar", [avatar])
        avatar.connect("mouse_entered", self, "_on_hover_over_avatar", [avatar, true])
        avatar.connect("mouse_exited", self, "_on_hover_over_avatar", [avatar, false])

func disable_avatar_selection():
    for avatar in _avatar_list.avatars:
        avatar.disconnect("clicked", self, "_on_clicked_avatar")
        avatar.disconnect("mouse_entered", self,  "_on_hover_over_avatar")
        avatar.disconnect("mouse_exited", self, "_on_hover_over_avatar")

The _on_clicked_avatar() function will emit a custom defined signal, avatar_clicked, along with the unit the avatar represents. How do we know which unit the avatar represents? I’m glad you asked! In the set_avatar_list() function that we brought over from the UnitTurnGUI we’re given a list of units. From those units we instantiate all the avatar scenes we need. All we need to do is add an extra line of code in that function to link the avatar with the unit it represents.

avatar.set_meta("linked_unit", unit)

Then in the _on_clicked_avatar() function, we just need to put the following.

emit_signal("avatar_clicked", avatar.get_meta("linked_unit"))

The other function about hover enter and exit will set the border outline to white or black, depending on whether it’s entering or exiting.

func _on_hover_over_avatar(avatar, entering):
    if entering:
        avatar.border_color = Color.white
    else:
        avatar.border_color = Color.black

As for the grayscaling, I just added another option to the CharacterAvatar shader indicating whether it should be grayscaled or not, and the grayscale_avatars() function will set this option on the desired avatars.

And that pretty much covers it!

Testing it out

The last thing to do is replace the current _select_next_hero()/_select_next_monster() functions with using this functionality instead of using the next unit in the list. This is as simple as connecting to the avatar_clicked function on the AvatarSelectionGUI and starting the selected unit’s turn.

# For simplicity I'm using the term "unit" rather than "hero"
#  or "monster" but the function will behave the same for both.
func _select_next_unit():
    var gui = GUIManager.get_avatar_selection_gui()
    gui.set_avatar_list(units)
    gui.set_header_text("Select unit...")
    gui.grayscale_avatars(_have_finished_turn)
    gui.connect("avatar_clicked", self, "_start_unit_turn",  [], CONNECT_ONESHOT)
    gui.enable_avatar_selection(_have_finished_turn)

func _start_unit_turn(unit):
    GUIManager.get_avatar_selection_gui().disable_avatar_selection()
    # Change state to unit turn start phase ...

We’re now able to select which unit we want to activate, and you can see the columns get resized when there’s an extra action available. The attack action is also only available once per turn for monsters. Sweet! We’ve verified our code works!

---

Monster Groups

Now, if all we had to do were select between any monster on the screen then our work would be done! (Minus one or twelve bug fixes) However, the Overlord’s monster phase works by selecting a monster group, and then activating all monsters within that group before moving on to the next group. That means that we need yet another layer of selection logic.

Fortunately, because we separated the AvatarSelectionGUI from the UnitTurnGUI we only need to worry about the first in the OverlordMonsterPhase. However, we’ll need to tweak the AvatarSelectionGUI slightly in order to accommodate non-unit nodes (since the OverlordMonsterPhase will be concerned with nodes that have units as their children, rather than the units themselves).

Fortunately this won’t be too much of a hassle. We’ll just add a second parameter option to the set_avatar_list() function, is_unit_group. This will affect the function in the following way.

func set_avatar_list(units, is_unit_group = false):
    _unit_list = units

    var avatars = []
    for unit in units:
        if not unit or (is_unit_group and unit.get_children().size() == 0):
            continue

        var avatar = _avatar_scene.instance()
        var meta_key
        if is_unit_group:
            # We're assuming that all children of the unit group node
            # are of type "Unit"
            avatar.character_sprite = unit.get_children()[0].unit_data.sprite
            meta_key = "linked_units"
        else:
            avatar.character_sprite = unit.unit_data.sprite
            meta_key = "linked_unit"

        avatar.set_meta(meta_key, unit)
        avatars.append(avatar)
    _avatar_list.set_avatar_list(avatars, true)

Then when in the callbacks like the _on_clicked_avatar() or _on_hover_over_avatar() we just need to check for which meta key is defined before using the appropriate one.

if avatar.has_meta("linked_units"): ...

---

All Done!

And that’s it! Obviously I didn’t provide every new line of code I wrote, but I hope that I explained my process well enough for people to follow along and fill in the spaces themselves. Here’s a quick demo of checking that the unit selection process is working seamlessly with the state machine.

The code for all the posts up to this point can be found here.

In Descent and many other games, units often must have what’s known as “line of sight” to their targets when performing various actions such as attacking, buffing an ally, teleporting, and more. Sometimes games differentiate between “line of sight” and “line of targeting,” the difference being between what a unit can see versus what a unit can target. However, for our game these are going to be the same for simplicity’s sake.

At the end of this post we’ll have a functional line-of-sight calculator, as well as a visual representation of what a unit can see and what it cannot.

---

The Script

We’ll start by adding a new Node2D to the Dungeon scene called “LineOfSight” and create a new script to attach to it. I named it line_of_sight.gd (super original, right?). Our script is going to have only a single public method: can_see(). This follows the single-responsibility principle, which states that functions, modules, and classes (or in our case scripts) should be responsible for only a single part of the larger program. I’m not always the best at following all of the principles I learned in school in every piece of code I write, but the goal is to always be striving to improve.

The basic idea of the function is this: take in two points and try to draw an (invisible) uninterrupted line between both of them (also known as a raycast). If the line is not blocked by anything we define to be a vision-blocking item, the target point is considered to be in the line of sight of the origin. Let’s start by defining the function signature.

func can_see(world_point_origin: Vector2, world_point_target: Vector2):
    pass

The simplest way to do the check is to use Godot’s raycaster.

get_world_2d().direct_space_state.intersect_ray(pointA, pointB)

The intersect_ray() function returns a dictionary object containing the information of the first intersection the ray makes from pointA to pointB. If there’s no obstruction, the dictionary will be empty. This is the state we’ll want to check for to make sure there’s line of sight from pointA to pointB.

Our simple function should look like this now.

func can_see(world_point_origin: Vector2, world_point_target: Vector2):
    var result = get_world_2d().direct_space_state.intersect_ray(world_point_origin, world_point_target)
    return result.empty()

The only caveat with using a raycaster is that it interacts with the physics system, which our game does not use. In order for the ray to collide with something, that “something” needs to have a collider attached, so we’ll need to set up colliders on our tileset. Those instructions can be found on the Godot docs.

Once you’ve set that up, select the Obstacles node in the Dungeon scene and enable the “Show collision” property in the inspector. You should see something like this if you’ve set it all up properly.

Now if we write some quick code in the dungeon.gd script we can check that our can_see() function is working like it should. If the two points are within line of sight of each other, the line color will be green. If not, it will be red.

---

Refining The Function

So now that we have a basic function to calculate line of sight, let’s look at the rules for how Descent determines line of sight.

In order for a figure to have line of sight to a space, a player must be able to trace an uninterrupted, straight line from any corner of that figure’s space to any corner of the target space.

Rulebook, pg. 12, “Line of Sight”

This approach to line of sight is known as the corner-to-corner method. The other most commonly used method (when dealing with a grid system) is the center-to-center approach. I like the corner-to-corner method because it allows for a much larger field of vision than center-to-center.

With this in mind, let’s update the function. We now want to do the same raycast from each of the origin point’s corners to each of the target point’s corners. If any of the raycasts are successful (meaning they didn’t collide with anything) then we can exit the function early without needing to do any more checks.

First of all, we need to ensure that the world point we pass to the can_see() function is the top-left corner of the tile that was clicked on. This is fairly simple since the origin point of our tiles are set to the top left, so we just need to get that point and then add Vector2.RIGHT * tile_size, Vector2.DOWN * tile_size, and Vector2.ONE * tile_size to it and we’ll have the four corners of the tile.

Let’s start by getting the position of the top left corner of the tile in world coordinates. Because the LineOfSight node is on the Dungeon, I think it makes sense for the dungeon.gd script to have a method that exposes the can_see() function, just so we don’t have to rely on the structure of the Dungeon scene tree to get the line_of_sight.gd script.

# dungeon.gd

func has_line_of_sight_to(from_world_point: Vector2, to_world_point: Vector2):
    # First we need the map coordinates for the given world coordinates.
    var origin_map_point = floors.world_to_map(from_world_point)
    var target_map_point = floors.world_to_map(to_world_point)

    # Then we need to convert those map coordinates back to
    # world coordinates. This will give us the top-left corner
    # of the tiles in world coordinates.
    var origin_world_point = floors.map_to_world(origin_map_point)
    var target_world_point = floors.map_to_world(target_map_point)

    # Then we just return the result of the can_see() function
    return $LineOfSight.can_see(origin_world_point, target_world_point)

Now let’s fix the can_see() function to check each corner of the origin point and target point.

# line_of_sight.gd

func can_see(world_point_origin: Vector2, world_point_target: Vector2):
    for from_world_point in _get_tile_corners(world_point_origin):
        for to_world_point in _get_tile_corners(world_point_target):
            if from_world_point == to_world_point or _has_LoS(from_world_point, to_world_point):
                return true

    return false

func _has_LoS(from_world_point: Vector2, to_world_point: Vector2):
    var result = get_world_2d().direct_space_state.intersect_ray(from_world_point, to_world_point)
    return result.empty()

func _get_tile_corners(point):
    return PoolVector2Array(
        [
            point,                              # top left
            point + Vector2.RIGHT * _tile_size, # top right
            point + Vector2.DOWN * _tile_size,  # bottom left
            point + Vector2.ONE * _tile_size    # bottom right
        ]
    )

The last variable we need is the tile_size, which the tilemap can give us in the dungeon.gd script. So when I said we’d only be surfacing a single function in the line_of_sight.gd script… I lied. Oops! But because this function will supplement the can_see() function I think it still follows the single-responsibility principle, so we’re in the clear.

# line_of_sight.gd

var _tile_size: Vector2

# Make sure to call this function from the dungeon.gd
# script at some point before calling can_see()
func set_tile_size(size: Vector2):
    _tile_size = size

Here’s a visual representation of how the algorithm behaves now.

---

What’s Left?

So it seems like we’re pretty much done, right? Well, almost. Our function currently only considers the tilemap obstacles for blocking line of sight (because that’s the only thing we’ve set up colliders for so far). But in the game, there are more things that can block line of sight than a static obstacle — units, for instance. Units of different types (meaning hero or monster) block line of sight for the opposite type, so we still need to account for that in our calculations.

As I said at the start of the post, I’d also like to have a visual indicator of what a unit can or cannot see. I originally thought it’d be cool to have all the tiles that are within line of sight of a unit highlighted, but running this function for every possible combination of tiles on the grid could get expensive, especially when you consider that the grid will most likely be much larger than our little demo dungeon here. I think instead I’ll settle for calculating line of sight only when needed, and only on hovered tiles (kind of like what’s happening when displaying the movement of a unit).

And of course lastly there’s bound to be bugs or inconsistencies that will come to light with further use. I actually discovered one bug while recording the above gif! It seems like when the line of sight would pass on the diagonal edge of an obstacle tile (but not through it) it counts it as being blocked. This is a case that’s specifically called out in the rulebook as being allowed, and I think it should be as well, so I’ll need to figure out the best way to handle that use case.

The code for this post can be found here.