Hisham Jarad – MA Games Design

Parrs Wood Zombies DevLog

Post author By Hisham Jarad
Post date 1st December 2022
No Comments on Parrs Wood Zombies DevLog

Final Major Project

Game Overview

Throughout my teens I clocked an unquestionable amount of hours playing Call of Duty: Black Ops Zombies. The endless survival aspect was an addictive trait for a game, as my friends and I would always try to best each other’s highest rounds or work together to achieve our own high scores. During my time at Parrs Wood High School I had always dreamt of transforming its terrain into a virtual playground to fight against the undead in similar fashion to what I had experienced in Black Ops Zombies. Parrs Wood Zombies is my first endeavour in bringing that dream to reality.

Parrs Wood Zombies is fundamentally a First-Person Shooter game, with the similar endless survival feature to that of Black Ops Zombies. Boasting a virtual recreation of a real-world geographical location, Parrs Wood Zombies is a coalescence of 3D modelling forged in Blender, and algorithmic programming engineered in Unreal Engine 4 (UE4).

Aims

Successfully recreate a 1-1 rendition of a real-world geographical location
Through Level Design, interpret the game world to reflect the zombie genre
Create an endless game-mode including a progressive increase in difficulty upon each spawning wave of enemies
Implement various weapons types in-game

Development Process

Level Design: Prototype

3D Data Capture

I researched into various options for the 3D modelling of Parrs Wood High School, eventually discovering a tutorial by Nicko16. His tutorial outlines a method of capturing 3D data from Google Maps and importing it into Blender as a 3D model.

Nicko16‘s tutorial: https://www.youtube.com/watch?v=F_XsmoZJmG8

2. I downloaded both the MapsModelImport Blender plug-in – made by eliemichel, via GitHub, and RenderDoc, an open source frame debugger.

Download location of MapsModelImporter (Left) and RenderDoc (Right)

3. In Google Chrome, I changed the target to RenderDoc using the code below:

4. Using Google Maps via Google Chrome, RenderDoc was used to capture the 3D data from a satellite image of Parrs Wood High School. Via the MapsModelImporter, this data was then imported in Blender.

Blender

As a newcomer to Blender, I took my time to grasp the basics by watching Blender’s online tutorials to understand and navigate its interface.

2. Following further tutorials by Nicko16, I cleaned up the model by trimming the map using edit mode, specifically, deleting vertices within the Mesh View. clean up mesh using baking (use tutorial and screenshots for guide)

3. To further clean up the mesh enough for it to be imported into Unreal, I attempted to bake the textures onto the 3D model via UV unwrapping. However, the baking process estimated 16 hours to complete, eventually, acknowledging this method as insufficient.

4. Upon this drawback, I decided to create a prototype model using the 3D rendered model of Parrs Wood as a template.

6. Using the Google Maps model, I mapped out the Level Design for Parrs Wood Zombies.

7. Adding cubes and planes where necessary, I utilised the knife tool to sculpt certain shapes and paths, extruding faces, edges and vertices. Filling faces in-between edges and vertices helped save a time. This entire process took a week to complete. The Blender file was exported as an FBX.

Process of creating a 3D model of PWHS using the Google Maps 3D model as a template

Note: For an accurate 1-1 rendition, I used imagery of Parrs Wood from personal photos and online sources (including Google and YouTube) to recreate areas where the Google Maps 3D model had low quality.

8. Due to my laptop’s inferior specs, I was unable to install Unreal Engine 5, and therefore, settled for Unreal 4.27.2, along with Xcode 13.2.

9. A number of errors occurred upon importing the FBX into Unreal 4: a) Certain errors messages appeared. b) Certain faces and planes were missing in UE4.

Errors presented when exporting the Blender FBX into UE4 – a) Left b) Right

Fixes used to resolve UE4’s FBX import errors – a) Left, Middle b) Right

10. These errors were resolved by: a) Exporting faces via Shading, UV unwrapping faces, and merging vertices by distance. b) Recalculating normals inside and outside where necessary; simultaneously navigating through the UE4 map to identify which sections were missing (2 hour process).

11. Upon exporting the final FBX prototype, the scale of the 3D model was reduced to 0.6 along all axis, and the Player Starting Position was relocated.

Game Mechanics: Prototype

Character & Gun

I downloaded my character assets from: https://smartpoly.gumroad.com/l/ZombieFPSFiles

2. In a new FPS Template Project, relevant folders were created to import assets, animations, materials and textures used to render the player’s arms.

3. Within the First Person Character Blueprint (BP_FPC), I deleted FPGun, VRgun; compiling and clearing error messages by deleting any related blueprints in order to implement my own weapons. The default FPMesh was switched out for the previously rendered arms rotated accordingly.

4. For the initial player animation: an Animation BlendSpace1D was created named “IdleWalkBS”, selecting the Arms_Skeleton as the mesh. Inserting both the Idle and Run animations to transition between them, renaming the Horizontal Axis to Speed with a maximum value of 600. Furthermore, an Animation Blueprint was created, and through the use of State Machines the engine could track the player’s speed to output the respective animation. This logic was implemented into the BP_FPC via selecting the Animation Blueprint as the AnimClass. The FirstPersonCharacterMesh was then adjusted to accommodate the camera view.

IdleWalk Blend Space

5. The Military Weapons Silver and Dark assets were downloaded and imported from the Unreal Engine Marketplace.

6. In the Arms_Skeleton, a “PistolSocket” was added to the right hand. The pistol was then implemented into the mesh, by adding a new mesh “PistolMesh” and adjusted using animation previews.

7. Further State Machine were added to accommodate aiming the pistol, each state had its own respective animation using an “IsAiming?” boolean variable to create circuit to determine whether player is aiming, using the RightClickMouseButton, in order to cycle through pistol animations.

8. In BP_FPC, the CharacterMovementComponent was used to down movement while aiming, with values of 200 when aiming and 600 when not.

9. An AnimationMontage was created for the AimFire and IdleFire animations using the LeftClickMouseButton as the trigger. By using a branch node within the BP_FPC, the engine would determine if the player is aiming, thus, playing the relative animation. The length of each animation was snipped to create more polished animations.

Zombie

The ZombieGirl asset along with its respective animations were imported, and the relevant materials were adjusted.

2. A Character Blueprint “BP_Zombie” was created, adding the ZombieGirlMesh and adjusting the transform, rotation and scale accordingly.

3. A BlendSpace was created to play certain animations at specific speeds, along with an Animation Blueprint to hold and cycle between all zombie animations.

4. Within the BP_Zombie, logic was implemented for the zombie to chase the player. Changing the rotation orientation and maximum walk speed helped refine this. Navigation Mesh Bounds were implemented into the level to allow the zombie to move around.

5. For zombie to start running, I added a PawnSensingComponent to the BP_Zombie, to increase the zombie’s speed when close enough to the player

6. An Animation Montage was created for the ZombieAttack animation with logic to return the zombie to chasing the player upon each attack animation.

Weapon Damage

The pre-existing template red crosshair was removed by disabling the HUD Blueprint within the FirstPersonGameMode Blueprint. I imported my own downloaded crosshair asset, and implemented it by creating a Widget Blueprint “BP_MainWidget” and anchoring it to the centre and rescaling it. The Widget was implemented into the scene via logic within the BP_FPC. The orientation of the pistol was the adjusted to line up with the cross hair.

2. Via FirstPersonCamera, both the WorldLocation and WorldRotation were used to set a centre point for line tracing which would act as the bullets for the pistol.

3. Within BP_FPC, damage was applied via the ApplyPointDamage logic, with a value of 25, used to register when a line trace hit a zombie.

4. Within BP_Zombie, a float variable “Health”, with a value of 100 (100HP), along with a PointDamage logic, subtracts any damage inflicted from Health variable. A print string helped show that this was active and working. Creating a Boolean “Death” would register when the zombie’s health is at 0. Logic was implemented to stop the zombie’s movement immediately, accompanied by a AnimationMontage for the Death animation which was set to play once, achieved by creating a MontageSection that would loop at the end of Death AnimationMontage.

5. Another AnimationMontage was created to showcase the ZombieHit animation, used when the zombie has taken damage. Within in the ZombieAnimation Blueprint, Bone Nodes were manipulated to allow this animation only to play from the waist up so the zombie’s legs would carry on walking when hit; and not slide along the floor. This was achieved by creating SavedPoseNodes, and recalling these CachedPoseNodes to play from the WaistUp and from the HipsDown.

6. Within the Project Settings, “HeadShot” and “BodyShot” surfaces were added to distinguish between shot types and relative damage infliction. Assigning these surfaces to Physical Materials allows them to be allocated to certain segments within the zombie’s Physics Asset. Reshaping the capsules to distinguish between the head and other body parts. Then, within BP_FPC, the HeadShot and BodyShot logic was implemented within the Line Trace logic.

