Skip navigation

Monthly Archives: December 2013

The fourth and final prototype for this semester. This prototype consisted of hard work, long discussions, and a bunch of -interesting- interactions. For the final prototype, we were allowed to make our own teams, which resulted in people running ll over the lab to grab the people they wanted to work with. This happened when I was in India, and by the time I got to know about it, I feared it might be too late and that I would be left without a team. As it turns out, there were atleast two teams that wanted to me (which feels awesome), and eventually I was in a team of six people consisting of me, Skip Fowler (again) and Siyuan “Shelwin” Cheng as engineers, Joe Rozek (again) and Rachel Leiker as artists, and Tina Kailnger as the producer. As you can see, I was working again with a couple of former teammates, and it felt great knowing that they wanted to work with me a second time.
This time around, we had to develop a game, that will be published on the Windows 8 app store, so yeah it was kind of a big deal. We had a talk with Randy Guthrie, a tech evangelist from Microsoft, who told us a lot about how the App store works, and what type of games are succesful. With this knowledge, we came up with our game, called Freeze back then. It was a game where you had to protect your cabin in the mountains from evil winter creatures. The cabin was in the bottom right corner, and the enemies would walk in from the left side, and both the players and the enemies could shoot at each other. After the team meeting, we had an engineers only meeting that lasted about 1.5 to 2 hours long, where we decided to make in the game in C++ and DirectX, instead of using an engine like Unity or Gamemaker. The fact that we were using C++ turned a bunch of heads, with Randy commenting that we were brave to try that. Shelwin had some doubts about this, as he felt that using an engine like Cocos2D would be easier and quicker than coding in C++, but we managed to convince him that we could get this to work. After that, we wrote up everything that we would need from the engineering side, shown below:
Stuff needed for the Game
We divided the work into 3 seperate tasks, consisting of DirectX and Rendering, the C++ Classes that will be used, and the Game Loop itself.
Who will do what
I got the task of making the classes, which was amazing. I used all things we had learned in our Game Engineering class to make them, and I have to say that using all the Game Engineering stuff was the best decision I made. One of the best moments for me came when we added the classes to the game loop code, and they worked almost flawlessly. This was great for me because I had forgotten to test them, and seeing them work on the first try is just awesome.
We continued working on the game, adding and tweaking features, when in the third week we had a talk with Tobiah Marx, the guy who made Blast Monkeys. He played the game we had till then, which was simply swipe right to win. This made us realize that what we had was not fun, and had us rethink the game. We came with three different ideas for the engineers to work on, and this was where the decision to choose C++ proved right. Even though we were each doing different iterations, we didn’t need to remake the game from the ground up, as the classes worked perfectly in all three cases. We also knew everything about our code, which made it very easy for us to change it as needed. After working on the new iterations for a day, Tina told us that she had come up with a new idea, and having discussed it with Tobiah and getting a positive response, she shared it with us. Instead of shooting enemies to kill, the idea was to swipe across them, connecting them in big chains to score more points. Here is the concept art for it which Tina drew:

As you can see, the art  is amazing :P

As you can see, the art is amazing :P

The entire team liked this idea, and we decided to work on this. Once again, C++ helped us, as even though the core gameplay changed, the classes remained useful, with us only having to remove code from them to make them work without problems. We added a bunch of features to help the player see the combos that they set up, added all the amazing art in the game and had a fun game ready by 12th December. The name of the game also changed from Freeze to Snow Place Like Home, because there was already a game called Freeze. Here is the post mortem for this prototype:
Snow Place Like Home
No matter how great the team was, no development cycle is free of problems. Most of our problem was the huge loss of development time throughout the 4 weeks, with some minor technical issues, and one huge issue as well. At 5 PM on 11th December, our game simply broke. One of the engineers did a bad commit to the SVN which had the latest working version of the game, and that made the game unplayable. I was up till 1 AM fixing it, and got a playable version ready for the presentation the next day. C++ once again helped us, as I never had to think “Why is this code breaking the game?”, instead, I only thought “Why did he write this code?”. I was able to find the problems quickly, it was just the task of fixing them that took some time.
After the presentation, there was EAE Open House that evening, where we showed all our Windows 8 games, as well as some past prototypes, including Bounty Blast. The Open House was a huge success, and I met a lot of interesting people, some who were interested in the program, some who were already making games on the side, and some who just playing our games. Kids liked playing Snow Place Like Home, and pretty much everyone we talked to was impressed that all the prototypes were done within 4 weeks. After the Open House, we had till 17th December to submit the game on the Windows 8 App Store. We fixed some more issues in the game over the weekend, and submitted the game on the 17th. Another plus of using C++? Our game size is about 7MB, including all art and animations. Compare this with a sub-100MB “hope” for some other teams that used Unity. Here is the start screen for the game:
Snow Place Like Home
As of 18th December, it has passed certification, and will be soon available for download on all Windows 8 devices. Check back here for the download link and an awesome cheat for the game soon!

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.

So, work on the Bounty Blast prototype ended on 10th October. This prototype had a bunch of ups and downs, from getting an awesome working uild in Unity, to being told that we can’t use Unity, and with only a week left, finding the gem known as Construct 2 and getting another solid working build in a week. Yeah, this prototype taught how things can drastically and suddenly change in development, and how we have to work with changing requirements, while still meeting a deadline. It also taught me that without proper communication, the concept of a team falls flat. To give you an idea of what happened in these 3 weeks, here is a post mortem we did:
Bounty Blast Post Mortem

As you can see, the first thing we were happy about was that we didn’t have to use MOAI. IN our previous prototype we had no option but MOAI, and every single engineer hated using that. Then, after we had a solid game idea, we got a working Unity build, and after spending two weeks on it, we were told that unity can’t be used. This happened on Roger’s birthday, and I remember the lunch that day, our entire team was there, but we were in complete silence. Then my friend Binoy told me about Construct 2, and how quick and easy it is to use. I had the new build ready in about 2-3 hours (though Matt thinks I was up all-night :P), and spent the morning of Wednesday just making tiny changes to make sure the Matt shows up in his pirate costume the next day. One of the big negatives that happened was communication. Our team as a whole couldn’t commuincate properly with my fellow engineer, Jinzhi “George” Zhang. This resulted in me doing pretty much all the engineering work (not that I’m complaining), but it would have been better if we could have actually worked together. Well, lesson learned for the future! Thats it for now, thanks for reading, and be sure to play Bounty Blast here.