December 12th, 2011

As the Winter months came upon us I once again, at Metia, had the opportunity to create a Festive game for the UK Microsoft Partner team. Through the success of last years game we were given more time and budget to make sure this years game stepped up a level. Go play the game!

This was the perfect chance for me to use the Farseer Physics Engine. Farseer Physics Engine is a collision detection system with realistic physics responses, it is free to use and runs on the Silverlight platform.

Being a festive game, I went for a Santa theme. The general gist is to move the sleigh, collect the presents and then drop them into the passing houses. Your score is then based on the presents collected, the presents you delivered and the the time you complete the course in.

The game boasts 18 levels, with achievements and special unlock levels. There is a global scoreboard that keeps track of your total score and ranks you accordingly.

Microsoft Partners were given the chance to customise the game. A customised version allows the Partner to add in their company name and logo to the home screen along with their logo featuring at the start and end of each level.

February 7th, 2011

While developing my WP7 game Bitbreaker, I tried and tested several methods to get a reliable game loop running.

What is a game loop

Many games require movement that is affected by constant changing factors. This often requires that movement to be adjusted on a regular basis. In arcade games, for example Bitbreaker, this action is required to happen many times each second. A game loop is the function that fires this repeatable action on a regular basis.

Game loop types

I tried the following types of game loops while developing my Windows Phone App.

Looping a storyboard

Composition Target Rendering

Dispatch Timer

Looping a storyboard

This is a very simple way to create a game loop.

Create a storyboard either in the XAML or in your code behind file.

Set the storyboards duration to the amount of time you want delayed between each action.

Set the storyboard to repeat forever.

Set up a Storyboard.Completed Event handler to fire a function every time your storyboard plays out: Storyboard.Completed += new EventHandler(Storyboard_Completed);

Place your game logic inside the function called on completed.

CompositionTarget.Rendering

This is a good way to ensure your game loop is called every possible chance it can as it matches your games frame rate.

Set the interval value to control the time delay between each action: timer.Interval = TimeSpan.FromMilliseconds(25);

Set up a Tick event handler on our DispatchTimer: timer.Tick += new EventHandler(timer_Tick);

Place your game logic inside the function called on each Tick.

Start the DispatchTimer: timer.Start();

The results

After trying all 3 methods on a Windows Phone, I found the DispatchTimer to be the best suited for my Windows Phone game. So while many people think Windows Phones are more suited for business users and the odd chore like comparing buildings insurance online, these results show that it’s more than suitable for gaming. I needed to get the fastest frame rate but also keep the movement in my game consistent. The dispatch timer achieved this very well.

I found using the looping storyboard approach gave me a low frame rate as it required communicating with the XAML each time, even if there were no visible parts moving.

I use the CompositionTarget.Rendering route often when creating games for the common desktop PC, this is due to it giving a very fast loop. However, when developing for the Windows Phone, we are using a much slower processor and can’t guarantee the frame rate will stay consistent. For Bitbreaker I required the ball to keep a consistent speed, using this approach would make the ball speed up and slow down when asking the game to perform different tasks of varying difficulty.

As this was my first attempt at producing a Mobile app, I knew I was in for some interesting learning curves. Because of this I decided that my first app should be based on the well established bat and ball style game.

Game features

The launch version consists of the following features:

1 free trial level

36 additional levels in the full game

5 power-up blocks that effect game play

6 types of blocks to hit varying in strength

1 bat that deflects the ball lower at the edges

An exponential multiplier point system requiring skill to master

3 tier achievement system for each level

Fast level restart system for people trying to hit those top achievements

Level designs

The level designs range from quirky retro designs honoring the game industries history to complex and tough mazes. The user is required to complete a level before unlocking the next one to play.

Multiplier bonus system

I wanted to encourage players to try and trap the ball in mazes instead of just bashing away brick by brick. To help this I implemented a multiplier point system. Each time the player destroys a block they get an additional multiplier point that multiplies the score you get for destroying the next block. When the ball hits the bat then the multiplier bonus resets back to zero. This means in order to score high points the player needs to trap the ball so that it destroys several blocks before hitting the bat again. Some later complex levels allow the user to score massive points if played correctly

Obstacles overcome

During my progress I had several obstacles present themselves that I had to work around.

The first one, that presented itself early on, was having to code for a mobile processor. Having created Silverlight experiences for desktop PCs over the last 4 years has somewhat spoiled me over the years, meaning I have not had to be too careful about how many times I check values within the XAML. I found with the Windows Phone platform that taking my usual approach to creating a game left me with an unimpressive framerate when testing on the device. I soon learnt my lesson and started storing data in arrays and variables, this meant my app only had to trawl the XAML tree when it absolutely needed to.

The second obstacle was getting my app to load quickly on the test device. I found that my initial approach, running a for loop to create 81 block controls, took nearly 40 seconds to load. Two of the rules set out by Microsoft in order to have your app approved are:

Your app must load within 20 seconds

Upon restarting your app from a tombstone state it must take under 5 seconds to load

I found that asking the app to create and then draw so many controls upfront was a big task. To get around this I placed the controls into the XAML and set their visibility to collapsed so that the app did not have to redraw them until I asked it to later on.

The last problem was associated with the type of game I was creating. As I wanted to include blocks that were solid (could not be destroyed) I had the possibility that the ball could get stuck in an indefinite loop. To get around this I implemented a piece of code that checks to see if the ball has been trapped for a prolonged set of time and then adjust the balls trajectory slightly. This process is then repeated until the ball registers a hit with the bat.

Future updates

I have several plans for updates to Bitbreaker. They include some of the following: