Battletech Live

Online, Turn-Based Battletech – Development Logs

Building maps with Battletech Live.

I’ve started designing a map editor for Battletech Live.  Over the last several days, I have been building a large map based on an image taken from Google Maps.  Several days to produce one map is much too long.  The map editor will have buttons similar to Photoshop, able to open and close menus through a click.  So far, I’ve got one button for tile selection, one for landscaping, one for roads and one for buildings.  I’ll have a pair of buttons for changing elevations, so when plus is selected, clicking on a hex will raise it’s elevation, etc. I’ll have presets for map size as well as plus and minus buttons for tweaking X and Y values.  I’ll have logic in place so that you can’t put water on top of a hill and when a water hex is raised to the same surface as surrounding terrain, the hex type changes to match.  I also want a toggle so that users can easily identify unreachable hexes.

Below is the map, set up in Photoshop to determine elevation and hex type.  The lines are to be roads.  Needing to color each hex by hand is a major pain.  No more.


September 18, 2009 Posted by | Project Development | Leave a comment

BattleMech Selection page

Today, I began capturing wireframe models from Lightwave for use in Battletech Live.  When selecting a unit for the singleplayer demo, the player will move through the available chassis’, as seen below:

Picture 5

Picture 6

September 9, 2009 Posted by | Project Development | Leave a comment

Texturing trees, rocks and BattleMechs.

More texturing work is done today, getting trees and rocks in place, as well as placing the first BattleMech.  From my previous tests, I remember that something was causing textures to shred in all but one axis.  It’s doing that again, so I’ll have to figure out alignment, but for now, things are going well.  I need to build controls for camera pitch and rotation, then get surface contours done.  The second picture shows how close you can get to units, but I want to get closer still.

Picture 2

Picture 4

September 7, 2009 Posted by | Model Rendering Tests, Project Development | Leave a comment

Singleplayer Gameplay Demo

Production of the gameplay demo is underway.  The concept is that the user is given an introduction page where they select a unit type, where it will display a basic record sheet, detailing the armor rating, available weapons and an illustration of the unit.  When the player begins, they’ll be directed to either select a hex along the starting edge of the map, or perform a combat drop which will use the entire map to select a random hex and hex facing for the starting point.  From there, the player will go through the movement phase.  The reaction phase will take place, where both the player and a fixed opponent have the opportunity to turn to torso-twist a single hex side to face the opponent.  (The single enemy on the field will be a randomly-selected unit, but will remain stationary except for torso-twisting.)  As the game proceeds, both units can fire and be fired upon, taking damage as normal.  Since the target is computer controlled and doesn’t move, Initiative doesn’t really matter, but the rolls will take place as a proof of concept.  Rounds will continue until the player destroys the target or the player is destroyed by the target.  I’ll be working on landscape features tomorrow, textures for trees and rocks so that the map can be made to look as much like the paper sheet as possible.

Picture 5

September 6, 2009 Posted by | Model Rendering Tests, Project Development | Leave a comment

Construction of a self-regulating helpdesk system.

Yesterday, I began working on a better helpdesk panel for Battletech Live.  I wanted more than just a form for users to fill out, and to eliminate the need to send email responses to users.  Looking at and others as a guide, I wanted users to be able to ask questions and have the panel auto-update as a mini forum.  Other users, not just moderators, should be able to help answer questions and leave comments on threads, while only moderators should be able to flag official answers and make edits to posts.  I also wanted a number of filters, such as the top 10, top 100, most active, most viewed, unanswered, as well as custom keywords and sort by category.  The first screenshot is my first draft.

Picture 3

While it all works, it’s a bit cluttered.  The first two buttons take up too much space.  I looked at them and thought that they could easily become elements within a combo box, and the section to the right, to be used for word filters, looked much too empty.  Within the grid, the three columns are aligned to the right since they contain numbers, but the headings look really off.  Finally, it seemed to take up too much space.

So, I decided to make it wide and short.  The word filters are moved to the left edge, the buttons have been consolidated, and more options added to the combo boxes.  The grid was made a little wider, and a few pixels padding added to the numbered columns.  The thread was then narrowed and moved up and to the right, with statistics moved to the bottom.

I’m now working on enabling replies and comments, as well as various administrative and record-keeping tasks.

Picture 2

August 28, 2009 Posted by | Project Development | Leave a comment

Deleting elements from an XML-driven tree control

I’ve been struggling with a number of concepts this weekend, mainly how to add and remove objects from a tree component that uses XML as a source.  There are a number of blogs available that talk about XML, XMLLists, how AS3 uses E4X, which is good, but most don’t go into enough detail to be truly useful.  Within XML structures, you can have siblings, which are other nodes, descendants, and attributes.  As a brief example, consider the following block:

<xml label="friends">
     <element kind="user" label="Aleksizz" icon="boy0" gender="M" age="new"/>
     <element kind="user" label="Le Singe" icon="boy0" gender="M" age="old"/>
     <element kind="group" label="Oklahoma">
          <element kind="user" label="berzerker" icon="boy12" gender="M" age="old"/>
          <element kind="user" label="Granpa_jo" icon="boy28" gender="M" age="old"/>
          <element kind="user" label="zardozbtech" icon="boy4" gender="M" age="old"/>

