Game Basic Information

Summary

KnightQuest is a 2D platformer with simple sword combat mechanics. The goal of the game is to traverse various obstacles and platforms while attacking or avoiding various enemies. The level begins relatively straightforwardly, but increases in difficulty the further you progress in the map. The map's platforming will grow more difficult to complete, while variations to the slime enemies will make avoiding or defeating them more challenging as well. Through the map, the player will encounter deadly spikes both static and falling, disappearing platforms, exploding enemies, and moving platforms. The player wins when the finally reach the end of the level and save the captured royal family.

Play the WebGL build online here

Gameplay Explanation

Gameplay in KnightQuest revolves around moving or jumping to traverse obstacles or avoid enemies, as well as attacking. The A and D keys are used to move left and right respectively, while the spacebar allows the player to jump. Pressing spacebar again after having jumped allows the player to jump one more time before landing. Pressing the left mouse button for fewer than 2 seconds will perform an attack, while holding for 2 or more seconds will perform a heavy attack. Players can also move faster by rolling with shift. When the player touches a slime, they will take damage, indicated to the player by a reduction of their health bar. Players may encounter chests that restore health when stood on. Platforming generally requires good timing to ensure that the player does not land on an enemy or fall off a platform. At certain point, players will reach checkpoints that will update where they spawn on death.

Main Roles

Your goal is to relate the work of your role and sub-role in terms of the content of the course. Please look at the role sections below for specific instructions for each role.

Below is a template for you to highlight items of your work. These provide the evidence needed for your work to be evaluated. Try to have at least 4 such descriptions. They will be assessed on the quality of the underlying system and how they are linked to course content.

Short Description - Long description of your work item that includes how it is relevant to topics discussed in class. link to evidence in your repository

Here is an example:
Procedural Terrain - The background of the game consists of procedurally-generated terrain that is produced with Perlin noise. This terrain can be modified by the game at run-time via a call to its script methods. The intent is to allow the player to modify the terrain. This system is based on the component design pattern and the procedural content generation portions of the course. The PCG terrain generation script.

You should replay any bold text with your relevant information. Liberally use the template when necessary and appropriate.

User Interface (Ronvic Cuevas)

Describe your user interface and how it relates to gameplay. This can be done via the template.

The user interface is designed based on the core game logic and giving necessary information to provide better user experience for the players. Our game is a platform game and providing these five scenes helps the players to interact to the game itself. Any button that has been designed has a hover shadow in order to let the player know that this is the UI button they are choosing. When the button gets darker, it means the player click that button and proceed to the next menu or scene. The hovering allows the players to be more interactable with the UI itself.

Easy Scene - This Scene provides "Easy Difficulty" gameplay where their less enemies and the enemies are weaker.
Ending Scene - This Scene provides "Ending Menu Scene" where it asks the player to play again or go back to the main menu.
Hard Scene - This Scene provides "Hard Difficulty" gameplay where their more enemies and the enemies are stronger than "Medium Difficulty". The difference with this difficulty is that the enemies will respawn to its own position when the player dies.
MainMenu Scene - This Scene provides three things "Play Game", "Controls" and "Quit" button.
Medium Scene - This Scene provides "Medium Difficulty" gameplay where their more enemies and the enemies are stronger than "Easy Difficulty".

Gameplay UI

The Gameplay UI provided tons of pop-up menus which allows the players to explore and have more fun with the game.

Pop-up MainMenu - This is the main scene when you are about to start the game. Players can look the controls before they start the game.
Pop-up ControlMenu - This menu provides players to look at the controls before they start the game. Based on the feedback from other players non-group members, they are quite confuse on what are the controls of the game. So we decided to add a control menu in order to help the players play the game without guessing the controls. These control menu only provides on desktop version, since the mobile version are pretty straightforward.
Narrative(Mission) UI - I added a mission narrative UI to explain the objective of the game and explain a mini-backstory.

HealthBarUi - The HealthBar UI is anchored to the top left of the screen to adjust to any resolution, as well as communicate with the player how big is the damage that is taken from the enemy. The HealthBar of the player is set into 100 HP. The Player will be taken damage if the enemy collided onto the player. Health is checked on every update and the UI is updated accordingly under KnightController Script

Movement/Physics (Donald Chan)

Describe the basics of movement and physics in your game. Is it the standard physics model? What did you change or modify? Did you make your movement scripts that do not use the physics system?

A standard physics system was used when movement was being implemented into the game. Our team decided to use a prefab that was found on the Unity Asset Store, which included some premade movement options. In addition to modifying the premade movement options, we also implemented our own movement moves, such as double jump and a heavy attack.

Right Character Movement Class

Left Character Movement Class

Character Roll Movement Class

All other movement related functions

Animation and Visuals (Rajesh Mudaliar)

List your assets including their sources and licenses.

Third-Party

