Creating the Deck class

Last section we created tests for building our deck class. Now we are ready to create a deck class. Initially we will create the code within the testDeck.html file but once it is functional move the code into the Deck.js file so it can be used by our various card projects. While it is certainly possible to create the code entirely within the Deck.js file and import that file, for prototyping it is often faster to write the code within the test file and iterate over the code before moving it to the appropriate class as during prototyping the structure of the code may change multiple times so keeping it outside of the main code-base until it is stable can make maintaining the project easier.

This class needs to hold 52 cards in a deck, deal out those cards, and shuffle those cards. First, we are going to need to create the constructor function for this class. This will just create an array for itself to hold the deck and fill that array with in-order values. We also set the index for where we are going to grab cards to the top of the deck.

spelchan.Deck = function()
{
this.cardArray = [];//new Array(52);
for (var cntr = 0; cntr < 52; ++cntr)
this.cardArray[cntr] = cntr + 1;
this.nextCardIndex = 0;
}

This means that we now have a deck of cards but running the test will still fail. While the card ids are in the deck, the deal method is not dealing them out! Dealing out a card is simply the matter of returning the card at the nextCardIndex while increasing the index.

spelchan.Deck.prototype.draw = function()
{
var rv = this.cardArray[this.nextCardIndex];
++this.nextCardIndex;
return rv;
}

Running the tests now show us that we are getting there but the shuffling is not sufficiently random enough to pass our test. This is because we are not shuffling the deck yet. We are going to need a way of shuffling the deck. Think about the different ways to shuffle a deck. There are many ways of shuffling, but most of them are inefficient as far as the computer is concerned. What our goal is, simply stated, is to make the cards in the deck appear in a random order. I realized that taking each card and swapping it at random with another card would be a very good way of shuffling as the computer can do this blindingly fast with really good results. While I came up with this algorithm on my own, my Algorithms teacher did tell me that I was not the first person to think of this and that this is like the technique that shuffling machines use.

spelchan.Deck.prototype.shuffle = function()
{
var cntr, temp, rnd;

for (cntr = 0; cntr < 52; ++cntr)
{
rnd = Math.floor(Math.random() * 52);
temp = this.cardArray[cntr];
this.cardArray[cntr] = this.cardArray[rnd];
this.cardArray[rnd] = temp;
}
this.nextCardIndex = 0;
}

Now when we run the test we see that all the tests have passed. We are now ready to start planning the tests we will be needing for a video poker game. There are other things that we could probably add to this class, but I have discovered over my years that it is easy to refactor and to add things later, especially if you have a testing framework to verify your changes don’t break anything. One tenant of Extreme Programming is to only write the code that you need. We have all that we need for video poker, so next chapter we will start working on a video poker game!

Test Driven Deck

While having a plan for testing your code is important, Test Driven Development (TDD) takes this to another level. The idea here is that you write automated tests before you start writing the code. When it is practical to do this, it is an incredibly good way of creating code. Planning tests gets you thinking about the code you are going to write – hopefully with an idea of the fringe cases that you are going to encounter. Writing the tests give you something to check the code against. All tests should initially fail, with a successful test likely indicating either an error with the test or an error with the test plan.

You then write the code and run it against the tests trying to pass one test at a time. Once you have passed all the tests and no missing tests have been discovered, you are finished the code and can start planning the tests for the next piece of code that you need to write. Having automated tests also means that it is easy to have the tests running frequently while you do other things and if something breaks then you know right away and as it is likely what you (or someone on your team) is currently working on, it will be trivial to fix the bug! Remember that in general the quicker you can find a bug, the less it will cost to fix it. This cost is in time, but can also be in money if the bug is in a production version and you have marketing and patching costs in addition to the cost of finding and fixing a bug.

We have a card class that can display any card, so what we need next is a deck of cards. This deck needs to be able to be shuffled and we need to be able to deal cards from the deck. So, how would we test such a beast?