7. By downloading the VFX Starter Pack from the Unreal Marketplace, Particle Effects could be emitted upon a zombie hit or an environment hit at the location of the line trace. This was achieved by adding the tag “Zombie” to BP_Zombie. A Blood Particle Effect would spawn when hitting a zombie and an Asphalt Particle Effect would spawn when hitting any other surface.

8. To fix a bug that would cause the player to collide with dead zombie’s mesh, logic was implemented to destroy the zombie’s mesh once dead.

Player Health, Player Damage, Health Regeneration & Blood Overlay

A Float “Health” was also created for the player with a value of 100.

2. Within ZombieAttackMontage, a MontageNotify would register the collision of the zombie’s attack with the player, achieved by add SphereOverlap to the zombie’s hand. The zombie attack was set to inflict 25 damage to the player upon each hit.

3. In ZombieBPViewport, create ArrowComponent and move in front of Mesh. Damage logic was applied to BP_FPC , similar to that of the damage logic within BP_Zombie.

4. Within BP_MainWidget, an Image was created on the canvas, anchored to the full screen and reset offset, importing a BloodOverlayImage asset, set to hidden. An animation for this blood overlay was created and set to looping, changing Opacity from 0 to 1 and then back 0, creating a flashing effect. Implementing logic within this blueprint to hide or show this blood overlay dependant on the player’s health, a value of 50 was used.

5. Within BP_FPC, logic and conditions for health regeneration were implemented, if player health was less than 100, 5HP would be added every 5 seconds.

Pistol Ammo & Reloading

Within BP_FPC, I created three integer variables: “CurrentAmmo”, “Total Ammo”, “MaxClipSize”, with of values of 8, 72, 8 , respectively. Setting the RButton as the trigger for reload, and creating an Animation Montage for the Reloading animation. Using a boolean variable and the necessary logic, the engine would stop the player from shooting when the Reloading animation was playing. Logic for ammo usage and ammo transfer from TotalAmmo to CurrentAmmo was implemented into BP_FPC. In addition to this, within BP_MainWidget, a representation of these ammo variables was created, binding the text to each variable.

2. In MainWidgetBP, create AmmoRepresentation in bottom right corner and create bindings to CurrentAmmo and TotalAmmo variables, respectively.

Zombie Game Mode

A GameModeBase Blueprint “ZombieGameMode” was created with logic to spawn zombies, using the variables: CurrenRound, ZombieTotal, ZombiesLeft, setting up a basic multiplication for the number of zombies to spawn each round.

2. Using an array, a number of locations within the world were saved, and corresponding logic was implemented to divide the zombies equally between them. This logic would also track the number of zombies killed and, thus, the ZombiesLeft variable per round, along with a round increment upon successfully dispatching all zombies within a specific round. This logic included a short delay before destroying the zombie actor upon its death.

3. Within BP_MainWidget, a Round Icon was create and bound to CurrentRound variable. In addition to this, three animations were created: a GameStart animation, resembling the Black Ops Zombies round start UI, a RoundBuffer animation and a StartRound animation.

Death Screen

Within BP_MainWidget, a DeathUI resembling to that of Black Ops Zombies death UI was created, by using the bind function, this UI would show the amount of rounds survived. The necessary logic was implemented to show this UI upon player death.

2. Within BP_FPC, I implemented logic to disable player input, controller, movement and widgets.

Ammo Pickup

For the Ammo Pickup, I imported an AmmoCrate asset from QuixelBridge

2. An Actor Blueprint “BP_AmmoPickup” was created with a StaticMesh, SphereCollision and a RotatingMovementComponent. Within this blueprint, logic for player interaction and the subsequent destruction of this actor was implemented.

3. An array of world locations were used to store different spawn locations for the AmmoPickup, set to spawn at the start of each round, bar round 1.

4. Within BP_FPC, I set up the logic to replenish the player’s CurrentClip and TotalAmmo, clamping them to their maximum values.

Sounds

For zombie sounds, I imported the previously downloaded ZombieSounds, created a SoundCue “AttackCue”, adding a RandomNode to randomly cycle between four different sounds upon each zombie attack.

2. I also added a SoundComponent to BP_Zombie, with Attenuation.

3. A PistolMagSound was added into the ammo logic for when pistol has no ammo, and the player tries to shoot.

Adding Parrs Wood

To accommodate the imported map of PWHS, I updated the locations for both zombie and ammo pickup spawns.

2. BlockingVolumes were placed on the edge of the map to set the game boundaries. Along with an exponential increase to the Navigation Mesh Bounds.

3. In the Project Settings, I added an object channel in collisions and renamed it “Zombie”. So certain BlockingVolumes would act as passages for the zombies; blocking the players, these would host the zombie spawn locations. Setting the Camera to Ignore to allow shooting through these channels, and the Zombie to overlap (this was also done in BP_Zombie)

Main Menu

For a prototype version of the Main Menu, I imported an in-game video and created a MediaPlayer, adding the video into it. A new material was created for newly made video, along with a new Main Menu Widget, inserting this material into an image on the Canvas Panel.

2. In the LevelBlueprint, I added a MediaPlayer Variable and added the MediaPlayer as the Default Value. Then creating the logic to play the video on BeginPlay

3. Within the MainMenuWidget, I created a simple title and buttons using the EventGraph to set up the buttons.

Game Mechanics: Main Build

Gun Revamp & Additional Weapons: Shooting

I downloaded and imported the FPS Weapon Bundle from the Unreal Marketplace

2. Unfortunately, it deemed difficult to adapt the player arms and its animation to different guns, so I decided to delete the mesh completely, along with the Pistol_Mesh from BP_FPC

3. I created an Actor Blueprint “Weapon_Master”, adding a SkeletalMesh within it called “Gun”. From this class, I added a Child Class “Weapon_Pistol” and added the PistolSkeletalMesh, rotating it accordingly. I then duplicated Weapon_Pistol, making a class for each gun: “Weapon_Assault Rifle”, “Weapon_Shotgun” and “Weapon_Sniper”.

4. Within BP_FPC, I added a SceneComponent “WeaponPlacement” and made it child of camera, changing its location accordingly. Then, within the Event Graph, I created a function “EquipWeapon” with the input “WeaponClass” of type Weapon_Master and set up the necessary logic.

5. Within the Weapons Folder, I created an Enumeration Class “E_FireType”, adding two types: “SingleFire” and “Automatic”. Then within BP_WeaponMaster, I created a variable “FireType” of class E_FireType, changing Weapon_Pistol to a default value of SingleFire.

6. Within BP_FPC, I created a function “FireWeapon” and set up its logic along with the Event Graph logic.

7. In Weapon_Master, I added a vector variable “WeaponPlacementOffset” and adjusted each weapon accordingly to centre them.

Gun Revamp & Additional Weapons: Recoil

Within BP_FPC, I created a CustomEvent “Recoil” and attached it to a TimeLine, and then set up the necessary logic for the timeline and recoil mechanic.

2. Within BP_WeaponMaster, I created three Float variables “recoilAmount, “recoilYaw” and “recoilLength”, setting the default values to 0.4, 0.15, 0.03 respectively, and then inserting them into the Recoil logic.

3. Within BP_FPC, I added a Float variable “previousPitch” and a Boolean variable “canResetPreviousPitch”; adding this to the “NoEdit” category. The previousPitch variables were then added to the FireWeapon function logic.

4. Within BP_FPC, I added a CustomEvent “PullDownRecoil” and set up the TimeLine and logic, then adding this logic to both the SingleFire and Automatic FireTypes.

5. In BP_WeaponMaster, I created a function “SetRecoilVariables”, implemented the necessary logic and variables. Following this, I created another function “RecoilAnimation” and set up its logic.

6. Within the BP_FPC, I created a RecoilAnimationTimeLine followed by the corresponding logic.

7. To test the Automatic FireType, within BP_WeaponMaster, I created a Float variable “fireRate” with a default value of 0.1. Then within Weapon_Pistol, I changed its FireType to Automatic.

8. Within BP_FPC in the FireWeapon function, I collapsed the SingleFire logic into a function “FireTrace”, then off the AutomaticNode I set up its logic and created a function “AutomaticFire” and within this function I then recalled the FireTrace function, adding logic to clear the timer on the LeftMouseButtonClick logic. I then implemented logic to t stop players shooting very fast with single shot, and collapsed this into a Macro “FireMacro”.

9. I then updated each weapon with unique values.

Gun Revamp & Additional Weapons: Bullet Spread

Within BP_WeaponMaster, I added a Float variable “bulletSpread” and defaulted it to 250.

2. Within BP_FPC in the FireTrace function, I set up the necessary logic for BulletSpread.

3. I then updated each weapon with unique values.

Gun Revamp & Additional Weapons: ADS

In Project Settings, I changed the Near Clip Plane to 0.1.

2. Within PistolSkeletalMesh, on the Root, I created a Socket “ADS_Socket”, and adjust it in the viewport to line with pistol’s iron sights.

3. Within BP_FPC Construction Script, I promoted the RelativeLocation of WeaponPlacement variable to a new variable “WeaponPlacementLocation” and set up its logic.

