There are a lot of good articles already written & screen casts about memory management in Flash Player.  I encourage you to read them first before reading the below.  I cover memory management in a large application using a PureMVC architecture, typically on top of Flex.

• Unloading Flex Modules
• Resource Management in AS3 Session Notes Available
• AS3 Resource Management: Part 1
• Garbage Collector Interactive Simulator
• Garbage Collection and Memory Leaks
• Memory Performance in the Land of References
• Flash Player Memory Management
• Using Object Pools
• Object Pool Class
• Tweening and Object Pools
• Garbage Collection with Flex and Adobe AIR
• Screencast: Performance and Memory Management

Introduction

Memory Management, referring to making sure your application doesn’t leak memory through the use of responsible coding practices, is hard.  It’s even harder if you don’t have a history of having to deal with such things (*cough* Flash Developers *cough*).  It was challenging for me to learn… and I’m still learning.  As the Flex community has grown, we’ve seen the influx of more traditional programmers to help write blog entries and white papers, especially for AIR apps, on better memory management, how to prevent memory leaks, and how memory in the Flash Player works (and doesn’t work).

What I haven’t seen is this applied to Enterprise programming and frameworks.  Most articles are either from a Flash game developer, or a Flex dev referring to AIR applications.  From my consulting, the people who need the biggest help are doing the web applications that need to run as long as a normal desktop application.  Below, I’ve documented how you do this using PureMVC.

Why Memory Management?

Many Flex & Flash projects don’t need to use good memory techniques.  Memory leaks on a small scale are ok.  If the application is responsive to the user, you have no problem.  The purists will argue that creating a bunch of things and not removing them from RAM is bad.  However, if your application works, is responsive to the user, and doesn’t adversely affect other applications, then the purist is wrong.

For things like games that use a lot of system resources, or applications that need to run on your computer longer than 10 minutes, memory leaks will eventually use all available memory that a SWF is allowed, and cause it to stop working, or the browser to crash.  The application will be slow to respond, Garbage Collection may freeze Flash Player while it attempts to clean up, and/or your memory will become fragmented over time.  Fragmented memory makes things slower to access it, and thus can slow down your application.

Another side effect of not cleaning up the memory you’ve used yet no longer need is weird bugs.  You’ll sometimes have objects around that are doing things, yet you have no strong-references to.  Examples include timers still running, service classes that were “removed” yet receive a response from the server and no one is still listening for the response, or duplicate PureMVC classes.  Weird bugs can arise from these situations, causing your debugging time for problems to take longer.

Bottom line: If you want  your application to run for hours at a time, not to adversely affect other applications, and remain responsive, you need to employ good memory management.

Smaller projects that have memory leaks can often be re-factored.  Enterprise ones, however, will often take months to fix.  Worse, those months will have a major lack of visible project progress as things are broken on purpose to get things back into shape.  This is sometimes a contributor to the reason larger projects have the infamous “last 10% is 90% of the work”.  If you don’t start early with easy to follow conventions, it’ll be really hard to add them in later in; “add” is too nice a word since those projects don’t just stop to wait for you to clean up some memory; the logistics are a lot more complex than that.

This is even worse in Agile.  Where 80% of your time is re-factoring and you’re constantly creating new code, it’s quite challenging to keep up.  The best you can do is have a good understanding of the life cycle of your app.  The better understanding you have, the better you’ll be able to know what you don’t have to clean up, and what you do; i.e. when you have to write code and when you don’t.  Remember, designers / UX people can help here.  They’ll be able to give you a better understand of user paths into your app, and you can focus on what truly matters and knowingly let the rest remain in memory.

Example: If the user is constantly creating 3 types of forms, you can focus your efforts on ensuring they are cleaned up.  If the user hardly ever goes to a FAQ page, you can spend little to no time ensuring it’s cleaned up.  The reverse can be true as well.  If the 3 forms are accessed often, you can ensure that only the data they create is unique, but the forms themselves remain in RAM.  You can instead focus your efforts on those items that are rarely accessed.  If you user does go to the FAQ page, they shouldn’t be punished when they leave; it should remove from memory.

Why NOT memory management?

Memory management, sadly, requires you to often write more code.  More code is a negative contributor to projects.  For Enterprise code bases, they are often quite large.  Even when all features are completed, you are often adding more code for modifying features, or fixing bugs.  The last thing you want to do is knowingly add more code if you can help it.

A common practice for classes is to add destructor methods.  These are basically methods that are called “public function destroy():void” and clean up the class.  It’ll remove strong event listeners, remove child display objects, and stop asynchronous classes such as Timers, Sockets, and service classes.  Another common practice is to create “addListeners” and “removeListeners” functions that will do just that; add event listeners to an object/objects, and remove them.

Often, though, both classes fall into the trap of those methods never staying in sync with the rest of the class.  If you create a new object, you forget to clean it up in destroy.  That, or you add a new event listener amongst the other 4, but forget to add it to the removeListeners function.  Worse, and most often the case, these methods aren’t ever called.

The developer meant well, but ended up creating more code, code that isn’t used, and code that isn’t even finished with no obvious indications thereof.  The road to hell is paved with good intentions.

When View’s Go Away

When creating applications, whether Flash or Flex, you’ll have View’s that are shown and hidden.  You’ll have to make the decision how they are hidden.  If you need the View quickly, you’ll set visible to false and true.  If you don’t need to View quickly, you’ll simply addChild/removeChild.  If you only need the View rarely, you can destroy it entirely and rebuild it when you need it.

When you know you need to destroy a View, then you can write code to remove it from memory.  This is the only YAGNI approach I’ve found that works.  Meaning, as soon as you recognize you’ll need to remove a View, only then do you write code to clean up the mess.  If you do it prematurely, you just wrote a bunch of code you may never need, and now have to maintain.  Adding it later actually isn’t so bad, but that assumed you designed for it.  Meaning, if you don’t make it easy to remove a View, it’ll be hard because you first have to re-factor the code that uses it.

From a GUI perspective, this is sometimes ok.  Take the case of a View used in a Flex ViewStack.  All a ViewStack does when you leave a View is remove the View from the DisplayList.  If she’s a big View, that’s nice… but not enough.  You’ll need to refactor this code to support the child in the ViewStack from being destroyed.  You can either wrap the View you want destroyed in say, a Canvas that has code to destroy/create the single child View based on Event.ADDED/Event.REMOVED.  That, or you could make the child a ModuleLoader, and based on Event.ADDED/Event.REMOVED, load/unload the module.  Or, you could just write a function that creates/destroys views based on where it’s supposed to go.  You lose the flexibility & ease of using a ViewStack, but you get more control with more efficient code.

Registering & Unregistering View’s in PureMVC

…but this assumes you can, in fact, get the View out of memory.  In the case of frameworks, larger Views will often use the Presentation pattern, a Mediator, or something like it.  Sometimes it’s directly in the View itself.  How ever it’s done, the “Master View” will integrate with a framework.  In PureMVC, this is usually via registering itself with PureMVC.  There are varying ways to do this.  The way I do it is via ApplicationFacade.getInstance().registerMyView(this), where “this” is the instance reference passed in.  The ApplicationFacade will take the instance, create & register a Mediator passing the instance into the constructor of the Mediator.

public function registerMyView(view:MyView):void
{
        facade.registerMediator(new MyViewMediator(view));
}

Others will dispatch an event, and have a Command class handle those details to prevent their ApplicationFacade from growing large.  Either way, time and time again, I see View’s that should be removed, but have no “unregister” function, nor a Command to remove the Mediator.  Basically, there is a lot of code to register the View the the framework and create associated Application domain classes, but nothing to clean up everything when you’re done with it.

The way I do it is via ApplicationFacade.getInstance().unregisterMyView(this).  This is the opposite of the last method; it’ll unregister the Mediator.  The Mediator’s onRemove function will fire, which gives the Mediator an opportunity to clean itself up.

public function unregisterMyView():void
{
        facade.removeMediator(MyViewMediator.NAME);
}

Weak vs. Strong Listeners

Let me take this opportunity to protest against using weak listeners.  They are for pussies.  Seriously, the only time they are valid is when you are creating code modules that other developers could use, and there is no conventional destruction point.  Since you have no control over when your code will have the opportunity to clean itself up, nor do you know if the developer using your code is smart enough to call your destroy method, you try to code as defensively as possible.  If you must snag a reference to a global object such as “stage” for example, which’ll surely lock your code into memory, you at least make it a weak listener AS WELL AS listening for Event.REMOVED_FROM_STAGE.

It’s been suggested to always use weak listeners when using Timers for example.  Since these are some the major culprits of memory leaks in applications, if you use a weak listener, you’re set right?  Same with Dictionaries with weak keys, right?  *face palm*  Sure man… with that attitude, I’m sure you’re code REALLY makes an effort to help clean itself up.  Besides, Flash Player 9 has some issues garbage collecting weak listeners, so you can’t even depend on it working as advertised.  They’ve fixed a lot of this in 10, but you need to make an effort to de-allocate as much memory as you can.  Just because a large object has no references to itself doesn’t mean the Garbage Collector will immediately free up everything.  While it is a black box, you do have ways of helping it out.  In my experience, it’s more likely to free up smaller objects more often than large objects since running Garbage Collection itself is a processor intensive operation.

If your code is explicit, it’s clear where you’re freeing memory.  If you’re not, it’s challenging to figure out where leaks occur, nor is it easy to write proactive code to free up memory.  Granted, deadlines may dictate otherwise, and I concede the point on those instances.  Regardless, a lot of people who use weak references for listeners forget that unless they keep a reference to the object itself, it’ll randomly get garbage collected, which leads to strange bugs for asynchronous classes that are hard to reproduce reliably.  If you don’t know what you’re doing or have doubt, just use a strong reference and provide a clear way of removing it later.

Any help you can provide… would be… well… helpful!

Make no mistake: Helping the Flash Player garbage collect your objects has major, positive impacts.  Even a half-assed approach is better than none.

