Choosing a Technology Stack

Inside look at how not to choose a technology stack

Tim Mensch

3 minute read

Pile of smartphones
Not This Kind of Technology Stack

I always end up spending too long choosing what game engines and technologies I want to use to build my games. So much wasted time. Last time around I couldn’t find a single game engine that looked competently developed: I tried everything that was available at the time, and nothing really worked for me.

Hardly anything even supported Android, which was one of my desired targets, so I didn’t have a lot of choice. It was before Unity3d had Android support, which was important to me, and I was writing a 2d game, which meant that I didn’t want the extra overhead of Unity regardless, so I didn’t even try it. Instead, I wrote my own game engine, and it took me 7-8 months to create a game that should have probably taken no more than 4-5 months.

But that’s in the past, and I’m working on a new game now. My old engine was stale, and would require some work to make current, so I looked around to see what engines were available. I started out by wasting some time trying to use the 2d game engine Moai (which has subsequently died), but found it to be a terrible pile of … marketing. Every single thing I tried was broken or didn’t work quite right. At about the time I was testing Moai I realized that, since I needed to write most of the game as a web client anyway, it would just make sense to write the whole game using web technologies. That also excluded my old game engine: C++ and Lua don’t run as well when the primary game client has to run as a mobile web app.

I’ve tried reading reviews of different game engines. But it seems like they’re all reviewed by a beginner who is either confused by basic things or doesn’t have the context to know what’s important. So I just tried a number of options:

CreateJS looked good at first, but it doesn’t support WebGL. Didn’t realize this at first and wasted a few weeks creating code that I was going to need to change. For various reasons the pile of code I ended up with was a complete loss. Back to square one.

Cocos2d-x has a full JavaScript/HTML5 binding that includes both Canvas and WebGL renderers. I met with the team from Cocos2d-x at GDC a few years back and they told me how great their toolchain was. I unfortunately believed them. A dozen or so patched bugs, frustrations with terrible UI code, and a completely broken game editor later, I abandoned Cocos2d-x. A few more weeks lost.

Phaser.io is a full game engine that has a ton of support. I’m using it now. What I didn’t know, that I wish I’d known earlier, is that Phaser doesn’t have any UI worth using (beyond a button), and Phaser’s renderer is based on a modified PIXI 2.0. PIXI is up to 4.0 now, and it’s blazing fast; most of what I get with Phaser are things that I’m not using (physics, sprite object health, etc. – things that a game with bouncy objects might need, but not so much a digital board game).

But I’ve done enough porting of the game from one engine to another, so I’m sticking with Phaser for now. It’s more important that we finish the game than that the technology stack is perfect, after all.

comments powered by Disqus