Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

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

  1.   Click here to go to the next staff post in this thread.   #1
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658

    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.

  2. #2
    Did you choose the middleware that is being utilized due to prior experience, or did you decide on an individual basis? Also did you consider the interoperability before making these decisions?

  3.   Click here to go to the next staff post in this thread.   #3
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658
    Quote Originally Posted by kettels View Post
    Did you choose the middleware that is being utilized due to prior experience, or did you decide on an individual basis? Also did you consider the interoperability before making these decisions?
    Some of our choices were indeed based on experience. For instance, our sound engineers at Kpow are very familiar with FMOD and it is their tool of choice. I have used it in the past as well, although long enough ago for it to be ancient memory. I feel confident about it because of those experiences, though.

    as3 and Ant build system are pretty standard, and are used at every as3 shop for whom I have worked. Those actually work pretty well together.

    Jenkins was chosen by our build engineers who are volunteering in Dallas. It was chosen because of its support in the community as well as its pedigree with Hudson, which is a heavily used piece of technology. It is well known to interoperate well with Ant, upon which we are relying heavily. We compared Bamboo, Hudson, and Jenkins.

    Amazon EC2 was chosen for our cloud based servers due to its ease of use and setup. We haven't had any problems with it at all so far. As I mentioned in a previous blog, I chose Heroku over raw EC2 for ease of use reasons when deploying our gameserver. But for running Jenkins, EC2 is quite fine.

    Using AIR ANE was a gamble. I have used AIR in the past and have been pleased with it, on PC, Mac, iOS, and Android. This is my first time using ANE, so it is a learning experience. As I mentioned, getting ANE up and going has been a struggle, but we've gotten our system to a nice stable state now. I feel a bit stressed out over burning well over a week on ANE related issues which I did not anticipate, but it feels good to have now gotten over that hump. All I need now is a nice thorough massage and I will be happy with it. It is also my first time developing on Mac OS X, so I've had to come up to speed on that as well. So far so good!

    I've gotta say that after 12 years of developing on PCs it is nice to be back in a nice, polished, mature UNIX environment like Mac OS X. It beats the pants off of developing on PC as far as I'm concerned. I am a bit biased though because I started my career as a Unix and Linux programmer before going to work for Sony as a PC client programmer in 2000. I do miss Visual Studio 2010 which is truly a world class tool. Visual Studio has come a long way in the last decade.

    Does that answer your questions?

  4. #4
    You might have come across them, but I thought I'd mention that there are some decent JSON lint tools out there if you're editing by hand at the moment - http://jsonlint.com/

  5. #5
    Backer Mudfly's Avatar
    Join Date
    May 2012
    Location
    Sweden
    Posts
    236
    Per usual i don’t get… well… most of this. It is however great to hear that the development is coming along fine.
    I must also (again) say how happy I am that you guys take the time to write these reports and answer questions on the forums! You guys rock!

  6.   Click here to go to the next staff post in this thread.   #6
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658
    Quote Originally Posted by talldan View Post
    You might have come across them, but I thought I'd mention that there are some decent JSON lint tools out there if you're editing by hand at the moment - http://jsonlint.com/
    Yep that page is a real life saver when something does wrong. We use the Eclipse JSON Plugin. If I had more free time I would love to try to upgrade that open source plugin to have the level of error reporting that jsonlint has. *Hint* to any programmers reading this

  7. #7
    Backer Troll's Avatar
    Join Date
    Apr 2012
    Location
    France
    Posts
    650
    Very rare to be told how the game is made and shown too. While I may not understand all of it, I find it interesting. Thanks guys.

  8. #8
    An enlightening read ! Thanks for taking the time to write it.

  9. #9
    Thanks, John! One question, however. I didn't notice any mention of Linux builds; is that planned for later, or simply not mentioned?

  10. #10
    My understanding is that Linux is getting ported after the Mac/Windows release so not a current concern.

    That said, is Linux being dropped as a platform for AIR a concern for the port?

  11.   Click here to go to the next staff post in this thread.   #11
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658
    Quote Originally Posted by Cusith View Post
    My understanding is that Linux is getting ported after the Mac/Windows release so not a current concern.

    That said, is Linux being dropped as a platform for AIR a concern for the port?
    @jaggers and @Cusith: Linux builds are going to be accomplished using ScaleForm as a wrapper. We don't plan on tackling that right away. The first order of business is to get the PC and Mac builds released, then iPad. Those 3 platforms are all AIR supported. Linux support on AIR was killed last year, sadly. It sure would make my life easier of it were still being supported as an AIR platform. Using the legacy version of AIR isn't an option, either, because we rely on may of the modern AIR features (like ANE).

  12. #12
    Ah sorry I'd forgotten you mentioning ScaleForm, and pay sufficiently little attention to AIR to have only recently discovered it dropped Linux.

    I have to admit I was only really familiar with ScaleForm as UI middleware so I hope you'll go into using it when the time comes, well assuming there is anything interesting to be said about it.

    Oh and thanks for these posts, and the replies, it cool seeing how things are being put together.

  13. #13
    This was a very interesting read. Thanks you for providing such detail of your setup.
    I find this a bit too complex (too many nuts and bolts), but I understand your choices.

    Regarding JSON, if you're going to have to edit the JSON files manually, I would recommend using XML instead. It's more humanly readable/editable, it can be easily validated with an XML Schema (that can be generated by some tools by providing XML samples and then tinkered with to provide/restrict exactly what you want for each field). This way the editing is less error prone, plus you could make the XML editing easier by using an XML tool that provides content completion from the schema. If you need the JSON format in the end, you can easily convert the XML file to JSON (ant script). The current JSON files could be converted to XML as a starting point.
    I'll admit that I'm a little biased here, since I mostly work with XML files, but manually editing JSON files does not seem reasonable IMHO.

  14. #14
    Backer lamaz's Avatar
    Join Date
    May 2012
    Location
    Finland
    Posts
    105
    In your latest Kickstarter update you mentioned that you would be hosting the multiplayer servers on Amazon cloud for non-Steam users. How will you handle the actual multiplayer game servers, like what operating system/program combos are you running? What database software will you use for player data and have you noticed anything special in TBS that requires extra configurations or special actions? Like integration with your own and the Steam systems, if that is even possible.

  15.   Click here to go to the next staff post in this thread.   #15
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658
    Quote Originally Posted by WarlordSmoke View Post
    This was a very interesting read. Thanks you for providing such detail of your setup.
    I find this a bit too complex (too many nuts and bolts), but I understand your choices.
    I'm always looking for ways to simplify... with which particular complexities are you concerned?

    Quote Originally Posted by WarlordSmoke View Post
    Regarding JSON, if you're going to have to edit the JSON files manually, I would recommend using XML instead. It's more humanly readable/editable, it can be easily validated with an XML Schema (that can be generated by some tools by providing XML samples and then tinkered with to provide/restrict exactly what you want for each field). This way the editing is less error prone, plus you could make the XML editing easier by using an XML tool that provides content completion from the schema. If you need the JSON format in the end, you can easily convert the XML file to JSON (ant script). The current JSON files could be converted to XML as a starting point.
    I'll admit that I'm a little biased here, since I mostly work with XML files, but manually editing JSON files does not seem reasonable IMHO.
    I chose JSON mainly because it works well with as3. The syntax for parsing and creating JSON is clean, and results in easier to read code than XML parsing. Also, all of our client-server communication is via JSON encoded data, so I said, 'What the heck, let's do the content in JSON as well'.

    The downside has been that the editing is not as easy. XML has a lot of really good tools for editing. JSON has few, and they are not even that good. I would say that JSON is much more human readable for small snippets (less than 1 page), but past that, XML starts winning. As our files have gotten very large, e.g. the abilities JSON file, it becomes literally impossible to edit without lots of frustration.

    We are using a schema validator for JSON, called Frigga (Which is an appropriate name given a Viking game). That helps... without a schema validator I don't think I would actually use JSON at all.

    Another problem with JSON is that the JSON encoder in as3 does not result in a stable sorting of properties. That's because the properties are stored on the as3 object in a hash table rather than a alphabetic binary tree. So merging the JSON files can be a pain if one person's runtime happened to serialize the properties in a different order.

    In the end, we won't be editing any of the large JSON files by hand anyway. Jeff is hard at work on all the various tools we need. I've used XML quite a bit in the past, and now quite a bit of JSON, and going forward I would have to agree with you that XML is still better. Fortunately, we were clever enough to keep the data parsing separate from the data structures, so it is pretty easy to swap out to a different format if I get frustrated enough. I could convert the JSON to XML I suppose, and insert a XML->JSON shim prior to parsing but I would get tangled up in the reverse operation. Saving out JSON from the editor, and converting to XML would still run afoul of the mis-sorted properties... unless of course there is an easy way for me to alphabetize the XML objects prior to writing to disk.

  16.   Click here to go to the next staff post in this thread.   #16
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658
    Quote Originally Posted by lamaz View Post
    In your latest Kickstarter update you mentioned that you would be hosting the multiplayer servers on Amazon cloud for non-Steam users. How will you handle the actual multiplayer game servers, like what operating system/program combos are you running? What database software will you use for player data and have you noticed anything special in TBS that requires extra configurations or special actions? Like integration with your own and the Steam systems, if that is even possible.
    The game servers will run entirely under our control. You will have a game account with us. When you log in through Steam, your steam account will become linked to your game account. Similarly for Game Center on iOS.

    Our servers are Java based. They are REST services and run within embedded web servers. All of the communication between client and server is via HTTPS or HTTP. That means the connections are stateless and ephemeral, just like web connections. This allows potentially massive scale if we are super popular

    The servers run on the Linux OS on in the EC2 cloud. We don't manage our EC2 instances directly -- we let Heroku do that for us. Heroku takes our application and provisions as much EC2 resource as well need automatically. I looked at using Elastic Beanstalk, but it required me to run the gameserver inside Tomcat containers, which I really don't want to do. My reasons for disliking that approach is that iteration time (packaging the server, installing it in Tomcat, restarting the apps) is too long. With a totally standalone app I can pop it up and down very quickly while I'm developing it.

    Right now I am using SimpleDB for our database. I chose it because it is incredibly easy to setup and use. I do have concerns with its performance... If it struggles to perform at scale, then we could switch to Dynamo with relatively little pain.

  17. #17
    Backer Aaron's Avatar
    Join Date
    Apr 2012
    Location
    Canada
    Posts
    49
    Speaking of multiplayer servers, will it be possible for people to host their own servers? Are things like LAN being considered?

  18.   Click here to go to the next staff post in this thread.   #18
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658
    Quote Originally Posted by Aaron View Post
    Speaking of multiplayer servers, will it be possible for people to host their own servers? Are things like LAN being considered?
    No, we have no plans for players hosting their own servers. However, we do plan on allowing people to play directly against their friends.

  19. #19
    Moderator stelly's Avatar
    Join Date
    Apr 2012
    Location
    Manchester, UK
    Posts
    98
    Hi John,

    When you say play directly is this on a peer to peer basis, or does the person that started the game become the serve by default? Also how would the saving of the game work?

    Stelly

  20.   This is the last staff post in this thread.   #20
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Location
    Austin, TX
    Posts
    658
    Quote Originally Posted by stelly View Post
    When you say play directly is this on a peer to peer basis, or does the person that started the game become the serve by default? Also how would the saving of the game work?
    It's still client-server, but the server mainly serves the role of a router between the clients, validator of moves, cheat prevention, and state persistence. Saving is done on the server for Factions.

Page 1 of 2 1 2 LastLast

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
  •  
Single Sign On provided by vBSSO