The Organic Android

8/7/2019 The Organic Android

1/12

The journey of a programmer into the android world.

The organic android

Sunday, November 21, 2010

Creating 2D games with Android andBlender

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, startingby 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).

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 thehardware 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.

1. Introduction

2. The Blender side (for artists only)

Rubn Lpez

View my complete profile

About Me

2010 (35)

November (8)

Egg Savior 1.4 in the market

Creating 2D games with

Android and Blender

Egg Savior 1.3 fixes the forceclose bug


OTempo 2.0 in the market


open-source and admob

Egg Savior - Trailer

October (5)

September (4)

August (8)

July (10)

Blog Archive

Download Egg Savior

Download OTempo

Searchpowered by

Search This Blog

Share Report Abuse Next Blog Create Blog Sign In

Page 1 of 12Creating 2D games with Android and Blender | The organic android

11/23/2010http://organicandroid.blogspot.com/2010/11/creating-2d-games-with-android-and.html


2/12

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.

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...

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):

1. 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.

2. Walk in place, as if done in a conveyor belt. It is very easy to program, but itinvolves 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:

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):

1. Background. I suggest using a perspective camera unless the background

2.1. Modeling / Shading

2.2. Rigging

2.3. Animation

2.4. Render

Blogging

Anddev

Android developers blog

Android Development

Android goups

Android source

Droidnova

Hello Android

My life with android

Related




3/12

have to be aligned with the foreground. This will add depth to the game levels.

2. 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.

3. 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 setupthe 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 i f 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.

I have experience with the Canvas object, and will center this part in this way ofworking 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:

?

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

to make:

1

2

3

4

Bitmap loadedAssetBitmap = BitmapFactory.decodeResource

(...);

Rect targetArea = newRect(left, top, right, bottom);

[...]

canvas.drawBitmap(loadedAssetBitmap, null, targetArea, null);

3. The engineering side (for programmers only)




4/12

1. 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:

2. 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:

?

1

2

3

4

5

6

7

8

910

11

publicclassSpriteFrameInfo

{

publicSpriteFrameInfo(Point pivot, Point posDelta)

{

_pivot = pivot;

_posDelta = posDelta;

}

Point _pivot;

Point _posDelta;

}




5/12

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 I have a maximum number of columns in the single image thatholds 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:

?

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:

?

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

1

2

3

4

5

6

7

8

9

10

11

publicvoidupdateFrameRectangle()

{

introw = ((int)_curFrame) / _columns;

intcol = ((int)_curFrame) % _columns;

intx = _spriteWidth * col;

inty = _spriteHeight * row;

_srcRectangle.left = x;

_srcRectangle.top = y;

_srcRectangle.right = x + _spriteWidth;

_srcRectangle.bottom = y + _spriteHeight;

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

1718

19

20

21

22

23

24

25

publicbooleanupdateFrame(longdeltaTimeMS)

{

booleantoReturn = 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

{

returntoReturn;

}

}

returntoReturn;

}




6/12

Posted by Rubn Lpez at 2:00 AM

Labels: 2D, android, blender, game

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:

?

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

1

2

3

4

5

6

7

8

9

publicvoiddraw(Canvas canvas, intx, inty)

{

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);

}

1 comments:

santogiuseppe said...

Thanks Ruben...

November 23, 2010 12:03 PM

Post a Comment




7/12

HomeNewer Post Older Post

Create a Link

Comment as: Select profile...

Post Comment Preview

Links to this post

Watermark template. Powered by Blogger.




8/12




9/12




10/12




11/12




12/12


Documents

The Organic Android