Results 1 to 10 of 10

  Click here to go to the first staff post in this thread.   Thread: Technical Blog #3

Threaded View

Previous Post Previous Post   Next Post Next Post
  1.   Click here to go to the next staff post in this thread.   #1
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Seattle, WA

    Technical Blog #3

    Saturday, June 30

    It’s been a HOT few weeks here in Austin. It was 108°F here a few days ago. Despite the sweltering, we’ve been pushing steadily forward on the technical work.

    Game Packaging:

    I mentioned in the last blog that we had to abandon the AIR installer and generate native bundles for the game. Of course, these native bundles are just folders full of files, and we can’t exactly distribute a .zip or .dmg file that you are expected to extract to the right place on your hard drive. We now have the game packaging up into installers on Windows using NSIS (Nullsoft Scriptable Install System) and on Mac using Packagemaker. This allows the non programmers (Arnie, Alex, Kpow, Austin, and others) to download and install new versions of the game easily.

    I mentioned pretty substantial AIR bloat in the last blog as well. The Windows installer is currently 34 MB and the Mac installer is 66 MB. Of that, the breakdown of relative content is:

    • Assets: 69%
    • AIR: 25%
    • Game: 6%

    • Assets: 60%
    • AIR: 34%
    • Game: 6%

    This is a very content-heavy game, full of high resolution images. I expect that the final product will have a very large download size. However, it pains me to see such absurd bloat from AIR. The AIR bloat also makes our ‘Lite’ developer version much too large. I’ve already pruned it down a fair bit, and I’m sure I can get some more fat cut out of it as we go forward.

    Build System:

    Jenkins has been working great for us. We have a continuous build that runs every time the mercurial repository changes, and sends out alert emails if the build breaks. We have a nightly build that packages everything up and publishes it to our internal servers.

    We had some minor snags a few weeks ago, and it turned out to be various incompatibilities between Ant, Java, Flex, and Jenkins. In particular, there is a bug in the Flex Ant tasks that causes the Ant JVM to run out of PermGen memory space. I finally got everything stabilized on JDK 1.6.0u32 (32 bit) and Ant 1.8.4.

    We also upgraded our build system and development environments to use AIR 3.3 (rather than AIR 3.1)


    Zeno is coming along quickly. We have integrated the Greensock Transform Manager into the landscape editor for easy manipulation of images. We can adjust the camera viewport preview on the landscape, and set the boundaries of how far you can pan from side to side or up and down. Landscapes are used in most of the outdoor scenes: Combat, Travel, and Town. Once we had the landscape editor up and running, we went back and integrated the undo buffers before going any further. Undo is one of those features that is extremely difficult to add to a tool later.

    The Character Class editor is almost fully functional, and Alex has started implementing the classes. Character Classes define what the range of stats is for a class, what abilities he or she is able to use, and so on. One of the missing pieces in the Character Class editor is the functionality to edit localized strings. Ideally, one would just enter the English names and descriptions right in the editor, and it will write the strings into the English translation file behind the scenes. Since we are all English speakers, the English translation file will be the ‘master’
    translation file, from which the other languages are derived.

    Jeff is now hard at work on the Ability editor, which is the largest piece of the puzzle when designing characters. We sat down on Friday and got Alex and Arnie started with the tools, and were quickly able to start editing how the characters look, how many tiles they take up, their base stats, and so on. It generated a good bit of excitement to suddenly see the tools so flexible and powerful.


    We’ve had several very productive skype sessions with Kpow and Austin, and have started nailing down exactly what we need from the sound system. As a result, we have upgraded the way we load and preload sound data through FMOD.

    One of the peculiarities of our system is that we handle ALL resource loading through our custom resource manager. The resource manager is capable of loading from the web via HTTP, from disk via file I/O, and ultimately from pack files on the disk as well. For that reason, we cannot allow FMOD to do the file loading and management itself. If your game always loads from loose files on disk, you can just allow FMOD to do the file I/O for you and it makes your life a bit easier. Aside from wanting the flexibility of loading from different times of asset sources, I also want to run everything through our resource manager for ease of monitoring what is loading and when. I’m certainly paying a complexity and maintenance cost for that functionality, though.


    We have implemented our animation event system, which allows animations to dispatch events on certain important frames. For instance, the animator can flag a frame of animation as the “HIT” frame. The game listens for that event, and responds by doing something like playing sound effects or rendering a particle.

    At this point, animation events are encoded into a data file, but we are working on a system that allows the animator to label keyframes in Flash, which the asset compiler then scans and compiles into our metadata automatically.
    Youtube link


    Refactoring is a constant activity in any software project, and for the past few weeks I have been focusing on our project structure. We had divided up our as3 code into well over a dozen projects. They are grouped into app (Application), api (Application Programming Interface), and lib (Library) projects. Within this grouping, they are divided into engine (common, not Banner Saga specific) and game (Banner Saga specific). I had ended up with dozens of engine library projects because Flash Builder provides a way to manage and analyze dependencies between projects, but absolutely no way to manage dependencies within projects. Having entangled dependencies is one of the worst things that can happen in software development, and using Flash Builder projects is a way to tightly control them. However, it turns out that this makes things really hard to manage. It also makes updating and maintaining the Ant scripts really time consuming. So, we have ended up collapsing many of the engine and game libraries down to a minimal number, and hoisting more and more abstract interfaces into the api library instead. This seems to be a fair compromise.

    As a side note, I discovered a Flash Builder plugin called SourceMate. It provides many of the refactoring functions that are missing in Flash Builder. It is pretty good so far. Hooray! On the down side, some of its functions are totally broken. For instance ‘Extract Superclass’ tends to generate complete garbage code, and ‘Generate Ant Build script’ doesn’t make anything useful. But overall it has lots of things that DO work well.


    Our usage is slowly growing, and a couple weeks ago our VPS (Virtualized Private Server) web host ran out of memory and rebooted. I manually bumped up the amount of memory available to it. Web server configuration is not one of my strong points, so one day we’re probably going to have to enlist the help of a real IT professional.

    One of our backers has very graciously created a Crest tool that allows other backers to upload their crests, and browse the crests that have been uploaded. It allows the community to vote on crests, and to flag crests that violate the guidelines. That has been stalled for some time waiting on me to figure out how to integrate it with vbulletin authentication on our web site. Fortunately, we have found a vbulletin expert who is willing to donate his time to get this up and running. I hope to share it with you all very soon!


    I finally got a chance to sit down and start hashing out the multiplayer protocol and getting that going. I’ve been swamped with what seems like every other thing for weeks now, and I’m tired of answering the question ‘When will we have multiplayer working in game?’ with, ‘Oh, next week or so’, for about 10 weeks now . It feels great to finally make traction on it. One of my most important jobs is to make sure everyone else can work, and nobody is blocked by tech, so the things that have been keeping me from working on multiplayer are indeed valuable, but I am excited to finally make progress on it. I am writing the multiplayer system as a formalized state machine, and as discussed in previous posts, I am writing it test-first, so hopefully it will go quickly and be nice and stable when I’m done.


    I gave a presentation and talk at Femme Film Texas’ Film Camp for Girls. I showed them lots of shots of the production stages, very similar to what you saw in Arnie’s most recent Art Blog. Additionally, I showed them the production process for storyboarding our cinematics, and shared some inspirational reference material from Eyvind Earle, Sleeping Beauty, and Studio Ghibli. I got a good reception, and since they were all film nerds, I didn’t get the sort of eye-rolling ‘whatever’ response that an adult might expect to get from a room full of teenage girls.

    I had a phone call with RAD Game Tools, and learned about Telemetry, which is a sort of performance monitoring and profiling tool. It looks really cool! I’m not sure how easy it will be to integrate with as3 via ANE, but if it can be made to work, it would be really valuable. On Star Wars we used a great tool called Deja, which served a similar purpose among others. In fact Deja is a fantastic tool, but again very C/C++ centric. It takes a bit of work to get it working well with a managed or scripting language. I hope to have some time to evaluate Telemetry next month.

    I attended a Flash Users Meetup here in Austin, and met Lee Brimelow and Mike Chambers, two VIPs in the Flash game development world. I got some information about upcoming features in Flash and AIR, and hopefully made some useful contacts within the Adobe organization.

    We’ve had lots of discussions with Desura and GOG about publishing. We also finally got setup with a developer account on Steam, after a long long time. Right now we are working on our playable demo to submit to Steam and start getting integrated there. We hope to do that in the next few weeks.


    That’s it for now. We are building up speed, and over the next few weeks we expect to make major progress in the areas of GUIs, Battle Board tools, Ability editing tools, character animations, and multiplayer combat. See you then!

    Previous: Technical Blog #2
    Next: Technical Blog #4
    Last edited by John; 11-04-2013 at 12:45 PM. Reason: Added youtube link for video.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts