Tuesday 16th, September 2014

Game Tech Stacks

It seems that the most common first question people seem to ask me about my game is, "What are you making it in?"

I get this question more often than "What is your game about?" This could be because most of the people I interact with are creators, so this is likely a very biased observation, but nonetheless, I'm happy to talk about my tech stack and what influenced my decisions!

For those that don't know me. I'm an experienced programmer, but a newbie game developer, so keep that in mind when reacting to my posts.

There are many questions you have to ask when choosing a tech stack. There are a lot of variables, I'll name some of them, and rate each tech stack with a 1-5.

• Portability - How easy is it to adapt your game to target different environments? Mobile, Console, Desktop?
• Compatibility - Given a target environment, how much friction will you get from compatibility issues? E.g. If I target browsers, will I have problems with different OS/Browser combinations?
• Workflow - Tooling. How easy is it to create content for your game? What is the iteration speed? How easy is it to refactor your code?
• Performance - How smooth will the game run? I rate this not just in terms of frame-rate, but also: How steady is the memory usage? Do games tear? Hiccup?
• Footprint - How much overhead will there be to your game? A smaller game has less tolerance to a large footprint.

Adobe Flash

I have a heavy Flash background, so I feel obliged to first talk about the viability of using Adobe Flash for games today.

As everybody should know by now, Flash has been in its decline over the last 4 years or so. Flash has been historically a way to push the limits of what browsers were capable of. HTML 5 has taken over most of these capabilities, leaving games and arguably video left. (Before saying I'm crazy, just see what the default YouTube video player is for IE11.)

A few years ago Adobe tried to refocus the Flash platform into gaming. That's why there was a ton of great additions since 11.0 involving gaming: Starling, Stage3D, Workers.

These were good additions, but the PR damage was too great, and HTML 5 and Unity were grabbing a stronghold and Flash is now in its end of life.

Despite being in its decline, as far as web games go, Flash is still used the most.

• 2/5 Portability - Flash will work as browser or download (AIR) for Mac and PC. No mobile, Linux, or console.
• 5/5 Compatibility - If Flash is supported, there are very few compatibility issues. That means if my game is working in Firefox for PC, I can reasonably expect it to work exactly the same in Opera for Mac. For AIR there are a few more things to be aware of, but the same applies.
• 4/5 Workflow - Coupling the Adobe tools with IntelliJ or Flash Builder for code, Flash has very mature tooling with reasonably fast iteration speed.
• 3/5 Performance - You can make performant games with Flash. However, there are two major problems. The first is vertical tearing. There is no way to make a Flash game with vertical sync. The second problem is that the core ActionScript libraries produce a lot of garbage, so it is nearly impossible to make a Flash game with a game loop without a sawtooth memory pattern. This is what gives most Flash games that slight hiccup every few seconds. Flash does have Adobe Scout, which is one of the best profilers I've ever used, so debugging performance issues is easy, but Flash is not for the performance nut.
• 4/5 Footprint - Flash has around a 90-95% penetration rate for those that play online games. For those that don't, the plugin is around 10MB, which is not exactly small, but the install is easy and compared to a typical game's total size, not that bad.

HTML 5

Browsers have come a long way in the last 5 years. WebGL, CSS3, Canvas. All sorts of good stuff. Talking about HTML 5 games doesn't make a whole lot of sense without talking about the framework used to make the HTML 5 game, but there are a few commonalities I can speak to.

JavaScript. The iteration speed of JavaScript is awesome, but the scalability is poor. JavaScript is not typed, so tooling around refactoring, self-documentation, and error checking is limited. There are several options like Dart, TypeScript, and GWT, but all of these have their drawbacks as well.

• 3/5 Portability - This is improving quickly as there are growing ways to package hybrid apps for mobile, desktop, and console.
• 3/5 Compatibility - Depending on the abstraction libraries you use, HTML 5 compatibility can be a huge pain. Every browser interprets things differently, and chasing down issues with varying OS/Browser/GFX Card combinations is a challenge to say the least.
• 3/5 Workflow - Iteration speed for most HTML 5 setups is awesome, and tooling is very good. See my earlier rant about JavaScript to understand why this isn't a 5/5.
• 2/5 Performance - In my experience, HTML 5 games run at a fraction of the horsepower as Java, Flash, Unity, or C++ games do.
• 5/5 Footprint - This is of course library dependent, but most HTML 5 game frameworks I've seen have a very small (less than 2MB) footprint. Even GWT, which creates a JavaScript version of the JRE is fairly small.

LibGDX

LibGDX is a lightweight 2D/3D Java framework.

LibGDX appeals to me because it's open source, it's very unassuming, and the libraries are well written and produce no garbage. As an Indie developer, writing in Java+LibGDX is easier and faster than C++, but with only a moderate performance penalty to writing native.

• 3/5 Portability - LibGDX supports Desktop, Mobile, Ouya, and Web (with GWT). However, the workflow to web is pretty bad and unpopular.
• 4/5 Compatibility - Compatibility for Web has been problematic, but other than Web and OpenGL issues, moving from one device to the next has been a breeze.
• 4/5 Workflow - Iteration speed is good, and Java + LibGDX is a very smooth way to code. The biggest thing it lacks is a good visual way to edit your levels and data. For 2D animation, Spine works amazingly well for LibGDX, Unity, Flash, or HTML 5.
• 4/5 Performance - LibGDX is extremely lightweight, and will run very smoothly even on the incredibly underpowered Ouya. The libraries are tuned perfectly to produce no garbage, so my memory usage looks nice and flat.
• 4/5 Footprint - Deploying to web, mobile, or Ouya has a very small footprint, to Desktop can be an extra 10-20 megs if you package the JRE, which overall is reasonable.

Unity

Unity popularity has exploded over the last few years. While Flash has been criticized for its proprietary systems, Unity has avoided this black eye by striving for flexibility in its output formats. WebGL, Desktop, Console, even (briefly) a Flash export.

Unity tooling, its store, and its rapidly growing market dominance and newly added 2D support is making it a highly attractive choice for many styles of games.

However, perhaps surprisingly, I have not chosen Unity at least for this game. After the fall of Flash, the openness of LibGDX was more appealing to me, and I personally prefer the workflow of IntelliJ + Java over Unity + C# (or VS).

• 5/5 Portability - I am unaware of a better platform to write once and deploy everywhere.
• 5/5 Compatibility - Unity is a closed ecosystem and from what I can tell a Unity application will behave the same from one device to the next.
• 4/5 Workflow - The Unity editor is awesome for what it is, but from what I understand, it's difficult or impossible to do Unity without the Unity Editor.
• 4/5 Performance - I don't have metrics to back up my observations, but based on the games I've played written in Unity, it feels comparable to Java.
• 5/5 Footprint - Unity doesn't maintain backwards compatibility to the level Flash does, which is good in that the footprint is very light, at the expense that your old games will eventually cease to function.