
Erik Larsson
Game Designer
No More Monkey Business
Project Summary
Punch, slam and throw office props through 4 levels of stylized monkey world!
​
Fast-paced gameplay where you try and reach the end.
Genre
​
3D
Destruction
Funny
Engine​
Unreal Engine 4.27 Chaos
Project length​
7 weeks
Team size
​
14 devs
My Contributions
Product Owner
As the product owner and design lead, I made sure we spent our time on the most important and efficient things.
​
​
​
System design
How we managed the player's expectations with destruction
​
Sound design
Monkey voice acting & destruction SFX.
See the "sound design" page
Game Pillars
Light-hearted
The style and theme of the game has a look and feel that isn't too serious and welcome a broad audience.
Stressful
Short sessions that invoke stress in the player, also makes for a replayable & competitive experience.
Cheating
The player figures where they can cut corners in their cleaning.
Gameplay Mechanics

Get rid of items
Two different containers Thee kinds of items. the player explores what places they can be put around the house, and what option is the most efficient

Clean items are worth more
Two ways Use the sink and washing machine to clean up to six items at a time, how many do you have time to clean?
Score
​
Depends on where items are placed. Putting items where they intuitively belong awards the most score. The player has to find where to cut corners to reach the higher score. Depending on the score, the player is also awarded different narrative endings which encourages replaying.
Hazards
Throws your flow off Adds a layer of disruption to the learning process and extends the playtime, also contributes to the worldbuilding
Core Game Loop
Explore item & container combinations through intuition
Plan your actions for the next playthrough
Figure out score values & level layout
The player needs to figure out the fastest way to put as many clean items as possible in the correct container. There isn't enough time to do it for all of them.
​
With the help of the narrative, the player has a chance (very unfair) to figure out the system through intuition because the concept of cleaning is common knowledge.
They are expected to play the game around 5 times to reach a high score. Earlier playthroughs are expected to have the player cheat too much and award them too little score which is comically fun and narratively accurate. Later playthroughs instead give satisfaction through improvement and skill.
System Design
The player has 3 parameters to consider when figuring out the system (learning the game):​
The value of items
Plates & laundry > Bottles.
Their placement
Is the laundry too far away from the bedroom?
Which items do I have time to wash?
Is it faster to fill the washing machine with plates?
Early spreadsheet of the scoring system, designed to give more score for "not cheating"

The system is intuitive!
The rules are similar to the basic concept of cleaning, but with a few exceptions:​
Wash it where you want
You can do the laundry in the sink.
Items where they belong award more
Plates in the kitchen, laundry in the bedroom.
Cheating does not pay off
But it is faster!
More system design under the "Golden path"
Design Process
Because of the short timeframe (4 weeks) we knew that good scoping was very important. There were many ideas on different (mechanically different) kinds of cleaning tasks and levels.
​
We ended up with only one level, and cut some mechanics, it required a lot of faith for a team of juniors that the game's content would be enough.
Design Goals
Feel like a good cheater
The player feels like they are good at cheating.
Fun to explore & experiment
The player is curious to explore different kinds of cheating and what works.
The golden path
It should take ~5 playthroughs for the target audience to reach the "best" ending.
For the base concept I had most of the finished game's core features, but with a larger variety of tasks that we later cut.
​

The option of cleaning in different ways remained throughout development, as did some kind of scoring system that evaluated the player's behaviour at the end.
​

It also contained the concept of hazard mechanics that interrupt the player from figuring the system out too quickly.
First Playable
In the first playable, I pushed for the core mechanics: putting items in containers and getting scored. The level layout was important to get a sense of how the player's decision-making would develop.
​

For the second playable, I pushed for finishing the core loop over every task so that we could have more time for testing which would be important for this game.
My early gameplay loop​
​

Alpha
In the second playable we added a timer which was important for testing how stressed the player would get, we cut some more complicated cleaning tasks and the idea of having more than one level in the final product.
​

We decided that tasks needed overlapping mechanics to save time and the "cheatable" option idea was discarded.
​
My early system overview of player choices with items.​
​

Cleaning the toilet and broom mechanics where cut.
Beta
In the beta, we considered the game feature complete and spent the remaining time on polishing the gameplay experience (number of playthroughs), accessibility, and tutorial for the player.
​

The player's golden path
The Beta was heavily playtested to ensure the player would reach all 3 different ending screens at appropriate levels of playtime.
​
They provide a narrative reward and are meant to be relatable to the player's experience.​
​
The first playthrough is meant to fail. It is almost impossible for new player's to perform well.
​
Therefore the screen is meant to match the player's feeling of unfair treatment, and also as a joke.
​
A grade from F - S is meant to foreshadow how much improvement is possible.

With attempts 2-3, the player should reach the middle screen which rests between score grades C - B.
​
They will reach this as long as they have a basic strategy for how to play.
​

With attempts 4-7, the player will work their way to the final end screen in the upper A - S grade.
​
In order to reach this score, the player has to understand both score values and execute a plan based on previous playthroughs and their own experimentation.
​

Final Product
Due to good scoping and planning, we added a lot of SFX, VFX, lighting to an intro animation, and a tutorial level to polish the final product!
​

Product Owner
As the Product owner I focused my efforts on conveying the vision/game to the team and the First playable, Alpha, Beta and Final release. I kept close contact with our scrum master and kept in mind the skills of the team members and how they fit in with the product.
Organizing the team
How to organize, document and handle descisions made/information was one of the biggest challenges of the entire project. The team was inexperienced working in scrum and common software that facilitates it (ex, Trello, Jira, Hack'n plan etc). We ended up with a mix of scrum practices (sprints, daily standups, and weekly retrospectives) used with lighter organizational tools for production (Miro, Excel) an later switching to Jira.
Due to the short duration of the project (4 weeks) we used a basic MOSCOW prioritization in miro for planning features. The art assets and sound design tasks were kept in separate lists in Excel.
At the start, we wrote a design document in Word that was never read by anyone. Together with the scrum master/design team I learned that for this project our team was better off with lighter forms of gathering information. If we took on the task of learning a powerful tool like Jira, the product would suffer.

Later in the project when we were more comfortable, we decided to make the switch to use Jira to learn it for better scrum practice. This was a difficult adjustment, but important for preparing us for the industry, ultimately we learned a lot from it.

Challenges & Take-aways
With 4 weeks and 9 developers, the team benefitted a lot from proper management to help build trust to steadily work together as strangers.
At the start we put effort on working the game idea together, making sure every member was heard, and writing a good team contract together. We also did a lot of teambuilding. Halfway through the project the team was working in a much more self organized way, which was very valuable.
​
We also recognised the importance of every developer having clear areas of responsibility. This led to less task switching and more meaningful work.