The main game loop is actually quite simple, as you can see here. Note that most of the functions called here will be examined after this, but I think the names are pretty clear, and you shouldn’t, I expect, have any difficulty understanding this code conceptually even if you don’t know all the details beyond the functions it calls just yet.

A few tasks need to be accomplished with each 100ms iteration of this method, beginning with moving the player. As you’ll see next, the keyHandler() method doesn’t actually move the player in response to keypresses; it only sets flags to tell us which way to move it. The move() method of the player is what looks at those flags and actually moves the player, but that’s coming a bit later.

The crystal and player game objects are animated, but that doesn’t happen by itself; you have to write code for that, and that code is inside the animate() method of those objects, so they get called next.

The same is true for the enemies, which is where that enemies array comes into play as it gives us an easy way to loop through the enemies and animate them. Enemies also have to move, of course, so their move() method is also called.

Next, things get a little more complicated because any time the player collides with an enemy, an explosion needs to occur. So, the wxGame.collision() method is called to determine when a collision occurs. Since collisions can only occur between a player and an enemy, you only have to pass a reference to each enemy to check the player against. When this function returns true, then an Explosion game object needs to be created. There can be more than one explosion on the screen at once (not because the player can collide with more than one enemy—it can’t because of the spacing between the enemies—but when the player brings energy back to the planet, all of the enemies explode simultaneously). So, the explosionCount member is used to number each explosion (and used to generate a unique ID for each). The explosion’s location needs to be offset a little from the player’s coordinates (the actual screen coordinates, that is, which the xLoc and yLoc attributes of the player tells you) because of the geometry of the graphics used. There’s no magic here; it’s just trial and error to get it to look like it’s centered on the player! Unlike the enemies, x and y in this case do mean real screen location (which means left and top style attributes correspondingly since all these game objects are just img elements, as you’ll see later).

In addition to exploding, the player needs to lose a few points too, so a call to the adjustScore() method does that, which accepts a positive number to increase the score or a negative number to decrease it. Also, any energy the ship is carrying should be cleared out, so player.energy is set to zero. This also means that the energy bar needs to be emptied immediately, so its value is set to zero. To update the chart, you need to alter its data, which is where the updateItem() method comes in. This takes an ID and a hash of values to set and updates a specific data item in the collection of data items the chart is rendering. Since you have only a single series in this chart, though, you have only a single data item, and it’s the one with an ID of energy, and its count property is the property that the chart uses to render itself, so it’s a pretty obvious call. One last thing needs to happen, which is that the player must be hidden until the explosion animation cycle completes, plus the player needs to be returned to its starting position. The hide() method takes care of the first part, and the aptly named toStartingPosition() takes care of the second.

Two more tasks need to be accomplished with each game loop iteration, and that’s to see whether the player is touching the crystal or the planet. The same sort of call to collision() as was done to check for collisions with the vermin is done, and a flag is set on the player for either condition, which will be used in some other code later.

The first line ensures that you have an event object because not all browser types pass one in to the handler; some require the handler to get it from the window object. The second line then uses that object to determine the key code of the key that was pressed or released. These two lines are relatively standard and nothing Webix-specific.

The switch statement then looks to see whether the key code is one of the four defined in the constructor corresponding to the four cursor keys. For any match, one of the dirXX flags on the player instance is set. As previously mentioned, these flags will be used in the player’s move() method, which you just saw is called from run().

Most video games, including this one, require the ability to detect when two images (two game objects) run into each other. For instance, you need to know when your player’s ship hits one of the enemy vermin. There are numerous collision detection algorithms, but many of them are not available to you in a browser setting because they require access to pixel-level data. For instance, checking each pixel of one image against each pixel of another, while giving 100 percent accurate detection, isn’t possible in a browser (at least not without using the canvas element).

Instead, a simpler method is available to you than what is used here: bounding boxes. This is a simple method that basically just checks the four bounds of the objects. If the corner of one object is within the bounds of the other, a collision has occurred.

As illustrated in the example in Figure 10-3, each game object has a square (or rectangular) area around it, called its bounding box, which defines the boundaries of the area the object occupies. Note in the diagram how the upper-left corner of object 1’s bounding box is within the bounding box of object 2. This represents a collision. You can detect a collision by running through a series of simple tests comparing the bounds of each object. If any of the conditions are untrue, then a collision cannot possibly have occurred. For instance, if the bottom of object 1 is above the top of object 2, there’s no way a collision could have occurred. In fact, since you’re dealing with a square or rectangular object, you have only four conditions to check, any one of which being false precludes the possibility of a collision.

This algorithm does not yield perfect results. For example, in this game, you will sometimes see the ship “hitting” an object when they clearly did not touch (most obvious with the asteroids). This is because the bounding boxes can collide without the object itself actually colliding because the graphics aren’t all themselves perfect squares or rectangles. This could only be fixed with pixel-level detection, which, again, is not available to you. However, the bounding boxes approach gives an approximation that yields “good enough” results in many cases, including this one, so all is right with the world.

The actual code behind the collision() therefore becomes pretty straightforward.

If the player isn’t visible, as determined by examining its isVisible attribute, or if the player isn’t visible, then there’s no need to check for a collision because game objects are only ever not visible when they’re exploding. After that, you get the values to be compared, which means the coordinates of the top, bottom, left, and right bounds of the player and the test object. Finally, it’s just the four simple checks described to tell you if a collision has occurred.

Transferring energy from crystal to ship, or from ship to planet, occurs every time the animation frame of the player changes. Or, more precisely, it can occur because whether it does occur or not depends on whether the ship is in contact with either object (and whether there’s energy to transfer, of course). As you’ll recall, the animate() method of the player object is called with every tick of the main game loop, which is the run() method, and since the webix.wrap() method was used to intercept the call to animate(), that means transferEnergy() will also be called with each game loop iteration.

The first branch of the if statement covers the case when the player is touching the crystal , as the player.touchingCrystal flag denotes. It also accounts for when the player touches the crystal even though their energy is full, in which case you skip the work here too. If both conditions are met, though, then with each tick of the game loop you add 5 to the player’s energy stores, and you also set the value on the bar chart to the player’s current energy value, which causes it to fill up. When the energy reaches 100, then the crystal is randomly repositioned. Why the while loop, you ask? That’s because each call to crystal.randomlyPosition() could result in the crystal being positioned still in contact with the ship. You don’t want that. So, the while loop will keep calling crystal.randomlyPosition() until it returns false, which means the crystal is not in contact with the ship.

The second if branch is for when the player is touching the planet. There, the player’s energy is reduced by 5 each iteration, and when it hits zero, it’s the planet this time that needs to be repositioned. Then, all the enemies need to explode, which is what blowUpAllEnemies() does. The player has to score some points here, so adjustScore() is called. Finally, the energy bar has to be cleared again, so its value is set to zero, as previously described.

In fact, the only interesting bit here is the use of setHTML(), which is a method of the ui. template component that allows you to set any arbitrary HTML in the component you want.

This works a lot like how the explosion is created when the player collides with an enemy, but here you need one explosion per vermin. Each is positioned according to the location of the vermin (and it doesn’t really need those adjustments like was done for the player explosion because the geometry of the graphics lines up pretty well without it). Every enemy is hidden before its corresponding explosion is created, and it is also moved back to its original starting position via the call to its moveTo(), passing it the startingX and startingY members attached to each enemy (which are populated when the enemy is created, as you’ll see shortly).

Now, that’s great for blowing up the vermin, but the game has to continue after that, which means they need to be shown again. How do you do that? Well, in the interest of showing you another new Webix function, I’ve gone with usage of the webix.delay() function. This works a lot like the JavaScript-standard setTimeout() function, but with some additional features. First, this function takes the code you want to execute, which here is simply an iteration over the array of enemies, calling show() on each. The second argument is what scope that code should execute in, meaning what the this keyword points to when it executes. The third argument is an array of arguments to pass to the code, which is just an empty array here since you don’t need to pass any. Finally, the last argument tells webix.delay() how long to wait until calling the code, in milliseconds. Since there are five frames of animation for an explosion and since each frame takes 100 milliseconds (because that’s how long there is between main game loop ticks, and the frames are flipped from there), that means you have to wait at least 500 milliseconds before showing the vermin again. I doubled that for good measure, so 1,000 milliseconds, or one second, is it.

As you saw, frameCount tells you how many frames there are, so the code loops with that value. Each animation frame winds up being a separate DOM node, and since you need to be able to access each, that means each must have a unique id, so the id value is constructed using the baseName and the loop count at the end. There’s also an inConfig.n value that is optional and is inserted even before the frame number. This is specifically for explosions since there can be more than one of those at a time, so each needs to have an extra value in the id, and that’s where inConfig.n comes into play. So, for example, the player will wind up with two nodes, one with an id of player1 and the other player2, and an explosion will have an ID of explosion11, exposion12, and so on.

Speaking of creating a DOM node, that’s exactly the next step! The webix.html.create() function lets you do that easily. The first argument is the type of element to create, an <img> element in the case of game objects. As you can see, that previously described unique id is included in the second argument, which is an object containing all the attributes associated with the element. These are any attributes that an <img> take can take, so src is one that is clearly necessary! The baseName again comes into play here to construct that src attribute value (so img/player-1.png, for example).