4. Within BP_FPC, I created two CustomEvents: “ADS” and “Un-ADS”, and set up the logic for ADS along with RightMouseButtonInput.

5. Within BP_WeaponMaster, I created two Float variables: “ADSFOV” and “ADSDistanceToCamera” with default values of 75 and 10, respectively. Then, updating the the logic within BP_FPC, with these variables.

6. Within BP_FPC in the FireTrace function, I added the ADS variable to stop bullet spread.

7.However, lining up the ADS with the iron sights did not work correctly for each gun, thus, I manually adjusted them by creating a Float variable “ADSHeight” and changed the value for each weapon.

Gun Revamp & Additional Weapons: Ammo

In BP_WeaponMaster, I created two Integer variables: “CurrentClipAmmo” “MaxClipAmmo”, then within the Construction Script I set the CurrentClipAmmo to MaxClipAmmo to start with a full clip.

2. Within BP_FPC, I created variable of WeaponMasterClass “Ammo”, changing its type to Dictionary and its values as Integers, then adding MaxAmmo for each gun.

3. Within BP_FPC, I set up the logic for printing ammo. Then within the Fire Trace function, I set up the logic for shooting and ammo reduction, then implementing the logic within the DecrementClipAmmo function.

4. Within BP_WeapnMaster, I created a Float variable “ReloadTime”, defaulting it to 2.2.

5. Within BP_FPC, I created a function “Reload”, created its Logic, and then created a CustomEvent within the EventGraph called “ReloadAnimation”. Implementing a TimeLine and logic including using R as the input.

6. For better game feel, I implemented logic to return to shooting or ADS after reloading if the button is still pressed.

7. However, due to this new ammo logic, the previous ammo UI no longer shows the ammo values. To fix this, I decided to ditched Dictionary Ammo variable and create a new variable in BP_WeaponMaster “WeaponTotalAmmo” and swapping in for the GetTotalWeaponAmmo Function.

Gun Revamp & Additional Weapons: Weapon Switching

Within BP_FPC, I created two CustomEvents: “UnEquipAnimation” and “EquipAnimation” and set up logic for each.

2. I then created a CustomEvent “CheckForWeapon” and created its logic, then updated the EquipWeapon function logic

3. A Boolean variable “CanShoot” was then added in BP_FPC, and inserted into the Shooting logic to stop shooting while switching weapon. Similarly, a “StopReloading” CustomEvent was created.

4. I then set up logic to prevent players from switching to the same weapon.

5. The Boolean variable “IsEquipping” prevents any of the gun mechanics to be carried out while the player is switching.

Gun Revamp & Additional Weapons: Aesthetics

For Muzzle Flash: Within BP_WeaponMaster, I created a variable “MuzzleFlash” of type ParticleSystem with an ObjectReference and set the muzzle flash for each weapon with its corresponding effect. I also created a Rotator variable “MuzzleRotation” as some muzzle flashes emit in the wrong direction.

2. Within BP_FPC in the FireTrace function, I integrated the MuzzleFlash logic, and renamed all weapon muzzle bones to “b_gun_muzzleflash”.

3. For Weapon Sounds: Within BP_WeaponMaster, I created a variable “FireSound” of type SoundCue with an ObjectReference and set the sound for each weapon, and integrated the FireSound logic within the FireTrace function. Similarly a “ReloadSound” variable was created and implemented in the Reload logic.

4. I also downloaded a BulletHole image from google, creating a PNG format in Photoshop. I then created a material, and added it into the FireTrace logic.

5. For Weapon Sway: Within BP_FPC, I created a function “WeaponSway” and created InputFloat variable “DeltaTime”, two Rotator variables “Final Rotation” and “Initial Rotation” and a Float variable “MaxSwayDegree” defaulted at 2.5, and then set up the necessary logic.

6. I tried to create a scope for the Sniper, however, this deemed very difficult, therefore, I decided to purchase a Rifle Weapon asset from the Unreal Marketplace instead, and replaced the existing Sniper.

Zombie Revamp

I imported the Romero (zombie) skin from Mixamo, having downloaded the Breathing Idle, Walking and ZombiePunch animations, editing the values to make them more zombie like.

2. Within the ZombieWalking animation, I edited arms to stick out and add keys to change the animation, repeating this process throughout animation, then copying and pasting the initial values to the end to loop the animation.

3. I created a Character Blueprint “AI_Zombie”, inserting the ZombieMesh, transforming and rotating accordingly.

4. I then created an AIBehaviourTree, BlackBoard and an AIControllerBlueprint.

5. In the AIBehaviourTree, I created two tasks: ChasePlayer and AttackPlayer, setting up the necessary logic for each. For the animations, a Blend Space, Montages and Blueprint were all created similar to the prototype build.

Health Revamp

Within PHYS_Zombie, I edited the capsules to create hit boxes, and in AI Zombie’s Viewport, I change the Mesh Visibility to Block

2. Within AI_Zombie, I created a function “TakeDamage” and created three inputs: Amount (Float), Bone Name (Name), and Impact Point (Vector).

3. Within BP_FPC in FireTrace, I inserted the TakeDamage function logic to detect bone names.

4. For Health, I created ActorComponent Blueprint “BPC_Health”, creating two float variables “Current Health” and “Max Health”, and also two Float variables: “Remove Health” and “Add Health”, creating logic of each. Adding this health component to both the player and the zombie.

6. Within BP_WeaponMaster, I added a Float variable “Damage” and set the damage for each gun.

7. Within BPC_Health, I set up logic for a headshot multiplier and for death.

8. I also rewired the prototype player death logic into this Health component.

Damage Indicator

Importing DamageIndicatorImage, I created a new Widget “BP_DamageIndicatorWidget”, added the image, created an Actor variable “Instigator” and a Player variable “Player”, making both instance editable, checking expose on spawn for both, then creating the necessary logic.

2. I then linked this Widget to the BP_MainWidget, and created a function “PlayerTakeDamage” within BP_FPC, and added it to AIZombie’s Event Graph.

3. An animation was created for the indicator to fade out for a more polished look.

Blood Screen & Camera Shake

I imported new BloodScreen to show incremental damage the player has taken, to do this I created a material and set up the relevant texturing, and created a MaterialInstance

2. Within the BP_MainWidget, I added the BloodScreen and set up its necessary logic paired with the player’s health component.

3. For the Camera Shake: I created MatineeCameraShakeBP “BP_CameraShake”, edited class defaults and added this blueprint to the PlayerTakeDamage function. BP_FPC>PlayerTakeDamage

Round Revamp

In Black Ops Zombies fashion, Call of Duty has a specific algorithm used for the increment in the amount of zombies spawned and their corresponding health upon each round. To Implement this algorithm a new Game Mode was created called “BP_PWZ”, and two Integer variables: “RoundNumber” and “MaxZombiesInLevel”, and a Float variable “TimeBetweenSpawn” were created. The necessary logic was implemented, also taken into consideration the maximum amount of zombies present in the world, maxed at 24 to sustain game performance.

Pause Menu & Main Menu

Creating a Widget “BP_PauseMenu”, a Background Blur with a Z Order of -1 was added along with buttons; with their own logic.
Similar logic and design was implemented into the MainMenuWidget.
I added to the Zombie sound into the Main Menu as it sounds better than silence.

Control Scheme

A Control Scheme was created using assets from the following link: https://icons8.com/icon/set/computer-hardware/ios

The assets were imported into Photoshop to create a PNG image, and then imported into UE4 to create a PauseMenuWidget.

Round Sounds

Sounds for Player Death, Round Buffer and Round Start were exported from YouTube and implemented into BP_PWZ.

Font

The Zombie Treats font was downloaded and imported from the following link: https://www.dafont.com/zombietreats.font, and replaced all existing in-game text.

Level Design: Main Build

Blender Materials

All materials for the Main Build 3D model were found on Quixel Bridge’s Surface Library. However, Blender’s Plug-In for Quixel Bridge did not work for me, therefore, I installed the Node Wrangler Add-On within Blender.
By creating a new material and clicking [CTRL SHIFT T], I was able to import all the required texture files at 2K definition due to my laptop’s limited specs.
Textures would stretch across the 3D model’s faces, therefore, utilising the Smart UV Project function and the Knife or Loop Cut tools in blender allowed the textures to rescale to the size of the face.

Asset Implementation

Using Quixel Bridge’s Megascan Library, I was able to import various assets into the world within UE4. Assets were used to mark the world boundaries, for example: stone walls and sandbags, and also used as props.

Fog

By adding an Exponential Height Fog into UE4 and setting it to volumetric, I was able to create a Fog Material, and subsequent Material Instance. Inserting this Material Instance into a Particle Effect allowed for a Local Volumetric Fog to produced. This Fog was placed around the world to mark the level boundaries and hide the edge of the world.

Playtesting & Feedback

Playtest #1: Prototype

Positive Feedback:

