Obstacles for Flash Game Development

Posted: February 3rd, 2009 under Opinion.

Flash is far from perfect. In fact, there is an entire micro economy providing support for things Adobe left out. Some of the setbacks that Flash game developers suffer from are communal to all Flash developers: having to wrestle with the Flash editor, coping with the rudimentary UI components, and not having access to ActionScript’s source code. More specific to game development, Flash lacks an acceptable collision system, profiling tools, and other typical features like a particle system and physics classes found in other game development suites. Flash is not marketed as a game engine so it is unfair to be overly critical; however, there is a Flash game development community and it continues to grow. Adobe needs to respond to the needs of game developers.

I understand both sides of the open source controversy, having developed proprietary software I can relate to a closed source policy. However, if your source is closed the community generally expects that your documentation is flawless. I am not the first person to find several flaws in Flash’s ActionScript language reference. Flash did do some things right in there documentation, I greatly appreciate all of the examples, there is good use of imagery on pages referring to graphics, and the show / hide functionality of inherited methods, properties, and events keeps pages clean and topic focused. Typically, the documentation is clear and straightforward and only few instances where the documentation says one thing and ActionScript does another. My criticisms are when critical information is completely left out. Case in point, hitTestPoint “Evaluates the display object to see if it overlaps or intersects with the point specified by the x and y parameters. The x and y parameters specify a point in the coordinate space of the Stage, not the display object container that contains the display object (unless that display object container is the Stage).” What Adobe fails to tell us is that hitTestPoint only evaluates at the last place that the object was drawn. If the object is moved, re-parented, or added back on the stage you would need to know where the object was the last time it was drawn, which surprisingly includes if the object is still on the stage and was drawn into a BitmapData object. This kind of imperfection is exactly what needs to be documented the most. The other painful aspect of working with closed source code is that there is only a general idea about the performance of different functions. Unless you have done a significant amount of benchmarking rooting out performance bugs is a guessing game. I doubt Adobe will ever release Flash’s source code, so improved documentation is a necessity.

There are certain design choices in ActionScript that should be more consistent internally and changed to what has become standard in graphics suites. There are some instances where Flash has already shown improvement in this regard. For example, in ActionScript 2.0 the alpha property on an object was in the range 0 to 100, somewhere I remember reading that they thought it would be easier for designers that were programming. In ActionScript 3.0 Flash 9, they corrected this mistake and used the standard range 0.0 to 1.0; however, they managed to forget to change this for gradients, which still use the 0 to 100 range for alpha values, Flash 10 corrected the oversight. There are other areas where Flash blatantly breaks the norm. An example is how Flash handles rotation, ActionScript is the only language that I know of that has a rotation range 0 to 180 then -180 to -1. Straying from conventions is one source of frustration, the other major issue with ActionScript is that it lacks structures common to most programming languages. Again, Adobe is working to improve conditions, in the upgrade from ActionScript 2.0 to 3.0 is we finally got a dictionary data structure. In the release of Flash 10, ActionScript 3.0 has a vector class; it still boggles my mind that a vector rendering program did not provide a vector class. Other data structures in the game developer wish list are queues, trees, graphs, and finite state machines. Vectors, queues, and finite state machines are basic components of programming languages. Tree and graph structures are critical to artificial intelligence routines.

The Flash editor could use some improvements. This is one area that there has been a great deal of third party development. Other editors do a much better job of highlighting code, turning functions into links to source code, and superior code show and hide features. The Flash editor’s help does not rank search results, you are left to sift through every entry containing your request. CS4 finally promises a long overdue library search feature. Between the library, help, and the code there is a lot of time wasted searching – something that should be effortless. Another usability concern, that I myself forget at least once a year, is that the Flash editor absorbs keyboard input when it plays a swf. The keyboard input bug seems to be one problem that everyone runs into, and having to publish and externally test our desired keyboard setup slows us down. Lastly, the performance of Flash applications seems to vary widely depending on its environment; results vary if a swf is run from the editor, a local Flash player, or embedded on a webpage. Combined with being closed source, environmental play differences lead to many false conclusions about performance. I do not expect Adobe to make performance uniform for every scenario, just to disclose the differences between them.

