Final Touches

As is quite often the case with my games, the last part of the game that is created is the title screen. The first part of the title screen is the game's logo. My One of the Weeks logo is not really appropriate, even though this game is part of that series, so to make this a stand-alone game I created a new logo. For the start button, I opted for a door as that is emblematic of the game play. As always, the code to control the button is very straight forward.

spelchan.Nightmare.prototype.startTitle = function() {
this.playButtonHandler = this.playButtonClicked.bind(this);
this.stage.playBtn.addEventListener("click", this.playButtonHandler);
this.stage.stop();
}

spelchan.Nightmare.prototype.playButtonClicked = function(e) {
console.log("Play Button Clicked!");
this.stage.playBtn.removeEventListener("click", this.playButtonHandler);
this.stage.gotoAndPlay("Intro");
}

One problem that I had with the game at this point was the fact that someone who started playing the game without reading the instructions would be totally confused by what was going on. While confusion may actually add to the story, it can also turn a lot of people off the game. As this is the first episode of a series, one thing I don't want is to turn people off the game.

While I would like to think that people read the instruction pages that I put a some effort into creating, the reality is that a lot people just start playing the game.

One solution would be to have a link to the instructions on the game's title screen. The problem with doing this is that the people who skip over the instructions page are likely to not bother clicking on the instructions button either. This means that I would end up putting more time into creating the instruction pages - which is more time consuming then writing an instruction page - which few people are going to read. This is obviously not a good solution.

The solution I did for this episode is to incorporate the background portion of the instructions into the game by starting the player at an explanation screen. This is simply a looped animation of the text bubble growing then shrinking. The code for handling the button is also very simple.

spelchan.Nightmare.prototype.setIntroButton = function(e) {
this.introButtonHandler = this.introButtonClicked.bind(this);
this.stage.con_btn.addEventListener("click", this.introButtonHandler);
}

spelchan.Nightmare.prototype.introButtonClicked = function(e) {
console.log("Intro Button Clicked!");
this.stage.con_btn.removeEventListener("click", this.introButtonHandler);
this.stage.gotoAndPlay("enterRed");
}

And that is all there is to the game. Next fortnight we will look at changes to my Blazing Games porting plans and next month we will start chapter 7 which sets the foundation for the creation of video poker.

Linking the Rooms

Now comes the task of assembling and linking the rooms. I create a block of frames for each of the six rooms with each room being broken into three animated sequences. First is the Enter sequence (labeled enterColor, with Color being the color of the room). This sequence shows the room zooming into view. Next is the main room loop (labeled colorLoop, with color being the color of the room). I want to have an additional disorienting effect added to the room. Therefore, I set this block of frames to loop. The room will slowly grow and then shrink back to it's starting size. Finally there is an exit sequence (labeled colorExit, with color being the color of the room). This shows the room shrinking into nothing.

As animate likes to tie code to the frame it is written in, we are creating a globally accessible class that we will be using for tracking the state of the game. This class will be added to throughout this chapter but to start with we have the following initialization code.

if (typeof(spelchan) == "undefined") spelchan = {};

spelchan.Nightmare = function() {
this.registerStage = function(stage) { this.stage = stage;}
this.dirButtons = [null,null,null,null];
this.dirClickHandler = this.directionClicked.bind(this);
this.exitTarget = "exitRed";
}

This sets up a spelchan.Nightmare class that holds the list of buttons that are used to control the navigation between rooms. We need buttons for the four directions that the player can go. Quite simply, I will label the directions North, South, East and West. The four buttons will be invisible buttons. These are buttons that have a hit box but no image. Actually, when the player is over the buttons, we will have a "Go Direction" message appear. This is done simply by having the over and down frames of the button have the desired text in them. In the editor the invisible buttons have a cyan color and are placed over the doors in the image. Due to the animation of the room this placement isn't exact.

Every room will have it's own set of four buttons. I use the convention of naming the button instances colorDirection_btn. As the logic for the buttons is similar for all the rooms we can create a general method for setting up the buttons for a room as follows:

