Adobe Max 2013: Best Gaming Sessions

I recently covered an Introduction To Adobe Game Developer Tools. With excitement and momentum (created primarily by Stage3D and its Starling Framework) we see proactive, positive marketing by Adobe for gaming and the Flash Platform. The community hopes this will help keep the Flash Platform in the minds of business leaders and developers as a viable technology for new projects.

Adobe recently announced the details for the annual Adobe Max conference. Thankfully, in 2013 we see a focus on gaming.

Adobe Max 2013

Adobe MAX 2013 will be at the L.A. Convention Center & Nokia Theatre L.A. LIVE on May 4 – 8, 2013

(From Adobe Marketing:) Adobe MAX is all about creativity and expressiveness. If you create, you won’t want to miss MAX. Designers, developers, strategists, video professionals, photographers, and more all come to MAX to exchange ideas and inspiration. Together with industry pros and visionaries, you’ll learn about the latest technologies, techniques, and strategies for delivering your best creative work. Come to MAX and explore how creativity is changing the word and what part you have to play in that change. And every full conference MAX pass includes a one year membership to Adobe Creative Cloud*

Adobe Max 2013: Gaming Sessions

Here are the game-related sessions we can look forward-to;

ID TITLE DATE TYPE
L7804 Building a Platformer Game with the Starling Framework Monday 5:00 PM, Tuesday 3:00 PM Lab
L7902 Developing Multiplatform Games with the Adobe Gaming SDK Monday 12:45 PM, Tuesday 12:30 PM Lab
PB7682 Building Games with the Adobe Gaming SDK Sunday 9:00 AM Preconference BYOD Lab
PB7683 Advanced Flash Gaming Development with the Latest Adobe Technologies Sunday 9:00 AM Preconference BYOD Lab
S7802 Adobe Gaming Roadmap Monday 2:00 PM Session
S7805 Wired Up: Integrated Tools for Game Creation Tuesday 1:00 PM Session
S7862 Becoming a Successful Game Developer with Adobe Flash Tuesday 4:00 PM Session
S7904 ActionScript Game Frameworks Panel Wednesday 9:30 AM Session
S8022 Mastering Multiplayer Stage3D and AIR game development for mobile devices Monday 2:00 PM Session
S8202 Extending Mobile Games with AIR Native Extensions (ANEs) Tuesday 8:30 AM Session
S8362 Next-Generation Runtime for Adobe Gaming Tuesday 8:30 AM Session

Next Steps

Fixing Memory Leaks with Adobe Flash Builder

On a recent project, we had a performance problem. The AIR project’s requirements include the heavy adding/removing of UI elements and over time we could easily see the performance slowed. We knew there was a something wrong. It was a memory leak. A memory leak starts when an object is stored in memory but cannot be accessed by the running code. When the undesired object cannot be freed from memory, and is not usable, it is a leak. Over time the application may leak (or re-leak the same issue) more and more. Eventually the application may show signs of the leak or even become unusable.

User Experience Symptoms Of  A Memory Leak

  • During regular use the application becomes more and more sluggish/slow. If there is nothing ‘new happening’ onscreen and no heavy ‘rendering’ it is more obvious to notice the Framerate-per-second (FPS) lower. You can use a small debug window (such as Hi-Res-Stats formerly MrDoobs Stats) to show the current FPS and estimated ram usage to help you notice this. If you see the FPS run at 30 for example during the first minute of use and 20 after 5 minutes, there may be a memory leak.
  • The application quits suddenly. This could be for many reasons, but it may be that the application runs out of memory.
  • Flash throws the memory-specific error ‘flash.errors.MemoryError’
Even if you see one of these symptoms it may not be obvious that there is a problem or that the problem is a memory issue. Or perhaps your development machine is high powered with ample RAM, yet your target user’s machines are slow. You don’t see the issue, but your users will. So how can we diagnose the issue. Luckily, the Flash Builder IDE has a ‘Profiler’. This program runs alongside your application and serves several key roles. You can monitor your applications USAGE of memory over time, and see a live list of all OBJECTS in memory (including references to those objects).