In a sorted deck, the cards should be from 1 to 52 so simply drawing cards from a sorted deck and making sure they are in sequence would solve this problem. A shuffled deck, however, has two issues that we need to check for. First, we want to make sure that all the cards are in the shuffle (that we haven’t duplicated cards losing some cards or other similar problem). Next we want tom make sure the cards are not in order. Simply checking to see the card is different from its position in the deck will not work as we would expect that at least some of the time a randomly shuffled card would end up in the proper deck position. A good shuffle would have at least half the cards in a different position so simply counting how many cards don’t match would suffice most of the time.

As the deck class can be written without the card class, as it uses card IDs and not instances of cards, it is possible to write the deck class in its own html file which I called deckTest. This starts off with your typical html5 boilerplate followed by a simple version of the Deck class with none of the necessary methods implemented.

test results go here

Now some of you may have noticed that there is a lot of test code here. This is the downside to test driven development. You will often end up with test code that is the same size as the code that you are testing, and sometimes even larger. The plus side is that you know your code works within the testing parameters and if you refactor or change code you will be able to check to make sure that nothing you have done is broken. Manual testing could have been done with a lot less code. As always there is a trade-off that must be made. In a solo environment, and possibly a small team, manual testing may be adequate and may be productive enough. As you start to get to larger teams, people inadvertently mucking up other people’s code happens a lot more often than you would expect.

Chapter 7 Overview

One nice feature of card games, is that once you have created a card game you are able to take advantage of existing assets and code to handle the cards so that creating other card games in the future is easier. In this chapter we are going to take advantage of this in two ways.

First, in ``Creating the Card Movie'' we are going to create a card movie. This movie will have frames for all the cards in a deck and will be able to display any specified card. While fairly simple to build, creating a deck of cards is a time-consuming process. Thankfully, we only need to do it once. After the card movie has been created, you simply need to drag it into the new Animate CC project to use it in other card games. You could also place it into a common library.

Next we are going to create some JavaScript classes. For the most compatibility, which probably is not that big of a deal as most browsers in use support ECMAScript 6 JavaScript code, we are going to use the older and most compatible way of creating classes. In ``Creating the Card Class'' we create the class for handling the cards while in ``The Importance of Testing'' we test this class.

Test driven development, which is a very common practice now, does things the opposite way so in ``Test Driven Deck'' we create the tests for a deck class and with the tests ready to go actually create the deck class in ``Creating the Deck Class''

Once we have these classes created we will be able to build our Video Poker game.

Losing and Winning

In the previous section we introduced the BSoD. This leads to the problem of what to do when the player loses the game. My first thought was to have the BSoD claw the player to death. This would reflect the feeling you get when you have an hours worth of unsaved work and the real blue screen of death shows up. Not that I’ve ever had that happen to me as I always save my work frequently. Mind you, the reason I always save my work frequently is because of learning what losing hours of work because of a computer crashing feels like.

Having someone being clawed to death is not really appropriate for a family friendly game so instead, I decided to have a bit of fun and generate a nice error message.

There is a button on the screen which returns the user to the title screen that we will be creating in the next section. To have the button do something we have a method in our Nightmare class for dealing with returning to the title screen. This method is called using nightmare.registerTitleButton(this.losecon_btn);

spelchan.Nightmare.prototype.registerTitleButton = function(btn) {
console.log("registering toTitle called! " + btn);
this.toTitleButton = btn;
this.toTitleHandler = this.toTitle.bind(this);
this.toTitleButton.addEventListener("click", this.toTitleHandler);
}

spelchan.Nightmare.prototype.toTitle = function(e) {
console.log("toTitle called!");
this.toTitleButton.removeEventListener("click", this.toTitleHandler);
this.stage.gotoAndPlay("Title");
}

This code simply sets up a button that is passed to it to call an event handler that simply returns the game to the title sequence.  To remove an event listener, however, you need a link to the event that is to be removed. Binding objects end up creating something new so to properly remove the event handler we need to keep a reference to the binded version of the handler. The actual handler code simply uses this binded reference to properly remove the event handling reference and then goes to the title sreen frame.

Now that it is possible to lose the game, perhaps it would be nice to allow the player to win the game. The winning scene was designed with two purposes in mind. First, as a distinct way of showing the player that they have completed the game. Second, to preview the next episode of the game. The number 666 has certain significance with my upbringing and to this day I still consider that number to be a bad omen. As you can't have that number on a clock, at least not legitimately, I opted for 6:36 for the time. The code for handling the “To be Continued...” button, as with the lose screen, is simply a call to nightmare.registerTitleButton(this.wincon\_btn);

