top of page

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.







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


The style and theme of the game has a look and feel that isn't too serious and welcome a broad audience.


Short sessions that invoke stress in the player, also makes for a replayable & competitive experience.


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?


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.


Throws your flow off Adds a layer of disruption to the learning process and extends the playtime, also contributes to the worldbuilding

Gameplay Design

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


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.


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!

Golden Path

Product Owner

As the Product owner I focused my efforts on conveying the vision/game to the team and the First playableAlpha, 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.

See "Gameplay Design" for how I did scoping

Keeping vison
bottom of page