The organic android

Merged permanently

2011-04-13T15:14:00.000+02:00

This blog, along with other blogs maintained by me, have been merged into this new generic blog:

http://rubenlopezg.wordpress.com

All posts and comments should have been merged correctly, if not, drop me a comment.

Tater Hater, you have to try it!

2011-03-29T11:49:00.000+02:00

Some time ago, I wrote an article about memory management in Android that was the result of some research with my friend Sergio about his own game. Now he has ended the first version of this game: Tater Hater, which you can download from the Android Market. But remember to try first the Lite version and give him some feedback before purchasing the great complete version.

Here you have the links to the android market web site:

I wish Sergio the best of luck with this new Android project, and I wish you to have lots of fun with his game.

OTempo is now open-source

2011-03-22T22:54:00.001+01:00

After a long time of learning stuff about the android ecosystem, I have finally decided to go open-source, and even remove advertisement from OTempo in the source code. This has several implications:

You can now contribute to this project if you have some programming or artistic skills.
I will continue to publish new versions of OTempo in the market, completely free of Ads, as significant changes happen in the source code.
Yes, the next version of OTempo in the market will be completely free of Ads.

You can check the google code page for the open-source project here:

http://code.google.com/p/otempo/

If you want to contribute to this project, download the code, play a bit with it, and when you feel confident to make some improvements, either send me a patch or ask me for write permission in the SVN repo.

Baking game levels in Egg Savior

2011-02-26T18:55:00.001+01:00

This article covers the way Egg Savior handles the rendering of static objects in order to save both CPU and APK size. The method presented is implemented into the last version of Egg Savior and is working really well, given the limited size of game levels.

The problem

Egg Savior currently has 30 levels. Each one of these levels include a generic background and a lot of bricks that act as platforms for the main character (the chicken). The bricks are all 64x64 pixels in size, and placed in a grid. The obvious yet inefficient way of rendering and interacting with bricks is to handle all of them one by one:

for brick in brick_list:
    brick.render()
    character.detect_collision(brick)

This code is inefficient for two reasons:

Renders the same bricks in the same way all the time, one by one.
Forces to detect collisions with every single brick, even if they are stuck together creating a larget platform

The bricks are static, they don't change during the gameplay. For this reason, it would be faster to render them just once into an intermediate buffer, and then just render this buffer on each frame. This saves a lot of CPU time at the expense of more memory usage. If you have huge levels it may not be a good solution, because devices limit the amount of memory granted to each application to a quite small value. For Egg Savior this worked very well, because the size of levels is somehow limited.

Different backgrounds

The first version of Egg Savior had only 10 levels, and the approach was to have a different background image for each level, with the bricks already included into it. It worked really well, but as more levels were added, it proved not very scalable, because each new level added a lot of data to the APK. This approach meant brick objects to be just invisible rectangles, without render code, because they were already drawn into the background. This enabled a way to optimize also point 2, because there were no reason for defining each brick individually. If three bricks were stuck together in a row, they were defined as a single larger brick, thus enabling less time to process collisions.

Run-time baking

The second iteration of the design, focused on solving the scalability problem with an algorithm that allowed baking the bricks above the background when loading a level. This also involved a way to easily define where to place the bricks. The solution was to use strings with spaces on empty cells and hashes on brick cells:

String levelPattern[] = {
        "           ",
        "           ",
        "#   #      ",
        "##  # #    ",
        "   ## # #  ",
        "## ## # # #",
};

With this language to define brick positions, we already know where to place the bricks on the background. Anyway, there is still a problem to solve: brick shape change depending on its neighbours. If a brick is the first or the last in a row, it has round corners, in other case, it has sharp corners in order to blend with the next or previous one. This leaves us with four cases to handle, depending on the previous, current, and next brick (the current brick is in the middle):

