When we started brainstorming ideas for MouseBot: Escape From CatLab, we knew we wanted to make something new and unique -- we just had to figure out what that would be.

Vector Unit has always made racing games, and we wanted to step back from that just a bit. We decided being able to traverse different terrain types was definitely something we wanted to integrate in our next game. Because we’ve made both land driving and water racing games, we’ve been intrigued by the idea of smashing those two together.

We brainstormed a hybrid driving platformer game where you have to dodge obstacles, and your vehicle would transform depending on the situation. But what exactly is a twitchy driving platformer, anyway? What kind of gameplay would it have? What makes our game different from other games? MouseBot is more experimental than our previous games, so we had fewer things in common with currently existing titles. Super Meat Boy, classic Mario, and especially SkyRoads were great for gameplay inspiration. Because it was being made for mobile, we also looked at more simplistic games like Temple Run and Subway Surfers.

We decided on a mouse running through a maze for the basic theme. We liked the idea of dumb cats dressed in scientist outfits trying to trick this mouse and thought it had a lot of silly, cheesy, pun-filled comedy potential. Having a mouse as a main character led to its own problems, though. Smashing a real mouse would be too brutal of a sight, and not very child-friendly. This is why we decided on a robot. Wall-E and Portal were part of the aesthetic influence for our main character. It also allowed us to be more flexible with the transformation idea we knew we wanted to do from the start. We used a lot of classic cartoons we loved as kids for inspiration, so that's why MouseBot has a bit of an Inspector Gadget feel to his motion.

Early mouse transformation and death concept ideas

We went back and forth on how much transformation and variety we could reasonably author in our short and tight development cycle. The mouse originally had a quick sidestep move, which we ended up taking out to simplify the controls for mobile. Making a platforming game without physical controls like buttons and joysticks is a challenge. There are going to be times where, because you can't actually feel the buttons, you're going to hit the wrong one and die because of it. The fewer buttons on screen, the less opportunity you have to make that mistake. If you can take something out, like the side hop, and no one really misses it, it’s probably safe to do. It all feeds back into simplicity.

Screenshot showing our scrapped sidestep move

The real substance of MouseBot comes from the traps. We asked ourselves, “What kinds of traps would there be? What was important gameplay for each one? What important rules would we need to adhere by?” We first came up with a list of screen placement options, a cross section splitting the screen into 8ths; 2 rows with 4 columns. This was a major part in being able to see and process what's coming up when we started to layer one trap after another. We wanted it to be possible, if you were really good, to navigate a level from start to finish without any unfair surprises. It was also important to determine rules like which traps we should layer behind other traps, and how far apart they needed to be so that you could see both and manage your approach accordingly.

This helped us decide what the traps would actually look like. For example, we knew we wanted something that swept the floor side to side (the bottom 4 quadrants), that eventually turned into a sawblade. The vertical lasers were originally simply concepted to be placed anywhere, to not move or animate, and to block both the bottom and top section of 1/4th of your play area. Each trap has a unique purpose. Once we knew the general guidelines of what we wanted each trap to do, and what column and row it would or could cover, we focused more on what we wanted each one to specifically look like. Gameplay came first and foremost, and visuals came after.

Simple, quick design experiments for what became the Kitty Krusher

Further along the design process, figuring out how the traps lay into the (rough) environment. This involved lots of paintovers and importing the traps into the actual game.

We also knew we wanted a lot of levels (the most recent version of the game has over 75), and we didn't have much time to make them. We got a lot of bang for our buck in previous games like Beach Buggy Blitz by using tiles, or chunks of the environment that can be reused and snapped together. MouseBot is made exclusively out of tiles. This made it really easy and fast to author levels and be able to playtest them immediately.

Examples of MouseBot tiles in our level editor.

Because of the extremely controlled environment and consistency of level building, it was really fun having full control over how we wanted each trap and tile to look. All of the traps have some sort of primary color and usually a dynamic light associated with it. Their silhouettes, colors, and placement on the screen are distinct. You can look down a long hallway and know, yeah, green vertical lasers, red Paw Saws to the left, two Kitty Krushers, wait is that cheese or a mousetrap? Visual consistency and patterns were extremely important so there's a lot less new information your brain has to process all at once. We also turned off distance fogging on the traps, so you can always see every trap down a single hallway. If you have to double take to know what you're looking at, your MouseBot has probably already been stomped.

During production, we ran into a few issues we needed to solve with the trap behavior. It became apparent that we needed some unwritten “tutorial” for each of our traps, to teach the player how to survive each one. It seemed important to ease the player into the different traps. For example, the first time you are presented with a new trap type, it stands alone, has a decent amount of approach time, and is repeated a bit until the player has a chance to understand it. Then we begin to slowly layer in more complicated setups.

We wanted the timing to be consistent on each trap, per level, so the same level was predictable and the timing on all of the traps when you get to them was the same with each playthrough. There was a lot of effort putting timing and delays into the trap animations so we could use them in a variety of different ways and patterns. We discovered that if we started the animation of every trap at the beginning of the level, there were too many variables caused by different driving patterns that would mess up the timing on the next setup of traps. We solved this by breaking up our levels into a series of chunks based on passing through doorways or driving around corners, which worked really well for adding things like checkpoints later in development. In each corner or doorway there is an invisible trigger plane you pass through that starts up the animation on the next section of traps. This way you can respawn in the middle of a level and have all of your traps behave and timed out just as expected.

Both the gameplay and technical boundaries lead into the overall style we developed. Everything had to work hand in hand. Through many iterations, challenges, and hours of playtesting, MouseBot lives!