Chapter 13
Ten Game Starters
In This Chapter
Learning to build various game types
Storing high scores on the browser
Building tile-based worlds
Creating simple artificial intelligence algorithms
Writing a lot of games!
For the final chapter, take a look at a number of different games that can be built with the skills learned throughout the book. Each of the games featured below is a “starter” game. I illustrate some key ideas and sometimes introduce a new concept or two. None of the games is completely finished: I deliberately left the graphics simplistic, and left out many details like audio, scorekeeping, and multiplayer functionality.
For each program, I illustrate the basic type of game I’m trying to produce, point out a few key technologies or ideas, and give you some suggestions on how to build your own game from this starting package.
Note that I’m not printing out every code listing in this chapter. Instead, I encourage you to play around with each game on my website, (www.aharris books.net) look at the code yourself, download it, and modify it as much as you wish.
I reproduce code snippets that illustrate a particular idea from a code example when that makes sense.
In this chapter, I also am including GIMP images in .xcf format so you can see my original images and change them as you wish.
Lunar Lander
This is one of the oldest game types. The basic idea is to replicate landing on a planet without an atmosphere. The Apollo astronauts had a limited amount of fuel to slow a rapidly moving spacecraft and bring it to the surface safely. This game, shown in Figure 13-1, is a variation of that theme.
The essence of a lunar-lander game is the interplay between thrust and gravity. The game relies heavily on the addVector() method described throughout Chapter 8. Gravity imparts a small downward thrust every frame, which can be counteracted by thrust from the arrow keys.
The game features four different lander images (to provide feedback that the user is applying thrust), which are simply swapped with the setImage() method as needed.
Figure 13-1: Land the spacecraft on the platform.
The eagle has landed
The most interesting part of this game is the landing routine. The ordinary collision routine is not specific enough to handle this type of collision, as the landing will be considered a safe landing only if a number of conditions are true. The cleanest way to check for multiple conditions is in a deeply nested if structure, like the following:
tLander.checkLanding = function(){
if (this.falling){
if (this.y > 525){
if (this.x < platform.x + 10){
if (this.x > platform.x - 10){
if (this.dx < .2){
if (this.dx > -.2){
if (this.dy < 2){
this.setSpeed(0);
this.falling = false;
message = “Nice Landing!”;
} else {
message = “too much vertical speed”;
} // end if
} else {
message = “too fast to left”;
} // end if
} else {
message = “too fast to right”;
} // end if
} // end ‘x too big’ if
} // end ‘x too small’ if
} // end ‘y not big enough’ if
} // end ‘are we falling?’ if
} // end checkLanding
When you’re checking for several conditions at once, it’s best to create a separate if statement for each. Place each if statement inside the next, so the most deeply nested part of the code represents success.
1. Determine if you’re falling.
I created a Boolean variable called falling that describes whether the spacecraft is falling or landed. If falling is true, the gravity force is turned off. It only makes sense to check for a landing state if you’re currently falling.
2. Check the Y value.
Because the platform is placed at a Y value of 550, the lander will appear to be landed when its Y value is larger than 525. I’m really only concerned with the bottom of the lander touching the top of the platform. Note that this check happens inside the falling check. If any condition fails, it is not necessary to check the others.
3. Check the X value.
I want the center of the lander to be within ten pixels of the center of the platform, so use a pair of nested if statements to check the X locations.
4. Check horizontal speed.
For a safe landing, the craft must have a dx value between -0.2 and 0.2. (This is somewhat arbitrary, but upon testing, it feels about right.) This is best checked with a pair of nested if statements.
5. Check vertical speed.
If everything else is working well, check to see that the craft is not falling too rapidly. Use the dy property to determine how quickly the spacecraft is falling.
6. Provide feedback with else clauses.
A deeply nested structure like this shows you the real value of proper indentation and commenting. Provide feedback in the various else clauses to explain why the landing was considered a failure. (Notice I didn’t provide feedback when the lander is too far from the platform because this state happens during most of the gameplay.)
Producing a text console
Another interesting part of the code is the mechanism for displaying text data to the user. The easiest way to do this is through a simple HTML div. Use CSS to place the div exactly where you want it to be. While I rarely use absolute positioning in normal web development, it makes sense in the context of creating a label for a game. Note that you might need to set the z-index property to a high value to ensure it appears above the canvas, or it may not be visible to the user. Here’s the CSS that makes my label look like output on the screen:
#stats {
position: absolute;
font-family: monospace;
left: 50px;
top: 50px;
z-index: 999;
color: white;
}
Enhancing the game
This is just a starting point for the game. Many other interesting features could be added:
Fuel: Add a fuel variable that is decremented each time the user applies thrust. Vertical thrust should use more fuel than horizontal adjustments. If the fuel level gets below zero, ignore further thrust inputs. This mechanism puts a realistic complication into the game.
Powerups: Add some other features the user can earn: bonus fuel, less intense gravity, a wider platform.
Multiple landings: Maybe move the landing pad after a successful landing, or have the user carry an object to a second platform.
Obstacles: Put space junk or buildings in the way that will crash the player on contact.
Change the theme: The same mechanics can easily be used for a helicopter or hot air balloon game.
Mail Pilot
This is an example of a scrolling racer game. This type of game has long been a staple of the video game universe because there can be so many interesting variations. In this particular iteration, you’re a pilot flying a plane over an island archipelago. Your job is to fly over the islands and avoid the clouds. The game features user control of the airplane’s X position and an endlessly scrolling world.
Figure 13-2 shows this game in action.
The approach to this game is quite similar to all games in the book:
Identify the key variables: In this game, the main variables are the airplane, the islands, and the clouds. All are implemented sprite objects.
Create each object in isolation: As I did with the frog game first introduced in Chapter 7, identify what each object should do and implement those basic features.
Figure 13-2: Fly over the islands and avoid the clouds.
Build a single element; then convert it to an array: The clouds object is really an array. It’s very common to have arrays of objects. The key is to build a single element first that does what you want and then convert that object to an array. Typically, when you do so, you’ll build two custom functions. The first function creates the array and uses a for loop to initialize each object in the array. The second function also has a for loop that steps through each object, invoking any of its event functions and updating each object on the screen.
Manage interactions: Most of the interesting things that happen in an arcade game occur when objects collide, so collision routines are an important part of game development.
Building an “endless” background
One interesting feature of this game is the endless tiled background. The user avatar doesn’t move forward at all. Instead, the illusion of motion comes from having a background that moves down perpetually, making it look like the plane is moving up.
Of course, it’s impossible to create a truly endless background, but you can do a couple of tricks to produce a believable illusion:
1. Build a sprite for the background.
The easiest way to get the moving background behavior is to simply make the background a very large sprite.
2. Create an image larger than the scene.
As this particular graphic is meant to tile vertically, I make it the width of the scene (800px) but much taller than the scene (1440px tall for a 600px tall scene). Larger sizes lead to less-obvious repetition but will be more resource-intensive. If you want horizontal scrolling, make your image larger on the X axis than the scene.
3. Duplicate the top and the bottom.
The key to an “endless” scrolling effect is to have the top and bottom (or left and right of a horizontal image) identical to each other. Use the copy and paste tool of your graphics package with the Clone and Smudge tools to get this effect.
4. Overwrite the checkBounds function.
The background sprite will need custom boundary behavior, so overwrite the sprite’s checkBounds method.
5. Check to be sure the background never leaves the screen.
In the Mail Pilot example, the sprite starts far above the scene and moves downward. With some testing (and the console.log() command), I was able to determine that my background begins to leave the scene at a Y value of 720. Use an if statement to check for when that happens.
6. Move the background so the identical section is showing.
The top and bottom of my ocean gif are the same, so when the ocean is about to leave the scene, the user is seeing the top of the large ocean gif. Change the Y value so the user is now seeing the identical bottom of the same .GIF, and keep it moving. You may need to use console.log() and some testing to get it to work exactly like you want.
Here’s the code for the checkBounds() method so you can see it in action. Note that you’ll have to change the specific values to match your image size.
tOcean.checkBounds = function(){
//seamless ocean gif repeats
if (this.y > 720){
this.setPosition(400, -120)
} // end if
} // end checkBounds
Improving the top-down racer
This type of game is very popular because it’s easy to write and can be modified in a number of simple ways to get many different types of games. Here are a few suggestions:
Add a scoring mechanism. The most obvious improvement is to add some sort of scoring system. Award points for touching the islands and take away life for touching clouds.
Build up the difficulty level. Consider adding more clouds, changing the size of the various elements, or changing the speed.
Add powerups. Powerups are simple sprites that provide some sort of benefit or disadvantage when they’re activated (usually by shooting or running over the powerup). The options are nearly limitless but here are a few starter ideas: Temporarily allow vertical as well as horizontal motion, change the speed, and make the plane larger or smaller.
Change the motion. Right now, the plane moves only on the horizontal axis. Allowing motion on the vertical axis as well will dramatically change the gameplay.
Add weapons. Add bullets for an interesting twist. If you want a lot of bullets, you’ll need to create an array.
Switch to horizontal scrolling. You can switch to horizontal scrolling quite easily. You can also allow scrolling in either axis, but you’ll have to really think through the boundary-checking aspects.
The Marble-Rolling Game
This game is designed specifically for mobile devices with an accelerometer (although it works on a desktop). The idea is to tip the device to move a ball into the blue goal without hitting any of the blocks. Every time the user achieves the goal, the game is redrawn with an additional block, making the game harder and harder. The game is shown in Figure 13-3.
Managing dual input
Perhaps the most interesting part of this game is its novel input mechanism. It feels very natural to tilt the screen for ball motion. Check Chapter 9 for details on using the accelerometer to get tilt input. The essential plan is this:
1. Create an Accel object.
Turn on the accelerometer by creating an instance of the Accel object.
2. Build a checkAccel() method.
I added a method to the Ball object that checks the accelerometer.
3. Get the accelerometer rotation.
Use the getAX() and getAY() methods to find the amount of rotation around these axes.
4. Convert rotation to dx and dy values.
Use the mechanisms described in Chapter 9 to convert rotation to appropriate motion values.
5. Add an optional keyboard input.
It’s much easier to debug a program on a desktop than on a mobile device, so often I’ll add an alternate input option so I can test as much of the program as possible before moving to the mobile platform. Use the Scene class’s touchable property to determine whether you’re using a mobile device. This approach also makes the game playable for a wider array of users.
Figure 13-3: Tilt the device to roll the ball.
Here’s the code (in the main update() function) for checking which type of input is available:
//get input from accelerometer or keyboard
if (game.touchable){
ball.checkAccel();
} else {
ball.checkKeys();
}
And here’s the checkAccel() method of the Ball object:
tBall.checkAccel = function(){
//use the accelerometer to get input
newDX = accel.getAY();
newDY = accel.getAX();
newDX *= -5;
newDY *= -5;
ball.setDX(newDX);
ball.setDY(newDY);
} // end checkAccel
Building an array of obstacles
Another interesting feature of this game is the ever-increasing level of difficulty. Getting the difficulty level of a game correct is very challenging. You want the game to be beatable, but beating the game needs to feel like an accomplishment. One way to achieve this goal is to begin with a very easy level of difficulty and then ramp up until the game becomes more difficult.
For the marble game, I use an array of blocks as the obstacle. When the game begins, there are only ten blocks on the screen, so it’s quite easy to get to the target without hitting any blocks. Each time the player reaches the target, the game scene is redrawn with one more block.
The blocks and the goal are drawn at random positions on the screen. However, you need to be careful not to create an impossible situation. The Block object’s reset() method tries to place a block at a random position on the screen. However, if the block collides with the goal, the game will be difficult to win. Likewise, if the block collides with the ball’s current position, the player will immediately lose. If either of these conditions occurs, the block is redrawn until a legal position is available.
I allowed blocks to overlap each other freely, but you could add this constraint as well. Here’s the block resetting routine:
tBlock.reset = function(){
//don’t let me overlap the goal or ball
keepGoing = true;
while(keepGoing){
newX = Math.random() * this.cWidth;
newY = Math.random() * this.cHeight;
this.setPosition(newX, newY);
keepGoing = false;
if (this.collidesWith(goal)){
keepGoing = true;
} // end if
if (this.distanceTo(ball)< 150){
keepGoing = true;
} // end if
} // end while loop
} // end reset
Improving the marble game
The marble game is quite playable as it is, but any game can be improved. Here are a few suggestions:
Add a time limit. Require the user to reach the target at a specified time.
Add new kinds of barriers. Barriers of different sizes will change the gameplay.
Change the ball’s boundary action. In my version of the game, the ball wraps around the screen. This adds an additional tactical element to the game, but you may prefer to stop at the border.
Add powerups. You can always add special elements that temporarily change gameplay. Maybe consider making the ball invincible for a few seconds, or inverting gravity (multiply dx and dy both by -1). You could also temporarily change the size of the ball or have a powerup that resets the current level.
Create moving blocks. The game entirely changes if the blocks also move. You’ll probably want them to move very slowly in a random direction because this feature could make the game much harder.
Make cosmetic improvements. Of course, you can always add sound effects, a high score mechanism, and improved graphics.
Whack-a-Mole
The whack-a-mole genre re-creates a classic physical arcade game. In the original game, you have a series of holes and a big hammer. As a mole pops out of a hole, the user smacks it with a hammer, and it goes back into the hole. This game is easy to re-create for both mobile and traditional desktops, and it can be frantic fun. Figure 13-4 shows this game in action.
My version creates a number of moles in random positions. Each mole has two states: up and down. The mole starts in the down state. A mole in the down state has a random chance of popping up in any frame. A mole that is currently up stays up for a limited time. If the user clicks a mole in the UP state, the mole drops and the player earns a point. If the mole stays up past a time limit, the mole drops, and the player loses a life.
Building a mole in a hole game
The main concept of this game is the mole. It’s a simple Sprite object with two states. Everything the mole does is really about changing states.
The mole has a few properties that separate it from a normal sprite:
state: The most important property of the mole is state. This can be either UP or DOWN. Various game behaviors cause the state to change.
UP and DOWN: These values are treated like constants, and they are used to indicate the two possible states of the mole.
imgUp and imgDown: These are the images representing the two states. Obviously, I created ridiculously simplistic images for the states. Note that both state images should be the same size, or the sprite will appear to jump around the screen when it changes state.
popupPerc: This property indicates the likelihood a mole that’s currently down will pop up. The initial value is 1 percent. Remember this value will be checked 20 times per frame, so at 1 percent, a down mole will pop up (on average) every 5 seconds. Modify this value to change the game difficulty (larger numbers will cause moles to pop up more frequently).
popupLength: This property indicates how long a mole will stay visible once it has popped up. The default value is 3 seconds, but you can adjust this to make the moles disappear more quickly or stay visible longer.
Figure 13-4: Whack those moles!
Here are the main methods of the mole object:
setState(state): Sets the state to the specified state value. States are stored as constants (UP and DOWN). When the state is changed, the mole’s state property is modified, and the mole’s image is modified to reflect the current state. If the state is set to UP, a timer begins, which will be used to track how long the mole is visible.
CheckClick(): Checks to see if the mole is currently clicked. If the mole is currently UP, hide the mole and increment the score.
CheckTime(): The behavior of this function depends on the mole’s status. If the mole is currently down, randomly determine if it should pop up. If the mole is up, check to see if the popupLength has been exceeded. If so, lose a life and consider ending the game.
The checkTime code is the most interesting code in the mole game, so here is that method:
tMole.checkTime = function(){
//if down, consider popping up
if (this.state == DOWN){
randVal = Math.random();
if (randVal < this.popupPerc){
this.setState(UP);
} // end if
} else {
//if up, check to see how long we’ve been up
time = this.timer.getElapsedTime();
if (time > this.popupLength){
this.setState(DOWN);
//lose a life
lives--;
if (lives < 0){
saveHighScore();
alert(“You lose”);
document.location.href = “”;
} // end if
} // end if
} // end if
} // end checkTime
Other features of the mole game
Once a single mole has been created and is acting correctly, it’s easy to build a lot of them. As usual, I created an array to handle a large number of objects of the same type. Modify the NUM_MOLES constant to change the number of moles in the game.
Also note that I added a virtual joystick if the scene registers a touch object. This will cause the touch screen to act just like a virtual mouse, and will allow the game to be played on a touch device. (It turns out to be a really great game for touch screens, but you should avoid using a real hammer.)
One more interesting feature is the high score mechanism. The computer keeps track of the high score on that particular machine. The high score mechanism uses a relatively new feature called localStorage. It’s similar to the well-known cookie mechanism, but safer, more powerful, and a lot easier to use.
The getHighScore() function loads the current high score. If there isn’t yet a high score, it will be set to zero.
function getHighScore(){
//get the high score on this machine using localStorage
highScore = parseInt(localStorage.getItem(“moleHighScore”));
console.log(“highScore: “, highScore);
if (highScore == “null”
|| highScore == null
|| isNaN(highScore)){
highScore = 0;
} // end if
} // end getHighScore
The saveHighScore() function is called when the game ends. It checks to see if the current high score has been exceeded. If so, the new high score is saved.
function saveHighScore(){
if (hits > highScore){
alert(“New high score!”);
localStorage.setItem(“moleHighScore”, hits);
} // end if
} // end saveHighScore
Even if the user leaves the page or turns off the browser, the high score will be maintained.
The localStorage mechanism only keeps track of the current browser. It cannot be used to check global high scores. This requires server-side programming, which is beyond the scope of this book.
Improving the mole game
As always, you can improve this game many ways.
Improve graphics and sound. The default graphics are pathetically weak, and this game has no sound effects to speak of. These are easy ways to improve the program.
Change the screen size. This game is highly dependent on screen size. A larger screen can be much more difficult than a smaller screen.
Modify the number of moles. This is an easy way to change the difficulty level. More moles will be more difficult, unless they begin to overlap.
Prevent overlapping moles. As a default, the placement of each mole is completely random, so they can overlap. Use the techniques described in the marble game earlier in this chapter to prevent a mole from spawning on top of another hole.
Make a more orderly setup. I actually like the randomness of this game, but the traditional version uses an orderly grid for the moles. Line up the moles so they are in a more organized pattern on the screen.
Change mole settings. The popupRate and popupTime properties give you a great way to modify the behavior of each mole. You might adjust these values over time to make the game speed up.
Move the holes. Consider moving the mole after it has gone down. This adds variety to the game.
Jump and Run on Platforms
The platform “jump and run” genre has long been a staple arcade genre for good reason. It provides a nice interactive experience and is relatively easy to modify for many different kinds of games.
The essential element of a platform game is — well — platforms. The action usually happens with a side view and a player character that responds to gravity. Normally, the player will jump around on platforms and fight enemies by shooting, jumping, or melee combat.
My prototype shows the essential features. It includes a player character that can jump and land on platforms. I’ve also included draggable platforms so you can edit the scene and see how the character interacts with various platform configurations.
You can see my example in Figure 13-5.
Figure 13-5: The character jumps around on the platforms.
Jumping and landing
The key to a side-scrolling game is the jumping and landing mechanic. As with the lunar lander described earlier in this chapter, use a falling property to track whether the character should respond to gravity or not. Here’s the code from the checkKeys() method that reads the up arrow and makes the character jump.
if (keysDown[K_UP]){
if (this.falling == false){
this.setImage(“characterUp.png”);
this.y -= 5;
this.falling = true;
this.addVector(0, 15);
} // end if
}else {
checkFalling();
}// end if
The checkFalling() function checks each of the blocks. If the character is not touching any of the blocks, set falling to true. This will make the character fall once it moves off of a block.
Coming in for a landing
The interaction between the character and the blocks is important because you want the character to stop moving before it hits a block. This requires a technique called predictive collision detection, which sounds a lot more complicated than it is. Here’s the mechanism:
1. Move the element as normal.
Do the calculations to move the object (in this case the character) as normal. Note that the character isn’t drawn yet, but new x and y values have been determined by adding dx and dy.
2. Check for a collision.
Check to see if the character has collided with anything (in this case, each block in the array of blocks).
3. If a collision occurs, back up the character.
You’re checking for a collision, but you don’t want the character to overlap with the block. Instead, you’re interested in knowing whether the current motion vector would cause a collision.
4. Subtract dx from x, dy from y.
A collision has been detected, so detract that collision by subtracting the motion vector. This results in the sprite being where it started before the collision was detected.
5. Set the sprite’s speed to zero.
Set the sprite’s speed to zero so the next frame doesn’t cause the sprite to crash into the block again.
The easiest way to get the predictive behavior is to add a backup() method to the Sprite object, which can be called on any type of collision:
tCharacter.backup = function(){
//I’m overlapping something I shouldn’t share space with
//back up to where I was before the collision was detected
X = this.x - this.dx;
Y = this.y - this.dy;
this.setPosition(X, Y);
} // end backup
Making draggable blocks
This game features another very interesting feature: Each block can be dragged to a new position so you can experiment with other block placements. Making any sprite draggable is relatively easy. Simply check to see if the block currently is being clicked. If so, set its position equal to the mouse position:
tBlock.checkDrag = function(){
//allow the block to be draggable
if (this.isClicked()){
this.setPosition(scene.getMouseX(), scene.getMouseY());
} // end if
} // end checkDrag
Improving the platform game
The platform game is open to many kinds of enhancements:
Use multiple levels. The default blocks are easy to build and work with, but they aren’t very interesting. Experiment with different block shapes and positions to build interesting levels. You can store the block positions in arrays to make new levels, and simply reuse the blocks.
Consider a tile-based approach. The platform example uses an arbitrary block placement scheme, but you can also use a tile-based approach. Look at the tile-based world described later in this chapter, in the Miles and Miles of Tiles and Tiles section, and convert it to a side-scrolling mechanism.
Add goals and enemies. An obvious improvement to this game would be to include some goal to reach with some obstacle in the way. Consider how you might implement enemy characters. Will they move? Will they shoot? Also consider adding powerups to improve jumping speed, add a ranged weapon, or whatever else you can imagine.
Add more firepower. Add a weapon to the character so it can shoot. In side scrollers, the weapon normally fires horizontally, but you can play around to get the behavior you want.
Improve the physics. The dynamics of this game work pretty well, but you can improve them with a bit more tweaking. Follow the general outline of the existing program, but see if you can make it work exactly like what you want.
Pong — the Granddaddy of Them All
No game development book would be complete without a mention of the famous Pong game. While this wasn’t technically the first video game, it was the first to attract popular attention, and it’s by far one of the more influential games ever made. Figure 13-6 shows my take on this classic game.
Pong is a relatively easy game to write, but it does have a couple of features that can be surprising. It can be a bit tricky to get the ball-paddle collision to work correctly, and coming up with an interesting computer player can be challenging. Read on to see how it’s done.
Figure 13-6: It’s pong. What else can I say?
Building the player paddle
The paddle object is quite straightforward, but there are actually two paddles with different behaviors. In my version of the game, the left paddle is controlled by the player, and the right paddle is controlled by a computer AI. I built a single paddle object that can serve as either a player or an AI paddle. (This will simplify converting the game to a multiplayer game.) The player paddle just follows the mouse:
tPaddle.followMouse = function(){
//follows mouse for player control
this.setImgAngle(90);
this.setPosition(this.x, scene.getMouseY());
} // end followMouse method
Adding artificial stupidity
It’s actually very easy to build an Artificial Intelligence (AI) for the opponent. Simply set the paddle’s Y value equal to the ball’s Y value. However, this will be boring, because the opponent will never miss, and will always hit the ball squarely in the middle of the paddle, making it easy to return. A perfect AI is no fun at all. What you need is to give the AI paddle some kind of attention issues (but we still love it).
The AI shouldn’t directly follow the ball. Instead, it should check to see whether the ball is above or below it, and respond accordingly.
I added two variables to control the AI paddle’s motion. The BRAINS constant is a percentage. If BRAINS is set to .5, the paddle will check for ball location only half the time. For an easier game, set the BRAINS value low. The other primary value is V_SPEED, or the vertical speed of the paddle. This indicates how quickly the paddle will move toward the ball. A higher value will create a more powerful AI player. Find the right combination of these two values to get the AI behavior you want. Here’s the code for the autoMove() method:
tPaddle.autoMove = function(){
//automatically moves
this.setImgAngle(90);
//don’t move on every turn
if (Math.random() < BRAINS){
if (this.y > ball.y){
this.setMoveAngle(0);
} else {
this.setMoveAngle(180);
} // end if
this.setSpeed(V_SPEED);
} // end if
} // end autoMove
Building a ball to bounce off boundaries
While the ball is a seemingly simplistic sprite, it does have some interesting behavior. The ball has a unique boundary-checking scheme. It bounces off the top and bottom of the screen, but if it leaves the sides, it wraps (and one player or the other scores).
If you don’t have a boundary scheme that fits one of the standard patterns, you can simply overwrite the checkBounds() method to do whatever you want. (Note that you don’t need to explicitly call checkBounds(). It is automatically called by the sprite’s update() method. Your custom version of checkBounds simply replaces the built-in version. Here’s my variant:
tBall.checkBounds = function(){
//overwrite checkbounds function to give
//custom behavior
//bounce off of top and bottom
if (this.y < 0){
this.setDY(this.dy * -1);
}
if (this.y > scene.height){
this.setDY(this.dy * -1);
}
//wrap off of sides
if(this.x < 0){
this.setPosition(scene.width - 150, this.y);
//computer scores
} // end if
if (this.x > scene.width){
this.setPosition(150, this.y);
//player scores
} // end if
} // end checkBounds
If the ball hits the top or bottom of the screen, invert dy to make it bounce. If it hits the left or right of the screen, move it to the other side (in front of the paddle, so it doesn’t bounce off of the back of the paddle).
When the ball leaves the screen at the sides, somebody will score, so I left myself a comment indicating where the scorekeeping (and eventually end-of-game conditions) will go.
Putting some spin on the ball
In traditional versions of Pong, the ball can be controlled by choosing where on the paddle to hit the ball. If you hit the ball near the top of the paddle, the ball will move upward. If you hit the ball near the center of the paddle, it will fly across the screen horizontally, and if you hit near the bottom, the ball will move downward. A little bit of math gives you this behavior. (And you told your algebra teacher you’d never need this.)
tBall.checkBounce = function(paddle){
//responds to a collision with the given paddle
//Max and min dy
MAX = 10
if (this.collidesWith(paddle)){
this.setDX(this.dx * -1);
dy = this.y - paddle.y;
dy = ((dy / paddle.height) * 2);
dy *= MAX;
this.setDY(dy);
} // end if
} // end checkBounce
The dx value is easy to calculate because you simply invert dx to move in the other direction. The dy value is calculated by determining the difference between the ball’s y position and that of the paddle:
1. Determine a maximum dy.
This value determines the highest level of deflection you’ll allow. If the MAX value is set to 10, the ball’s dy value will be -10 at the top of the paddle, 0 at the middle, and 10 at the bottom of the paddle.
2. Invert dx.
If the ball is moving left, multiply the dx value by -1 to make it go right. If it’s going right, the same operation (multiplying by -1) will make it go left. Any paddle collision inverts the ball’s dx.
3. Find the raw difference in y values.
Calculate how far apart the y value of the paddle and the ball are.
4. Normalize this value.
If you divide the raw dy value by the height of the paddle, you’ll get a range between -.5 and .5. Multiply that value by 2 to get a -1 to 1 range.
5. Multiply the normalized dy by MAX.
Multiplying the normalized dy value by the MAX value will give a dy value between -MAX and MAX.
Improving the Pong game
While this Pong game has the basic behavior down, it’s far from ready for actual play. Here are a few things to consider adding:
Add aesthetic appeal. As usual, my game is functional but not very pretty. You can do a lot to make it look better, from customizing the paddles to adding ball animations and sound effects.
Add scorekeeping. Without a scorekeeping mechanism, the game is kind of pointless. Add the ability to track user and computer scores. Also add some way to determine the end of the game.
Add powerups. Add some spice to the game by having new variations: Change the size of each paddle, invert the control of the player paddle, change the ball speed, make the ball occasionally invisible, or invert the ball-paddle collision algorithm for starters.
Tune up the AI. The AI I present here is functional, but it can be improved. For one thing, it gets pretty jittery when the ball is traveling in a flat trajectory. See if you can figure out a way to smooth out this behavior.
I’m a Fighter, Not a Lover — RPGs
The role-playing game (RPG) is one of the most enduring forms of gameplay. While role-playing games can work in many different ways, the general setup follows a familiar pattern. The user engages as a character with a set of basic characteristics. The player then collects objects and defeats enemies to eventually improve her performance, which leads to more difficult monsters.
The simple variation shown in Figure 13-7 illustrates a basic yet very flexible combat mechanic: The user controls a spear-wielding hero facing a dastardly orc.
This game features a number of important ideas: an animated character, a base class, and a simple combat system.
Figure 13-7: Poke that orc with a stick, will you?
Building the base Character class
From a data point of view, monsters and heroes are actually very similar to each other. (I’ll leave debate about the meaning of this point to philosophers.) Begin by building a generic Character class that supports all the common characteristics, and you can then easily modify this class to build all the heroes and monsters you can imagine. The keys to any character class are the statistics used in combat and leveling. You can handle this a number of ways, but my game uses a simplified combat form familiar to tabletop role-players:
Name: While this may be obvious, the name is useful for reporting what is happening.
hp: Hit points. This is the amount of damage a character can take. If you have a lot of hit points, you can take a lot of damage.
hitPerc: This is the percentage of likelihood that a particular attack will hit. If the hitPerc is 50, attacks will land half the time. Higher values lead to more successful attacks.
damage: The damage modifier indicates how much damage will be done upon a successful hit. This value indicates how many six-sided dice will be rolled. (Using dice gives a more believable damage value than a straight random value. For example, rolling two six-sided dice will produce the values five through nine much more frequently than 2 or 12.)
defMod: This value is a defensive modifier. It’s used to simulate dexterity and the ability to dodge an attack. The defense modifier is used to make an opponent less likely to land a blow.
armor: Once an attack has landed, the armor value will absorb some of the damage. The larger the armor value, the harder it is to hurt the character.
The Character class holds all these values in properties, and it also contains two functions. The showStatus() function returns a string containing all the stats for the character. The fight() function manages a round of combat.
Here’s the code for the fight() method:
tChar.fight = function(enemy){
//assumes enemy is also based on Char
hitPerc = (this.hitPerc - enemy.defMod) / 100;
if (Math.random() < hitPerc){
damage = 0;
for (i = 0; i < this.damage; i++){
damage += parseInt(Math.random() * 6);
} // end for
damage -= enemy.armor;
enemy.hp -= damage;
if (enemy.hp <= 0){
alert(enemy.name + ” is dead!”)
document.location.href = ””;
} // end ’enemy dead’ if
} // end ”hit” if
} // end fight
Here’s how the fight() method works:
1. Accept another character as a parameter.
The fight() method expects an enemy class, which should also be a character (or something based on the Character class).
2. Determine the hit percentage.
Subtract the enemy’s defense modifier from the attacker’s hitPerc. This will give a value between 0 and 100. Divide this value by 100 to get a 0-1 float.
3. Roll a random number.
The Math.random() function returns a value between 0 and 1. Compare this to the calculated hitPerc to find out if there has been a hit.
4. Roll the dice.
Roll one six-sided die for each damage point, and add this value to a running total to determine how much damage is caused by this hit.
5. Compensate for enemy armor.
Subtract the armor value from the damage amount.
6. Subtract damage from the enemy hp.
Apply damage by subtracting it from hp.
7. Check to see if the enemy is dead.
If the hp goes below 0, the enemy is dead.
The combat model is designed to be simple and flexible. All the various pickups or level improvements can be boiled down to modifying these characteristics. For example, if your character picks up a shield, simply add a value to the armor modifier. A stronger weapon may involve a better toHit percentage and/or more damage. As your character gets stronger, he gets more hp. Likewise, all the monsters are pretty much the same, but they’ll have different values. For example, you can make a small creature that’s difficult to hit with a small hp, small damage, and a large defense modifier. A large slow monster might have a lot of hp but a small defensive modifier.
The Character class is interesting, but it isn’t really meant to be used on its own. Instead, it’s designed to be a base for more specific characters. It has the minimal features you’d expect of any character, but then you can extend it (like you extend the sprite) to add more specific behavior.
One does not simply build an orc . . .
The Orc class is a simple extension of the Character class. In my example, the orc does very little, but I could easily extend it to move, drop treasures, or whatever. However, this version is quite straightforward. All I do is extend the Character class, setting specific values for the various parameters.
function Orc(){
tOrc = new Character(“orc”, “orc.png”);
//orc is bigger than default but with weaker weapons
tOrc.hitPerc = 50; // perc likelihood of hitting opponent
tOrc.damage = 1; // damage(d6) done on a successful hit
tOrc.defMod = 5; // subtract from opponent’s hitPerc
tOrc.armor = 1 // subtract from opponent’s damage
tOrc.hp = 50; // amount of damage I can sustain
tOrc.setSpeed(0);
tOrc.setPosition(300, 200);
return tOrc;
} // end orc
We need a hero
The hero is another extension of the Character class, but (as befits a hero) it has a bit more enhancement. The hero uses a sprite sheet animation like those described in Chapter 8. I produced the images from the marvelous resources at openGameArt.org. In particular, I used a wonderful GIMP file that allows you to build custom characters by turning on and off various layers in GIMP. I then simplified those images to create only what I needed to build my Hero class. See Chapter 11 for more information on the sprite sheet and openGameArt.org.
The Hero class is much like the default Character (in fact, it uses all the default combat values, so I don’t change those at all). The main addition is the animation code. Here is a portion of that code:
function Hero(){
tHero = new Character(“hero”, “hero.png”);
tHero.loadAnimation(512, 256, 64, 64);
tHero.generateAnimationCycles();
tHero.renameCycles(new Array(“up”, “left”, “down”, “right”));
tHero.setAnimationSpeed(500);
//leave all stats at their default values
tHero.pause = function(){
this.setSpeed(0);
this.setCurrentCycle(“down”);
this.pauseAnimation();
}// end
tHero.checkKeys = function(){
if (keysDown[K_LEFT]){
this.setSpeed(1);
this.playAnimation();
this.setMoveAngle(270);
this.setCurrentCycle(“left”);
}
I obviously left out some of the other keyboard-checking code, but you can see this program is a variation of the animation described in Chapter 8. The hero uses a predictive collision model to prevent walking into the orc. If a collision is noted, the hero simply backs up to the original spot before updating itself:
tHero.checkCollision = function(){
//predictive collision detection
if (this.collidesWith(orc)){
//back up and pause
this.x -= this.dx;
this.y -= this.dy;
this.pause();
fight();
}
} // end checkCollision
If the hero collides with the orc, the fight() mechanism begins. This is actually quite simple:
function fight(){
hero.fight(orc);
orc.fight(hero);
heroStatus.innerHTML = hero.showStats();
orcStatus.innerHTML = orc.showStats();
} // end fight function
The fight() function has the hero attack the orc, and then the orc attacks the hero. After the round, each character’s statistics are displayed in the appropriate output.
Improving the role-playing game
This game simply begs for improvements. There are many ways to take this particular example further:
Add more monsters. You can build an entire range of monsters. Note that each monster could simply be an image and the combat statistics. It’s relatively easy to build a data structure that stores an entire array of ever-more challenging monsters to fight.
Add an inventory. Allow the user to pick up various items. Each of the items will simply change a variable or two: making the player stronger, giving her more damage, or better defense against attack, for example.
Include a dungeon. This game doesn’t have a lot of atmosphere so far. Use some background graphics to add atmosphere. You can always use an array of blocks for barriers as you’ve seen in other examples in this chapter.
Add a tile-based dungeon. Of course, tile-based worlds and RPG combat are natural companions. Look at the tile-based example later in this chapter for information on building a tile-based world to hold your monsters and treasures.
Tanks — and You’re Welcome!
I’ve long enjoyed the artillery genre. This type of game gives you some sort of launch mechanism with semi-realistic physics, and has you launch projectiles (avians with anger issues or otherwise) at some sort of target. My take begins as a single-player game against a drone tank, but you can easily extend it to a two-player game or give the opponent more intelligence. Figure 13-8 shows the tank game in action.
Figure 13-8: I’m shooting at the evil enemy tank.
Tanks, turrets, and shells
The most interesting thing about a tank-style game is the relationship between the tank, its turret, and the bullets it fires. In my game, the tank is controlled by the A and D keys, and the turret’s angle is controlled by W and S (I use these keys to reserve the arrow keys for a two-player game if you ever want to do so).
The tank is a sprite, but the tank image (at least the player-controlled tank) doesn’t include a turret. The turret is a separate sprite intended to be linked to the tank and rotated on its own. When the player moves the tank, the turret moves with it. When the user rotates the turret, the turret rotates, but the tank doesn’t. The bullet is a third sprite, which appears when the user fires the tank. The bullet’s initial position is determined by the tank’s position, and the bullet’s initial motion angle is determined by the turret’s angle.
The turret sprite is the same size as the tank. Design the turret so it revolves around its center point (which, in the simplest case, will also be the center of the tank). Most of the turret sprite will be transparent so the tank can show through. (Check the raw images on my website if you’re confused.)
Here’s the code for the tank:
function UserTank(){
tTank = new Sprite(game, “greenTank.png”, 50, 25);
tTank.setSpeed(0);
tTank.setPosition(100, 550);
tTank.turret = new Sprite(game, “turret.png”, 50, 25);
tTank.bullet = new Bullet(tTank);
tTank.checkKeys = function(){
if (keysDown[K_A]){
this.changeXby(-2);
}
if (keysDown[K_D]){
this.changeXby(2);
}
//always move turret with me.
this.turret.setPosition(this.x, this.y);
//rotate turret
if (keysDown[K_W]){
this.turret.changeImgAngleBy(-5);
if (this.turret.getImgAngle() < 0){
this.turret.setImgAngle(0);
} // end if
}
if (keysDown[K_S]){
this.turret.changeImgAngleBy(5);
if (this.turret.getImgAngle() > 90){
this.turret.setImgAngle(90);
}
}
if (keysDown[K_SPACE]){
this.bullet.fire();
}
this.turret.update();
this.bullet.checkGravity();
this.bullet.update();
} // end checkKeys
return tTank;
} // end tank
The tank design is mildly complicated by having a dependent turret sprite, and a bullet sprite. Here’s how to build this mish-mash of armored sprite goodness:
1. Build the tank sprite first.
As with most examples in simpleGame, begin by building a temporary sprite for the tank (called tTank).
2. Build a turret sprite.
The turret is a second sprite. It is a property of the tank, as well as a sprite in its own right. The turret is fairly simple, so it can be a stock sprite. It does not need to be a complete subclass.
3. Build a bullet sprite.
Each tank has a sprite and a bullet. The bullet will need some specific behaviors (boundary-checking, collision, and gravity), so it will be a subclass of the Sprite object. Look at the next section for information on building the bullet. For now, just know that the tank will need a bullet. Note that the bullet will need to know which tank it belongs to, so I send the current tank as a parameter.
4. Read the keyboard.
The tank is currently set to use the WASD keys for input. (I did this to enable a two-player game later.)
5. Move the tank left and right.
The left and right controls move the tank sprite itself. Move the turret so its center is always the same as the tank’s center. This causes the turret to always move with the tank.
6. Rotate the turret.
The up and down controls cause the turret to rotate. Set minimum and maximum values to keep the turret within a reasonable range of angles.
7. Fire the bullet.
On the fire command (space bar by default), invoke the bullet’s fire() method. (Of course, you’ll need to write that in the Bullet class.)
8. Update the turret.
Up to now, all update() calls have happened in the main update() function. However, the main game doesn’t really need to update the turret. Because the turret is part of the tank, updating the tank should update the turret. Because the checkKeys() method will happen every frame, I update the turret to ensure that it draws correctly.
9. Move the bullet.
If a bullet is active, use the checkGravity() method to track its current course while taking gravitational pull into account. If there is no bullet currently active, this line will be ignored.
10. Update the bullet.
Again, the bullet feels like part of the tank, so it should be updated automatically.
Building a bullet
Okay, military purists, I know it’s a shell, but for now, let’s just call it a bullet. It’s an arcade game, after all.
The bullet class will be fired by a tank. The bullet is a surprisingly sophisticated class, as it needs a fire() method (which will fire the bullet based on the tank and turret’s current situation) and a checkGravity() method (which plots the bullet’s trajectory in space).
Here’s the Bullet class code:
function Bullet(owner){
//owner is the tank owning this bullet
tBullet = new Sprite(game, “bullet.png”, 5, 5);
tBullet.owner = owner;
tBullet.hide();
tBullet.setBoundAction(DIE);
tBullet.fire = function(){
//begin at center of my tank
//pointing in tank turret’s direction
this.setPosition(this.owner.x, this.owner.y);
this.setMoveAngle(this.owner.turret.getImgAngle());
this.setSpeed(20);
this.show();
} // end fire
tBullet.checkGravity = function(){
this.addVector(180, 1);
} // end checkGravity
return tBullet;
} // end bullet
Here’s the life story of a bullet in my game:
1. Specify the owner tank.
When this game has multiple tanks firing at each other (which it clearly needs), there should be a lot of bullets flying around. Each bullet will need to know which tank it belongs to so it can fire from the right position in the right direction.
2. Hide.
The Bullet object is created at the very beginning of the game, but it spends most of its life hidden away unseen. One of the first things you do is hide the bullet so it will be visible only after it’s fired.
3. Set boundary action to DIE.
Bullets typically die when they reach the end of the screen. The sprite is not removed from memory. It simply isn’t displayed on the screen and doesn’t respond to collisions. Setting the boundary action to DIE will cause the desired behavior.
4. Fire from the owning tank’s position.
When the bullet is fired, place it at the owning tank’s position.
5. Set the movement angle to the owning tank’s turret angle.
The turret’s main job is to indicate which angle is used as the bullet’s starting trajectory.
6. Provide a large movement speed.
Bullets should move quickly, so set an initial velocity of 20 pixels per frame. (You can add another control to allow the user to modify the initial velocity if you wish.)
7. Reveal the bullet.
Invoke the bullet’s show() method to make the bullet appear on the screen.
8. Check for gravity.
All this function does is compensate for gravitational pull with the addVector() method. Check Chapter 8 if you need a review on the use of this powerful method.
Improving the tank game
Although all the tank’s basic functionality is in place, this game has a very simplistic behavior. Right now, the only enemy is a very stupid drone tank (which simply jitters around and doesn’t even shoot back). The improvements you might make begin with these suggestions:
Improve the other tank. Modify the other tank to have a real turret and the same general behavior as the first. (Note that you may want to invert the second tank so it generally fires to the left.)
Improve the AI. The drone tank isn’t very bright or fearsome. Give it the capability to shoot back periodically.
Add fixed defenses. Maybe instead of an enemy tank, you have a target to destroy (the enemy command bunker or something) with defenses in the way. Add some obstacles that need to be blown up before you reach the bunker.
Make enemy artillery. Build fixed-position artillery units that periodically fire. The user will have to destroy these or risk being blown up.
Make a two-player version. The tank-style game is ideal for two players on a single keyboard. Add the second tank and a scoring mechanism.
Change the whole theme. This general game can be rebuilt along many themes. You can be a gunner defending your bomber from enemy aircraft, or manning a turret defending from hordes of onrushing enemies. (This is the foundation of the famous tower defense style of games.)
Miles and Miles of Tiles and Tiles
A tile-based world isn’t really a game type. Instead, it’s a technique used in many other games to provide interesting flexible backgrounds without huge memory costs. The basic idea is to take a number of small images and use them in combination to build a complete background image. Figure 13-9 shows a simple map drawn with a tile-based world.
Typically, you’ll build a tile object, which contains a number of small (32 x 32 pixel) images. Each tile object can display any of the images on command. This scheme has a number of interesting advantages:
Memory requirements can be very small. Each image loads into memory only once, so you can create a very large world (much larger than the visible screen) with a small memory footprint.
You can use many different tiles. My example uses only three small tiles (grass, dirt, and water), but you can build an extremely complex world with any of the beautiful tile sets you can download from sites like OpenGameArt.org.
The map is dynamic. The image displayed in each tile can be modified at runtime. In my example, you can click on any tile to change the terrain type. This allows the map state to change during gameplay (for example, a block becomes molten slag after a nuclear attack). This also allows you to add a map editor.
Figure 13-9: Only three small images were used to draw this map.
Tiles can have gameplay effects. You can use tiles to create interesting tactical situations, like water that cannot be crossed or mountains that give an advantage to a defender.
Maps are simply arrays of integers. To store a tile-based map, you don’t need to store the tiles at all. Instead, you simply keep track of the tile states. See the code in this section for an example.
Maps can be much larger than the screen. A tile map can be any two-dimension array of integers. If you want to display a huge game world, you can build it as large as you want and simply reflect a subset of that world as the tiles shown on the screen.
Scrolling a tileset is simple. It’s easy to make large scrolling worlds with a tile system, because the display is separated from the data. The tiles themselves rarely move. Instead, a different subset of the map data is displayed, giving the illusion that the player is moving in a larger world.
Tiles are suitable for multiple game types. Tiles are frequently used for role-playing games, as well as board games, tactical games, and side-scrolling platform games.
Creating a Tile object
The Tile object is (naturally enough) the foundation of tile-based maps. Here’s my code for a simple tile prototype:
var GRASS = 0;
var DIRT = 1;
var WATER = 2;
var NUMSTATES = 3;
function Tile(){
tTile = new Sprite(scene, ”grass.png”, 32, 32);
tTile.setSpeed(0);
tTile.state = GRASS;
tTile.images = new Array(”grass.png”, ”dirt.png”, ”water.png”);
tTile.row = 0;
tTile.col = 0;
tTile.setState = function(state){
this.state = state;
this.setImage(this.images[this.state]);
} // end setState
tTile.getRow = function(){
return this.row;
} // end getRow
tTile.getCol = function(){
return this.col;
} // end getCol;
tTile.getState = function(){
return this.state;
} // end getState
tTile.checkMouse = function(){
if (this.isClicked()){
newState = this.state;
newState++;
if (newState >= NUMSTATES){
newState = 0;
} // end if
this.setState(newState);
} // end if
} // end if
return tTile;
} // end Tile constructor
The most significant part of a tile is its multi-state nature. It has multiple states. Each state displays a different image. Here’s how to write it:
1. Prepare your images.
The most visible parts of the tile-based system are the various images. Build or obtain (with the necessary permissions, of course) some tiles you can use. Mine came from the excellent lpc tile atlas at http://opengameart.org. I broke each image into a separate 32-by-32 image. Each image should be the same size, and usually these sizes will be a power of two (16 x 16, 32 x 32, and 64 x 64 are the most common sizes).
2. Build constants for the states.
The easiest way to work with states is to assign constants for them. Constants have the advantage of being easily readable by humans and straightforward integers to the computer. I created a constant for each state in my tileset, as well as a constant describing the number of states. (My example has only three states, but you can easily expand it to make as many as you want.) I also added constants for the number of ROWS and COLS in my map.
3. Build a standard sprite.
The tile is still essentially a sprite. It doesn’t typically move, so you can set its speed to 0. Use any of the sprite images you want as the default.
4. Assign a default state.
The state property is the most important aspect of a tile. It indicates which state the tile is currently displaying. The state value should always be one of the state constants.
5. Create an array of images.
Each tile will have access to all the possible images. Store them in an array. Make sure the array order lines up with the constant values. For example, “grass.png” is element zero in my array, and the GRASS constant is zero, so images[GRASS] will be “grass.png”
6. Set a row and column.
Tiles are usually placed in a two-dimensional grid, so it can be very useful to track the current tile’s row and column.
7. Add a setState() method.
This method allows you to easily change a tile to any of the state values. Use a constant to assure the state is recognized by your tiles. The state property is modified to reflect the current state, and the image is also changed, so the correct image will display on the next update.
8. Provide data retrieval techniques.
These functions return the row, column, and current state of the tile.
9. Allow an editing behavior.
In my example, I’m actually making a map editor, so I’ll allow the user to modify each tile by clicking on it. The checkMouse() method determines whether the tile has been clicked. If so, the state is incremented and the new state is displayed.
Building a map from tiles
Each tile is a powerful tool, but the real power of the tile-based structure is how tiles are combined to create a complete map. The tileset is a two-dimension array of tile objects. Like most two-dimension arrays, it’s normally managed by a pair of nested loops. Here’s the code for setting up the tileset:
function setupTiles(){
tileset = new Array(ROWS);
for (row = 0; row < ROWS; row++){
tRow = new Array(COLS);
for (col = 0; col < COLS; col++){
tRow[col] = new Tile();
xPos = 16 + (32 * col);
yPos = 16 + (32 * row);
tRow[col].setPosition(xPos, yPos);
tRow[col].row = row;
tRow[col].col = col;
} // end col for loop
tileset[row] = tRow;
} // end row for loop;
} // end setupTiles
There are only a few points to keep in mind here:
The tileset is an array. Each member of the tileset array is actually a row (which is another array). Build an array of length ROWS.
Step through each row. Use a standard for loop to step through all the rows.
Each row is an array of length COLS. A two-dimension array is actually an array of arrays (at least, that’s how it’s implemented in JavaScript and many other languages). Make an array of length COLS for each row.
Step through the columns. Make a for loop that happens once per column. You now have two counting variables (row and col), which together describe the position of each tile in the two-dimension structure.
Create a new tile. Simply use the tile constructor to build a new tile.
Set the tile’s position. I used a little math to calculate the appropriate position of each tile in the scene. You can multiply the row and column by the width and height of the cell to determine a rough placement, but because the X and Y positions of a sprite refer to the center of the sprite, I added half the tile’s width and height to make the tiles fit nicely in the screen.
Assign the row and column data to the sprite. For easier access later, simply copy the row and col data to properties of the sprite.
Updating the tiles
Tiles are just sprites, so they are updated in the normal way. However, there are a lot of tiles, so it makes sense to use an organized approach to updating. Remember, nested for loops are the natural companions of 2D arrays, so a pair of loops is the best way to ensure every tile gets updated.
function updateTiles(){
for (row = 0; row < ROWS; row++){
for (col = 0; col < COLS; col++){
tileset[row][col].checkMouse();
tileset[row][col].update();
} // end col for loop
} // end row for
} // end updateTiles
My example is also a map editor, so I included a call to check the mouse inside the nested loops so I don’t have to build another nested loop structure.
Loading a tile map
One of the most exciting things about tiles is how easily they’re stored, loaded, and modified. It isn’t necessary to store and load all the tiles. All you really need to know is the states! Take a look at the loadMap() function, and you’ll see what I mean:
function loadMap(){
// loads a map from an array
map = new Array(
new Array(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0),
new Array(1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0),
new Array(0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0),
new Array(0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0),
new Array(0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0),
new Array(0,0,0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,0),
new Array(2,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,2),
new Array(2,2,2,2,2,2,0,0,0,0,1,0,0,0,0,0,2,2,2,2),
new Array(0,2,2,2,2,2,2,0,0,0,1,0,0,0,2,2,2,2,2,0),
new Array(0,0,0,0,0,0,2,2,2,2,1,2,2,2,2,2,0,0,0,0),
new Array(0,0,0,0,0,0,0,2,2,2,1,2,2,2,0,0,0,0,0,0),
new Array(0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0),
new Array(0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1),
new Array(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0),
new Array(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)
);
for (row = 0; row < ROWS; row++){
for (col = 0; col < COLS; col++){
currentVal = map[row][col];
tileset[row][col].setState(currentVal);
} // end col for loop
} // end row for
The interesting part of this function is the map variable. This is nothing more than a two-dimension array of integer values. If you squint a little bit while staring at the array, you’ll see the map pattern in the integers. Each integer represents the state for the corresponding tile.
Of course, you can have more than one such array, which means it’s easy to store multiple maps. You can also make the integer array much larger than the screen, and simply display a screen-size subset of the main map.
The second part of the function simply maps through the integer array and sets each tile to the state indicated by the integer.
Improving the tile world
The tile-based world is really a technique more than a game, but you can use a few techniques to improve the system:
Collision states: You can test to see if a sprite collides with any tile. You might have certain states that register collisions and other states (for example an “empty” state) that ignores collisions. You’ll frequently want to use predictive collision detection (described in the RPG section of this chapter) to keep your sprite from intersecting a wall or barrier.
Editing maps: You can build a map editor that allows you to graphically build a map with a given tileset. Then just have your program print out the corresponding state values. You can then embed these values in your code. Although it would be nice to load and save worlds in external files, JavaScript doesn’t have this capacity (for security reasons). It’s possible to do so, but the best solutions involve server-side languages like PHP, which are outside the scope of this book (but see one of my other books on this topic if you’re interested).
Large scrolling worlds: One of the nicest features of tile systems is the capability to have worlds that are larger than the visual screen. Just build a very large world array. Then create variables called something like offsetLeft and offsetTop. When you want to scroll the map, just change the values of these variables. When you display a map, just display row + offsetTop and col + offsetLeft to display the appropriate subset of the larger map.
Page maps: An alternative to the scrolling world is a page-based tile system. For this system, you simply create a series of maps. When the character leaves a map, simply load the new map. This is frequently used in RPGs to simulate entering a building, for example.
While role-playing adventure games are the obvious use of tile-based worlds, they also appear in a number of other genres.
Playing cards: Build a tile set based on playing cards. (There are some good card images at http://openclipart.org.) Use these tiles to illustrate a simple card game.
Platform: Platform games are great for tile-based worlds, because they can be expanded in multiple directions. Use a collision-state mechanism to determine if a tile registers a collision.
Puzzle: Certain kinds of puzzle games (like matching games and pipe games) are ideal tile games. Essentially, you’ll store all possible elements in each cell, but display only the ones you need.
Strategy games: Strategy games can be implemented quite well in a tile-based setting. Typically, the map is implemented in a tile setting to allow for combat and movement modifiers based on terrain types.
Board games: Take a look at the tic-tac-toe game implemented next for another example of a tile-based implementation.
Tic-Tac-Toe Is the Way to Go
Like many programming teachers, I see a lot of tic-tac-toe games. This game seems pretty simple, but it can be surprisingly difficult to implement well. There are three main aspects to tic-tac-toe:
The visual and data interface: The most obvious (and easy) problem is how to manage the visual layout: How do the players interact with the board to make their selections?
Determining a winner: It seems straightforward to determine if somebody wins. After all, it’s just a series of if statements. But this is where beginners usually get into a lot of trouble. The number of comparisons necessary gets out of control in a hurry. I show a better technique.
Building an AI: Artificial intelligence is a topic in advanced classes in computer science. However, the AI problem in tic-tac-toe is easy enough for beginners to manage if you think carefully through the data problem.
My tic-tac-toe game is shown in Figure 13-10.
Creating the board
The best way to manage the user interface is to build a simplistic tile-based mechanism. (Look at the Miles and Miles of Tiles and Tiles section of this chapter for more on tile systems. The key to the tic-tac-toe game is a special sprite called a cell. Each cell represents a space on the board. It has three states (X, O, and blank). Clicking on the cell changes the internal state and (of course) the visual representation of the state.
Figure 13-10: A basic tic-tac-toe implementation.
The cell object is simply a subclass of the sprite:
function Cell(){
tCell = new Sprite(game, “blank.png”, 100, 100);
tCell.setSpeed(0);
tCell.state = BLANK;
tCell.images = new Array(“blank.png”, “X.png”, “O.png”);
tCell.checkClick = function(){
if (this.isClicked()){
if (this.state == BLANK){
this.state = currentPlayer;
this.setImage(this.images[currentPlayer]);
//change the player
if (currentPlayer == X){
currentPlayer = O;
} else {
currentPlayer = X;
} // end if
} // end if
} // end if
} // end checkClick
return tCell;
} // end cell
Here’s how the cell code works:
1. Create a currentPlayer variable.
This variable holds the value corresponding to the current player. The current player variable will rotate between X and O.
2. Assign constants for the states.
The three states are integer constants.
3. Create an array of images.
Assign images that correspond to the various states.
4. Create a checkClick() method.
This method will change the cell’s state appropriately. It will also change the currentPlayer variable so the next click will register for the other player.
5. Build an array of cells.
Once a single cell does what you want, you can build an array of them.
Setting up the visual layout
The placement of the cells on the screen is interesting. It may seem natural to use a two-dimension array for the tic-tac-toe board, but the nested loop structure can be cumbersome on such a small data structure, and treating the board as a 2D array doesn’t provide many benefits. Instead, I build this as a single-dimension array and use some tricks to get the visual appearance I want.
The cells are arranged like this:
0 1 2
3 4 5
6 7 8
To make them draw in the correct rectangular pattern, I use an old programmer’s trick to turn the single dimension array into a two-dimension visual structure.
Try dividing all the values in the image above by 3. You’ll see some interesting patterns. Every value in the first row (0, 1, and 2) yield zero (and some remainder) when divided by 3. Each element in the second row (3, 4, and 5) gives 1 remainder something, and each element of the third row produces a 2 remainder something. If you divide any of these numbers by 3 and convert the result into an integer, you’ll get the row number. In JavaScript, you can use this line of code:
row = parseInt(i / 3);
There’s another interesting pattern if you look at the remainders. All of the numbers in the first column (0, 3, and 6) are evenly divisible by 3, meaning they have remainders of 0. All the numbers in the next column (1, 4, and 7) have a remainder of 1, and the last column produces a remainder of 2. In other words, the remainder of division by 3 will give the column number. In JavaScript, the modulus operator (%) will produce the remainder of an integer division, so you can get the column number with a similar formula:
col = i % 3
The code for creating the cells uses these formulas to extract the row and column number for each cell, and then places the cell on the screen by multiplying these values by the cell width and adding an offset (just as I did in the tile-based world, because this is another tile-based world).
function buildCells(){
cells = new Array(9);
xOffset = 100;
yOffset = 100;
for (i = 0; i < cells.length; i++){
cells[i] = new Cell();
row = parseInt(i / 3);
col = i % 3;
xPos = (col * 100) + xOffset;
yPos = (row * 100) + yOffset;
cells[i].setPosition(xPos, yPos);
} // end for loop
} // end buildCells
Checking for a winning combination
It’s very easy for a human to tell if one player or the other has won a game of tic-tac-toe: Just look for three in a row. The computer doesn’t understand the concept of three in a row, and it needs to be taught. It’s possible to use a complex series of if statements to check for all the possible winning combinations, but it takes a lot of code to do this. With a little thought, you can simplify the process tremendously. Take a look at the following code fragment:
winningCombos = new Array(
new Array(0, 1, 2),
new Array(3, 4, 5),
new Array(6, 7, 8),
new Array(0, 3, 6),
new Array(1, 4, 7),
new Array(2, 5, 8),
new Array(0, 4, 8),
new Array(2, 4, 6)
);
The code simply sets up a two-dimension array. This array is a list of all the winning combinations. If the same player controls cells 0, 1, and 2, that player has won the game. Each row represents a different winning combination.
It then becomes easy to check for a winner:
function checkWins(){
winner = 0
for (combo = 0; combo < winningCombos.length; combo++){
a = winningCombos[combo][0];
b = winningCombos[combo][1];
c = winningCombos[combo][2];
if (cells[a].state == cells[b].state){
if (cells[b].state == cells[c].state){
if (cells[a].state != BLANK){
winner = cells[a].state;
} // end if
} // end if
} // end if
} // end for
return winner;
} // end checkWins
This code goes through the array of cells and checks each winning combination. If it discovers any combination with the same value (but not blank), the value in the cells indicates the winner of the game.
Adding an AI
The most common type of artificial intelligence for this sort of problem is called a heuristic algorithm. It’s a trick that allows the computer to quickly come up with a good solution while not guaranteeing a perfect solution. In general, heuristic algorithms work by assigning a point value to each possible move and then selecting the best move available.
The general strategy is to build an array of cell rankings:
cellRank = new Array(3,2,3,3,4,3,3,2,3);
The rank of each cell indicates the number of winning combinations that go through it, so cell 4 (the center cell) is the most valuable cell at the beginning of the game.
As the game goes on, the computer reevaluates the grid according to the following simplistic calculations:
1. If any cell is nonblank, demote it.
The only cells you should consider are those that are blank, so if a cell is already taken, subtract 99 from its cell ranking.
2. Look for partially completed winning combinations.
Step through each winning combination. If any two cells have the same value but the third is blank, add a value to the third.
3. Find the highest cell.
After going through all the combinations, loop through the cell rankings to see which is the highest cell ranking.
The tttAI.html program on the website (www.aharrisbooks.net) shows the cellRank heuristic and a hint for the next cell.
Improving the tic-tac-toe game
The tic-tac-toe game is reasonably complete, but it can be improved. Here are a few suggestions:
Implement a computer player. My version calculates the best cell for the computer player, but it doesn’t actually play. It’s relatively easy to have the computer player pick the best cell.
Improve the heuristic. While this heuristic will work, it could definitely be improved. It plays well, but it can be beaten. Learn its weakness, and see if you can improve on the performance.
Allow multiple plays. Right now the game must be reset after every game. Add a mechanism to replay, keeping track of the score. Look into the localStorage mechanism for how to add this feature.
Occasionally, I feel the need to indulge my “self-important computer science instructor” nature, and I give some technical background on things. These ideas are interesting but not critical, so you can skip them if you want. However, you might want to memorize a couple of them before you go to your next computer science cocktail party. You’ll be the hit of the party. 