Flash

Flash aspires to be the premiere program to deliver rich interactive content, so why are its UI components reminiscent of standard HTML? The composite objects like text areas, lists, combo boxes, and data grids are difficult to theme with colors and textures; often the internal text field reference is private so you cannot perform normal modifications on the text. There is no reason that it should be so difficult to make a text area have a black background and white text or color alternating rows or columns of a data grid so it is easier to read. Then there are some components that are useless. Flash has perhaps the most basic color picker component that I have seen; even Java has a more capable color component for its applications (featured to the left). Furthermore, there is a complete absence of graph components. Third party developers are thriving on providing Flash UI components; personally, I took the time to build my own library of components. Development time that could have been spent working on games.

In comparison to other game engines, Flash lacks many typical developer tools. Flash has a bandwidth profiler and a size reporting feature. Even simple things like a frame rate and memory meter have to be written. Unfortunately, some tools are only possible if they are provided, like a runtime render profiler. It is just another case where development time is wasted on support that would be standard in a game development platform. For example, take Panda3D, it is a free, open source game engine yet it still has sophisticated profiling tools (featured below). If Adobe ever adds a particle system or other digital effects to Flash, I would expect tools for those systems as well.

Flash Color Picker
Java
Java Swatches
Java Hue Saturation Brightness
Java Red Green Blue
Panda3D Tools
Panda3D Profiling System
Panda3D Run Time Tools

Collision detection is fundamental to making video games and Flash’s collision system is one of the more primitive types. Axis aligned bounding boxes is so limiting that many developers choose to design games that need little or no collision detection. Some developers elect to implement a distance based collision system to better handle rotation, but there is only so much that you can do with circles and squares. There is no support for casting rays, typical in most collision systems and used for bullet physics, path finding, and other routines in games. Some of the previous topics discussed, tools and interface components, are frustrating to have to write but not too difficult. Writing your own collision system is not something the average user can do, and even those that are able avoid doing so because of the enormous time commitment.

Even with Flash’s limitations, there are many Flash game companies. Flash’s widespread use is just too appealing to game developers. With increased support Flash could become an incredibly powerful game development platform. Adobe does listen to user comments and make changes accordingly, so hope does exist. Unfortunately, the Flash gamming market is smaller than the Flash website and Flash video markets so I fear Adobe will be slow to improve the conditions specific to game developers. Adobe will likely continue to over look and put off gaming features until we see Flash games making as much money or garnering as much attention as the website and multimedia developers. Until then we will have to design around what Flash lacks or take the time to build what we need ourselves.

Thanks for reading, and remember, we are all in this together.

Bookmark this on Delicious

