0% found this document useful (0 votes)
111 views

Game Design and Development: Assignment 3

- The document describes user testing conducted on a game created by the authors, including observations from 5 playtests and feedback from questionnaires. - Most testers understood the controls but had issues with camera rotation, and all wanted to complete the game despite difficulties. This suggested the overall experience was enjoyable. - Based on the testing, the authors decided to add a controls explanation screen and work on improving the camera controls in the future. They were also able to gather requirements for difficulty progression and level design.

Uploaded by

James Cunnigham
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
111 views

Game Design and Development: Assignment 3

- The document describes user testing conducted on a game created by the authors, including observations from 5 playtests and feedback from questionnaires. - Most testers understood the controls but had issues with camera rotation, and all wanted to complete the game despite difficulties. This suggested the overall experience was enjoyable. - Based on the testing, the authors decided to add a controls explanation screen and work on improving the camera controls in the future. They were also able to gather requirements for difficulty progression and level design.

Uploaded by

James Cunnigham
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Game Design and Development

Assignment 3

Richard Matthews - 182587


Amber Shamsi - 181393
James Cunningham - 181308 Daniel Payne - 181417
User Testing
Whilst conducting user tests it was important to let the user play the game before we would ask
them any questions. Whilst playing the game, we observed the testers and took note of any
problems they encountered. Afterwards we asked them to answer a few simple questions to help
us gain an understanding of their experience.

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.

P lay Test Number Observations

1 • Understood the controls straight away


• Was able to understand the attack functionality
• Got stuck against a wall
• Was able to fully complete the game

2 • Unsure of controls at first, tried using arrow keys


• Attempted to run past the first enemy.
• Some issues when turning around
• Was able to complete the game

3 • Understood the controls straight away


• Attacked the skeleton straight away, instantly picking up the controls
• Was able to complete the game
• Didn’t use the turn camera functionality, making the spells much easier to land

4 • Understood the controls straight away


• Explored the entire level
• Camera issues when trying to turn around
• Was unable to complete the game first try

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

1 What was the most fun thing about the game?


“… attacking the enemies”
What was the most frustrating thing about the game?
“Rotation Controls”
If you could change any aspect of the game or your experience, what would it be?
“Fix the camera… add in collectables to restore health”

2 What was the most fun thing about the game?


“it was pretty”
What was the most frustrating thing about the game?
“Understanding the controls”
If you could change any aspect of the game or your experience, what would it be?
“Add a menu that describes how to play the game”

3 What was the most fun thing about the game?


“Exploring the levels”
What was the most frustrating thing about the game?
“Nothing”
If you could change any aspect of the game or your experience, what would it be?
“Fairly easy, needs to be more challenging”

4 What was the most fun thing about the game?


“Fighting the boss at end”
What was the most frustrating thing about the game?
“…enemy went behind me… was difficult to turn around”
If you could change any aspect of the game or your experience, what would it be?
“…almost missed non-obvious features.”

5 What was the most fun thing about the game?


“Exploring the maps”
What was the most frustrating thing about the game?
“Can’t see where you are aiming”
If you could change any aspect of the game or your experience, what would it be?
“… change the difficult controls”

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 dialogue system was designed for quick


expandability, so was developed as a state machine: this
allows for states to be created and customised entirely
within the Unity editor, meaning the code does not
need to be edited.

Edit State options within Unity

Creating a State from the Unity editor


Menu System
Navigation is achieved through a simple set of clearly named buttons; this makes it immediately
clear how the menu is operated without the need for instruction.

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.

Visual Glitch Fix


In level 2, the trees used as part of the environment display differently depending on the machine
on which they’re run. We would like our game to show our “ideal render” (see below) on every
machine.

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

◦ Activates the second spell and opens the chest.


Dialogue
• DialogueTrigger
◦ Detects when a player is close enough to an NPC to initiate a dialogue sequence and
updates the UI accordingly.
• Dialogue
◦ Handles input during dialogue interactions and causes text to be displayed with a
typewriter effect.
• State
◦ Stores information about a dialogue “state” for creating dialogue sequences
Pause Menu
• MenuScript
o Opens/Closes menu when “P” key pressed and pauses/un-pauses the game.
• ButtonPress
o Checks which menu button was pressed and loads the corresponding canvas.
I nventory
• InventoryManager
o Handles adding and removing items from the inventory.
• HealingPotion
o Healing item with name, description and image to be stored in inventory.
• ManaPotion
o Magic item with name, description and image to be stored in inventory.
• IItem
o Interface inherited by HealingPotion and ManaPotion; ensures items are
standardised to work with the inventory system
Pickups
• Potion
o When player makes contact with potion, their current and max health will be
increased by 10. A health potion will be added to the inventory and the
gameObject will be destroyed.
• HealthPickup
o Upon player collision, current health increases by 10. Pickup also rotates.
GameObjects
• Player
o Moves in scene, has health & attack functionality. Interacts with enemies and
NPCs.
• Wizard (NPC)
o Used for narrative dialogue purposes.
• Health Potion
o When picked up, will add 10 to the player’s max and current health. The object is
then destroyed.
• Enemies
o Cyclops
▪ Main boss enemy that occurs at the end of the level.
o Giant Rat
▪ Basic Enemy that follows player and attacks when close.
o Skeleton Knight
▪ Basic Enemy that follows player and attacks when close.
Externally Sourced Assets
Enemies:
• https://assetstore.unity.com/packages/3d/characters/creatures/heroic-fantasy-creatures-
full-pack-volume-1-5730
o Skeleton Enemy
▪ https://assetstore.unity.com/packages/3d/characters/humanoids/skeleton-
knight-283
o Giant rat
▪ https://assetstore.unity.com/packages/3d/characters/creatures/giant-rat-
3641
o Giant cyclops
▪ https://assetstore.unity.com/packages/3d/characters/humanoids/giant-
cyclops-14142

Level 1 Environment
• https://assetstore.unity.com/packages/3d/characters/purple-crystal-mine-113576

Player and Spellcasting Graphics


• https://assetstore.unity.com/packages/vfx/particles/spells/realistic-effects-pack-4-85675

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

Dialogue Typewriter Sound


• https://www.freesfx.co.uk/

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.

You might also like