Profiling To Find Evidence Of A Memory Leak

  • Run your application with the Flash Builder Profiler. Run -> Profile As… -> etc…
  • Watch the ‘Memory Usage’ Panel
  • Look at the curves of Peak Memory (Red) and Current Memory (Blue). The analysis is totally application dependent. In your particular application, if you expect memory not to grow, but you see it grow, that is a problem. If you expect the memory to drop (UI removed from stage, arrays and vectors emptied, etc…) and you don’t see it drop, that is a problem. Herein lies the art of memory profiling. Consider to add a button to ‘Reset Application’, then click it and see that indeed the Current Memory drops to zero (0).
  • Watch the ‘Live Objects’ panel. Compare the 1. ‘Cumulative Instances’ and 2. ‘Instances’. For each object. #1 shows the total objects every created since the application started and #2 shows only those currently in memory. If these numbers are the same, and should not be, that is a problem. Perhaps you feel you have deleted a sprite from the stage or deleted another object from memory yet it still exists.


Tools And Tips For Finding And Fixing Memory Leaks (Must Read!)

If you want to play with a simple example you can download the example below (See ‘Member Resources’) below.

Example 1: Without Memory Leak

[actionscript3]
package
{
import flash.display.Sprite;
import flash.events.Event;

//USE A LOW FRAMERATE, SO WE CAN STUDY CLOSELY
[SWF(frameRate="1")]
public class MemoryLeakDemo extends Sprite
{

private var listOfDots_vector:Vector.<CustomDot>;
public function MemoryLeakDemo()
{
//REPEAT SOME CODE EVERY SECOND
addEventListener(Event.ENTER_FRAME, _onEnterFrame);

//CREATE A LIST
listOfDots_vector = new Vector.<CustomDot>();
}

protected function _onEnterFrame(event:Event):void
{
//EVERY FRAME WE…

//1. CREATE A NEW ‘DOT’ (A Red Circle Sprite)
//MEMORY NOTE: ‘var’ is a temporary variable.
//So CustomDot has 0 (permanent) references
var customDot : CustomDot = new CustomDot();

//2. ADD TO THE STAGE
//MEMORY NOTE: So CustomDot has 1 (permanent) reference; ‘this’
addChild(customDot);

//3. REMOVE TO THE STAGE
//MEMORY NOTE: So CustomDot has 0 reference
removeChild(customDot);

//So…
//THERE IS NO LEAK
//The GC will *mark* the ‘customDot’ as having 0 references and
//The GC will *sweep* it away from memory.

}

}
}
[/actionscript3]

Example 2: With Memory Leak

[actionscript3]
package
{
import flash.display.Sprite;
import flash.events.Event;

//USE A LOW FRAMERATE, SO WE CAN STUDY CLOSELY
[SWF(frameRate="1")]
public class MemoryLeakDemo extends Sprite
{

private var listOfDots_vector:Vector.<CustomDot>;
public function MemoryLeakDemo()
{
//REPEAT SOME CODE EVERY SECOND
addEventListener(Event.ENTER_FRAME, _onEnterFrame);

//CREATE A LIST
listOfDots_vector = new Vector.<CustomDot>();
}

protected function _onEnterFrame(event:Event):void
{
//EVERY FRAME WE…

//1. CREATE A NEW ‘DOT’ (A Red Circle Sprite)
//MEMORY NOTE: ‘var’ is a temporary variable.
// So CustomDot has 0 (permanent) references
var customDot : CustomDot = new CustomDot();

//2. ADD TO THE STAGE
//MEMORY NOTE: So CustomDot has 1 (permanent) reference; ‘this’
addChild(customDot);

//2B. CREATE ANOTHER REFERENCE TO THE DOT
listOfDots_vector.push(customDot);

//3. REMOVE TO THE STAGE
//MEMORY NOTE: So CustomDot has 0 reference
removeChild(customDot);

//So…
//THERE *IS* A LEAK
//While we are correctly calling removeChild
//There is a reference left in ‘2B’ above.

}

}
}
[/actionscript3]

Next Steps

  • Download the code and check it out! (See Member Resources)
  • Comment below with your thoughts.
  • NOTE: Flash Builder 4.7 (BETA2) has new Profiler called “Monocle“. It looks very exciting, yet this article focuses on the currently available (non-BETA) profiler.

Member Resources

[private_Free member]Enjoy this members-only content!

[/private_Free member]

Considering Flash-To-Mobile Development

THE CHOICES

