Catastrophe Factory
A top-down puzzle game where the players use environmental levers and lasers to escape.
SHORT DEscription
A top-down puzzle game where the player will use environmental elements such as levers and lasers to navigate their way out of a cat plushy making factory.
Game Goals & Features
Catastrophe Factory is a single-player 2D environmental puzzle game. In the first area players are introduced to the core mechanics of cracking tiles, levers that move blocks up and down, and the collectible fish. Players learn that by stepping on different tiles and levers their decisions are impacting the game space and they must think critically in order to progress.
In the second area players are introduced to lasers, laser redirectors, and laser receivers. The player must avoid lasers or else they will die and have to restart. Blocks and levers can be used to block lasers from harming the player, tying in the previously introduced mechanics. Lasers can change directions when entering a laser redirector, which is used to have lasers activate laser receivers. While a laser is hitting a laser receiver, the exit door is unlocked.
In the third and final area players are introduced to conveyor belts. Players can step on an entrance tile to walk onto a conveyor belt and be moved along the line. Be careful, if a conveyor has the player go through a laser line the player will die and have to restart. Conveyors can’t be entered from the sides, making the player navigate back to the start of the conveyor to get on.
Context
In Catastrophe Factory players play as Patch the cat as they attempt to escape from the cat plushy making factory they accidentally wandered into. Players navigate through the factory to get back out, all while collecting as many fish treats as they can to satisfy the cat and make the journey worthwhile.
Game Pillars
Puzzle Solving
Spatial & logical awareness
Casual Mobile Gameplay
Pickup & put down, short levels, easy to understand mechanics/movement
Repeating Levels for Completion
Replayability to 100% levels, get all the fish, try different approaches for completion
Project Details
Role: Level Designer, Game Developer
Client: SMU Guildhall Team Project - Neon Duckies - TGP 1
Platform: Android
Tools Used: Unity 3D, C#
Year: 2021
Team Size: 6
Development Time: Approximately 2 ½ months
Team Name: Neon Duckies
Team Members Name / Title
Tim Herrmann / Software Developer
What I did on Catastrophe Factory
On Catastrophe Factory I was the principle level designer for Area 2 of the game. This Area has 1 tutorial and 3 levels.
Area 2 Tutorial
Tutorials and Level 4-6
Level Design Goals:
To teach laser mechanics of the game to the player.
Introduce the concept that lasers can kill the player, the player can block the lasers with the lever, the player can redirect the laser using the redirector and that the player has to use the laser to connect it to the laser catcher to open the door.
Introduces the player to the laser, laser redirector, the laser connector, and laser catcher.
Reinforces player movement, fish collectables, and lever mechanics.
Level Summary
Through the levels I created I focused on reinforces player movement, fish collectables, lever mechanics, one color walls with switch lever sates, laser mechanic, laser redirector, and the laser connector. I also increased the difficulty a bit, and playtest and iterated off the feedback I got from my stake holders and playtesters.
My Post Mortem
What Went Well
During the design process, I found it easy to work with others coming up with design ideas that improved our game mechanics and level design goals.
Due to my experience working as a game designer / developer, I experienced very little friction when I needed to brainstorm and come up with ideas and levels during extremely quick design sprints.
Over the course of development I designed, built, play tested and improved 3 levels of Catastrophe Factory that focused on the laser mechanic, as well as 1 tutorial level on the laser mechanic.
Aesthetically, these levels accomplished the goal of teaching the player on the rules of the laser mechanics and challenged them with it in different ways each level.
What Went Wrong
At the latter part of the development process, I struggled with building off my original game mechanic ideas, and level design goals. Creating new ones are fun and easy, building off them is quite the challenge.
I also struggled with keeping track of the overall game goals, my levels were in the middle, so I had to keep track of a lot of design changes between the levels before and after mine, what they were teaching and when they are being taught and how hard the player is being challenged.
Because our sprints were very quick, I should have been more diligent in tracking our game systems and level mechanics on our GDD and LDD tracking excel sheet and taken time to ask for more help and information from the other designers when they made a change in their level.
What I Learned
In a short amount of time, I learned the complexities of communication in a small scrum team with extremely fast sprints.
I learned the design and development spiral design sprint process. Risk Analysis (Sprint Retrospective / Sprint Burn Down), Customer Evaluation (Sprint Review/ Usability Testing), Engineering (QA / Daily Scrum), and Planning (Scrum Boards / Sprint Backlog).
our team postmortem
What Went Well
During development, we meet just about every deadline, we only had to crunch once as a team, and it was for a day. We also got along well and moved quickly during sprints.
Flexibility with ideas & ability to pivot
Ability to rapidly iterate
Collaboration & communication was fluid
Easy onboarding of a new team member
Friendly & productive team culture
Excited to come in everyday
Game was always in a playable state
Tim always accommodated other disciplines, made sure the code would last throughout the project & was designer friendly
Didn't work outside of class, was able to complete work on time, minimized crunch
Honored the scrum process & learned/improved
Stayed true to the initial vision
Having a producer, Sydney, to keep the team organized & on track
Had trust with Kim as a stakeholder & her feedback to improve our game
What Went Wrong
During development we struggled with conveyance a lot and even when we came up with many solutions and implemented them and play tested it. Our conveyance improved quite a lot, but it was still hard for players to understand completely the mechanics of the game before interacting with them.
Friction for the player was reduced but we struggled at a team to solve it, conveyance is a design issue, but it required our art and programming team members to create new assets and implementation to test it, it was quite time consuming.
Had a lot of conveyance struggles throughout the process
Major Perforce issues, especially with the .meta files
Later in the project it felt like the LDs had a hard time coming up with work to do, no more LD work to be done
Discouraging to throw out ideas for new levels & features
Struggle of trying to avoid feature creep
Misunderstood the PoCG milestone requirements
Tried to show the best of our features by making hard levels, but this led to losing the fun & the playtester’s being totally confused throughout due to lacking conveyance & teaching
Design was hard to visualize in the LDD
Difficulty "finding the fun" & coming up with consistent iconography
Artist was asked to redo assets multiple times
Lack of time & resources
What We Learned
Over the course of development, we learned that conveyance was the most important aspect of any game. As a team we created a solid game and all the levels were created, implemented, and tested but after all that work, we still had conveyance issues. This was a fascinating outcome we were successful as a team, but still had conveyance issues.
Would have liked to have more time on milestones/overall project
Needed a better work pipeline & commitment to file organization/naming conventions
Would have liked to have a larger room with windows
Have early collaboration between art & design to get iterations on assets
Miro was frustrating, would have preferred another software
Making a task required too many small steps, led to avoidance
Slow to load up, especially once there were multiple images & files in it
Would have preferred physical board, Trello, Jira, etc... (Something more specifically geared to the task)
We started putting date completed on tasks to help with sprint retro documentation
Would have been nice to have documents like the GDD, Asset Dev Doc, & Epics Doc at the beginning of the project rather than completing them retroactively after launch
NEXT
Buffalo Trace Distillery Virtual Tour
A multi-platform virtual tour
Ghosts of DUMBO
Explore DUMBO, play games, summon ghosts