About this blog
Blog detailing the Development Process of the IMPACT 2D Game Engine for the Android OS
Entries in this blog
Since the Android SDK is based on Java,I was leary of whether or not there would be performance issues, With that in mind, I took to the lovely internet to do some research. After scrounging for information on on the ever-evolving blogesphere, and referencing multiple articles via Google Scholar, I eventually realized that my worries were not groundless. There exist multiple accounts of people attempting to make their 2D games using the Android SDK, only to find that their frame-rates were so low that they would hardly perform on the most powerful of devices. This realization lead me to the thought of using the Android NDK (Native Development Kit) to solve the potential performance issues.
Using the NDK also opened up the possibility of using some of the vast number of libraries developed in the C and C++ languages. The following is a list of libraries that I decided to use for the initial release of the engine:
1) SDL - SDL, although not the prettiest library, is highly functional and provides a lot of optimizations that take a lot of the work away from me. This is a good thing. Furthermore, the developers behind SDL were kind enough to provide a port of SDL to the Android OS. This library is the foundation for our engine.
2) SDL_image - The SDL_image library provides quick, optimized loading of various image formats--perfect for a 2D sprites.
3) Box2D - For the physics side of things, we went with Box2D, as it was also ported to android and well received by the andorid community.
4) Freetype 2 -- We plan to use the FT2 library to handle the font rendering when creating our GUI system.
5) TinyXML - Because our asset system will be XML-based (We might decide to go with a filesystem-based approach later, but for now, we are KISS) we needed a simple XML solution and TinyXML provided.
6) Lua and LuaBind - Since our engine will be have a component-based architecture and wanted qucick imnplementation without lengthy re-compiles, we needed to implement some form of scripting. For this, we went with the popular Lua language.
Because getting each of these libraries to compile on the ARM-based architecture is a job in itself, we haven't gotten very far into the actual engine code. We have, however gotten every one of the libraries to compile and are now set up. We have also started working on the asset manager for our engine, as well as the log system. Both of which are about half-way complete.
This journal will serve as a continuous log of problems, solutions, and comments on the development process.