Now we just need the title and intro screens and we are finished.These will be completed next fortnight which will conclude this chapter.

Enter the Nasty

To add a bit more pressure on the player, I have a villain that pops up after the player has stayed in the room too long. Being a programmer, the first villain that came to mind is the dreaded Blue Screen of Death that occurs on Windows machines. Linux and Macintosh OS X don't have this problem (and are extremely stable operating systems) but most people have windows, and a lot of my programming happens to be for Windows machines. To be fair to Microsoft, the blue-screen problem has largely gone away.

In addition to the BSoD image, we also need a movie that controls the BSoD. This movie consists of nothing for the first few frames (labeled hide) with a stop on the second frame. There is also be a block labeled show which is a two second sequence of the BSoD appearing. For control purposes we have the button code in the previous section call the hide method which shows nothing. There is a flag that is set indicating that there is no BSoD yet. A timer is set up to 0 and when this timer reaches 3 the BSoD will appear. What are we timing? We already have a loop for growing and shrinking the room so we will use the end of that loop as the timer. So instead of having a gotoAndPlay on the last frame to loop the animation, we instead have nightmare.updateBSOD("blueLoop"); with the string being the name of the label to go to for looping the room animation. The BSOD update code is as follows:

spelchan.Nightmare.prototype.updateBSOD = function(loop) {
// BSOD calculations
if (this.bsodAppearing) {
this.stage.gotoAndPlay("loseGame");
return;
}
++this.bsodTimer;
if (this.bsodTimer >= 3) {
this.bsodAppearing = true;
this.stage.bsod_movie.gotoAndPlay("show");
}
this.stage.gotoAndPlay(loop);
}

The function simply keeps track of how many times it has been called. As the function is called every 2 seconds, we simply figure out how long we give the players before the BSoD appears and then start the appearing animation. If another tick happens after the appearing animation has occurred then we know that the player has bit the bullet. This simply goes to the loseGame frame which we use for losing the game. Which leaves us with the task of handing the winning and losing of the game.

Building the Rooms

The idea behind this episode of the game is that the player is dreaming that they are in a maze of rooms being chased by something. The rooms are connected in a non-linear fashion, but the rooms each have their own color. Thinking about this, all the rooms in the game will look the same except for their color. This means that all we have to do is create a single room and then duplicate it five times changing the colors in the duplicates! There, however, is an even better way of handling the creation of the rooms. Tinting!

To make tinting work the best, it is best to create the non-tinted image using gray-scale. I am going to keep the game in third person perspective so that we don't have all the work required to move an animated figure around. This means that the room needs to be drawn to look three dimensional. To better add to the three dimensional look, I created a tiled floor. This was done by drawing receding lines, then by drawing lines in the distance and angling them so that there is a larger distance between the closer points than the further points. Had I been really ambitious I could have created a far off point (a vanishing point) and having all the horizontal lines coming from that point. I then filled in the squares and finally removed the lines.

The ceiling I wanted to be stuccoed. This would have required a huge amount of work to accomplish using vectors, so I opted to use a texture for this image. The texture was generated in fireworks, but all high-end paint programs (and many low end ones as well) have texture creation support.

The three doors that are in the scene are actually all the same. I drew the far door and then used the distort command to alter the other two doors. While I could have been picky and tried to get the doors to look perfect, to keep the dream motif, I wanted the doors to be a bit distorted.

There are a number of ways of dealing with the room once you have the gray-scale done and want to apply tinting. This could be done within the program. Though tinting is a very costly operation, you would only have to do it once when you entered the room. Another option, which is the approach I took, is to create copies of the gray-scale image and individually tint those symbols. The advantage of doing this is you can get a bit better result from the tinting by tinting different parts of the room with different shades of the room color. The floors and ceiling were tinted a slightly different shade then the walls and doors, resulting in nicer looking rooms from the original flash version of this game.

Now that we have the rooms ready, we need to link them together which is what we will be doing next fortnight.

Planning the Adventure