12 Comments »

  • Comment by Michael J Williams — February 9, 2009 @ 8:15 am

    1

    Excellent article. Do you think there is anything we, as a community, can do to help improve the situation?


  • Pingback by AS3 Avoider Game Part 6: Several Small Improvements | Michael James Williams — February 9, 2009 @ 10:46 pm

    2

    [...] That’s what Flash “sees”, and so it’s not surprising the collision detection is so bad. (It’s one of Stephen Calender’s Obstacles for Flash Game Development). [...]


  • Pingback by AS3 Avoider Game Part 7: Keyboard Control | Michael James Williams — February 16, 2009 @ 10:19 pm

    3

    [...] is another of Stephen Calender’s obstacles for Flash game development, and it’s incredibly irritating if you want to use keys that also happen to be used by Flash. [...]


  • Comment by SP — February 25, 2009 @ 1:11 am

    4

    “Control -> Disable Keyboard Shortcuts” in the flash PLAYER window should solve the “The keyboard input bug” from the Flash IDE.
    If that is what you guys are talking about.
    (That thing should be ON by default).


  • Comment by JessicaMayPe — May 10, 2009 @ 2:51 pm

    5

    Wow! Thank you very much! I always wanted to write in my site something like that


  • Comment by mook_mook_mook — September 18, 2009 @ 12:45 am

    6

    I have to pick up on one of your first points – the lack of a sophisticated collision system. I know there are workarounds, but that’s kind of a dealbreaker for certain types of games.

    Shocking that it hasn’t been addressed yet.


  • Comment by davegorman — March 19, 2010 @ 12:20 pm

    7

    Don’t complain about the Flash IDE when you’re using it for an unintended purpose. It’s a design tool, for making advertising banners and animations. If you’re making games and you want improved syntax highlighting, code completion, memory metre, profiler, etc you should be using Adobe’s programming IDE Flash Builder. As for ActionScript not having complex physics and collision systems, you said it yourself in your opening paragraph, “Flash is not a game engine”. If you want collision and physics, just download an opensource library like Box2D or CDK, don’t whine at Adobe to provide them for you. The above, along with your claim of an apparent “keyboard input bug” (a commenter above me “solved” this for you) leads me to believe you have done very little research for this article. Please try harder next time.


  • Comment by Stephen Calender — March 27, 2010 @ 6:05 pm

    8

    You make some very good points davegorman, and I want to take some time to address them.

    I believe that the community of users determines how something is supposed to be used. Technologies grow and evolve, and the community of users shapes that growth. The origins of Flash was just a drawing app, then people wanted to animate with it so frames were added, it wasn’t even until Flash 5 that there was a programming language – all changes driven by the needs of the community. So with the increasing volume of Flash games out there, and with the increasing amount of money they are earning, merits increased support from Adobe to support gaming.

    The problem with writing or using a third party library for physics and collision detection is that Flash is closed source. Since we cannot manipulate the Flash language directly, we can only write ActionScript routines on top of it. ActionScript is not as fast as code internal to the Flash language. So Adobe, by making their code closed source, has effectively created this feedback loop where we have to complain for systems that need fast execution. And a note on using open source libraries, some licenses restrict your ability to sell code, so it isn’t always an option, personally I have always written my own.

    I have been working with Flash for a very long time; it’s not ‘research’. I started this Blog to share my experience and knowledge with others. It doesn’t sound like you make games, use Flash, program, or even want to be helpful, so maybe this site isn’t quite for you.


  • Comment by thienhaflash — August 4, 2010 @ 10:16 pm

    9

    Excellent post !


  • Comment by traveller — March 7, 2011 @ 12:12 pm

    10

    @davegorman
    Never read anything dumber.

    “If you want collision and physics, just download an opensource library like Box2D “, and have you ever seen a browser based game written in C++ ?

    Please try harder next time, and think before you post.


  • Pingback by Retrobottega » Archive » Creare un Gioco in Flash – Parte 6: Tanti Piccoli Miglioramenti — April 7, 2011 @ 2:32 am

    11

    [...] Al contrario delle zone disegnate, le due bounding box vengono tranquillamente in contatto! Può essere scoraggiante da dire, ma questo è stato sempre uno dei peggiori ostacoli allo sviluppo dei giochi in flash, tanto che c’è gente che c’ha fatto articoli sull’argomento (Stephen Calender per esempio). [...]


  • Pingback by Retrobottega » Archive » Creare un Gioco in Flash – Parte 7: Usiamo la Tastiera — April 7, 2011 @ 2:33 am

    12

    [...] Nota Aggiuntiva: provando a premere gli altri pulsanti sulla tastiera durante l’esecuzione di un gioco noterete che il cursore potrà cambiare e verranno selezionati i simboli nell’IDE flash a seconda del tasto premuto. Questo è uno degli altri scogli del flash per la programmazioni di giochi secondo Stephen Calender. [...]


RSS feed for comments on this post. TrackBack URL

Leave a comment