Week 11 - Week 15
Ahmad Firas Bin Ahmad Fisal | 0345121
Games Development | Bachelor of Design (Hons) in Creative Media
Final Project: Playable Game
INSTRUCTIONS
TASK 03: GAME PROTOTYPE (Status: Completed)
We are required to produce a fully functional and playable game.
--
As a continuation from the previous task which was the prototype, I mainly
showcase the player's movement, sprite, the ground layers, the heart
collectable, the trap placement, the temporary enemy placement indicator, the
sword that is at the end of a level to enable users to load the next level.
After submitting task 03: prototype, I faced many challenges and obstacles
that built up my frustrations. I continued with building the rest of the game,
which I will list below; however, creating a multi-level game is more than
just copying and pasting assets from level 01 and applying them to the next
levels. This was proven to me when I encountered scripting issues where
scripts that were applied and activated in level 01, weren't activated in
levels 02 and 03.
Because of that, I stumbled across this video tutorial where you can do
multi-levels in one scene file. So that your scripts, Game UI, etc. are not
separated and this minimises risks or it not working well. As hard as it may
be, moving on was the only way we could go and the process of fine-tuning and
adding features to our work was very rewarding although when errors came, I
felt like the whole game was falling apart and that caused me to be really
anxious and stressful. If one experience could describe how game
development truly is, it would be the constant need to debug your scripts and
fix them blindly that can go up to hours for a simple mistake in the
scripting, that's the experience.
Due to this, I had to reset my development framework and find the balance
between executing my original idea with the time it will take for me to
complete it as they are not as easy as it may seem. Especially, with the
remaining time you have left until the deadline.
The flow of this blog;
- Total Scripts
- Levels
- Scenes and Tilemaps
- Player
- Enemy
- Obstacles
- Items
- Game UI
- Music
- Building & Deploying
--
Progression
Scripts
Game Controller:-
- GameController
This script holds the most linked variables and logics. The brain of the
entire script as they handle bits and bits of the overall gameplay and
functionalities.
Scenes ;-
- StartMenuController
Handles the functionality and navigation of the start menu to the instruction
scene.
- InstructionSceneController
Manages the instruction scene where players can learn how to play the game.
- EndMenuController
Controls the end menu displayed after the game is completed. The condition to
trigger this is only if the BossDefeatChecker logic is activated which also
only be activated if the Enemy I assigned to be the boss in the inspector.
EndScene scene, EndMenuController.cs, BossDefeatChecker.cs, and EndTrigger
GameObject work together.
- HoldToLoadLevel
Implements a "hold to load" mechanic for transitioning to the next level,
requiring the player to hold a button for a specified duration only if the
sword has been collected. This is linked to the Sword level progression
slider.
Environment Background & Music:-
- BackgroundController
Manages the background image for each level for the infinite scrolling
logic.
- MusicManager
Handles the background music and it is linked to the music controller UI
in the game with a slide, so players can slow down the volume as they
please.
- CameraController
Controls the camera behaviour, ensuring it follows the player and respects
level boundaries. (currently deactivated)
Collectables & Health:-
- HealthUI
This script controls the UI of the health on the screen which reacts to the
heart collectables and it will directly update the status of the health on the
screen.
- HealthItem
Defines health items that the player can collect to restore the health of the
player.
- Sword
The sword pickup is an essential part of the game, it is the condition set to
load the next level. If not collected, players can't move to the next level.
- Trap
A spike trap that will cause damage to the player when in contact. The
perimeters of the damage and effects are defined here.
- IItem [To control the Collect logic for other collectable scripts]
- Collector
An interface for implementing the Collect logic in collectable scripts.
Handles the collection of items by the player, interfacing with various
collectable scripts. These two scripts work together with the rest of the
relevant scripts.
- *LivesManager [Deactivated]
An old script that was used in the prototype stage, handles the destroying of
the heart object logic but wasn't doing anything to the health in particular.
Used for showcasing only.
Player:-
- PlayerMovement
- PlayerHealth
- PlayerAttack
- Projectile
- FallTrigger
- Checkpoint
These scripts control the player's movement and manage the player's health
which includes taking damage and healing. Linking them back to relevant
health scripts. Attacking is also handled here, combining it with the
Projectile script to define the behaviours of the projectiles fired by the
player. This was made separately for organisational purposes.
Whereas the Checkpoint and FallTrigger scripts, they were created because,
before the the FallTrigger, nothing was happening if the player fell between
the gaps. So now, when I added that script in, I made it call the
GameOverScreen game object that I've made. This particular GameOverScreen
also comes with clickable and functional retry and exit buttons.
Additionally, the checkpoint was created because when I decided to do a
multi-level game in one scene, and if GameOverScreen was triggered and the
retry button was clicked, the system was confused about what to show after
the retry button had been clicked. So, in this particular script, logic like
level indexes are there to ensure that in which level you are retrying, you
will respawn at the same respective level that you died in.
Enemy:-
- EnemyPatrol
- EnemyHealth
- EnemyAttack
- EnemyProjectile
- BossDefeatChecker
- FinalBossAttack [Deactivated]
- FinalBossHealth [Deactivated]
- FinalBossPatrol [Deactivated]
- FinalBossProjectile [Deactivated]
These scripts control the enemy patrol behaviours which is also their main
movement between set waypoints and idle states/duration. EnemyAI doesn't
require a movement script such as the player because we will not be
controlling the enemies ourselves. Besides, health is also managed here
including their taking of damage action and triggering hurting and dying
animations. This is also where I added an IEnumerator and coroutine logic to
make the enemy flash red upon hit. Just like the player, the enemy also has an
attack and projectile scripts that control their ranged attack where
projectiles will come out of the shooting point. Everything from the speed,
attack range, and player detection, can be manually controlled by the
inspector. As mentioned, the BossDefeatChecker is a conditional script where I
could drag my enemy prefab into the inspector and this script will be applied.
So, only when the player kills the final boss, this checker will activate the
EndTrigger GameObject which is also linked to the EndScene scene. To control
the EndScene, this is where the EndMenuController script comes in with the
functionalities of the buttons
*[Deactivated] - Enemy
FinalBoss scripts are deactivated due to the issue I faced in making the final
boss work. I've tried doing it and it requires more time to further refine it
which we don't really have anymore. This is why I decided to change part of
the game course to Orc Berserk enemies only. To differentiate the normal Orc
Berserk enemy and the final boss Orc Berserk is by the increase in size and
also the boss's lives.
Levels
The images attached below are the overview of all three levels of the game.
Child layers are organised well under their respective parent. As mentioned, I
am continuing with this approach of having multiple layers under one scene for
script management purposes. I've tried the usual route of linking scenes with
scenes, but there are too many errors appearing that were preventing me from
moving forward with the project with the limited time duration left.
|
| Level 01 - Overview |
|
|
Level 02 - Overview |
|
|
Level 03 - Overview |
Scenes & Tilemaps
ForestTiles and CastleGroundTilemap are two tile palettes that I've imported
and used for this entire game project. It has been used dynamically from the
background, ground, and foreground on the respective levels.
|
| Tile Palette 01 |
|
| Tile Palette 02 |
What you see below is the StartScene that I've created to be the home page of
the game when players first click on my game. There are the main title, credit
information, and two clickable buttons at present in this scene. I linked the
Start Button to the next scene which is the InstructionScene where the player
will learn the controls and tips of the game.
The StartScene, InstructionScene, and EndScene have similar concepts in terms
of executing it, as you can tell the way the hierarchy is filled up and
expanded is almost similar. Here, players click on the next button that will
bring them to the game playing/levels which is SampleScene.
This is the EndScene, the making of this scene involved conditional perimeters
that needed to be met first before being able to trigger this Scene. I've
created a script called; BossDefeatChecker and a game object called End
Trigger at the very end of the last level. Only when the boss has been killed,
the end trigger work and will bring the player to the EndScene which is the
victory message. However, if the boss has not been killed, the trigger will
not react, even with the collision of colliders.
Player, Enemy
Starting off for Player, the picture below is a Polygon Collider that I've
used that acts as the game's boundaries. When linked to the PlayerCam
settings, it becomes the new boundary for the camera and cinemachine settings
to follow.
As mentioned, under the inspector of the PlayerCam, there is a cinemachine
attached in the inspector and the polygon collider is now dragged into the
panel so that it's now integrated.
|
| PlayerCam - CineMachine |
As for the movement of the player, it seems like a great addition to
introducing the particle effects to the player. As you can see from these two
images below, there is a detailed showcasing of the SmokeFX and also a demo
picture of how it looks when it's jumping. Even when moving around the game
left and right will also have this trail of particle effects.
|
| Player - Particle Effects (SmokeFX) |
|
| Player - Particle Effects Demo (SmokeFX) |
The image below showcases what the projectile of the player for the ranged
attack would look like:
|
| Player - Projectile (Attack) |
Moving on to Player's animation, this is a screenshot of how the animator
window looks like for the player. Different variants of animations are done
here; Idle, Jumping, Walking/Running, Attacking, Hurting, and Dying.
![]() |
| Player - Animation |
This is an overview of how the orc berserk (enemy) would look in the project's
stage. There are scripts such as EnemyHealth, and EnemyAttack attached to the
enemy to ensure that they can be hurt and also attacking the player would be
the command upon detecting the player nearby.
There is also a script that controls the enemy's patrol movement. As you can
see in the scene, there are two purple dots on the left and right of the
project's scene. These are patrol points for the enemy to move back and forth.
The yellow dot that we can see at the tip of the enemy's sword would be the
shooting point. This is where the enemy's projectile would start from. I've
encountered issues such as the projectile not shooting according to the
flipping of the enemy and whatnot, but those are now fixed accordingly.
This below is the final boss's orc berserk enemy. To differentiate, I have
made the final boss orc berserk noticeably bigger than the normal version as
an indication that it is harder to kill, fiercer, and more. Even the
projectile for the final boss berserk is different from the normal one, they
are fireballs projecting out instead of the normal diamond-shaped projectile.
Just like the player, the enemies have their animations set up as well.
![]() |
| Enemy - Animation |
Obstacles & Items
The trap spike is attached to a script that allows this obstacle to deal
damage and a little bounce effect on the enemy when colliding together. This
trap was placed strategically and exponentially more as the game level
increased.
As for the heart collectables, the player can collide with this item and their
health will regain from any damage taken prior, The increment in health can be
seen from the health bar that could be seen further below of this blog under
the Game UI section.
|
| SpikeTrap and Heart - Overview |
This sword acts as the game's level progression indicator. I have linked and
made it in a way that only when the player collects this sword, the slider bar
progress will show that it's full and now players can hold the key 'E' to load
to the next level.
|
| Sword - Overview |
Game UI
The most right slider is an interactable bar, where that controls the volume of
the game's background music. It will be further explained down below for the
whole music-embedding process.
|
| GameUI - Overview |
This is the GameOverScreen where there are buttons like Retry and Exit. This
game object is controlled by the GameController script. There are a whole
bunch of OnReset logics that are called so that the collectables can respawn
at the original position when the player clicks Retry
**However my main issue with this game is the inability to continue
debugging on how to get the enemies, both normal and final boss to react to
the OnReset function properly. Although the game is playable, for example at
the particular level you're in, and you have killed 3 out of 10 enemies of
that level when game over is triggered and retry has been clicked, you can
restart back at the start of the level (this part is handled by the
Checkpoint script where current level index logics are called) but without
the first three enemies respawning at their position. Only the remaining 7
enemies are there.
|
| GameOverScreen - Overview |
This is the demo of the radial circle animation that appears at the top of
the player when the sword progression bar is filled and the player is
actively holding the key 'E', to load to the next level.
|
| Level Loader Animation - Overview |
Lastly, it would be the MusicManager object, this is where the background
music is controlled throughout the whole game. Settings like looping,
volume, play on awake, etc could be controlled by the inspector of the music
manager. It is also linked to the MusicManager script where we can drag the
music that we would like to use in the inspector section so that the
particular music is activated upon playing the game. The game UI and music
slider are also attached here from the hierarchy so that the interactivity
can be activated.
|
| MusicManager - Overview |
Moving on to the building and deploying stage of this project, I watched a
video online on how to build our game. In summary, getting the scenes
ordered correctly in these particular settings ensures that the scripts that
are handling the scene transition can happen smoothly. I also need to switch
my platform from Windows, Mac, and Linux to WebGL because that is the
requirement set by our lecturer.
At first, I continued building the game without changing the compression
settings and tried deploying it on Netlify, however, that caused a failure
with an alert mentioning the file. The solution to this was initially
provided by a classmate of mine but also confirmed by our lecturer after
making the necessary changes in the compression setting so that this error
could be removed entirely. Making our game playable after re-building it
with the compression setting now changed.
After successful build-up of the project, I proceeded with changing the URL
of my game project into something more recognisable and the image below is
the game overview when I clicked my game link.
Final Submission for Games Development - Final Project
Netlify Link: https://firasfisaldesign-enchantedquest.netlify.app/
Video Presentation:
*This video combines the walkthrough (0.00-4.47 minutes) and explanation presentation (4.48 minutes onwards)
Updated Game Design Document:
Reflection
The Games Development module got me thinking of the life choices I've made and made me doubt myself so much. The workload in this module was too much, it feels like when someone superior is putting unrealistic expectations on you. 3-level full game development was too much for someone who is not even acquainted with coding at that level. I've talked to my programme director and asked her why wasn't this module choice for those who take UI/UX specialisation and made it compulsory for Entertainment Design instead? I was super stressed with the module which caused me to visit the clinic two times in a month and I'm still down with this cough up to the submission date of this module. Countless migraines, dehydration, 12 hours on the screen minimum every day and sleeping at 5am every night. I don't know if it was worth it doing all that at such expense.
Regardless, I am very much proud of my overall outcome and nobody can tell me otherwise. My game is playable up to the very end with issues here and there in between. Although the outcome might deviate from the original design document proposed, I feel like this deviation shouldn't be the primary focus. The focus should be on the ability to complete what's needed to complete at the end of the day and to persevere.



























Comments
Post a Comment