Online, Turn-Based Battletech – Development Logs

For the readers who have been following along, I’ve been working on a problem for quite some time. The main application file contained most of the structure for how the site worked, while detailed components such as the calendar, email and avatar selectors were built as separate modules that were then loaded into containers. The problem is that the code necessary to enable a module to be loaded and to be fully referenced took up 400kb, making the main file anywhere from 600kb up to 1.1mb, depending on how much or how little I stripped out of it. It seemed that the more I removed, the larger it got, needing to keep references around to make the other modules usable. I followed a comment from a user, stating that the main file should be extremely small and should contain very little except the code necessary to load a single module, which would then act as a loader for everything else. That’s where my big issues began.

When I moved the primary constructors out of the main file, inter-module communications fell apart completely. I could load modules in, but I had no way to send data between them. I’ve now started working with Local Connections, which are proving to be extremely beneficial. A Local Connection is essentially a pipe that is connected between two modules and is one way. They allow variables to be passed from one to another, as well as for functions in the target to be called. For example, a login box allows a member to sign in and upon completion, an image in an accounts module needs to change to reflect who is signed in. However, the login box is incapable of saying “acctBox.memberPic.source=pic;” because one module doesn’t have literal access to objects and functions of another module. Instead, the login box processes the signin as normal and retrieves a number to represent the users picture. It then creates a connection to the accounts panel, passing it the connection name, a function name and a variable. The accounts panel then executes the function it’s told to run and uses the variable passed to it to set the icon. It’s actually extremely simple, it just sounds complicated.

The big thing is that any single connection name should be reserved specifically for one sender and one recipient. If one module has a need to at times, send information to three different modules, then it needs three connections. Then, if one of those modules needs to send information back to the first module, a separate connection is made. The easiest way to organize this is to set the name of the connection as sender_recipient so that everything always ends up in the right place.

I’m going to get started on this tonight, but I expect it to solve at least 80% of the problems I’ve been encountering.

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.

My son is visiting me this week. He was supposed to be here for three weeks, but upon hearing of a new cancer case in the family, it’s being cut short and I’ll be visiting parents in a couple weeks.
The other day, my roommate came home for lunch and found my son and I asleep in the living room, taking the following picture.

Connor fell asleep leaning over a footstool. Later, he fell over, waking himself up and started crying.

I have an mp3 player in the works. At this point, I have a static list of songs that can be selected or cycled through. The things I’m trying to work out is how to set up a random function or get it to play the next song in line instead of the same song over and over again. Instead of a static playlist, I’m working in php to have it build an xml list based on the target directory structure so that multiple lists are available and are subject to change based on those contents. The next task will be to deal with id3 tags and to pull artist and song length automatically.

I hope to have the bugs out and it up and running within a couple days.
I will have multiple colors available and probably a number of watermarks based on a several of preferences.

I learned something new today. Last last week, I began making a few modifications to Battletech Live, trying to bring a few of the components into tighter integration. I moved a mini calendar from the left side menu into the drop-down menu used for Instant Messaging. I also moved the container for the helpdesk contact and for invitations into this panel. What this meant is that these three components were now part of an attached module instead of part of the main application. What I found is that if I loaded this newly modified module before loading the development panel that appears in the bottom center, the development module would fail to appear, but if I loaded the development module first, then the messenger module, the messenger module would die and start throwing errors.

I know that if you have two modules that have similar components, those components must be defined within the parent application, else one child will kill the other upon implementation, so I began going through my code to see if there was anything in either module that wasn’t present in the parent and I didn’t find anything. While looking at tutorials for the ModuleManager controller to check my code, I found information about sub-applications as opposed to modules. In an instance where a component is a display-only element, not needing to send information back to the parent, it can be configured as a stand-alone application, then tied into the parent application through the use of an SWFLoader. In my instance, the sub-application can still communicate back and forth with the server and as long as it doesn’t have need to affect elements of the main application, it works perfectly. These components are compiled separately from the main application and can be run on their own, which makes development faster and less dependent on the functionality of a single computer. An interesting added benefit is that I could also tie in swf files on other servers, and those written by other developers, which gives me the ability to coordinate with other people in order to add extra functionality to the project.

Now that this is sorted out, I can get back to developing new material instead of trying to fix the existing.

Other than breaking things in Battletech Live and fixing other things, I’ve been looking at design options for various units. I’ve started with Atlas.

Illustration of the original FASA Atlas model.

An Atlas in use in Classic BattleTech.

Atlas from MechCommander 2

The original Atlas is a little chunky, but still a good design. The pewter model is nice but in some ways, still seems like a collection of boxes piled together. The model used in MechCommander 2 is extremely plain, as most of the models are, and uses the paint scheme to make it appear to have more detail than it really does. The first picture below is a drawing I found of an Atlas that has been heavily redesigned. While this is an excellent picture, I think it’s a little too far separated from the original Atlas. I might make something like this available to the later time periods, but not to the early years. The next picture is the lower half of a Kodiak. I think that they’re similar enough that this could serve as a workable style element for Atlas. I like the angular look to it. The third is a Mad Cat made with Google Sketchup. This is probably fairly typical for polycounts.

A very advanced redesign of an Atlas.

Lower half of a Kodiak as drawn for MechWarrior 4.

Mad Cat

When all said and done, I’m hoping that the look and level of detail will be similar to the following:

I spotted a news article that talked about Google’s new take on email, a project called Google Wave. The idea is to extend email and instant messaging in new ways. They say, it’s what email would be if it were invented today. While I can’t say that Battletech Live is nearly as ambitious as Goggle Wave, I do find it interesting that I’m using a few of the same ideas. My plan, first and foremost is for Battletech Live to be the game itself, but also be supported by a communications element. That element is to be a combination email/IM with voice chat/forum/calendar system. While Battletech Live is still in it’s infancy, I’m thinking of ways to take the four communications elements and make them more into a single fluid form.

Parts of Google Wave include features already found in gmail. The upper left is occupied by a navigation panel that includes a number of standard items such as an inbox, trash can and custom folders, with a contact list directly below it. These are both fluid panels, so items can come and go. To the right, is a panel that looks like a gmail inbox with a few differences. Included are pictures of the people who are included in the post. I won’t go into all of the details of Wave, but you can read about it for yourself: http://www.techcrunch.com/2009/05/28/google-wave-drips-with-ambition-can-it-fulfill-googles-grand-web-vision/

Catalyst Game Labs is pleased to attend the inaugural Pax Unplugged! The action begins in just under three days in Philadelphia, running from November 17th to the 19th. We’ll have our usually fantastic BattleTech and Shadowrun games for sale, including … Continue reading →