[_#_]: The brick doesn't have neighbours.
[##_]: The brick has only a neighbour on the left.
[_##]: The brick has only a neighbour on the right.
[###]: The brick has neighbours on both sides.

Four brick shapes with enhanced contrast.

The algorithm to generate the background with the tiles is as follows (I removed some obvious code to compute drawBitmap rectangles to enhance algorithm readability):

public static Bitmap bake(String[] rows, Bitmap baseBackground) {
    int nRows = rows.length;
    int nCols = rows[0].length();
    Bitmap newBitmap = Bitmap.createBitmap(nCols * TILE_SIDE, nRows * TILE_SIDE, Bitmap.Config.ARGB_8888);
    Canvas canvas = new Canvas(newBitmap);
    canvas.drawBitmap(baseBackground, null, ..., null);
   
    for (int row = 0; row < nRows; row++) {
        for (int col = 0; col < nCols; col++) {
            char left = '#';
            char right = '#';
            if (col > 0) {
                left = rows[row].charAt(col-1);
            }
            if (col < nCols - 1) {
                right = rows[row].charAt(col+1);
            }
            char c = rows[row].charAt(col);
            Bitmap toRender = getTile(left, c, right);
            if (toRender != null)
            {
                canvas.drawBitmap(toRender, null, ..., null);
            }
        }
    }   
    return newBitmap;
}

The getTile method just handles the four cases mentioned earlier, and returns the right bitmap from the app resources.

Automatic collision optimization

The baking of the bricks into the background solved the render part of the original problem (point 1). The bricks, which now consisted only in invisible rectangles, were defined by hand, looking at the hashes and chosing a smart way of arranging them in a minimum set of rectangles. This is a highly boring work that discouraged me to add more levels, and the perfect candidate for automatization.

Finding the minimum set of rectangles that covers all the bricks is not an easy task, because there usually exists more than one way of covering all the bricks with rectangles. Sometimes the best way involves using overlapping rectangles. Even though finding the optimal solution was an interesting challenge, I realized that including complex (and maybe slow) code to reach perfection was not worth in this case. Having 10% more rectangles than the optimal solution didn't impacted the performance in a visible way. I decided to go with a simple algorithm that provided a good enough solution.

Original bricks

The basic idea of the algorithm is to process each row independently, looking for contiguous blocks which define single rectangles, and then try to mix rectangles from consecutive rows if possible. As I said, this doesn't find the optimal solution, it is just a greedy algorighm that provides a good enough one.


Column joins	Row Joins

This is the pseudo-code:

previousRow = new Set[Rectangle]
currentRow = new Set[Rectangle]
rectangles = new List[Rectangle]
for row in rows:
    currentRectangle = None
    currentRow.clear()
    for char in row:
        if char == '#':
           if currentRectangle == None:
               currentRectangle = new Rectangle(colNum, rowNum)
             else:
                 currentRectangle.grow()
        if (char == ' ' or isRowEnd) 
           and currentRectangle != None:
           if canMix(previousRow, currentRectangle):
                  mix(previousRow, currentRectangle)
            else:
                 rectangles.add(currentRectangle)
       currentRow.put(currentRectangle)
    previousRow = currentRow
return rectangles

The algorithm already tries to mix rectangles with the previous row ones while they are generated, and does a pretty good job joining lots of bricks into big rectangles. Another optimization that I did to the algorithm is to encode the previousRow as an array with the same width as one row, where each position of the array has a pointer to the rectangle that covers this cell or to null if it is empty. This way, finding the right rectangle to mix with in the previous row runs in constant time. Actually, my implementation doesn't need a currentRow structure, I overwrite the previousRow one after reading it...

I will not go into the actual implementation to avoid making this article infinite, but if anyone has some doubt on how to implement it, feel free to leave a comment and ask.

Conclusion

With the background baker and the rectangle optimizator, generating new Egg Savior levels reduces to actually thinking them and mostly writing a string with hashes. This code runs each time that the player starts a level, and is so fast that it is actually overshadowed by resource loading time.

A very exigent market for games

2011-02-16T00:47:00.000+01:00

It has been almost four months since I published the first version of Egg Savior in the market. This game was mainly an experiment to learn a couple of new things. First of all, I wanted to learn how to develop games for the Android platform. Secondly, I wanted to learn how the market reacts to games. And finally, I wanted to learn how global apps perform, since OTempo, my former app, is a local app targeted to galician users.

For the first target, I am quite proud. The game performs quite well even on middle-end hardware like my old Galaxy Spica, and I was able to try graphics, sound and input. You can read my post on Creating 2D games with Android and Blender where I share some of my gathered knowledge.

About market reaction to games, I have learned a quite hard lesson: The market is very exigent, even with free games. Actually, I think that gamers don't care if your game is free or costs a couple of bucks, they expect a high quality product from the first version, and if the first version is not good enough, upgrading and enhancing it will not work like it would have done with other apps. Advertising has been very helpful on recognizing usage patterns on the first version and each upgrade.
I have to admit that this lesson was hard to fit, because I spent long hours working in this game, but sometimes one has to get back to planet earth and remember its objectives. It was a learning experience, and I have learned a lot. I realize that the artistic needs of the game far exceed my ability, and the number of levels is quite ridiculous, but it was not about fame and glory ;-)

About the global market, I also learned a valuable lesson. There is a lot of fragmentation. Every country behaves differently to this game. All the statistics that admob provides point to the fact that the usage pattern varies a lot from one country to another. The most obvious example is the case of Korea, where the game was a huge success, maintaining the first position in free games for several consecutive days. I believe that this is a great opportunity rather than a threat. It enables development of products with a strong personality, focused in a concrete market, and opens more opportunities for everyone. It also warns of the risk of starting a serious project (I mean, investing money) without any kind of market research.

Egg Savior reached 100K downloads in Korea

2011-01-24T11:01:00.001+01:00

Some time ago, I made an agreement with UbiNuri to distribute Egg Savior in the korean market. On January 17, Egg Savior was published in the T Store, and the users reaction was really impressive. In Just five days it came to the first position in the free game category, with 50K downloads, which doubled during the weekend, making a total of 100K downloads after just eight days.

I want to thank UbiNuri and all the korean users who are enjoying this game, and promise new versions with more levels.

By the way, the korean name of Egg Savior is 달걀 지키기.

OTempo bugfix release: 2.5

2011-01-23T22:22:00.000+01:00

Unfortunatelly, the previous version of OTempo (2.4) had a bug with advertisement. You now have the choice of upgrading to 2.5, thus supporting development by re-enabling ads, or stay in 2.4 without ads until the next version which will include new features. It is up to you :)

OTempo 2.4 in the market

2011-01-18T21:53:00.002+01:00

I have just updated OTempo once again. This time, it contains a bugfix in the dialog management code, that someone of you reported to the market. Thanks!
I also took the opportunity to update the rain icon, because the old one was too uniform. I hope you like the new one, and also hope it looks OK in the brighter areas of the background.

By the way, in the moment of this writing, OTempo is ranked 103 in the list of weather applications! Thanks to all the users who trust OTempo!

If you don't have it already, you can download OTempo using a mobile device, from this link:
market://details?id=org.otempo

You can also find OTempo on bubiloop.

Remember that it only works for Galicia.

OTempo 2.3 in the market

2011-01-05T23:23:00.000+01:00

I have just released a new version of OTempo. This time it is a bugfix release.
It addresses a bug for all Android 1.5 devices, and another one that affects all phones when using the prediction descriptions in some circumstances.

As always, you can download OTempo using a mobile device, from this link:
market://details?id=org.otempo

Supporting Android 1.5 in the new ADT

2011-01-05T16:06:00.002+01:00

It seems that the last version of the ADT behaves slightly different from the previous versions and may involve changing code. One of the changes that I have seen is that you must explicitly disable formatting in the strings.xml files if you have more than one placeholder that you will use from code (like %s).

The other one was discovered by one of the OTempo users (Jose Miguel). It seems that ADT can not package correctly the resources if there is a folder called "drawable-mdpi". This is odd, because "drawable" is for density independent images, not mdpi ones. This behaviour seems to affect only Android 1.5 devices, as I could not reproduce it on 1.6, 2.1 or 2.2.

I think that I will have to learn to live with this, at least until the last Android 1.5 user migrates or changes its phone.

Expect a new version of OTempo in the following hours.

Total/Free memory on android apps and games

2010-12-28T18:18:00.000+01:00

Yesterday I was helping out my friend Sergio with his own Android game, and he needed to how much memory does each android device have, and how much memory is the app using. After checking out the biggest source of wisdom (yes, stackoverflow), this seems to be the solution:

Heap size:

long heapSize = Debug.getNativeHeapSize();

The heap size is not exactly the memory that your app is directly using, but the memory that the VM is reserving for your app. It may be slightly higher than the memory that your app is using due to fragmentation and provision. This number will vary as you allocate memory and force the VM to grow the heap to fit the extra needs.

Allocated size:

long allocated = Debug.getNativeHeapAllocatedSize();

The allocated size is the actual memory amount that your app is directly using.

Free size:

long free = Debug.getNativeHeapFreeSize();

The free size is the amount of memory from the heap that is not being used, because of fragmentation or provision.

These three measurements are very useful. Of course, the first one is the more important one, because it tells you if you are approaching the memory limit or not, but the other two are very interesting for performance reasons. If you use to have a lot of free memory in the heap (say, more than 100KB), this could be a symptom that your app is allocating and freeing a lot of memory on a regular basis, and this may lead to performance problems due to involving the garbage collector all the time.

Ok, this tells you how much memory you are using, but now there is another interesting question left: How much memory are you allowed to use? It actually doesn't depend on the physical memory amount, but in a hardwired limit that vary from device to device.

Memory limit:

long maxMem = Runtime.getRuntime().maxMemory();

This memory limit will tell you how much memory your app can allocate. In my device it is as little as 18MB. And the biggest EggSavior Level is using 13.5MB. There is room for slightly bigger levels!

I hope this brief article will shed some light to other Android game developers.

OTempo 2.2 in the market

2010-12-28T13:29:00.000+01:00

I have just updated OTempo to a new version (2.2). This version allows to click on short-prediction days to see its description, which sometimes gives very usefull information. Besides, a bug about using huge custom background images has been fixed.

As always, you can download OTempo using a mobile device, from this link:
market://details?id=org.otempo

Egg Savior website

2010-12-05T20:57:00.000+01:00

I have finished the website of Egg Savior. There you will find images, videos, and instructions to play it, as well as the latest news and a download area for those of you without Android Market in your device:

Egg Savior website

From now on, general Egg Savior news will be published in this website, and The organic android will focus on technical articles derived from the development, as well as other apps like OTempo.

Egg Savior 1.5 is here!

2010-12-04T11:02:00.000+01:00

After a lot of work, I have published a new version of Egg Savior, my Android game. This version includes three new levels and these improvements:

Added a level panel, where you can see your achievements. I had advanced it here.
The last level includes something new that will change the gameplay in next levels.
Changed black background in small levels for a more interesting one. I hope that this makes the game less ugly :)
If the chicken is teleported into an obstacle, it dies. This makes the game a bit more realistic (As much as possible with teleportation system ;-)
Changed game icon for a more dynamic one. I hope this attracts more players.

If you are reading this from an android device, you can download Egg Savior from this link:
market://details?id=com.eggsavior

OTempo 2.1 in the market

2010-12-01T21:52:00.000+01:00

I have just updated OTempo to a new version (2.1). Everyone is encouraged to download this version as soon as possible, because it lacked snow icon, and tomorrow there will be a lot of snow out there.
Besides, it fixes a couple of bugs that were reported by users.

Egg Savior will have a levels menu

2010-11-29T19:30:00.002+01:00

I have been quite busy these days developing a couple of new features of Egg Savior. One of them is the levels menu, that will let you know which levels have been played, and what was your score on them.
This menu is the reason why the previous version started to record scores. I wanted to share its design here, just in the case that anyone with good taste would like to suggest some enhancements before the next version is out:

I am planning to add 3 more levels in the next version, thus reaching a milestone of 20 levels. Expect it in the following days...

Egg Savior 1.4 in the market

2010-11-22T22:27:00.000+01:00

I have just finished a new version of Egg Savior, with the following improvements:

Adds a new level
Warns if you try to move pieces while the game is paused
Stores achievements on the phone. Players should not notice anything about this in the current version, but it the next version will do level blocking based on played/unplayed levels, and the game needs to gather info from current users to effectively block levels for them. You will be able to see your achivements in the next version too.

This is a little release because I was working really hard in my last article. Next version will be much more interesting, I promise!

If you are reading this from an android device, you can download Egg Savior from this link:
market://details?id=com.eggsavior

Creating 2D games with Android and Blender

2010-11-21T02:00:00.001+01:00

1. Introduction

This article will cover one of the possible workflows that you can use in order to create Android games using Blender for content creation. This article is based on the knowledge that I could gather during the development of Egg Savior. For the programming part, I will assume that you have some knowledge about game creation in Android. If this is not the case, please start by reading these great tutorials before continuing. For the graphics part, I will assume that you know how to create graphics with blender. If this is not the case, please start by reading these great tutorials, or consider hiring a blender artist.

Blender is a powerful 3D content creation tool that has proved application in many different areas. It even includes a game engine that you can use to develop PC games. There are several 3D games made with Blender, starting by Yo Frankie, the first open game from the Blender Foundation. But the most important feature of Blender is its license: which makes it open-source, and free of charge.

So why use a 3D tool for 2D games? Because unless you are a great 2D artist, it is easier and faster to animate in 3D, and it is easier to get an acceptable overall result if you are not very good with graphics (like is my case). The obvious trick is to pre-render the 3D graphics into 2D images and use these images as assets for your game.

In the following sections I will explain how you can build your own pipeline for working with blender for 2D Android game creation. I will focus first on the artistic side (Blender) and then on the engineering side (programming).

2. The Blender side (for artists only)

I will focus on pure 2D games. There are some 2D games that fake a 3D effect (eg isometric games) but I still have to explore them and develop a workflow for these. Creating the graphics with blender is quite straightforward, and you just have to follow a few simple rules to have a set of graphics that can be used without problems in a game engine.

First of all, you should chose a hardware target for your game. Android runs on a variety of devices with different screen sizes and resolutions. You simply can't make a 2D game that looks good and runs fast on every possible device. Narrow the hardware where you want your game to run properly and then design your graphics to fit in the chosen range of supported screen resolutions and sizes.

2.1. Modeling / Shading

There is nothing magical here. Just ask yourself a few questions before starting:

Which sides of the object will be seen on the screen? Maybe you don't need detail in the whole object.
What will be the maximum size in pixels of the object? I mean, in the highest resolution device. Maybe you don't need to add feathers to your chicken because they will not be seen ;)
Do you want to give the game a cartoon look? Take into account the cartoon edges, they also use pixels!

By the way, don't be afraid of the number of polygons, the devices will not see them, because the final output of Blender are images.

2.2. Rigging

Rigging for 2D games is not easier than rigging for movies, but it takes less time. 2D games have something in common with series, though: lots of animation cycles! These are my tips after having made Egg Savior:

Automate everything that you can. You will be animating lots of cycles, and the more automated is the rigging, the less effort you will need to put in animation.
As with modeling and shading, concentrate on the level of detail. You don't want to add a muscle system that will not be seen because the character will be 64 pixels tall...

2.3. Animation

Up to this point, I was just writing about several optimizations that you can do to work less. Now we will get into something more important, because the choices that you make in this point, are related to the choices that have to be made in the programming.

If your character is going to move across the screen because of the animation (eg walking), you have a very important decision to make, how to animate this cycle. Two options (I will use the walking example):

Move the character across the scene while it walks. You get the highest quality of animation, because you can even change the speed of movement from step to step. The problem is that this involves a bit more complex programming.
Walk in place, as if done in a conveyor belt. It is very easy to program, but it involves strong restrictions on the animation, that have to move the character at a constant speed.

Later, I will explain how to program both options. In Egg Savior, I choosed the first one, because I wanted higher quality and to avoid foot slip:

2.4. Render

The first thing to consider in the render phase is how to configure the camera for the render of each asset. I will share my own point of view, although yours may differ (feel free to comment):

Background. I suggest using a perspective camera unless the background have to be aligned with the foreground. This will add depth to the game levels.
Foreground objects. I am calling foreground objects to those that doesn't move, but the character can interact with them (eg platforms). I suggest using an orthogonal camera, to help them integrate well with the character. If you want to compose the foreground by tiling small objects, the orthogonal camera is the only option.
Characters. Characters will be animated, and the last frame of the animation must match the first frame to be able to cycle it. Unless you use the "walk in place" solution, the last frame will not match the first frame if you use a perspective projection. Anyway, if the character is rendered with perspective, when it moves across the screen the eye will notice that this perspective is not changing, thus making it less believeable.

The use of an orthogonal camera for the render of foreground objects has an additional benefit. You can predict the size of the object on the image without actually rendering anything, because there is an easy relationship between the size of the object, the size of the camera and the screen size. An easy rule is to setup the orthogonal camera with an scale of 1, and make objects with size 1x1 when they must fill the whole asset image. You can now simply play with the output resolution to make assets with different sizes, if needed.

The second thing to consider is the AA filter that you must use. It depends on the target hardware, and specifically on the screen resolutions. If your graphics are going to be small because you target handhelds, you have to use a crisp filter even if it generates a bit of aliasing. You can try mitch or even catrom. If you target big screen devices with little dpi (like some tablets), then you might consider less crisp filters because the aliasing artifacts can be very noticeable. In that case, avoid catrom, try mitch or even gaussian.

The third thing to consider is the output format. I suggest using PNG in RGBA mode for the foreground and characters, as it is a quite programmer-friendly format.

3. The engineering side (for programmers only)

I have experience with the Canvas object, and will center this part in this way of working with 2D graphics. You can also program 2D graphics with OpenGL ES, and some games do it this way because you can gain some performance, but not every device supports it correctly (eg my Samsung Galaxy Spica).

Rendering foreground objects on the screen is quite straightforward. You can just use the canvas methods for this:

Bitmap loadedAssetBitmap = BitmapFactory.decodeResource(...); 
Rect targetArea = new Rect(left, top, right, bottom); 
[...] 
canvas.drawBitmap(loadedAssetBitmap, null, targetArea, null);

The difficulty comes with animated objects, like characters. There are two decisions to make:

How to encode the animation?

Each frame on a separate image. Easy to program, but bad for performance, as you have to decode lots of images at startup and cycle between them may also hurt the cache.
Every frame on a single image (like a texture atlas) as suggested by Stephen Flockton. Harder to program, but better performance. Also, this option is more OpenGL-friendly, just in the case that you want to switch at some point in the future. This was the option implemented in Egg Savior, with good results. Here you have an example of the walk cycle:

How to handle movement? This is a decision that you have to make both for programming and animation, as I wrote before. The two options, as seen from the animation:

Walk in place, as if done in a conveyor belt. If the animation was done this way, you just compose every frame that Blender outputs in the single image and compute how many pixels should the character advance on each frame. This way, each time that you advance one animation frame, the character moves X pixels on screen.
Move the character across the scene while it walks. If the animation was done this way, you end up with a series of frames like these three samples:

As you can see, the character advances through the image. And if you play the whole animation, you will see how the character advances through the floor without foot slip. You can make a simple python script that extracts the bounding box of the character and encodes just this piece on the single image, and at the same time, encodes the offset that each new frame applies to the character with respect to the previous one. When programming this thing, you just move the character with the offset associated with each frame. This allows different offset on each frame, and gives more freedom to the animation stage.

As you can figure out by seeing the samples, I have chosen the hardest but more efficient and flexible way of handling both aspects. This is the information that I attach to each frame to handle movement:

public class SpriteFrameInfo 
{
    public SpriteFrameInfo(Point pivot, Point posDelta)
    {
        _pivot = pivot;
        _posDelta = posDelta;
    }
    
    Point _pivot;
    Point _posDelta;
}

posDelta is the offset that this frame must apply to the character to move it to the right position.
pivot is the position inside the frame that can be considered as the "character position" to have it standing on the floor. This is usefull in a platform game like Egg Savior, but not as much in other 2D games.

As you have seen, I have a maximum number of columns in the single image that holds every frame. In fact, I try to keep the image as square as possible, to be easy to open with any editor/viewer. Thus, the code to compute the rectangle that corresponds to each frame is this:

public void updateFrameRectangle()
{
    int row = ((int)_curFrame) / _columns;
    int col = ((int)_curFrame) % _columns;
    int x = _spriteWidth * col;
    int y = _spriteHeight * row;
    _srcRectangle.left = x;
    _srcRectangle.top = y;
    _srcRectangle.right = x + _spriteWidth;
    _srcRectangle.bottom = y + _spriteHeight;
}

Where:

_curFrame is the current frame
_columns is the number of columns of the single image that holds every frame
_spriteWidth is the width of each frame in the sprite
_spriteHeight is the height of each frame in the sprite

And now, the method that updates the current frame:

public boolean updateFrame(long deltaTimeMS)
{
    boolean toReturn = false;
    _curFrameTime+=deltaTimeMS;
    _positionDelta.set(0, 0);
    while (_curFrameTime > _mspf)
    {
        if (_looping == true || _curFrame < _nFrames - 1)
        {
            _curFrame = (_curFrame + 1) % _nFrames;
            _curFrameInfo = _frameInfoList.get(_curFrame);
            _curFrameTime -= _mspf;
            updateFrameRectangle();
            Point p = _curFrameInfo.getPosDelta();
            _positionDelta.x += p.x;
            _positionDelta.y += p.y;
            toReturn = true;
        }
        else
        {
            return toReturn;
        }
    }
    return toReturn;
}

Where:

_curFrameTime is the game time relative to the current frame, in miliseconds. Each time that the animation advances, it restarts counting. You need this because the animation framerate may be less than the device framerate.
_positionDelta is offset that have to be applied to the character in this frame
_mspf is the number of miliseconds per frame. It is obviously derived from the FPS.
_curFrameInfo is the current instance of SpriteFrameInfo

You may notice on this code that there is a while. This is needed because on some situations, you may have to advance several animation frames. For example, Egg Savior has a "fast forward" button that simply scales the deltaTimeMS parameter used for animation, faking that time goes faster, and on a single device frame you may have to advance several animation frames, and apply all the offsets of these frames to the character. In that case, the performance would be higher with the "walk in pace" approach, but I prefer the animation freedom.

Finally, the code that renders the sprite is almost obvious:

public void draw(Canvas canvas, int x, int y)
{
    Point pivot = _curFrameInfo.pivot;
    _tgtRectangle.left = x - pivot.x;
    _tgtRectangle.top = y - pivot.y;
    _tgtRectangle.right = _tgtRectangle.left + _spriteWidth;
    _tgtRectangle.bottom = _tgtRectangle.top + _spriteHeight;
    canvas.drawBitmap(_sheet, _srcRectangle, _tgtRectangle, null);
}

I hope that this article helps you to start developing your own 2D games. And if you are an experienced developer, feel free to share your knowledge and propose other alternatives to these ideas.

The android image of this post is a modification based on work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.
This post is shared according to terms described in the Creative Commons 3.0 Attribution Share Alike License

Egg Savior 1.3 fixes the force close bug

2010-11-16T00:16:00.000+01:00

I have just published a new version of Egg Savior to solve a bug introduced in 1.2 that caused force close on some situations when going to sleep and coming back.
Sorry for the inconvenience.

Egg Savior 1.2 in the market

2010-11-14T21:29:00.000+01:00

I have just finished a new version of Egg Savior, with three new levels and the following enhancements:

Automatic scroll when approaching an screen edge. Can be configured, or even disabled if you dislike it.
Now you can drag the pieces that were below the inventory. This was a bug and on some devices could get very annoying.
The audio resumes after turning off/on the screen. This was related to this contribution in StackOverflow.
The game is now paused when you return from another app, avoiding you to lose the game if you had an incoming call.

If you are reading this from an android device, you can download Egg Savior from this link:
market://details?id=com.eggsavior

I am working on an in-depth article explaining the Blender/Android pipeline that was used to develop this game. Stay tuned!

OTempo 2.0 in the market

2010-11-10T22:26:00.001+01:00

OTempo 2.0 (not a major change, just didn't liked 1.10) has come to the android market. This version is specially driven by the community of users, because most changes are suggested by the users themselves. The list:

You can change the background image. You should use vertical images to avoid stretching. The ideal size varies from one phone to another, but use something like 320x359, or similar aspect ratio should be nice.
The button next to the prediction time will not be shown after you press it once. This button was really ugly, I know.
Fixed a bug in the widget, that was showing the previous day prediction sometimes. Actually, at any hour from 0:00 to the first day prediction :-(
Added a share button to the menu. Use it to tell your friends about OTempo, and help creating a community of users. It will share a link to the OTempo facebook page.

As always, you can download OTempo using a mobile device, from this link:
market://details?id=org.otempo

Egg Savior 1.1 in the market

2010-11-06T02:14:00.002+01:00

Egg Savior has been updated. This new version includes two new levels and the following changes, suggested by users:

Added a fast-forward button (asked by a lot of people)
Disabled scroll when the whole level fits on the screen (should fix the problems with big-screen devices)
Fixed bug: having won, you could not restart the level to improve the score.

If you are reading this from an android device, you can download Egg Savior from this link:
market://details?id=com.eggsavior

Thanks for your support.

open-source and admob

2010-11-04T21:32:00.001+01:00

From the first line of code of my first android app, I had the idea of open-source in mind. I wanted to test the advertisement business model and clear my own ideas before doing the mix with open-source, because I had a lot of doubts about how to manage both things at the same time.
Now I have a plan and no longer fear this combination from the economic point of view. Take my words with care, as I am still in a learning process with toy projects of zero cost and zero risk (and almost zero income). Two things can happen that I was concerned about:

Case 1

Someone can take the code, not contribute anything, and start making money for himself. This is something that can happen with open-source in general, but in the android environment, it is specially easy to do. Anyway, as long as I don't make less money, I don't care if others do it also.
Even if this person contributes with enhancements and users prefer his/her version over mine, I would have access to the source of his/her enhancements to update my version and build on them. That is the power of open-source, and I am not afraid of it.

Case 2

Someone can take the code, remove the advertisement, and republish it free of charge and free of ad in the market. This is a little annoying, and would hurt my income. I used to be also a young boy with plenty of free time and no bills to pay, and did projects for fun, but now things changed a bit, so I must take some action to protect the income. Tom Tasche, author of SayMyName, suggested an interesting and friendly solution to this. If someone is so annoyed by the advertisement that he/she would take the time to publish an ad-free version, then I should allow disabling the ads at the configuration. People annoyed by advertisement don't click on ads anyway, and people that don't care and even click when they are interested, would leave them turned on if only as a contribution to the developer.

As I said, my toy projects are not giving real income, allowing me to test these theories with zero risk and better define a business model for the projects to come.

GPL and admob incompatibility

So far so good, but then Brendan Dahl, the author of gcal-call-logger, pointed to an interesting problem with GPL (my favorite license). GPL doesn't allow linking with closed-source libraries, like is admob. At first, without community contributions, you could relicense it to yourself without GPL just to publish it with admob, and it would work, as it works for gcal-call-logger. The problem comes when you want to accept community contributions to the codebase, something that I would love to do with OTempo, for example. Community contributions are covered also by GPL, but these contributions are not your property, and you can not relicense them in order to publish the resulting app with admob again.

I have not yet found a solution to this last problem. Maybe GPL is not the right open-source license in this case, or maybe I should give AdWhirl (an open-source meta-ad-provider) a try.

Update: People from GNU already thought about issues like this one, and they explain in the FAQ how to overcome it: GPL FAQ (GPL incompatible libs)

Egg Savior - Trailer

2010-11-01T16:14:00.002+01:00

Egg Savior 1.0 published, worldwide!

2010-10-29T16:28:00.001+02:00

After just a week of beta testing, it seems that the game is stable enough to be released worldwide. I have uploaded the 1.0 version to the Android Market, and its available for you to download.

This version includes 11 levels, of varying difficulty. I will be adding extra levels on each new release, plus bug fixes and gameplay enhancements as suggested by the players.

Thanks to all contributors who made this possible, especially to Diego F. Goberna for his invaluable help with graphics and Silvia Izquierdo for her patience and the help with the marketing and level design.

Thanks also to all the beta-testers, because without them, this first stable release would not be nearly as stable.

If you are reading this from an android device, you can download Egg Savior from this link:
market://details?id=com.eggsavior