Promotional adventure flash-game

Shamelessly cross-posting about a thread I made earlier to Showcase, Showcase / a promotional adventure flash -game

I'm double posting to discuss about some flash-specific issues, how I figured a solution for them and help others who might bump into those. The game is published as flash for now, iOS, webplayer and standalone versions coming out next week. The game is in Finnish only, but you should be able to complete it anyway, it's not that hard. Here's the url of the game: http://mestareidenluola.fi/peli/ and a screenshot:


First of all, XML. Flash has zero-support for that from unity, so parisng XML has to be done separately on the Flash-side. I didn't use System.Xml, but a simplier class I mention on the other thread. Keeps it lighter, and my needs for XML was just to store ingame-texts, such as dialog etc. One cannot store strings inside Unity's, since any characters beyound basic ascii gives you head ache.

Second issue was related to the first one. Even though I was using external XML, it wasn't enough. GUIText -elements would break the moment there was umlauts or other "exotic" characters in the strings, but ONLY on Windows side in flash. Somehow the encoding was broken, even though it looked good on a Mac. I overcame this by duplicating the textfields in flash, and pushing the stuff in there. It wasn't that hard after all, I just created an SWF-file with all the necessary textfields in place, loaded that in the beginning and made simple AS-functions to fill those fields when needed. Way easier to position the fields than in Unity.

There's a contact-form at the end of the game, that had to be done in a separate SWF also, since Unity's text-inputs won't work on flash, they say. Didn't even bother trying. No biggie, even did field checks and sending of the stuff wrapped in XML in ActionScripts, since I was in a bit of a hurry at the time, and didn't feel like gambling with the umlauts anymore. Now I've almost completed the form in Unity, too (checking of the required fields still missing).

If only I had checked out NGUI-plugin before I started doing ANYTHING GUI-related, I might have saved myself a ton of work. Seems to work flawlessy on every platform, even the text-elements (you also have fewer chaces to mess those when using bitmap fonts, methinks). I was under the impressions, that one shouldn't waste time checking whether plugins work on flash, since most of them had at least some issues. The help-menu was too much of a work to create with Unity's GUI-system, so on the online version it's once again a separate SWF. No it's also composed with NGUI-version for iOS, and is going to be replaced from the flash version too, I guess.

iTween is used very much, I'm glad there was a flash-patched version that seems to work quite OK. I even hacked the Visual iTween path editor to work (or at lest export without errors) on flash. Reverse paths still seem to be problematic, but regular paths work. Character movement is done solely on iTween paths (player doesn't really choose where the main character is going to move, everything is in the script). I tried using navmeshes in the beginning, but it was too inaccurate for this kind of game, and dynamic obstacles were missing in 3.5.x.

On the occasions where something had to be done separately in flash, I used two methods. First of all, the "two identical classes" -method, where I wrote two static classes, one in UnityScript, the other in ActionScript. They have identical function names, and the ones in US are marked as "NotRenamed". That way, the functions in US are not renamed during flash-export, and the AS-counterpart is used instead. Very handy, I'd say. So when I have to do something flash-specific, for example, push data to the textfields residing in flash, I just use a function call like this: GameLiterals.showDialog(). The US-version does nothing, there's only a dummy-function with the same name, but AS-version checks first out that wha't sthe active dialog we should be displaying, and fetches the necessary info (like character name and his line) and spits that out to the correct fields. Displaying the dialog in the Unity was done inside OnGUI() -function and I saw no reason to move them into the "GameDialog" -class afterwards, hence only a dummy-function there.

The second method was using a "FlashProxy", as it is commonly called. Once again two identical static classes, this time the US-version does absolutely nothing. It's used in situations like when the help overlay is needed. It has a function called showHelpOverlay(), which, when called, just calls the same function inside the parent movieclip (where unity is loaded) and the separate help-swf is displayed.

When working to the other direction, when flash has an urge to talk to unity, I used a "FlashGW" -method. That is simply just an US-script attached somewhere in the scene. An example of the usage of it would be something like this (a function call inside the SWF that load's all the other SWFs, including unity):

Code (csharp):

1. unityContent.sendMessage("FlashGW","setGraphic",{clip:dialogOverlayLoader.content});

It is simply calling a setGraphic -function of a gameobject named FlashGW on the root of the scene, passing a reference of certain movieclip wrapped inside object as it's only parameter. The movieclip is later unwrapped from the object in an ActionScript-class, that is compiled inside the SWF unity has produced. A bit complicated method, I know, but the only way I managed to get this working. The static flash-classes (that are inside unity's swf) have absolutely no idea about the stage, they cannot use addChild even if they had any idea (since they're static), so addChild-stuff has to be done elsewhere, but in this example the static class has to know about the textfields it's going to be populating. Tricky S***, I didn't like it either when I had to find some way to put this together.

Finally, everything is put together inside simple Flash Builder -project. It consists of one class, that is the main application. Inside that class the unity loading takes place, and every required external SWFs are loaded. I also made a simpler class, in where I tested the flash-specific functionalities. Compiles much faster (than exporting the swf from unity every time) and is easier to debug. Debugging the whole project was also pleasant in Flash Builder, since Unity's debug statements gets displayed there (I'm aware of the flashlog.txt -method, but this is more convient). Now that Adobe has made up this new licensing-fraud, I've also registerd the game on Adobe's site to make sure it has hardware-assisted 3D in the future, too.

Eventhough we tried to make this game as light as possible (well the file size could be still squeezed a bit), we've got complaints about the game not working when a.) flash player is older then 11.0 b.) computer is too slow. Can't really do anything to come around those issues, that's why we're going to offer webplayer- and standalone-versions as an option later. The game is the main material for a launch campaing of a big parking hall mined under a city, and there's also tv-commercials to get people playing it, first one came out this week: http://www.youtube.com/watch?v=9RZkKaXQcFk