Rounds intensify rapidly, difficulty arisen from increase in zombies makes for fun gameplay
Player Arms and Pistol animations are fluid and realistic
The world is recognisable as Parrs Wood High School, even as a prototype
UI (round number and ammo) is helpful and clear
Players enjoyed exploring to see how big the map really is

Negative Feedback:

More guns, having just a pistol is boring and bland
Some players felt lost without knowing the extent of the control layout
The world needs more texture
Zombie health does not increase as rounds increase, it is too easy to kill zombies even in the higher rounds
Blood overlay is deceiving, players would prefer an incremental blood overlay to see how much damage they have received
The game needs more sound, not just zombie growls
Game crashes when reaching rounds 7+ (too many zombies)
Zombies are really low quality, and some players do not like the idea of shooting female zombies
Glitch found where if players shoot a zombie while they are hitting you, the zombie will freeze and not chase or attack the player anymore

Implementations #1

Three more guns have been added, each with their own unique characteristics: recoil, weapon sway, fire type, fire sounds, reload sounds, etc.
A Control Scheme UI has been added to both the Main Menu and the Pause Menu
Zombie health increases incrementally upon each round with a pace tried and tested by Activision in Call of Duty (the use of their algorithm)
New Blood Screen implemented, covers more of the screen and increments; gets more opaque the more damage the player has taken
Round Buffer and Start sounds implemented, along with a Game Over music soundtrack
A cap has been introduced for the amount of zombies able to spawn to sustain game performance
New zombie models and animations of higher quality have been imported
The use of an AI Behaviour Tree resolves the zombie freezing glitch

Playtest #2: Main Build (Game Mechanics)

Positive Feedback:

New zombie animations are funny and a big improvement
Different guns make the game feel like a real FPS game, each gun feels unique, and can be used tactically to get the player out of tough situations
No performance issues
Wait between rounds is perfect amount of time
Players enjoy looking for ammo boxes when low on ammo, adds another element of survival
Damage indicators are a great addition
Player health representation is subtle, but players appreciate not knowing how much health they have, but that they aware if they are in imminent danger or not
Recoil is a challenging feature when playing
Players really like the particle effects

Negative Feedback

The world is still empty and a bit bland, needs texture
“What fun is it if I can’t play with my friends?”
In higher rounds, killing zombies is a lot more difficult, but players feel like they do not have enough ammo or weapons to compensate
Too much open space
Glitch with ammo, when switching guns, clip ammo is replenished automatically
The world still needs more sound
Some players mentioned they would enjoy playing an actual character (seeing hands, hearing voices)
World is too big for the amount of zombies there are
Zombies are too slow, faster zombies would be more challenging
Glitch with Round animations (delay, and Round Buffer noise is very loud and repeats a few times)

Implementations #2

Textures have been added into the world, along with a few assets
Fog has also been implemented to reduce the visible open space
Weapon switch ammo glitch has been resolved by creating a Clip and Total Ammo variable in BP_FPC for each weapon and used to set ammo amounts when ammo is used. This logic was inserted into the Construction Script of each weapon to save and recall each variable.

Reflection

Parrs Wood Zombies has been both a personal aspiration and a gratifying milestone for me during my game design journey. Before deciding on this concept for my Final Major Project, I had every intention of working independently for my final semester, and had my eyes set on Level Design, as I believe these are two focal aspects of game design I had not yet tackled. It is for this reason I chose to write a thesis on the Level Design of Assassin’s Creed Syndicate and Watch Dogs: Legion, highlighting Ubisoft’s feat of virtually recreating real-world London. During my thesis, I recalled this lifelong idea to recreate my high school into a virtual world, and as of that moment it felt that the stars had aligned.

Similar to Ubisoft’s reconstruction of Ancient Greece in the development of Assassin’s Creed Odyssey, where they analysed and used digital elevation data from NASA and Google Earth to map out the terrain of their virtual world, I decided to utilise an appealing method of manipulating 3D geographical data into constructing a virtually identical rendition of Parrs Wood High School. However, I was quick to learn the limitations I would face using an outdated laptop, not adequate for any design work. Yet, the low quality 3D model achieved from my attempt of this method served as a perfect template to construct my own 3D model, and I have relished the process, furthermore, I am very pleased and proud with the result. I feel l have achieved what I set out to do to an extent.

Having worked with others on other projects throughout MA Games Design, I have always had an accessible support system surrounding me, and although that boasts its own benefits, I have had to push my design capabilities further on this project than I have ever had to before. Constructing 3D models, animations, game physics, and learning and understand blueprints, with that, I feel fulfilled with the degree of work I have produced for this project.

Having never used Unreal Engine before, I was faced with a multitude of problems on a daily basis, I felt that I have resolved most of the detrimental issues such as the new ammunition system not binding to the existing Widget UI, and creating a cap to limit the amount of zombies present in the level at any given time to prevent the engine from overloading and reducing performance. Regarding the solutions applied to resolve the ammunition errors, my peers have termed them as “dirty” fixes, and I wish to carry out a more competent way of addressing these issues for future projects.

Working on my own has had the disadvantage of a burdensome workload, as time management was key discipline to consider, I would regularly schedule deadlines for Level Design, Game Mechanics and Prototype builds; for Play Testing, in order to sustain an efficient pace in my work. Each deadline would typically be on a weekly basis, however, due to the extensive amount of tasks to complete, I saw that I would miss deadlines and was only able to produce two builds for playtesting. Unfortunately, the biggest drawback I have had throughout the entirety of this project is the performance of my laptop. Compiling shaders would take hours, UE4 would run on average at 10FPS, I found it difficult to gain any momentum between tasks.

A recurring bit of feedback I have received regarding the game world of Parrs Wood Zombies is how empty it is, that there is too much open space. I feel my attention has been diverted away from Level Design in recent weeks due to the extensive number of game mechanics needed to implemented, fixed or improved upon. However, I am keen to explore different methods of filling out a vast amount of open space, and this will be a focal point of my research going forward. I do not believe 3D assets to be the solution in this instance, only due to the restrictions posed by my laptop’s performance capabilities.

The only noticeable glitch I can seem to find at this moment in time is the Round Buffer. The engine is constantly checking to see how many zombies are left from those who have spawned. Upon killing the last enemy, the engine is still running its checks and is causing a short looping duration between rounds, affecting the Round Buffer animation and sounds; as it is playing the sound multiple times at once. I have yet to find a fix for this, but it is something to note down and discuss with my peers or other developers in the future.

Despite this, I have received a lot reassuring praise for Parrs Wood Zombies, and it is a project that I am confident to work on in the future; and look back at what I have achieved thus far, until I have successfully recreated the vision I had for this concept as a teenager.

In regards to future iterations there is an endless list of mechanics I would love to implement into Parrs Wood Zombies. Firstly being arms! I found it very difficult to animate arms when using multiple weapons, therefore decided to remove them entirely. More weapons is always a good option too, specifically, I would have liked to create a melee system, and the ability to purchase weapons in-game, similar to Black Ops Zombies, as I believe carrying four weapons at once is excessive and unrealistic. For this I would need to implement a points system, something that I have considered throughout this project, but I felt would take too much time to incorporate. One point made by a playtester which had been removed from the prototype and overlooked since, is the speed of zombies, I am fully aware and able to have implemented this as I have already done it once before, however I feel it is too late to be amended. The list could go on infinitely as the endless survival game genre leaves a lot of room for crazy and interesting concepts, but now that I have reached the end of my time at ual, going forward I wish to now merge all the disciplines of game design I have experienced, and create more multi-faceted games, that include a competent degree of elements such as Level Design, Narrative Design, Animation and Development. I wish to also improve on my ability to prototype more efficiently, a tall order for a perfectionist such as myself.

PU002626: Critical Play and Development

Corrections DevLog

Game with a Message Project (Collaboration w/ James Grey & Abhimanyu Chattopadhyay)

Game Overview

Set in a fictitious Britain, preceding the nation’s general elections, Corrections follows the daily life of a corrections officer employed by the government-run Ministry of Corrections. As newly elected THE PARTY come to power, the grain of society is direfully shifted as a product of their totalitarian intent. Players find themselves at the heart of this political despotism, torn between professionalism and civility.

Day-to-day, players will convict countless criminals by inspecting criminal RAP sheets, reading through internal emails, and keeping up to date with current news. While doing so, players must maintain a high-performance level in their work to prevent drawing suspicion from their superiors, raising the risk of jeopardising their career, or safety.

Corrections is a puzzle game, narratively drawing inspiration from the totalitarian worlds of V for Vendetta and George Orwell’s 1984. As for gameplay and game mechanics, Corrections is greatly influenced by Lucas Pope’s Papers, Please. This game is a collaborative effort by students of MA Game Design at ual: Game and Narrative Designer – Hisham Jarad, Game Developer – James Grey, and, Game Designer and Developer – Abhimanyu Chattopadhyay.

Aims

To specialise in Game Design over Development, by actualising collaborative concepts via Narrative and UI Design. Thus, building upon my existing design proficiency
To implement unconventional design methods into project tasks
To create a game where all narrative elements (News, Emails, criminal RAP sheets) coalesce to satisfy the major plot
To work under somebody, as part of a team – successfully complying with a colleague’s vision, limiting my own personal input, by fulfilling their project aims

Design Process

Due to personal circumstances, my ability to attend university this semester has been heavily impacted by having to work full time, imposing restrictive time constraints on my studies. Therefore, I believed my skills would be best suited as part of a group project.

I reached out to James and Abhimanyu, fellow MA Game Design students, to propose the notion of collaborating on a project, with the personal intention of solely designing, as both are very capable developers. They had already built a prototype for a game during the semester’s game jam sessions, thus briefing me on their political game concept: Corrections.

2. Via Discord, Abhimanyu informed me of my role for the project, designating me the position of UI and Narrative Designer. He made it clear that the major storyline should be difficult for players to decipher, proposing the idea of shrouding the storyline with various narrative elements they intend to include in the game, such as “News” and “Emails”.

3. I put forward the idea of implementing a shared online workspace with the purpose of organising online meetings and brainstorming ideas, concepts, and narrative features desired by the team. In the end, we decided to use Telegram for its team-friendly interface.

4. I explained to the team that I felt confident following their lead on the intended gameplay and feel. I wanted to take on the challenge of joining a team with a clear shared vision; working in this way would give me experience similar to that of joining a games studio and finding out how I can add my own value.

UI Design

Regarding UI Design, I intended to illustrate visual concepts for each of the following game elements: Criminal RAP sheets, News and Email interfaces. Concepts would be completed on a daily basis and fed back to the group to discuss thoughts and ideas.

2. I decided to create a Mood Board for each element; in-line with my aim to utilise personally unconventional design tools, via Milanote, a free online Mood Board tool. Mood Boards would aid in drawing inspiration and guidance when designing each concept.

3. Inspirations and references consisted of existing games, films and TV, and real-world documentation. With the inclusion of certain colour palettes, to produce a multitude of alternative designs when proposing each concept to the Development team.

Mood Boards for criminal RAP sheet (top), News (right) and Emails (left)

4. A lasting debate during early development was to establish the time period the game would be set in. The general consensus agreed for a game set in the present-day or future, on account of this, I decided to design present-day and futuristic interpretations for certain UI concepts, to aid in the debate.

Present-day (left) and futuristic (right) criminal RAP sheet UI designs

The UI concepts would later be scrapped due to the positive feedback received from play-testing regarding the prototype build of the game. As players felt the UI closely resembled a government website.

Narrative Design

James recommended I watch the film: V for Vendetta, and research George Orwell’s 1984 for inspiration on dystopian totalitarian states. Therefore, I took notes from my research, noting down quotes, events, and news headlines, that I would revert to for guidance when building the narrative.

2. We organised a group meeting to discuss the narrative further, particularly: discussing what emails, breaking news and fluff news would consist of. Concluding that Breaking News would consist of major in-game events, essentially, portraying the narrative of Corrections.

3. James compiled a storyline; split into four chapters, for the major events that would occur throughout the course of the game. My job was to adapt each event into a news headline, along with a supporting description. The requirement I would have to follow was that the breaking news headlines were not to portray the elected totalitarian government in an evil manner, as said government would be “controlling the media”, as described by James.

4. All headlines were originally composed by myself, with loose inspiration taken from google searches of news headlines, including those noted from V for Vendetta, to aid with the tone when writing.

Below is a link to download the Narrative document used when producing the breaking news headlines.

Corrections-Narrative Download

5. My next task was to produce news headlines (without a supporting description) to obscure the significance of the breaking news, we termed this narrative element as “Fluff News”. Through a group discussion, we agreed that twenty headlines per chapter would be ideal, proposing the idea to split each twenty, into two halves. One half for chapter-related news that would potentially tie into the criminal RAP sheets players would receive in that specific chapter, and another half, for headlines deemed miscellaneous. For the latter, I intended to implement some original humour as I felt the game’s premise is quite morbid. This task concluded the Narrative Design for the News game element.

Below is a link to download the Narrative document used when producing the Fluff News headlines.

Corrections-Fluff-News Download

6. Both developers felt that the inclusion of emails within the game would provide a more human insight into Corrections ever-changing narrative. Abhimanyu suggested to base emails off of the breaking news headlines, however, he mentioned that each headline does not need a relative email, and that multiple emails can be used per headline. Each email contains a Sender Name, Subject Line and Body.

7. The Development team granted me creative freedom when designing the characters of Corrections. I felt three characters would suffice the narrative, these included: the player’s initial manager, Abby, a friendly colleague, Ethan, who would support players throughout the game via hints and advice, and lastly, an oppressive manager, Col. Ames, to replace Abby when the totalitarian government take control the player’s department. I loosely created a personality for each character, to dictate the tone of their emails when conversing with the player.

8. A concept for the emails was as the gameplay changes via story progression, these changes would be mentioned within these emails. For example, once a player has the authority to pass the death sentence, they would receive an email advising this was permitted to use. From this, I believed an initial tutorial email would be necessary, eventually including this when the emails script were sent to the Development team for implementation into the game.

Below is a link to download the Narrative document used when producing the emails.

Corrections-Emails Download

9. Two further types of emails were proposed by James: “Mutator Emails” that would act as templates to present randomly generated in-game events, for example, players would be required to harshly punish anyone convicted over protesting, and, “Suspicion Emails” that would tie into the suspicion level system of Corrections.

10. In regards to Mutator Emails, a template was created for each chapter, four in total. Little guidance was necessary for this task, as long as each template varied in text and substance, promoting a more diverse narrative system.

Below is a link to download the Narrative document used when producing the Mutator Emails.

Corrections-Mutator-Emails Download

11. In regards to Suspicion Emails, five were necessary to correspond with the varying levels of the in-game suspicion system. I was instructed to use a family member to convey this email type, eventually choosing a fiancé choosing the name “Alex” to keep the gender ambiguous for both female and male players. The premise of the Suspicion Emails would be that as the player gains more suspicion, Alex would send an email detailing incremental suspicious activity.

Below is a link to download the Narrative document used when producing the Suspicion Emails.

Corrections-Suspicion-Emails Download

12. In-line with the in-game Performance Level feature, I was tasked to create performance blurbs/comments for each performance level granted to the player. Upon group discussion, we agreed that grades A-F would be an ample scale, furthermore, two tones were necessary to reflect the pre and post-totalitarian periods of the game. Blurbs were inspired by researching worldwide grading systems, and, subsequently altering the tone where appropriate.

Below is a link to download the Narrative document used when producing the Performance Blurbs.

Corrections-Performance-Blurbs Download

13. My final tasks were to research different crimes that were to be used as in-game criminal convictions, and produce a range of incremental punishments available upon chapter progression. A very straightforward task, as a complete list of punishable crime can be found on FindLaw.com, a highly acclaimed business who provide legal information for law firms. A few more impractical crimes were added to this list that would be introduced in-game by the totalitarian government. As for the punishments, a group discussion aided in deciding what punishments would be appropriate for each chapter.

Below is a link to download the Narrative document used when producing the Crimes and Penalties lists.

Corrections-Crimes Download

Play-testing & Feedback

Players did not accustom well to the action of scrolling down through criminal RAP sheets, as some players did not ever realise that they had to scroll, resulting in soft locking. However, this feature was initially implemented to increase stress when trying to complete cases quickly, as feedback shows this was accomplished, but is more detrimental to gameplay than intended.
- The scroll down feature was later removed to accommodate player feedback.

Players felt more feedback was necessary when sentencing criminals to make it feel more rewarding, and less bland.
- A “SENTENCED” graphic stamp was implemented, with complimentary sound effects to produce a more tactile feel to the game, along with a short fade transition between cases for emphasis.

Some players thought the wording in certain emails was misleading, alluding to absent mechanics.
- Therefore, I took it upon myself to rectify each specific email. Any changes were easy to implement due to the designer friendly nature of the game’s systems.

The lack of audio in Corrections made the game less engaging and felt one dimensional.
- In response to this, audio was added via audible reinforcement to actions, such as scrolling, notifications and sentencing. A further audio addition included progressive music throughout each chapter, to create an increasingly oppressive atmosphere throughout the game.

A number of players did not easily grasp the interactions available in the game, despite the existing tutorial email.
- To resolve this, a UI-orientated tutorial was implemented explaining how players should navigate the game.

Every play-tester voiced that the pacing was too slow, as playthroughs took too long and felt tedious. Players were not compelled to stick through to the end of the game.
- Gameplay was sped up by reducing the time between introducing each narrative element, and shortening the days between each chapter, along with the game’s internal clock.

Reflection

