UNITY ENGINE
TOOLS
FIREBASE ANALYTICS
VISUAL STUDIO
ATLASSIAN SUITE
GOOGLE SUITE
POSTMAN
Get your shellmet’s ready!
Crab God is an innovative game that seeks to change the world through environmentally sustainable gameplay. Such a game called for equally innovative process to match it’s QA. On this project, there were many processes I saw had the potential to be better than best. On this page are a few examples of those.
My daily tasks included functionality testing, smoke testing, user acceptance testing, and eventually release testing!
✩ Key Roles ✩
🦀Being the crab-champion (racking up the most hours in the game and then smashing my co-workers in an in-house Crab God tournament)
🦀 Testing the game prior to release
🦀 Working with the designers to curate gamemodes, make user driven decisions, and provide feedback on rapid design iterations
🦀 Deliver accurate UX findings to support design and development changes during high pressure deadlines
✩ Challenges ✩
🦀Having to rapidly burn through design iterations to quickly keep or cut proposed design features in a tight delivery timelines
🦀Having to grow the mental fortitude to organise and collate external and internal testing feedback, and then iterate on those opinions
🦀Learning how to prototype quickly within the engine using Jira, C#, and recognising when something was outside of my capability and asking for assistance
✩ Outcomes ✩
🦀Learned to adapt to high pressure situations, and act with empathy and understanding in particularly stressful sprints
🦀Have a better understanding of Unity engine, rapid prototyping, and coding in C#
🦀Developed interpersonal skills, leaving pride at the door and knowing when to ask others for help
🦀Grew stronger skin, learning how to take feedback and criticism as a positive step toward a stronger game
✩ GAMEPLAY VIDEOS ✩
✩ TIDE TRIALS ✩
CURATING GAMEMODES
Upon the release of Crab God, the senior designers had a major piece of feedback to tackle from the first wave of paid players:
Replayability.
In wake of this, we decided to implemented gamemodes as an addition to our patch one update. The limitations from production were clear:
a) Trials had to have a low development and art cost/utilize existing systems
b) Trials could not be overly similar to existing gameplay loops in the standard mode
c) Trials had to be implemented rapidly (roughly in the forthcoming two sprints), with low-cost prototyping and validation before implementation
Ideas were rapidly prototyped. A few of my own ideas included a “fast trial” mode to cater for players who disliked the slower pace of the game, a “deadly trial” mode which was basically for masochistic soulslike players, and a “timed trial” for players who enjoy a crushing deadline.
I digress — these ideas came with a lot of discussion and back and worth between QA (which I was currently still doing for this project) and the design team. My QA background allowed me to nitpick design ideas with a broader knowledge on how the game works to a player, and not as a designer.
I gave lengthy feedback after playing every mode (dedication to the craft) and worked with the senior designers to catch possible edge cases, and contradicting implementations:
For example, a late change to the gameflow was being able to swap a crabling role during the intermittent shelter scenes. This conflicted with our “no-swapping roles” trial, which I alerted development of. It was eventually made that role swapping was disabled only for this mode:
✩ PRESENTING DATA ✩
SPREADSHEETS! I LOVE SPREADSHEETS!
Spreadsheets are an integral part of design, as taught by my senior designer. Almost everything was tracked in sheets, whether it was balancing changes, trait types, or copywriting content (some data blurred for privacy). This was also the preferred method of communication to production, as they would read the values and make edits using Google’s handy collaboration system. This also eventually made localization easier as we were working with an external translation team, as well as proofreading and peer-reviewing content.
I used to hate spreadsheets, and to be honest, still do — but being able to use it not only as a way to convey data, but as a low-cost digital prototype using Google formulas is invaluable.
✩ QUALITY ASSURANCE INNOVATION ✩
BETTER TESTING, BETTER GAME (WHO KNEW)
On Crab God, I fulfilled QA responsibilities such as functionality testing, release testing, acceptance testing, and smoke testing. I wrote bug reports and suggestions on Jira, as well as tested through this platform.
When I first came onto the project, there were a bunch of improvements I saw possible! Here are a few.
SMOKE TEST SHEETS
🦀 OUR PROBLEM: Previously to me being on the project, smoke test issues were logged in our project Slack channel. Whilst these were eventually logged into Jira, it was difficult for production to prioritize and expedite issues that were blocking game play before the start of the next sprint.
🦀 MY SOLUTION: I workshopped a smoke testing sheet, which is used on every project till today. This sheet allows QA to give their opinion on bug prioritization, but also opens a discussion with production to reassess sprint priorities. Additionally, bugs in the sheet that were marked as ‘need to fix now’ would send an automated alert to the developer assigned to the task.
DESIGN REVIEWS
🦀 OUR PROBLEM: Features were being implemented rapidly by design, so certain features would contradict pre-existing implementations and cause either UX or system issues.
🦀 MY SOLUTION: I campaigned for a tighter alignment between design and QA, looping QA earlier into the design process to pick up potential edge cases or possible error outcomes. This collaboration also built up a stronger camaraderie between design and QA, that ultimately assisted with stronger designs that furthered the player’s perception of Crab God’s unique selling points.
PRIORITY TICKETS
🦀 OUR PROBLEM: It was unclear as to what tickets needed to be validated ASAP by QA when a developer was finished with a feature. This was previously done by word of mouth or Jira priority assignment, but as features were being completed, it took me a short time to realise that despite some features being “low-priority”, there were still a pattern of tickets that needed to be completed before the end of the sprint to align with client or production expectations.
🦀 MY SOLUTION: I prompted the creation of a smoke testing ‘ticket’ — a master Jira ticket that encapsulated all tickets to be completed by the end of a sprint. This also made determining when to begin smoke testing more clear: it was as simple as wait for the checklist to be completed.
