I wanted to make a game that was as fun to lose as it was to win.

The idea for Willy Crash was hatched while I was playing around with the ragdoll physics in Unity. Seeing a ragdoll flop around is fun. I thought up a game idea where a player timed the jump of a skydiver. If the skydiver hit his target the player got a reward. But if he missed the ragdoll would comically fall into various obstacles. The idea got convoluted pretty quickly. I was going to add a second action for the player. Not only would he have to time the jump, they would have to then time the pull of the ripcord. Then I was going to make wind speed a factor…

I talked this idea over with my friend Rob, one of the software engineers at Bay Tek. Through our conversations we simplified the idea. We decided to just shoot the guy out of a cannon toward a row of buildings. If a player landed on top of a building they got a reward. But if they missed the ragdoll would bash into balconies, AC units, and awnings on the way down. It was fun to lose.

The idea was pretty solid, but we had a problem. We needed a special camera system to capture the action. When the game started players needed to be able to see the whole play field. But after the cannon shot the camera needed to zoom in for a close up of the comedy when the ragdoll fell. That was way beyond me. I needed Rob to program a custom camera script, but he was bogged down with other projects. So the idea sat idle for almost a year.

During this period I tried my best to explain the idea to the team at Bay Tek hoping a programmer would be assigned to the project. But 2D renderings didn’t get the point across.

Then Unity released a new camera system called Cinemachine. It automated almost everything I wanted to do with the camera so I wouldn’t need a programmer for that portion of the project. I was able to slap together a prototype game.

The prototype helped me make a lot of the artistic decisions. Though the game takes place in a 3D environment, the game play is essentially 2D. At its core, this was no different than a game where you shot a ball toward slots with dividers. Sure, our ball was a ragdoll, but the concept was the same. I wanted to reinforce this feeling so I made the slot dividers very obvious by making the line of buildings dark and everything in the background pastel tones. Below is a shot from the finished game.

A lot of work went into timing the camera transitions correctly. I wanted a smooth zoom-in effect. If the camera moved too quickly the players might lose a sense of what they were shooting at. So the buildings had to be in view as long as possible. But if the camera moved to slow it would miss the action when the ragdoll crashed into obstacles. It was tough to find a good compromise.

When the prototype game was where I wanted it Rob and Mark (another software engineer) spent some personal time getting the game off my computer and into an actual cabinet that could be evaluated by a larger audience at Bay Tek. We often push games over to our factory where multiple people can play and offer opinions.

Just as the game was finally about to be tested in a real cabinet I had to leave on a business trip. I texted Rob from the airport to see how the test was going. He told me people in the factory were playing the game so much they were getting yelled at to get back to work. This was the point where people thought we might have a hit. The game officially became an actual project.

Rob got assigned to the team and we started dreaming up ways to add more and more goofiness to the game. It was during this period that Rob made an Android version of the game so we could show it to people more easily. That got us thinking. If we’re doing all the work of making an arcade game, why not release an app at the same time?

A team of artists and another programmer from our sister company, Zymo Interactive, were added to the project so we could do app and arcade development at the same time. It took a while to get the project moving again because we had to get both teams on the same page and decide how to divide labor.

At this point we decided to really dive into who the character was. I wanted to pay homage to Evel Knievel, but not create a parody. We decided the character would be a young redneck that has dreams of becoming a famous stunt man. Cody, a great 3D artist at Zymo, was going to take on Willy’s modeling and animation. I asked him to create a look that was a cross between a superhero and a country music star.

Here is a version of Cody’s model that I painted over to create one of the game over illustrations. I tried to walk the line between comedy and violence. After Willy crashed players would see that he was pretty banged up, but still in good spirits and always ready to try again.

The game went out to test locations and initially did well. Then we added a bunch of instructions and highlight reels and other stuff to the attract sequence and performance started to suffer. We started to have doubts about the project, but we decided to go back to the simple attract sequence from the prototype game. That did it. Simple is better. Performance stabilized and it was full steam ahead from there.

Part of the fun in creating this game was hiding a ton of Bay Tek jokes into the content. Several of the background buildings and obstacles feature Bay Tek employees, past game titles, or real businesses in Pulaski, WI. Here are some shots from inside the editor.

Here is the final game cabinet.