Chapter 3: Procedural JavaScrip

One area where Animate is very different from programming in Flash is the scripting language. Flash used a language based on ECMAScript called ActionScript. As browsers don't natively support ActionScript and HTML Canvas projects need scripting, the language you use to program Animate games has changed from ActionScript to JavaScript. Both languages are based off of ECMAScript so ActionScript programmers will have little problems adapting but there are differences between the two languages.

JavaScript is the scripting language that is used by browsers to allow more complex pages. People often confuse Java with JavaScript but they are not the same thing. The name came about when Java was starting to be added to browsers to allow more complex content. Netscape was working on their own scripting language and there was a decision – sources vary on the details – where the scripting language was altered to be more Java-like so Java programmers would also be able to do simpler scripting using JavaScript.

Programming is interesting as it borrows aspects from science, engineering, and art. As a result, there are many ways of accomplishing the same thing. This has resulted in many different methodologies on how to write a program. In the early days, we had procedural programming in which programs are written with one main block of code that may call subroutines. Object oriented programming adds the concept of classes and inheritance, which we will cover in a later chapter.

The core concepts behind procedural programming happen to be the core concepts needed for other types of programming so it makes sense to learn programming from a procedural methodology before going into other methodologies. This chapter will cover the procedural aspects of the language starting with the surprisingly controversial topic of “Comments Controversy”.

The “Variables and Math” section covers the concept of variables and how they are used in mathematical operations. JavaScript is a dynamic programming language which means that variables can change their type.

The main reason for writing a script is to handle situations which have different outcomes based on the current state of the game. JavaScript handles conditional states using an if statement which we will cover in “The If Statement”.  For complex forms of the if statement, we have an easier to read form known as the “switch”

Expanding upon conditional execution is looping. In the “Looping” section we will examine the evil goto statement, the while statement, the do statement, and the for statement. These statements go together with manipulating blocks of variables which we call “Arrays”.

 We will then conclude this chapter with a very brief look at objects in the section surprisingly named “Objects.” This is entering the territory of object oriented programming but is necessary to cover before we start creating our first game in the next chapter.

The Road to Animate

Younger readers may not fully appreciate how much the internet has changed over the years. When I started using the internet in the nineties it was done with a device called a modem which plugged into your phone line meaning that when you were connecting to the internet you were making a phone call to your internet service provider. The modem I originally had was a 28000 baud modem which means it was able to send and receive 28000 bits or 0.028 megabits which is roughly 3k per second under optimal conditions. This is really slow so video was not really something that you would have on a website. Even images were really slow where with large images you could actually see the image being loaded. This is why vector based animation systems actually made sense and why Future Splash was pretty impressive for its time. Instead of sending the bits that make up the image, vector systems would just send the points and edges that make up the shapes. For simple shapes, like those in early internet animations, this was significantly less information than the bitmap representation of the image so could be transmitted much faster.

Future Splash was competing with a technology that Macromedia was pushing called Shockwave which was acquired by Macromedia when they purchased MacroMind for their Director game making software. Macromedia acquired Future Wave, the company that was behind Future Splash, so they could add the vector animation tool to their shockwave platform. This is the reason why Flash binary files have the swf extension which stands for ShockWave Flash.

When Java arrived on the scene Java applets (note that Java and JavaScript are not the same thing) were still thought to be the future of interactive web pages. Browsers were being shipped already loaded with Java while Flash required a plug-in program be downloaded and installed into your browser. The Java craze was so strong that even Macromedia had an optional Java version of their Flash player. I was hired to see if it would be possible to have a Flash game where the animation was handled by the Java-based Flash player and game logic would be written in Java. This proved to be clumsier than expected and pure Java solutions were chosen for the project.

While I think Java could have taken control of the browser, this ultimately failed due to a conflict between Microsoft and then Java-owner Sun Microsystems. Sun wanted Java to be a standard that would work the same on all browsers while Microsoft wanted to be able to make Windows the operating system of the internet and added extensions to the internet explorer version of Java that made it work better on Windows due to the ability to access Microsoft APIs such as Direct X. A court battle ensued, Java on the browser stagnated, and alternatives for Java started being looked for.

This is roughly the time that ActionScript was added to Flash. While not the greatest scripting language, this made the product useful for games and other interactive web content and ultimately replaced Java as the go-to technology for interactive web sites.  I started using Flash and wrote the original Flash Game Development book that this book is based on and everything was good with the exception of the occasional exploit, too many sites having intro movies created in Flash, and many extremely annoying interactive ads which happened to be written in Flash though would have also existed in any other alternative had there been an alternative with a large enough market share.

