Jumping Back (Into) Flash


On my previous project, I was busy delving into the relatively new world of Unity game scripting as my go-to solution for dynamic content.  Now I’m working on a game that has me going back into the world of Flash, so I thought I would write a brief commentary on the differences I perceive between the two frameworks as it pertains to 2D game-crafting.

Before I go too far into this, I should point out that these two design paradigms are really not expected to be compared like this side-by-side most of the time.  Flash has existed for more than 15 years, and has undergone significant improvements in that time.  Unity is a relatively new framework with a more specific vision: 3D games that can be easily exported to other frameworks, like the iPhone or a web-based player.  In fact, the next version of Unity will even allow publishing to Flash itself.

This is significant, as Flash has been around so long it’s become common for many rich internet applications.  Most modern browsers include the latest flash player without any extra effort from the user, and it has extensive documentation and 3rd party resources.  The fact that a prospective user will almost certainly have to download the beefy Unity plugin before using a Unity web-application is perhaps its most significant drawback when deciding what framework to use.  If your goal is more eye-balls, Flash is simply more prevalent.

Publishing aside, Unity and Flash have some interesting differences when it comes to developing interactive content.  The first difference that comes to mind is the hierarchy of classes and objects used to organize game elements.  In Unity, everything starts with an abstract class called a GameObject.  Lights are GameObjects, as are cubes used in level structure and localized audio sources.  In the 3D editor, you can drag and drop various GameObjects into the world and arrange them as you like.  Things start to get interesting when you attach one or more components to these GameObjects.  Components can be anything, and are usually some customized script that dictates what behavior the GameObject will exhibit.  For example, I would create a player GameObject based on certain geometric shapes.  Then, I might attach to the player a ‘PlayerControl’ script component that dictates how it moves around the game world.

In what I’m sure is mostly a grammatical irony, my time developing Flash (using Flex) has me looking at this basic hierarchy backwards.  The basic structure in Flex is actually the component, be it a Label or a TextArea or whatever.  Once these components are identified and added to the stage, I can extend them in AS3 and give them behavioral functions that dictate how they interact with the user or other components.  Flash in general does have the edge when dealing with pure 2D in a game setting.  I was able to manipulate 2D objects in Unity just fine, but only after designing a number of custom classes and work-around techniques.

Another big difference I’ve encountered is the use of singletons in the scripting structure.  In Flash, we are using PureMVC to manage the application.  This framework includes a four ‘core’ singletons that help reference singly-generated classes.  This is particularly useful in game programming, where complicated event systems usually have to refer back to a centralized processing structure.  In Unity, a similar approximation I used was to create an empty GameObject that contained several ‘brain’ scripts which could be referred to via all future GameObject children.  It was a bit of a work-around, but worked in the end.

Aesthetically, the Unity editor is much more in tune with the demands of game developing.  Changes are logged in real time, and you can start the simulation from any point.  This is opposed to to having to start the game from scratch each time with Flash.  The Flex design preview is a nice tool to set the initial conditions of the components, but does little in the way of representing interactivity in the editor, which is a shame given the long load times you have to sit through when tweaking a Flex component.I enjoyed working with Unity, and I would recommend it to anyone who might appreciate an aesthetically different approach to developing interactive applications (games or otherwise), but its practical use might be dictated by the circumstances of your target audience.

Leave a Reply

Your email address will not be published. Required fields are marked