Software development has gone mobile. We see a large audience using smartphones and tablets, and as developers/marketers/entrepreneurs we want in. When planning such a project there are myriad decisions.

CHOOSE – THE PLATFORM

The choice of target platform (e.g. iOS) and target device (e.g. iPad2) is a primary consideration. Apple’s iOS hits the majority of the market but with time others will mature and may offer more competition. Moreover to hit your market you may be best served to offer your software to more than one platform and more than one device-per-platform. Quite quickly a rather conservative project can target 5-10 unique pieces of hand-held hardware.

CHOOSE – THE DEVICE

Each device offers unique features. The market-penetration, platform, processor-speed, input-capabilities, screen-size, and other factors are all important. Two major form-factor camps are ‘phone’ size and ‘tablet’ size. There is some overlap between these categories such as the Samsung Galaxy 1000.

CHOOSE – THE MONETIZATON

There are many monetization schemes possible. Here are a few of the popular ones;

  • Free – To gain experience and reputation.
  • Freemium – Offer a free version and market within the experience for a pay-version with more features.
  • Ads – Integrate video ads, animated ads, or still ads into the experience.
  • Micro-transactions – Offer bite-sized purchase opportunities which enhance the experience.

CHOOSE – THE DEVELOPMENT PATH

When the platform(s) and device(s) have been chosen, the path to develop must be chosen. In general there are two strategies

a) Native App Development – This means you use the 1st-party language (and tools) offered by the platform creators. This means using XCode tool with Cocoa framework coded with the Objective-C language when developing for iOS. Native development generally offers the very best potential performance (i.e. for high-end gaming) and tightest integration to the devices (e.g. detect battery level, etc…) and OS/marketplaces (e.g. iOS in-app-purchase).

b) Non-Native App Development – Many 3rd parties offer code libraries and tools to ‘speed up development’. Some of these are in the native language and some are not. Some of these non-native solutions offer the ability to ‘code once (so to speak) and deploy to multiple platforms’.

c) Mobile Web Development – Instead of a standalone application, an experience can be made available via web-browser and development to fit the size of the target (mobile) device(s). With HTML5 much is possible, but in general this is used for less-expressive less-device-specific experiences. It can also be a very inexpensive way to ‘break into mobile’, as you can use assets/code from your existing website..

CROSS-PLATFORM DEVELOPMENT

While the ability to develop one project for multiple platforms offers many advantages in saved development time and ease in maintenance, it also offers many challenges. Designing a compelling application that takes advantage of the unique features of each device and looks polished on the dizzying array of screen sizes out there can be daunting. For Flash-To-Mobile there are many resources on Adobe’s Mobile Devnet to help you learn the basics.

BACKEND

It is possible for an application to be self contained, including all data/assets with the original install. This is common for games. However many projects require internet connectivity. The data/assets loaded can reside on existing servers outside of your control, or can reside on your own servers. Custom backend solutions using typical backend languages (c++, Java, PHP, Python, etc…) may also be required. All of this depends on your particular project. In general any of the development-paths can contact any of these backend solutions, but some may connect more easily than others.

EXAMPLE…

Let’s assume you have a great new game and want to capture a ‘big audience’ with ‘modest investment’. If the application does not require deep-device-integration a recommended choice is to target both iOS (iPad1/iPad2, iPhone3G/iTouch3G, iPhone4G/iTouch4G) and Android (various devices). If your team has Flash expertise the Flash-To-Mobile publish path may be ideal.

FLASH-TO-MOBILE

With Flash CS6 and more-so Flash Builder 4.6, Flash/Flex developers can publish ONE codebase to MULTIPLE platforms. Using Adobe’s AIR 2.7 (latest public release) you can develop many platforms & Devices.

Compatible Target Platform/Devices: Web-Browser (Mac+Windows+Linux+Non-iOS Mobile Browsers), Desktop (Mac+Windows+Linux), iOS (Ipad1+Ipad2, iPhone+iTouch 3rd Generation, iPhone+iTouch 4rd Generation-Retina), Android (Myriad Devices), Blackberry Tablet OS (Blackberry Tablet).