spelchan.Nightmare.prototype.setDirectionTargets = function(
btnNorth, targetNorth, btnEast, targetEast,
btnSouth, targetSouth, btnWest, targetWest, exitTarget) {
this.dirButtons[0] = btnNorth;
btnNorth.directionTarget = targetNorth;
this.dirButtons[1] = btnEast;
btnEast.directionTarget = targetEast;
this.dirButtons[2] = btnSouth;
btnSouth.directionTarget = targetSouth;
this.dirButtons[3] = btnWest;
btnWest.directionTarget = targetWest;
this.exitTarget = exitTarget;

for (var cntr = 0; cntr < 4; ++cntr) {
this.dirButtons[cntr].addEventListener(
"click", this.dirClickHandler);
}

this.bsodTimer = 0;
this.bsodAppearing = false;
this.stage.bsod_movie.gotoAndPlay("hide");
}

This code simply sets up the buttons and gives each button a target frame to go to when it is clicked. It also provides the frame to goto to start the exit room animation. The buttons are then assigned an event listener to handle being clicked. We will be covering this handler later in this section. Finally the code sets up the timer for the villain. We will cover the appearance of the villain in the next section. Each of the six rooms needs to call the above method when it is appearing with the code being on the frame where the room starts appearing. This code is something like the following:

nightmare.setDirectionTargets(
this.redNorth_btn, "enterCyan",
this.redEast_btn, "enterGreen",
this.redSouth_btn, "enterCyan",
this.redWest_btn, "enterYellow", "exitRed");

As you can see this is simply a function call to the method we created above. The parameters would be the appropriate buttons for that room and the labels of the frame the program should go to when the button is clicked. The button variables are self-evident while the target frames require looking at the map to determine the appropriate room to go to.

Handling the click is the next thing we need to do. This is done by the event handler we hinted at above.

spelchan.Nightmare.prototype.directionClicked = function(e) {
// make sure button has valid target
if (typeof(e.target.directionTarget) == "undefined") {
console.log("ERROR - Missing target in button");
this.directionTarget = "enterRed";
} else {
console.log("Button target is " + e.target.directionTarget); 
this.directionTarget = e.target.directionTarget;
}

// clean up buttons
for (var cntr = 0; cntr < 4; ++cntr) {
this.dirButtons[cntr].removeEventListener("click", this.dirClickHandler);
}
this.stage.gotoAndPlay(this.exitTarget);
}

This function first sets up a class variable called directionTarget to be the name of the frame to go to once the room has been exited. We can't go to this frame right away because we have to play an exit animation first. To be good citizens, we need to clean up our event handlers so we remove the event listeners. Finally we start the animation for exiting the room.

To finish our navigation system we need to go to the appropriate room when the player is exiting the room. Each of the exit animations will have a call to nightmare.nextRoom() on the last frame. This is a simple method that simply goes to the frame indicated by the button that was clicked on above.

spelchan.Nightmare.prototype.nextRoom = function() {
this.stage.gotoAndPlay(this.directionTarget);
}

This code simply goes to the appropriate frame for the next room. And that is all that is required for a navigation system. Now we need to implement the villain of this game which we will do next fortnight..

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.

Fleet Postmortem

Fleet is one of the first Java games that I wrote. As the game was written in Java, and Kotlin is a replacement to Java which can compile to JavaScript, I decided to see how well Kotlin works for HTML5 games. The create.js library was used for handling the GUI aspects of the game. To make the game more playable on tablets, I had to rework the user interface quite a bit which makes this more of a re-write than port.

Fleet was released on Spelchan.com on June 1st and is based on the classic pen and paper game that is now played on a board with easily lost plastic pieces. You control a fleet of ships. You have an opponent who also controls a fleet of ships. Your goal is to destroy your opponents fleet of ships before your opponent can destroy your fleet of ships.

What Went Wrong