The text block corresponds to the following tree.  In the lower-right is a trash can.  The idea is that the items within the tree structure can be moved around and if any of them need to be deleted, they can be dragged to trash.  When this happens, the item gets removed from the tree and placed in the trash, reflected by the change in the icon.  If the user wants to review what’s placed in the trash, they can click on the can and  a small panel will display those items.  Everything, up to this point, sucked.  The struggle was not to remove an item from the tree or from the XML, but in finding which item to remove.  If I do a trace on folderTree.length before anything is placed into the tree, I find that it already contains 3 items, which I couldn’t figure out how to reference.  After the friends list was built, the tree shows six viewable rows, but if I trace folderTree.length again, the result is 17.  wtf?  Looking at the XML above, there nine rows, so that doesn’t add up either.  In the end, the code that got it to work is as follows:

delete friendSource..element.(@label == String(trashGrid[trashGrid.length-1][‘label’]))[0];

In the XML listing, every displayed item begins with “element”.  In the string x.y.z, y is a child of x and z is a child of y.  But, an attribute is part of a node, not a descendant, so you might say x.y.@z.  Make no sense so far?  This might help.  The double dots after friendSource, tells the system to search for all “element” nodes within friendSource, regardless of relationship.  Inside the parenthesis, it says that if the label attribute of the found element is equal to the label value of the last item to be placed into the trash can, then we have a match.  And finally, at the very end we have [0].  I still don’t know quite what that part does, but I know that without it, it doesn’t get deleted.  [0] typically represents the first element of a sequence or an array.

The next task to be completed is dragging items from the trash back out into the tree.  That bit is typically something like this:

friendSource = friendSource.prependChild(friendRecord);

prependChild tells it to place the new record at the beginning of everything else.  appendChild would place it at the end.  There are also commands to tell it to place the record before or after a particular node.  I should have that done tomorrow and started on the buttons for adding and removing groups.

Picture 1Picture 2Picture 3

August 9, 2009 Posted by | Project Development | Leave a comment

User avatars for friends lists

The most recent task in the site development has been to create a means by which a user can add others to their friends list.  These users will appear in the friends portion of the messenger panel and as an icon attached to inbound and outbound email.  Users should be able to perform the following actions:

  • Create user groups
  • Remove user groups
  • Add friends
  • remove friends
  • set custom icons

Since each user has their own friends list, the information is stored in a field of the users table on the database and this is one of the elements that gets retrieved when a user signs in.  Using Actionscript, the field data is parsed and stored in two places.  Once as an XML list to display in a tree control and second, in an array collection.  This array collection keeps lines corresponding to the number of rows of the tree controller and keeps track of whether it’s a user or a group.  If grabs the group name and in case of users, the id, username and gender.

When a row of the tree controller is clicked, logic dictates which buttons should be available and when the change icon button is changed, a series of avatars are made available based on the gender of the selected user.

When the Add to Friends button is clicked, it will be set up so that the chosen user is automatically added to the friends list as uncategorized.  The user can then drag-and-drop the user into the desired group, or leave them as-is and click Done.

Picture 1

August 5, 2009 Posted by | Project Development | Leave a comment

Temporary Downtime

Picture-1I will be in Oklahoma for about a week and during that time, won’t have much opportunity to work on anything new, so I’m taking this time to clean up a couple items.  I worked out a method that allows the webpage to detect installed AIR applications and if found, launch them.  So, the tools panel that sits over top of Battletech Live is being adapted to Adobe AIR.  Doing so causes some communication problems as most existing modules communicate back and forth using LocalConnection.  With it being in a separate application, it’s moved to a different security domain and they don’t play nice.  So, I’m adjusting the scripting to detect who the parent is and behave accordingly.  An example of what I have so far appears below.  The nice thing about it is that many of the user preferences, and authentication credentials can be stored within the AIR application.  So, the website detects the app, launches it, authenticates for you and imports user preferences.  Additionally, I’m working on some formulas to increase member ranks from 5 levels up to 20.

July 22, 2009 Posted by | Project Development | Leave a comment

Battletech Live turns one year old.

It’s hard to believe that Battletech Live has actually been around for a year.  It has changed a lot in that time, with many components closer to completion, while some still remain in the planning stage.  Here are some pictures of what Battletech Live looked like in the beginning:




July 18, 2009 Posted by | General, Project Development | Leave a comment

Gaining ground on the Battletech Live Forums

I’ve been working on the Battletech Live forums every day this week, hoping to bring them back online by the end of this weekend or early next week.  I’m thinking about how an individual thread should be displayed.  In an email system, messages are traditionally sent back and forth and in the scheme of things, the end result is a somewhat disjointed conversation.  In a forum, each message is displayed above or below the others, depending on how it’s set up to display them.  To me, a top down design seems to make the most sense.

I’ve seen some forum systems that ist one post after the other, with little organization except to split it into multiple pages if the thread gets too long.  On other forums, I’ve seen systems used that allow for the viewing of only one message at a time, with a text-based tree view below it to illustrate the connections between messages.

threadUsing the illustration to the left, I think I’m going to combine list and tree views.  The first message in a thread will appear in a container which provides a heading and a body.  The heading will detail the author, title and timestamp.  When a reply is posted, it will appear directly below it, vertically aligned.  If everything continues in that manner, the next response applied to the last element in line, the thread will appear as a column.  However, looking at the fourth message to the left, if a user replies to some posting further up the thread, that response is indented below the element to which they are replying to.  Any response to that message would then appear aligned below it.

Each post within the thread can be expanded and collapsed but will default to expanded and I’ll probably again impose a limit on 20 posts per page to limit scrolling.

July 9, 2009 Posted by | Project Development | Leave a comment