Technical tags

Apps and Source code

AdventRush

it is a bullets curtain survival game on Android. The first game using the proposed game engine. You can download the game by searching "AdventRush apk" on Google. I provide a possible link here that you may get the installation file, which was found by Google.

Kapow

Kapow, a social networking game on Android implemented by the game engine. You can download the game by searching "Kapow apk" on Google. I provide a possible link here that you may get the installation file, which was found by Google.

Source code of Hummingbird Game Engine on GitHub

Hummingbird is a game engine designed for game developers of Android platform.

• Check out the source code of Hummingbird.
• Check out the source code of performance testing comparison.

Introduction

Hummingbird is a lightweight and fast game engine to support programmers to develop games on Android platform. We were thinking about developing games on mobile platforms at the very early stage when modern smartphones just becoming pervasive. At that time, the Android system was in its premature version 2.x, that was running not very stable, even on the flagship phones. For example, it restarted in silence by itself sometimes at night without been noticed by users. Besides, we never trust alarm clocks that were settled on the phone, because background programs like these may unpredictably crash in random to mess up your schedules. Once in a while, Motorola Milestone was a flagship phone in Android market. Yes, it's equipped hardware was already out of date today, however, in those days, it was a high-end platform. One of the most appreciated feature was the full real keyboard on the phone, which made it an ideal device for prototype programs running, debugging, and testing. Our game engine was developed and tested on that platform.

Worked with a group of talents, who were interested in developing games, I was a graduate student at the campus. We had taken a couple of game designing competitions and earned a few prizes. Most of these games were developed and ran on desktop PC. By investigating games markets, we believe the mobile games have extraordinary potential. Then we had an idea of developing games on smartphones such as Android. Though mobile platforms was a very new thing for game developers like us, we were confident that portable devices would become very popular in future. Everybody would have more than one portable devices, including phones and tablets. Then we needed to decide a particular system for the development. At that time, the markets were shared by 3 big mobile operating systems: Android, iOS, and Symbian. As we were students, Android platform was more friendly to us, because it is more open and inexpensive than others.

Game Engine Development

Because Android OS was a new thing when we began the programming, there were not many practical game engines to support our development. As our first mobile game, we wanted to design a simple one, that did not have many technical risks. The genre of bullet curtain game caught our eyes. Most of these games were shown with fancy 2D graphics, running on desktop PC and Console devices. To the best of our study, there was no this type of games released on mobile devices that were competitive to those non-mobile devices. Existing similar games on mobile devices were too simple, with ugly graphics and lagging interactions. Then we had a motivation to design a real game, giving the same amazing experience as you were playing on traditional devices. To make it happened, we did everything from the fundamental one, the game engine. This engine should support all features we supposed to have in the game. Based on our requirements, these features are essentials for a 2D game engine:

1. Fast sprites drawing. The bullet curtain game would have a large number of bullets running on a screen. They are changing textures, sizes, locations, velocities, accelerations, and rotating all the time. Rendering sprites in an efficient way is necessary.
2. A comprehensive particle system. To make an illusive game, awesome particles are crucial effects to attract users. To design excellent particle effects, a mature WYSIWYG particle system editor is the most powerful tool for developers.
3. Game assets packaging. We want to organize all artistic data into one package file, to make it not to be so easy acquired by curious users.
4. Sounds and music for an immersive experience. In the game, all objects that are running on the screen have their unique sound. Moreover, we have sounds for blasting, hitting, collisions. On resource restricted mobile devices, we need some tricks to mix these sounds.
5. Scripts to describe resources, making data loading more convenient. We use script files to describe resources. This is particularly useful for the level based games. When we enter a new level, we do not need to hard code loading new resources, such as images, particles. Instead, we load a script file for the level. The game engine will handle all resources specified in the script file.
6. Supporting multi-touches, and scalable to external Bluetooth game controllers.
7. Providing a framework that is easy to understand. Designed to follow Object-Orient philosophy. Developers inherit a basic class to get all functions of the game engine.

To design an algorithm for fast sprites drawing, we studied some existing 2D game engines. OpenGL ES as a hardware acceleration technology is applied to improve the drawing efficiency. Some DirectX and OpenGL based renders use batch drawing method to eliminate the overhead of states changing. We used the same idea in our implementation. Some methods of designing the render were referred from a DirectX based Haaf's Game Engine (HGE). To evaluate the performance of our proposed game engine, we compared it with 2 well-known rendering methods on Google Nexus 7 tablet. One method is the Android Canvas, the basic drawing for Android GUI. Another one is Cocos2d-x, an open source game engine.

The performance is evaluated by the number of sprites, and the frames per rate (FPS). Usually, we appreciate a game for its smooth showing when the FPS is 60. In addition, we feel acceptable if the game is running at FPS as 30. If the game is running at FPS lower than 15, we can feel obvious lagging and skipping. Particles, characters, bullets, backgrounds, and texts are all drawn as sprites on the screen. It is important for a game to run smoothly at a high level of FPS with a large number of sprites. It means that we can use more sprites to present a shocking game. In the experiment, we use the 3 methods to draw sprites with 10 different textures. The size of each sprite is 32x32 pixels. We vary the number of sprites drawing on the screen from 0 to 5000, with increased step of 100. The experiment result is shown as follows. With the number of sprites increasing on the screen, all 3 methods show trends of decreasing FPS, due to the computational restriction on the mobile device. Overall, our method outperforms the other 2 methods when the number of sprites is substantially increased.

1. Cocos2d-x and Android Canvas methods show the deterioration significantly faster than our method.
2. In Cocos2d-x, when the number of sprites exceeds 700, we can notice a dramatic drop in its performance. It means that Cocos2d-x has some time-consuming codes regarding sprites management. The bottleneck in these codes causes the inefficiency when the number of sprites is large.
3. In Android Canvas, the performance is even worse than Cocos2d-x. The performance is notably impaired when the number of sprites is greater than 200. It shows that Android Canvas is not appropriate for developing the game with a considerable number of sprites.
4. The hummingbird game engine shows the minimal impact from the increased number of sprites. The performance is efficient, durable, and stable, even we reach 2500 sprites drawn at each frame. In a typical bullet curtain game, it occasionally has sprites more than this value, including particles.

The following video gives you a more intuitive result of the experiment. We presented the video records of the 3 methods on the same screen. From left to right, Hummingbird, Cocos2d-x, and Android Canvas were listed. For each method, the metric of efficiency in terms of FPS located at the top right corner gave you a quantitative measurement of real-time performance.

We avoid reinvented wheels for many features listed above. Our engine can read particle system file created by HGE particle system editor. You can design particle effects using the existing editor on desktop PC. Then you export the file to our game engine. The game engine reads the particle file and gives you the identical effect on mobile platform.

The resource package tool was implemented by C#. The tool can help to aggregate all your assets into one file. Then the game engine read the files to load your assets into memory, such as textures, resource scripts, and particle scripts. For details of the Hummingbird game engine, please visit the GitHub page of the project to get more information.

Challenges in developing AdventRush

In developing the game, my work was mainly in designing the game engine. To draw as many sprites as possible was the most challenging task. Besides the game engine, I gave some contributions in writing a few parts of business logic of the game. If you finish all levels of the game, there is a secret storyboard will be presented at the end the game. The storyboard gives an experience like you read a paper-based comic book. Each page of the storyboard is composed by a few irregular slides. These slides are shown in an order. Finally, they compose a rectangle page. Then this page vanishes and the slices of the next page are shown one by one as predefined. I created a resource script to describe each slide. The game engine interprets the resource script, then loads images and creates textures as specified by the script. Then we present the slides based on a timeline. You can preview the storyboard at the end of the game in the following video begins at 4:10.

Challenges in developing Kapow

Kapow is a very interesting game that is used to trick your friends. At the beginning, a user chooses a character from his/her contacts as a target to be tricked. During the game, the user fights the target, to make it flying as far as possible. during the flying, the target can collect some random items floating around it. If the user applies these items at the perfect chances, they can cause the target to fly faster and higher. When the target drops on the ground and loses bounce to return the sky, the game is over. Then the user has an option to send a multimedia message with a snapshot of the game screen with the flighted distance to surprise the target.

I did not participate a lot in the development of this product. However, I joined some of discussions about background optimization. This game has several backgrounds, which are scrolling at different speeds to simulate landscapes at different layers. Beyond as consultation, I helped in analyzing protocol of Multimedia Messaging Service (MMS). The standard multimedia messaging protocol was not designed as an API on Android platform, we needed to implement the feature by ourselves for the function of sending an image by MMS. I captured the traffics between mobile devices and base stations for entire procedure of sending a typical multimedia message with an image attached to a contact. Then I analyzed the communication based on the captured packets. Then the detailed protocol format of sending an image was figured out. After that, we can easily replay the whole communication by using our own image, to accomplish the multimedia message sending. Using this feature, users can trick friends, then show off the result of how far the friends have flighted in the air. When their friends find this, we suppose they have high probability to install the game and fight back. You can think it is a kind of marketing strategy to make the game being known by more people.

Conclusion