In the original Fleet, ship placement was done one ship at a time with the player using the space bar to rotate the ships. As I wanted this to work on touch-only devices this meant that requiring a key stroke was out of the question. Dragging the ships around to move them seemed like the ideal touch-based controls. Double-clicking on a ship to rotate the ship became the obvious solution for ship orientation.

While create.js does have some support for drag-and-drop, I still had to write a fair bit of code to get this to work. Getting it working with the mouse was easy but for some reason it would not work on the tablets that I have access to. I finally searched on-line for any information where I discovered that you had to enable touch by using the Touch class. Seconds later I was running it fine on my tablet, but my Dad's older tablet ran very poorly and inconsistently. While I suspect that this is predominantly due to the age and slow speed of the device, I decided it would be a good idea to have the initial layout of the player's ship be randomly generated just like the AI ships so that if a player was having problems moving ships around, they could just go with the default random layout.

Testing the dragging and dropping of ships resulted in the ship often not going where the player was expecting due to the way the sprite snapped to the grid. One solution to this problem was to simply have the grid snapping happen as you dragged the ship but this simply did not feel right. The original version would highlight the grid squares where you were going to place a ship in white or red so I figured that I would do the same thing here but opted for yellow and red. This took a bit of work to accomplish but I think the results are quite nice.

Mixed Blessings

Kotlin is a rather new language that came to the scene more as an alternative to Java programming on Android but with the ability to compile to JVM, JavaScript, or Native it has a lot of potential. I started my Atari 2600 project to try out the language where I found myself enjoying the language. I wanted to see if it could be used for porting games so decided that as Fleet was originally written in Java, it would be a good contender.

One of the nice features of Kotlin is that you are able to use the "native" features of the platform you are compiling to so a JavaScript project can make use of JavaScript libraries and other native features. This has to be specified using the external designation but there is a utility to convert TypeScript definition files into Kotlin definitions so it was simple enough to get a create.js definition. Using create.js with Kotlin always felt like a kludge and its JavaScript nature made working with it awkward for many activities such as tweening.

The biggest downside to using Kotlin and Create.js together is that both are large libraries making the loading time a bit larger than I would like. For a larger project this would be okay, but startup time for Fleet seemed to be way too long.

What Went Right

The AI that I created for the original version of this game was surprisingly good and yet was fairly simple to implement once the base ideas behind it were worked out.  The version of the AI in this game is essentially the same as the original version except that it was cleaned up. It didn't take too long to port the code over and it just work. If all the code I ported went this smoothly, I would have ported many more games by now.

Summary

I think this version of Fleet is a bit nicer than the original though there is still a lot of things that I would have loved to do had I the time. It is possible that I may revisit this game in the future with a deluxe version of the game, but that will not be for a while.

As for using Kotlin for future HTML games, I am still up in the air. If I could find a good cross-platform library with similar functionality to Create.js, then this would possibly be a good thing. Writing my own cross platform library is not likely in the near term, but after I get my Masters it may be something I would think about. I am still wanting to try out the Rust language, so how much I like that language will determine which of the two languages I will be focusing on in the future.

Towels for Earth Postmortem

This is a postmortem for the game that I will be posting on May 25th for Towel Day which is the HTML5 port of Towels for Earth. Towels for Earth was a game that I created for a Game Jam back in 2013. The theme of the game jam was towels in honor of Douglas Adams. I suspect that there are several Douglas Adams fans who managed to encounter my Blazing Games site somehow as the polls show that there are quite a few people who wanted to see this game ported to HTML5. It is a fun but short missile defense game where missiles are destructor beams and anti-missiles are towels with the player tossing towels at destructor beams to save the Earth.

What Went Right

This was a game-jam entry so it was very quick to port over. I had a bit of time left over from what I budgeted so I decided to add some sounds to the game. The original game is in space for which there is no sound, but purists can simply turn the sound off via a nifty sound toggle that I added. The speaker artwork was taken from another game I wrote that had a sound slider but I didn’t have enough spare time to try and create a slider, but that is probably something I should be doing in the future if I ever get enough spare time, which won't be in the next couple of years.

