{"id":120,"date":"2009-02-03T13:58:58","date_gmt":"2009-02-03T18:58:58","guid":{"rendered":"http:\/\/www.stephencalenderblog.com\/?p=120"},"modified":"2010-05-24T00:32:44","modified_gmt":"2010-05-24T05:32:44","slug":"obstacles-for-flash-game-development","status":"publish","type":"post","link":"https:\/\/www.stephencalenderblog.com\/?p=120","title":{"rendered":"Obstacles for Flash Game Development"},"content":{"rendered":"

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\u2019s 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.<\/p>\n

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\u2019s 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 \u201cEvaluates 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).\u201d<\/em> 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<\/a> rooting out performance bugs is a guessing game. I doubt Adobe will ever release Flash\u2019s source code, so improved documentation is a necessity. <\/p>\n

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. <\/p>\n

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\u2019s 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 \u2013 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. <\/p>\n\n\n\n\n\n\n\n
Flash <\/p>\n\n\n

\nFlash 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.\n<\/p>\n

\nIn 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<\/a>, 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. <\/p>\n

<\/tr>\n
\"Flash <\/td>\n<\/tr>\n
Java<\/th>\n<\/tr>\n
\"Java <\/td>\n<\/tr>\n
\"Java <\/td>\n<\/tr>\n
\"Java <\/td>\n<\/tr>\n<\/table>\n\n\n\n\n
Panda3D Tools <\/th>\n<\/tr>\n
\"Panda3D<\/td>\n<\/tr>\n
\"Panda3D<\/td>\n<\/tr>\n<\/table>\n

Collision detection is fundamental to making video games and Flash\u2019s 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. <\/p>\n

Even with Flash\u2019s limitations, there are many Flash game companies. Flash\u2019s 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.<\/p>\n

Thanks for reading, and remember, we are all in this together.<\/p>\n\n\n
\n<\/a>\n<\/td>\n\n Bookmark this on Delicious<\/a>
\n<\/tr>\n<\/table>\n<\/td>\n		\n