Games Development - Final Project: Playable Game

 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

Scripts Overview

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.

StartScene - Overview

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.

InstructionScene - Overview

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.

EndScene - Overview


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.

Player - PolygonCollider2D

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.

Enemy and Enemy Projectile - Overview

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.

Final Boss (Enemy) and Special Projectile - Overview

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

This is the overview of the Game UI. There are health bar that indicates the player's health level. The middle bar is the sword progression this particular UI acts as the level progression whereby the player needs to collect the sword first to be able to activate the HoldToLoadLevel script. 

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.

Unity - Build Settings

Netlify - Overview

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 Project - Game Overview

Final Submission for Games Development - Final Project


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