Technical Blog #1

[Kimberly]

"Elastic Beanstalk runs a Tomcat container for you, and you just install your Jersey web apps into that."

It's like reading a decidedly foreign yet vaguely familiar language. Most of the details of this post were lost on me, but I got the gist of it; glad to hear you're making good progress.

About linking making a unified game account, will it be possible to have different user account names from in-game names? While they work fine on the forum, a name full of numbers and multiple instances of the letter X is a tad immersion-breaking.

[judd]

How does one go from Flash to a multi-platform product distributed on Steam? Is Flash just a prototype tool, or are you moving into an intermediate language that is portable before you go big time across all the target platforms?

-J

[John]

How does one go from Flash to a multi-platform product distributed on Steam? Is Flash just a prototype tool, or are you moving into an intermediate language that is portable before you go big time across all the target platforms?

-J

Great questions. The short answer is that Flash and its surrounding technologies are now a multi-platform portable programming environment.

The long answer:

Flash technology has changed quite a bit over the last few years. Also, true to form, Adobe has named the various parts of it in the most confusing and obscure way possible. Let me try to break it down according to my understanding of it.

Flash: An art tool for generating animations and compositions of images (usually animated). The name of the tool is Flash CS6.

ActionScript3 (as3): A programming language similar to JavaScript that compiles down to bytecode. as3 can be written and included in Flash via the Flash CS6 tool. as3 can also be written totally by itself, typically written and debugged in a tool called Flash Builder 4.6. The compiled bytecode runs in the:

Flash Runtime: A virtual machine for executing as3 bytecode and displaying Flash animations and images. The flash runtime is typically part of the Flash Plugin which runs in your web browsers. Apple famously gave Adobe a kick to the nuts by refusing to allow the Flash Plugin to run on iOS.

Flex: The name of the as3 SDK. It's also the name of an as3 widget library. Adobe uses both terms in totally different contexts for maximum confusion.

AIR: A way of compiling as3 bytecode into native platform-specific code. This allows you to create native executables from as3 on Windows, Mac OS, Android, and iOS. This is very new technology. Speaking of intermediate languages, the AIR compiler uses LLVM compilers to generate native code.

Adobe Native Extensions: A way of writing C++ or other native code and linking it with your AIR project. It allows you to call native code from as3. This is even newer technology (fall 2011).

We are using AIR to deploy to Windows, Mac OS, and iOS (and potentially Android). We are using ANE to link with 3rd party libraries like FMOD (for sound) and platform specific stuff like GameCenter friends on iOS, Steam friends, etc. We are using Flash Builder to write, test, and debug our as3 code. We are using Flash CS6 to create our GUIs and to rotoscope all of our awesome hand drawn animation. We aren't using the Flash Plugin because we rely on several AIR-only technologies, including Adobe Native Extensions, as well as some improved AIR-only networking features. We will use ScaleForm to port to PSN, XBLA, Linux, and maybe Vita.

Does this answer your questions?

To answer your next question, why Flash and not Unity? Because our game relies heavily on 2d hand drawn animation, at which Flash particularly excels.

JW

[judd]

Does this answer your questions?

Totally does, thanks for the great info.

-J

[judd]

Great questions. The short answer is that Flash and its surrounding technologies are now a multi-platform portable programming environment...

So when I install this, I am installing AIR, running AS3 bytecode, rendering and coordinating assets generated in the Flash "pipeline"?

Before it would have just been an FLA right? Will you be releasing this to browser based players later - or does a browser based game diminish it's "impact" (or whatever you might want to call it, maybe it's "perception of quality")?

Thanks again for responding, it's a rare opportunity to ask questions like these to guys actually making cool stuff.

-J

[John]

So when I install this, I am installing AIR, running AS3 bytecode, rendering and coordinating assets generated in the Flash "pipeline"?

From the player's point of view, it is no different than any other game on your platform. You run an installer, and ultimately launch the game with "TheBannerSaga.exe" or something (on Windows). On Mac OS, it installs like any other Application. On iOS, it installs as an App from the Store. The AS3 bytecode is a sort of intermediate language that gets compiled down to native code by the AIR compiler.

