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.
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:
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.Based on the result, we can get these interesting observations:
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.
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.
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.