I started going through some of the public domain and royalty free sounds that I have collected over the years to find a few sounds that would work with the game. While some people may not like my choices, I think they work well for the theme of the game. Sound in Create.js is very easy to play if the files have been downloaded which I am using preload.js to do so this was trivial to add once the sound files were found.

What Went Wrong

I went a bit overboard with the original game and had created a pixel-perfect collision detection routine. This requires the use of bitmap libraries that Create.js doesn’t have and would have been very painful to do – not to mention excruciatingly slow – to do so I reverted to good old-fashioned bounding circles. The wonderful thing about bounding circles is you just find the distance squared between two objects and see if the squared distance is within the combined radiuses. The problem is that if one of the shapes is not spherical, then the collision results can be a bit inaccurate. I don’t really mind too much but suspect that I may hear some complaints about this. I did try to be a bit generous with my circles feeling it is better to have more false positives than false negatives.

Some of you may be wondering why I am using distance squared. This is an old-school technique to save a bit of CPU cycles. Distance is sqrt( (x1-x2)^2 + (y1-y2)^2) which is a slow routine to calculate since square roots are very slow to calculate. On the other hand, radius*radius is very fast to calculate so by forgoing the square root portion of the calculation you can speed up the check while keeping the accuracy of the calculation.

Mixed Blessings

The original game used a combination of background images and vector artwork, but I opted to go with all images even though I could have saved a bit of space by using some vector images. The tradeoff of a slightly larger file size for slightly faster game rendering and a easier coding was arguably worth it. The images I did want to have as vectors were actually fairly large so it wasn’t that much space that I was using. My original plans were to have the backdrops converted into a separate jpeg file while the other parts were stored in a png file so I could get a bit better compression. When using my image view to see how different compression ratios would affect the image quality, I noticed that the images looked pretty good when converted to 8-bit png files with only a small increase in file size so I put all the images into a single image atlas.

For people who still have slow internet connections, these decisions may have resulted in longer loading times. For that I apologize as I know most people with slow internet don’t have a choice in the matter.

Conclusion

Overall, I am happy with how this game turned out. Sound does add a bit to the game, but sound and music is my Achilles heel. I really have to start trying to add more sound to my games in the future.

Script Soup

Games are not movies. Movies are linear with no interaction. Games may have a linear story, though often that is not the case, but they have interaction. Interaction means that the application will behave differently based on what the user is doing. The best example of this would be the user clicking on a button. The Animate movie has no idea when the user is going to click on the button. Likewise, if there is more than one button, the animate app is going to need to know what to do based on what button is pressed. To deal with this, we need a scripting language.

A scripting language is just a programming language that is was created specifically for handling domain specific activities. In other words, scripting languages tend to be specialized. Often, a simple scripting language grows over time and you will end up with what could be a full-blown programming language if only it didn’t require the application it was attached to. This is pretty much the case with JavaScript.

JavaScript is loosely based on the Java language, which itself is based on the C++ language which is an object-oriented version of the C language. In other words, understanding JavaScript will make it easier to learn real programming languages like Java or C++. One of the (many) downside to JavaScript is that it is slow because it was designed as an interpreted language. Explaining the difference between compiled, virtual machine, and interpreted languages is a bit beyond this book but essentially computers only know their specific machine language (which depends on the processor being used). Compiled languages, such as C++, convert their source code into machine language. Virtual machine languages, such as Java, compile into an intermittent machine language which then gets converted into the machine language of whichever machine is running the code. Interpreted languages convert the script into machine language as it is being run.

The scripting language itself is not enough for Animate, it also has a library of functions that are used to actually do the work. Originally Flash used a JavaScript variant called ActionScript which was JavaScript but with proper types and classes. The scripting language had a library of classes for manipulating movie clips and other aspects of the animation. When HTML5 started appearing, several Flash-like libraries started appearing for JavaScript. One of the more popular ones was Create.js. Adobe decided to migrate to Create.js instead of writing their own JavaScript library so when you are using an HTML5 canvas in Animate, you are creating a Create.js JavaScript application.