Let’s take an Array or ArrayCollection full of Strings for example.  He’s within a View, and you removeChild the View, and null the reference in his parent.  The GC will eat it eventually right?  Wrong… you accidentally have a stage listener buried deep within the bowels of a base class of a Button you’ve written.  If that’s all you’ve done, simply removing the child from the DisplayList and nulling the reference, you’ve at least giving back memory the View was using to display itself to the screen.  Glass half full baby!

Taking it a step farther, what if you’re View implemented a destroy method, and cleaned up its internals to help the GC out, and free up some memory of things it’s no longer using?  Remember, the View itself is still locked in RAM because you don’t yet know about the rogue stage listener.  BUT, you at least remove all Strings in the ArrayCollection and null its reference in your destroy method.  Running the Flex profiler, you’ll see some [reap] and [sweep] using more CPU time + memory go down slightly + less String instances.  Yum yum… while your View couldn’t get it’s fat arse outta RAM, you at least managed to free up all of those Strings it had a reference too.  They no longer have any references to them, and therefore they are cleaned up, and the memory THEY use is freed up.  Rad!  GLASS HALF FULL BABY!  Even with a memory leak, we’re lessening the damage by freeing as much memory as we can.

I know this doesn’t fix the problem, but if you’re under a deadline you gotta do what you can to survive.  The only reason I don’t think weak listeners are justified in the deadline scenario is because it’s like you’re not even trying to do the above: thinking about what View’s & classes need to be removed, writing destructor methods, and validating they worked.  Sometimes you just don’t have time to do those things, though…

What do you do in a Mediator::onRemove method?

Assuming you’re PureMVC is setup correctly, then the onRemove function of your Mediator’s will fire when it’s removed from the PureMVC ApplicationFacade.  Here, you can remove strong event listeners you’ve made on the View, remove the Mediator’s view reference by setting it to null, and clearing any other data.  This is where things get hard.

Removing the View’s listeners and it’s reference is easy; there is a 1 to 1 relationship with with Mediator’s and a View.  But what about Commands and Proxies?  If the Mediator registered one or more Commands, it’s pretty clear he should unregister them.  Often I’ve seen Commands that are relevant to a particular View being registered in the ApplicationFacade by overriding the initializeController method.  For smaller applications this is ok.  For larger ones, it’s still ok in that they don’t necessarily take a lot of RAM.  The problem is this doesn’t scale.  Your Facade will get really really large.  Some people compensate for this by creating multiple Facades for the relevant Application Domain (called Contexts in early RobotLegs builds).  While this spreads the damage, it removes relevance from the code; it isn’t immediately obvious what problem domain these Commands are associated with.  When the Mediator registers them, it’s usually pretty obvious.  That, and it makes it easier to remove them with confidence without worrying about breaking things.

…Proxies, however, are another story.  Proxies are the #1 cause of race conditions in PureMVC.  Regardless of how they are written (holders of data as your Model or Services or both), they are often encapsulated enough that they could be relevant to many different Views, and thus many different Mediators.  This causes a problem in knowing when they should die… if ever.  The benefits of using a stateful client like Flash Player RIA’s, as opposed to a paged based, non-AJAX HTML application, is that you get the benefits of keeping data in RAM.  This in-RAM data allows the application to be quick and responsive.  As long as your data is ActionScript objects (excluding XML, Strings, Bitmaps, and large ByteArrays) your memory usage is often very low.

Therefore, there isn’t a lot of harm leaving Proxies around.  The one side effect is when your profiling your application via System.totalMemory, you’ll notice it doesn’t go down as much when you’re View is destroyed.  Using the Flex profiler, when taking memory snapshots, you’ll notice you’ll have a lot of potential loitering objects (things that are still around in memory even after your View is destroyed and Garbage Collection has run).  If you’re trying to track down a leak, some of those loitering objects, your Proxy and his data, are valid… you want them to loiter in the first place so you can immediately access them again later.  Additionally, you’ll need to write more defensive & proactive code in your PureMVC code that accesses the Proxy.  For example, instead of registering the Proxy every time, you need to ensure it’s not already registered.

private function getSearchProxy():SearchProxy
{
        var searchProxy:SearchProxy;
        if(facade.hasProxy(SearchProxy.NAME))
        {
                searchProxy = facade.retrieveProxy(SearchProxy.NAME) as SearchProxy;
        }
        else
        {
                searchProxy = new SearchProxy();
                facade.registerProxy(searchProxy);
        }
        return searchProxy;
}

Another tactic if the amount of data a Proxy has uses a lot of memory, or you just need every byte you can, is to cache on the local machine.  If you’re running in a web browser, you can use a local SharedObject and save your serialized data.  If you’re using AIR, you can read from the local disk via File, or use the local SQL database support. When the Proxy is re-created, he can check the local cache first, validate the data is good, and use it instead of fetching it again from the back-end.

Bottom line, if you DO remove a Proxy, that’s your cue to go implement his onRemove method as well.  Here’s an example of a Mediator cleaning up its View reference & listeners as well as proxies.

protected override function onRemove():void
{
        if(community)
        {
                community.removeEventListener(LoginEvent.LOGIN, onLogin);
                community.removeEventListener(LoginEvent.LOGOUT, onLogout);
                community.removeEventListener(LoginEvent.CHANGE_PASSWORD, onChangePassword);
                community.removeEventListener(SearchEvent.SEARCH, onSearch);
                community.removeEventListener(PowerEvent.OPEN_POWER, onOpenPower);
                community.removeEventListener(PowerEvent.DELETE_SEARCH_POWER, onDeletePower);
                community = null;
        }

        facade.removeProxy(AuthenticationProxy.NAME);
        facade.removeProxy(SearchProxy.NAME);
        facade.removeProxy(GetPowerProxy.NAME);

        sendNotification(ApplicationFacade.COMMUNITY_SHUTDOWN);
}

And here’s an example of a SearchProxy nulling out internal data, an ArrayCollection and a String, as well as cleaning up an internal web service.

protected override function onRemove():void
{
        powers 		= null;
        _searchText = null;

        if(searchPowersByNameService)
        {
                searchPowersByNameService.removeEventListener(CommunityServiceEvent.SEARCH_POWERS_BY_NAME_ERROR, onSearchPowersByNameError);
                searchPowersByNameService.removeEventListener(CommunityServiceEvent.SEARCH_POWERS_BY_NAME_SUCCESS, onSearchPowersByNameSuccess);
                searchPowersByNameService = null;
        }
}

Remember, once you start implementing clean up methods, you’ll need to keep them in sync with any changes in the class.  Tread with confidence.

Conclusions

Managing memory in Flash & Flex applications is hard.  Validating your hard work actually is paying off is time consuming.  Most programmers who are used to managing memory keep it in the forefront of their minds while their coding, so they often don’t perceive it as an issue/challenge.  A lot of times the frameworks we use handle a lot of the mundane details of these operations for us (like Tweening engines).

If you’re application does need to run for any long length of time and you’re using PureMVC, having a good, up front understanding of what Views need to stick around and which ones don’t will help you better plan for which Views, Mediators, and Proxies you’ll need to write code for to free up memory.  If you do your best to make each View follow it’s own Application Domain problem it’s solving for, then it’s easier to have that entire silo follow the standard removal scenarios, and thus code to it.

For example, if you are creating a FAQ View, and it has a FAQ Mediator with a FAQ Proxy, then it’s pretty simple to clean up thing when you’re done: implement a destroy method in your View, then implement onRemove methods in your Mediator and Proxy.  When in doubt about the Proxies, just keep ‘em around since they usually aren’t the biggest memory offenders… but be sure to validate this using the Flex Profiler and/or System.totalMemory as even rogue XML can take 200 megs or more.  It’s easier to make View’s more efficient than it is to solve for race conditions in PureMVC.

A good tool to help visualize your memory usage in real-time is Mr. Doob’s “Stats”.  Just be sure your system is only running 1 SWF at a time as System.totalMemory, what Stats uses, applies to all SWFs running on your box.  I usually wrap him with a UIComponent, add a right click menu to my app to open him via ContextMenu, and launch him via PopUpManager.  Another tool you can use is Flex PMD.  It’ll help identify which code isn’t used… and perhaps should, like destroy methods that aren’t ever called.  Finally, if you’re desperate on Flash Player 9, you can also force Garbage Collection via the LocalConnection hack.  This saved us on a project where we were loading SWF’s.

Remember, if you destroy & recreate a View and his PureMVC equivalent classes a lot, you may fragment the memory over time, so don’t get overzealous.  Use your best judgement, and don’t be afraid to get the designers help on which sections of the app need to be the most responsive, and which ones it’s ok to lazy load.

What is RobotLegs?

RobotLegs is a MVCS framework for Flex & pure AS3 applications.  You can use with Flash as well.  I call it PureMVC done right.  She’s still not at version 1, but is really close (docs in progress).

What is Gaia?

The Gaia Flash Framework is the Ruby on Rails for building Flash websites.  You can code generate your entire Flash website in seconds.  It has modules, SEO, page navigation, and deep-linking all built-in, amongst other things.

Why?

Gaia is great for building websites, but it’s just a platform for you to build on, a bunch of helpful scaffolding; it doesn’t prescribe a way to build your applications.  Specifically, you have to write your own code for Business logic and Application/Domain logic.  You still have to write code to hit back-end services, parse the returning XML/JSON/AMF, and act on that data.

This is where an application framework like RobotLegs comes in.  You’re domain model goes in the Model classes, your Business logic goes in the Service classes, and your Domain/Application logic goes in your Commands & Mediators.  You setup your shiz in your Context class(es), like PureMVC’s ApplicationFacade

Gaia builds your site, and RobotLegs makes it work with dynamic data.

Requirements

Before we get to the “How”, you need to know 2 requirements first.  This may scare some people off.

1. You need both mxmlc & Flash CS4 or CS3
2. Your application must be AS3

RobotLegs requires compiling in mxmlc because of the custom metadata tags.  Flash CS3 & CS4 do not currently support the -keep-as3-metadata mxmlc compiler parameter, thus, you must compile your RobotLeg’s implementation code using mxmlc (via Flex Builder 2, 3, Flash Builder 4, FDT, FlashDevelop, etc.).