The basic theme behind nightmare maze is that you are lost in a maze and must move quickly from room to room before the evil Blue Screen of Death reaches you.  The maze in this game is consistent in the fact that the same door will take you to the same room, however it is not commutative meaning that the door from A to B does not necessarily go back to A. This means while there is a structure to the maze it works different then the real world, which is typical of dreams.

Mazes are fairly easy to implement. This maze, however, is not a linear maze. With a linear maze, you can use graph paper to plan out the maze. This is obviously not the case with a non-linear maze. Instead, a different type of graph is used for creating a non-linear maze. This graph consists of the rooms drawn as boxes with arrowed lines showing how the rooms connect. I used a variation on this having colored lines corresponding to the room the line is from.

As you can see by the above map, the links between rooms are fairly complex. However implementing the links is actually very easy. You can also see that there are a lot of ways of reaching the exit, but do to the fact that there is nothing highlighting the exit, a player could end up being stuck in the maze for quite a while.

The room approach is very common in adventure games as travelling between locations is a very common activity. Generally, when designing an adventure game, each location will be considered to be a room even if it is an outside location. This allows for rooms to be worked on independently of each other and for earlier computers that had a very limited amount of memory would allow for the computer to only have to load the drawing data for the room that the player was currently in then having some type of transition animation between "rooms" when the player left a room and the game had to load in the image for the next room.

From a programming perspective, having rooms that are connected together with lines allows us to represent the map as a mathematical graph in which each room is a vertex of the graph and the connections between rooms are the edges of the graph.  Graph theory, however, is not necessary to build an adventure game. All that really matters is that you are able to create a basic map of the locations within the adventure so that you can move between them. The map can also be used to plan out where objects are located in the world and what obstacles or puzzles there are in the game. This allows for a walk through of the game before you have even started any real work on building the game so that you know that the game is solvable.

Once the map is planned out you then have the ability to itemize all the assets that will be needed for the game and can start work on building the art needed for each of the rooms. Building the rooms is what we will be doing next fortnight, but thanks to the nature of our maze this is a lot easier for this game than it would be for most other adventure games.

Nightmare Maze Overview

In the flash version (as well as my original draft) of this book, the adventure game material was near the end of the book but as the game is fairly simple from a programming perspective, I have decided to move it to here. Nightmare Maze is actually the first episode of a 46 episode series called One of those Weeks, which I hope to be redoing using a 3D engine sometime in the future.

In "Planning the Adventure" we take a look at how the game was designed. Adventure games tend to break areas that the player can visit into rooms, with the word room being a generic concept so outdoor areas are also referred to as rooms. For this game, all the rooms in the game are in fact rooms so the next step to the creation of this game is "Building the Rooms" which covers the techniques used to build the rooms used in this game. While it is a little but unconventional, it works for this game and the basic concepts are the same for other adventures.

While it is possible to have an adventure game that exists in a single room, such as a puzzle room, our game requires movement between rooms. I am not taking about adding doors to the room, though they are what the players use, I am taking about the underlying code for moving players between rooms. This is covered in "Linking the rooms"

While mazes are often enough, for this game we have a villain, who also happens to be in all the other dream sequences in this series, so in "Enter the Nasty" we cover the mechanism for getting the villain to appear. This obviously leads to "Losing and Winning" where we cover how to handle the nasty getting the player as well as the opposite but related player escaping from the nightmare.

With the game finished, this only leaves "Final Touches" where the title screen for the game is added. This covers what we will be doing over the next six fortnights, but the game is already on Spelchan.com so feel free to play the game while you wait for my sections on how the game was created.

5.7 Closures

The bind function takes advantage of something in JavaScript known as a closure. This takes advantage of the way that scope works within JavaScript and can be used to hide variables within a function. For binding it is making sure that the reference to the object that created the object is tracked.

Scope simply is a term that describes which variables are known to a particular piece of code. The visibility of a variable depends on where it is declared. When declared outside of a function it is global and is visible to everything, including other scripts running on the same web page, which is why you do not want to have global variables in your code if you can help it. Variables declared within a function are only visible to code within that function. Variables declared within a loop are only visible to code within that loop, and so on. The code within the loop, however, can see all the variables in the scopes leading up to it.

