Skip to content
May 2, 2011 / Aurélien Ribon

Universal Tween Engine: rev 4.2

Hi there,

I released a new version of the Tween Engine. It mostly features facilities to handle overwriting tweens.


+ Added “boolean contains(Tweenable target)” to
+ Added “boolean contains(Tweenable target, int tweenType)” to
+ Added “void kill(Tweenable target)” to
+ Added “void kill(Tweenable target, int tweenType)” to
+ Added “Tween[] getTweens(Tweenable target)” to
+ Added “Tween[] getTweens(Tweenable target, int tweenType)” to

Read more…

April 26, 2011 / Aurélien Ribon

Logic vs Render, the separation of concerns

On many occasions, I saw people wondering what magic they should cast at a physics engine to make it properly render its simulated objects on screen. This post aims at helping you understand how to make a clear separation of concerns, and why.

If you are a beginner in the game development world, I hope you’ll find this tutorial helpful !


When designing a game, there are two major concerns that should be separated: LOGIC, and RENDER. Here is a quick sum-up:

  • Rendering code is where you draw on screen. Anything related to textures, camera, viewport, meshes, sprites, etc. should be handled in this part of your application. You will most certainly use a rendering framework to help you (I strongly recommend the very powerful LibGDX framework for desktop and android targets).
  • Logic code is where you create and update your simulation code, your object models. You may use simple positioning and collision detection, or even a complete physics engine. Measures will most certainly be related to real-world references (meters, kilograms, etc.).

Therefore, logic and rendering parts do not have anything in common. Well, actually they do have something, because your rendering code has to present to the user what your logic code is computing.

Why do I need to separate render and logic ?

Because it is the best way to make your game mechanisms robust and efficient. Also, it will greatly help you to support a lot of different targets with different resolutions.

Indeed, by separating our concerns, the logic part (defining the gameplay of your game) will be universal. Build it once, and you won’t have to mess with it thereafter. Only the render part is target dependent.

Logic part: it’s all about models

You define your objects and you update the game state  in the logic part. This does not involve any platform target or rendering attributes. This part should be universal. Measures are expressed in a static, target-independent way. You can use your own arbitrary units, or the SI units (meters, seconds, etc.).

A simple interface for the logic part would at least contain the following:

public interface Simulation {
	 * Objects are defined with target-independent units.
	public void createObjects();

	 * Objects are updated according to the simulation laws.
	 * If using a physics engine like Box2D, this method
	 * would at least call "world.step()".
	public void updateGameState(float ellapsedSeconds);

Render part: know your targets!

Now that you got some objects interacting with each other, you need to present them to the user. However, there are nearly as many desktop/phone resolution as there are potential users. Kidding, but that’s quite right.

The target resolution

First, you need to define what will be your main target resolution. The entire game will be developed with this resolution. It may correspond to a real device or be an arbitrary resolution. Let’s say we use 480×320.

This resolution on its own is not sufficient to display your game. Indeed, your objects have sizes expressed in meters. Thus, you need to define a PIXELS_PER_METER constant, which will link the logic part and the render part.

// With the following value, our 480x320 target resolution
// corresponds to a 15m x 10m visible world size.
public static final float PIXELS_PER_METER = 32;

Last thing to do is to define your assets. If you made an enemy 1m tall, create an image for it with a 32px height.

Supporting other resolutions

OpenGL, as every rendering layer, will happily stretch your target display to fit any other resolution. Therefore, the width/height ratio of different targets is important. Indeed, our 480×320 target resolution will perfectly fit in a 720×480 resolution. However, a 800×480 target will trigger a width deformation.

Solutions are as follows:

