The game is based on the XNA sample game “Catapult Wars Lab”. We’ll reuse the assets from that game as we develop a new version for Windows 8 that’s based on web technologies.
The Game Loop
The heartbeat of any game is the game loop. It’s a function that runs many times per second and has two primary jobs – update what’s going on then draw the new scene.
In Part 2, we already put the outline in place:
Now the question is, how do we get the
gameLoop() function started, and keep it running many times per second?
EaselJS Ticker Class
Fortunately, EaselJS has a Ticker class that has some features we’ll use:
- Manage the timing of the game loop
- Pause/resume the game loop
- Measure elapsed time
It’s a static class, so we can just start using it. In
default.js, add a new
startGame() function and call it at the end of
Here we’re telling Ticker to use
window.requestAnimationFrame to control how frequently the gameLoop function is called.
requestAnimationFrame is a relatively new API for web applications that helps ensure work isn’t being done unnecessarily. To understand why this can be better than setting a fixed timer (e.g. with
setTimeout()), see the requestAnimationFrame sample on the IE Test Drive site.
Every time the
requestAnimationFrame is ready, our game loop will run.
“Ready, Aim, Fire!”
Okay, now we have a game with a running game loop, so it’s time to add some fun!
Each player/catapult is going to be firing the ammo/rock toward the other. We need to know if a shot is currently flying, who’s turn it is, and how the shot is moving.
First, let’s add more variables to
Now let’s use some of them by adding the following to the
For now, both players automatically fire (at a random velocity) on their turns. The
ammoBitmap is moved to the top center of the firing catapult, and
shotVelocity is given a random value within a bounded range (adjusted for screen resolution.)
We’ll also add a
fireShot() function to show the shot and tell the game it’s in the air:
Updating the Display
Before we move the shot through the air, let’s focus on the 2nd half of the game loop equation – drawing to the screen. This can often be very complex, but EaselJS Stage takes care of drawing our content (all of the children – Bitmaps, Text, etc. – we added to Stage) to the canvas, so this is all we need:
That’s it! If you run the game, player 1 will automatically fire and the shot will appear over the red catapult…
… but it won’t budge. Let’s get things moving.
Moving the Shot
Let’s return to the
update() function and add logic to the
if (shotIsFlying) statement:
Don’t run it yet, we still need two functions, but here’s what’s going on:
- Lines 149 & 150 – Move the shot by adding velocity (which may be negative to go up and/or left)
- Line 151 – Apply gravity to slow velocity
- Lines 153-155 – Has the shot hit the ground or gone of the left or right edge of the screen?
- Lines 157-160 – Missed – end the shot and change players
- Lines 162-168 – Player 1’s shot – see if it hit player 2. If so, update player 2’s lives.
- Lines 169-175 – Player 2’s shot – see if it hit player 1. If so, update player 1’s lives.
Let’s add the
What’s that talk of hitTest? EaselJS DisplayObjects (on which
Bitmap is based) supports a
hitTest() method, which makes it very easy to see if a point is over the current object’s position. Unfortunately, we’re scaling objects and hitTest only works with the original sizes, so we’ll need to check for hits ourselves. Just a bit of math and we’re set.
Now, add the processHit() function:
This simply ends the shot, changes players, and makes sure the game isn’t over.
Ending the Game
Let’s end this post by ending the game. Add the
That’s it! Now you can run the game and see who wins.
We’ve added a lot in this part – things are drawing, moving, hitting, ending… but there are two gaping holes. First, the player doesn’t actually play, so we’ll add input processing next. Second, things are awfully quiet, especially for a war, so we’ll toss in some sounds as well.
On to part 4: next week!
Chris Bowen is a Principal Technical Evangelist with Microsoft, based in the Boston area and specializing in Windows 8 development. An architect and developer with over 19 years in the industry, he joined Microsoft after holding senior technical positions at companies including Monster.com, VistaPrint, and Staples. He is coauthor of two books (with Addison-Wesley and WROX) and holds an M.S. in Computer Science and a B.S. in Management Information Systems, both from Worcester Polytechnic Institute.