A Little Bit About Blitz

Happy New Years everybody!  I know it's been a little quite around here lately due to the holidays and what not, but I think things are going to be picking back up as we move into the new year.  ColorGuess Plus is live on the App Store so if you don't already have it, you should really go get it.  For this post I'm going to talk a little bit about the development process of the Blitz Game Mode.

Thinking back to the development I would say blitz mode was relatively simple.  We didn't run into any major issues like we did with the challenge mode (which you can read about over in Austin's Blog).  However, blitz mode did bring up the new concept of different game modes, which proved to be a bit of a challenge.  The overall mechanics were pretty simple, just start the timer backwards from ten and when you get to zero, check the score and start a new game, making sure to keep track of how many games have been played.  There were a few minor things we needed stack overflow for, like figuring out how to change screens with out any user interaction.  The main challenge with blitz mode was keeping track of the different game modes.

From our early development days of the original ColorGuess! we knew that transferring a variable from one screen to another took a few extra steps.  Since we had already worked that out previously it was relatively simple to have the player select a game mode in one screen, and carry that through the entire game.  One of the major problems, though, was how and where exactly in the code to implement the different rules each game mode created.  For example, the blitz game needed to start the decrement timer and the initial time needed to be ten seconds while the standard game needed to start the incrementing timer at zero seconds.  At first the check was performed when ever a slider was moved, however this caused the timer to stop when ever a slider was being moved.  We ended up putting the check in the start timer method, which also had an initial check of weather or not a timer was already running.  There were a couple of other places we had to put in checks for the game mode but once we got those in the right places blitz mode came together quite nicely.

Overall, a lot of these minor game mode changes came around because we wanted to keep one play view with one controller.  We could have just made copies of the play view and made new controllers for each one, but that was obviously wasteful.  I think blitz mode taught us a little bit about keeping things simple and lean.

- Matt.

First

So. . .most of the introductory stuff that I might put in a first blog post is already over on the info page.  All my interests and what I do and what I'm going to blog about are all over there.  With that out of the way, let's dive in.

I figured I'd start off with the development progress I've made towards the new game we are working on.  If you don't know, the game is basically going to be a tower defense game with two kinds of game play.  The player will be able to build towers with upgrade paths and all the usual tower defense game stuff, but in addition to that, you'll be able to change to the point of view of a tower and shoot the on coming enemies one at a time, man to man, sort of like a 1st person shooter tower defense game.  The player takes control of a tower by holding the device in a portrait orientation and when they do, they are able to scan the horizon by sweeping the device from left to right, almost like taking a panoramic picture.  Except instead of taking a picture you're looking for enemies to kill.

My job was to basically do that.  Access the gyro readings from the phone and make them move the background.  At first I thought this was going to be a kind of daunting task because the gyro values would have to be integrated to get the position and nobody likes integration.  But upon further research I found that in the CoreMotion framework there is already attitude values, yay!  What that means is that Apple has already done the hard part for you and integrated the three gyros to give you a position vector in three space defined by  roll, pitch, and yaw values in radians.  For the purposes of sweeping the background all I was interested in were the yaw values.  So with a little (a lot) of help from stack overflow I built a gyro object which would give the yaw values at a variable time interval.  Then, after realizing that the values were pretty noisy I put in a low pass filter to help smooth out the readings.  Now it was time to go back to Cocos2D.

The last part of this was pretty simple.  I had an angle value of how far off center I was.  So then I assumed that the background was going to sweep a total of say 90 degrees.  Then, knowing the total horizontal pixels in the background image I could divide by 90 and get a pixel per degree scalar.  Then I just had to multiply by the angle given by the gyro and poof, I had a number of pixels to move my image to.  Then there was some fiddling with coordinate systems and switching some signs but in the end I got it all working pretty well. 

There are some minor issues that may need to get worked out later on down the road but for now I'm happy with what I've got.  The next step now is to paste the enemies and the background in one layer so that when you sweep the device you not only change the background position but also the enemies lateral position so that it's in the view of the screen.  I want to talk to Austin about how that's going to happen since it has a large impact on how the rest of the game is going to be coded. 

So yeah.  That's my first blog post.  Longer than I was expecting and a lot of words.  I'll try to keep things more interesting with pictures and videos and stuff.  I hope this gave you and idea of the game we're working on and what kind of progress we've made so far.  My next post will probably be about the quadcopter.  That one will probably be kind of mathy as well, but I'll try and add a video to keep it interesting.  

Thanks for reading! 

-Matt.