The purpose of scope is two-fold. First, each layer of scope can be considered it's own name-space. Second, and more importantly, this allows JavaScript to know which variables are no longer needed and can be garbage collected so that the memory it used can be reclaimed for use by other things. There is an exception to this garbage collection rule, any variable that is still being referenced by another variable that is still in scope will not be garbage collected.

Functions within another function have access to the parent function's variables. This information is stored in a scope chain, the details of which are a bit beyond the scope of this chapter but the nutshell is that the function has access to the information contained within the function that created. This means that if we have a case where there is a reference to the inside function then even if the outside function goes out of scope, the outside functions data will not be garbage collected as it is still referenced by something that is still in-scope.

Here is a simple demonstration:

// General function for printing to the web page so results can be seen// without requiring the console
function printTestLine(s) {
// we are grabbing an html element
var results = document.getElementById("testResults");
// now append the new line to this element
results.innerHTML = results.innerHTML + "
" + s
}

function HiddingVariables(p, v) {
this.publicValue = p;
var hiddenValue = v;

this.getHiddenValue = function() {
return hiddenValue;
}

this.bindPrint = function() {
var owner = this;
return function() {
printTestLine("The hidden value is " + owner.getHiddenValue());
}
}
}

var hiddenVar = new HiddingVariables(21, 42);
printTestLine("Attempting to read public variable: " + hiddenVar.publicValue);
printTestLine("Attempting to read hidden variable: " + hiddenVar.hiddenValue);
printTestLine("Getting through method: " + hiddenVar.getHiddenValue());
setTimeout(hiddenVar.bindPrint(), 1000);

When the HiddingVariables function runs, the public value is stored as part of the object. The hidden variable is a local variable which means that it will go out of scope as soon as the function finishes running. As the function has a reference to this value, it is still visible to it. If you still don't quite understand how a closure works, don't worry too much as it is not necessary to understand them to use them.

Now that we have a basic understanding of classes we use some of these concepts in the next chapter when we create the Nightmare Maze game.

5.6 Binding Events

The one really nice thing about classes is that they are a nice way of grouping data with the code that manipulates that data. This leads to a very common situation in programming where you want to do something with the data when an event happens. Event-driven programming is where the behavior of a program is structured around events instead of sequences and is the way you typicality approach user-interface related tasks. Combing objects with events seems like a no-brainer but this is where JavaScript starts showing some strangeness. To understand lets write a simple event.

// General function for printing to the web page so results can be seen
// without requiring the console
function printTestLine(s) {
// we are grabbing an html element
var results = document.getElementById("testResults");
// now append the new line to this element
results.innerHTML = results.innerHTML + "
" + s
}

// The timeout method uses a callback which gets called asyncronously
function tickTest(){
printTestLine("Tick Test was called!")
}
setTimeout(tickTest, 1500);

Timing events in JavaScript can be controlled by using a timeout. SetTimeout simply takes a function and a duration in milliseconds which are thousandths of a second. After the duration has expired it will call the function. Note that the timer is not precise and that the delay can be more than the specified amount bur for general usage timeouts are adequate. Running the above would result in a second-and-a-half delay before something was printed.

Now lets write a simple class that will store a value and when a function is called will display that value back.

// A simple class that stores a value and can display the currently stored value when asked to.function Demo() {
this.setValue = function(n) {
this.storedValue = n;
}

this.displayValue = function() {
printTestLine("Stored value is " + this.storedValue);
}

this.displayWithMessage = function(s) {
var str = "NO MESSAGE PROVIDED ";
if (s !== undefined)
str = s;
printTestLine(str + this.storedValue);
}
}

// as this shows, the class works as expected
var demo = new Demo();
demo.setValue(42);
demo.displayValue();
demo.displayWithMessage("Custom message before value ");

This works just fine so using it as part of an event seems trivial but lets try that.

// however, the value does not seem to exist if used as a callback.
setTimeout(demo.displayValue, 2000);
\end{lstlisting}
}