Create.js is actually a collection of four different libraries. These libraries can be used individually, but tend to be grouped together. As Animate generates a lot of the code for you, the bulk of the code that will need to be written is game logic code with direct manipulation of the Create.js very rare and often only to adjust already existing objects.

Easel.js is the heart of Create.js. This is the stage that the animation occurs on. The library tracks sprites and movie clips and is able to take the scene graph that results from the position of these objects and is able to draw a frame on the HTML5 Canvas. The HTML5 canvas is a special API for drawing things in JavaScript but is only for 2D images. There is an extension to this canvas called WebGL which lets the canvas take advantage of accelerated 3D graphics. An experimental version of Stage.js using WebGL is available and is distinguished from Stage.js by being named Stage.gl. I may cover StageGL in a future book.

Tween.js handles the animation aspects of the program. As explained earlier, tweening is simply changing an aspect of an object over time so it is possible to use Tween.js for non-animation related aspects of a program.

Sound.js handles the sounds that a program makes. JavaScript sound handling is a mess so having a simple API for getting sounds to play is nice. The downside to this API is that the sounds need to be loaded before they can be played. This is the reason the final API in the Create.js suite exists.

Preload.js is an asset preloader. This simply means that you give it a list of assets that you want your program to use and it will load them in. The preloader generates events to let your program know when it has loaded assets so you can even create a fancy loading screen if you wish.

We will cover the Create.js API as we need to, with my follow-up book going into much greater detail. As games require interaction to be playable and interaction requires some code to handle it, we are going to have to at least learn the basics of JavaScript. Still, in many cases you can get away with a minimal amount of simple JavaScript if the game is not too involved and by the end of this book you will have a good grasp of what games will require the most code and can pick your projects accordingly.

The Key to Animation

Animate uses a layer based keyframe animation system. For people who are not familiar with the creation of animation, this sounds complicated. It is a very quick and effective way of creating animation as the animator is just setting up guidelines for the computer to generate the majority of the  frames.

A keyframe is essentially a frame of the movie. Within the frame you place objects where you want them to be. Every time you want to change the contents of the frame you create a new keyframe. This by itself is not that powerful. Where the power comes from is with tweening. Tweening is a method where you let the computer animate the object for you. The word tweening is a concatenation of the term “inbetweening” which is where the lead animator would draw the key frames and junior animators would draw all the frames between the keyframes. Animate has two types of tweening. Motion Tweening and shape tweening.

Motion tweening moves an object from the location it is on the starting keyframe to the location it is when it is on the ending frame. You can also apply rotation to the object that is moving. While technically not motion, you can also adjust any color adjustments (such as the alpha level) and the adjustment will smoothly transition between the frames. As objects in nature don’t move at steady rates, you can use leading to have the object start the motion at a faster rate and slow down as it approaches the end keyframe or have it start slow and speed up as it reaches the keyframe. The image below illustrates the difference between the three types of tweening.

For even more advanced animation effects, you can have guides. Guides let you specify the path that a moving object will follow. You can have the object follow the path while maintaining the same orientation or you can have the object orient itself to the path. My April Fool series of games has a title sequence where each letter has a winding path to it’s ultimate location. The screenshot below illustrates the different paths that the letters follow to reach their final location.

Shape tweening is a bit complicated. Shape tweening is when you have one shape and it transforms itself into the second shape. This is easy to do, but hard to do well. You simply need two shapes, a starting shape on the start keyframe, and an ending shape on its ending keyframe. To make sure the shape morphs the way you want, you add key points to the shapes. These points help Animate determine where the lines and points that make up the shape should line up after the end of the tween. Here is an example of a square turning into a star with the red shapes being the onion skin outlines of the frames between the square and the star.

An Animate movie consists of one or more layers. Layers go from back to front with closer layers overlapping further layers. Every layer is independent of the other layers. In other words, you can have keyframes in one layer but not any of the other layers. Animate lets you define as many layers as you need and lets you group the layers into folders. It is advisable to keep each animated object on its own layer as not doing so will result in animate creating a separate tween object in the library which often leads to problems.