Flash was still a very strong standard when Adobe bought out Macromedia. Unfortunately for Adobe, things were about to change thanks to a fruity company releasing a phone a couple of years later. While saying that iPhone not supporting Flash was the cause of its demise is not the full story, it was certainly a big factor. The idea of plug-in for browsers was starting to be looked on as a negative factor as plug-ins were increasingly the target that hackers used to attack browsers.

The ultimate nail, in my opinion, was the release of HTML5 and the Canvas API (which if I recall correctly was an API designed by Apple for their browser). This allowed for web developers to do everything that Flash could do right within the browser knowing that all users with a browser could run the program. Granted, the HTML5 apps were slower and larger than the equivalent Flash files, but they worked without any plug-ins.

Flash was not just used for creating web pages, but was still a popular tool for animation studios. With the death of Flash on the browser rapidly approaching Adobe decided to handle the death of Flash by renaming the tool Animate which reflects the target audience for the tool. To help support browser developers, Adobe did introduce the HTML5 stage which allows the creation of HTML5 projects that convert Flash vector objects and animations in to JavaScript using the Create.js library. The ActionScript code is not currently converted to JavaScript so any interactive code must be written in JavaScript using Create.js library calls.

So while Flash is dead, Animate is not and can be used as a tool for the creation of HTML5 animated content. For people who have used the Flash development tools, things have not changed that much and you will quickly find your way around the tool. For those not familiar with the tool, there are several built-in tutorials and a decent manual that can be downloaded.

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).

Drone Defence Postmortem

It is a new month so time for my postmortem of my Blazing Games release for this month. The game is my first game created with OpenFl which is the flash-like library for Haxe. I am not sure why I decided to try doing a similar game to what I did as my Game Maker test game, but I did. The game needs a lot of polish yet, but for the limited time I put into it worked out great.

What Went Right

OpenFL is a flash-like library for Haxe. While Haxe already supports the Flash API for projects exporting to Flash, OpenFL expands this to all the other platforms that programs can be exported to. At least in theory. As I have done a lot of work using the Flash API, this is a great feature for me as it makes getting up to speed with Haxe much easier. If you are not familiar with Flash, this is probably not that big of a deal but it is still a decent library. I have tried a number of different Flash-like libraries for a variety of languages to various results. This library, from what I did with it, worked exactly like I expected (at least until I exported for HTML5) which was nice considering the learning curve that Haxe gave me.

Mixed Blessings

Haxe is a rather interesting language as instead of compiling to machine-language (or a virtual machine-language) it compiles to a number of different programming languages for a variety of different platforms. The idea here is that different platforms have different key languages for development. Windows is C++, IOS/OSX was Objective-C, Android is Java, the internet is HTML5 or Flash. The idea here is that you code in Haxe then fine-tune for each platform in it’s preferred language. It is, however, it’s own language with it’s own way of doing things. While similar to ActionScript, it is different enough to occasionally throw a wrench in the works. One of the nice things it does, which I wish C and all its decedents did, is automatically break switch statements unless you explicitly tell it not to. One thing I didn’t like is the requirement of iterators in for loops.

What Went Wrong

Unfortunately, as is often the case with projects still in development, there are issues with OpenFL. In my case, the HitTestObject method did not work in the HTML5 export. As this is essentially just a bounding box test, I replaced my hit test code with calls to check for rectangle intersections between the bounding boxes for the objects. The problem here then became there always being a collision. After checking the results of the getBounds function, I discovered to my dismay that the width and height of the object were the canvas size and not the size of the sprites. Worse, requesting the width and height of the sprite also returned the canvas width and height. These bugs don’t exist in the other export formats I tried so I ended up releasing the Flash build of the game instead of a HTML5 build like I was originally planning to. I will have to look into this issue a bit more as I really liked OpenFL and think if issues like this can be fixed this would be a great platform to develop for.

Color Smash postmortem

When I heard about the New Year's Game Jam, I thought it would be perfect for my first game of the year. Unfortunately, I had some other plans for New Year's Eve which meant that I had a shorter period of time to develop this game. This is the postmortem for that game.

What went right

When I went to the NYGJ site to find out how the challenge worked, I noticed that they did not specify a theme.  Having the option to do anything is nice but if you can't decide what you want to do then there is little chance you will finish a project within such a short timeframe. Having a plan, at least in your head, is important for really time-restricted projects. Thankfully the site had a theme generator (1GAM had not released their January theme yet so I couldn't use that). While the theme I was given, click the button, was rather generic, it was enough to get me to focus on a whack-a-mole style of game.

Mixed blessings

Knowing that I was going to only have a short period of time to work on this game was both a disadvantage and an advantage. By anticipating a short development time I opted to go with a much simpler game than I would have liked to but it also meant that I was able to finish the game and even get a slight polishing pass.

What went wrong

Perhaps anticipating a New Years Eve party is what caused me to make a rookie mistake but a simple order order of execution bug stumped me.  With Flash, it is important to remember that the last playhead adjustment is the one that gets executed. This means a gotoAndPlay() followed by a stop() is not going to work well. This is a fairly obvious bug, but in my case things were a slight bit more complicated so obvious sequence was hidden from me.

For the lights I dispatch an event when an animation sequence finished playing then going to the default "off" animation to wait for orders to change the color of the lights. The problem is that the event dispatcher actually calls the event handling functions before returning. This means I tell my main game that it is time to start the next animation, which calls the light to set the color to the new value causing a gotoAndPlay() call to the appropriate color appearing animation. When the dispatcher returns, the light goes to the default off animation. Simply by moving the gotoAndPlay("off") call to before the dispatchEvent call solved the problem.

This bug is an important reminder that it is important to think about when things get executed. As the trend of having more cores instead of faster speeds continue, future speed gains will come from taking advantage of multiple cores, meaning that I expect to have to write more threaded code in the future. This makes order of execution issues even more prevalent.

Apple Harvest Postmortem

For the August Ludum Dare #27 I released a simple game called apple harvest. The game was simpler than I would have liked due to what went wrong but it was finished and isn't too bad of a game all things considered. Here is my postmortem of the game.

What went wrong

Unfortunately Ludum Dare #27 happened to take place the same weekend as one of my cousins' was getting married. This meant that instead of having 48 hours to work on a game I only had about 8. This greatly reduced both my options for what type of  games I could develop and the amount of polishing that could be applied to the game. As I really need to work on my polishing skills, this was disappointing.

What went right and wrong

I have been moving away from Flash preferring HTML 5 solutions as they do not require plug-ins. Right now my choice is to use Dart, but depending on what happens with ECMAScript 6 this could change. Still, when there is a limited amount of time, Flash is a bit faster to work with. Part of the reason that Flash is more efficient is simply due to the fact that the art/animation tools are built right in so you are not switching between multiple tools and writing code to load the various assets into the game as that is all handled automatically for you. While I would have preferred a HTML 5 solution, using Flash allowed me to finish the game at a relatively reasonable time so I wasn't overly tired for the Wedding.

What went right

The first thought that I had when I read the theme was a money booth type game. The kind radio shows like to have where you have a short amount of time to grab as much money as you can. Playing around with air dynamics would have been great fun but probably would have taken me more than 8 hours so I had to apply a  Keep It Super Simple approach. I replaced harvesting money with apples. Why apples? I wanted some type of motion to the harvesting and falling apples is what came into my head so I just went with it. The apple life cycle was fairly simple with a flower, then a growing green fruit then a transition to a mature fruit. The transitions had a per-frame probability of  happening adding a slight random element.  Spawning new blossoms was also easy as I just pick a random spot on the trees. If there are no apples near enough then it takes otherwise, no spawning happens that frame. The simple artwork for the apple also got co-opted into the buttons for the menus.

Conclusion

For a very rapid game I think it turned out good. If I do revisit the game I would add multiple levels with quotas per level, and possibly different types of fruit trees.

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.

2013 Plans

I am sure that anybody who regularly reads this blog already has a good idea what my plans for 2013 are, but I figure I should go over them anyway for the record. While I was originally planning on developing Color Collapse Plus over the year, that was before I actually started participating in game jams. I may still work on that project as it was my mothers favorite game, but my priority for 2013 will be on a number of larger commercial projects. As I want to have regular content for the site, I am planning on participating in game jams such as Ludum Dare. The games developed during these challenges will make up the bulk of the site game releases, with the remaining releases being updates of already existing games until I actually finish one of my larger projects.