While you can compile Gaia to an SWC in Flash CS4, and then re-compile via a Library linkage in mxmlc, this defeats the purpose of using the Gaia workflow in Flash.  I understand this is deal killer for many automated build/continuous integrations of Enterprise applications, so I’ll cover optional build scenarios in a future article.

Flash CS4 is required because it allows you to link to external libraries, in this case, Flex created SWC’s.  You could utilize Flash CS3, and just add a class path to the RobotLegs classes since you’ll typically only be using the interfaces in your Flash/Gaia specific code.  Both Flash CS3/CS4 will be exporting AS3 code since RobotLegs is for AS3, so you can’t use Flash 8 and export to AS2.

I currently do not have access to Flash CS5 alpha/beta to determine if it’s integration with Flash Builder 4 demoed at MAX 2009 would help in this instance, nor do I know if it can -keep-as3-metadata.

Quickstart Preface

The Quickstart may appear intimidating at 15 steps.  If you know Flex Builder/FlashDevelop, Flash, Gaia, and RobotLegs, you’ll do just fine, it’s not that bad.  Additionally, you only need to do this stuff once.

The rest of your project, you’ll spend in your code editor.  You can also link the Main file in Flex Builder to get code hinting on it.  The only time you go to Flash is to do Control + Enter.

GIT-R-DONE!!!11oneone

Quickstart

1. Setup your Gaia site.

2. Open up your main.fla in Flash.

3. In Flash CS4, go to File > Publish Settings, click the Flash tab, click the Settings button next to AS version, click the Library Path tab, and link to the RobotLegs.swc.  In Flash CS3, just add a class path to the RobotLegs source code directory.

4. Save your main.fla.

5. Create an ActionScript 3 project in Flex/Flash Builder, FDT, or FlashDevelop.  Point it to the same directory your Gaia project lives.  I suggest changing bin-debug to bin since that’s what Gaia uses.  Although it’ll generate a SWF, it’s hereafter referred to as a “module” SWF since Gaia will load it in and use it’s pre-compiled classes.

6. Create your own main class, differently named (ie not “Main.as”), and put next to Gaia’s Main.as.  This will be where your RobotLegs code lives.

7. Link to the RobotLegs.swc as a Library.  If you are in Flex/Flash Builder, you may wish to link to the RobotLegsLib Library project instead.  If so, I put this in Gaia’s lib folder next to the FLA’s that Gaia puts there.  The image below shows linking to the Library Project.

8. Create a “MainContext” ActionScript class where ever you’d like in your package structure.  Might I recommend something other than Gaia’s pages directory, like “com.company.project.robotlegs.contexts”.  In this class, you register your modules, in this case, your Gaia pages that actually need Mediators.  Here’s mine:

package com.jxl.gaiarobotlegs.robotlegs.contexts
{
        import com.jxl.gaiarobotlegs.pages.IAboutPage;
        import com.jxl.gaiarobotlegs.robotlegs.mediators.AboutMediator;

        import flash.display.DisplayObjectContainer;

        import org.robotlegs.mvcs.Context;

        public class MainContext extends Context
        {
                public function MainContext(contextView:DisplayObjectContainer)
                {
                        super(contextView);
                }

                public override function startup():void
                {
                        mediatorMap.mapModule('com.jxl.gaiarobotlegs.pages::AboutPage', IAboutPage, AboutMediator);
                        super.startup();
                }
        }
}

Notice the mapModule method goes “Your Gaia Page class as a String”, “The interface the Gaia Page class and the Mediator share”, and “The RobotLegs Mediator class”.  NOTE: In older builds of RobotLegs, they are using the fully qualified class name which is ::AboutPage, not .AboutPage (more info).  I have a hacked version locally which accepts a normal package path of “pages.AboutPage” vs. “pages::AboutPage”.  Yes, I’ve asked the RobotLegs authors to fix this.

9. Create 1 more class and 1 corresponding interface: a Mediator class for whatever Gaia page you’ll be mediating, and an interface of the same name with the I prefix.  Example: If you’re creating an “About Us” page for your site, you’ll probably have an about page node in your site.xml, and thus a corresponding FLA.  Create an “IAboutUs” interface, and an “AboutUsMediator” class that implements the interface.  Your Gaia “AboutUsPage” class will also implement the “IAboutUs” interface.  This is how RobotLegs will communicate to your Gaia code via the Bridge Pattern (more info on why).

Here’s the interface:

package com.jxl.gaiarobotlegs.pages
{
        public interface IAboutPage
        {
                function setAboutText(value:String):void;
        }
}

Here’s the Mediator:

package com.jxl.gaiarobotlegs.robotlegs.mediators
{
        import com.jxl.gaiarobotlegs.pages.IAboutPage;

        import flash.events.TimerEvent;
        import flash.utils.Timer;

        import org.robotlegs.mvcs.Mediator;

        public class AboutMediator extends Mediator
        {
                [Inject]
                public var aboutPage:IAboutPage;

                private var timer:Timer;

                public function AboutMediator()
                {
                        super();
                }

                public override function onRegister():void
                {
                        timer = new Timer(3 * 1000);
                        timer.addEventListener(TimerEvent.TIMER, onTick, false, 0, true);
                        timer.start();
                }

                private function onTick(event:TimerEvent):void
                {
                        timer.stop();
                        timer.removeEventListener(TimerEvent.TIMER, onTick);
                        timer = null;

                        aboutPage.setAboutText("Blah blah blah,nthis is from RobotLeg's 'AboutMediator'");
                }
        }
}

Thing to note in the above is the Dependency Injection via the [Inject] tag does IAboutPage vs. AboutPage; this ensures mxmlc doesn’t attempt to compile Gaia code into your module SWF.

10. Any events your Gaia About Us page will emit, put in the IAboutUs interface.  Any data your Gaia About Us page needs to have set on itself, implement a setter or a method in the IAboutUs interface.  This’ll ensure your About Us page class in Gaia and your AboutUsMediator won’t compile until you implement those methods, nor will your AboutUsMediator RobotLegs class.  Yes, I know events in interfaces aren’t enforced, but that doesn’t mean you shouldn’t do it.

Here’s the Gaia AboutPage class:

package com.jxl.gaiarobotlegs.pages
{
        import com.gaiaframework.api.*;
        import com.gaiaframework.debug.*;
        import com.gaiaframework.events.*;
        import com.gaiaframework.templates.AbstractPage;

        import flash.display.*;
        import flash.events.*;
        import flash.text.TextField;

        import gs.*;

        public class AboutPage extends AbstractPage implements IAboutPage
        {
                public var copyTextField:TextField;

                public function AboutPage()
                {
                        super();
                        alpha = 0;
                        //new Scaffold(this);
                }

                // called by RobotLegs's AboutPageMediator
                public function setAboutText(value:String):void
                {
                        copyTextField.text = value;
                }

                override public function transitionIn():void
                {
                        super.transitionIn();
                        TweenLite.to(this, 0.3, {alpha:1, onComplete:transitionInComplete});
                }

                override public function transitionOut():void
                {
                        super.transitionOut();
                        TweenLite.to(this, 0.3, {alpha:0, onComplete:transitionOutComplete});
                }
        }
}

Notice the implementation of IAboutPage.  Since Gaia FLA’s by default have “../src” set in their class path, it’ll share the same class path with your ActionScript project.  The only class it’s importing form that code, however, is the interface, which is a few 300 bytes or so once compiled into the SWF.  If you’re clever, you could use External Libraries in CS4, but that’s out of scope for this article.

11. Open up your main.as file in your editor of choice.  First, create a mainContext class reference, like:

private var mainContext:IContext;

12. Override init and do no call super.init.  Instead, write code to load in your RobotLegs SWF that your ActionScript project will create in bin.  You can use a Loader, your own wrapper class, extend Main to abstract away these details in a base class… whatever you want.  I used a Loader for this example.  Ensure you load the classes into the same ApplicationDomain so Gaia can share and use these classes, as well as any loaded SWF’s that need them.

var loaderContext:LoaderContext = new LoaderContext(false, ApplicationDomain.currentDomain);
moduleLoader.load(new URLRequest('GaiaRobotLegs.swf'), loaderContext);

13. In your Event.COMPLETE function, snatch your MainContext class from the loaded SWF, instantiate it, and pass the stage in, and call super.init to let Gaia know you’re done, like so:

private function onComplete(event:Event):void
{
        const mainContextClassName:String = "com.jxl.gaiarobotlegs.robotlegs.contexts.MainContext";
        try
        {
                var mainContextClass:Class = moduleLoader.contentLoaderInfo.applicationDomain.getDefinition(mainContextClassName) as Class;
                mainContext = new mainContextClass(stage) as IContext;
        }
        catch(err:Error)
        {
                trace("Failed to find class: " + err);
        }
        super.init();
}

You use the stage so any DisplayObject added to the DisplayList will be checked to see if it has an associated Mediator.  Yes, I know OOP Purists will groan at this; don’t worry, I’ll offer a more pure solution later.  Remember, Gaia is typically used in Agencies with 2 week deadlines vs. 4 months; this is more than good enough for that crowd.

14. In your main ActionScript project class, define a dependency variable; this is strictly to ensure your RobotLegs code is compiled into the “module SWF”.  Assuming you have Build Automatically on in Flex Builder, it should make your SWF in the bin folder for you once you save.  Here’s mine:

package
{

        import com.jxl.gaiarobotlegs.robotlegs.contexts.MainContext;

        import flash.display.Sprite;

        public class GaiaRobotLegs extends Sprite
        {
                private var mainContext:MainContext;

                public function GaiaRobotLegs()
                {
                        super();
                }
        }
}

15. Test your Gaia project in Flash.

Conclusions

As you can see, all you need to do now is code all your code in Flex Builder (or editor of choice), and anytime you need to compile your site, you just go back to main.fla in Flash and hit Control + Enter.

You’ll also notice I create one “global” context here.  Reiterating, this is good enough for most design agencies as not every Gaia page will need a Mediator, and most Gaia pages aren’t that complex View’s anyway.