Overall, I am honestly proud of my input in designing and producing a compelling narrative for Corrections. I take pride in exploring new elements of design with each project undertaken during my time studying MA Game Design. I have never felt confident in compiling scripts and producing narratives for my concepts in the past, which is why I felt this assignment would challenge me to leave my comfort zone and truly test the limits of my design capacity. Having balanced a full-time job while working on Corrections over the past months, I have had to preserve my mental wellbeing while managing the stress that time constraints have on my academic work. However, I believe I have become a better game designer for it, prioritising project tasks and retaining a form of originality in my work.

Over the course of the year, I have been experimenting with different aspects of game design and development and have lately realised that design is an avenue I wish to further explore with the intention to eventually break into the games industry. This is why I reached out to both James and Abhimanyu, with the intention of designing Corrections, and I am grateful to them for the opportunity to immerse myself in this specific field.

As a result of recently researching Game Design theory, I feel that my utilisation of Mood Boards, is a first step in exploiting innovative design methods. To help build a mental picture of a concept prior to putting pen to paper, these Mood Boards allowed me to carefully plan my ideas, resulting in my most commendable work to date, shown by the praise received from friends and family upon presenting the News and Email narrative elements.

However, I wish to implement alternative design methods, such as a Rip-O-Matic, in my future projects, to push the boundaries of my design skill set.

Feedback from play-testing has proved the narrative elements of Corrections to be exemplary, as hardly any negative comments were voiced, however, not perfect, as players felt my work was misleading at times. I strive to resolve faults like this in the future earlier on in the design process.

In terms of narrative advancements, I believe giving players more interactions would improve engagement. An example being, the ability to respond to emails and develop immersive conversations between characters and the player, subsequently, imposing emotions onto players regarding characters driven by interaction and further character development.

I proposed to the Development team that implementing more distinct transitions between chapters would help emphasise the change in tone of the narrative during story progression. However, a core aim for the team was for the major narrative to remain as concealed as possible. After conversing with the team, as we finished building Corrections, they complimented me for my efforts in sticking with their vision for the game, and not greatly diverting from their original concept. This leads me to believe that I would succeed in working under a structured team, as my previous project To Bee, had been the polar opposite, as I was the Director.

PU001744: Collaborative Unit

To Bee DevLog

Collaborative Unit Project

Game Overview

An original game concept set in a fictitious world. To Bee follows the aftermath of a devastating hurricane, as players take control of a remaining bumble bee, ushering the journey of restoring nature to the world. Once introduced to this bleak, barren land, players gather pollen through interaction with surviving flowers in order to re-pollenate the virtual world.

Falling under the Zen game genre, To Bee boasts a minimalistic yet visually pleasing art style, accompanied by a harmonious serene soundtrack. Initial inspirations were primarily drawn from Thatgamecompany’s Flower, a game stripped of complex game mechanics with the intention of evoking positive emotions in players through the use of art, sound and life. Along with other games alike, such as Flow and Journey, all titles exaggerate a surreal experience where their beauteous worlds are the plots’ centrepiece.

As a Collaborative Unit project, a coalescence of academic backgrounds have contributed individual expertise to produce a unique gameplay experience. Consisting of seven ual students: Hisham Jarad and Sophia McPolin of Game Design, David Edwards and Mesha Bruckner of 3D Animation, and Tim Heron, Rafaella Binder-Gavito and Emmanuel Neill of Sound Arts.

Aims

To create a simple, minimalistic game experience, including the absence of on-screen HUD or UI
To build an immersive game space, where players change the world through interactions
Emphasise the surreal visual aesthetic, by including vibrant colours and a consistent theme of game assets
Build on my current skillset in both Unity; including alternative Unity plug-ins, and C#, to produce my first complete gaming experience

Development Process

Design and Collaboration

Contemplate the scope and limitations of various project ideas, determining the academic courses to collaborate with; as disciplines such as VR and AR are too advanced for my current capabilities. Thus, choosing 3D Animation as a clear prerequisite to bring my existing project ideas to fruition

2. Draft a design proposal for a Collaborative Unit Project, To Bee, for potential 3D Animation collaborators, reaching out via email and presenting an early-stage concept of the game

3. Assemble a small team, including another Game Designer; Sophia McPolin, and 3D Animators; David Edwards and Mesha Bruckner. Implementing a shared online workspace; consisting of a WhatsApp group chat, a Discord group and a shared One Drive file, necessary to organise both in-person and online meetings to further brainstorm ideas, concepts, and mechanics for To Bee, including the theme of hurricanes

*To Bee* Collaborative Group’s shared online workspace

4. Assign roles and delegate workload accordingly:

Hisham, Director & Game Designer – Game Mechanics (inc. Camera Operation)
Sophia, Environment Leader & Game Designer – World-building and Pollination Mechanics
Mesha, Producer & Scribe, 3D Modelling Artist, 3D Animator – 3D Modelling and Animation
David, 3D Animator, UI Artist – Title Screen and UI Animation

Game Mechanics

Construct a small-scale prototype to test Player Movement, Wind Zone feature and Camera Controls
Establish player movement via a C# script that utilises Unity’s axes settings. Torque and force were both added to the script to produce fluid movement upon player input. A Third-Person perspective was achieved by parenting Unity’s Main Camera to the player GameObject and adjusting orientation

Player Movement Demo

3. Implement Wind Zones by using a Box Collider and a C# script, resulting in an exerted force that pushes the player in certain directions. Strokes of wind were created via the addition of a manipulated particle system allowing visibility of Wind Zones

Wind Stroke Demo

Creating the World

The Unity Asset Store was used to find pre-made assets that satisfied the project’s art style. Assets used can be found using the following link: https://assetstore.unity.com/packages/3d/environments/fantasy/azure-nature-167725

As the Environment Leader, Sophia had creative reign over the world design and feel. The game world was to be set in a valley; therefore, the terrain was plotted around a large body of water. Elevating the encompassing land to generate inaccessible mountains, which would act to limit the game space for players to explore, in-line with the game design scope discussed during initial group meetings. The lake was to be a guide around the space for players to subconsciously follow due to how the world was introduced. Dividing the world into three distinctive terrains: Open-fields, Lake/Grass area, and a Forest. The world was brought to life by adding pre-made assets, together with their animations. It was noted that the world size was reduced to aid performance and to limit the repetitiveness of pollenating the world

2. After persistent testing and refinement, a growth mechanic; used as a result of pollination, for plant assets was established. Consisting of a C# script that would manipulate the scale of any given game object, resembling the growth plants. An additional, but later scrapped, growth mechanic was also made, this involved the generation of foliage along a player’s movement pathway

Plant Growth Mechanic Demo

Scrapped Growth Mechanic Demo

3. Triggering the plant growth mechanic was achieved by parenting all plant assets from a certain section to a parent cube game object; a replacement for the yet to be made Beehive asset, attaching a Box Collider and a C# script, activating the growth mechanic upon player interaction. A pulse-like particle system was implemented to animate once the script was activated

Plant Growth Trigger Demo

4. Pollen was represented by a golden particle system emitting from Flower assets throughout the game world. Using a player-attached C# script, a bool was created in order to track once a pollenating flower had been interacted with by the bee, subsequently activating an identical particle system to emit from the player, a visual cue to advise that the pollination mechanic was now active. Using Unity’s tagging system to register the relevant collisions, deactivating the player pollen particle system. Further tweaking to the tag system ensured certain unwanted interactions were prevented, for example, pollenating a beehive when the player is “unpollinated”

5. During a second group meeting, it was mentioned that ruins were a desired asset to be included in-game, thus, Sophia found a pre-made asset and implemented ruins into the game; found here: https://assetstore.unity.com/packages/3d/environments/stylized-ruins-191107, which doubled-up as navigational landmarks for players. With the world created, 3D assets provided by the Animation team were ready to also be implemented into the game

6. Final touches to the game include adding non-player animal assets to the environment. Their animations help bring a more life-like feel to the end result of this particular game world

Examples of Additional Animal Asset (inc. birds, spiders, and bees) Implementation

Animation

All 3D models and animation were created using Maya; by Mesha, utilising a 3-step process: concept art, constructing 3D models via rigging, producing 3D animations. Concluding each stage by collating feedback from group members

Tasked with designing the interactive flower used for pollenation and the playable bee, initial models were sketched and provided to the group for a consensus to be made

Initial sketches for both Flower and Bee designs

2. 3D models were built for both key assets, along with models for other useful game objects used to populate the world. All team-made assets were designed to match the existing art style

3D Models for Original *To Bee* Game Assets

3. Animations for both Flower and Bee assets were produced by taking advantage of Maya’s Rigging feature previously used to construct the 3D models, importing and exporting via the One Drive allowing proficient implementation of each asset into the game world

Flower Animation Demo

Bee Wing Animation Demo

4. David also produced other animations for animals to be included in the game scene

Bird Animation Demo

Spider Animation Demo

5. Title Screen and Credits UI were both constructed and animated in Adobe After Effects by David, using constant feedback from the Game Designers to refine the following aspects: Design, Font, Colour and Particle Effects

Title Animation Demo

Sound Design