Before it would have just been an FLA right? Will you be releasing this to browser based players later - or does a browser based game diminish it's "impact" (or whatever you might want to call it, maybe it's "perception of quality")?

FLA is the source file format. That is the format that artists work in. It is equivalent to a PSD when working on images in photoshop. It has layers, settings, and all that stuff.

Flash compiles to a SWF file for consumption by web browser plugins. This is what you typically see online. You can double-click a SWF file and if you have Flash Player installed, it will execute.

I think it would be great to run in a browser, but we are using some AIR features that preclude this. A browser plugin can only run as3 bytecode, not compiled native code. The networking capabilities of Flash in the browser plugin are also limited, and we are going beyond those. If Adobe updates the browser plugin in the future to be more full-featured, or allows AIR apps to run in a browser plugin, we could consider that.

Right now the only option for us to run in the browser is probably via Chrome as a Native Client App. I would love to do that, but first things first.

JW

[Illessa]

Great to see these technical posts, makes for an interesting contrast with Double Fine's higher level equivilants. Pretty expected since you guys are so much further along than DF, but together they definitely satisfy my itch for broad design chat and nitty-gritty toolset details .

Agreed as to the awesomeness of test-driven development. Personally I often feel I don't have time to write tests, but I always come to regret that decision.

It also does my heart good to hear your feelings on Java too. I do a lot of Java development and find myself defending it a lot. Sure it's not the sexiest language, but the maturity, relative strictness, extensive native libraries and wide choice of excellent tools (special shoutout to the aweomse JRebel plugin for saving untold hours of my time), IDEs and so forth make it a great choice for just Getting Stuff Done as a team.

[John]

Agreed as to the awesomeness of test-driven development. Personally I often feel I don't have time to write tests, but I always come to regret that decision.

Yep I have found that test-driven has always SAVED me time in the end. ALWAYS My one problem with TDD is that I find myself getting out of that mode when I am prototyping and don't know exactly what the end result is going to look like, or what the API will be. If I have a chance afterwards, I can re-write the prototype from scratch in TDD fashion and end up with something really tight. Sometimes, however, the prototype becomes the final product...

I've never learned to effectively mix TDD and rapid prototyping.

It also does my heart good to hear your feelings on Java too. I do a lot of Java development and find myself defending it a lot. Sure it's not the sexiest language, but the maturity, relative strictness, extensive native libraries and wide choice of excellent tools (special shoutout to the aweomse JRebel plugin for saving untold hours of my time), IDEs and so forth make it a great choice for just Getting Stuff Done as a team.

Yep it's mature and the tools are wonderful. It runs everywhere. It's flexible. We wrote all our tools on Star Wars in C# and I came to love that also... in fact as a set of language features and syntax I prefer it to Java now, even though it seemed to start life as a shameless Java clone . Java has a much more broad reach for deployment though, and an absurdly rich ecosystem of server libraries and tools. As much as I enjoy C#, writing a server in it would be a little iffy.

[judd]

When you guys talk TDD, are you thinking "pure", as in literally write a test, let it fail, write some code, run the test - lather, rinse, repeat? Or is it more like write some code, write some tests, write some code, write some tests?

If the former, would you mind talking about it a little? I have found it pretty hard to get devs to make that happen and have found it hard to implement in general.

Thanks.

[John]

When you guys talk TDD, are you thinking "pure", as in literally write a test, let it fail, write some code, run the test - lather, rinse, repeat? Or is it more like write some code, write some tests, write some code, write some tests?

If the former, would you mind talking about it a little? I have found it pretty hard to get devs to make that happen and have found it hard to implement in general.

Thanks.

Yes, I am thinking test-first. The test precedes the code because it serves an important purpose. The test is a statement about how you intend for the code to function. The test is the first client of your new code's API. You design how you want the interface to your new code to look, then you write the test that exercises it, step by step. By doing it this way, it encourages (and requires) you to put some up front thought into how you want your new module to behave, and to design its API in the most elegant way possible.

