Results 1 to 20 of 22

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

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
    Location
    Seattle, WA
    Posts
    413

    Technical Blog #2

    Friday, June 8 2012

    The past two weeks have been characterized by four main activities:

    1. Game Scene Editor Development
    2. Sound Integration
    3. Platform Specific Game Packaging
    4. Build System


    I’ll go over each in order.

    The Game Scene Editor (Zeno) is coming along quickly. The first order of business is getting our Landscapes editable in the tool. Right now they are represented by layers of sprites which pan across the screen at various rates. A Landscape can be bundled with a Battle Scene or a Caravan Path across which the Caravan travels. This data is all currently represented by JSON files, which I carefully and lovingly created by hand. The JSON parser requires that the data be in a very very specific format. A single misplaced or missing quotation mark or comma can cause the whole thing to fail, with no useful error messages. For some reason Alex and Arnie don’t want to edit them by hand. Anyway, our tool lets you add, remove, and modify sprites and layers visually.

    Click to Zoom In



    Sound has been progressing well. We are loading sounds and music through FMOD. We are currently triggering sounds on GUI interactions and combat abilities. Music is playing in the battle scene. We have some works in progress samples from Austin Wintory, so we are using those... VERY inspiring to hear it playing in-game.

    We still have a long way to go in setting up how the music actually works. We intend to have various things in battle change the music dynamically. For instance, when an ally dies, the music might transition into a more sombre mood, or play an ominous ‘sting’. We will be working close with with Austin to make it work the way he wants.

    Also, we recently provided a draft sound list to Kpow, and will very soon be starting the sound engineering work on their end. As they need to hook up different samples and loops, we will be expanding our sound system to accommodate them.

    One of the powerful parts of the AIR technology platform is the Air Native Extensions (ANE). However, it is a new technology and full of pitfalls and difficulties. Because our ANE depends on several FMOD dynamic libraries (DLLs on Windows, dylibs on Mac OS X), we have spent an inordinate amount of time making them work seamlessly in all situations.

    There are essentially 3 deployment options with ANE:

    1. Debugging in Flash Builder. This process creates your as3 bytecode, collects your ANE and DLL/dylibs, and invokes the AIR runtime with ADL, the Air Debug Launcher. The downside is that the damn thing can’t find our 3rd party (FMOD) DLLs/dylibs. This only affects programmers, and we finally came to a satisfactory workaround by running FlashBuilder with a particular set of environment variables on Windows. On Mac OS X the workaround is still TBD. The other downside is that FlashBuilder incorrectly stores absolute paths to the ANE in its project settings. This means that every programmer has to do a little prep-work before running after syncing down the latest code changes. And we all know how programmers prefer that everything just work automatically.

    2. Deploying a Native installer executable. The Native executable requires that AIR be installed on your system, and helpfully installs it for you if it is not. This makes the download sizes smaller and is generally pretty convenient. In addition to being a stripped down executable, this build was configured to NOT include the game assets. The game assets are loaded from the web dynamically. This is how we have been deploying our builds internally, although we never intended to deploy them externally in this fashion. Internally, you typically tweak your configuration to look on your hard drive for your work-in-progress assets so you can do things like replace images and see them in-game without pushing your changes. However, similar to the ADL issues above, when you run the installed program it can’t find your 3rd party DLLs and dylibs. Because you have little to no control about how it packages your installer, you can’t really apply too many workarounds. We had to abandon this method of deployment.

    3. Deploying a Bundled native executable with Captive AIR Runtime. This is how the end user will receive our game in the end. It contains all the AIR framework code that makes everything function. The downside is that the deployed files are about 20MB (or more) larger right now. In fact, on Mac OS X the deployed size is about 80MB more. This is because of massive bloat in the Captive AIR Runtime. The upside is that it creates the bundled application laid out on disk in a way that allows you to perform surgery on it before packaging it up into an installer. So our build script can go in and strip away lots of unnecessary fat. It’s still too big, though. I really hope Adobe makes some improvements to this before we launch. Adobe is scheduled to release the next version of AIR this summer, so we shall see.

      In addition to trimming the fat, the build system can also make some changes to the way the bundle is structured to ensure that the game can find all of its required dynamic libraries. On Mac OS X the primary strategy for this is to create a front-end game executable launcher that sets the correct working directory prior to invoking the real game. On Windows the primary strategy is to just copy the DLLs into the same folder as the executable.

      Overall, ANE is a piece of technology that we absolutely require to make this game. ANE allows us to integrate 3rd party libraries, integrate with platform specific features (Steam, GameCenter, etc...), and to simply write performance critical code in C++. Despite that, over the last 2 weeks I have experienced extreme frustration with getting it to work in practice.

    4. Because we had to abandon our internally used Native executable, I created a ‘Lite’ version of #3, the Bundled Captive AIR Runtime. This is essentially the same, but does not include the game assets.

    The Build System is finally in a pretty final and usable state. It took a long time, but it was well worth it. We have some very good volunteers setting up a Jenkins server on an EC2 instance running Windows Server 2008. The Jenkins server serves two purposes:

    1. To Continually Integrate changes from all the developers, build them, test them, and ensure that everything still functions. If something breaks, we get emails about it within about 20 minutes of the break occurring. It watches Mercurial for changes to code or assets, and then starts a build. Preventing code and assets from rotting is a hugely important function of software development.

    2. To create final builds and publish them to our internal servers. The published builds can then be downloaded and installed by everyone working on the game. This would be the guys at Kpow, our new GUI contractor in San Francisco, external QA, Austin Wintory in LA, and Alex and Arnie internally. The published builds include a full build, the Lite build, Zeno the game editor, and the asset compiler.


    Since we are building and publishing executables for both PC and Mac, we have to do the builds on two different machines. The Jenkins machine running in the cloud starts the build. When it finishes building all the Windows and platform-independent stuff, it sends a command to my iMac in Austin TX via ssh. My iMac creates the Mac OS X specific stuff, and uploads it to our publish server if necessary. The process of getting this ssh invocation working was incredibly difficult. We exposed yet another bug in ADT, the Air Deployment Tool when trying to use it through ssh. I just got this issue resolved today, and it is a great relief to have that out of the way. You can follow the saga on the adobe forum here.

    Long story short, we have gotten quite a bit of infrastructure taken care of, and I am looking forward to resuming some forward traction on the game itself ASAP. We have a meeting on Monday with some of the Waking Mars folks to check out their game landscape editor. We expect to take some inspiration from that. If you haven’t played Waking Mars yet, do yourself a favor and check it out on your iPad, if you have one. We are going to get going integrating Steam and Desura very soon as well. The other big thing coming up is lots of GUI implementation work. We have a very talented GUI developer out in San Francisco, and we will have to work hard on our end to keep him supported and fed with the tech support he needs.

    Previous: Technical Blog #1
    Next: Technical Blog #3
    Last edited by John; 07-05-2012 at 05:12 PM.

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
  •