Skip navigation

Category Archives: Prototypes

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.

Remember the part about using Unity because it supports both Flash and Web Development? Well throw that out of the window because Unity only supported flash in its older versions, and that too only with a license. And the beautiful part is that buying the license gives access only to the latest version of it, which has no Flash support. And, games developed with Unty for “Web Development” use Unity Web Player, and not HTML5 as we had hoped. So, it turns out that we can’t use Unity now, and all the work that we had put in in making the prototype is simply useless now. Also, did I mention the fact we have only three weeks for this prototype instead of four? And now that our first week’s work is useless we have only two weeks left to make a game from scratch, and in a language that I’m not familiar with.
After these developments, I spent the rest of the day thinking about how I am going to make this work. Then one of my friends told me about Construct 2, an editor made specifically to make games in HTML5. I checked it out, and in 3 hours I had a prototype ready which did everything that the Unity prototype did by Tuesday (1st October). This result was partly fueled by what my producer Matt said: “If you get the prototype working again by Thursday(3rd October), I will come to the class dressed as a pirate.” Needless to say, I was not going to miss this opportunity. So I have Bounty Blast (The name of our game), up and running here. Let me know how it is! And yeah, that’s Matt in the center.

After the completion of the first prototype, we were divided into new teams, with my team comprising of Matt Jensen and Antonio Revard (Producers), Cory Haltinner (Artist) and Jinzhi Zhang (Fellow engineer). This time, instead of making a game for our “clients”, we were asked to take an old arcade game (late 70’s to early 80’s), and put a new twist on it. Our team decided to go for the classic Asteroids game. The twist we decided on was based on the theme we chose for our prototype. Instead of a spaceship, the player now controls a pirate ship. This led to an overhaul in the movement and firing mechanics. The pirate ship can’t go in reverse, has a large turning radius, and shooting can happen only from the sides, instead of the front. We also decided that rather than giving a fixed playing area that was visible the entire time, the playable area would be larger. Also, the ship would not wrap around the playing area, i.e. when you reach the left side of the area, you won’t automatically reapper on the right side. With this base idea in mind, we went ahead with our game.

Another condition of this prototype was that we had make it in Flash or HTML5. We decided to make it using Unity3D, as it supports both Flash and Web Development. Also, our producer Antonio is experienced in Unity, making the job of engineers easier. Starting off with Unity seems promising, and coupled with the great idea that we have, I’m sure we’ll have a fun prototype by end of this project!

First thing: the fact that I am writing a post-mortem doesn’t mean that the “Starving Artist” game is dead. This is an analysis of what happened in the development process, both good and bad, and how it will help me in my future projects. Below is an image of our analysis: Starving Artist Postmortem

As you can see, a lot good stuff happened (everything above the timeline), while all the bad stuff (everything below the timeline) happened either because of unfamiliarity with MOAI, or because we didn’t prioritize the right things. The former can’t really be helped, as every new platform is unfamiliar in the beginning. However, recognizing the priority issue will definetly help me in the projects to come.

One particular problem I faced during the development of this game was getting the animations to work. The game logic worked beautifully, but that wasn’t really visible to the player, as without animations the game looked…confusing. It was after I had spent 3 days trying everything that I realised that it was the way I had made the game, using a single “prop” to show and manipulate all the paintballs, rather than a seperate “prop” for each paintball, which caused it nearly impossible to have it way animate the I way I wanted it. That and the strange rules MOAI has for re-drawing the screen were the reasons I couldn’t get the animations to work. I could have redone the whole game to get the animations to work, but we had run out of time by then. But fear not, because the Starving Artist has decided that we would love to see the game completed and available for play on smartphones in the near future! Thus, I will continue working on the game and will keep posting my updates here. Ooh and before signing off, here is Starving Artist

Alright, this is gonna be a long one. These last two weeks, our game idea went from an idea to a work in progress, which as I learned the hard way, involves MANY changes. The UI in my last post, which everyone liked, was changed 3 times, the core gameplay changed twice, and even now one feature which is needed to understand the working of the game doesn’t really work. We went from having four colors to six, simple swapping to swapping and mixing, to sliders on top and bottom to finally just slide everything. The UI changed accordingly with each change in the mechanic, but our artist did a terrific job each time. The “final” prototype is a mix of Bejeweled (get four or more of the same color in the same row or coloumn) and Rubik’s Cube (think before sliding). One of the producer’s, Owen, did some awesome sounds and music for the game, which really go well the whole “Starving Artist” theme of the game.

Getting to internal working of the game, we had to make it on MOAI, a platform specifically made for making games for iOS and Android. Using it was quite a task, as I had no experience in MOAI or the scripting language it uses, Lua. The first week went by in just learning how to use it, and writing simple code. Then when I got the hang of it, I started working on the actual game. Getting the mechanics to work (the first time) took about a week, during which my knowledge of MOAI also grew. Then came the day when a man (who-shall-not-be-named-but-you-know-who-you-are) gave us some great feedback on our game, but also ended up completely changing the core gameplay mechanic. So that simply resulted in me starting over on the mechanic, while our other engineer and artist had to redo the whole UI. And we also added the powerup system (which was written from scratch in one day). All in all, it was a good experience, as I got to know how drastically things can change in the prototyping stage, and I ot experience in MOAI and Lua.

As for the one feature that isn’t working, the movement of the balls isn’t animated. As soon as the player makes a move, the balls instantly appear at their new location. This can cause problems with people who aren’t familiar with the game not really understanding what is going on, but I hope to fix atleast part of the problem before the final pitch. Before I leave you, here are a couple of screenshots of what the game looks like now:

Initial game.

Looks…sketchy

 

MAXIMUM POWER!

MAXIMUM POWER!

Hey everybody! This is the first of many posts (atleast 100) that’ll be here documenting my journey in the EAE program at University of Utah (as if you couldn’t tell that from the URL). But with the formal introduction out of the way, we can get down what this blog really is about. I’m a computer engineer, which means I get to write the stuff thats related to the stuff that makes pretty much everything today. Specifically, being part of the EAE program, I’ll be doing the code behind fun (hopefully) and interesting (again – hopefully) video games.

As part of one of my first assignments, I’m a part of a 5 member team (Travis Turner, Owen Peterson, Joe Rozek, Peijun Zhou and yours truly) working on a mobile game, titled “Starving Artist”. It’s a match-3 puzzle game in the vein of Bejeweled and more recently, Candy Crush, but with an interesting theme and some new game play features that aren’t famous in this genre. You can see some of the concept art below, and I’ll update our progress here regularly.

concept_game_inplay concept_power_full_with-_powers

 

 

 

PS: A bit about the part about being regular: I was supposed to have this post up at the end last week, but as you can see, I got a bit “delayed”. I’ll make sure this was the first and last delay, but please don’t kill me if I miss a date 😛