After a couple of seconds delay we get a rather interesting result. This is a byproduct of the way JavaScript calls methods within a function and is something that we will discuss in detail next fortnight. Obviously, this means that we can't use events with classes. But, as this is an obvious necessity, there is a bind function that browsers provide to solve this problem. By simply adding the bind function to the end of the function you are calling you will be able to specify which class the event is for. The function takes the instance of a class to use as it's parameter and does not need to be the calling instance but I can't think of any situation where I wouldn't want to use the same instance.

// this is where binding comes in
setTimeout(demo.displayValue.bind(demo), 2500);

// Binding also helps with parameters.
setTimeout(demo.displayWithMessage.bind(demo), 3000);
setTimeout(demo.displayWithMessage.bind(demo, "Message added in Binding "), 3000);

As can be seen from the demo code, binding can also be used to add additional parameters to a callback function. When dealing with situations such as having multiple buttons being handled by the same logic, this is an incredibly convenient feature of the bind function. But what exactly is the bind function doing? Tune in next fortnight to find out!

5.4 Inheritance

One of the most powerful and most over-abused features of object oriented programming is the use of inheritance. The basic idea here is that there are a lot of classes of objects that have a lot of features in common. Instead of re-writing the same code repeatedly for similar objects, a hierarchy of related classes can be created. You start with a base class, also known as the parent, that has the base functionality it's children will inherit. To demonstrate this, lets create a base class for pets.

The pet class will have a name for the pet and a species for the pet. Pets will be able to greet their owner, and make a noise. First, lets take a look at the more modern ECMAScript 6 way of doing this. This is set up just like any normal class that we would have created in the previous section.


class E6Pet {
constructor(name, species) {
this.name = name;
this.species = species
}

greet() {
printTestLine(this.name + ", the " + this.species + ", comes to greet you");
}

makeNoise() {
printTestLine(this.name + " makes a noise");
}
}

var fish = new E6Pet("Nemo", "Fish")
fish.greet();
fish.makeNoise();


The old way of creating the base class is also the same way you would create a class using older versions of ECMAScript.

function Pet(name, species) {
this.name = name;
this.species = species;

this.greet = function() {
printTestLine(this.name + ", the " + this.species + ", comes to greet you");
}

this.makeNoise = function() {
printTestLine(this.name + " makes a noise");
}

}

var oldfish = new Pet("Dora", "Fish")
oldfish.greet();
oldfish.makeNoise();

Once you have a class that can be used as a base-class, you can create a new class that inherits the methods and variables of it's parent. This effectively gives you all the code that you have written in the base class. You can then add additional methods and variables allowing the new class to have the functionality of the base class while adding new features to the class. This alone would make inheritance worth doing, but it gets even more powerful. It is possible to override an existing method and replace it with another method that is more appropriate for the class you are creating.

In our example, different pets make different sounds so by overriding  the makeNoise method, we can create species specific noises. We will create a dog and a cat, with each of them having a unique noise and the dog being able to wag it's tail.

ECMAScript 6 makes inheritance very easy as you just use the extends keyword when you are creating a class. Sub-classes can have a different number of parameters, with the super method used to call the original code. Overriding the method is simply the matter of using a method with the same "signature." A method's signature is simply the method name and the particular parameters that make up the method. finally creating a new method is done by having a new method in the class.

class E6Cat extends E6Pet{
constructor(name) {
super(name, "Cat")
}

makeNoise() {
printTestLine(this.name + " Meows!");
}
}

class E6Dog extends E6Pet {
constructor(name) {
super(name, "Dog")
}

makeNoise() {
printTestLine(this.name + " Barks!");
}

wag() {
printTestLine(this.name + " wags his tail!");
}
}

var cat = new E6Cat("Lexi")
var dog = new E6Dog("Scruffy")

cat.greet();
cat.makeNoise();
dog.greet();
dog.makeNoise();
dog.wag();

The old way of inheritance is a bit more confusing as older versions of ECMAScript does not have a way of directly indicating inheritance so the programmer must manually set this up. JavaScript use prototype based inheritance where every class has a prototype that determines which methods it has. This prototype is used by the new operator to set up the class, but the prototype can be modified manually. The result is that there are many ways of setting up inheritance in JavaScript. The most common way is simply assigning the prototype of the class to the prototype of it's parent by using the new function.