The animation system is the primary reason why you would choose to create a game in Animate instead of creating it from scratch using the free Create.js libraries. While everything listed above can be done manually in Create.js, having a tool that generates all the source code for you is nice. If your game is a very heavy animation-oriented project, then using Animate makes sense.

Using animate to create the animations for a game project but then doing that project manually using Create.js or some other library (or even another language) can also be a consideration. In a team environment, this approach can be very cost effective as you would only need creative cloud for your art team while the development team can have other development tools.

Symbolizing things

Animate revolves around symbols. Symbols are a very efficient way of building movies, as a symbol only needs to be loaded once. After it has been loaded, you can create as many copies - known as instances - as you want to. More importantly, every instance of a symbol can have properties independently applied to it. You can adjust the size, orientation, and skew. You can also apply tinting, control the brightness, adjust the alpha (transparency) level. There are three basic types of symbols that Animate uses. The Graphic symbol, the Movie symbol and the Button symbol.

Graphic symbols are just a drawing converted into a symbol. The drawing can be as simple or complex as you desire, and can even contain other symbols as part of it. These tend to be vector based, but it is possible to use bitmaps for graphics. Flash used a very compact binary format for vector images making them take significantly less space than bitmaps in many cases. Animates’ HTML5 exporting converts these vectors into Create.js shapes which take up significantly more space, especially if you are not letting Animate compress the images.

A movie symbol is essentially a movie within the main movie. You have as much control over an Animate movie symbol as you do over the resulting movie. You are not limited to having a single level of movie clip as movie symbols can contain other movies as part of them, which can contain movie symbols within them which can contain movie symbols within them and so on. While this recursive nature of movie clips adds a lot of flexibility to creating animations, movie clip objects are fairly heavy in memory and processing requirements so having too many nested movie clips can slow things down substantially.

A Button is simply a special symbol that has special actions associated with it whenever the mouse is over it or the mouse has been clicked while over it. To be more precise, a button has 4 frames associated with it. The up frame is simply the normal appearance of the button. The over frame is how the button looks when the mouse is over it. The down frame is what the button looks like when the mouse is over it and the mouse button has been pressed. Finally, the hit frame defines the over/hit areas.

The hit frame may seem confusing to people new to Animate. This frame is not actually seen by the viewer, but is instead used by Animate. How it works is any area in the hit frame that is solid will react to the mouse being over it while an area that is not solid will be ignored. While touch users will not get the mouse over effect, the hit area is used for determining if a touch results in a down event.

Some of you may be wondering why you would want or need such a thing? Couldn't you just use the existing button image? The answer to that is you could, but then the button would only work if the user had his or her mouse positioned in a solid part of the image. In some cases, such as with our Play the Game button, we want the button to react if the mouse is within a block or an area that covers more than the frames cover. Conversely, you may not want a rectangular region or even the entire button to be clickable. The hit mask gives you total control over where the button can be clicked.

As an example, here is a button that I use for switching a sound from enabled to disabled. The top right image is the normal image and is what the user will see normally. The top-middle image is what will be shown to mouse users who move the mouse pointer over the image. The top-right image is what is shown when the button is clicked or touched. Finally, the bottom image is the hit map that is used for determining if the mouse is over the image.

Symbols can be created in animate simply by drawing something and then selecting the drawing and choosing the “convert to symbol” option from the right-click menu or the modify menu from the menu bar. Creating a symbol adds it to the library. Empty symbols can also be created from within the library, though personally this is not something I do. The library is a file-folder structure allowing you to easily arrange your symbols to make finding and working with them much more efficient. This is especially true when you get to larger projects that contain hundreds or thousands of objects.

Libraries also have the benefit of being sharable between projects. Animate makes it easy to move symbols between different libraries allowing you to create a standard set of library symbols that can be copied between libraries. There are also built in tools for converting a selection of library symbols into image atlases or stand alone files which can come in handy for environments where animators create assets in animate then hand them off to developers who are using pure JavaScript (or other language for non-HTML projects) for creating the application.

