Documentation:

Comparing

The Vision Laid Out in the Concept Document

With the Final Game:

Differences listed and justified…

The main differences between the ‘original vision’ and the final game, are mostly to do with how far I have progressed in exploring my level ideas for Biscuit Run. I have many level designs and so many more idea sketches, that haven’t been created in this iteration of the Biscuit Run Game Project. This step-along-the-way finish-line really clarifies for me what is involved in bringing an idea into existence. The flow of the game and the need to gradually increase the level difficulty are important, and this has meant more time and experimenting with these game elements rather than constantly building new features. The only feature that really will always be different from what is in the concept statement, is the look of the characters because the art design has gone to a blockier style, but the majority of differences are attainable in future iterations, but just not here yet:

For later iterations the ‘difference gaps’ that will be closed are:

‘Moving and shifting walls’: So far only the Dropper Spikes serve as moving platforms.

‘Puzzling maze-like levels’: So far only a few levels really involve any problem solving.

‘Player controlled anti-gravity’: I have this implemented in scripts, but not in levels.

‘Mental challenge’: there is so much more scope for designing levels that are fun to figure out.

Other game aspects seem to line up well with the concept document, such as the game being easy to play and hard to master – although some further refinement of incrementing the difficulty level may be required to truly say it is easy to play for most people. Some players have said to me that they aren’t any good at the game.

Generally, the differences in art design, are justified by the gradual development of a blocky style through using the tools that unity provides, that I think is very coherent and clear. I really enjoy where the graphics have gone. The other differences are, as mentioned already, just a matter of how long it takes to implement things like puzzle mazes with moving walls. I opted to generate more simple levels that gradually get more complex, rather than creating 2 or three trickier mazes. There are definitely samples of these ideas already there, and to me this is a temporary shortfall because this is a prototype made with limited time, using an iterative process that is gradually developing the game’s outcome, rather than a change in direction.

Summary of feedback from the Game Testing Session:  

What existing features would you like to see more of?

The general flavour of all the feedback for this element was that the testers would like more moving threats, and complexities such as varied individual character pathways that cross-over, varied antigravity experiences, and maze-like levels. More widespread use of the lighting and shadows featured in level twelve was also on the list. This all ties together with my existing plans for further expanding the game through exploring a range of unusual new level experiences. I have already introduced one more level with the moving threat of  the Enemy Capsule “pusher blocks” in a unique scene where players do cross paths – so I am hopefully ticking some of these boxes already!

Did you finish the game (and see the Eat biscuits scene)?

83.3% of my game testers said they finished the game, which is a good indication that things are flowing okay now. I had removed a problem level identified in a previous feedback session, which really was a bit hard and annoying, and since the testing I have shrunk the colliders on the spikes just a little bit in the hope that this was prevent the remaining 16.7% of players from becoming frustrated.

Which aspects did you enjoy the most?

The feedback indicated that the most enjoyable aspects of Biscuit run are elements that contribute to the level of challenge that is packed into the achievable screen-sized levels. Aspects of this nature which were mentioned include: controlling both characters independently of each other, the enemy capsules (“pills”), and the chaos of some levels that required thinking about how to solve them.

Could you break the game? Did you find bugs? If so please comment.

Six game testers and they returned 4 different bugs. That was productive.

Bugs reported included:

• The testing revealed a buggy Dropper Spike enemy, which I later realised was a result of failing to apply changes to a prefab/ This has been fixed and now players can jump on the tops of all the Dropper Spikes enemies (without respawning) – just watch out for the spiky bits!
• The end screen UI element that revealed the player’s scores showed weird values if you just visited the End Scene via the Title Scene’s level select buttons. This also has been fixed. Now there is a nice message there for people instead.
• The antigravity controls were easy to tap accidentally and were causing problems. These controls have been disabled using a boolean in the movement script and can be switched on for suitable future levels as required.
• At the beginning of each, while the characters were dropping onto the platform, a key held down would send the character hurtling off the platform. I thought I had fixed this previously, but it turned out that I had only frozen player movement during respawn. This has been fixed now so there is a short delay before the players can move the characters, while they drop onto the platforms at the start of each level.

What features/issues would you like less of?

Only one game tester responded to this one, with a comment that seem to contradict some other positive feedback about complexity by requesting to see less levels with too many moving parts. I think that highlights the risk of frustration with accidental ‘death’ can occur in complex scenes. I will try to keep the flow and more gradually increment difficulty in the future.