My larger projects will be targeted towards tablets and possibly smart-phones. The target platforms will be iOS and Android, though I may also port to Windows 8 tablets/phones if the effort will not be too great. Once the tablet releases are done, I intend on porting the game to the browser (probably Flash but HTML 5 isn't inconceivable). The browser versions will be broken into a number of episodes and released in installments.

My game jam work will initially be done in Flash but as my GameJam library reaches maturity (hopefully by this summer) I will port it to HTML 5 and transition to using that if the performance is adequate. While ActionScript and JavaScript are very similar, I am just way more comfortable with ActionScript as it has language constructs that make it much nicer for working with larger-scale projects. Still, JavaScript is quickly becoming the language of the web, though a lot slower than the experts predicted. I personally think Flash will be viable for at least another 3-5 years. If Adobe gets their head out of their butt and create an ActionScript to JavaScript compiler it may be significantly longer though the resulting Flash programs would be "native" HTML 5. Sadly I suspect that Adobe will let Flash whither away and instead try to turn their new Edge Animate software into the replacement for Flash.

I have not decided which games I will be updating, so if anybody reading this feel free to email me with your favorite game and I will put that game on the top of my update list. Updating will include cosmetic updating as well as (for Java and Flash games) porting the game to HTML 5.

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.

TMoD episode 4: Space Shield

When researching different disasters the idea of a solar flare was high on the list. The big problem was finding a classic-style arcade game that would work with the theme. Thinking about how to stop a solar flare lead to the obvious placement of satellites, even though realistically you would need way too many. Placing satellites immediately got me thinking of the space junk problem that we are having. This immediately got me thinking about the road-crossing games I played on my cousins Atari 2600 so the game was set.

One of the big issues with the game was the collision detection. Unfortunately, Flash does not have per-pixel collision detection (at least not built in to Flash Player 10, I haven't researched Stage 3D or Starling enough to know if Flash Player 11 does). The object detection is bounding box based. Point based detection does support a per pixel option so I set off on my task to write a simple per-pixel collision detection routine. I originally opted for a simple brute force approach. Flash let's you find the bounding box of a clip relative to a container, so getting the bounding boxes of the two colliding objects then finding the intersection of the two objects is easy. My thought was then to look though the points in the intersection rectangle to see if they both flag collisions at the same points and are therefore overlapping.

In my tests this worked great. The problem is that my tests used vector shapes. When bitmap images were used, anything within the bitmap bounding box was flagged even if it was transparent. There is really no excuse for this other than lazy or incompetent programming at Adobe. This meant that I would have to look at the bitmap data myself. Sadly, this is not a very efficient thing to do.

To get the pixel information, I need to draw into a bitmap data object. This first requires getting a copy of the transformation matrix used to draw the display object. Thankfully this is easily accessible. Next, a translation is applied to only draw the intersection portion of the image. The drawing is done. Repeat for the second object in a second BitmapData object and then compare the pixels in the two bitmapData objects. As this is done using a getPixel function call repeatedly, I honestly can't see this as being very efficient. Then I remembered an article I read about using color filters. This got me thinking about how I could get rid of one of the bitmapData objects  and combine the two images into one.

First, you set the bitmapData background color to black. The draw function supports color filters making it possible to max out or clear a color channel. By maxing the red and green channels while dropping the blue channel of the first image then dropping the red channel of the second image while maxing out the green and blue channels of the second image while drawing it over the first image using the ADD filter you will end up with white pixels where the two images overlap. There is actually a built in routine for finding a bounding box containing a particular color so finding the overlapping pixels is easy.

This is not the best way of doing the collision detection, but it works. There are some edge cases where it won't work, but that isn't a problem in this game. It is sad that such a straightforward thing requires so much work.

Porting Deadly Dodge Ball

I have been slowly moving away from Flash towards HTML 5 for a while with 12 Months of Doomsday most likely being my last Flash project. It is certainly possible that Flash CS6 will somehow convince me to keep developing for Flash, but Adobe has pissed me off quite a bit the last few months so CS6 would have to have extremely impressive features (or a really cheap upgrade from CS5.5) in order to keep me as a customer. For this reason I decided to port my Friday the 13th project from Flash to HTML 5. If porting from Flash to HTML 5 wasn't enough, I thought it would also be a good opportunity to play around with EaselJS, which is a Flash-like animation library for JavaScript.

The reason I thought about using a third-party (open source) library instead of cleaning up and building on top of my own is simply due to the fact that going forward I am going to have less time to spend on my site as I am going to be focused on developing some mobile games. By using a third-party library, I don't have to worry about the low level graphics code and can focus my limited time creating games. There are a lot of choices available, but I decided to go with EaselJS because it is similar to Flash and is being used by a couple of other projects so it has some chance to stay around.

EaselJS is not vector based, but instead relies on image strips. Flash has a feature that lets you export an animation as a series of image files so I used this feature to create the fireball. This left me with a large number of files that had to be combined into an image strip. Sure, it is possible to load the images by hand into a paint program and assemble the image strip but there must be a tool that does this. A quick search for such a tool lead me to Texture Packer. While this is a paid tool, it does have a free version that simply restricts you to the more essential features. This provides enough capability to create image strips for games. As I happen to write a development blog, the author of the tool was kind enough to give me a key for the full version. With that disclaimer out of the way, I do suggest that if you need to take a number of individual frames of animation and turn them into an image strip that you take a look at this tool.

With the movie clip converted into an image strip it was fairly easy to move the code over to JavaScript.  The big difference was that the stage does not automatically update itself but requires you call an update function. This is not that huge of a deal as there is a built-in timer class that lets you call a tick function which can be used to call the stage update function. Of course, you also have to remember to change getTimer() into Ticker.getTime() and a few other minor differences, but overall the library feels enough like Flash that it was not too difficult to transition to. It is certainly a library that I will be playing around with in the future.

For those of you interested in either of these tools, EaselJS is located at EaselJS.com and Texture Packer is located at www.texturepacker.com.

Flash Image Atlas Animation System. Why?

This was suppose to be posted on Sunday, but with my mother going into the hospital, I kind of forgot about posting it. Sorry for the delay.

As part of my larger project, I have decided to develop my own animation system. As this larger project is currently being done in Flash, which is essentially an animation system with a powerful programming language tacked on to it, this may seem redundant. If I knew for sure that the project was going to be exclusively done in Flash, it would be. The truth is that I may end up having to port the game to other devices. While Flash is sort of runnable on portable devices, the performance currently isn't quite there. If, when my game is in a near finished state, the game runs fine on the target devices then there is no issue. However, this is not necessarily going to be the case so I have been looking into what would be involved in porting a game by creating a native version for certain devices.

OpenGL ES is pretty much the standard for all the devices I am thinking about targeting. While studying OpenGL one common optimization that comes highly recommended is to combine the textures that one is using into something called an image atlas. As it turns out, an image atlas is a more advanced version of image strips (aka sprite strips) and image grids (aka image sheets or sprite sheets). Image strips/sheets are what I was using for my Java games so I am well versed in the technique.

A lot of the artwork for my larger-scale game is bitmap graphics so  creating a library that allows for an image atlas to drive an animation would be convenient and make porting easier. Spending a development week or two to get this functionality is really not much of a loss while the benefits are potentially great. I define a development week to be 40 hours which is a typical work week in Canada. As my work on the large scale game is part time, it may take two or three weeks in real world time for a development week. I plan on porting it to HTML 5 and possibly other platforms. Not too long ago I created a simple image atlas class for my HTML 5 JavaScript graphics library so an HTML 5 port so the HTML 5 version should be fairly quick to develop. This will give me a common set of components that will make it much easier to switch between platforms. While I personally believe that Flash will be around for a while, having an easy path to other platforms doesn't hurt.

In fact, with Microsoft not supporting Web GL in IE 9, any web-based will have to use a plug-in such as the upcoming Flash 11 to support 3D graphics in a cross-platform way. While Microsoft is claiming security issues (WebGL is fundementally far more secure than Microsoft's Active X which is still in IE), I hear that in Windows 8 there will be browser support for accessing Direct X 11. Since Direct X is essentially a less-secure version of Open GL (what WebGL is based on) I am wondering what Microsoft's true motivations for not supporting WebGL are. Still, I see the future of 3D on the web being Flash. Ideally it will be a WebGL with fallback to Flash future but more likely it will be just Flash with paid iOS apps for Apple users. Thanks Microsoft.

Why I Use Flash

There has been a lot of negative press about Flash lately, so I thought now would be the ideal time to take a look at why I am using Flash. Before I begin, though, I should first point out that much of the hatred of Flash seems to be oriented around Flash based ads. If you hate Flash for this reason then you are in desperate need for either medical help for your brain or are needing to learn critical thinking skills. Flash is used in advertising because it has the animation capabilities and interactivity that advertisers want and it is in use by over 90% of the browsing public. When HTML 5 becomes that dominant, then all the ads will be done in HTML 5 with its much slower JavaScript eating up processing cycles far worse than Flash ever could. As long as people do not want to pay for the content they are consuming (bandwidth may be cheap but the time to create the content certainly is not) then content creators need to find other ways of getting enough money to put food on their table and advertising is the dominant way of doing this.

The reason I use Flash for my games is that it is currently the best choice available. JavaScript is painful as different browsers run it differently and until HTML 5 it lacked a lot of the necessary capabilities such as the Canvas tag. Even after HTML 5, JavaScript is going to be annoying to work with, but I think that this is where things will eventually lead so I am slowly going to transition to it. Nobody wants to install plug-ins (especially from small companies like Blazing Games) so writing stuff in C is out of the question. This leave the option of relying on a plug-in that people will already have installed on their browser. The two choices here are Java and Flash. An upcoming choice may be Silverlight, which I dread as I do not trust Microsoft ("DOS isn't done until Lotus won't run" among thousands of other reasons). I wish Unity was on this list but don't see this happening. If it does, then there may be a transition to that but since it uses JavaScript that won't be that big of a change.

I choose Flash over Java largely because Java stagnated and has more compatibility problems between versions than Flash. More important, at least for a game development perspective, is that Flash is a really powerful animation system. ActionScript, the language that Flash uses, is based on the ECMAScript standard that JavaScript is and is a pretty decent language. I do wish that it had better thread support like Java and more 3D support (there is some 3D support in Flash Player 10+ but it is very limited).

CS5 is coming

Right now I am using Adobe Creative Suite 3 to aid my development, not bothering to update to CS4 due to the fact that while it had a lot of nice features, I didn't think those features were worth the hefty upgrade price. While I can not say whether it is worth upgrading from CS4 to CS5, It seems like it will be well worth the price to move from CS3 to CS5. While I am slowly going to be migrating from Flash to HTML 5, I still think there is enough life in Flash to make one final upgrade. Getting Dreamweaver, Photoshop, Fireworks, and Illustrator also helps but the biggest addition to the package was Flash Builder 4 (formerly Flex Builder) and its integration with Flash CS5.

As I have said in the past, I think that Flash will slowly fade away as HTML 5 starts to take off. Still, there is a lot that you can do in Flash that you will not be able to easily do using HTML 5. Until the still dominant browser is HTML 5 friendly, which IE8 is not, Flash is still important. Even after this point, Flash will still be a good prototyping tool. Especially when you consider ActionScript and JavaScript are both based on ECMAScript.

Adobe, obviously, will not just stand by and let Flash die. The question is what will they do to salvage it? Some suggest turning it into a tool for creating Canvas or SVG code. Others think that new compelling features will be added that the various HTML 5 additions simply can't support. AIR is certainly a factor. While I haven't created any AIR applications yet, that could possibly change. The key question for me, however, is does the added features of a proprietary platform out-weight  the open standards enough to warrant its use? HTML 5 is a balancer, but more weight on the Flash side could tip the scale. It seems we are still living in interesting times.

Does Apple hate Adobe or Developers?

I was thinking that perhaps I should wait until tomorrow to make a post. April 12th is when Adobe is going to officially announce the Creative Suite 5 lineup. I am hoping that something big is going to be announced tomorrow but think that perhaps the iPhone OS 4 rumors may have dampened Adobe's plans. One feature that they were planning on having for Flash CS5 is an iPhone exporter that would convert Flash apps into iPhone apps. Sadly, the iPhone SDK license agreement (required to use the iTunes store) may be specifying that apps must be written in Objective C or C++ and that API features must not be accessed through third party libraries. This effectively rules out using Flash to develop iPhone apps. It also rules out other tools like Unity.

I think the real reason for doing this is to force developers to develop specifically for the iPhone/iPad. Flash being able to export to iPhone would circumvent this requirement making it easy to develop cross-platform applications. While Unity also allows this, it has a much smaller developer base as compared to Flash so Apple probably didn't even notice it yet. In other words, this attack against Flash isn't actually aimed at Adobe, but it is instead an attempt to make it much more work for developers to create cross-platform versions of their apps. Right now, the iPhone is in a dominant position, so developers pretty much have to support it. This is just like Windows is the dominant platform for PCs which is why there is so much Windows software.

With Android continuing to gain market share, one has to wonder if this is a good long-term strategy for Apple. Right now, the major player is the iPhone, but with all the hassle and inconsistencies with the approval process, how much market share will Android have to gain before it becomes the better choice for initial development? In the computer industry, Apple was the dominant player with the Apple II, but that quickly changed when IBM created an easy to clone PC that numerous companies copied (today's PC) resulting in Apple slowly becoming a niche player. When companies start developing for the Android and then deciding if they should bother porting their app to the iPhone,  we may again see Apple become the niche player but this time in the mobile market.

April Fools 2010

Here is the text of the April Fools message that was posted on Blazing Games. Note the first letter of each sentence and the date at the bottom. I (Billy D. Spelchan) am still president of the company, and as this month's release shows, we are still slowly transitioning to HTML 5. Flash will probably be our main development tool for the next few years, though.

At Blazing Games, we are proud to announce a deal between ourselves and Microsoft. Sadly, Billy D. Spelchan has agreed to sell his shares of the company and has terminated his position as President of the company, we wish him best of luck with his future endeavours. 

Part of the deal will require that all of our Java and Flash games be replaced with Silverlight versions of these games. Work on this transition has already begun and the non-silverlight games should be removed from the site by the end of this week.

Rich Internet Media in the form of Silverlight is the future of the internet. HTML 5 features simply do not match the power and potential of Silverlight. Our former president's views on open standards clearly are outdated.

Internet Explorer will become the browser of choice for viewing Blazing Games. While we will not be taking any moves to prevent users of other browsers from accessing our site, testing will only be done on Internet Explorer 8 running on Windows 7. We recommend that visitors upgrade their machines to Windows 7 as soon as possible.

Lots of people, such as our former president, have the mistaken feeling that making a deal with Microsoft is the equivalent to selling your soul to the devil. We hope that crazy superstitions such as that are not going to impact our existing visitors enjoyment of this site.

For those of you who feel you can no longer support the site, we thank you for your consideration for other people by making site bandwidth available for the countless new users we will be receiving from a high placement on the Bing search engine. Clearly Bing is vastly superior to that googol thing that our former president used.

Our open source efforts will continue, though we will be switching from the virus-like GPL license to the much more business friendly Microsoft Public License (Ms-PL).

OSX users do not have to worry about Silverlight as Microsoft has assured us that they will always support the OSX version of Silverlight. While not all the advanced features of Silverlight will work on the Macintosh, OSX users always have the option of purchasing a copy of Windows and installing it on their Bootcamp partition.

Linux users are urged to give up their anti-capitalist ways and install Windows on their computers as that is what their machines were designed for. Those Linux users who are running old, obsolete hardware should do their part to restore the economy by purchasing new hardware capable of running Windows 7.

Small changes to our games, such as changing the One of those Weeks' Blue Screen of Death into the Linus the Penguin of Doom and changing Coffee Quest into Clippy Quest will be done at the request of our generous corporate partner but feel that such minor changes will not alter the enjoyment of those games.

M. Caton
President,
Blazing Games Inc.
April 1, 2010

The path to JavaScript

When I first started web game development last millennium, the landscape was quite a bit different. Java had just come out and was being pushed as the next-best thing in web development. While there are a lot of programmers who hate Java with a passion, a large chunk of my savings account is the result of third party work I have done using that language. At the time, Netscape adopted Java as the way to make the internet more interactive and even altered the browser scripting language they were working on renaming it JavaScript. Sadly, largely due to a battle between Microsoft and Sun, use of Java in browsers never became the dominate force it should have.  Java became more of a server side or back-end language with a lot of businesses adopting it.

On the browser side, Flash seemed to grow. This was largely because Flash was flashy. Flash was designed to be a vector animation program but added scripting and in Flash 5 an ECMAScript based scripting language called ActionScript. ECMAScript is the name given to the standard for JavaScript. Purists are free to correct my oversimplification of this but I am a programmer not a bureaucrat. Still, the scripting language that Flash uses is essentially the same as JavaScript.

I have dabbled with JavaScript in the past, but have never attempted to create a serious project in it. Still, with my ActionScript background, I figured it should be a piece of cake. Syntax-wise I was correct. DOM-wise, I couldn't have been more wrong. The DOM is the Document Object Model. It is essentially the API for browser-based JavaScript. I could not find an Java-Doc style guide to the DOM, which may be part of my frustration.  The part that really annoys me is how different the different browsers are at supporting it. Code that works great in Firefox and Safari does not run in IE. This means that I have to test a lot more than I would like which is why I think it may be a while before HTML5 replaces Rich Internet Applications written in Flash, Java, or other  RIA platforms. This is really too bad as I personally think open standards are better then proprietary platforms.

Still, next month will be my first JavaScript game. Working in it has certainly been interesting. One thing I will be looking into is better JavaScript libraries that make it easier to write cross-browser code. There are a lot of them out there, though the two I keep hearing about are Dojo and jQuery. I am not sure how necessary this will be as most of my stuff will be using the canvas for the user interface. That said, Flash CS5 is probably still in my future but I am going to slowly try to move to JavaScript for my client side programming.

Toronto?

With today's release of One of those Weeks episode 45, there is only one more episode left in the series. I am planning on finally finishing One of those Weeks next month, though it will be a while before all the episodes are released as open source and all the chapters from the making of book are released. As those of you who filled out the poll on BlazingGames.com already know, I am considering writing a proper novel based on the game. When you consider that the game is based on an outline I wrote for a novel that I was considering writing, this would be an appropriate end to the series. If I do decide to do this, I would probably not release anything until the novel was completely done and then release the novel under a creative commons license. The time spent on the novel would be separate from the hours I am allocating to the site so don't worry about it taking away from the site because it wont.

This episode is actually rather interesting as it is the texturing version of my ray caster ported to Flash. This could be thought of as a proof of concept that I could get Coffee Quest 5 working in Flash, but now that Flash 10 is out and has some built in 3D support this is probably a moot point as using the built in Flash 3D primitives will probably prove to be faster than doing the ray casting. When I have time this will be something that I will be looking into.

An annoying Flash issue

While I am doing a lot of Flex development, I plan on still using Flash for the creation of animations. More importantly, my One of those Weeks series is being developed in Flash. There are only a few episodes left so there really is no point in moving that series to Flex. Flash and Flex are very similar, which is not surprising as they both produce code that is run in the Flash Player. Flex, however, is entirely driven by text files. While FlexBuilder has a graphical editor that helps you layout stuff, all the GUI work ends up being turned into an MXML file which is a text file. Graphics and other assets are separate files and can come from any tool. Flash, on the other hand, uses a binary format which embeds all the graphics. ActionScript code can be separate text files, which is what I have been doing.

When I was finishing up One of those Weeks episode 44, I came across a rather interesting bug. This was not really a bug in my code, but more of a quirk in the way that Flash handles animation. I had come across this quirk before so it didn't take me long to figure out what was going on. You see, when the player has solved the episode, there is a brief animation sequence that starts by zooming in on the background. Unfortunately, the background in this episode is scrollable by the user so the position of the background movie clip is changed by code. Flash, for some reason, does not handle hard-coded animations with symbols if that symbols location has been changed by ActionScript. The results were rather interesting, but not the ending sequence that I wanted.

Sadly, the only solutions were to use a different symbol for the animation or to do the animated sequence using ActionScript. If I was using Flex, the later approach probably would have been my approach from the outset. In Flash, though, it is easier to just create another symbol of the background and use that for the animated sequence. Actually, if I was doing this in Flex, I would have probably created a Flash .swf file that held all the assets and the end animation sequence would have just happened to be one of the assets as while Flex is much nicer for coding, Flash is way better at animation.

Thirteen Spikes and the Flex decision

One of the nice things about this year's site format is the simple fact that most of the posting work for the weekly update is done on the first post of each month. This means that posting Thirteen Spikes Unlimited, which has just been posted, doesn't take too long. This is a good thing as this is one of the rare occasions when I was taken out for supper so I was late posting the site today. Because everything was ready to go, however, it only took minutes when I got home to post the update for this week.

While I know that you should never drink and blog, I am going to make an exception today as I do want to explain my Flex decision and think that since Thirteen Spikes Unlimited was created using only the freely available Flex3SDK and jEdit for editing. While the remainder of One of those Weeks will be created in Flash CS3 and the remainder of the Ultimate Retro Project will be finished using Java, future projects will be created using Flex. Flash will be used for asset creation but the projects themselves will be compilable using the freely available Flex3SDK. In a couple of years I will take another look at the browser landscape and possibly change my development direction, but right now I am going to be focusing on Flex development.

I have been playing around with a number of different languages and quite frankly am sick of having to shift my gears when switching between projects that are in different languages. Having all my work done in a single language makes my work easier. If a paying client wanted me to do some C++ or Java work for them then I would certainly do so but for Blazing Games and other programming I am doing in my spare time then the work will be done in Flex unless there is a very compelling reason to use a different language.

I really do not trust Microsoft, so even though Silverlight 2 has some really nice aspects to it unless I am being paid to use their platform I am not going to do so. Java still has a place in my heart but I feel that Sun just dropped the applet ball and FX is too little too late. Still, this is one case where I would like to be proven wrong. HTML 5 is no where near being a finalized standard so I might as well focus on Flex while I wait for it. Other browser based game development plug-ins simply do not have the installed base.

I have already pointed out numerous times that Flash CS3 is expensive, while Flex has a freely available SDK. Flex produces Flash output and I can still use Flash for the creation of assets and animation.