function Cat(name) {
this.name = name;
this.species = "Cat";

this.makeNoise = function() {
printTestLine(this.name + " Meows!");
}
}
Cat.prototype = new Pet();

(Dog = function(name) {
this.name = name;
this.species = "Dog";

this.makeNoise = function() {
printTestLine(this.name + " Barks!");
}

this.wag = function() {
printTestLine(this.name + " wags his tail!");
}

} ).prototype = new Pet();

var oldcat = new Cat("Abby")
var olddog = new Dog("Smokie")

oldcat.greet();
oldcat.makeNoise();
olddog.greet();
olddog.makeNoise();
olddog.wag();

You will notice two slightly different styles for doing this. The cat way is the textbook way while the dog way is the way JavaScript code generated by Animate CC does things. You could also manually copy just the methods you are interested in, which can be a handy way of inheriting functionality from multiple different classes.

Inheritance is not just for reducing code duplication, but allows for a powerful technique known as polymorphism which we will be covering next.

5.3 Constructing Classes

While I have my January game ready, I am at my parent's place while the game is in a different city so I will not be posting it until January 2nd when I return to University.

JavaScript did not have "proper" classes until ECMAScript 6. The problem is that while there is now a class keyword that makes creating classes much easier in browsers that have an ECMAScript 6 complaint version of JavaScript, this is not all browsers. Eventually there will be so few browsers that do not support ECMAScript 6 that using JavaScript classes will make sense, but before that transition takes place, the old way of creating JavaScript classes must be used. The nice thing is that backwards compatibility means that the old way will still work on new browsers.

The ECMAScript 6 way of creating classes is with a class construct. Within this construct we have a constructor which initializes the class and then methods that the class knows. There is some special support for getter and setter methods which I will not be covering here as this book is more focused on older JavaScript but that may be something I cover in a future book. Here is what a soldier class would look like in ECMAScript 6 versions of JavaScript:

// General function for printing to the web page so results can be seen
// without requiring the console
function printTestLine(s) {
// we are grabbing an html element
var results = document.getElementById("testResults");
// now append the new line to this element
results.innerHTML = results.innerHTML + "
" + s
}

class E6Soldier {
constructor(name, rank, serialNumber) {
this.name = name;
this.rank = rank;
this.serialNumber = serialNumber; 
}

printNRS() {
printTestLine("Name: " + this.name + " Rank: " + this.rank +
" Serial Number:" + this.serialNumber);
}
}

printTestLine("ECMAScript 6 tests");
var soldier1 = new E6Soldier("Bob", "Private", 12345);
var soldier2 = new E6Soldier("Doug", "Captain", 23456);
soldier1.printNRS();
soldier2.printNRS();

You will notice that both soldiers simply used the E6Soldier class to build their object. The creation of an object from a class is called instantiation in object oriented terminology. Every object of a particular class is known as an instant of that class. Instances share the same properties and methods, though object specific properties and methods can be manually added to specific objects if desired, but are otherwise independent.

The old way of creating classes is similar to the new way but instead of grouping things into a class structure you are creating a function. This function sets up the properties just like the constructor above did and then sets up all the methods that are used by the class.

function Soldier(name, rank, serialNumber) {
this.name = name;
this.rank = rank;
this.serialNumber = serialNumber;

this.printNRS = function() {
printTestLine("Name: " + this.name + " Rank: " + this.rank +
" Serial Number:" + this.serialNumber);
}
}

Note that it is not necessary to have all the methods defined within the function. Some people actually like defining the methods of a class outside of the class. This is done by using the function's prototype, which is something we will be talking about in more detail in later sections.

Soldier.prototype.changeRank = function(newRank) {
this.rank = newRank;
}

Using the classes is pretty much the same the old way as it is the new way.

var soldier3 = new Soldier("Pete", "Private", 34567);
var soldier4 = new Soldier("Billy", "Captain", 45678);
soldier3.printNRS();
soldier4.printNRS();
soldier4.changeRank("General");
soldier4.printNRS();

The real power of classes comes from polymorphism and inheritance, but that is also where the biggest problems of object oriented programming come from. Next section we will start our exploration of polymorphism and inheritance.