For the purists, in a future article I’ll explain how you can modify the Gaia template files, and configure your Context classes via the Gaia site.xml externally.  This ensures that the details of a Gaia page registering it’s own Context, or simply just creating a single Context + Mediator for itself, are self-contained and as strongly-typed as possible.

For those building Enterprise sized sites with automated build processes, I’ll later go into how you can integrate a Gaia site into your build process.

Thanks

Just a quick thanks to Steven for helping answer my Gaia architecture questions, and to the RobotLegs crew for helping me work out the details of how it could be done.

The following is a set of articles relaying my experiences in Flex consulting with the hope they will benefit others.  While they include general consulting advice, they are specifically geared towards Enterprise Flex software development consulting.  I try to compare and contrast with contracting to give context.  While it’s mainly focused on Flex, there are the occasional Flash references as well.

Consultant vs. Contractor

There are 2 camps: those who believe contracting and consulting are the same thing, and those who do not. I believe they are two different disciplines.

A contractor writes code for another company. A consultant does more than just write code; she does the typical consulting process:

1. Listen to the client’s problems
2. interview project members by asking questions
3. investigating project requirements, design documents, code base, and project tracking records
4. write up a plan that contains a set of solutions to the client’s problems, and present it
5. implement the plan

Consultants can be contractors; they can be called upon to be team augmentation, or the team itself to build the software, hired specifically for their software development & leadership skills.  While contractors can work for both big and small companies, consultants typically work for only large/Enterprise companies.  This is because the large problems that require a consultant’s skills are found in larger companies, and in turn they are capable of affording the consultant’s rate.

Types of Consulting Gigs

You’ll notice from step #3 in the above mentioned consulting process that consultants are typically brought into an “existing” project.  This can be one that is just starting, underway, or is just completed.  The following 5 are the most common type I’ve encountered.

1. Confirm Our Confidence/Trepidation’s

The client wants to ensure the existing team is “on the right track”.  As a 3rd party, the client is either looking for your vast expertise to confirm the current plan of attack & team skill set is enough for success… or they just want your opinion.  A lot of times this is to confirm what they already know, but don’t necessarily let you know they know.  This is called the “Confirm Our Confidence” or “Confirm Our Trepidation’s”.

2. Why are we sinking?

The project is clearly off track, but no one knows the root cause(s).  The client is looking for you to tell them why.  This is called “Why are we sinking?” or “Save our Flex Project!“.

3. Ensuring It All Goes Smoothly

The client isn’t getting enough traction on the project, and want a heavy hitter.  Since a lot of top talent typically doesn’t do contracting, you often can only find the heavy hitters as consultants.  Other times, the client merely has budget, and decides to reduce their risk by bringing on a senior architect/developer from an existing firm that is known for producing quality work.  Assuming the project requirements are far below the challenge the consultants typically face, there should be no problems completing it, right?  This is called “Ensuring It All Goes Smoothly”.

4. The Last Mile

The client has just completed a project, and it doesn’t work.  They’ve invested a lot of time and money, and are angry/frustrated/confused why there are so many problems.  Sometimes they even try to convince you that it “just needs some minor bug fixes” and it’ll be fine/good enough for their needs.  They call upon you, since apparently you’ve successfully completed many projects, to figure out how to get them to, and past, the finish line.  This is called “The Last Mile” project.

5. Last Minute Replacement

Making software takes a team.  On every team you have one or more senior developers; the developers who “have done this before”.  Without their leadership, projects can get really bogged down, and often fail to launch on time, or at all.  Some clients for one reason or another, often under not-so-good-circumstances, will have lost their main architect or senior developer.  With no one else on the team who is capable of taking an architecture/leadership role, companies will look for a replacement to ensure the project stays on track.  You are then put in the position to learn a code base you didn’t architect, don’t know, and may not agree with.  You must do this in a short time frame, integrate with the existing teams, and learn their processes.  It’s often done for entire teams, not just 1 individual.  This happens when another firm has a fallout with the 3rd party company/firm for whatever reason.  This is called the “Last Minute Replacement”.

The Consulting Process

As you can see from the above process, and the types of gigs, they aren’t your typical “software development”, even though you do “software development” during those gigs.  These are not mutually exclusive.  Some clients use Agile, some Waterfall, some mish-mashes, and some no process at all (Process.COWBOY_CODING).  Let’s go through the consulting process first, since that part is ALWAYS the same regardless of client.

Step 0: Who’s my boss and define success?

This one I learned from Tom Link over at Universal Mind.  There are 2 questions you should always ask the client, AND get answered, before you start any consulting project.

First, who’s my boss?  Second, what would make you happy once I leave?

For contracting gigs, it’s pretty clear who your boss is; whoever contacted you.  Often project managers are the ones responsible for both the hiring, and managing the remote contractor, in this case you.  Therefore, if a designer emails you comps, and you don’t agree, you usually take it up with the manager via email/phone.

In consulting, it’s usually not the simple.  Often times you’re dealing with large/Enterprise companies.  You may have some random Director of blah blah East Coast operations come in and start making demands.  Seeing others jump, you may get the impression you should jump too.  You shouldn’t.  If she isn’t your boss, you shouldn’t do what they say.  As a consultant, every minute of your day is costing the company who is hiring you a lot.  Anything you do that deviates from your original assigned goal is not only unethical towards the company you are working for, but could potentially cause you not to get paid.

The great thing about being a consultant is you can say and do things an employee of the same company you are working for could never get away with.  Feel free to ignore someone telling you what to do if they aren’t your boss.  Obviously you need to treat these situations with tact, but if you just remember you may piss your real boss off and not get paid, it’s easy to stand firm.

Regarding defining success, it helps keep in mind what you were originally hired for.  If you were originally hired to help enable the team to succeed, and you hand-hold them to victory, technically you failed at your job.  You can potentially breed resentment by those you were supposed to empower to succeed.  Remember, you’re not a contractor, but a consultant, a professional specialist hired for a specific purpose: to offer a plan of attack, not actually implementing that plan.  While you may feel good creating a brand new video player for the client, they might not like the bill when all they asked for was you improve their existing one.

Knowing who your REAL boss is keeps you out of trouble.  Knowing your true objective keeps you focused amongst the chaos that WILL ensue around you.

Step 1: Listen to the client’s problems

When you are looking for a new contracting gig, you are looking for a client who wants you to build something for them.  ”I need a Flash widget”, “I think I need a website that does X”, or “This video player needs to have these custom features”.  Inheriting other people’s code to fix isn’t very profitable, and is often a miserable experience.  Therefore, a lot of contracting where you’re “building things” for clients is a lot of fun, and often a positive experience.

Consulting often times is done under negative circumstances.  ”We were building a Flash widget, but ran into trouble”, “We don’t understand how a website could be so challenging to build with $80k worth of development over 4 months with so little to show for the time and money”, or “our video playback performance is very poor”.

