Skip navigation

Category Archives: Requiem

Fall break got over, and we were once again divided up into new teams, and tasked with making another prototype. This time, my team consisted of Skip Fowler (Engineer), Kent Stephens and Ryan Butcher as producers, and Jing Zeng as our artist. This time, we had to use two specific techniques to come with our idea for the prototype. First, we had to a technique known as the design box. This technique uses four walls, each listing attributes related to a specific part of game development. One of the best, and most vague feature of our design box was that the audience had “fun lovers” in it. Anywho, the second technique that we had to use was Jesse Schell’s lenses. We were given 3 lenses at random, and had to pick one to use in out game. We chose the lens of punishment, because the other two lenses we received were highly generic. So, with our lens in hand, and the design box in our heads, we started thinking up a game idea. We had bunch of really nice ideas, and through group voting we came up our final idea, which was First Person Shooter (like Quake) meets Beat Hazard.
Once we decided that this was the idea we were going with, with had to decide on what engine we were going to build it. This time, we had the freedom to choose our engine, and since we didn’t have a lot of idea about them, we decided to go with UDK. Boy was that a mistake. Later that day we talked to Sherly Yunita, our TA in the Game Engineering class, and she told us that UDK is a bad choice for a four week development cycle. And when we told her our game idea, a music based shooter, she told us about Visualizer Studio, a plugin for Unity which analyzes music and gives us a lot of information about it. A couple of days later, we talked to Nikhil Raktale, our other TA, and he too said that UDK is not a good option. Thus, with this expert advice, we switched over to Unity, which Skip didn’t like, and started working on the game. I was tasked with making the movement and interaction scripts for the player as well as the enemies, while Skip worked on getting the music gun to work.
One of the biggest problems we faced with this prototype was that we couldn’t decide how a music gun works. We lost a couple of weeks to this, and in the end me and Skip came up with an idea for the gun, and started working on it. We decided that the bass would affect the rate of fire, treble would affect the damage each bullet did, and the mid frequencies would affect the accuracy. With this plan being developed, we came across our second biggest problem. I had to take about 10 days off, as I was going back to India for my sister’s wedding. This left Skip working alone on the engineering end. But, being as awesome as he is, he managed to to get the gun working, with some changes.
I wasn’t here when we did the final presentation for the game, but it turns out that the map that Kent and Jing were working on, didn’t work at all with the movement controllers I had made. So while the end product wasn’t as good as we had hoped it to be, we still managed to get our idea for the game across. Here is an in game screenshot:
Screenshot with the gun and a Boss enemy.
As you can see, we went from accuracy to cool down. Also, you can see some of the great art that Jing did for the prototype. She chose to go with a cutesy style, and in retrospect, it didn’t really gel well with the map that was made. Also, here is the postmortem we did:
Postmortem for the MusicShooter
Our first playable came very late into development, and a lot of negative things happened, which resulted in a not so good prototype. But, we had a great idea for the game, and were able to build it and iterate on it, while still learning about how to work in a game development studio environment, which a major part of what this class is about.