  1. Either accept this stretching if it has no impact on the game visual quality , or
  2. Let players see different portions of the game depending on their device aspect ratio

In the first case, it will result in different PIXELS_PER_METER ratios for the X axis and the Y axis. In the second case, this ratio will stay the same for each axis, but the player viewport will depend on its resolution. Either add some black areas to fill the screen, or let the player show a little more or a little less of the current level. It really depends on what game you are designing.

Pixel-perfect everywhere

Pixel-perfect rendering or 1:1 pixel mapping corresponds to making a pixel of an asset cover one and exactly one pixel of the target device.

If you designed your game with a 480×320 target resolution, and you want to support 800×480 resolutions, your assets will be scaled up (see the illustration below). Therefore, there won’t be pixel-perfect matching anymore, and visuals won’t look as sharp as with the target resolution.

It may be ok for many games, but you may want to overcome this. The only solution is to create as many assets as supported resolutions. For instance, if your enemy is still 1m x 1m, you made a 32×32 px image for your 480×320 target resolution. Therefore, you also need to make a 48×48 px image for 800×480 and 854×480 resolution (if you chose the show black lines or a bigger portion of the level), etc.

Interaction with the user

We never talked about user interaction, and you need it to make not just a fantastic game, but an awesome one. However, when the user touches or clicks on the screen, you will usually get an input in pixels coordinates, relative to the screen origin.

It means that you need to process the inputs before sending them to the logic part, since the latter do not want anything related with screens and pixels.

Hence, you got your complete separation of concerns. On each frame, inputs are processed and sent to the logic part in a compatible format. Then, simulation code is updated according to these user interactions and to internal mechanisms (gravity, forces, torques, collisions, etc.). Finally, objects are drawn according to the PIXELS_PER_METER constant as well as the current camera state.


You should now be able to understand why and how to separate things to make your code cleaner. Separation of concerns does not imply different classes for rendering, simulation and inputs, it just means that you should process things in a certain order.

Of course, this tutorial is based on my past experience. Do not hesitate to tell me how YOU plan your games! ;-)

NB: to go further, I greatly suggest you to read the first comment of this article!

April 20, 2011 / Aurélien Ribon

Universal Tween Engine rev 4.0

A new revision of the Tween Engine is out: 4.0. It features a much more flexible engine, with TweenManagers and optional tween poolingExtensive documentation has been added to the project wiki, you should easily understand how to use it.

April 13, 2011 / Aurélien Ribon

Java Universal Tween Engine

Blog back !

I’ve been really busy these days, sorry for the total lack of updates. I saw that strangely enough, there are many pages viewed each day.

This post is there to present you one of my main recent additions: the Universal Tween Engine.


What I designed is a Tween Engine, for Java, which is able to interpolate every attribute from every object using every Robert Penner’s easing equation. You can get a look at these equations here. Thus, you can use it in any project, being a desktop GUI made with Swing or SWT, an OpenGL Game or an Android application.

Talking about Android, I specifically built this library with performances in mind. There is no dynamic object allocation, so no garbage collection at all (Tweens are pooled, etc.). As a result, it performs very well on embedded devices!

Tweens, Animations, Interpolations…

If you’re not used to the concept of “tweening”, here is the Wikipedia definition:

Inbetweening or tweening is the process of generating intermediate frames between two images to give the appearance that the first image evolves smoothly into the second image. Inbetweens are the drawings between the key frames which help to create the illusion of motion. Inbetweening is a key process in all types of animation, including computer animation.

The concept of tweens comes from the Flash world. The goal of a tween is usually to let you create a nice and cool animation in just one line of code, such as:

// This single line means "animate my sprite rotation from its
// current value to 360° in 1s (1000ms), with an elastic equation,
// but wait 1.5s before doing it". You said pretty cool ?, ROTATION, Elastic.OUT, 1000, 360).delay(1500).start();


Here’s the library code page:

In the download section, you will find a JAR executable that demonstrates every equation and a small demo (need to add real showcase… :p), as well as the JAR library itself.

All you have to do to use it is to implement the Tweenable interface, so the library can act on your objects. See the provided example source code to begin, it’s a real piece of cake.

The possibilities are (currently) as follows:

// Arguments are (1) the Tweenable target, (2) the type of interpolation,
// (3) the easing function, (4) the duration in milliseconds and
// (5) the animation target values (which count depends on the tween type), TweenTypes.POSITION_XY, Elastic.INOUT, 1000, 50, 50);

// Possibilities are:; // interpolates from the current values to the targets
Tween.from(...); // interpolates from the given values to the current ones
Tween.set(...); // apply the target values without animation (useful with a delay); // calls a method (useful with a delay)