Once the element is created, you can set some style attributes on it. (Yes, you could do this by specifying a style attribute in the second argument to webix.html.create(), but that means building a string, and I find this style of coding it cleaner.) The element is positioned absolutely, and its left and top attributes are set using the inConfig.x and inConfig.y values passed in. You also store those as xLoc and yLoc for easier access later (which saves you from having to access DOM node attributes, so it’s a little faster this way). The game object could be hidden initially via the inConfig.hidden attribute, and if so, then display is set to none. There’s also a concern with z-index in that the player should always be on top, even if it’s not created last (which it can’t be because some other code depends on it having been created earlier). It’s only a concern for the player, but being able to pass inConfig.z to set zIndex lets you deal with it consistently in all cases.

Next, you have two new Webix functions. First, all you’ve done so far is create an <img> element in memory. It’s not actually on the screen at this point. In fact, it’s not even in the DOM yet. So, you need to insert it into the DOM, and that’s where webix.html.insertBefore() comes into play. You pass this function the object to insert, then a reference to the DOM node to insert the new one before (its “sibling,” so to speak), and then a parent node if the sibling doesn’t exist. In this case, you just want to append the element to the playfield node, which is passed in as inConfig.playfield, and not actually before any other element, so that’s why null is the second argument. The third kicks in, and you get an append, as the last child, of the playfield node.

Finally, you need to have a reference to every <img> element created for each animation frame. While you could have gotten that reference from the call to webix.html.create(), since it returns the reference to the new node, I instead decided to use webix.toNode() to show you something new. This function allows you to get a reference to any DOM node by ID. Here, the reference is stored as an attribute of the game object instance, with each frame being a new attribute named frameX, where X is the frame number. That will allow later code to access these DOM nodes quickly and easily. In fact, the next thing you’re going to look at makes use of that!

Animating a game object is fairly simple and, as you know, is triggered by a call to each object’s animate() method from the run() method.

First, you abort if the object isn’t currently visible because why do the work of animating it if it can’t be seen? If that check is passed, then the frameSkipCount member is increased, and until it equals the frameSkip value , no animation is done. This means that a certain number of main game loop ticks can be skipped before an object’s animation frame is changed, effectively slowing the animation.

Once it’s time to animate, the first thing to do is to hide the current frame. Remember that each frame is a separate DOM node, so only one can be showing at any given time for a given game object. The attribute name is formed using the currentFrame value, and from there it’s a simple matter of setting its display style attribute to none.

Next, currentFrame is bumped up. When it equals frameCount, then it’s time to restart the animation cycle. There’s also the opportunity for some code to be executed when the animation cycle completes via a callback attribute of the game object that can optionally be set. This is specifically for explosions, as you’ll see later. When the callback function is called, it is passed the inCollection argument that is passed to animate(), which is only ever done for explosions and is the collection of all explosions (and again, why that is will become apparent when you look at the Explosion class).

Finally, the new animation frame is shown by getting a reference to it through those frameX attributes I described earlier. Setting the style attribute to an empty string, which is the default for that attribute, makes it visible.

It’s just a matter of setting the style attribute of each animation frame <img> node to an empty string and of course marking the object as visible too.

Where there’s a show() method, there’s likely to be a hide() method, and you won’t be disappointed to know that there in fact is!

I’m gonna go out on a limb here and say that doesn’t need an explanation.

First, a random number between 70 and 730 (inclusive) is chosen. These values result in the object never going off either edge of the playfield area. Once you have a location, every animation frame is hidden and then moved to the new location. Only the left style attribute needs to be changed since this is only randomizing the horizontal location; the vertical location never changes.

Once that’s done, you need to see whether the object now collides with the player. If not, then animation frames are all shown (which doesn’t matter for the planet since there’s only one frame, and for the crystal this will be undone with the next game loop tick and only a single frame shown). The collision result is returned so that those while loops you saw earlier can kick in and randomlyPosition() will be called again (and again, and again, and…) until a noncollision location is determined. This isn’t the most efficient way to go about doing this, but it’s pretty simple and does the job well enough.

This simply takes in X and Y values, which are set as the left and top style attributes, respectively, of every animation frame for the object. Its visibility isn’t impacted, there are no worries about collision, and it’s just an immediate move. This is primarily present for the enemies, as you’ll see soon.

That done, your look at the GameObject class is concluded. Now let’s move on to some specific game objects, starting with the Crystal class.