Cubicle Ninja

Finally we get to part 6 of the game creation tutorial / learning endeavor. Reality conspired against me to cause this post to be delayed, but I got here all the same. Today we’re going to dig into creating goodness, gracious great balls of fire for our hero to throw around in a devil-may-care fashion. The image we’ll be using for our fireball sprite is one I found somewhere ages ago (honestly, no clue when or where I got it) and slightly modified to meet the needs of this game. It follows the same pattern as our other animate sprite (for the hero / villains) and is just a sequence of “keyframes” for the sprite with a transparent background.

Several of the pieces for the fireball object will be directly duplicated from our hero object (because, really, fireballs and people share, like, 95% of the same DNA sequences). We will have one main new concept that will be introduced: destroying / recreating an object. We want to ensure that when our fireball hits a wall, enemy or the edge of the world it is destroyed to free up the memory allocated for it (and to make sure invisible fireballs don’t keep roaming around all higgledy-piggledy).

As I mentioned, thee fireball object is going to be almost identical to the hero object. We’ll adjust the width and height to be 16 instead of 32, change the speed a little and (the biggest change) give it a destroyed property that will be set to true when it goes off the screen:

Much like we did for the enemies and the rocks, we’re going to need a base fireball object that we will load the image into in order to speed things along as we are playing. At the top, underneath var baseEnemy = null; we’ll add in:

And we need a new function to initialize the base fireball object (it’s actually only two lines of code, but we’re doing it for consistency since we did it for all the other objects):

