Team:
Chapin Boyer, Mary Georgescu, Chris Kindred
Design Goals:
Chez Epee was designed for the final project of Studio 1 at the NYU Game Center. Our task was to create a physics game in four weeks. The group settled on the idea of a game about catching food on a fencing sword and cooking it over a grill. Mary and Chris created the art, and Mary created the sound. Mary and I did the programming for the game. I focused primarily on programming and physics tuning.
The core conceit of the game was that the main character would be mouse controlled, with the mouse controlling the sword. The character is essentially a paper doll controlled by physics hinges. We also wanted to try to do multiplayer fencing, as we had access to a script that would let Unity interpret two different mice plugged into the same computer.
Challenges and Solutions:
The first challenge I ran into was integrating the two mouse script. The script only worked for certain brands of mice, so we scrapped the multiplayer pretty much right away, deciding that direct fencing didn’t fit the theme of cooking anyways.
The next challenge was tuning the character itself. We controlled the sword by creating a physics object that followed the mouse and hooked to the sword using a spring joint. I tried to make the character feel as good as possible without using any kind of “cheats” so that it felt intuitive to control. This involved some tuning of the 2D physics settings, and a lot of joint friction tweaking, but still resulted in the player slumping into a lunge more often than not. Also, returning to a standing position from a lunge felt awkward because you had to drag the mouse all the way back.
I solved the control issues by adding a second mouse following object behind the player, and limiting both objects to radii in front of and behind the player. I hooked this second mouse follow object to the player’s front shin. This meant that it held the player up passively, and also dragged the player back to standing without having to pull the sword all the way back. It also felt intuitive enough to not interrupt play.
Skewering food proved to be a bit of a challenge, but we solved the problem by adding slider joints to food when they hit a trigger stuck to the end of the sword. We also checked the movement vector of the food and sword to ensure the food had been stabbed and not simply grazed. When food slid to the hilt it would add a fixed joint and lock in place, and when subsequent food hit locked food it would do the same.
We also found that when we integrated the art for the character on top of the greyboxes, we had to redo some of the physics tuning. This did not present a huge problem, but it taught me to try and integrate as much of the art as possible early on to avoid late stage tuning changes.
The final challenge I tackled was the scoring system. We came up with a kind of esoteric scoring system for the game: Each piece of meat grants the player some points when skewered, and a larger points value when cooked. Peppers, however, multiply the score of the adjacent food. To solve this problem, I registered food to a stack as it got skewered, and then checked to see if any peppers came off the stack. It was a bit of a brute force solution, but it worked perfectly well.