This scrolling shooter prototype is now included as a sample in Voxyc. The sample Lua source is here. Endless runner games can be done from this too. About the earlier kitten, pony and bunny idea, what about Star Kitten? A kitten that flies around in a spaceship and doing it's galactic duty destroying all the alien mice. It could be turned into an endless runner or a scrolling shooter easily. Maybe star kitten has has friends like star pony and star bunny and there is a story that follows. Anyway, you can start making your own endless runner or similar with that sample, and easily draw pixelated characters like this in the 2D editor now.

By the way, Google is phasing out 32-bit and I'm about to drop assimp as one of the supported third-parties because I don't have time to re-build it for Android x64, unless someone has a ready binary out there. I'm about to replace it with OBJ Loader, and if that fails, then it's sprites-only now for a while.

Is this the first go with an obj format loader? If yes, great. More power to you.

The problem I have with assimp is it's build time, so adding it as pure source into your project was an annoying move. I eventually didn't even want it around in the main application code. Then years ago, one of the heavy hitters around here expressed having your data on disk in a form that closely (or exactly) matches the layout that you would upload to hardware at run time. Engine side, becomes a single bulk read on import. This does just move the problem though, but in a good way. My rational was, if I'm going to spend the time to write an import parser, why not do it for a format that makes things easier. To me, the easiest was to go all the way back to the DCC and handle it there in an export process. Blender is my modeling tool of choice and I find the scripting to be the most understandable between the three major applications. (3ds I never figured out, maya was a little better) But that's me. 

Here, I've linked a sample export script to hit the ground running with if you so choose.

@GoliathForge, yep, it's the first time and it worked. I just integrated the OBJ_Loader and even though it works, the loading is noticeably slower than assimp, OBJ's have to be pre-triangulated, and it looks like some of the normals don't load anymore (some things don't glow in the light anymore; weird). But I got rid of the assimp requirement and I'm in the clear for the upcoming Google x64-pocalypse ?. Overall, I do recommend OBJ_Loader if you don't need skeletal.

Plus, this makes the build smaller, and I'm also in the clear for releasing on iOS. I've built assimp for iOS before and the binary ends up being hundreds of megabytes (it wouldn't build partially for some reason). Somehow, the resulting .IPA was still only 50 MB. So only 2 possibilities there: 1) Xcode does some magic trickery to partially strip the library (really?! ?) or 2) the library does not go in at all and the whole thing just won't work in production. Regardless, that whole issue is solved now!

Thank you for the Blender export script. That is an excellent idea. I bet that reduces load times by a ton.