Indie pig.
Indie Pig Indie games and experiences.

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.

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.


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.


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.


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).


Add your comment