We first conceived of this project during winter break before our final semester at Brandeis University. With no experience whatsoever in mobile applications or game development, we dove head first into an Android game. Here are some of the preliminary decisions we made, as well as the reasoning behind them.
1) Platform: There were only two real options for our purposes, iPhone and Android. We chose Android for multiple reasons.
Firstly, Android is written in Java, a language driven repeatedly into our brains at school. iPhone, on the other hand, is written in Objective-C, a language we are much less familiar with. Since we were already undertaking a task with a huge learning curve, we decided the more familiar language would be advantageous.
Second, the Android market is much more accessible than the iPhone market. iPhone apps must undergo a strict screening process before they are allowed onto the market; many are rejected due to seemingly silly reasons (for example, the 512×512 iTunes store icon does not match the 57×57 icon on the phone). Although strict rules may be advantageous for security reasons, I see it also as a hindrance to creativity.
2) Game conception: We are both big fans of tower defense games, and we found that the Android market is somewhat lacking in that category. A 3D game wasn’t yet in the realm of possibility for us, so we decided a top-down, 2D view on a tiled map. To illustrate the way a tower defense game works, I will explain how “level one” could play out.
After starting a level, the screen becomes a tiled map, in which all tiles are click-able. Enemies will spawn from one side of the screen and attempt to follow a set path to the other side. This path is the same for all enemies on a level. The player’s goal is to not let the enemies reach the other side. To accomplish this, the player has resources, from which he/she can build towers (towers cannot be built on the path of the enemies). Once placed, the towers automatically attack and damage enemies within a certain radius. There are many different kinds of towers and enemies; some towers have weaknesses and strengths against specific types of enemies.
For each level, the player has a certain amount of health, represented by hearts. If enemies make it all the way to the other side of the screen, the player’s health is decreased. If the health reaches zero, the player loses; if all waves of enemies in a level are destroyed before health reaches zero, the level is complete. The game will contain several levels, and we will leave it open-ended so that we can add more levels as we see fit.
3) Game framework: When we first began working, we were learning only how to use the Android API. My first project was a simple menu system, then I went as far as making a Sudoku app from a tutorial. The more we worked, the more we realized that the packages supplied by the Android API were not enough to make the type of game we wanted. We learned that we would need to use OpenGL, which is a huge API that is now the standard for both 2D and 3D games. As we searched our possibilities, we came across a game development framework based on OpenGL called libgdx.
libgdx has been very helpful in our development process. It allows us to develop our application first as a desktop application; then, with the addition of a few more lines, it will work on an Android device. This flexibility between desktop and Android is useful, mainly because the Android Emulator is extremely slow compared to a desktop application. Also, in addition to an extensive graphics library based on OpenGL, libgdx contains support for audio, file I/O, Input, math, and physics. As an added bonus, they have an active community on their forum, and any questions we had were answered promptly.
So now that we’ve established the platform, premise, and framework for our game, we can start to get into some of the nitty-gritty details about our project. See the next post.