Claret (2020)

High school Major Assignment

Goals

• Complete the assessment while meeting all of the marking criteria

• Gain experience in working with the game development lifecycle

• Learn to appropriately scope and plan a game project to meet pre-set deadlines

• Start and complete my first major game project

Game Design

Vision

Narrative:

I wanted to convey a story about a character who puts too pressure on themselves to meet their own high expectations, and the expectation of others, and eventually learns that it is necessary to forgive themselves to be able to properly grow as a person. It is essentially a message to those who overwork themselves to remind them that they need to take a break every so often to avoid burnout. This narrative was conveyed through the fantasy genre as I felt that it was the most appropriate genre to work with at the time for this type of story, and the one I felt the most comfortable working in.

Gameplay:

The core idea behind the gameplay of Claret was to allow the player to immerse themselves in a story where they assume the role of a powerful mage who blends martial arts with a unique source of energy they can conjure. I wanted to adopt a traditional top-down JRPG style of play with simple controls to allow the player to equally focus on the story and the game.

Dialogue and Cut Scenes

A custom dialogue system was created in Godot to be able to display the conversations between characters, and which was used in conjunction with an Animation node and the level manager within each level to produce the game’s cut scenes.

Dialogue set up in editor

Displaying the required lines of dialogue on-screen was handled by the main dialogue UI node, which had functions to advance the dialogue as well as custom signals to allow other nodes to know when a certain line had been fully displayed or when the whole conversation had ended.

A JSON file was used to hold the required dialogue for each scene to make it easier to import into Godot. Each line of dialogue was accompanied by the name of the speaking character, as well as how fast the dialogue should progress (slow, normal, fast). These JSON files would then be set through an exposed variable in the main dialogue UI node for the corresponding level, and each line would be accessed via its index.

Dialogue JSON file example

The animation for the cut scenes were created using an Animation node and controlled via the level manager where the main dialogue UI node was also connected to. Since the level manager controlled both the dialogue and the animation node, it ensured that the right animations played at the right times by keeping track of the current dialogue index from the main dialogue UI node.

There are some flaws with this system however that could be addressed to improve it for future use:

• Many moving parts are required to be set up before a cut scene can be created and played. This could be simplified to make it more efficient to use

• As everything is being controlled via the cut scene level manager, creating new cut scenes requires modification of its code which makes it complex to use – especially those who are unfamiliar with programming

UI Design

As the focus of RPGs is typically the story and the environment of the game, a minimal design for the UI was adopted.

The player HUD only displayed what was required - health, mana, and the player’s abilities.

Player in-game UI

The dialogue UI only displayed the dialogue box as well as two black bars on the top and bottom of the screen to emulate a cinema screen effect. The dialogue box was also partially transparent to allow the player to see more of the cut scene.

Dialogue UI

Enemy AI

Four different types of enemies were included in the game, in addition to the boss (Kahn himself), to add variety to the different levels. All their behaviour were handled by a simple state machine and implemented using an Enum defining all of their states, a switch statement to determine the correct state behaviour to execute, and functions which defined the actual behaviour of the different states. Switching between states was controlled via Area2D nodes (which essentially served as the AI’s senses), as well as Timer nodes. Each state an enemy had typically had an animation associated with it.

func _physics_process(delta):
match state_current:
	IDLE:
		state_idle()

	RUN:
		state_run()

	ATTACK:
		state_attack()

	DEATH:
		state_death()

Enemies and their behaviour:

Slime:

• Moves slowly towards the player and performs a short-ranged melee attack when they are close enough

Slime behaviour

Spinner:

• Once it starts targeting the player, it will curl up in a ball and being to spin before attacking the player by dashing at high speed towards them. When the Spinner starts dashing, it cannot change its dash direction until it comes to a stop

Spinner behaviour

Bear Ape:

• A large slow-moving enemy that deals damage in a small area around it by slamming its fists into the ground to create a shockwave if the player is close enough

Bear Ape behaviour

Exiled Grunt:

• One of Kahn’s followers who wields an energised axe to attack the player after charging their attack for a short period of time

Exiled Grunt behaviour

Boss (Kahn):

• A boss who will continuously chase and attack the player using one of their three attacks which are randomly chosen. There is a delay between attacks.

• Attack 1: Charged Punch – Kahn charges his fist for a short period of time before pushing forward and dashing towards the player

• Attack 2: Punch Flurry – quickly approaches the player before unleashing a rapid barrage of punches after a short delay

• Attack 3: Shockwave – after a longer delay and charge time, Kahn slams his fists into the ground dealing damage in a large area around him in the form of an energised shockwave

Kahn Attack 1

Kahn Attack 2

Kahn Attack 3

Due to the way the simple state machines were implemented, the main file for each of the enemies became very lengthy by the project’s completion and a little disorganised. In the future, I would choose to implement a more complex finite state machine for enemy AI should I use this design pattern. If applied correctly, it would enable me to implement and control the different states of an entity more easily while also decoupling and better organising my code base.

Reflection

Seeing as this was my first major game project, albeit for a high school assessment, I was fairly happy with the final product especially considering the circumstances at the time. I was able to complete the game with minimal cuts and compromises, and learnt a lot about developing games and the processes involved. Furthermore, I was able to expand my general programming and project management skills which I will be utilising for my future endeavours.

There are some things I would do differently for future projects however:

• Allow myself to be a little more ambitious with some of my ideas and not stick too rigidly to established codes and conventions just because they are easier to implement

• Avoid making levels unnecessarily large when there is insufficient content to fill them

• For games with a strong emphasis on story; I need to more thoroughly plan the pacing of my game’s narrative to be able to convey it in the most effective manner and to achieve the desired impact