https://assetstore.unity.com/packages/2d/environments/2d-platfrom-tile-set-cave-61672 (Standard Unity Asset Store EULA License)
https://assetstore.unity.com/packages/2d/characters/hero-knight-pixel-art-165188 (Standard Unity Asset Store EULA License)
https://stealthix.itch.io/animated-slimes (Creative Commons Zero v1.0 Universal License)
https://assetstore.unity.com/packages/2d/characters/pixel-monster-pack-75508 (Standard Unity Asset Store EULA License)

Self-Made

Royal Family Members: https://github.com/breliu-dv/KnightQuest/blob/main/Assets/SelfMadeAssets/RoyalFamily/royal_pixel.png

Modified

Hero Knight Charging Sprites:https://github.com/breliu-dv/KnightQuest/blob/main/Assets/Imported%20Assets/Hero%20Knight%20-%20Pixel%20Art/Sprites/HeroKnight-charging.png
Hero Knight Charge Attack: https://github.com/breliu-dv/KnightQuest/blob/main/Assets/Imported%20Assets/Hero%20Knight%20-%20Pixel%20Art/Sprites/HeroKnightChargeAttack.png
Animated acid Tile: https://github.com/breliu-dv/KnightQuest/blob/main/Assets/Tilemaps/Acid_Animated_Tile.asset

Self-made Animation related items

Describe how your work intersects with game feel, graphic design, and world-building. Include your visual style guide if one exists.

Together with Brandon, I was responsible for designing all the levels and game mechanisms. I helped decide what the map will look like, what each specific area of the map should look like, where the traps and the enemies should be placed, as well as what everything should look like as the person in-charge of gathering all the art and animation related assets.

I gathered the assets by searching the unity asset store, itch.io, or just general Google searches. All the art we used was free and licensed to be used freely by us.

When I couldn't find an asset online, I created them on my own using Piskel, an online free sprite editor. This is how I made all three of the royal family members assets.

When it came to animation, most of them were provided by the third-party asset makers themselves. Our team just had to figure out how to trigger them appropriately. When we needed an original animation, like for example the Charging attack related animations for the knight, I made them again on Piskel. I edited the original sprite to make it look the way we wanted and got it to work during animations.

Input (Ryan Wong)

Describe the default input configuration.

The default input configuration is basic left, right movement with 'a' and 'd'. The jump and double jumps will be controlled by the spacebar. The roll mechanic is controlled by left shift. A string of normal attacks is controlled by a sequence of left clicks. Holding the left click for more than 2 seconds will execute a heavy attack.

Add an entry for each platform or input style your project supports.

Mobile

The mobile version uses a touch screen joystick to control the player movement. There will be labeled buttons on the UI of the mobile version to prompt different attacks and character movement.

Desktop

On detection that the game is not ran on a mobile platform, all the mobile input UI would be removed.

Web

Game Logic (Henry Chou)

To implement the core game logic systems of our game, which is our AI for the slime enemies, first, the AI for the green, blue, and red slimes were implemented according to the specifications that we defined for each of the types of slimes. For the green slime, I created green slime controller script where the green slime will move back and forth between two position values in the X axis, while ensuring that velocity and health values are managed properly within the code as the player attacks the green slime and also when the green slime attacks the player. For the blue slime, the underlying AI logic had to be implemented in an more intricate manner as the slime has to not only chase the player but also ensure that it does not move outside of a predefined boundary, get stuck behind an obstacle or wall, as well as only jump when it is supposed to jump.

For instance, when the knight gets within the chasing boundaries of the blue slime, the blue slime will start to chase the knight and also jump at random intervals during the chase. When the slime reaches a ledge, it will also jump to avoid falling off as well. These logical systems of the behavior of the slime are defined in several sets of if conditions within the update function of the blue slime. This required me to effectively test and note the different ways and edge cases that the slime would behavior depending on whether it hits an object, encounters the player, among other things so that the behavior of the slime is more realistic, exciting and also responsive in a life like manner. On the other hand, the behavior for the red slime is very different from the blue slime, as it chases the player and always jumps regardless of the situation that it encounters which forces the player to adjust its attack strategy from the blue and green slimes.

Besides the slimes, I also managed other important game systems and the underlying logical implementation of those features. Falling spikes, moving platforms using MoveTowards between two defined locations, disappearing platforms, a lake full of poisonous acid, as well as the varied terrain all add on the difficulty and excitement during game play. While moving and disappearing platforms can change the player's position (such as falling off of a disappearing platform or moving along with a moving platform), spikes, acid, and enemies all alter the player's health value when the enemies perform damage to the knight. On the other hand, the player's health can also be boosted with a treasure chest, which also alters the player's health value by setting the knight's health value. Most notably, the moving platforms are implemented using a coroutine design pattern to effectively represent the different states needed to control the behavior of such platform. Coroutines are useful here as this allows for the efficient modularization of the different stages of a disappearing platform and allows for good reusability of the different routines depending on the situations encountered during game play.

The player's attack is implemented by calling the take damage function of the slimes, therefore allowing for an effective ability for the slimes to know that they have been damaged by the knight's attacks. The player must be grounded to perform certain actions, however, and so the logic for detecting if the player is on the ground is implemented using the draw ray function, which will allow the movement functions to function properly with the state of the grounded boolean.

