How i built – Part 6 – Dashboard

In the sixth post of the series, i will talk about the challenges faced when building dashboard on




The dashboard is an important module on It enable players to edit and manage they profile, view their progression in the game and interact with other players through debates and surveys. Dashboard is invoked by a call to action button located in the mini-dashboard component, who himself is located at the bottom of your screen. Let’s talk a bit about the mini-dashboard.


The mini-dashboard doesn’t look a big deal breaker at first sight, and in case, it shouldn’t be. It’s a simple component sticking to your webpage bottom and shows up when you over it. The mini-dashboard should always be accessible when playing the game, during a interview or when watching videos. He’s only hided on homepage or when dashboard is opened. With that in mind, i’ve build a simple flash.display.Sprite containing everything needed in the mini-dashboard and put it on top of everything. It worked perfectly in all case on desktop, but not on iPad.

Do you remember the problem i’ve talked about in Part 4 – Video & Audio, when mixing StageVideo, Starling and the Flash display list? To resume fast, on mobile, Flash Player draw opaque black background on elements displayed on top of Starling layer. In this case, the mini-dashboard was displayed with an opaque background when shown on top of exploration module. That was a big issue.

To come over this problem, i’ve choose to build 2 mini-dashboard. One using the Flash display list, displayed only during interview and video playback and another using Starling display list, shown only on exploration mode.


The dashboard is a huge module in It consists of 10 views who can communicate and be invoked by each other at any time. Each views are initialized and loaded only when requested to reduce load time and memory usage. Each views as his own sprite sheet containing all visual assets used in this particular view. Sprite sheets are loaded only when the view is requested.

Home View

Dashboard’s home view is the main entrance and wrap up of each views content’s. Home view is loaded at dashboard startup and refreshed when displayed. It also trigger views open action.

Compass View

The compass view is the most complex view of all. Each animated graphics (called indicators) displayed in the compass consists of a frame by frame animation exported as a sprite sheet from Flash CS6. Frame by frame animations are exported at retina resolution by using the Generate Sprite Sheet functionality of Flash CS6 and then scaled down to standard resolution by my custom Grunt script. For more information about my Grunt setup for this project, see Part 3 – Assets Automation with Grunt.

Views management and Transition

Views management and transitions are handled by the main dashboard. When a view is requested, dashboard check if this view is already initialized. If so, it create the transition and display it. If not, it initialize the view and when ready, create the transition and display it.

Transition is a Sprite containing a blank BitmapData used to draw view UI. When views initialization process is completed, the view UI is draw into transition’s BitmapData. Then, transition’s sprite is put on stage and animated. When animation is completed, transition’s sprite is replaced by view.

Instead of scaling and fading a complex display list hierarchy, Flash Player only have to render a flat BitmapData. It’s way easier for Flash Player to draw a single flat BitmapData than a full display list hierarchy containing multiples BitmapDatas, Sprites and Movieclips.


I hope you enjoy this post about Dashboard and mini-dashboard challenges when building In the next and last post of the series, i will write my final thoughts about my experience in building

Thanks for reading

Posted under Fort McMoney
Tagged as Tips, Fort McMoney, Case Study