Electronic Space Nintendo

Here’s the trajectory of our development so far:

We are making a 2d vertically scrolling shooter. We started with an air 3 game but did primary dev on desktop. The intent was to have a “simple” game running on desktop, then optimize as we went mobile. Basically we philosophise that it is better to go in with the mindset that you will compromise, rather than be constantly disappointed in having to cut back.

First engine was plain displaylist. Performance on Galaxy S2 was nice, but sort of rotten on Galaxy Nexus. Didn’t test that build on Nexus S. At this point I personally was opposed to using Air at all; I’m historically a strong advocate of going native wherever possible. However, we intended to deploy to iOS eventually, and I have to concede that writing three engines, one java, one objc and one for desktop was more time than it was worth. I also concede that writing a single engine in cpp is a total pain in the ass, and not worth MY time. Life’s too short for cpp.

Second engine was post Air 3.2, built on nd2d; I eventually dug into the nd2d source to further simplify shaders and how it works with collections internally. I’m really strongly aligned with nd2d’s structure, and it’s my go-to on desktop, but for mobile I found it almost a little too pragmatic. Mobile needs kickflips to be cool.

At this point our engine was running with a scrolling background, single touch input, and bullets being fired almost every other frame update, with about 50 or so enemies max on screen. This is the extent of our pooled objects, and the intent was to push the engine quite a bit. Collisions were handled with rectangles, points, and spatial hashing. Entities that die are not instantly removed, but stacked, and then removed in a batch at the end of every game update. We don’t create any objects during gameplay, but use object pooling extensively.

Performance on desktop was, as expected, golden. Performance on Galaxy Nexus was around 40fps, which became, for me, the signal that we should limit to 30fps. However on S2 we got 60fps with occasional stutters (gc, though I can’t figure out what there would be to collect other than linked list internals). At this point we had not tested on iOS yet (we are 2 windows devs and 1 osx dev).

One night I decided to port our engine to haxe/nme, for kicks. It was less a port and more of a rewrite to make better use of haxe features such as generics, and it also allowed us to use the excellent polygonal data structures libs. The big difference here is that our nme build doesn’t use hardware acceleration consciously. It’s all plain display list, with sprite sheet animation implemented with scrollrect on sprites.

NME performance on android is spectacular. Rock solid unwavering 60, with 100s of enemies and bullets, collision detection, explosion animations. Just everything I would want from a game like this. I post the APK, and the team sort of collectively agrees NME on android is badass. So we try on iOS.

Oof. NME on iOS nowhere near as smooth. Actually totally unacceptable with the same code base. Adding insult to injury, we build our original nd2d AIR build for iOS, and what do you know; Rock solid performance.

Huh.

So now we’re left strategizing almost where we started: Do we really have to choose a “lead” platform again? The hope with nme was that our lead platform was simply nme, much like we were hoping air would have comparable performance across devices. In a sense we are now choosing between middlewares, which might as well be the same question we asked originally; Should we go native?

It appears, for now, that we will go with two branches; A haxe branch for desktop/android, and an air branch for iOS. Our engine will instead be data driven and thus allow us levels, behaviors etc described in json or other, and we can share that among engines.

Big takeaway for me is that it fucking sucks having to place trust in middleware for performance issues. When air underperforms on an android device, all I am left to do is say ok, that’s what air thinks so I guess that’s our limit. Same with nme on iOS. It’s uniquely frustrating as a developer to have to accept such compromises.

But compromise is what you get when you go multiplat anyway, right? I’ll keep writing about new findings. My hope is that the iOS nme performance is just us fucking up our build somehow. I was real ready to just go all out haxe/nme for multiplat.