How well did the levels seem to progress?

The majority of the critical feedback suggested that the difficulty was good but the levels were not in the right order of ascending difficulty and could be rearranged. I have taken this on and reordered some levels. I will try to increment levels consistently in future. There was a comment that some levels didn’t seem to add much, and I think that was due to the arrangement, but will value incrementing difficulty correctly as more levels are created in the future.

Any other comments or feedback?

Following on from the last testing element, in order to steadily increase difficulty in levels, I will follow feedback and (at some later iteration) shorten some of the Respawn Timers. Plus some special effect (like screen-shake on respawn). Sound might fill this need. I will see.  

Other general vocal feedback during the live testing session, included the suggestion of adding more tutorials to early levels and introducing enemies more gradually. I have already added a level that does both of these things, and plan to do more later.

List of Assets:

UI:

Canvas, Background and Event System

Button sets with text elements:           - used for Level select, Start Game, Play Again.

Title Text        To make the game look pretty

Players:

PlayerOrange  - The blue character object

PlayerBlue      - The orange character object

+feetOrange    -Child object of Player (with trigger collider) to detect if they’re on the ground

+feetBlue       

Enemies and Obstacles:

Enemy Triangle

Enemy Dropper Spikes

Enemy Capsules (“pusher blocks”)

Block-jumps

Spikes (of several varieties)

Off-screen Death/reset barriers

Goal Objects & Managers

Goal Orange Level Managers – The circular goals of each level

Goal Blue Level Managers

Score Manager

Scene Index Checker

Prefabs:

Platforms (OrangeGroundPlatforms, BlueGroundPlatforms, ParentPlatforms)

Particle system (biscuit explosion)

…

90% of all these assets are prefabs.

Scripts:

BiscuitRunPlayerMovement – the players movement script

DeadFall – used by the Dropper Spikes

DestroyAfterTime (adapted from KIT109 tutorial script)

DraftMovementScript (For reference - containing iterations of methods all commented out )

FlashButton (for StartGame and PlayAgain buttons)

LevelManager - Loads new scenes, etc.

PatrolSliderBlock – used by the Enemy Triangles and Capsules.

PlayerEnemyInteraction – used so the player can ride the Dropper Spikes like an elevator!

resetPlayersAndTimer (currently unused respawn player script)

ReverseGravity (currently unused)

SceneCheck (currently unused - but for when I implement player controlled Reverse Gravity for some levels)

ScoreManager – track attempts and counts levels

ScoreScript – Displays the players final score at the End Scene

StartGame – To Start the game and levels from UI buttons

TimerScript – Runs the timer

Additional Features List:

Custom Art:

Title art in Title Scene and End-Scene title art using partical effects)

Simple Scene design and layout

Enemy design

User Interface (UI) Functionality:

End of game screen with feedback on how well the player performed

A Restart Game button

Basic UI Art: Flashing Start Game button and Level Select buttons integrated into the scene.

Timer: Displays the countdown left before the characters are respawned.

Controls:

Local Multiplayer Controls

•  Also:
  • ‘R’ to reset scene
  • ‘0’ (zero) to return to Title Scene
  • A currently unused Reverse Gravity controls ;-D

Advanced programming Functionality:

Basic Artificial Intelligence (Enemy movement)

Multiple Levels [counts as 2 areas]

References & Sources:

TimerScript script: // The original (unmodified) script was sourced from : https://www.youtube.com/watch?v=hxpUk0qiRGs

PatrolSlider script was modified from the source:  https://www.youtube.com/watch?v=aRxuKoJH9Y0  

PlayerEnemyInteraction script used a method to make parent/child which modified from: https://www.youtube.com/watch?v=O6wlIqe2lTA  

LevelManager script got some of the method for loading scenes from: https://www.youtube.com/watch?v=26d1uZ7yrfY

ScoreManager script was based on code written by: Lake Hopkins (2023) but was still hard to make work ;D 

DestroyAfterTime script was modified from UTAS KIT109 Practical work.

BiscuitRunMovement script sourced the Rotate() method was sourced from: https://answers.unity.com/questions/1768573/trying-to-reverse-2d-players-gravity-after-collidi.html  and contains a method 'Hyperspace' which was clearly not very surreptitiously modified from KIT101 Tutorials.