You first, and foremost job as a consultant is to listen.  You need to get the whole story, and you NEVER get it during the hiring process.  A lot of the times the story you get is only the tip of the iceberg, misleading, or just wrong.  This isn’t to say it’s always wrong; a lot of times you do get an accurate assessment from management.  The key here is you need to get the details so you can ensure whatever plan you create to fix it is the RIGHT plan.  Creating a plan to optimize the client side code to improve performance when in reality the back-end servers just never work consistently, nor was any thought put into optimizing the messaging format makes you look incompetent, or trying to take advantage of the situation.  Part of your plan could include allotting additional time to investigate the service layer’s issues, and come up with a plan to fix them should they have issues.  [Did you catch that?  I just said "plan to plan" in so many words.  Just seeing if you're awake!  --JXL]

There is also the potential for negative pretense about your arrival that can affect the story you get.  While you may perceive the management as good for caring enough about a troubled project to bring an expert in, those on the project may hold resentment towards them, and displaced aggression towards you.  Therefore, you may get answers to your questions colored with emotion, or nothing useful because emotions are so raw.

The point here is to ask questions, investigate, find out what’s really going on.  The information you garner will enable you to formulate an effective plan to fix/solve the client’s problems.  This process doesn’t necessarily stop, but by the time you are presenting your plan, you know what the problems really are, and how to fix them.

Step 2: Interview project members by asking questions

Asking questions.  It’s the same thing you’d do if you were a contractor trying to build software for the client, or a consultant trying to save a project from doom.  What back-end am I hitting and what is the data format we’re exchanging for both the request and the response?  Where are the design comps?  Why were they created like this?  Who is the designer and is there a nearby open window to throw them out of?

You need to learn who is on the project, who those people are, and what makes them tick.  You need to learn how they act, and how they acted under the circumstances of the past to better predict how they’ll act in the future.  You need to learn why those decisions were made, and truly understand what the the ramifications of those decisions were.

The point of this step is to figure out what the true problems are by talking to the project members.  Your goal is to glean as much information about the project as possible.  From that information, you can formulate a relevant plan of attack to help solve them, one tailored so that it will work in the particular organization you are working with.  Notice the keyword “help” in the previous sentence; often times in Flex/Flash consulting, you are the one who will help implement the plan.

Step 3: Investigate the designs/code/requirements

While this is often done in tandem with step 2, a lot of step 3 can be done alone with questions posed in emails and phone calls.  Getting a team member to walk you through the code is something you’d do in step 2, while walking through yourself and getting familiar with it is step 3.

Here you start digging in and ask questions like “Why did you all choose this framework?  Why not this other framework instead?  Did you know about X, Y, and Z when you started down this development path?”  Your goal here is to get history on an existing code base or project plan.  ALL code bases have a story.  Code is born from the 4th dimension.  Software developers will often debate about best practices as if code existed in the 3rd dimension, but it does not.  All code has a reason the way it is.  It came from a certain set of decisions that shaped what it is today.  These decisions where made under certain circumstances.  Those decisions were made by certain individuals and teams who were in those circumstances.  Context is key here, and once you can tell the story of the code, you’ll have a good understanding of why it is the way it is.

An example is, “The code base is a large Flash website created by a 3rd party agency.  Some if it is a professional, simple, and easy to understand custom MVC portion.  The code in the associated FLA’s, however are not.  The reason for this is that a senior developer was brought on initially to setup the website.  Apparently, this senior developer moved onto other projects, and junior Flash Developers were brought on to finish the more GUI related tasks.  This worked out well for the agency since the junior developers didn’t have to know anything about the framework; they just wrote 1 line of code on the root timeline.  The downside is that while the framework was flexible, portable, and provided a good foundation for the code, the FLA’s themselves, all 32 of them, were basically useless to re-use.  The amount of time spent figuring out, and attempting to finagle already badly written code to work would not be worth our time.  Since the current redesign plan is currently in flux, and the client now owns the code, we can work with the in-house team to start building a firmer foundation on the View portion, and create easier to work with FLA’s while still re-using the older FLA’s assets.  The Model and Controller portions that run the website can remain the same.”

You’ll notice I’ve already started to form opinions about a possible plan of attack whilst writing the story.  That’s the point; you’ll recognize possible scenarios on what your team can do to make the most in the current situation given your current resources.  From there, you just need to document it.

Another example, when you look at a Cairngorm code base and go, “Why the F$*^ didn’t these guys build this using Gaia!?”, you know’ll how to answer your own question: the team was an existing team of server-side Java developers doing Flex for the first time, and the small size of this project seemed like a good test case for seeing how Flex performed in their department.  Flex was specifically created for developers because Flash never took off in the software development world, and Gaia currently doesn’t work with Flex.  That, and they perceive this “website” as an “application”.

This becomes more important when you start to recognize problems not just in the code, but in the development processes in the team, and perhaps the client’s organization.  A lot of times the code’s poor state is a direct result of those managing the developers; ie they are setup to fail.  Other times, 1 developer is preventing the others from succeeding.  We as coders sometimes get too focused on the code, when the code is the last thing that can positively affect itself.  Unfortunately, it’s often easier as a good coder to merely fix the code because you don’t think you can fix management or their processes.  Often times, this is what you must do.

Now, a lot of times you may think, “Oh man, I hate this framework, I’m going to re-write this whole thing in my other favorite X-framework, and then we’ll be able to make progress”.  If you ask around, though, you may find that the team had specific reasons for doing so.  Hiring Cairngorm developers is a lot easier than hiring PureMVC developers, for example.  Maybe the team didn’t know the other frameworks and decided on the one they chose because they all participated in company-paid training for it.  Or, maybe the team claims they know other frameworks, but they really don’t.  Training is often an option and sometimes a crucial part of consulting, but again, you need to remember what you were hired for.  Sometimes, the code base is just too big, and you might not have the resources to port it in a reasonable time frame without sabotaging productivity of the rest of the team.  Worse, you port it, the app has “more” bugs because it’s fresh out of a major re-factoring effort, and the client is wondering why they hired you.  For the big code bases, you often need to figure out how you can make the most with what you got.  That phrase, for me anyway, often never happened in the Flash world, but happens ALL THE TIME in the Flex consulting one, merely because the projects are so large.

Step 4: Write up an Implementation Plan, and Present It

Based on your talking with team members, and doing your own investigation into the code and design comps, it’s time to create a formal plan.  There are 3 goals for this.  First, to formally show the client what your professional recommendations are.  Second, while writing, you help solidify what those recommendations are now that they are written down formally.  Third, if you get caught up working on other things during the implementation phase, you can remember what your true goals were, and re-align since you can refer to the document.  To get to this point in the process usually takes me 2 to 3 weeks on-site with the client.  I’ve done it in 2 to 3 days before, though.

The plan can follow the typical “tell what you’re going to tell them, tell them, tell them what you told them” format.  The plan is often a document that has 3 sections.  An executive summary, problems & solutions, and conclusions.  Your executive summary is a 4 sentence paragraph summarizing as high level as possible what you were hired for, what you found, and how you plan on fixing it.  This is both for management to get a quick of assessment, and it’s also great when they forward to true “executives” who don’t have a lot of time, and will not read things.  Having a succinct paragraph that makes it “appear” like you did your research and know what your doing makes it easy for managers to copy and paste that into emails or other reports for example… hence the name, “executive summary”.

The problems and solution section states what problem(s) you found, and each possible solution(s) to each problem.  A problem cold potentially have multiple solutions.  Often solutions to a problem aren’t very straightforward, and you want to give management options.  Like Darrell Ross once told me, your goal isn’t to spend your client’s money, but rather provide transparency to the problems at hand, with well thought out solutions, and allow them to make the decisions that directly affect their project.

Finally, the plan document needs a conclusion.  Here you summarize your succinct, professional assessment of the situation, any other high level risks that need to be made known, and your desire to move forward highlighting the positive results of doing so.

Once completed and proof read, you present this to your boss.  Often times it’ll just be your boss, and no one else on the team.  If you’re a good consultant, you’ll provide the raw truth of the situation, and your honest assessment may offend others.  The client hired you to get the real truth, and you are obligated to provide this; this isn’t personal, it’s business.  This can be done over email, phone, a more formal presentation with slides if others are present who either don’t have time to read the document, or need some high level context on what you are consulting about, and what you plan to do to help fix things.

Finally, the document, as well as communicating it’s contents effectively, legally shows you attempted to provide value to the client vs. stealing their money by slacking off.  Remember, consulting is often done in really negative situations; having a paper trail is good CYA (cover yer arse).

Step 5: Implement the plan.

Also known as, git-r-done.

Contracting?

If you’re a contractor, you may have read a lot of the above and said to yourself, “I already do a lot of that.”  Perhaps you do.  Contractors are often pulled into consulting situations because they are a LOT cheaper than consulting firms, and the contractors don’t realize their monetary worth.  Sometimes only 1 individual is needed vs. multiple consultants.  That, or a firm isn’t found/known to the client.

Mostly, though, contractors are hired to build things, fix things, or help on things.  Consultants are hired to give their professional opinions on existing projects, fix really large, screwed up projects, or help on larger endeavors with multiple consultants helping.  The 2 main differentiators are scope of the project, and amount of emails & documents you write.  If you have the capability to re-write the software from the ground up in 2 weeks, don’t write documents multiple times justifying your efforts, nor participate in meetings with various stakeholders who are all mad… you’re a contractor, not a consultant.  That, and if you don’t charge consulting rates.

Conclusions

Consulting is the disaster recovery of the software development world.  It sometimes has a negative connotation in larger enterprises because by prolonging the problem a firm can make a lot of money.  Others view the client’s resistance to positive change as a no go, and instead choose to let the client fail, THEN come in to help them up.  To me, consulting is a natural progression from being a contract software developer.  You’ve been in enough negative situations, you recognize how to get out of them.  Convincing the client of this, as well as getting them to actually do it, is where it’s challenging.

Software development is hard.  That said, there are a lot of development shops out there that can work with larger companies to create wonderful solutions.  What’s more valuable, and challenging, is working with larger companies to escape horrible situations.  You get into this line of work because either you love the challenge, like the appreciation of clients who are saved from certain doom, or you just fell into it as an “unnatural” career progression like I did.

A lot of times, you and you’re fellow consultants may be very skilled compared to others in your industry, yet you’re given way less time than needed, with an already existing problem code base… and you’re expected to work miracles because “you’re so good”.  …and then God invented alcohol.

If you are an independent software developer interested in getting into consulting, the easiest way to to start is to join an existing firm.  I won’t name names, but there are a few firms in the Flex industry that do this kind of work all the time.  Beware of evangelists/owners from said firms that claim you’ll “work with clients to create engaging solutions, building awesome Flex applications from scratch”.  They are all full of shit.  If you’re any good, you’ll be put in the worse situations imaginable.  Clients like you when you build something awesome for them.  They like you more when you prevent their project from going up in flames… and are often more willing to part with bling.  Consulting firms know this.

To be a consultant, you typically are brought into troubled projects, and use the consulting process to help those projects succeed.  This includes listening to the clients problems, investigating the code, writing up & presenting a formalized implementation plan, and executing the plan.  Everything else is based on your experience, intuition, and luck.

Here’s a video from Tuesday of Steve & Paul showing off the application in 5 minutes.  There are a lot of cool things they don’t show, but this should give you the gist in a short time frame.  Notice the camera is powered via the ethernet cable.

Paul is the only developer I’ve met in my entire career who does accurate time estimations. Also, props to Jonathan Miranda who took over for me and brought her to launch.

Short Version

I’ve built an AIR application in my spare time using Flex that helps you play Dungeons & Dragons 4th edition faster. It took 6 months in my spare time and cost around $50k to build, and $40 a month to maintain.

See and download it here.

It was created in response to my new players, who are tech saavy, having a slow time getting a game going. I copied the design metaphor used in MMORPG games, as well as creating an online database via Django of user submitted content to help the process go faster, as well as supporting house rules. In doing market research, I found my product is for a younger generation, and this makes it challenging to market. I used an Iterative/Agile development process to ensure it got completed.

The app had 3 goals: make money, make our games quicker & easier, and prove to myself I could execute. I succeeded in the latter 2, and failed in the making money… so far.

• Preface
• Introduction: Why the need for Powerz?
• The Power of Power Bars
• Why AIR?
• Why Django?
• Self-Inflicted Iterations
• Quick Note on Scrum
• Schedule
• Technical Details
• Flex 3 vs 4
• Libraries
• Monkey Patches
• Development Challenges
• Feature Casualties
• Marketing & Research
• Target Audience
• Trip to Dragon*Con
• Failures
• Successes
• Conclusions

Preface

I’ve spent my spare time the last 6 months building an AIR application called “Powerz“. Simply, it is an application that allows you to play Dungeons & Dragons 4th edition a lot quicker. It was built in response to newer players hastily flipping back and forth through rule book pages, all the while lamenting how much easier it is to do this in World of Warcraft.

It also became a test for myself. I wanted to see if I could release a product on my own, perhaps even turn a profit. I’ve been attempting for 5 years to create an online version of D&D, fueled by the wishful emails of those around the world who both managed to get their hands on alpha builds and validated my target market. That, and I had recently become an advisor for a startup, so needed creditability that I had produced results in the product sphere as opposed to the service industry which I’m currently in (Flex & Flash consulting/contracting). I had just recently completed my first official Agile/Scrum project getting a startup client to (*ahem* near) Alpha, and upon reflecting, knew I was now capable of releasing a real product on my own.

Introduction: Why the need for Powerz?

D&D 4th edition was created, in my opinion, to cater to, what I call, the “WoW Generation”. Wizards of the Coast, the company also responsible for Magic the Gathering, owns the D&D game. They recognized that to gain broader appeal of a game traditionally challenging to learn and losing market share to video games, they needed to not only make it easier to learn and play, but also target this gaming demographic. The new rules do just that. They are easier to learn for those not inclined to “read a bunch of rules”, and the new power concept allows a gaming group to quickly ascertain how they can contribute to the group.

The problem with the WoW gen’s, though, is that they grew up texting, and not only want, but EXPECT digital tools to be there, as well as cross device. D&D, at least currently, doesn’t totally work like that. They have made great strides in years to provide online digital content, such as Character Builders, rules compendiums, and online magazines with exclusive content. What’s funny to me is that the main goal for most of this content is to be printed to paper and used during gameplay. If you want to use these tools strictly digitally, you can, but that wasn’t why they were made. Ultimately, your still going to be using “real” books during gameplay.

When you have a background in MMORPG’s, or even just gaming on consoles, you look at rule books as primitive, and cumbersome, and ultimately, not as fun. They, like me, know this problem has already been solved digitally.

What kept coming up as a hassle during gameplay with this new generation of gamers was referencing their character’s powers, the main crux of 4th edition rules. I figured if I could solve this problem digitally, I’d be onto something special. I knew I couldn’t solve everything; I’d tried multiple times in the past to digitize the entire D&D experience, and I simply didn’t have enough resources to pull that off. For a digital power bar, however, I didn’t need a lot of resources…

The Power of Power Bars

If you’ve ever played World of Warcraft, Star Wars Galaxies, DDO, or any other Massively Multiplayer Online Role Playing Game, they have the concept of a power bar. There are a series of slots on the bottom, like a horizontal list in Flex, and in each you can drop a power into. It’ll be represented as a little image icon that infers what the power does. Upon rolling over them, they provide details of what they do. Upon clicking them, you use them. While veteran players use keyboard shortcuts and macros, this GUI concept is the core to most MMORPG’s today. Players familiar with such games “get it”, just like you and I understand to click & drag on a scroll bar to scroll text.

World of Warcraft Power Bar

This interface element is important because in MMO’s, those powers, while forming the crux of the 2 most important aspects in those games, chatting & fighting, they also serve another subtle purpose. RPG games in general are technical. They basically take a lot of math, specifically ratio’s & percentages, and personify the results through the use of chance. While neat from a geek perspective, newbie players, especially those not tech saavy, can get overwhelmed by information overload.

Just like how Word hides non-frequently accessed information in menu’s that reveal, so to do MMORPG’s “reveal” information when the user requests it. Additionally, since these interface elements are actually over top of a 3D virtual world, they need to be as non-intrusive as possible.

In short, they provide the user with the ability to learn what their character can do, when she/he can do it, all using a mnemonic device of visual icons that relate to the action in a non-intrusive interface.

Why AIR?

I’ve bashed her in the past and got shot down by desktop developers who came out of the wood work.  To this day I still don’t get clients asking me to build AIR apps.  Regardless, it was a pretty clear choice as to why I needed AIR: offline capability to run Flex apps.

You can play D&D ANYWHERE. I’ve played at friends houses, at a camp site deep in the woods, on a plane, a bus, etc. All of these places don’t always have internet. Nowadays with wireless and cell phones that have decent coverage, you can tether on your device to ensure you have an internet connection just about everywhere. “Just about” isn’t good enough; if you can’t use it, or it’s a spotty connection, you view the “cloud” as holding your data hostage vs. some benevolent caretaker.

So, I didn’t want an internet connection to be a requirement, and thus, targeted AIR vs. a web browser. If you know me, using the Flex SDK was a no-brainer. If you don’t, here’s the run down:

1. Needs to work on as many platforms as possible. AIR works on most PC, Mac, and enough Linux distros. I use a Mac mostly, my gaming group uses Linux and Windows. The Character Builder for DDi works on a PC with .NET. Using CrossOver or Parallels isn’t cheap. Buying an OS + emulation software when you already have a working computer is lamesauce.
2. Writing my own component framework is time consuming. It took me 6 months to build Shuriken for Flash Lite 2, I’m still working on CorePlay for pure AS3… so if I ended up doing that, I’d spend all my time on developing code to develop code vs. finishing my product. Flex has all the components & styling features I need, Flex 4 more so.
3. I make my living developing in Flex Builder. This is what I’m most comfortable, and thus productive in.

Why Django?

Once I personally started using Powerz in my game sessions, taking her for a test run with my gaming group, a new problem arose: setup time. While battles finally went a lot faster, and focused more on strategy and chaos vs. wtf can I do, actually STARTING to play took awhile. Players had to manually input the powers from the Players Handbook into Powerz. Without OCR, this is a lot of meticulous hand typing.  This included those who played with made up house rules.

I thought, why couldn’t we do something like the CDDB days of old? CDDB was an online database where people would submit CD track lists. That way, when you turned a CD into MP3’s, it automatically filled out the song names and album name for you.  By the time it got popular, most CD’s were in the database so you didn’t need to submit them yourself. This was the first Web 2.0 (aka the read-write web) phenomenon that I remember. Basically you are leveraging the community, much like Wikipedia leverages the knowledge from every contributor in the world. This is a double-edged sword, as sometimes CDDB would have incorrect data without an easy way to change it. Wikipedia has had its fair share of drama about article authenticity, and who defines the truth when multiple authors disagree about the same topic.

Regardless, both are using the forces of good, and showcase how leveraging community input can greatly benefit the masses. Two heads are better than one, and thousands are just f’ing awesome.

I set out to build an online database of powers so when one person submitted it, everyone else could use it.  The most common ones, say all 1st level ones for all classes, would be ready to go. That way, even new players could quickly get up to speed. Powerz is supposed to speed up gameplay, and this would be the final lynchpin.

I hate, and suck, and server-side anything. I’d argue the majority of arguments, philosophical debates, and technical podcasts about software are regarding server-side development (iPhone apps aside). When people talk about Inversion of Control, server clustering, or Aspect Orientated Programming, my eyes glaze over, I face palm, and am like, “Wow… that’ll solve like 10% of my problems. That 10% is on the server… WHERE MY CODE ISN’T RUNNING!” To be fair, the majority of all cool software is running on the server. Most Flex apps I’ve written are merely pretty faces for pimp server-side action. The problem with server-side stuff is that you can’t see it. I’m a visual person, I went to art school, and if I can’t see it, to me it’s boring. I like seeing visual results from my coding efforts, and no, logging statements don’t count.

So… I knew I was in trouble with my idea. Every time in the past I had such an idea, I merely turned to PHP, since finding good server devs looking to work for free is really hard. PHP is available on just about every web host, for free, and there are a lot of resources out on the internet for it. It’s also very similar in syntax to ActionScript, so learning it was easy. The problem is, I’m not “in” the PHP community.  Creating a user account system may seem like a reasonable programming task to me, but an ignorant waste of time to a veteran PHP programmer who has used Zend or Drupal on many projects. Most of my endeavors into larger PHP systems have failed because the workload was just to large for me to tackle both the front and back-end. I knew this time I HAD to find whatever framework others were using for a user account system. I’ve failed to find like-minded server-side developers in the past for such ideas. I actually had a friend offer his services for this very project, but I was concerned I might actually make money, and I make a rule of not mixing friends and business.

However, I had just got off a Django project. Having spent 5 years or so evangelizing AMFPHP, yet never actually successfully getting native object passing working, I decided I’d see how easy it was in Python. Additionally, my experiences using Django’s user administration interface along with PyAMF Flex integration was a very pleasant experience. Since I’d already taking a look at Ruby on Rails awhile ago, I figured I’d give Python a chance.

Best decision ever.

I don’t know Terminal, my SQL knowledge equates to SELECT * FROM *, and I’ve never coded Python before. Django is the shit. It’s so easy, I learned my way around Terminal enough to not only “run a local server” (I know, right?), sync my database, and even play with Python code, just like Director’s message window. I even learned how to remote ssh into my production server, install PyAMF remotely, and deploy my code. Django is merely a framework atop of Python, but you have to know all that insane crud just to do it. Oh yeah, and I ended up buying TextMate (in part to Kristofer’s recommendation) to use for coding Python.

Speaking of Python, it’s a LOT like ActionScript 1. Really strange going back to loose typing. Unfortunately, the only real benefit I found was more succinct code. The Aspect Orienated/Functional stuff that uses the Decorator pattern with metadata tags for designating what methods require the user to be logged in only works for more recent builds of Python. Still… I got it and think its hawt. Additionally, the fact that you can import just a method of a class and use it is neat. There’s been a request on an unnamed list requesting ActionScript 3 get this ability so when you import 1 method of a library, you don’t end up importing the whole library, and thus incur the file size penalty. Since SWF is for web, this makes a lot of sense in investing in such a feature. Python’s for loops? Holy fish, advanced, and really cool stuff, way easier than doing similiar things in ActionScript 3 (faster? doubt it). I still don’t get their slicing syntax, but I’m sure if I did it every day I would.

So why Django? Within 3 days I had learned Python, Django, and PyAMF integration to have a working user authentication system working in my Flex app. Blah blah blah… open source has no value… blah blah blah.

…I suck at debugging it, though, a friend told me to look into Python logging, but I just ran out of time… print print print OT OT OT. That, and my admin only works on my local box, not the remote server… *ahem*.

Self-Inflicted Iterations

All my personal projects suffered from the most common symptom that affects a lot of us software developers: starting new projects is ALWAYS more fun than finishing them. You accrue a long list of awesome ideas that never make it to fruition. Of those, a few you blog about. Knowing this industry, a bunch are probably worthy of actually finishing and marketing because they’ll make bling… but… we’re a busy bunch. That, or you see no point because you have no clue how to monetize them.

I’ve had this happen 3 times with my major D&D online project in 5 years, 3 times with some games, and once with every other project that wasn’t specifically created FOR a blog entry since my career started. I almost swore a blood oath before starting Powerz. I didn’t really have too, though, because of circumstances.

First, I had just got off the best gig I’ve had in my entire career. It was working for a startup as a service consultant through Enablus. So, I make bling, but see $0 bling when they insanely succeed. Quite the soul reflection project. Second, I read a book called “Rich Dad, Poor Dad” upon a recommendation form a friend, and was then pissed for 3 weeks straight. Third, I now knew how to do Agile development which was better than my made up iterative process of the past. Fourth, D&D 4th edition really is slow if you don’t know your powers by heart; it’s even worse for DM’s who have 50 billion other things to keep track of. I needed this tool!

I made a simple rule. If I was going to work on Powers, I needed to release SOMETHING a week from when I started. If I grabbed a beer and started coding on a Friday night, there better be a new build, with associated forum post, WORKING up online the following Friday. If I had something come up, like say real, paying work, or my kid(s) got sick, or whatever…. then 2 weeks. If that didn’t work because, say I only had 4 hours in a 2 week period, then I’d lock myself into finishing just one feature before I was allowed to work on anything else.

Failure was not an option. To fail is to fail myself, and everything I stood for, and for those who listened to my blog entries full of “advice”. If I did fail, it meant Agile didn’t work, and all 10 of those blog entries I wrote espousing it were utter bullshit, and I needed to die in a fire. Seriously. After being so frustrated for so long about “figuring out” software development for the past 9 years, this was the line in the sand. Pick your platform, pick your tool, pick your framework, and either put up, or shut up.  Get something done vs. proselytizing about “how to program” with nothing to show for it.

In short, finish something I started.

6 months later, I’ve released version 1.0. That feels f’ing good. Really good. That, and D&D is easier to play now for me, and a lot of others.

Quick Note on Scrum

Remember, if you ever hear about this Agile or Scrum stuff, and are like, “Wtf?”, don’t stress. All you need to know about using Scrum correctly is release working software with a new feature every week (or every 2 weeks). That’s it, that’s all you need to do to be JXL Scrum compliant. If you don’t do that, you should really take a look at what you are really trying to accomplish.

If you’re a manager who’s trying to implement it, and your developers keep going off on paths they weren’t assigned, play to their ego’s. For example, if someone says, “I could write a login form in less than a day!”. If it then takes them 8 days for the form to actually work, call them on it. I guarantee you they’ll spout off about “OOP/Framework setup”, or some other lack-of-DRY-adherence excuse. That’s ok; the point here is to show them that what they thought they could do, they didn’t actually execute on. They’ll either re-assess what it really takes to develop even simple things, or you’ll come to a mutual understanding of what “working” really means.

I had to do that. In 2001, I created a stock charting application in Flash 5, AS1 pre-#initclip days, knowing very little OOP, zero best practices, and no frameworks, in 1 month. Today, that same application would take me 4 to 6 months, and cost 177% more per hour. Granted, the devil is in the details (quality of user experience, less bugs, more features, I actually know what I’m doing now + have experience, etc), but that, to me, says something about my ability to execute. Those in software know faster doesn’t mean better… but when you start splitting hairs about even simple features, you find some surprising things about yourself. I call this, programmer self-awareness through Scrum.

Schedule

For those who are interested, here is how my schedule worked out. When I mention a week, I’m speaking about a week of development time. So, if I started coding on Friday night, but only put in 4 hours for an entire week… I certainly had very little to offer in a true build. So, my first rule was, if I could do a week, do a week, and release. If I couldn’t because I had real work to do, then I’d instead get 1 feature DONE and release. This was still hard, because even if I could only devote like 2 hours a week to my personal project, it HAD to be on that one feature, and I had to force myself to finish it so I could get a build up, and move onto another. It was far from perfect, but it’s as Scrum as I could get with my free time… and it guaranteed I’d release multiple builds with enough room for user feedback.

• First 3 weeks, spent designing & doing initial prototyping (aka design phase in Waterfall). I had no gig lined up, so worked 3 weeks straight on my own stuff. I worked for about 7 days straight in Photoshop CS3.
• Work 1 hour one night, 4 hours another, 8 maybe on a weekend, or perhaps none for 4 days in a row. Bottom line, I still followed my weekly/bi-weekly/single feature release schedule.
• One build took 6 weeks (Alpha 9 to Beta 1) because I had to learn Django and do real work at the same time. Some weeks during that time, I only worked 1 to 2 hours per week, others, I’d work 3 days straight.
• Some weeks were coding. Some weeks were pure Photoshop. Three weeks was learning/implementing Django. Four weeks was setting up the website, porting all code & assets to work on it, and installing all forum and blog software. All was mixed amongst each other. Since I was doing everything myself.
• I did Analytics once in the beginning, and then changed it 2 weeks later when I couldn’t understand my own metrics.
• Start Date: Around April 5th, 2009.
• End Date: Hopefully September 26th, 2009.
• Total Time: 6 months

It’s hard for me to predict how long Powerz would of taken had I been able to spend 100% of my time on it. A lot of things came up, positively & negatively, during development that adversely affected the timeline. Users asked for features, work flows I originally tried didn’t pan out, Photoshop designs took a few tries, and learning Django staggered overall development on the Community portion. All I know is, Flex Builder 3 and Flex SDK 3.3 is foogin’ solid for what I needed.

Technical Details

The web site is pretty standard stuff. Forum is PHPBB, and blog is vanilla install of Wordpress. Hopefully post 1.0 launch, I can modify the blog to match the rest of the site look and feel (excluding forum) via the Dreamer, an easier way to design Wordpress sites via Dreamweaver. Her majesty used it for her site and it’s pretty cool.  I also need to redo my dated screen cast, and tons of other things.

While I did the original web site designs in Photoshop, the site itself was done by her majesty and I in Fireworks.  Fireworks’ text handling is superior to Photoshop’s, and now that CS4 shares the same font engine, you can get good looking interfaces.  If Photoshop were to improve their text handling capabilities, I’d probably still use Fireworks for it’s easier object editing + grouping + moving functionality.  For the web with lots of content, it was just quicker for me and her majesty.

For the video, shot using a Sony DCR-SR200, and edited in Premiere CS3 & After Effects CS3.  ScreenFlow was used for demoing the software.

Flex 3 vs 4

Yes, I very much wanted to use Flex 4. Unlike Flex 2 Alpha, however, she’s unstable and changes all the time. You could build some pretty Enterprise stuff on Flex 2, Beta 1. I would never do such a thing with Flex 4 just because she’s in such flux, and the IDE (+ Catalyst builds) is somewhat flaky. Obviously 6 months later things are more stable… but they still changed a lot (fx prefix, Halo interop, etc.).

I used Flex Builder 3 & Flex SDK 3.2… then 3.3… then 3.4. I use AIR 1.5.2. AIR still has a bug where you can’t seem to use compc (aka Library Projects) because of some weird Vector bug in playerglobals.swc or something. So I just gave up on using a library project.

Libraries

I have 1 Flex project, and a ton of libraries. Ones of note are:

• Cliff Hall’s PureMVC
• Ely’s SuperImage (that I patched)
• Claus Wahlers’ and Max Herkender’s FZip for reading & writing my custom file formats
• Christian Cantrell’s NativeAlert ported to Flex
• Google Analytics
• Google AdSense
• as3corelib for JSON, used in reading & writing custom file format
• Adobe AIR Update framework (which refuses to GTFO of RAM) with custom badges written in Flash (zomg!)
• my DebugMax window which is a lame attempt to copy that older Flash debug window (the Portuguese one)
• …and Grden’s localToLocal function
• Server is running Django on Python, using PyAMF to send AMF objects back and forth. I’m only using one class; getting nested ValueObjects to work with inherited and one to many relationships in Django’s Models was nigh impossible to debug.  For now, I just pass simple Objects which are uber-easy to parse.

Blah blah blah… open source provides no value… blah blah blah.

Monkey Patches

1. Commented out a bunch of InterManagerRequest code in AIR’s NativeDragManagerImpl class. Doing drag operations would cause the app to lock up for 7 to 11 seconds. Not sure if this was fixed in 3.4, but I don’t load multiple Flex apps with different SDK versions, so don’t need this code.
2. Added bitmap smoothing in SWFLoader, which Flex SDK 3.4 (or 3.3 I forget which, added officially)
3. Added a numLines getter to Label for more accurate text height measurement… which I then later didn’t use.  Proper invalidation fixed my measurement bug; text can be finicky, but if you wait a frame……

Development Challenges

There were 3 development challenges I faced.

The first was developing in AIR. If you are using Flex in AIR, it’s nearly the same thing. The hard parts were learning how Windows work, and their quirks (such as when does Window REALLY get its reference to nativeWindow?). How do you design for this as a designer, and what is an appropriate design metaphor? Multiple windows, or 1 window with many states? Also, event bubbling doesn’t work with windows, since each has it’s own stage, so there was a learning curve of when to manually re-dispatch, and when to just hand off to PureMVC Mediators.

The second was learning to work with reading and writing files. The FileReference class is EASY, but there are actually 3 classes (really you just work with 2) for AIR. They too have intricacies to learn, and how you can abstract them, and what the costs are in doing so. What was fun to figure out was how to associate a file with a document window in the PureMVC framework. I really had a tough time trying to tightly couple something when you’re technically not supposed to tightly couple anything in programming.

The third was creating a file format. I believe most traditional developers would of used some sort of serialization via ByteArray and the IExternalizable interface for your objects. To me, that stuff takes a lot of work, and isn’t easy for me to debug, nor verify if it worked. Maybe to those who think in 0’s and 1’s, but not me. It took some tinkering; I copied how SWC works.  SWC is a ZIP file with some XML and binary assets all inside. My file formats are basically the same thing; a ZIP file with a JSON text file holding the serialized object, images for any icons, and a text file determining what type the file format is (since you can’t rely on file extension). This allowed me to open up the file to see it’s contents and confirm my code worked as well as perusing the JSON to see if my objects serialized correctly.

What was great about being the only developer was that I was also the designer and back-end developer.  I knew how to design assets for Flex and could predict what I’d need designed. As the back-end developer, I could create data that the client would need, thus making my job easier in both places.

Feature Casualties

I had 2 features that caused major scope creep, and thus extended how long it took. They weren’t a waste of time, but as with every project, I learned something.

The first was the whole “document editing process” that people are used to. You open a file, edit it, save it if it’s dirty, and close the “document”. If you “Save As…”, you create a new file, yet use same window. I didn’t use this model at first. Instead, I just opened files, kept a reference to the file handle for each AIR window, and removed it when the window closed. However, this is not how every other desktop application works. Additionally, for those on network drives, you couldn’t really work with the files easily when moving things since it always had an opened file handle. So, it was a pretty big re-write/re-factoring effort to put this functionality & work flow in. I know how to do it now, but I’m just glad no one asked for undo yet. *whew*

The second was pimping out Christian’s NativeAlert window. I spent 3 days in AfterEffects when I was between gigs creating a transition in and transition out for the window.  Instead of just popping in, it’d “materialize” in, all magical like. To me, and one of my users, it looked awesome. It got old after 2 uses because you had to wait for it and there are a few alerts when saving files. If I speed it up any, it loses fidelity… so I just removed it. It required a lot of custom code to make the alert do it’s modality magic in time with the transition. I didn’t get to use any of it.

Marketing & Research

This was the most interesting for me. While I’m not a good salesman, I feel that I get online marketing and branding. I also feel like I understand my target audience, since I’m part of that audience. I actually did market research (aka learning my target audience and their needs) both at the start and during development.

I looked online and read about what WotC was offering, and then I looked at all the 3rd party offerings. I took a few for a spin. I read user reviews on forums and blogs, especially the passionate ones. I wanted to gain a better understanding of what they liked about the software, and how they expected software to work. There wasn’t really a pattern. The bitching about lack of Linux/Mac support was low, and a lot of the 3rd parties utilized Java. For those that didn’t, there we already well documented ways of installing a Windows emulator.

One thing that reading the forums did for me was really educate me on the current flux of the industry. Technology really has changed, and continues to change, table top gaming. WotC is in an interesting time of the market, and frankly I’ve think they’ve done a good job on positioning their D&D brand & rules for 4th edition to perform well with these changes. Where they haven’t done entirely well is executing both their community aspects online, as well as delivering their associated digital tools.

The short version of WotC’s transition to the digital age is, as magazine sales declined, WotC first sold their magazines to Piazo, and later brought them back and incorporated them into their new online subscription service; they no longer print magazines. You get the monthly magazines digitally, exclusive content, as well as access to their desktop and web tools. There are good and bad things about this. Some of their software isn’t released years later, but the ones that are are definitely nice.

Target Audience

I wrote something similar to this over a the Powerz blog.  Bottom line, there is a lot of confusion, at least for me, on who really is the target demographic. The high level view is that the older players prefer tangible rule books, whereas the younger ones are more apt to digital content. That’s where the black and white views end. Some from both groups are fine with digital content, but intend to transfer that content to paper in use in their games. Others would prefer to wholly digital, yet still play in person with their friends; like a LAN party.

I intended to confirm this suspicion beyond just talking online…

Trip to Dragon*Con

…so I took a trip to Dragon*Con 2009 this year. I go every so often to stock up on new dice as well as to see the 501st. My goal this year was to promote Powerz, and meet potential customers. I knew it would be challenging for a few reasons. First off, finding D&D players is actually hard. It’s a huge Sci-fi & fantasy conference; it’s not solely for D&D’ers. Additionally, most D&D’ers who do go play with their friends at predefined tables in a reserved hotel ballroom. These are usually niche groups, and while friendly, you can’t just barge in on them in a middle of game. If someone did that to me during mine, I’d be really ticked off. Additionally, the conference itself is confusing because it’s spaced around 4 semi-adjoining hotels (Hilton, Marriott, Sheraton, etc.), and signage isn’t large/verbose enough for you to get a clear picture of where you are, nor what events are happening where. I knew it’d be hard. Her majesty helped set my expectations to a reasonable level.

My first attempt was while waiting in dice line (like a food large buffet, except there are different colored dice you can choose from). One particular customer was taking awhile to get his transaction finished, and was in a TF2 spy costume (I think), so I figured he was a good target.

“Hey chief, you play D&D?”

“Yeah!”

“Cool, you play 4th edition?”

“Naw, 3.5.”

*sigh*

I then asked the attendant who was waiting on customers, but he didn’t play, just pointed to one of his co-workers; but they were UBER busy. Even Solid Snake briefly came out of his box to browse their wares. I didn’t want to annoy every customer, so moved to another vendor booth, full of D&D books.

A girl was just sitting down in a chair, and lamenting about how good it was to sit down. Prime target.

“Hey, you play D&D?”

“Yeah…”

“4th edition?”

Irritatedly, “Only because my group made me…”

“Rad, do you mind if you ask you a few questions about some software I’m building?”

Cautious, and body language suggesting she was about run at the slightest sign I was a vampire, “Ooookkkayy….”

I sat down next to her on the floor to make her feel more comfortable with my laptop, and briefly walked her through why I created Powerz, and what it does.

She immediately got excited, “Oh we already use that through our DM. He uses WotC’s subscription service… DD something…”

“DDO or DDi?”

“Yeah.”

“Which one?”

She shrugged but excitedly explained, “I don’t know, but it’s great. You can input all of your character data, and it prints out all your powers. Our whole group does it.”

I then proceeded to ask her questions about how her group plays, and take notes. Another gent from her gaming group joined in on the conversation, and motioned to a 3rd member who was also browsing books nearby. After I had asked my questions, I thanked them for their time… and went looking for a bar. I suddenly felt insecure, ‘How could DDi do all that? There is no way, I’ve seen the screen shots, read the reviews….’

While waiting for the bar tender who was overworked, and was already getting heckled by some disgruntled women next to me, I reflected on those I had talked to. I knew a lot of the older generation was very pro-3.5, me included. I really like, still, the 3.5 rules and felt they were akin to Macromedia’s Flash 8; the pinnacle of the company. I started getting really depressed, and quickly started going over all of my past research in my head.

…then I remembered something the girl had said. “Print them out.” Print? To paper? wtf? A smile came to my face, I gave up waiting on the bartender, and quickly headed to where I remembered the D&D gaming tables being the previous year. I stopped by the bellman’s desk to obtain some change so I could buy a few people beers in exchange for me pestering them with questions.

Paper. That was really what I kept seeing. The generation gap in that one prefers tangible assets to play with and the younger ones do not. Again, it’s not that black and white sometimes, but it’s still true. While waiting 1 hour and 40 minutes in line, I met a father who had brought his 11 year old daughter to “meet” the creators of the online game she played. It was some alternative to Club Penguin, which was apparently ruined under new management. She was really excited, and wanted to be a programmer when she grew up. The father, clearly out of his element, saw me in my business professional getup, clearly over dressed for such a casual, and often costumed event, and seemed happy to have some one to talk to. He found it strange that his daughter would spend his money on these online games for things that didn’t exist. Instead of a new barbie doll, she’d get a some new, exclusive outfit for her online character. We discussed her online habits, and those of her friends. I explained what I did, and he was intrigued.

His daughter is my target audience. The girls and boy in front of her, definitely early teens, one dressed up as Naruto, and others as Sango from InuYasha… those are my target audience. They grew up texting, the internet always existed. Those who were my age, dressed up as star trek characters… those probably aren’t my target audience. These kids revel in online content, but still have social interactions with each other in person.

People like me, and the kids who are used to digital tools don’t mind keeping things digital. Others see digital tools as a means to a paper end.

Upon leaving, I was convinced my target audience was mostly online and not at Dragon*Con… or at Dragon*Con WITH their PARENTS. It was a great learning experience, even talking to the few people I did was helpful.

Failures

The project as a whole, while successful, failed to meet one of its primary goals: make money. It does have some successes, which I document below. I had two main goals: releasing a product to prove I could execute, and to make money, enough to cover costs. Currently, there is not enough community features to justify a subscription pricing model. Additionally, I highly doubt I’ll get enough users to cover the costs via the ad supported model I use currently.

If you add up all the costs:

• Around 6 to 10 weeks of man hours (design, development, marketing + expenses)
• hosting costs ($20 hosting + $20 Django container @ Mediatemple)

The total comes to around $50,000. Each month I go $40 more into the hole as the ads currently aren’t providing enough revenue to cover costs, and I haven’t figured out how to monetize the anonymous usage data.

I have a new idea that will actually generate revenue, and Powerz could actually be a companion application, so that’s a positive.

I’m not sure about this statement, but… here goes: I’m glad I know I’m capable of executing vs. knowing how to make money and not execute. This, as opposed to someone who knows how to make money, but can’t execute. The sad fact is, most rich people I read about know how to make money, and get other more qualified individuals to execute for them.  Doh!

As a developer, however, I view this as yet another thing to learn, so that’s a good thing! If I start learning how to monetize things better, I can focus my development efforts on what matter monetarily, and eventually find easier ways to leverage help vs. doing everything myself. If at first you don’t succeed, try, try again.

Successes

My favorite part, the wins.

1. I now have a tool to make my D&D gaming easier, and more fun.
2. Others now have access to the same tool, with the ability to help guide it’s direction.
3. I’ve proved to myself for the 2nd time that Iterative development works.
4. I’ve proved to myself that I can execute on my ideas.
5. I learned Django & Python, and also learned not to hate the server-side.
6. I’ve learned, again, how much work it really takes beyond just coding to release a product.
7. I learned a little bit about engaging potential customers.
8. I learned a little bit about market research.
9. I learned how NOT to migrate data.
10. I now have something new to learn: How to make money with software.

Conclusions

While I’m disappointed I failed to monetize my work, it’s still early in the game, so maybe I’ll think of something. Overall, I’m really happy to have finally finished one of personal projects into an actual product. That, and I learned a ton. Soon, onto idea #2!

If you play D&D 4th edition, check it out and let me know what you think. If you don’t, but know people who do, let ‘em know; I’d be most appreciative!