Disclaimer

Introduction

This is a simple game that can be played in the simulator as well as on the device. Can you beat my x86 simulator best time of 19 secs?

You need to touch the area near the bottom of the space-craft to make it rise. Once air-borne, touch to the left of the space-craft to make it go to the right. Experiment with the control till you get the knack of it. Beat my time!!!

For those experienced in Android NDK development, the brief detail about my dev setup and procedure should be sufficient to get the code built.

For those new to Android NDK development, you will need to do go through some basic Android NDK tutorialson the net and on CodeProject.

I eagerly look forward to any questions or suggestions you may have with regards to this code base and even its dev setup (as it is a tricky thing in Android NDK development).

Inspiration and Motivation

I have based my work off the Apache 2.0 licensed 'gameplay' engine for BB10 by RIM.

While the game itself appears simple, it covers key concepts like 3D physics using Bullet, importing assets from Maya (or Max), and dynamic light calculations.

Equally important, I would like to draw attention to the poweful engine used to create this game.

A large part of my effort was directed at porting, modifying and enhancing this game-engine for use on the Android x86 platform.

Based on my professional experience, findings, and learnings in cross-platform smartphone game development, I can confidently state that this framework strikes the best balance as a lean yet feature-rich collection of open-source technologies for Android x86 game development.

Important: This code base comprises of only C and C++. It has no Java code. It relies on the Native Activity
feature of Android.

Game Implementation Details

The basic goal of this game is to pilot a space ship through a fixed distance in the shortest time.

The art assets are modeled in Maya. They are kept simple. The roof and floor meshes are repeated to create a long tunnel. A simple texture is used for the tunnel. Dynamic lighting is used to create interest in the scene.

Controls (algo)

1. The player touches the screen near the ship to activate the throttle.

2. The distance between the finger and the center of the ship determines the throtle magniture.

3. The angle between the finger and the horizontal axis of the ship determine the thrust angle.

4. If no input is applied, the ship drops as a result of gravity.

5. For adding interest, the ship does spins, and adjust exhaust glow based on throttle magnitude.

6. The sound pitch too is proprtional to the throttle magnitude.

The 3D models, fonts and sounds for the game are initially exported as FBX, ttf and wav. However, they are encoded to the gpb format via the gameplay-encoder for use in the engine.

Nitty-gritties!!

The biggest challenge in
using the stock engine on platforms other than the BB10 is that all the external
dependencies of the engine are provided as prebuilt libraries. The problem only gets worse for Android x86 as it isn't even a supported platform for the stock engine.

This was the primary roadblock that I faced while working on this game.
I removed the dependencies on the prebuilt libraries and replaced them by the actual sources of the libraries.
The library sources that I have added (and statically linked) to the engine include,

DS5 ARM Debugger Community Edition (the best for Android Native Activity debugging)

Ant (for asset packing only)

Maya 2013

AVD (API 15 with GPU emulation enabled)

Steps to follow

On unzipping the archive, you will get 2 Android NDK projects and an external-deps folder. These are the bare essentials needed for building this game, and they include all the modifications mentioned above.

gameplay, this is the game engine

CasualGame, this is the game

Do check the Application.mk and Android.mk files. The original files are renamed to Application.mk.orig and Android.mk.orig respectively.

From within Eclipse, import both projects as 'Existing Projects into Workspace'
This will preserve all settings necessary to build these projects correctly. Remember to import from within the android sub-folder, else Eclipse won't recognize these projects as Android NDK projects.

First build the gameplay project. This will build the engine as a static lib, libgameplay.a in the gameplay/android/obj/local/x86 folder.

Next, build the CasualGame project. This will build the game as a shared lib, libCasualGame.so

Now we have built the native parts of our code. Next we need to add the game assets to the apk. This is done from the command line via ant.

hehe, I know how you feel. I felt same way coming from strong typed languages background and well used to having power tools available. However, moving to dynamic languages is a paradigm shift, like moving to functional etc.
in LUA, for all its power, all you need is come with your own debug-purpose helping functions, like going through all table member and printing them for you. like inteli-sense and you can ask for it on demand to the interpreter. also using assert all around helped me detect faulty-error situation without the need to go debug line-by-line.

About the engine. I will look into it. Curios what the RIM guys came up with. One thing for sure, I don't see LUA examples, and seems not really LUA centric. Like WHY? use custom material format, I droped ogre3D exactly because of it, use already something put there like XML, even better define it in plain LUA (will look like JSON).

The example that I have ported doesn't use lua. Check out the sameple-racer. I am currently porting it. It's got lua. While the engine isn't lua-centric, the lua support is definitely well integrated into the engine. Just check that example.

I have yet to start loving lua, or any other script language for that matter. Your words have made we think more about lua. So I will explore and see what I find.

I can even live without a debugger if it has to be that. But what do I do about memory handling? What's your take on this.

I feel I really have to understand lua bindings before I accept lua into the family.

As long as it's C/C++, regardless of code complexity, I feel a sense of predictability and control.

I don't speak on behalf of RIM, but using the custom material format is good for a person (like me) who's yet to totally grasp the FBX format etc...

There is an encoder provided in the engine that encodes FBX (or DAE) into engine friendly format. I could easily patch that encoder to read materials from Maya etc...once I know my way around there. For all I know, the functionality may already be in there waiting to be used.

I find this engine bare-bones due to reasons like the custom material format. It seems they have done it deliberately. The .scene format too has a similar story.

in fact, being bare bone is what drove me to MOAI. it is the reason I might devote some time for this engine too. main limitation, for now I'm sure they will catch up, is the lack of 3D in MOAI. but keep in mind there is bare-bone and bare-bone while MOAI is a bare bone it is incredibly well designed. look at the animation system for example.

about LUA: it is right now #1 on my list of programming languages. and I know of plenty and proficient in few. LUA binding is something too look into , definitely.

"memory handling", yes LUA like many other dynamic frameworks,with no exception, is just BAD when put to stress. but as a rule of thumb, if it is CPU or MEM intensive, you task is not for LUA, but C or C++. marrying C/C++ with LUA is so powerful concept. not only for embedded and game-dev but in I rather say in general. Surely LUA had made an impact on embedded, it is famous in game-dev, now it is time to conquer new land.