Flash is Dead! Long Live Animate!

The first exposure I had to Flash was when I encountered some FutureSplash animations in the mid-nineties. This was interesting technology at the time as back then most people were using telephone lines and modems to get internet pages so having streaming animated video was simply mind boggling. Back in those days, streaming video was small thumbnails and generally didn’t work well.  In “The Road to Animate” we will look at this history as well as my personal history with the technology.

One of the biggest draws of using Flash, now Animate, was animation. Before you can animate something, however, you first need to draw it. “Drawing Things Out” covers the basics of the drawing functionality that comes with Animate. “Symbolizing things” explores Animates’ symbol and library which is vital to making objects move. “The Key to Animation” explores Animates’ keyframe animation system which really is the reason that you would want to use Animate over writing an HTML5 game purely in JavaScript, even when using a library such as Create.js.

We conclude this chapter with “Script Soup” which takes a look at how scripting is involved in the game making process. This is a rough exposure to ECMAScript, ActionScrpt, and JavaScript with a general overview of the Create.js library.

Personal notes

After finishing my Bachelor degree and looking back at my site I realized that there was a lot on my site worth saving. I was not sure what route to take but essentially knew that I had to at least attempt to salvage some of the games. Finding my old book on Flash and deciding to undertake this book project, which is now a two-book project and I suspect additional volumes may be added in the future (possibly for StageGL, Kotlin, and Web Assembly). The reason I decided to break the book into two separate books was simply that after playing around with Adobe Animate CC, I was disappointed with what the tool has to offer and found that most of my work was being done editing Create.js code. You do not need an expensive tool to do that which is why I broke this book in half. With that said, most of the material in this book is still applicable to people who want to go the pure Create.js route so if you have no plans on getting Adobe Animate CC, you can still benefit from reading this (especially now that it is being freely posted on my Blog).

Towels for Earth Postmortem

As a fan of Douglas Adams since I was a kid, there was very little chance of me not partaking the Towel Day Mini-Ludum Dare. I find it really interesting that Mini-Ludum Dare#42 happened to occur just in time for Towel Day but as Douglas Adams has repeatedly said "42 seems to show up a lot." For those not familiar with The Hitchhikers Guide to the Galaxy, 42 is an important number as it happens to be the answer to "life, the universe, and everything". I decided to take the challenge a bit further and make it a Towel Day challenge instead of a weekend challenge. Here is my postmortem.

What Went Right

Making Towel Day an important part of the project was my personal goal of this challenge. Technically, the theme was "Earth will be Destroyed" to make the challenge accessible to those sad souls who are not Douglas Adams fans.  I managed to incorporate the reason Earth is being destroyed, a two headed alien, adding nutrient enrichment to a towel, towels and 42 . Not too bad for a rushed project.

What Went Right and Wrong

The decision to create the game on towel day was a mixed blessing. A game jam is short enough without artificial restrictions. In this case there simply wasn't enough time to add sound and other minor gameplay enhancements such as an unlimited mode. Time limits and other restrictions do help build creativity and let you refine your skills so the extra self-imposed restrictions are useful. To be perfectly honest, though, the real reason for the extra restrictions were the emotions related to creating a game on Towel Day.

What Went Wrong

When I first heard about the challenge, my plans were to create the game using HTML5. I figured that work porting my GameJam library would be useful as it would make it easier to finish the game in time. As creating the functionality of the Flash libraries in JavaScript would be a lot of work, taking advantage of the existing CreateJS library seemed like a good plan. From my experience with this library, it works great but it is still in development. When I ran into issues with the event handling, it became clear that rethinking the jam plans was in order. While I think these issues are JavaScript issues related to the way I am creating classes, they could be CreateJS bugs or some  other code issues I am unaware of so the time needed to solve or work-around the issues was too random to chance it. With not enough time to solve the issues I resorted to my Plan B and created the game in Flash.