Supported Flash-To-Mobile Device-Specific Features: Flash-To-Mobile does offer view-persistance, data-persistance, video playback, still-camera capture, still-camera-roll save/load, internet access, in-app web-browsing, accelerometer/gyroscope, Microphone, Geolocation, Multitouch, File-system access. Not all devices offer the same features. In the future ‘Native Extensions’ (see below) offer a solution.

Project Setup: A recommended options is one bulky Flex Library with (most) all code and assets, and then one Flex Project *PER PLATFORM*. You add/edit to the library and publish each of the projects as needed. You can test with an mobile-emulator (fastest) window that appears on your computer, or on the device via USB (best to test hardware features like accelerometer. The ‘flash’ code is converted to ‘native code’ (so to speak) before deployment.

Deployment: Upon completion the platform-specific file is uploaded to the platform-specific marketplace (e.g. iTunes’ App Store for iOS). A Flash-to-Mobile project sits along-side native applications. Ostensibly users have no idea the application was developed with non-native tools. The marketplaces do not delineate this or otherwise make that info available in any way to users. The end-user experience can be indistinguishable from a native app (project type and project polish depending).

NATIVE EXTENSIONS

In light of the ‘Device-Specific’ features listed above, Flash-to-mobile currently leaves us without everything we may want to do (e.g. iOS in-app-purchase). The yet unreleased (release date is ‘early October 2011’) Adobe AIR 3.0 will include ‘Native Extensions’. In short, this allows for *ANY* Flash-to-mobile project to access *ANY* feature on *ANY* supported device (Android / iOS / Blackberry Tablet). Developer will require knowledge of both AS3 (flash) as well as the Native language(s) on the target device(s) to add new features. Or your team can find free and premium extensions which the community could share. This is not just for mobile, this technology will also allow AIR on desktop computers and AIR on TV’s to integrate with those devices too.

LINKS

Native Mobile Development

Marketplaces

Non-Native Mobile Development – Flash-To-Mobile

Non-Native Mobile Development – Others

THE FUTURE

Some of what is coming in the future is listed below.. This may or may not all be included in the very-next tools. Recently Adobe has announced What’s new in Flex 4.6 SDK and Flash Builder 4.6.

I. The Second Coming (Halleluiah) – Flash-To-Mobile Native Extensions

This future feature will ostensibly allow Flash-To-Mobile projects to access *ANY* feature on *ANY* targeted device (e.g. in-app-purchase on iOS).

Updated Febrary 23, 2012: See Here…

II. The Second Coming (Halleluiah) – Stage3D


Stage3D (Formerly codenamed ‘Molehill’) is a set of API’s available in the future that will ostensibly allow Flash Browser projects (using Flash Player 11) and Flash-To-Mobile projects (using Adobe AIR 3.0) to show high-grade hardware rendered 3D. Finally, the Flash Platform can truly compete as a 3D gaming engine. The same API (despite the name) can also be used for radically improved 2D gaming performance too.

NOTE: These API’s are low-level and challenging to understand. We expect 3rd parties will wrap this functionality with easy-to-use API’s for free/premium use.

Update March 10, 2012: See Here…

III. The Second Coming (Halleluiah) – Air 3.2 = Stage3D for Mobile + Many Stage3D Frameworks

So with AIR 3.2  (See Adobe Press Release) we can use Stage3D for mobile. This means GPU-Accelerated graphics on iOS/Android. I think there is a marketable benefit on getting the Flash Player to compete against other 3D gaming solutions (such as Unity3D) and perhaps compete less with emerging 2D gaming solutions (such as HTML5 gaming) so I can sympathize with Adobe’s (better late than never) focus on 3D for Flash. This article “Why Starling (or any other 2D framework on top of Stage3D)?” explains some really good reasoning.

[tubepress video=”ZPHATCbnHE0″ embeddedWidth=”500″ embeddedHeight=”350″]

Mind-blowing Demo’s of AIR 3.2 on mobile

Regardless of why, Stage3D is here, and Starling’s power lies in how it uses the Stage3D – first available in Flash 11 and AIR 3.0. Stage3D is designed for GPU accelerated 3D. While its possible to use the Stage3D API’s directly, it is very difficult. There are 3D frameworks for AS3 , but for many game developers we can exploit its power for 2D gaming. That’s why Starling focuses purely on 2D. So an API like Starling helps developers make great content – quickly.

AS3 frameworks use Stage3D for 3D gaming;

AS3 frameworks use Stage3D for 2D gaming;

Key Articles I’ve written on the subject

Stage3D Games

Spaced Away

Spaced Away

Falanxia brings its FWA Award –winning space physics puzzle game to both iPad and your web browser.

Play game Learn more

Angry Birds Facebook

Angry Birds Facebook

Join your friends on Facebook to take out Rovio’s famous pigs with enhanced special effects.

Play game Learn more

Waste Invaders

Waste Invaders

Waste Creative’s tech demo lets you blast aliens at a silky smooth 60 fps, across browsers and iPad, with Stage3D.

Show demo Get the source

Setup Flash Builder For AIR 3.2 Stage3D for iOS/Android

Stage3D was introduced in Flash Player 11. It allows for GPU-Accelerated 2D and 3D performance in the Flash Player that is 1000x faster than before. It was not publicly available for AIR mobile projects until AIR 3.2.

There are lot of new significant features like mouseLock, middle click, right click, silent auto-update and Stage3D on mobile.

Super Easy Setup

  1. Download the new SDK (“Step 2”)
  2. Unzip the new SDK
  3. Open Flash Builder. Open Preferences. Search for “Installed Flex SDKs”. Look at the URL for an existing SDK. See the image below.
  4. Open Finder (or Windows Explorer) to that ‘sdks’ folder. Drag the new SDK next to the existing sdk(s).
  5. Open the same Flash Builder Panel. preferences panel again. Choose ‘add’ and browse to the new SDK. Don’t set it as ‘default’. But for each new project you create, it will be a choice for you to use.

For Step #3

Thats it. Enjoy!

Next Steps

Checkout other related articles.

What *IS* Wrong With AIR 3.0 Native Extensions!

Hallelujah – AIR 3.0

In October 2011, Adobe Announced Flash Player 11, and AIR 3.0. AIR features all the greatness of Flash Player 11, plus more features – such as improved integration and performance on Mobile Devices (Android, iOS, and Blackberry Tablet OS).

I recently wrote about some of the benefits of using Flash-To-Mobile (AIR 3.0) for iOS/Android development.

Features of AIR 3.0 + Flash Player 11

  • Stage3D – High-Performance 3D and 2D rendering using GPU
  • StageVideo – High-Performance Video
  • Improved Encryption – Higher Security
  • Native 64-bit support (Flash Player desktop) – Faster Performance
  • Native JSON support – High performance data parsing
  • Much More
  • … and Native Extensions – See Below

Native Extensions

When developing AIR, the AS3 layer comprising the bulk of the user experience and logic sits on top of a native-language layer. The native layer is written in another language (not-AS3) and is device specific (i.e. Objective-C for iOS devices). The beauty of AIR is that we can code our the familiar AS3 and run on many many devices. Historically, only some of the native-device features were possible using AS3… until now.

Native extensions, new in AIR 3.0 allow the AS3-layer to communicate with the native-language layer. Essentially, *ANY* code written in the native language is accessible.

There are two flavors of Native Extensions – those that access existing built-in native features (i.e. iOS’s iAD Advertising API created an provided by Apple) and those that access custom native-language features which a developer creates for his own use (such as a feature I may create that only I need for a game).

The Good
In the latter case, for custom work, the AS3 Native Extensions is fantastic. You can link together any custom native-language code with any custom AS3 code. Nice. The flexibility Adobe provided to unlock *ALL* of the native-API is commendable.

The Good, yet Tedious
In the former case, when an AS3 developer wants to use an EXISTING built-in native-language feature, he/she essentially ‘wraps’ the related native-language classes, each with the Native Extension shell – Creating a setter/getter/function-caller to parallel the native-language’s API. The process is very straight-forward, but time consuming and tedious. In general the AS3 signature (classes, methods, arguments, properties) matches 1-for-1 the native-language signature.

The Ugly
I’m unsure why Adobe did not create the AS3-api to access all the features for us. Demanding that the community create, share (sell?) such solutions is a gross duplication of effort by the community.

My Problem: Why didn’t Adobe include strong-typed AS3 classes to access the native-language API’s at time of shipping AIR 3.0? Capturing the top 10-20 features the community wants (iADs, in-app-purchase, notifications, etc…) is a no-brainer.

LINKS

More About Native Extensions

Available Native Extensions & Tutorials