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