Chapter 5 Overview

Object Oriented programming has become the predominant way of developing software today. While there are some people who believe that object-oriented programming (OOP) is a misstep, there are also people who quite dogmatic about OOP. Both of the Universities I have attended tend to favor the OOP approach but there is starting to be a look at the alternatives to OOP, with functional programming gaining traction. I am a bit more flexible when it comes to programming believing that methodologies, like languages, are tools and one should try and use the appropriate tool for the problem they are dealing with.

Object Oriented approaches are so common, however, that no matter what your stance on OOP is, you should at least be familiar with the concepts behind it. This section of the book takes a look at the core OOP features that JavaScript supports. Unfortunately, like a lot of things about JavaScript, things are not as straightforward as they should be. While JavaScript has always had support for Objects, the language itself did not explicitly support OOP constructs until the ECMAScript 6 standard was released. This means that older browsers do not support the new language keywords but there are a shrinking number of people who use those browsers. It also means that there is a lot of legacy code out there that does OOP the hard way. These techniques are still valid so it is wise to at least be familiar with them.

In this chapter we will look at a number of OOP related concepts looking at what the idea behind the concept is, how ECMAScript 6 supports that concept, and the "old" way of handling the concept.

To start with, in the "NameSpace" section we will be looking at the name space problem and how to get around it. Even if you are not into the other OOP concepts, name spaces are something that ALL non-trivial programs should use.

It goes without saying that objects are important to object-oriented programming so we will then revisit creating objects in "Creating Objects". This will be followed by "Constructing Classes". Classes are what most OOP languages use to define objects with a class keyword being something that was missing from JavaScript until the ECMAScript 6 standard was released.

One of the more powerful, albeit over-abused, features of object oriented programming is the use of inheritance. This allows you to create new classes based off of existing classes without needing to write most of the functionality and will explained in the "Inheritance" section. Polymorphism is how OOP languages take advantage of inheritance by letting you use a child class in place of a parent class. JavaScipt uses a variant of polymorphism known as Duck Typing which gives you a lot of flexibility and power but has some downsides. These issues will be covered in "Polymorphism and Duck Typing".

JavaScript handles classes a bit different from most other object oriented languages. This leads to a strange issue when trying to use an objects function as a call-back. This issue can be solved using something known as binding, which we will explain in a section strangely named "Binding".

What allows JavaScript to bind functions actually is a very powerful construct known as a closure. Closures are a bit confusing and you may not want to use them in your programs, but they are an important JavaScript technique so I will be covering them in the "Closures" section.

And that should cover all the object oriented JavaScript knowledge that you will need for the remainder of this book.

4.8 Winning and Losing

As you know, the game ends when the last gem has been taken. Also obvious is the fact that there are two possible outcomes for this game. The player can win the game, or the computer can win the game. Knowing this, our movie is going to have to be able to handle either situation. This will require a bit of JavaScript. Here is the final version of the gemRemoved function with the new lines bolded.

function gemRemoved(gemCount) {

   if (gemCount <= gemsRemaining) {

          gameMovie.stop();

          if (gemCount == 0) {

                 if (gamestate == GAMESTATE_PLAYER_ANIMATING)

                       gameMovie.gotoAndPlay("playerWins");

                 else

                       gameMovie.gotoAndPlay("computerWins");

          }

          if (gamestate == GAMESTATE_PLAYER_ANIMATING)

                 computerTurn();

          else {

                 gamestate = GAMESTATE_PLAYER_PLAYING;

          }

   }

}

Both sequences start out with the final gem growing larger while moving to the left side of the screen. This is a simple scaling operation combined with a movement operation. The end result is shown in the image below.

To keep the code simple, the end sequence will simply display the results for a few seconds before returning to the title screen. An alternative approach would be to have a button that the user clicks to return to the title screen. To return to the title screen we simply call a returnToTitle function at the end of the winning screen and at the end of the losing screen.

The line of code that needs to be added to both:

                            returnToTitle();

Finally, we need a function in the global script called returnToTitle that actually does the work:

function returnToTitle() {

   gameStage.gotoAndPlay("Title");

}

And now we have a our completed NIM game!