Super Accurate Washing Simulator
This game was made as a game project during the first year of studies at Futuregames. It was made by a team consisting of designers, programmers, artists, project managers and QA at the school. My main role was Product Owner, but I also worked as a Gameplay Designer.
Project length: 4 weeks
Team size: 12
My roles: Product Owner, Gameplay Designer
Super Accurate Washing Simulator is a goofy, unpredictable, physics based game where you play as a shaky washing machine. Stumble into furniture and break doors on your way to find all the dirty laundry in the apartment.
The theme for the project was Chores and the sub category for my group was Laundry Cycle. Other requirements were that it should be a single player game made with Unity that could be played in less than 20 minutes.
What I did
Tools and how I used them
Miro was used for ideation and early planning. As soon as an idea was settled upon, we switched it for other tools.
Jira was used for task management. We used tasks instead of user stories because it quickly turned out to better suit the team. Different team members wanted different amount of granularity in the task so I adapted to each team member when filling out the backlog. I also created a custom issue layout for bug reporting.
Notion was used for my personal documentation and reflections. It was also a tool to keep track of all project management tasks to make sure I could help the team in the best possible way. Lastly It was also used for the Game Design Document.
Perforce was used for version control. To make sure the team could easily collaborate, I created prefabs for different parts of the level and all interactable items.
Example from my daily documentation.
Organized the team
The team worked remotely and most of the team members had never met before. Because of this it was important to foster a team spirit and active collaboration.
I encouraged being online during work hours by always being active myself and making sure to talk to everybody daily and help out where I could.
The team also had project managers, so in the beginning I had a meeting with them to figure out responsibilities. We decided that I would focus on updating the backlog and design documents, and they would facilitate the SCRUM meetings.
Whenever someone was ill or missing, I kept in contact with them to make sure they were okay and also brought them up to speed when they were back.
Game Design Document
I set up a Game Design Document using Notion to make it easily accessible to all team members.
The document included the pillars, three C’s, level design, gameplay, art style and more.
I encouraged everybody to look through it to make sure we had a unified vision.
I also asked the other designers to fill in the document in regards to their fields, such as UX Design.
I updated the document after every new decision during the project.
Excerpt from the Game Design Document
Although the Design Document was helpful for the designers, it was more important for the rest of the team that the backlog was clearly structured and with the relevant information for each task.
At the end of every week we had a playtest where we got feedback on the current state of the game.
We had meetings after the playtests to discuss the feedback and decide what to focus on for the next sprint.
I updated the backlog accordingly and prioritized the tasks.
When necessary I added details to specific tasks.
Scope and cutting features
Because of the short timeframe for the project it was important to scope it properly. Many ideas came up during the first week. Some features, such as a first person view, was also implemented in early prototypes. After the alpha playtest, the designers wanted to cut the feature but others, such as the programmer who coded the feature, wanted to keep it. As this was a school project, it was important that everybody had equal say. For that reason we had a thorough discussion and eventually the others on the team understood why the designers wanted to cut the feature and agreed. The reason was that it removed the player’s connection to the character and the visual indication of making a mess in the apartment that the third person camera provided.
The backlog during the Beta Sprint.
First Person View that was eventually cut.
A playful vibe should be embraced in all aspects of the game. Everything from character, animations, gameplay, music, sounds and art.
Gameplay should feel a bit chaotic. Movement is clumsy but not without control. While reaching the goal, chaos should arise.
The core loop is is a repetition of finding all the clothes, but the placement of the clothes should feel quirky and fun to make it interesting. A timer and a messiness counter invites the player to repeat the game.
The goal is to find all the dirty laundry in the apartment while wreaking havoc in the process.
Look for dirty laundry
Suck up dirty laundry
The character is an artificially intelligent washing machine which only goal is to find all dirty laundry. To add to the playfulness it was important to give it character. The controls and the mechanics play their part. We also gave it a happy yellow color and used some stretch and squeeze animations and bubbly VFX to give it more personality.
To make it feel playful, I wanted the washing machine to be shaky, clumsy and random, but still controllable. This was achieved by the programmers by adding random forces to the washing machine. In the first playable, it was very hard to control so the forces was reduced to improve mobility, but still enough to stand out visually.
We decided to go with a third person camera to allow for the player to really see all the mess they make accidentally as they move around trying to find clothes in the apartment. We also gave the player control to zoom in and out.
As the movement was made more controllable, we wanted something else that could cause more chaos in the game according to the pillars. We also needed a way to pick up clothes. We combined these requirements with the suction mechanic. The player need to use this ability to get the dirty laundry and while using it, they will also move around other items in the vicinity.
When the player uses the suction mechanic, they will also get smaller items. After a few items, they start to move slower. To get rid of the items they have to shoot them out, causing more chaos in the process. To teach this mechanic we made doors in the apartment that are only destroyed by shooting items at them. The room where the player starts acts as tutorial where they have to shoot the door to continue. To add to the playfulness, the player also gets pushed back when shooting.
We started out by brainstorming ideas. The first step was to let everybody in the team come up with as many ideas as they could. After that we talked about them and explored them.
Eventually we settled on three ideas that we explored even further and tried to figure out how they would work in practice. It was pretty clear after this that everybody liked the Washing Machine idea, so we went with that.
The first prototype showed promise and early playtesters enjoyed the concept. They felt however, that the movement was rough.
Pretty soon after the first playtest, we reduced the random forces added to the machine to make it more controllable.
By the time of Alpha we had implemented the suction mechanic and ability to pick up clothes.
The level design blockout for the alpha build.
For the Beta we now had most of the physics interactions implemented. The UI was partly implemented but we were still working on getting the HUD right. Some lighting had been put in.
Laundry under the couch pillow. At this point we tried to find as many fun locations for the clothes as possible. We wanted locations that would both provide a challenge in finding, but also cause a lot of chaos when picked up.
For the final game we added polish in the form of lighting, VFX, animations, SFX and some shader work to tie it together.