Shatterbound
Work with your past (and future) selves to solve puzzles. Shatter your obstacles, be your own platform, and more in this time-looping puzzler where YOU are your own solution!
Contributions​
-
Created 140+ test cases revolving around breaking the game’s mechanics.
​
-
Performed functional testing by sorting out two
​
-
Used black box testing to test both the necessary features of the game and any possible action that could potentially break the game.
​
-
Designed the particle effects for some of the power actions the player performs.
​
-
Created a small capsule for the game (for marketing the game on Steam).
​
-
Reported 30 different bugs on GitHub.
Tools​
-
Google Sheets​
-
Unity
-
C#
-
HacknPlan
-
GitHub
-
GitKraken
-
Krita
​
Deliverables​
-
82 test cases logged in a Sanity Check Test Suite (via Google Sheets)​
-
41 for testing with a keyboard​
-
41 with console controllers (Xbox and PS4)
-
​
-
142 test cases logged in a Full Test Suite (via Google Sheets)
-
41 for testing with a keyboard​
-
41 with console controllers (Xbox and PS4)
-
​
-
30 Bug Reports (via GitHub)
​
Reported Bugs
-
Ghost spawning problem after dash on vertical glass (Test Level (build and editor))
-
Description​
-
When you dash on the vertical glass near the goal, the player will respawn successfully, but a ghost doesn't get instantiated.
-
-
Environment ​
-
PC
-
-
Steps to reproduce​
-
Jump off a ledge and move near a vertical glass.
-
Dash towards the vertical glass.
-
-
Expected Result​
-
The player dissapears.
-
The player re-appears at the starting point of the level.
-
A ghost, reflecting the player's previous playthrough, spawns.
-
-
Actual Results:​
-
The player dissapears.
-
The player re-appears at the starting point of the level.
-
A ghost, reflecting the player's previous playthrough, spawns.
-
-
Severity:​
-
Severe​
-
-
Evidence:​​​​​
-
-
Seesaw Physics Problem: Player sticks with see saw
-
Description​
-
When player is pushing see-saw horizontally and when the see-saw platform goes up, the player goes up with it.
-
-
Environment ​
-
PC
-
-
Steps to reproduce​
-
Make sure one see saw platform is on the ground.
-
Move to the left or right side of platform
-
Push it left or right.
-
-
Expected Result​
-
The seesaw moves as expected (in the direction the player pushed it towards).
-
-
Actual Results:​
-
The seesaw moves as expected (in the direction the player pushed it towards).
-
The player slightly rises vertically with the seesaw, almost as if they were glued to it, for a brief moment, then drops to the floor.
-
-
Severity:​
-
Mild
-
-
Evidence:​​​​​
-
-
Dashing into spikes won't let the player respawn.
-
Description​
-
Dashing into spikes won't let the player respawn. Instead, the game will pretend that they're in the same position in which it died.
-
-
Environment ​
-
PC
-
-
Steps to reproduce​
-
Jump
-
dash either left or right on a vertically aligned set of spikes.
-
-
Expected Result​
-
The player dies.
-
The player death animation plays.
-
The player respawns back to the starting point of the level.
-
-
Actual Results:​
-
The player dies.
-
The player death animation plays.
-
The player respawns back to the starting point of the level.
-
-
Severity:​
-
Severe
-
-
Evidence:​​​​​
-
Lessons Learned
-
The Importance of the Sanity Checks
-
When starting the development of Shatterbound, I created a sanity check, a spreadsheet that checks if the game's main mechanics work as intended. ​
-
-
The Importance of Full Test Suites​
-
Along with the sanity check, it was important to create a full test suite, a spreadsheet used to record every possible action in the game that could potentially end up breaking it.​
-
-
Prepare the important guidelines before creating test cases​
-
When creating a sanity check and/or full test suite, it's best to set up important questions. For testing Shatterbound's development, those questions were the following:​
-
Name of the mechanic​/action​
-
Description of what the mechanic/action does
-
Inputs on how to activate the mechanic/perform the action
-
Expected Result
-
Actual Result​
-
-
-
Always check if a mechanic works on both the editor of the engine and the build of the project​​
-
Sometimes, the results of an action performed in the engine's editor don't always match that of the final build.
-
For example, during Shatterbound's development, jumping and ground pounding simultaneously would cause the game to break; sometimes, this bug would happen on the Unity engine, and other times, it would happen in the build. Therefore, cleaning the build of the game was crucial after you tested a(n) action/mechanic in the engine's editor. This action is done so that, if there's a bug found in the game, it's both the editor and build.
-
Screenshots
