Battletech Live

Online, Turn-Based Battletech – Development Logs

Streamlining Actionscript modules for Battletech Live

    I’ve been struggling with application design over the last few months. As the application size grows, it’s becomes a monstrous task to keep organized. Several options can be used to keep the site organized and smooth, but many of them make the SRC directory structure hard to follow. The publicly accessible version of the site is organized as follows:

  • The main application consists of the application frame, sign-in and registration panels, both left-side menus and the bottom menu.
    • One module is loaded for the contents of the upper menu.
      • The menu consists of five tabs, four of which are currently coded directly within this module.  The mp3 player is a separate application file loaded into a canvas.
    • One module for the bottom sliding menu.
    • Five modules for the various items in the upper-left menu.
      • Account Settings, which loads a further two modules.
        • Display Preferences
        • Avatar Settings
      • User Email
      • Event Calendar
      • Community Forums
      • Live Chat Rooms

While all well-and-good, the size of the primary application file is becoming extreme, at 672kb. While this doesn’t seem like much, the components needed to simply load modules, takes up 400kb on it’s own.  The transitions necessary to make things move smoothly from page to page take up more than 200 lines of code, one each.  The X and Y coordinate and the Shared Object size, while used for development only, look out of place, just floating in space and the development logs and administrator contact are hard to find, buried in the lower sliding menu.

Under ideal conditions, the main application file should be as clean as possible and contain very little but a loader.  That loader should then be responsible for organizing and loading the remaining content for the site.  As I begin splitting portions of the site off into their own modules, I quickly begin having problems with siblings killing one another.  For instance, I couldn’t get the login window and the main application layout to load at the same time.  If the layout was told to load, it would destroy the login window.  Adobe states that if two modules are loaded, definitions should be made in the main application file rather than within the modules themselves, otherwise the module that makes a definition owns that definition and it’s unavailable to other modules.  This is a major pain.  Additionally, I discovered that if a module is optomized against the main application file, the module can suddenly and inexplicably die and I’ve found that when they do work, communication between modules can be extremely difficult.

After much work, research and aggravation, I’ve settled upon the following structure:

  • The main application window contains 37 lines of code that defines the loading of three modules and two states.  The file size is now a much smaller 196kb.
    • The first module to load is a development window, seen along the right side of the screenshot below.  All of the information I need for development is moved into this panel, as well as the rundown of segment completion and status updates.  This panel can be collapsed using the arrow at the top and the administrator contact form can be accessed by using the life preserver along the top.  While it can be minimized, this panel is always visible.  The timer and triggers are moved into this module, as well are the record keeping for who’s logged in and such.
    • The next module to load is the signin/registration panels.  This module consists of only two states.  When a user signs in, variables are passed to the development window.  Taking much of the responsibility away from the main application, this module is now 224kb.
    • The final module to be loaded into the main application is the interface layout used for everything else.  This file is still in the process of being trimmed, segments broken out into their own modules where they make sense, but I’m still at 150 lines of transitions, 650 lines of code and eight subordinate modules.  The file size is 488kb.  As I move forward, I expect the number of modules to increase, but the file size to decrease.  The primary responsibility of the file should be display the layout and menus, sizing them per the detected screen resolution and preferences as defined by the user.

Picture 1

Advertisements

June 24, 2009 - Posted by | Project Development

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: