top of page

Otto the Combo Butler

Otto the Combo Butler is a humorous single player 3D puzzle game. Play as an embodied Alexa-type robot called Otto who serves the eclectic tenants of an apartment. Combine two items each matching one of their specified wishes to merge them into an object of their desire!

  • Spring 2018

  • Unity3D, 15-20 minute play time

  • I programmed the puzzle structure, player movement/interactions/UI display; made and animated the UI, designed some puzzle combinations.

  • Made with Temi Olujobi, Isabella Djurovic, Avery Holmes, and Kris Atanasoski.

  • Download and play here on

Development Progress

Check out a detailed progression of the game here on my blog.

Level Design

Our design goal with Otto was to create a charming, humorous experience that made players feel clever and like a robot. As a 3D puzzle game, item placement and gatekeeping were important to achieving this. Where items were placed and in what context changed the difficulty of puzzles drastically. For example, in early versions the power strip in the second puzzle of the game was very difficult for players to locate. We wanted this puzzle to be easier so I took a closer look at the item's placement.

Issues and Solutions

  • It’s the same beige color as the box it’s sitting on. -> In the next build I moved this to sit on top of some black rubber tires to help it stand out.

  • It’s cut off from the main traversal path. Players could access the area, but a collection of boxes made that area feel closed off, so players rarely walked over there of their own accord. Even when instructed where to find the power strip, it took them a while to actually locate it. This seemed too difficult. -> In the next build I moved the strip to be more central and visible as the player walks through the door.

I also designed an A|B test to find these issues in the remaining puzzles. There are six  puzzles in the game, each with one solution. I wanted to measure how long it took players to solve each puzzle (how long it took them to find and combine the correct items, not including the time it took them to deliver it to the requestor) and how many incorrect combination attempts they made per puzzle. I specifically wanted to test how the placement of objects in the level affected playtime. I thought this could correspond to the difficulty of finding hidden objects in the space. Measuring the incorrect combination attempts was an attempt to understand strategy and player interpretation. Since the ‘correct’ adjective of an object in the game was revealed to the player if they combined the object incorrectly with a non-requested quality, I wanted to see if in general players used this to learn about the world quickly (and if so at what point in the game.) I also thought this might correspond to players not understanding the quality of an object they were supposed to find. For example, do they interpret a broom as “clean” or “dirty”?

Build A was our ‘control’ using the item placements the team had designed as part of our gatekeeping strategy to get the player to explore the entire apartment complex. Build B had more carefully considered item placement in which sightlines, color, framing, and the composition of other objects in the room drew players toward items.

The major finding about the time to solve was that puzzles 3 through 6, and particularly 3 and 4, took longer to solve in Build B. In puzzle 3, the hot sauce item was moved to be closer its requestor in Build B, however, this placed the object in a closet out of a direct sightline from the door. In Build A the hot sauce is close by the door, if not directly visible. This may have been a time sink for players who explored the space quickly and might not have noticed the closet. To address this in the next iteration of builds, we chose to keep the hot sauce item in its Build A location in order to shorten the average solve time for puzzle 3.

Our major finding from the number of wrong combination attempts was that Build A had a significant increase in the amount of wrong combination attempts. We think this is linked to the short puzzle solve times in Build A and points to a particular strategy. Build A players may have used the adjective reveal feature often to learn an object’s adjective when they came across it. Therefore, they knew what object corresponded to what qualities when a new puzzle request started. This allowed them to remember where the correct object is rather than always needing to find and interpret the correct object. High wrong combination attempts and short solve times point to this strategy. 

Code Sample

Check out a code sample of the puzzle structure I designed and implemented here on github.

bottom of page