Inside the Lab:Part IV Programming news

Welcome to PART IV of our weekly “Behind the Scenes” series. This time we will discuss about what is going on behind the graphical layout of BioLab and what decisions we made while creating it.

THE PROPER SDK

As we started, we had to decide which Software Development Kit (SDK) to use for making our game. There is a variety out there, each one with its pros and cons.

Our first choice was ADT (Android Development Tools), the native SDK powered by Google especially for Android development. While it is a powerful Library written for Java programming language and CSS, we came up with several issues regarding visual content, text management and cross-device support restrictions, that made us not pleased with the final result. So, we set sail for another solution.

After we searched among the various choices, we reached Corona SDK, which writes in a programming language called Lua. The results after some tests were pleasing to our eye, and the development process seemed fluid and well paced. The features Lua provides, were very much similar to the demands of the BioLab graphical layout, and we found out that the Corona API was rich and enough for our needs. The documentation for the API is well-written and there is an active community for starters like us, to seek help for problems that could show up as the development progresses.

So, it is Corona SDK gentlemen…

LETTERBOX OR STRETCHED?

The next decision we had to make was whether we need our game in a fixed aspect ratio or not. Having in mind that a very popular aspect-ratio among famous Android devices is 16:9, we decided to stick with it.

This is an image with 16:9 aspect ratio:

But there are also famous devices that don’t have a 16:9 display, like Nexus 7 and Nook HD, which are 16:10.

So, this is what a fixed aspect ratio of 16:10 would look on them:

We have appearance of blank black bars, at the top and bottom of our screen.

And to go even further, this is how it would look on a 4:3 Tablet:

Even bigger useless ugly space top and bottom. We were skeptical with it.Not only it looks ugly, but it doesn’t make full use of the whole device screen. So, we decided to not have our game content fixed to a certain aspect ratio, but stretched to fit the whole screen.

The result on a 16:10 display is this:

A minor stretch, still pleasing to the eye, with the whole screen available to the player.

And for 4:3:

As you can see the stretch is even bigger here, but still pleasing to the eye, and without ugly blank and useless space.

So, blank space or a minor stretch? Between the two evils, we chose the later.

TEXTURE MEMORY MANAGEMENT

The most challenging part, is the Texture Memory Management.

Every time we load a graphic, our texture memory fills up. That affects two things: the amount loaded versus the amount available in the device, and loading times.

In example, a Full HD image with a resolution of 1920×1080 takes 16,386 MB in Memory!

And while this is not that big deal (it’s still a big deal!) for the latest devices that swarm the market, with high amount of RAM and processing power, it is unbearable for older ARMv7 devices. So, something should be done. The player can’t wait forever for the game to load or have his application crash due to lack of memory.

The solution is given by Corona. We create four different versions of the image, each version having different resolution suited for different device resolutions. Then we apply to the image file a so called “Image Suffix” and let the Corona do the dirty job. The result is high quality and lowest memory capture as possible. A background image is given in 4 different versions as follows:

1) background.png
2) background#1-5x.png
3) background#2x.png
4) background#4x.png

The job is done! Lower memory usage, lower loading times. It is important to note here that, in BioLab there will be a loading screen each time you start a new game, or load one. Just something to keep the player’s eyes busy, while the main game loads.

CLOSURE

There are more bits & pieces on the programming side. Like Storyboard. The Android application is divided by Scenes (activities in ADT SDK) and you want something to tell the app to which Scene it should go at any given time. There is splash screen scene, menu scene, main game scene, etc. Like editing a film, the programmer must direct the transition to and from Scenes so we can have a fluid and logical game. This is done with Lua.

There is also memory clean-up. Each time a Scene is destroyed, the programmer must clear the memory. Bad usage may cause “memory leaks”.

And of course there is the algorithmic logic when coding. The programmer must create “if statements”, loops, variable management code and many more, so that the program can understand what you want to do, and how. This can be easy or very challenging. Debugging the application is crucial, and many times, time consuming.

But in the end, all come together

THE BUGS ARE COMING!

We reached the end of part IV. We hope we gave you a very small idea of how things are working behind the spectacle of graphics. Programming is a very big, difficult and complex part of game development and here we tried to make it as clear as we could about some parts of it. Next week get ready because we will reveal the main attraction of our game that is the viruses! From concept, to design, to coloring everything you need to know about these little bugs as well as their role into our game and how you will be able to create them will be revealed.

Until then you can check our website at www.demigod-studios.com. We also wait you in our forums at forum.demigod-studios.com to get to know us and discuss about BioLAB.