You don't say? I seem to remember from my AS2 days that setting _visible to false didn't do anything for performance. Does visible behave differently in AS3?

Well, that was easy: the battlefield now draws all of its individual tiles' BitMapData into a single, giant Bitmap upon loading. The game already ran fast on my netbook notebook, but this seems to have given it a little extra oomph! I'll have to wait till later, when I get home, to see how this affects performance on the netbook.

Well, I learned something today! I'm going to try that little trick right now.

I'm exclusively using Sprites and Bitmaps for objects nested in the battlefield (Sprites for characters and destructible objects, Bitmaps for level tiles). The Battlefield itself extends Movieclip--or it did until just now. (I just changed it to extend Sprite and it works just as well.)

Does that limit apply to sprites as well as movieclips?

No--Flash only redraws regions of the screen where there are changes. (And if memory serves, it actually does this when there are changes offscreen as well.) So if the background is static, it only redraws the things moving on the background; if the background moves, it has to redraw the entire background.

That said, this didn't cause any slowdown on the netbook back when I first implemented it, so I'm not sure why the panning is killing the framerate now.

All right! Another update, this time with regard to game performance. I tested the game out on my netbook, and it ran smooth as silk except for one particular set of circumstances: characters moving combined with camera panning totally bottoms out the framerate. I've temporarily fixed this by having the camera zoom quickly to the destination ahead of the moving character, meaning that the framerate drops for only a quarter of a second or so. For mobile devices, I may just pull an X-Com and have the camera jump immediately to the destination without any smooth movement at all, depending on how this does.

You may also have noticed during Teaser #4 that the game would hang for a second or two when calculating moves for characters that didn't have any enemies in attack range. That's because the long-term planning routines being used were quite inefficient, checking for every possible attack from every possible space on the battlefield to determine the ideal destination.

Well, no more of that! I spent a few days going in and re-coding the long-term planning routines, and performance is way way better.

With that bit of housekeeping out of the way, I think it's time for me to get back to coding the asynchronous multiplayer.

Hey man, it looks like mechlore.com is down. Do you have a website for this somewhere?

Okay, Stonebridge is re-tiled and back in service! I'm not sure that I want to re-tile the other one, Islands--I'm pretty sure that I can design a better 6-player map than that, so I think I'll just let it die a dignified death.

Speaking of dignified: check out these lovely spriggats!

   

I can't wait to see them animated, flapping their wings and all.

YES. I have two new victories to report:

(1) The modular tile-loading scheme is now finished. It's fully integrated into the main game and working beautifully.

(2) I finally tracked down and squashed an obscure bug that was preventing certain characters from firing their full range on small maps, but only in one direction. (Don't ask.)

I also went and rearranged the tiles in the Grass tileset to make them easier to use in the map editor. However, this had the unfortunate side effect of screwing up two of my maps (which use the grasslands tileset). I'm probably going to have to redo those from scratch now. (On the plus side, I have an old build of the game that I can use to take a screenshot of those maps for use as a reference.)

I've been rewriting all the tile-loading code--and, in the process, rewriting the format for level maps. The map editor is now up and running with it; here's a video showing the current state of the map editor, with the improved moddable tileset system firmly in place:

http://www.youtube.com/watch?v=RKPgTK1wCmM

It's hard to go wrong making your game trim and focused.

Yeah, adding that as an option seems sensible.

Unrelated to that: here are two more units in their four-directional glory! Behold, the skiakineticist and the spearman:

Thanks!

I'm not sure about the arrows; I'm going to add in the directional facing graphics, then see if people have any trouble figuring out character facing without the arrows. If so, they're staying in. Useability trumps pretty.

Okay, I've found a different approach that works--I'm not using relativePath() anymore, so the question is moot. Still, if anyone can tell me what went wrong there, I'd still be like to hear the explanation purely out of curiosity.

Nah, it can't be that. If event.currentTarget didn't work, selectedFile would be null and the second trace output would be null as well. Thanks for trying, though.

I've been banging my head against this for a few hours, and haven't gotten much of anywhere. I'm using the getRelativePath() method to suss out the path between a directory and a file tucked away in a subdirectory, but it keeps returning null for some reason.

Here's the relevant code:

Code:

var baseDirectory:File = File.applicationDirectory;

var file:File = baseDirectory.resolvePath( "Maps" ); //add on Maps subdirectory
var fileFilter:FileFilter = new FileFilter( "Battle Maps" , "*.xml" );

file.browseForOpen( "Select a Map to Open:" , [fileFilter] );
file.addEventListener( Event.SELECT , fileSelected );

function fileSelected( event:Event ):void {

var selectedFile:File = File( event.currentTarget );

trace( "baseDirectory is at " + baseDirectory.nativePath );
trace( "selected file at " + selectedFile.nativePath );
trace( "relativePath from baseDirectory to selected file is " + baseDirectory.getRelativePath( selectedFile ) );
}

And here's the trace output I get when I run it and select Level1.xml via the dialog window:

Code:

baseDirectory is at C:\Users\Craig Stern\Dropbox\TT\Data
selected file at C:\Users\Craig Stern\Dropbox\TT\Data\Maps\Level1.xml
relativePath from baseDirectory to selected file is null

According to LiveDocs, it returns null if it's not possible to find a path between the two files. However, those nativePaths are identical except for the Maps\Level1.xml on the end--it should be returning Maps\Level1.xml, right? Any ideas on what I'm missing here? I'd be grateful for any help!

The map editor has been updated to conform to the new, more flexible map detection system: it now supports loading and saving maps with any sort of filename you want.

We have an art update! All of the directional character sprites are now finished to my satisfaction. Here are two I haven't shown yet--the Stone Golem and the Shadowling:

     

I realized yesterday that I have more work to do before I can continue coding multiplayer. In particular, I need to reorganize the way the game looks for external assets (particularly levels and tiles).

So, here's the way it works now: I specify a base filename (tile, say, or level) and then append an ever-increasing integer to the end using a for loop. The game then checks for every filename until it reaches the end of all available files. Thus, every level and every tile  must be named with a series of consecutive integers in order for the game to recognize them (e.g. level1.xml, level2.xml, level3.xml, etc.) If there is ever a gap in the numbering, the game won't detect anything beyond the gap.

This was quick to add and worked well for the early stages of development, but this is going to be hugely problematic going forward if I leave it that way. Suppose the game ships with 8 levels (level1.xml through level8.xml). If a player creates a new level, the game won't detect it unless it's named level9.xml. That means that there are going to be a ton of custom maps all named level9.xml--a player who wants to download and use more than one player-made map is going to have to manually rename all of the files so they have consecutive numbering.

The situation also exists with tilesets, which is even worse. Not only would there be potentially dozens of files for the player to rename, he'd also have to redo any maps that referred to the tiles' original numbering. That's terrible!

After experimenting a bit yesterday, I figured out a method for automatically detecting every single file in a directory regardless of filename. The game is now updated to auto-detect every level in the Maps subdirectory and load them; I need to update the Map Editor to do the same, then figure out a method for separating the game's tilesets and detecting them successfully in a similar fashion.

Thanks, man!