This document contains a growing list of best practices when developing Adobe® Flash® content for use with Autodesk® Scaleform® 4.0 and higher versions. These practices are specifically geared towards improving memory and performance of Flash content in games; however they can also be applicable for other use cases. The content creation section in this document is targeted toward artists and designers, whereas the ActionScript™ (AS) section is targeted toward technical artists and engineers. The Heads-Up Display (HUD) Development section is a general overview of the possible development scenarios for HUD creation. We encourage both artists and engineers to read this section before developing a HUD system with Flash and Scaleform.

This document provides a compilation of a wide variety of information from different sources such as customer support requests, developer forum posts, and various Flash and AS resources on the web. Scaleform can be used on many different platforms (from cell phones to cutting-edge consoles and PCs) and integrated with many different engines, and as a result there are unfortunately no “one size fits all” solutions. Every game and project requires a different solution for optimal memory consumption and performance (e.g., code tweaks may be required when porting from a high-end PC to a handheld platform).

We have tried our best to provide relevant performance data along with these best practices; however, these results will not be the same for your project, as there are many variables to account for. We recommend all User Interface (UI) work be thoroughly tested and alternative solutions should be stress tested for each use case early on in the UI development process.

Flash designers and developers must write code and structure applications in a way that is intuitive and beneficial to themselves as well as to the other people who are working on the same project. This is particularly important in FLA files with many assets. Note that Flash Studio CS5 introduced an XML based content format that replaces the binary .FLA format. This is very useful for versioning and changelist tracking.

As it is common for more than one designer or developer to work on a single Flash project, teams benefit when everyone follows a standard set of guidelines for using Flash, organizing FLA files, and writing AS code. The sections in this document outline the best practices for writing AS and best practices when using the Flash authoring tool to create rich media content. Adopt best practices at all times, whether a designer or a developer, working alone or as part of a team. The following are a few reasons why learning and following best practices is beneficial:

• When working on Flash or AS documents:
  • Adopting consistent and efficient practices helps speed up workflow. It is faster to develop using established coding conventions, and easier to understand and remember how a document was structured when editing it further. Additionally, code is often more portable within the framework of a larger project, and easier to reuse.
• When sharing FLA or AS files:
  • Other people editing the document can quickly find and understand AS, consistently modify code, and find and edit assets.
• When working on applications:
  • Multiple authors can work on an application with fewer conflicts and greater efficiency. Project or site administrators can manage and structure complex projects or applications with fewer conflicts or redundancies.
• When learning or teaching Flash and AS:
  • Learning how to build applications by using best practices and following coding conventions reduces the need to relearn particular methodologies. If students learning Flash practice consistent and better ways to structure code, they might learn the language faster and with less frustration.

Developers are bound to discover many more when they read these best practices and develop their own good habits. Consider the following topics as a guideline when working with Flash; developers may choose to follow some or all of the recommendations. Developers can also modify the recommendations to suit the way they work. Many of the guidelines in this chapter will help developers utilize a consistent way of working with Flash and writing AS.

Areas of possible optimization in Flash are as follows:

• Increase animation performance by optimizing graphics for fast redraw.
• Increase computing performance by writing code that executes quickly.

If code runs slowly, it is often a sign that the developer needs to reduce the scope of the application or investigate another method that solves the problem in a more efficient way. Developers should identify and remove bottlenecks, for example, by optimizing graphics or reducing the work done by ActionScript.

Often performance is about perception. If the developer attempts to perform too much work in a single frame, Flash doesn't have time to render the Stage, and the user perceives a slowdown. If the developer breaks up the amount of work being performed into smaller chunks, Flash can refresh the Stage at the prescribed frame rate, and there is no perceived slowdown.

• Consider reducing the number of objects on the Stage. Add objects one at a time and take note when and by how much performance degrades.
• Avoid using the standard UI components (available in the Components panel in Flash). These components are designed to run on desktop computers and are not optimized to run in Scaleform 4.0 and higher. Utilize the Scaleform Common Lightweight Interface Kit (CLIK™) components instead.

• Consider reducing the depth of the object hierarchy. For example, if some objects don't move or rotate independently, they don't have to exist within their own transform group.
• A large user interface is typically best broken into separate Flash files. For example, an MMORPG’s trading room would be one Flash interface and the life-meter HUD would be another. On the AS side, different files can be loaded through the various SWF loading APIs in both AS2 and AS3. These functions enable the application to load only the interfaces necessary at any given time and free content when no longer needed. Another alternative is to load and unload different SWF files via C++ API (creating different GFx::Movie instances).
• Scaleform 4.0 and higher supports multithreaded loading and playback. Background loading of multiple Flash files will not adversely impact performance if extra CPU cores are available. However, the developer must take care when loading multiple files from CD or DVD, as disc seeking is slow and may significantly slow down file loading.
• Avoid using Scenes as they often result in large SWF files.
• Realistic amounts of UI memory used for a game may fall in the following ranges:
  • Simple game HUD overlay: 400K–1.5M
  • Startup/Menu screen with animations and several screens: 800K–4M
  • Simple game fully in ActionScript with assets (Pacman): 700K–1.5M
  • Prolonged vector animation with constantly changing assets: 2M–10M+