Writing the test first forces your APIs to be testable. If you write the code first, you are more likely to pull in excessive dependencies and not use a sufficient level of abstraction. If your module is testable as a unit, it is necessarily free of external dependencies. Saying that code is testable is equivalent in many ways to saying that code is free of dependency entanglement.

Writing the test first enables you to start with the simplest part of your unit's API (construction, possibly), and then layer on the rest of the functionality. With each layer added, your test guarantees that the previous functionality remains functional. If something breaks, you _already_ have a controlled environment in which to test the failure. Your tests are most likely boiled down to the fewest possible variables required to exercise functionality. Each of your tests pivots with minimal motion around a different conceptual fragment of your code, slicing and dicing its logical elements into fully comprehensible bits with the grace of the scientific method.

Debugging something that breaks in a test is so much easier than something that breaks in the running program. It is so much easier I would quite comfortably apply hyperbole such as 'an order of magnitude easier'. The same thing applies to things that break earlier, as soon as a defect or error occurs. If the defect propagates silently through the program, as is common, only to manifest itself in some part of the code distant in time and space to its origination, then I would multiply the spirit of my previous hyperbole by itself and claim that such a manifestation is 'order(s) of magnitude more difficult'. And possibly data-corrupting.

Having your tests in place mean than when you add or change functionality in the future, your refactorings can be done in confidence, and quickly. If your refactoring breaks existing code, you know immediately. If programming without source control is the real-world equivalent to driving without a seatbelt, refactoring without unit tests is the equivalent to motorcycle racing without a helmet. I don't feel very comfortable when I'm doing it.

One of the best programming books I've read is called Working Effectively with Legacy Code. In it, the author defines Legacy Code as: code without tests. I feel that this is a fantastic characterization. Think about every time you've tried to refactor legacy code. How many of those times were frustrating and difficult? How many times did you have to just throw the whole refactor out and start over? How many times did the result go live only to crash and flail around with unexpected errors?

The very first step to successful refactoring requires that tests be in place. If you have no tests, you must write them yourself. However... writing tests for legacy code can be quite difficult. Code that was written without the guiding constraint of minimal dependencies can actually be impossible to test. The first step to writing tests for legacy code is to break the offending dependencies by refactoring. Wait... but I only just said that refactoring requires that the tests already be in place. UGH. This is why code-first, test-later doesn't work.

In practice, it is not easy to do everything test-first. Code with mostly graphical or auditory output (graphics and sound systems) is tricky. User interfaces can be difficult. Code that you're writing as a sort of rapid-iteration prototype, for which you don't yet know the final form, is difficult. I use test-first wherever I can, and try to expand my use of it into new areas.

Test-first is a skill like any other. It takes time and practice to get good at it. But even a novice can write test-first for a good portion of the code they write. The trickier bits that I mentioned above come over time and with experience. Along the way you stumble into things and change your technique. For instance, one of the mistakes made while writing tests in general is to make your tests super complicated and fragile. A sign of a bad test is a test that constantly breaks and requires maintenance, or a test that requires loading external data. A bad test makes your life difficult, and a good one decreases your difficulty.

It is unsurprising to most people that having a codebase instrumented by unit tests leads to more reliable software. However, my own experience, and that of others that do test-first, is that writing code test-first leads to faster development. The speed and confidence with which the software is put together is improved by testing first. This is surprising or unbelievable to the opponents of testing.

One of my most successful and expansive experiences with test-first was on Star Wars. I had worked on and been largely responsible for the animation system for several years. It had grown from nothing into a massive but functional beast. As is typical for game development, requirements constantly change and evolve, requiring organic growth and ad-hoc refactoring. About 1 year before game launch, it was time to add some major new features and optimizations. Myself and my team re-designed the animation system from the ground up, and then implemented the system step by step, completely test-first. I have never experienced such reliability and speed of development. We ended up with equal parts of animation code and test code, about 50k lines of each. Typing those extra lines of code sped us up, rather than slowed us down. This is surprising to some, but if typing speed is one's limiting factor in producing working software, then that experience is much different than mine.

[lamaz]

That was the most informative thing I have ever read about programming. I'm not a programmer and only posses the most basic knowledge about programming and I understood everything, which was a nice change of pace.

