top of page

Mouse Playhouse

Development Overview

  • Role: Lead Level Designer

  • Genre: Singleplayer VR Puzzle

  • Team Size: 18

  • Engine: UE 4

  • Platform: Vive

Downloads

kisspng-steam-computer-icons-logo-video-

Game Overview

Winner of 2nd for gameplay at the Intel Unversity Games Showcase GDC 2017

​

Mouse Playhouse is a VR puzzle game for the HTC Vive in which players use blocks and wedges to lead mice through a table full of challenges, to a wheel of cheese.

​

Mouseplayhouse has 15 levels, a sandbox, and multiple interactive toys.

Responsibilities

  • Managed, assisted, and provided feedback to a team of 5 designers

  • Responsible for level design and gameplay documentation

  • Iterated levels and gameplay

  • Ran design meetings with art department

  • Answered game design questions from members of every department

  • Managed level design project backlog

Design

Pre-Production

During pre-production, my job was to work with the game designer to determine what gameplay to test, and decide how the level designers should go about testing said gameplay. 

​

There was a lot of communication between me, the level designers, the game designer, the producer, and the lead programmer to share ideas, determine what was feasible, and coordinate implementation of work. 

​

A major consideration outside of the game itself was how the team worked together. My focus for the level designers was developing an efficient pipeline, collaboration on a single level, and how much documentation was necessary.

Mechanics

The level design department worked closely with the game designer to determine the game's mechanics. I had the level designers create prototype levels to test the mechanics and learn how to best designer around them. I used feedback from the level designers to help refine the mechanics.

​

The game designer wanted a separate document from the GDD that described the gameplay and mechanics, and put me in charge of creating and maintaining it. While working on the document, I finalized the mechanics and their interactions.

​

During production, I determined we needed to cut one of the mechanics. Although the level designers could quickly design and build levels, we were limited by how much time it took to test the levels before we could iterate on them. I realized the overall quality of the levels and how they flowed together would be better if there were fewer mechanics to teach and explore. The game designer agreed, and we cut the mechanic.

Level with cut "jump pad" mechanic

Level Flow

One of my core responsibilties was the level flow. The 15 levels are split into 3 sets of 5. After a player completes a set, they return to the main menu. This idea came from feedback that some players felt fatigued after playing a lot of levels back-to-back. Returning to the menu gives players a chance to take a break and look at their progress.

​

A problem that came up during was we had a lot of mechanics, not a lot of time to teach them, explore them different ways to use them, and test levels that use them. I found multiple ways to overcome this problem; one of the mechanics, along with the levels that used them, was cut. This gave us more time to test and refine the levels and mechanics we have. I also decided to front load the simpler mechanics to the first set of levels, which gave us more room to teach the complicated mechanics and make interesting levels out of them. 

Technical Design

Scripting

Throughout production I helped out with miscellaneous scripting tasks that other people did not have time to do. The largest scripting task I took on was creating the domino system.

​

Dominoes act as temporary walls; mice cannot move past dominoes until they knock them down. The programming team was very busy during the beginning of production so they pushed back development of the dominoes. I wanted to make sure the level designers had as many puzzle objects as they could as early as possible, so I decided to make the dominoes myself.

​

When creating the dominoes, I needed to learn how the programmers implemented puzzle objects and work within the system they created. I took responsibility for fixing bugs in dominoes and making sure the work with other puzzle objects until alpha, at which point I showed one of the programmers how they work and he took responsibility over them.

Packaging

Due to an elusive bug on the lead programmer's computer that hid objects in some of the levels, I became responsible for packaging the build of the game. Through this turn of events, I got firsthand experience the headache of people trying to add something to the build after lock.

​

In addition to packaging the build, I tested it and debugged it. While the programmer took care of most of the programming bugs, a common bug I fixed was textures not appearing in the build. 

​

I also modified the engine so the game appeared on the monitor full screen, rather than the default vertical strip with black bars on the sides.

Post-Production

After the team finished production, I helped work on the Intel University Showcase build and the Steam build with the game designer.

​

Working on the Intel build involved looking into programming I never touched. I unlocked parts of the game so we could show it off in our presentation.

​

For the Steam build, the game designer was having trouble implementing the framework from Steam achievements. I figured out how to get the framework to function properly, and learned you can give yourself any Steam achievement. (For testing purposes, Mouse Playhouse was Dark Souls III)

bottom of page