Now just add a call to initFireball(); inside the $(window).load(function() area right after initEnemies();.

Once we know what a fireball is and have the base all set, we’re going to make it up so that our hero is only allowed to have one active fireball in play at a given time. We’ll start off by just adding a new property to our hero object called “activeFireball” and a boolean “shooting” variable. Inside our function heroObject() add:

Now we’ll make a slight adjustment to our key capture logic to trap a press of the spacebar (we’ll add logic into our hero later to check for this in order to Hadouken!). At the top of the keydown and keyup handlers we’ll add a check to see if the spacebar was pressed. This is the code for the keydown event, the keyup event is the same code except we set the value to false:

Now we’re all set capturing the spacebar (why the spacebar, you may ask? Because that’s what it always seems to be in games, just accept it). The next piece is to adjust our hero update method to check for the spacebar being pressed and, if it is, start up a fireball object. This code will go inside the update method, just above the switch statement for the hero movement:

The steps we are having the code perform are: check if the spacebar was just pressed — if so, remove the spacebar from the keys array (we do this because we want the movement switch to go based upon the last arrow key that was pressed) and check if the hero currently has an active fireball — if not, create a new fireball object and position it based upon which way the hero is facing then draw it to the screen.

The last change we have to make to get our fireball moving on the screen (but not finished since it will just go on forever at this point) is to add the logic into our function gameLoop() right after the call to hero.render();:

When you run the code at this point you should be able to press the spacebar and have it shoot off a fireball. The fireball will be destroyed when it goes off the screen allowing you to shoot another. At the moment, the fireballs will pass right through the rocks and enemies and that just will NOT do! We’ll fix that glaring oversight by adding calls to the collisionCheck inside the fireball update method. For the rocks we’ll take the code we already have in place within the hero object that loops through and checks for collisions. We need to make a small tweak to it so that it tells the fireball to bugger off when it has a collision

Great, now we can toss fireballs around the map and have them be destroyed when they go off screen or hit a rock. Of course, the REAL fun comes from being able to shoot the enemies. To accommodate the need for wanton destruction and the killing of cute, onscreen pixels, we need to add a new property into our heroObject (remember the heroObject is used for both the hero and the enemies). Right below the this.shooting = false; line we added earlier we’ll add in

Next step is adjusting the fireball update method to also iterate through all of the enemies to check for a collision. We’ll add this code after the loop through all of the rocks:

That tells it to destroy both the enemy AND the fireball when we have a collision between the two. We have one final piece of the puzzle and that is to update the gameLoop to have it remove the enemy from the game if it is destroyed. We’ll replace the foreach loop through the enemies within the gameLoop with the following:

And that does it. You can know wield flaming balls of death (well flaming ball of death since you can only have one at a time) that will destroy enemies and disappear off the screen. This post covered a fairly large amount of changes, so if anything doesn’t make sense feel free to let me know. Here’s a screenshot of a fireball in action.

And, as always, the link to the demo for this code

I know I promised goodness gracious great balls of fire in part 5…but I changed my mind. I talked with a couple friends and they pointed out that it was a little annoying that the game was a fixed size and just sat there at 800×600 no matter how big they made the screen size / browser window. To remedy that, this post is going to be step through the process of implementing scaling into our context rendering. Fair warning, I have never done this with the HTML5 / JavaScript objects and haven’t even done it with DirectX for years now. This may not be the best way to do it! That having been said, this method seems to work for me in all the major desktop browsers I tried (Safari, Opera, IE 9, Firefox, Chrome) but if you know of a better way to do it, please let me know.

I’m going to assume that if you’re reading part 5 of the series you’ve already at least looked through part 1, part 2, part 3 and part 4. If you haven’t, I highly recommend you at least familiarize yourself with them somewhat or you may get lost. Then again, you may already know how to do this and just came to read my blog and mock me for the stupid decisions I make as I’m learning this stuff…I just made myself sad.

Back on topic now. The concept of scaling isn’t all that complicated in reality. What we want to do is tell the game that we want the resolution to be 800×600 but that we want that to stretch (or shrink) to fill all of the screen real estate the browser has available. Previously we had created two variables (gameW and gameH) that held the dimensions of our game and everything was driven off of those. In order to get our scaling working properly we are going to expand from those two variables up to eight different variables:

As you can see by the comments (go go comments) the gameW and gameH variables are now going to be holding the “true” dimensions of the game window (browser). The baseW and baseH variables are our static variables that tell the game what we want the resolution to be (feel free to change those around and see how things change later). Variables renderW and renderH are driven off of a comparison between the gameW/gameH and the baseW/baseH and will be used in our actual render methods for the objects being drawn to the screen. The scaleX and scaleY variables do just what you’d expect, they hold the scale ratio between what we want to show and what screen size we actual have.

There are a couple different ways I tried for doing this:

1. Keeping it always at the base resolution and centering it in the browser — I didn’t go this route because it wasn’t really any improvement over doing nothing at all
2. Maintaining a static aspect ratio and scaling to fill the window — this looks nicer, in my opinion, because the rendered objects are never stretched or squashed, but has the draw back of things not fitting properly if the window is resized to a different aspect ratio than at load time
3. Not maintaining the aspect ratio and scaling to fill the window — this can cause objects to be squashed or stretched if the browser window is not of a size that keeps the 800×600 ratio, but things always fit properly on the screen

In the demo we’ll be implementing both 2 and 3 and providing a checkbox so you can toggle between the two methods. I’m not 100% sure which I like best of all, so I’ll wait and see if I get any feedback about which one other people like most and go forward with that one when we add the fireballs (I’m going to do my best to get that in part 6!).

As I mentioned at the start, we’ll be using the renderW and renderH variables for rendering out our objects. Because of this there are a couple changes we need to make. In each of our object methods we need to update the this.x and this.y assignments to use renderW/renderH instead of baseW/baseH. For the staticObject() we only need to change the assignment lines since it has no update method:

In the heroObject() we’ll change the x/y assignments:

We also need to change the code in the update() method for the heroObject that handled wrapping around the screen:

Another change is required to our initRocks() function because we had the logic in place that calculated a new x/y position for each rock when there was a collision:

And the final change is inside the gameLoop to our clearRect call

The next bit of code we’ll put in will be a new function that will be used to calculate the values for the new variables we added at the top. I set this up to accept a parameter that determines whether or not we want to maintain the aspect ratio or not. If we want to maintain the aspect ratio then we take the following steps: determine what our current width-to-height ratio is, set our gameW and gameH, set our renderW and renderH using a ratio calculation to keep it constant, set our scaleX and scaleY to the same value since the ratio is being maintained. If we don’t care about maintaining the aspect ratio then our steps are simplified (and have no “real” logic): set our gameW and gameH, set our renderW and renderH to the baseW and baseH values, calculate our scaleX and scaleY values. The scaling function will look like this:

We’re going to need to adjust $(window).load(function() to make a call to the new scaling function, but first let’s go ahead and add a checkbox to the html file so we know if we are maintaining the aspect ratio or not. These lines can go anywhere inside the <body></body> since we are absolutely positioning it:

With that out of the way we’ll dive into the $(window).load(function() changes. Prior to the call to initCanvas() we need to calculate our scaling information and immediately following the initCanvas() we’ll save out the context objects and apply our scaling to them before rendering anything to the screen. The new $(window).load(function() will look like this:

At this point you should be able to run the game and see it fill the entire screen, stretching / squashing the objects as needed to do so. You’ll most likely notice that resizing the window has no effect. That’s easy enough to fix by hooking to the window resize event, but there are a couple things that could end up biting us in the patootie if we don’t watch out. We don’t want the resize event to reinitialize everything, because then our hero, enemies and rocks will all be regenerated and positioned differently on the screen. We’ll create a new function to handle resizing that will do the following: recalculate the scaling, reset our canvas width and height, clear our the context objects, restore to the saved context information, re-apply our scaling and re-render all of the objects. We will not reinitialize anything entirely because we want to keep the same objects we had prior to resizing:

Initially, I just wired the call to this function directly into the window resize event…that ended up not being the best idea. Firefox and Chrome (maybe others) trigger the resize event constantly while the window is resizing and cause a lot of extra calculations to be done if we call the resizeHandler directly from the event. Instead I created a simple customTimeout function that we can use to simulate a “resizeComplete” event. The customTimeout will make use of a timer object and the base setTimeout function to accomplish our goals:

Now to wire that up to the resize event we use a single line of jQuery

Voila, we have a “fullscreen” game that will adjust and resize the objects as the browser window is resized. Pressing F11 and going into fullscreen mode with your browser should cause the game to truly be fullscreen, but any resize should work as well (even making it really tiny).

Hopefully I managed to have this all make sense and didn’t do anything incredibly stupid. If I did, please don’t hesitate to let me know and I’ll update the post accordingly. Here’s what we should have at this point (I resized the window down to a fairly small size):

Here’s the link to the demo for this code.

In part 1 I went through the basics of setting up the canvas and adding a simple sprite to it. Then part 2 got through handling keyboard controls and animating the hero character. Most recently, part 3 added some scenery objects and the basics of collision detection. We now are to a point where we can leverage the framework we’ve created to add in some bad guys to roam around the canvas. We’ll make some modifications to our heroObject in order to allow it to accommodate NPC characters as well as the player controlled hero. Because I’m all for clichés I’ll be using the same sprite we used for the hero character…only making it evil.

We’ll start off with similar functionality that we used for our rock objects in part 3 and add a variable at the top for the number of bad guys we want to have on the screen at one time, an array to hold them all and a base image object to hold the sprite image.

The next part is to create an initEnemies function that will combine elements of the initRocks and the initHero functions. For each enemy we want to create we have to make sure it doesn’t collide with the hero and also that it doesn’t collide with any of the rocks that are on the scene.

We need to make a call to the initEnemies() function inside of the $(window).load(function() after we initialize the rock objects. This takes care of the initial creation and rendering of the enemies. Since we reused the heroObject (which we should *really* rename at this point to mobileObject or something, but we’ll get to that later) the enemies are drawn on the same canvas as the hero. Keep in mind that we are erasing that entire canvas each time through the game loop so we need to make sure we redraw the enemies each time. We do that by adding a small loop after our call to hero.render(); in the game loop:

At this point you should be able to run the game and have a screen with pseudo-randomly placed rocks and bad guys with none of them stacking on top of the other. The next piece will be to adjust the initEnemies() to get them started moving in a random direction and also to update the game loop to properly update them on the screen each iteration through the loop. We’ll tackle setting them up moving in a random direction first, and we do that by adding a single line above the call to render inside initEnemies(). We have 4 directions we are able to move and the heroObject is controlled by the values in the keys array (37 = left, 38 = up, 39 = right, 40 = down), so we will set the keys[0] value randomly to one of the 4 valid directions.

Before that change will make any difference we need to modify the game loop so that before it renders out each enemy it calls the update method for it

Running the game at this point you’ll notice that the enemies are basically very poorly developed roombas and will just walk in a single direction until they hit a rock and then they just repeatedly slam their heads into it(luckily, reusing the heroObject means they already have our collision detection logic without having to do anything additional). We’ll slightly upgrade their AI and allow them to turn away from a rock any time there is a collision. This is also done in the game loop after the call to the update method, and before the call to the render method.

This works well enough for the most part, but we have an issue if one of the enemies starts walking down a path that doesn’t contain any rocks…they just keep going ad nauseum. To correct that we’ll need to add a new property to the heroObject and then another test inside the game loop for the enemies (again, before the call to render). The property we’re going to add will be called “lastKeyChange” and it will be used to check how long it’s been since the enemy last changed movement directions. We can set whatever type of limit on that we want before we force a direction change. Inside the heroObject add the property underneath the this.collision = false; property

Then update the loop to make use of that property

At this point you should be able to run the game and have all the randomly placed rocks from before in addition to the new enemy mages wandering around on the screen bouncing off the rocks and pseudo-randomly changing directions. The next part of the series will get into allowing the hero to throw fireballs to kill the enemy mages and adding in some point tracking for the game.

Here’s the link to the demo for this code.

Having completed part 1 and part 2 of the tutorial you should now have a fancy green screen with a little red wizard that can wander all over the place. Now we’ll start getting into a bit more of the nitty gritty and work on adding in some scenery (for now we’ll just add some admittedly pretty pathetic looking bricks ) and providing some collision detection logic to make it so our hero cannot walk through the bricks that we add. Also, since the code is going to start getting a bit more complex, we’ll follow general practices and separate things out so that each function performs one main task instead of cramming it all together.

When you’re working with games in JavaScript you have to carefully weigh the cost of every action you perform in your game loop. Since we opted to clear out the entire canvas in each iteration, adding our static objects (scenery) to the mainCanvas object would force us to redraw all of the bricks each loop. Obviously, we don’t want to do that so we’re going to adjust our main HTML page to have two canvases that are stacked on top of each other (using CSS positioning and z-index). Here’s what our new HTML file looks like:

Nothing really fancy here, we added a new canvas with an id of “baseCanvas” and then wrapped both canvas elements in a div wrapper. The style tag handles adjusting the CSS on the canvas elements so they are stacked on top of each other with the baseCanvas (the one where we will draw our static scenery) on the bottom of the stack. The clever among you probably already realized that we’re going to have to make changes to our gameLoop even though we’ve stacked our canvases this way. We no longer are going to want to fill the mainCanvas with the green color because that would hide all of the scenery on the base canvas. Instead we are going to adjust our gameLoop code so that it just completely empties the mainCanvas each iteration through the gameLoop.

We’ll change this

to this

We’ll also need to adjust how we initially set up our canvas object in the $(window).load(function() so we’ll use this opportunity to pull things out into a separate function. Above the $(window).load(function() add a new function definition named “initCanvas” and then delete all of the canvas and context references from the $(window).load(function(). Before we fill out the initCanvas function we need to add in two new variables at the top of our JavaScript file so we can access our baseCanvas and the context related to it

Once those are in place, here’s the code for the new initCanvas function:

You can see we are getting our references set up for the baseCanvas and the context related to it and filling it with our dark green color. Since the baseCanvas is now going to contain the background and the scenery we no longer have to worry about filling our the mainCanvas other than setting its width and height. Running the code at this point should give you a result that looks exactly the same as what we had at the end of part 2.

While we’re on the cleaning up code kick, let’s go ahead and move the logic that instantiated our hero out of the $(window).load(function() and put it into an initHero function. The new initHero function and the resulting $(window).load(function() should look like the following:

There we go, the annoying organization bits are out of the way we are free to get started on the actual new functionality. We need to add a few variables to the top of the JavaScript file to accommodate the changes we are going to make: we want a variable to tell the game how many rocks to load into the scene, an array to hold all of the rock information and, since we’re going to be reusing the same image object multiple times, a base image object for the rock.

Before we start working with those variables let’s define what our rock object actually will be. We’ll do this in a very similar fashion to how we did our heroObject except much more simply since the rocks don’t need to move/update. Because this same object could be used for any static object you add to your game we’ll be calling it “staticObject” (I know, I’m very clever). We need to know the width and height of the object, its x and y coordinates, the image to use for the object and then have the ability to render it to the baseContext.

You can see that it is pretty much a copy and paste of the code we used for our heroObject except we modified the render to draw on the baseContext instead of the mainContext. We don’t need to worry about an update method for this object since they won’t be moving around on the screen or getting updated in anyway after they are initially rendered. As we did for our hero and our canvas we’re going to create a new initRocks function that will be a close cousin to the initHero function. We’ll load the image for our brick into the base and then use that to render each of the rocks we want in our scene:

The only thing left to do after that is to add a call to the initRocks function inside of our $(window).load(function() which leaves us with:

Running the game at this point will give you a pseudo-random layout of rocks on the game grid with the hero object on top of them able to walk around. Each time you refresh the screen you’ll receive a different pattern for the rocks (sometimes with the hero appearing on top of one). Assuming you’ve made it this far, the next step (and biggest leap forward for our game) is to add in some basic collision detection between the heroObject and the staticObjects. To that end we’ll first add a new property to both the heroObject and the staticObject that is simply a boolean letting us know if we have a collision or not

The next step is to create the method in the heroObject that will check for a collision with any of the static objects that we have loaded into the scene. Once we have the method in place we’ll call it at the bottom of our update method and, if we have a collision, we’ll undo the movement that we would have made. The reason we do this after we calculate the movement for the update is to make sure we catch the collision event prior to drawing the hero inside of the object. If we did it at the top of the update method then the hero would be allowed to take one step inside of a rock and would then be stuck there and unable to move any direction. The collision method is fairly straightforward and just takes a parameter of another object and tests to see if the hero’s x and y coordinates are inside the object:

In order for our update method to be able to “roll back” a movement we’ll need to store out the current x and y coordinates for the hero (and also reset its collision property. At the top of the update method add the following lines:

And now, the pièce de résistance, we add a loop at the bottom of our update method (this check is the very last thing, it goes after your check for looping around and / or blocking movement at the edge of the screen) to iterate through all of the rocks in the array and check to see if we have a collision. If we find a collision event then we reset the x and y coordinates of the hero:

Running the code at this point should provide you with something that is actually starting to resemble an old school sprite-based RPG. You have your little keyboard controlled hero, a “maze” of rocks and some collision detection. Before we wrap up part 3, we’re going to make one more adjustment to the code. As I mentioned above there’s nothing in place to prevent the hero from loading “inside” one of the rocks which would make that game start from an unplayable state since the collision would instantly be true and the hero could never move. To prevent that from happening we’ll modify our initRocks function so that it checks to see if the rock is “under” the hero object and, if so, will re-generate the x and y coordinates for it. The new initRocks function looks like this:

Coming up in part 4 of the series will be adding in some “Bad Guys” that will wander around the maze causing all sorts of havoc (actually they won’t do anything other than randomly wander around the maze and use our collision detection).

Here’s the link to the demo for this code.