[dezco]

Friday, May 25 2012
FlashBuilder

• An embarrassing lack of refactoring tools
• ‘open declaration’ sometimes just doesn’t work for symbols in another library
• cut-and-paste of code doesn’t carry any metadata of required imports, as it does when editing Java
• ‘Organize Imports’ doesn’t add necessary imports -- must be done one by one. it does remove unused imports, which is nice.
• ‘Organize Imports’ sometimes freaks out and removes all imports. :(
• absurdly slow compiler

My organization also works with Flash and ActionScript, and we started with and were greatly frustrated by Adobe Flash Builder. So much so that we researched alternatives and have settled on JetBrains IntelliJ IDEA. It's not perfect, but it has additional features including code refactoring, import organization, and generally better performance. And it's got a 30-day trial.

I don't work for JetBrains, nor do I have a stake in their product, but I thought I'd post this as we ran into the same issues with Flash Builder.

And I'm with the group in saying that as a software developer, I enjoy reading your technical posts on your tools and code design. Thanks!

[LvsAs]

We will use ScaleForm to port to PSN, XBLA, Linux, and maybe Vita.

About PSVita, PlayStation Mobile can be good for you or you need a full sdk vita game? Your game can be awesome on Vita, OLed 5inch screen, physical contrôleur, cross plateforme...

[Darkenmal]

About PSVita, PlayStation Mobile can be good for you or you need a full sdk vita game? Your game can be awesome on Vita, OLed 5inch screen, physical contrôleur, cross plateforme...

Speaking of the Vita, I think it would be a excellent choice. If you look around, lots of indie devs have had huge success with the Vita. A good example would be Retro City Rampage, where it was the most successful platform.

So if any of the team is reading this, please release it! Many people would play it.

[John]

I love the idea of the game on Vita as well!

[LvsAs]

I hope it will be realized.

I don't know if it can be useful: https://psm.playstation.net/portal/en/index.html # register

This SDK may be too limited ... And make a game with full Vita SDK can be better.

[Aleonymous]

One of my most successful and expansive experiences with test-first was on Star Wars. I had worked on and been largely responsible for the animation system for several years. It had grown from nothing into a massive but functional beast. As is typical for game development, requirements constantly change and evolve, requiring organic growth and ad-hoc refactoring. About 1 year before game launch, it was time to add some major new features and optimizations. Myself and my team re-designed the animation system from the ground up, and then implemented the system step by step, completely test-first. I have never experienced such reliability and speed of development. We ended up with equal parts of animation code and test code, about 50k lines of each. Typing those extra lines of code sped us up, rather than slowed us down. This is surprising to some, but if typing speed is one's limiting factor in producing working software, then that experience is much different than mine.

Aye, applying that test-first technique in the case you described, where the majority of what was outside the "black box" was fixed, would probably work wonderfully well. Things get more complicated with test-first if the architecture itself is not set in stone, e.g. when you're not sure exactly what the new feature is supposed to do.

[John]

Aye, applying that test-first technique in the case you described, where the majority of what was outside the "black box" was fixed, would probably work wonderfully well. Things get more complicated with test-first if the architecture itself is not set in stone, e.g. when you're not sure exactly what the new feature is supposed to do.

In some cases, yes. If sweeping changes in project direction occur, your tests may have to get thrown out. However, for many cases of feature evolution, the tests form the backbone to support your refactoring. Supporting safe refactoring is really one of the most powerful features of having tests in place.

[Aleonymous]

I am not so much into software engineering, but I have laboratory experience in electrical, electronic, microwave and optical equipment where there's this fundamental principle when trying/testing/measuring something new: Every failed attempt is more often related to problems with the testing environment (e.g. the settings of your sources or your measurement instruments) than to the device-under-test. That's why before initiating any big measurement you first set-up and test all the equipment. I guess it's similar with large programming projects: you have to have the backbone set-up and possess a good understanding of the environment (i.e. of "what's outside the black box") before moving on to the details and the constituting parts.

EDIT -- Verify that all your tech-blog posts are daisy-chained together. I think there's no link for 5->6 (only for 5<-6).