GameJam library release 0.01

For 2013 I plan on focusing more on my larger scale potentially commercial projects with Blazing Games content coming from game-jam competitions such as the Ludum Dare challenge that is taking place this weekend. As these challenges allow for use of your own libraries as long as they are shared before hand, I am planning on creating a GameJam library to make it easy to create games quickly. The first release of this library is located at http://blazinggames.com/other/openLibrary/html5Libs.php but I don't recommend anybody use it yet. This is still a very primitive release. For those who are curious, I am going to outline my plans for this library.

First, I want to get basic 2D game elements, such as scrolling maps and multiple layers of sprites fully working. This is mostly there but the code needs a lot of cleaning yet before I would be happy with other people using it. I suspect that seeing where things need improvement while participating in a couple of game-jams will get me to the ready for consumption point.

Once this is done, I will add a couple of kits to the game focused on the major elements of common Genres of games. The idea here is that there would be core mechanics for a number of types of games that can be mixed and matched. That way if I go into a game-jam and think that a RPG would be ideal, the core elements such as character sheets, inventory systems, conversations, dice rolls would all be ready to go so I could get the game skeleton done in a few hours and spend the rest of the competition focusing on the content of the game. Essentially, I want the ease of a game-making tool yet with the flexibility of total control of the code. More important, at least to me, I want the library to be mine. I am making a slight exception to my-own-code ideal by using the starling library for 3D acceleration of the 2D graphics but when I get to my final step in this project, that will not be the case.

Once I have the ActionScript library in a stable state, I will port the library to HTML5. The decision to develop the library in AS3 initially is due to the fact that I can get something useful much quicker as I am far more comfortable with ActionScript. As the world is shifting to JavaScript, it only makes sense to shift development to that platform. I will probably have both Canvas and WebGL versions of the sprite/map renderers to take advantage of hardware on browsers that support WebGL while still allowing IE users to play the games.

I have no timeline for the library (and am actually not putting in as much time towards the library as I hoped) but plan on updating the library before every game-jam that I plan on entering.

Zombie Starlings

While I might have been able to do more with this game had I used the Alein's Zombie game engine as my starting point, I decided to give the Starling framework a shot so spent a good chunk of time porting my existing code over to Starling. Actually this is probably not a big waste as I am going to be using this code as part of my Game Jam library that I am developing for use in future game jam competitions.

One of the reasons that I have decided to experiment with the Starling framework is simply that it is the sister-framework to the native iOS Sparrow framework. My thought is that I can do my prototyping in Starling as I am still fairly productive in ActionScript. If it proves to be too inefficient,  the option of going native is much easier as the frameworks are similar enough to make the porting of code very quick.

The map rendering was greatly modified when porting my old map code over. The old way I handled the map was to simply create a large sprite made up of tiles and simply moved this larger sprite around to scroll the map. While I am sure this technique could be used for Starling, the larger-scale games I am working on will require really large maps. As the size of these maps could exceed Flashes size limits, I opted to go with a slightly different technique.

I create a large sprite that holds just enough tiles to be one tile larger than the screen will hold. The tiles are set to the map tiles that correspond the top-left corner of the screen. Every time the map is scrolled to the point where one of the edges of the viewport sprite is visible then the map is repositioned and a new set of textures are assigned to the tile. This allows for smooth scrolling while not having to worry about size restrictions. It also requires a lot fewer sprites to be created which helps with memory and speed.

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.

Thirteen Spikes Unlimited 1.0

Thirteen Spikes Unlimited is now finished and has been on the Blazing Games site since Friday the 13th. As I have mentioned before, there was some plans to port the game over to HTML 5. ActionScript and JavaScript are very close as they are both variations of ECMAScript. This makes the game logic very quick to port, even if JavaScript does not have as nice of class or variable support as ActionScript. The other thing that ActionScript has that JavaScript lacks is the Flash library. Because Flash was created as a streaming vector animation system, this library is greatly tied to graphics and animation. The HTML 5 Canvas simply does not have these classes, but there would be very little stopping someone from writing them. In fact, to implement Thirteen Spikes Unlimited, only a small subset of the class library would be needed.