The To Bee Collaborative Unit group had been introduced to three Sound Art students mid-term: Tim Heron, Rafaella Binder-Gavito and Emmanuel Neill, to assist with the Sound Design of To Bee.

Introduce the Sound Design team to the game concept by presenting the design proposal, initial prototypes and having a brief discussion of the team’s current aims, performance and vision
Assign roles by splitting and allocating the workload accordingly:

Tim, Music Composer – In-game Music
Rafaella, Sound Designer – Game Sounds and Sound FX
Emmanuel, Sound Designer – Game Sounds and Sound FX

3. Tim was entrusted with composing two contrasting soundtracks for both Barren and Pollenated areas of the game, termed Desolate and Hopeful, respectively. Tim was advised to ensure the music looped to allow for continuous playback during gameplay

4. The remaining Sound Team generated a file accessible on the To Bee One Drive containing an extensive amount of possible Sound FX examples, a general consensus was reached between group members for which sounds to use in-game. Group feedback helped refine the sounds, as constant ideas were put forward. Each relevant audio file was implemented to add an additional element of realism and immersion to the game. These included: a buzzing sound for the bee, sounds for pollination including a pulse-like sound effect, soft wind sounds for Wind Zones, and a hurricane sound for the To Bee’s opening sequence

5. Both Desolate and Hopeful were stored as audio files within Unity and attached to Box Colliders that would help switch between the two. The idea was for the Hopeful soundtrack to play once an area of the game was pollinated. To achieve this the Box Collider would scale up; similar to the plants, once that specific locale had been pollinated

Camera Operation

Utilisation of the Unity Cinemachine suite helped improve the existing camera perspective, along with the Timeline feature to produce professional title and credits sequences

Unity’s Timeline feature allows the production of a showreel-type sequence to create in-game cinematics. Placing several Virtual Cameras within the scene; each accommodating a distinctive angle, and switching between them; a portion dictated by player input, a minimalistic yet polished title sequence was achieved. Ending with an Activation Track of a C# script to load the following scene

Timeline Component for Prototype Title Sequence

Prototype Title Sequence Demo

2. Title animations were imported as PNG files, therefore to create an animation all files must be physically added to the scene. Having this PNG sequence as a child to the camera allowed for implementation, followed by simple axis orientation to achieve the ideal shot

Final Title Sequence (exc. initial black sequence) Demo

3. An identical process was used to produce the ending credits sequence. However, the use of different camera types, such as the Dolly Camera and Virtual Cameras that target the player, allowed for more stellar cinematography. The vision for the ending credits was established early on during initial group discussions. Upon game completion, the credits were essentially a cinematic sequence of camera shots following the bee’s journey home, achieved by a manually created animation consisting of moving the bee between different points within the scene

Credits Camera Shots Test

Clips from Ending Credits (exc. audio)

Playtesting & Feedback

Playtest #1

Postive Feedback:

Players appreciated the environment growth mechanic as a result of their exploration and gameplay, as it was described as “rewarding”. Players admired this as the game’s key feature The environment growth felt rewarding and the particle effect was satisfying. Players responded very positively.
Players responded positively to the art style, atmosphere and overall feel of the game. Identifying the pollen particle effect as satisfying, acknowledging the concept behind `To Bee
Restoring nature to the world deemed very engaging to players. They enjoyed exploring the different environment zones, and felt their actions drove change in the world
Player movement received little criticism as they did not feel it to be restrictive of gameplay, being able to move in any desired direction

Negative Feedback:

There was a general consensus between players of introducing a prologue-like tutorial to the start of the game, in order to display the essential game mechanics – a consequence of the minimalistic approach to gameplay
Player movement felt slow over long distances
Players believed Q and E as elevation controls did not feel natural, several alternatives were suggested; such as arrow keys or mouse input. Other players believed using a controller would benefit gameplay
The third-person camera felt basic and restrictive
Players would pass through certain game objects; such as ruins and rocks
A few players would miss the interactive flowers; despite their particle effects, as they would blend into the foliage
More guidance around the world was also suggested

Implementation #1

Originally, the game began in an open space which felt daunting to players. Sophia decided a separate area of the world would need to be created for the tutorial section. This area would need to be small and narrow to guide players through the key game mechanics, and prevent the tutorial being missed. This was also achieved by implementing an invisible wall at the protruding end of the area restricting progression until the tutorial was complete. A Wind Zone was attached to the invisible wall, the wind strokes giving the effect of wind preventing the player to advance

2. Box Colliders were added to certain assets to prevent players from passing through, as Sophia had believed the imported assets would already have colliders attached

3. More flowers were placed into the world, including an abundance in certain areas, so they were to be easily seen. Some flowers were placed in open areas too

4. Replacing the existing Main Camera with a Cinemachine Virtual Camera, including the use of its 3^rd Person Follow setting, achieved a refined Third-Person perspective. Adjusting the camera’s Drag setting allowed for the camera to slightly lag behind the player, exaggerating speed and flight, intended to improve player satisfaction

Improved Camera Demo

5. Implementation of small improvements, for example: refined movement speed, the number of bee hives, and testing elevation control variations

Playtest #2

Players play testing To Bee

Positive Feedback:

Players appreciated the element of Wind Zones and how they tied in with the game’s theme
The new camera received tremendous praise, with it benefitting player movement

Negative Feedback:

Player speed still felt slow, appearing heavy and sluggish for a bee
Some players suggested that Wind Zones could be used to navigate around the world
Players wished for more feedback when interacting with the world, however, all were advised that audio was yet to be implemented into the game
One player mentioned more foliage types and colours would boost the vibrancy of the world
Again, a few players mentioned that a controller would be beneficial for player movement
One player mentioned that upon completion of the tutorial, the wind strokes at the exit were still visible, suggesting the player could not leave the area

Improvements #2

The tutorial Wind Zone was scripted to deactivate upon tutorial completion to avoid confusion for players

2. Due to numerous requests for a controller to used for player movement, Sophia easily implemented this as Unity immediately registered the left analog stick for player movement. Then registering the left and right bumpers as elevation controls, due to how they felt natural when playing the game

3. Using the new controller, the player speed was tweaked to the point it felt similar to a bee zipping through the world, however slow enough to appreciate the game’s scenery and atmosphere

4. Wind Zones strength was increased for an improved challenge to navigation, and to convey the theme of a hurricane disrupting the natural balance of the valley. Furthermore, the frequency and placement of Wind Zones were redesigned to emphasise the presence of wind. This was also beneficial by filling in the empty spaces of the world

Reflection

Overall, I am delightfully proud of To Bee, and grateful for each group member’s input into bringing this concept to fruition. I set out to design a game with a scope that allows me to test the limits of my design and development capabilities; I have had the opportunity to extensively improve my skillset and learnt valuable tools that will aid me on my journey to becoming a successful Game Designer. I naturally fell into the role of Director for this project, and the project’s success has given me confidence that my game concepts and ideas are strong. I am particularly proud of my ability to lead a team, identifying the strengths in each of my colleagues and bringing out the best in everyone to work together on a shared vision. I took particular care in creating a clear ethos for the game and ensuring we’re all aligned on this. Credit to Mesha, who as Producer, took the lead in organising and recording our meetings – no easy feat with a remote team.

Player feedback was a vital part in the game design process – it reaffirmed the appeal of the vibrant and atmospheric, yet minimalistic world I set-out to create. This feedback also gave insight into areas of improvement:

In response to feedback, I intend to implement a feature that temporarily boosts player movement speed, addressing concerns regarding the sluggish movement. Possible ideas for a trigger include: a boost to speed in pollinated areas of the game, when carrying pollen or adding a consumable in the form of nectar.

In my initial concept of To Bee, I included a player scaling up mechanic when collecting pollen; similar to mushroom consumption in Super Mario, as I believed this feedback upon each interaction would add a further layer of engagement with the environment. However, this deemed difficult for the animators to produce. Fortunately, we were able to sustain this layer of engagement with audio feedback and found that it worked work well enough for the scaling mechanic to be excluded from the final build. In future iterations, I may revisit this mechanic once I sharpen my development skills further.

Another mechanic up for consideration is an independent input for camera movement that would enhance the feel and polish of the game, as players could explore the world with more freedom. While we attempted to implement this, we were not able to develop the mechanic to a polished level and excluded it for the time being.

During playtesting, there were a few interesting ideas that we considered. One of which was using the existing wind zones as navigational tools to access inaccessible areas of the game, adding more challenge and strategy to the exploration element of the game – this remains a mechanic worth investing in down the line.

There was an ongoing discussion amongst the team regarding implementing enemies to the game. As game designers, Sophia and I considered this, but concluded it would not be feasible to design and build the components of a fleshed-out opposition such as health systems, AI, battle mechanics (projectiles or melee) within our timeframe.

Given our limited turnaround time, we were unable to fully address a small number of in-game technical faults. These issues included music muting in certain sections, specifically during the ending credits, as well as some minor camera issues. We implemented two soundtracks with juxtaposing emotions that would play in different areas of the world – we encountered an issue with transitioning between the two soundtracks and were unable to make this as seamless as we’d envisioned. Finally, I intend to conduct extensive research into how to optimise the game to boost performance, in particular eliminating framerate drops and reducing loading times.

To Bee Playthrough

PU001741: Design and Prototyping

12 Seconds to Poop DevLog

Post author By Hisham Jarad
Post date 13th January 2022
No Comments on 12 Seconds to Poop DevLog

12 Second Unity Physics Game Prototype (Collaboration w/ Shijie Song)

Aims

To produce a game that would never exceed 12 seconds, win or lose
To build a simple control scheme due to the short duration of the game
For players to feel satisfied to continuously attempt to complete the game despite failure

Development Process

Explore and draw up concepts: “Race Against Time”, “12 Seconds to Poop”
Outline the different components necessary to build this game: a UI Start Menu; including instructions, a Timer, the Rotating Mechanism for the Maze
Use C# script to build components, e.g. for aesthetics – fading start up screen
Illustrate and import maze from Photoshop
Add necessary physics components to game objects, e.g. Gravity Component

Feedback

The ball would get stuck in certain pathways of the maze
Players had difficulty completing the game on their first go, constant trial and error between different maze routes made the game feel tedious
Players appreciated the concept of the game, finding it both clever and funny

Reflection

A few bugs had arisen in the prototype, including the ball getting stuck or transported between walls. Revamping the rigid body components of the maze should amend these issues. Building a captivating game that only lasts for 12 seconds was difficult.

PU001741: Design and Prototyping

Bull in a China Shop DevLog

Post author By Hisham Jarad
Post date 13th January 2022
No Comments on Bull in a China Shop DevLog

Avoid and Collect Game Prototype

Aims

Create an endless running game that gets more difficult over time
To give the player both health and scoring components, implementing an element of competitiveness
To randomly generate different patterns of obstacles and collectibles, to avoid and collect respectively

Development Process

Contemplate the mechanics and different themes for this prototype, this includes finding Sprites for Game Objects
Code Player Control, Obstacles and Collectibles to meet minimum requirements of the brief
Create a Spawner game object via a C# script that generates obstacles to spawn in random patterns, and spawn progressively faster over time
Implement a light health and scoring system to make the game competitive for players
Polish game: by adding particle systems for aesthetic effect, and generate a script that destroys game objects once they leave the screen’s field of view, to prevent lag

Feedback

Players felt that the game should start a lot more difficult than it does, whereas others felt it should get harder a lot faster than the code dictates it to
Some players felt that it was difficult to see certain objects, as most of the game objects are the colour brown
Players enjoyed competing to obtain the highest score

Reflection

The endless runner genre was a big inspiration for this game, implementing a progressively difficult obstacle system was a key aim that I felt was met. Although players felt the difficulty could be more challenging at times, the game would eventually get to the difficulty they desired. Implementing a difficulty system via a UI Menu Screen, offering “Easy, Medium, Hard” would address this, tailoring the game to the skill level of each player.

Ideally, original sprites would have been used to make the space feel similar and vibrant, however, as this was a prototype, all sprites were imported from the internet.

PU001741: Design and Prototyping

Crime Scene DevLog

Twine Game Prototype

Aims

To compose an immersive/descriptive script, that would influence players to imagine the world and characters, independently from player to player
To develop some degree of player agency, providing players the opportunity to navigate freely, preventing linearity
To build a game that reacts to a player’s actions, e.g. certain actions reveal new dialogues previously inaccessible to the player

Development Process

Build characters and script: includes personalities, relations and their purpose in the game
Think of the end game, accusing one from a roster of multiple suspects. This limits scope when developing scenes
String pathways together – includes alternating pathways after player’s are given a choice. Blocking out previously visited scenes where applicable
Build clues and evidence system – difficulty to generate an inventory using Twine’s built-in coding engine

Feedback

Play testers wished for less linear dialogue paths during conversations
Testers believed that including music and sounds to the game would benefit player immersion
Most play testers enjoyed the game dialogue and were captivated by the storyline, discussing between themselves to ensure they accused the right suspect

Reflection

This prototype met my intentions for player immersion and agency. When spectating during playtests, players tend to pick different paths to one another. The script was humorous and easy to follow, during conversations players would immediately have their own opinions on each suspect and react to what they had to say.

For future updates, giving players multiple text prompts when replying to NPCs allows for greater control, and less like they are reading a book. Solving the inventory issues will add an extra element to the game, where players are able to recap their discoveries as the game can be quite lengthy.

The game title “Crime Scene” acted as a suffice indicator to what players can expect. This game was always intended to be solely text-based so that player imagination illustrates the narrative, so personally, the inclusion of music or sounds is not necessary.

PU001741: Design and Prototyping

The Grand Heist DevLog

Escape Room Puzzle Prototype (Collaboration w/ Abhimanyu Chattopadhyay)

Aims

For players to use multiple physical spaces during the game
For players to easily locate and solve tasks with little or no guidance
To create a captivating story, via an insight into a fictitious character, retracing their steps over the course of the Escape Room

Development Process

Discuss different narrative approaches to determine the plot for this Escape Room, agreeing on the Heist genre
Exploring various types of tasks, e.g. shading, tracing, jigsaw
Create the main game item, a journal, using coffee to make it look authentic, in order to produce a compelling story element for the game
Plan the flow of tasks, and how they are incorporated into the journal

Feedback

Players appreciate the journal’s appearance, describing it as authentic, as it helps set the scene for the Escape Room’s narrative and makes for a more interactive experience
Play testers had difficulty locating where and how many tasks could be found in the contents of the journal, often having to be directed where to look
Once some players had realised how to identify the tasks, they would look for more despite there being no similar tasks
Some players were confused once they had to move location once all journal tasks had been completed, this was usually due to not having read through the journal thoroughly

Reflection

This prototype included a gripping narrative along with a set of challenging cryptic tasks, meeting the development objectives. However, players had difficulty finding the tasks. Implementing indicators such as shading in some words on the same page as the journal shading task helped minimise this. An indication to the number of tasks that could be found in the journal would also help with any confusion for players.

Due to the nature of certain tasks, such as cutting out certain objects in the journal, playtesting this prototype was made tedious as extra journal copies had to be made for each trial.

PU001741: Design and Prototyping

Formula Fun DevLog

Race Game without Dice Prototype (Collaboration w/ Jia Liang Cai)

Aims

To give players the freedom to choose how much they want to move their piece by, along with consequences to prevent players exaggerating
Implement an element of strategy for when players compete against one another
To balance the number of moves made my players and the length of the race, ensuring the game is not drawn-out nor short-lived

Development Process

Contemplate and explore different ideas to replace dice found in typical board games
Upon considering different themes, we agreed to base the prototype on Formula 1
Determine game mechanics: shortest and fastest routes, how players choose to move their player piece
Outline a consequential tyre health system, finetuning this with playtesting
Design board and player pieces: finding 3D models online in order to 3D print a set of blue and red pieces

Feedback

Players preferred having a single track between corners rather than two separate paths, keeping corners separate, introducing a slip stream feature; inspired by Flamme Rouge
Players advised that instead of each player taking turns to move, a count of three allows both players to reveal their desired move at the same time, making movement competitive and random
Players preferred using physical pieces to represent movement rather than using fingers when counting down from three
Various tweaks to the health system advised by play testers allowed for smoother game flow
When play testing, one lap around the track felt too short, so an increase to two laps per game seems beneficial for enjoyment

Reflection

Player feedback has greatly benefited this prototype, for example, the introduction of slip stream causes players to think before they move, considering where their opponent is on the board, emphasising the desired element of strategy from my own personal objectives. Clear instructions, in text form, would allow easier understanding of game rules and mechanics for players, rather than verbally explaining to play testers.

PU001741: Design and Prototyping

Limb Reaper DevLog

No Components Game Prototype

Aims

To create a game that was both fun and not complicated for players to understand
To implement a player vs player aspect to my concepts; similar to existing No Components Games
To achieve a competitive nature between players, to ensure investment from play testers

Development Process

Research into existing No Components Games, e.g. Rock Paper Scissors, Viral Pointing game, Eye Spy, Charades, Hide and Seek, Arm Wrestling. Drawing inspiration to produce an original concept
Playtest original rules with an opponent, taking feedback on board to design a new set of rules
Playtest new rules with an opponent to experience game flow and duration

Feedback

Players felt the original rules made the game too short, play testers advised giving players the opportunity to regain a lost limb
Players were confused by how to mirror their opponent using a limb they have lost
Confusion as to who was attacking or defending each round

Reflection

This game was enjoyable for players, both players and spectators were invested and would cheer when a limb was guessed correctly. Regarding how to mirror an opponent when you have lost your own limb, implementing a pointing feature resolved this, as using eyes was not accurate enough. Also advising the attacker to count down from three prevented any confusion between rounds.

Ideas to make this game for three players or more had been discussed, with a clear vision for future development and interesting concepts.