// Current options are:

// You can chain everything:;

Have fun :-)

Future work

The library itself will see many new features added to it. I have many use-cases for special things in mind (especially a reverse() function).

However, what I’m currently developing is a total visual timeline editor for this engine. Something like the Expression Blend timeline (see picture) or the Flash authoring tool one. It would ease the creation of animation by a multi-tons of times !

I will also get a dedicated website up and ready, with tutorials, showcase and examples with source code.

I’m also planning C# and C++ ports, if I find out that there is a real need for it.

January 12, 2011 / Aurélien Ribon

Pirate Compass is now free !

Yes, that’s right, it’s a 180° turn ! But like I said, I wanted to test the android market. I have my answer :-p

Actually, I think that going directly non-free is a mistake, especially for a new application that no one knows and which interest is not sufficiently high to be publicized on forums. I think that for the next apps (which will be more complex and definitely more interesting) , I’ll try the add-on way. It will allow users to try it extensively and decide by themselves if they want to buy extra levels/options.

Anyway, have fun with it !

And a big thank you to all those awesome friends and family (and to those 3 american guys) who bought this app :-)

January 10, 2011 / Aurélien Ribon

First post, first android app out!

Hello, and welcome to this blog!

This will be a (yet another) blog with tips, tricks, techniques and tutorials about many Android and WPF related things. Mainly to help me remember what I find useful but also because blogs tends to be developers primary resources (aside from of course).

But for now, the most recent thing I want to talk about is my first experience with the Android market, from a developer point of view. Indeed, I recently developed an application (my first one) to test the Android SDK. But because I love animation, I quickly turned to a game development library, to see what can come out of it. As a result, I’m not very proud of this application, because it’s not a very useful app, but it allowed me to get ready for a real, big and complete game.

To sum up things a little, this application is (yet another) compass built to be a little more fun than what was already present in the market. The needle is linked to the center with a floating chain and is attracted by the north. Cannons arbitrarily fire bullets on objects falling in the direction given by the accelerometers. Well, built-in magnetic sensors being not that reliable, it was interesting to try a different, entertaining, approach. Yes, it’s a non-free app. I apologize. Actually, it will most certainly become free in a not-that-far future, but I needed to know if anything could be bought without any publicity. The answer, which might interest some of you, is “yes, at least while the app is featured in the new applications section”. Got 3 payments (other than supporting friends). Since then, nada :-). It won’t support me in the other app developments, but it was nice to see how the market actually works.

About Android game libraries

To come back to the developement, I firstly looked for a decent Android game library. Many are out in the wild, Cocos2D (from the iPhone world), AndEngine, LibGDX, and plenty of others. I first tried AndEngine, mostly because it features a complete live demo app for android devices, as well as a quite big community. But it appears to be limited to 2D graphics and many devs report some kind of bad performance results compared to other libs. Also, part of their JNI wrapper to C++ libs is just a direct extracts from the work of LibGDX developers. I’m not really against it, because that’s how open-source should work, but they won’t be as up-to-date as possible.  On the other hand, LibGDX is said to feature a more low-level API, and I’m not against it.

About LibGDX

From what I used, it’s not that low-level, especially when using 2D graphics. Orthographic camera, sprite batch, fonts, texture atlas, 2d physics (from Box2D). It comes with a lot of well designed helpers, but it also allows you to directly mess with OpenGL objects. Also, updates are done often, and the support is really fast: a message in the forum and a patch is on its way. But the most important and useful feature relies in the possibility of (most) entirely developing the application with a Java desktop target! Desktop wrappers are totally hidden, and switching from such wrapper to an android one is as easy as adding one line of code. It let me develop my app with a fast renderer (a desktop window), without having to wait for the emulator to launch the app on every compilation. That’s an awesome feature for an awesome library! The only android-specific code in Pirate Compass is the one related to the preference screen and to the orientation computation from the sensors.

That’s for my first steps in the Android world. I’ll write articles with complete descriptions and tutorials for LibGDX users (since there is a lack of it). Until then, I have a real game in preparation, and will of course share work-in-progress ;-)

Stay tuned !