This would require a bit more time than I have, so the port to HTML 5 didn't happen and instead themes, campaigns, and sound were added to finish off the 1.0 version. This does not mean that the next Friday the 13th won't have a HTML 5 version of this game. That would be May of 2011, so depending what is happening with my current projects (one which may be doomed) this might be an interesting project. So, while Thirteen Spikes is finished for now, it may resurface in the future.

A tool for porting to JavaScript?

Porting code by hand from Java to JavaScript/HTML5 was a rather interesting experience as working with JavaScript is not what I would call a pleasant experience. The language itself is similar enough to Java that writing or porting the code was trivial (more on that later) but the problem I had was with the debugging of the program. JavaScript is not a typed language and doesn't even require that you explicitly define variables. While this makes it easier to write simple programs (which is what a scripting language is for, after all) it has the downside of being very problematic for larger projects. The problem is that you don't have to explicitly define a variable to use it. This means that if you have a variable named java but later in your code miss-type it as jave then the program will sill run but you will have a very hard to find bug. Bugs like this are caught by the compiler in Java and ActionScript. Then there is the fact that JavaScript class support is barely there and largely has to be done by hand reminding me of my C programming days, though not quite as bad as passing structures to functions.

While the rich internet application platforms (Java, Flash, SilverLight) are ideal for such large projects, they are proprietary and are not universally supported. The direction things seem to be going, it appears that JavaScript is going to become the standard way of creating interactive HTML pages.  There is a ECMAScript 6 draft (formerly ECMAScript 4) that comes a long way towards solving a lot of the issues with creating a larger project in ECMAScript derived languages (like JavaScript). ActionScript 3 is based on this which makes it much nicer to work with than JavaScript. This got me thinking about tools for porting from one language to another. If I did my work in ActionScript 3 and then used a tool that ported it to JScript (Microsoft's version of ECMAScript which also happens to be, in my opinion, the worst implementation and therefore the lowest common denominator for porting) then I would have much greater productivity. This got me thinking about how hard such a tool would be. As the languages are so similar, this wouldn't be too hard. Especially if one was only concerned with a rough port and not a perfect port. This then had me look to see if anybody has already done this. I found two projects. Jangaroo and Mascara. Jangaroo is an ActionScript to JavaScript compiler, while Mascara is a ECMAScript 6 to JavaScript compiler.

Jangaroo is closer to what I envision, and is free. Mascara requires commercial users pay for it but is free for non-commercial use. There is also the option of writing my own tool that does exactly what I want. This is probably the worst choice as it eats up my already over-allocated time but I always wanted to write a compiler and this project would at least get me part way there. I will take a look at Jangaroo and hope that it is close enough to what I desire that I don't start yet-another-side-project as I am trying to get out of that really bad habit.

Why ActionScript and JavaScript are Slow

Slow is a relative term. Compared to the Commodore 64 that I use to program, today's computers are incredibly fast. Still, a lot of complaints about JavaScript and ActionScript (the scripting language Flash uses) is how slow they are. While both ActionScript and JavaScript use JIT compilers to greatly improve the speed of the code, there is overhead in compiling. Some proponents of "real" programming languages will say that this is still not as fast as a proper compiled language would produce. As someone who has programmed in a variety of Machine Languages, I should point out that compiled languages do not produce as good of code as hand-coded assembly language will produce. Some compiler makers claim that their compiled code is better than what the average assembly language programmer would produce. This is possibly true if that assembly language programmer was converting the higher level language line by line into assembly language like a compiler does, but if he or she is writing the routine from scratch the results would likely favour the programmer.

While some of the speed difference can be attributed to the nature of JIT compiled code, I think the bigger problem is that both ActionScript and JavaScript were designed to be easy to write code for. Remember that although these languages are now being used for more serious projects, they were intended to be for adding more flexibility to web pages or animations. In theory, these languages are suppose to be accessible to anybody, though if you look at more complex project, it is clear that real programming is still at the heart of these languages.

Concepts like dynamic objects definitely make these languages far more flexible than older languages like C/C++ but flexibility has a lot of overhead. Instead of just calling a function directly, the language has to go to the object in memory and find the pointer to the function (as it may have changed from the default one) before making the function call. It may not be much of an overhead, but it does add up. Then there is the issue of the libraries included with these languages. Using Strings for a lot of things that other libraries would have used integers for has a drastic effect on performance. If you used an integer, you would have one quick comparison to do. When you use a string, each letter of the string has to be compared. Using strings certainly makes it easier to program but there is a big cost in speed.

I could probably go on for pages, but ultimately, what it comes down to is that these languages are easier for humans to write code at a cost of efficiency, but as JIT compilers get better, the difference is not as great as purists would like to believe and the much greater productivity that results probably outweighs the speed costs.

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.

Dozen Day Plans

Before I get to the bulk of this post, I'll just let you know that Classic Light Box has been posted on Blazing Games. I don't know if I would consider this entry as an article, more like an update on the plans for Blazing Games. In particular, I am going to give some heads up details on what I am planning on doing with my Dozen Days series.

At the start of 2008 I was going to use the dozen days project as a monthly game release that would be developed live on the site. Two episodes were developed live on the site, but there seemed to be very little interest in the live aspects of the release. When you add the fact that developing the game live adds addition stress to an already stressful development the lack of interest makes doing the episodes live not worth the effort. More to the point, when I did the second live game, I did so when I was sick and had a really hard time doing it with the easy game taking twice as long to write as it should have. Had there not been a live aspect to the development, I could have simply put off the development by a week or two and done the proper thing by taking the day off.

As regular visitors already know, I am currently spending Sunday afternoon working on Ultimate Retro Project and at the moment development on those episodes are on fire! This means that I am filling up all of my Friday release slots at a rapid rate so don't really need to have any Dozen Days episodes. I have also decided that keeping the source code closed for a game in a day project does not make that much sense and all future releases of Dozen Days episodes will have the source code as part of the release. That being said, for the next three months I am going to be releasing the source code and diaries for the first 6 episodes!

The first six episodes were developed using Flash CS3, which is not the most open source format to use due to the fact that Flash CS3 is an expensive tool. That is why I am going to be making a transition from Flash over to writing pure ActionScript 3 games that can be compiled using the freely available Flex 3 SDK. Vector graphics and animations will probably still be created in Flash CS3 but because those assets are strictly artwork resources it would be easy for somebody to replace them without needing an expensive tool.

Before I make the switch for Dozen Days work (which will happen with the development of the official seventh episode even though technically it is the eighth episode created for Dozen Days of Dice) I am going to first create a different game using the Flex 3 SDK for compiling the game. This game is going to be an updated version of Thirteen Spikes. Obviously, I have great hope that this game will be finished before June 13 for reasons obvious to anybody who owns a calendar.

After June I am hoping to release new episodes of Dozen Days every month or so and will probably have sneak previews of those games available for readers of this blog.

One of those Weeks Episode 34 posted

Even though Episode 34 of One of those Weeks was delayed a couple of weeks, I never got around to adding a score to the episode. Even though the episode doesn't look that different from other episodes with conversations, a lot of work has been happening on the underlying conversation system. This work will continue throughout day 6 episodes, and the result will be a system that will allow much more elaborate conversations without all of the coding work. While the system is Action Script 3 code, it should be trivial to port the system to other languages. This means that if I ever switch to another language, the conversation system will be ported to that language. Considering how much M$ is pushing Silverlight, it is certainly possible that I will be developing Moonlight applets in the future. Moonlight, for those who don't follow open source, is the Mono-project's open source version of silverlight, with the mono project being the open source version of M$'s .net.

Why don't I use C

With all my ranting about the limitations of Java applets and Flash, one must wonder why I simply don't use C. I use to do a lot of C programming in the past for the simple reason that it is a lot faster to write code in C than in Assembly Language and the code is much easier to port. While Java and ActionScript are easier than C, they are not that much easier so one has to wonder why I am being such an idiot and sticking with Flash when if I moved back to C I could quit complaining about the limitations and start writing multi-threaded games that took advantage of hardware 3D.

The biggest factor has to be the simple fact that I want people to play my games. If people had to download the games and run them on their computer, the number of people who would play my games would drop, probably drastically.

The second reason is that I then have to worry about which operating system I am writing the game for and have to deal with porting the game to other operating systems when it is done. This is starting to become a non-issue as there are many cross-platform libraries now available and many of them are open source.

The third reason is that by having the game on my own site, I never have to deal with versions of the game. If I make an improvement to a game (or fix a bug, not that my games have any of those) then that version gets posted and everybody is immediately using the latest and greatest version. Anybody who has had to answer complaints about version 1.0 when the issue was resolved in 1.1 and the current version is 3.0 knows what I am talking about.

Still, once I have finished my current list of projects (One of those Weeks, Coffee Quest revenge b4 5 and 6, Dozen Days Pentalogy, and the Ultimate Retro Project) I will probably take another look at going to C for my next project.

One of those Weeks

Tomorrow evening I put together the final tally of the One of those Weeks related site poll. This poll is actually going to be more important than voters expect, and is a really close vote so if you haven't voted yet go to BlazingGames.com and cast your vote. At the same time as the results are announced, you will be able to play the final episode of Day 4.

Episode 28 is a special episode as it is the last episode that is going to be compiled for the Flash 7 player. Day 5 is going to be using ActionScript 3 and will require Flash Player 9. While it would certainly be possible to keep the rest of the series in Flash 7, ActionScript 3 is different enough from ActionScript 2 that I really don't want to have to worry about which version of Flash I am working on so all my Flash projects are going to be written in ActionScript 3 and therefore will require Flash Player 9. I don't think this is a big deal as most people can run Flash 9. The few of you who can't, well, I apologize but it is the logical path to take.

I suspect that future entries will cover a bunch of the migration issues and some of the nice features that Flash 9 has. I actually like Flash CS3, though still wish that the code editor was better. If Adobe were to drop the price of FlexBuilder when version 3 was released, I would really consider getting it and using it for my code editing while using Flash CS3 for all my animation work. At the current price level, however, I really can't justify the cost. I should also point out that FlexBuilder is different from Flex SDK (which is free).

Flash Bitmap automap

At the moment the amount of spare time I have is very low, and to make matters worse I am taking a drawing class. I am hoping that they will help me get my artwork up to a much better quality than it currently is. As with every other skill, the key is practice but knowing what you are doing wrong certainly helps.

I am still going to put an effort into getting my 10 hours of work on the site selected project, with any slippages of hours being rolled over to the next week's total. I did manage to finish a rough automap render but it only paints a test pattern as the map classes aren't developed yet because I decided that I wanted to make sure there would be something to post this Friday. This was done a bit different from the way I have normally handled such maps in Flash. Flash 9 has a Bitmap Data class which I am taking advantage of. Technically, this was introduced in Flash 8, but I am jumping from flash player 7 content to flash player 9.

The BitmapData class lets you use an image which is loaded with a separate loader class. I am not sure why you need a separate class that handles the loading of an external image, as it would make more sense to me to have this functionality part of the Bitmap or BitmapData class. Once copied into a BitmapData class, clips from the image can be easily copied to the bitmap used for the automap. This should be fairly fast as I believe the BitmspData class is able to use hardware acceleration, or at least native code for bitmap clipping.

At this point I have a test pattern being displayed, using the 16 tiles that the game uses. If I get around to finishing the map classes before Friday (assuming they can be done in less than 10 hours) I may have a proper map this friday, but if not I will at least be able to post the game running the test pattern.

Fathers Day

Father's Day was today, and I had my father's day animation to show my dad. If you haven't seen this animation, you should probably visit Blazing Games and take a look. The animation was done entirely in ActionScript 3. Even thought the animation appears fairly complex, it was in fact not that difficult to create. While I am not going to open up the source code yet, I will explain how it works. Each fish controls it's own movement with a movement function that is called every frame. While a time based interval would be more accurate, for this animation I really didn't need accurate timing for the movement, but for an action game this can be an issue.

The fish movement logic is very simple. It consists of a delay before starting to move, and a target location that the fish is going to swim too. When the movement function is called, the delay countdown is checked, and if the delay is over, the fish is moved by a set amount along the x axis (horizontal position). The y axis (vertical position) is where things are interesting. The vertical movement is in a sine wave along the horizontal line that crosses through the particular target y coordinate. The amplitude of the wave is based on the distance from the target, so as the fish gets closer to the target, the smaller the vertical movement will be.

Once all the fish have reached their target location, they are given a new target with a short delay. As the delays are the same for all the fish, they will swim off in formation. Once they have all reached their off screen location, they are moved back to their beginning off screen location. You may be wondering how the fish initially swim out in random order if they are in proper formation. Quite simple. They are given a random delay amount so their start times will all be different.

Flash CS3

Yesterday I posted my Mother's Day animation that I created for my mother on BlazingGames.com. This was kind of a milestone, as this was the first ever Flash 9 file that I released on my web site. By Flash 9, I mean that it requires the Flash Player 9 plug-in to view the animation. To create content for Flash player 9, however, there are a number of options available. The official channel is through Adobe, in which you have three choices available to you: the Flex 2 SDK, the FlexBuilder tool, or Flash CS3. The Flex 2 SDK is free (and is going to be released as open source), though is just libraries and command line compiler. The FlexBuilder program is Eclipse with a plug-in GUI. Flash CS3 is the traditional Flash animation program that comes with the various Adobe Creative Suite 3 collections. As I own CS3 Web Premium, I have Flash CS3 and used that for the creation of the animation, even though the animation was created entirely in ActionScript 3. Now is an appropriate time to go over my review of Flash CS3.

Flash CS3 has been reviewed a number of times, yet all of the reviews I have seen seem to miss the biggest reason for getting Flash CS3 which is ActionScript 3 (AS3). What is AS3? ActionScript is the scripting language that is used in flash. AS1 appeared with the release of Flash 5. Object Oriented extensions were "added" to the language with ActionScript 2 that appeared in Flash 7. The third version of ActionScript is a much larger leap over AS2 as it is actually compiled and the Flash Player uses a JIT engine to run the compiled code. This results in significantly faster code execution. The display engine was also drastically overhauled and is now much more flexible to work with. I will cover the display engine in future entries.

Writing AS3 code for me is a huge deal, though sadly the built in editor is still lacking. I suppose Adobe figures that programmers will migrate to FlexBuilder while artists and animators will stick with Flash. As code, including the code for the main timeline, can be assigned to external text files, this division of labor may make some sense. The problem is that there are people like me, who are somewhere between the two, who want the animation and drawing abilities of Flash yet want to write a lot of code so would like the code editing abilities of FlexBuilder, especially code completion. That said, the editor has improved a bit. The big improvement being collapsible code blocks and better debugging. In fact one of the neat things about CS3 is the fact that when the compiler catches an error, it will let you click on the error message and take you right to the problematic line. I, of course, intentionally left some typos in my code to test this feature out.

There are many other reasons to consider upgrading. The Photoshop like user interface, which I initially didn't care much for but am getting use to it now. The cool convert animation into ActionScript 3 code feature. Excellent support for importing Photoshop psd files, which will come in handy if Mary ever decides to do some artwork for Blazing Games. Better video exporting capability. Finally, integration with Adobe Bridge. If you have an earlier version of Flash, I think it is well worth the upgrade just for the ActionScript 3 support.