Game Design and Development: Assignment 3
Game Design and Development: Assignment 3
Assignment 3
We wanted to test our game on our target audience - however we also wanted to test it on users
without a great understanding of commonly used game techniques, such as, WASD controls. We
were able to get a split of ‘gamers’ and ‘non-gamers’ to play the game which helped us identify if
the game was too difficult or too easy.
5 • Thought about controls, attempted to use the arrow keys then realised it was WASD
controls
• Issues with turning
• Was able to complete the game
P lay Test Number Questions & Responses
Despite our small sample size, we were able to gain valuable insight into the users’ experiences.
Nobody wanted to quit before completing the game, despite finding it too easy/hard, implying
that the overall experience was enjoyable. The two levels we have designed are intended to be the
starting levels, helping the player to familiarise themselves with the controls. Inexperienced
gamers have time to understand the mechanics without being overwhelmed by challenging
enemies or being overwhelmed by additional mechanics introduced later in the game.
Unfortunately, 4/5 of the testers found the camera rotation issue to substantially impact their
gameplay in a negative way. We are fully aware of this issue but could not resolve it despite our
best efforts and decided to allocate our resources towards implementing additional functionality
instead.
It was suggested to add a controls menu for clarification as we didn’t tell them the controls unless
asked, which some did whilst others only used the one spell. As a result of this we decided to
implement a “how to play” screen at game start. Experienced users may find this tedious, however
as its only being displayed once it will have no substantial negative impact.
Two testers missed every non-linear path, something we designed to reward inquisitive play and
encourage level exploration and make the levels more interesting. It gave players a feeling of
agency and that their gameplay choices impacted the way the interacted with the game.
There were multiple approaches towards player movement; one of our first tasks was agreeing
upon the control inputs, where we took inspiration from well-established games. The most
common RPG style inputs for movement are WASD, which we implemented as it is intuitive to
PC gamers, as well as using the mouse to rotate the camera around the character. The camera
rotation was implemented to the best of our ability, although it didn’t function as intended. Given
more time, this would be the highest priority improvement to make to the game.
Spell implementation was more complex than originally assumed. Inputs to swap spells included
the scroll wheel, numbered keys or a single key to cycle through them. Numbered keys were
chosen to support laptop gameplay as they often are not used in conjunction with a mouse. The
actual spell shooting process was similarly thought-provoking. We initially set the raycast to fire
from the camera to cast the spell where the mouse pointed, but soon realised it was registering a
hit on the player. This was ‘fixed’ by instead firing it from the character’s chest. The issue with
this is the inability to aim vertically. Although it does not impact the functionality, it does affect
the gameplay slightly as players may find the unconventional aiming to be unintuitive and is
something we would address if given more time. Lastly, we would implement spell animations.
The team lacked the necessary animations/resources to do so without spending money.
Our game incorporates monsters which we wanted to attack the player. An attack is initiated
using ‘OnTriggerEntrer’. The attack is triggered when the players collider enters the trigger,
causing the enemies to ‘run’ at and attack the player. The enemy’s loose health when they are
struck by a spell (raycastHit), this invokes a takeDamage method, resulting in a reduction of
health.
Adding music and sound effects was important as this also makes the game far more immersive.
We have implemented background music, we felt this was necessary as we didn’t want the game
to be played in silence as this would’ve a negative impact on the user experience. All the enemies
also have their own sound effects, these are repeated each time their ‘attack’ method is called.
One slight issue we have with the enemy sound effect is when an enemy dies, their sound effect
continues to play as they fall through the ground. The reason for this is that the player is still
technically colliding with the enemy. The sounds can only be heard for a couple of seconds after
they die however this is something we’d like to fix in the future.
We felt it was important to make our game aesthetically pleasing, creating our own assets
would've been possible, however, extremely time-consuming. We searched the asset store and
found some cave assets, this included things such as lamps, rocks, rail carts and many other useful
items (https://assetstore.unity.com/packages/3d/characters/purple-crystal-mine-113576). These
assets made our game much more immersive and it transformed our simple cave into a realistic
looking scene.
One feature we made sure to include was to publicise enemy variables so that they may be
adjusted across levels. This would allow us to make enemies harder as you get further in the game.
Similarly, the playable character has a public health and attack value to allow for modifiers (e.g.
pick up item to increase max health).
For the environment, assets were combined from multiple sources to create something visually
compatible and aesthetically pleasing, so terrain also had to be uniquely sculpted by the team. All
objects were individually placed and rotated as necessary. One of the challenges faced was an issue
within unity in handling Trees in terrain resulting in a certain lack of realism. The imported assets
required an LOD group in order to apply random rotation – but a Tree with an LOD group cannot
bend from the wind. As a result of this, objects can ONLY have either random rotation or blow in
the wind. This was worked around by applying each method circumstantially; e.g. mushrooms do
not bend in the wind, so have random rotation. For level 2, it was designed utilising the density of
trees as guidance for the player for which direction to go next. Impassable walls of trees designated
the boundaries of the play space, and more sparse regions could be investigated for less obvious
paths.
Design Process
When designing the functionality and visuals of various mechanics, we found inspiration by
researching existing games to create visual examples of the various design choices. We then
discussed each design as a group to ensure all members agreed on a single design to operate with
the same vision for each feature.
Inventory
Design 1
Inventory
Design 2
Dialogue
Design 1
Dialogue
Design 2
Teamwork and Productivity Tools
Teamwork
Overall, our team was highly productive and well-coordinated, having
regular contact through weekly meetings, and the online communication
service Discord. Everyone successfully fulfilled their responsibilities and
contributed equally to the project.
Unity Collaborate
In place of Git, we used Unity’s in-built version control system which was
extremely efficient for uploading/downloading work and effective in
avoiding merge conflicts. We created individual features in separate scenes
but had no issues in collating all work.
Trello
We created a Trello board to keep track of tasks to do, in production and
completed (along with due dates and assigned members working on each
task) as we approached the project with an Agile methodology in mind. Unity Collaborate
The tool was invaluable in making sure all tasks were completed on time
and to a reasonable standard.
Trello
Individual Mechanics
I nventory
Before work began on the inventory system, we discussed incorporating a third party asset from
the Unity asset store called “Inventory Pro”
(https://assetstore.unity.com/packages/tools/gui/inventory-pro-66801). Though this is was a
highly efficient and polished option, we decided that creating a system from scratch would better
test our skills and would allow for more customisation of the design.
Final
Inventory
The final inventory system is a 2x4 grid of tiles with icons for each currently stored item. When
an item is removed, the items shuffle backwards so all empty spaces are at the end.
There are only two items which can be added – healingPotion and manaPotion – of which only
one (healing potion that increases max HP by 10) is present in the game.
One issue with this inventory system is that pickups and changes to player statistics (e.g. max
health) do not persist between levels. As such, any items picked up in level 1 will not be present
in level 2.
Dialogue
Inspired by traditional RPGs, the dialogue system writes on screen with a typewriter effect (with
ticking sound). This was achieved using an IEnumerator coroutine that waits a set time before
typing each letter. As some players may prefer to skip this “animation”, the complete text segment
can be immediately displayed on the screen by pressing the “Return” key.
Engaging in dialogue will switch the camera to one focused on a close-up of the NPC’s face; this
gives more personality to the character.
Final Dialogue
System
The overall menu is on a canvas containing 4 child canvases (one for each menu option). When a
button is clicked, the main screen above will instantly change to the appropriate canvas for that
menu.
Final Menu
System
Plans for Expansion
Given the timeframe, we were unable to implement many features originally outlined in our
design document. The following are features/improvements we would add if given the time and
resources to expand on our submission.
Save system
• Store inventory, current/max health, quest progress, current level and player position
• 3 save files
• Select and load a given save file to continue from the point at which the game was saved
Main map
These are designs for the main map on the pause menu:
We would also allow the player to zoom in/out using the scroll wheel and drag with the left
mouse button to look around.
Settings
• Volume settings (master, SFX, music)
• Difficulty level (adjust player/enemy health and damage)
• Dialogue speed (have a faster or slower typewriter effect)
Quests
Receive quests from NPCs to store in a quest log on the pause menu. Would update as you
progress through the quest.
Merchant
Add a trading system with a merchant NPC, allowing you to buy and sell upgrades or items for
your inventory.
Melee Combat
We would allow the player to acquire a sword and attack with it at close-range.
Additional Levels
Our original goal of 5 levels was unachievable, so we focused on making two levels to a high
standard. Ideally, we would add at least 3 more levels (with associated enemies, boss and NPC
interactions).
Additional Spells
Each additional level would warrant a further spell. The new spells would represent elements we
had not yet implemented (e.g. water, earth, air). We would also add animations for each spell to
give players a better visual cue.
Ideal Render
Visual Glitch
Scripts
Enemy
• Boss Attack
o Identical to enemy attack, was intended to contain more complex functionality
such as dodge and multiple attacks.
• EnemyAttack
o Checks in Update whether player is within certain distance of enemy, if true
attack animation is triggered, attack SFX played, and if player is alive calls
function in PlayerHealth to inflict damage.
• EnemyHealth
o Maintains health for enemies; when hit by player spell enemy takes damage, if at
this point the enemy dies the appropriate animation is triggered, after this
animation plays components are disabled & enemy sinks into ground before being
destroyed.
• EnemyMovement
o Uses nav mesh to translate enemy towards player, stops movement and walking
animation when enemy is in attacking range of player.
• EnemySpawnTrigger
o Instantiates enemy object at spawn point on collision with player object.
Game Management
• GameState
o Static script to store level, progression and health variables
• LoadOnCollision
o Loads next level on collision with player object
HUD
• HUDSpellPanelCTRL
o Conceptual parent of SpellCTRL, takes keyboard input to select a spell and display
this information.
• SpellCTRL
o Changes display of spell to show if it is cooling down or available.
Player
• Attack
o Controls spell casting. Checks in Update for mouse click, triggers relevant
animation based on which spell is selected. Spell one fires a ray and inflicts
damage on any enemy that it hits. Spell two inflicts damage on any enemy within
a certain radius using Physics.OverlapSphere.
• PlayerFollow
o Controls camera movement; maintains constant position and rotation relative to
the player.
• PlayerHealth
o Makes screen flash red when player is damaged, if currentHealth falls to zero
death animation is triggered and you are returned to start menu.
• PlayerMovement
o Takes WASD input to translate player, triggers walk run and jump animations
where relevent, allows player to jump and rotates the player to face position of the
curser on screen.
StartMenu
• LoadOnClick
o Loads next scene and sets up game manager.
• QuitOnClick
o Quits game on click.
ChestAnimation
• onTriggerEnter
Level 1 Environment
• https://assetstore.unity.com/packages/3d/characters/purple-crystal-mine-113576
Spell Icons
• https://assetstore.unity.com/packages/2d/gui/icons/spellbook-preface-111069
Wizard NPC
• https://assetstore.unity.com/packages/3d/characters/humanoids/red-samurai-4331
Potion Pickup
• https://assetstore.unity.com/packages/3d/props/potions -115115
Woodland Music
• https://assetstore.unity.com/packages/audio/music/woodland-music-album-070718-
122439
Enemy SFX
• https://assetstore.unity.com/packages/audio/sound-fx/monster-sfx-111518-132868
Testing
Te st Number De scription E x pected Outcome Actual Outcome P ass /Fail
1 The player should be When the spacebar is When the space bar is Pass
able to move on the y pressed the player should pressed the player jumps.
ax is. jump.
2 The player should able to The player to move The player is able to Pass
move on the x and z ax is. forward, backwards, left move along both the x
and right. and z ax is.
3 The player should be Player sprinting when The player sprints when Pass
able to sprint. the ‘shift’ key is pressed. the ‘shift’ key is pressed.
4 The player should be The player should be The player is able to Pass
able to interact with able to talk to NPCs. interact and talk with
NPCs. NPCs.
5 The player should be If a player finds an item When an item is found, Pass
able to collect items they they collect it and store it’s picked up and stored
find in the levels. it in the inventory. in the inventory.
6 Items should be All of the players’ items Players can pick up items Pass
accessible from the should be accessible and add them to their
inventory. from the inventory. inventory.
7 The player should be The player to attack tow The player is able to Pass
able to cast spells to enemy using a spell. attack the enemy using a
attack enemies. spell.
8 User controllable The player should be Not enough time to fully Fail
settings able to adjust sound implement
volume/ difficulty/
dialogue speed
9 The players position The user should be able The user is able to see Pass
should appear on a mini- to see where the player where the player is.
map. is using the mini-map.
10 Heads-up display, The heads-up display to The heads-up display Pass
showing current, spell, clearly show all the clearly shows are the
health and currency. useful information. important information.
11 Comprehensive menu A start and pause menu, The game can be paused Pass
system using the ‘p’ key.
12 The player should have Different animation for There are different Pass
animations for each player movement and animations for waking,
unique action. firing spells. running and firing spells.
13 The camera should The player should The player is always Pass
always follow the player. always be followed by followed by the camera.
the camera.
14 Implement as ‘quest Quest tracking system to Menu made, not enough Fail
screen’ help users identify time to fully implement.
current objective.
15 Enemy's should have When an enemy is When the enemy is Pass
sound effects. attacking a sound effect attacking a sound effect
should be played. is played.
16 Player sound effect for When the player shoots When a spell is ex ecuted Fail
spells. a spell, a sound effect a sound effect is played.
should be played.
17 Animation for spells When a spell is fired an No a nimation is shown to Fail
animation should be represent the spells a s they
were una ble to be sourced.
fired.