Plans for porting Java to JavaScript

When I heard that Oracle is changing their Java numbering convention because all the bug-fixes in Java are causing them problems with their existing scheme, the idea of porting my older Java games to HTML5 gained a lot higher of a priority. While the Canvas is simply not quite there yet, for the games that need to be ported it is more than adequate. I started porting the Ultimate Retro Project as a bit of a test project. Right now my results are mixed. I am using the CreateJS library instead of writing my own low-level library. This gives me the advantage of a class library that is similar to the Flash class library that I am familiar with but the disadvantage of a library that is a work-in-progress.

Unfortunately, there are quite a few old Java games that will need to be ported, so this project will take quite a while. At the same time, I am starting to port my GameJam library to HTML5/createJS and will hopefully start working exclusively in HTML 5 for my web games. I am going to be adding quite a bit of functionality to my GameJam library as I port my older games as there are many classes that can be broadened and added to the library.

In addition to playing around with createJS, I am also starting to look into WebGL. Rumours of Microsoft caving in and supporting the standard would be nice if they turn out to be true, but I have a functional canvas ray-caster that I can always fall back on so a certain series of games will yet again be revisited and hopefully this time I will get around to actually finishing the 5th and 6th instalments.

while I still think that ActionScript3 (Flash) is superior to HTML5, it is clear what direction things are heading in so I am thinking that now is the time to start focusing on HTML5. I am not sure how long JavaScript will last as the dominant web language. If the comities in charge of the language get their act together and create a better version of the language for the next iteration then it could last a while.

Flash Professional CS6

I was really considering staying with CS5.5 unless there was a compelling reason to upgrade. Flash CS6 really didn't provide that reason, but as the upgrade price for CS6 for CS5.5 owners was half the price of the normal upgrade price, it was pretty compelling. When I found out that the Web Premium package was being combined with Design Premium, it would mean that a program that I wanted but couldn't justify was now part of my upgrade. InDesign is a desktop publishing application. With all the additional features in the other apps in the suite, the upgrade became a no-brainer.

If I only had Flash, not a suite, I doubt even the reduced price would have been enough to justify upgrading. I hope that I am wrong, but I really get the feeling that Adobe is abandoning Flash. Still, it is a tool I see myself using for many years to come. Perhaps not as a game development platform, but definitely as a tool for creating animations for the games. With Air packagers and Stage3D, it is possible that Flash will remain a platform for game development. As I have the tools, I have decided that I will play around with the starling framework and possibly try some low-level stage 3D work.

Still, for web development, the move to HTML5 is clear. Thankfully, Flash CS6 provides some tools for aiding in this migration. A few weeks ago I looked at a tool for creating image strips. This functionality is now built right into Flash. Likewise, there is a plugin for converting animations over to the CreateJS suite (which EaselJS is part of). While it is a great feature, it does not convert the ActionScript into JavaScript. Had this capability been in CS6, Flash professional would have instantly become the best tool for HTML5 development. ActionScript is a far nicer language to work with than JavaScript so the ability to write in ActionScript and compile to JavaScript would be well worth the price of Flash Professional. Yet another case of Adobe being blind to what they already have.

The thing is, both ActionScript and JavaScript are derived from the ECMAScript standard. ActionScript just happened to be based on a specification that was abandoned due to politics and infighting. Personally I think JavaScript would have been a much better language for web development had ECMAScript 4 passed. Since the underlying language is the same the version would have been backwards compatible. While I understand that some people think JavaScript should be easier, as the web moves towards JavaScript even larger programs will be created in that mess of a language so thoughts of dealing with large scale programs should be at the forefront as that is what the web ultimately needs.

In fact, the languages are so close that I think a quick porting tool could easily be developed so as a side project for this development blog, in future weeks when I don't have other things to discuss, I will look into the issues of writing such a tool. Even though I don't want to add yet another project to my overflowing plate, I just might develop such a tool as part of this blog. I know in the past I had looked for such a tool and while some projects existed they did not work the way I needed. Perhaps it is time for another look.