Last but not least, another important design pattern that was used is the observer pattern of which was modified and adopted from exercise 3. This effectively allows the slimes to re-spawn after they die during the hard difficulty of the game in a modular and easily maintainable manner. When the slimes die, aside from the usual logic to handle the disabling of the slime, they also automatically subscribe to the re-spawn group and when the player plays the hard difficulty, then the re-spawning of the enemies gets triggered when the knight re-spawns from its own death.

Sources used:

Tutorial for animated slimes

For creating raining spikes

Tutorial for creating disappearing platforms

For creating a patrol path for enemies

For making explosions for red slimes

Tutorial for moving platforms

Producer (Brandon Liu)

For my role as producer, I helped to coordinate group work by making sure tasks were completed on time and by helping communicate between roles for tasks involving multiple people. I also helped schedule group meetings and led discussions on the design of the game and the implementation of mechanics. I worked to ensure that tasks being worked on did not conflict with each other. In cases where two or more people needed to work on the same files, I worked to ensure that merge conflicts were managed correctly. Because we needed to be able to test out basic mechanics like movement and attack, I proposed creating a prototype map so that our different roles could begin working even when the map was not yet implemented. This allowed our movement and input people to start working, while we could also begin work on figuring out how mapping using tilemaps worked.

https://github.com/breliu-dv/KnightQuest/commit/8cd2b996a207d4090f8dab8f60e6dad5f88f9794

https://github.com/breliu-dv/KnightQuest/commit/77db96442d857c775014e33d261fa940d139bf99

In a later meeting, I met with Rajesh to actually go about designing the map in figma. During the meeting, we spent time discussing how the player would move through the level and what sort of progression there would be. I made sure in that discussion to consider the enjoyability of certain obstacles, the potential for some degree of learning and exploration for the player, as well how difficult implementing certain mechanics might be. In regards to that last point in particular, I made sure to limit our ideas such that those implementing the mechanics would not find it overly complicated to do so. Finally, after we finalized the level, I spoke in a separate meeting with Ronvic and Henry, our UI person who would be handling the map implementation and our Game Logic person who would be implementing many of the mechanics respectively. I explained alongside Rajesh our proposed plan for the map, heping to answer questions they had regarding the specific details, such as the behavior of the three slime enemies as well as the trap and obstacle mechanics.

Other meetings were similarly focused around ensuring that everyone understood who was working on what, as well as on discussing possible ways of implementing our ideas. Additionally, I considered input from team members on how much we could complete on time and adjusted our scope accordingly. I also led meetings other times to discuss the process of merging branches. For tasks distinct from each other, I created new branches so that team members could work on their systems separately without having to worry about merge conflicts. When we each reached a stage where our systems were functional, I arranged those meetings so that I could discuss with group members how the merges should occur and which changes could be overwritten. If a file could not be merged seamlessly, one variant was discarded and I worked to reconcile changes after performing the merge to ensure that everything still worked properly. The link below is a list of some merges for branch pull requests.

https://github.com/breliu-dv/KnightQuest/pulls?q=is%3Apr+is%3Aclosed

In addition to merges, I helped with assorted coding tasks which either fixed bugs/issues or implemented certain systems while others were working on their tasks. Below are some example commits.

Sub-Roles

Audio

The implementation of audio for this project uses a slightly modified version of the SoundManager introduced in exercise 1. As an adjustment, the SoundManager class has an added function for handling notifications of hits by the player on an enemy. When a player’s attack contacts an enemy, it calls the NotifyHit function in the SoundManager class. That function randomly selects one of the five hit sound effects it has then plays it as a one off. For red slimes which explode, they call the NotifyExplosion function to trigger the explosion sound effect. Additionally, there is a background music track that loops continuously from when the game starts.

In general, the sort of sound style that was aimed for in the game was informed by the visual style we chose. Because the visuals fell within the pixel art end of the spectrum, sounds and music that might be considered 'retro' were chosen. This is why the background music is a chiptune track called “Dance Till You Die.” The track has a somewhat lively feel that matched the tone of the game, since the player is attempting to be vigilant against enemies and obstacles. There was some consideration for the use of a more medieval sounding piece given that the game is about a knight trying to rescue the royal family, but these tended to be too mellow or melancholic sounding, which led to the selection of the piece that was ultimately chosen.

In regards to the sound effects, these were similarly ‘retro’ sounding in theme. The pack from which the enemy damage sound effects were procured from labeled the sounds ‘retro,’ and these sounds seemed to work well for providing feedback to the player that their attack successfully connected. This is important for both game feel and for ensuring the player is not left wondering whether their attack missed. It is especially important when attacking enemies who take more than one hit to defeat. A random sound from the set of 5 hit sounds is played so that it does not sound repetitive when the player is performing attacks. The explosion sound effect is used when a red slime collides with the player, which triggers it as explained previously. This sound effect is also an 8-bit sound, in keeping with the style of the other sounds. While the sound effect itself is perhaps more like a firecracker in terms of sound, this means that it may also be less grating too hear when it is played multiple times, as may be the case when the player is surrounded by red slimes.