Posts Tagged ‘update’

There is a new version of Vampire Runner available, we changed to use a custom solution to store high scores and removed OpenFeint from the game.

One reason for that change was, we were experiencing a long delay when OF dialog loaded for the first time, and we believe some players preferred to close the game instead waiting for the OF dialog to show up. We wanted a seamless system which doesn't damage the user experience in any way.

Another reason for removing OF was that we wanted to have best scores by day, week, month and we couldn't do that easily using OF.

Finally, we can use now the scores server in both PC and Android devices without having to make custom code for each platform, something not so good when using OF (could be great if they add a desktop backend).

Don't get us wrong, OpenFeint is a great solution, it gives a lot of features (scores, achievements, friends and more) and it is not so hard to integrate in your Android project (although the typical way is not so clean). However, for now, we prefer to use our custom solution for our simple and casual games.

Since Christmas happened long ago now, we decided to remove all related decoration and add new one, hope you like it.

Here is the list of changes of the update:

Removed OpenFeint, using custom solution for scores with support for today, weekly and monthly best scores.

Removed Christmas theme.

Added alert to show new updates available (for future versions).

Here is the QR-code if you want to easy access from your Android device:

Since the last update of Vampire Runner we were experiencing some notorious performance issues on the Android version and that is why we focused our efforts trying to improve it. The main problem was having some stuttering from time to time and some really bad fps on some devices.

We updated Vampire Runner in the Android Market with all the improvements we made:

Improved performance.

Improved graphics.

Removed the energy bar

Fixed the instructions texts to be clearer.

Here is the QR-code if you want to easy access from your Android device:

As we mentioned on a previous post, we were having some performance issues in Vampire Runner and we were trying different approaches to improve its performance.

Introduction

One limitation of Android when making games is you have to avoid generating garbage whenever you can since the garbage collection would generate pauses on your games and that leads to a bad user experience. Then, we should try to reuse already created object instead of creating new ones.

In Vampire Runner, one problem we were having was that we were creating a lot of entities at a specific moment of the game, when we detected a new obstacle should be created, and that was making some pauses on the Android version.

As we use Artemis, we should try to reuse some entities when we can. For example, if we make a shooting game (like the Jetpac prototype I made) it seems a good idea to reuse bullets since their life cycle is really short. Ziggy made two blog posts about this topic some weeks ago here and here, however we followed a slightly different approach and we will explain it in this post.

Storing entities to reuse them

We created a concept named Store (similar to LibGDX Pool class) which let us easily store objects, in this case entities of one kind (for example bullets).

free(T t) // returns an entity to the Store to be reused later
get() : t // returns an entity from the Store, it reuses an object from the free
collection if there is one or creates a new object otherwise.

The idea is to, for example, instead of creating a new bullet when a weapon is fired, calling store.get() and set the component values as they should be, and when the bullet collides with something call the store.free(e) instead of deleting the entity, so we can reuse it later.

This is a generic approach and we can use different stores to reuse different kind of entities but it has a big problem, those entities keep being in Artemis world, that means they keep being processed (collisions, render, etc). A basic solution to this problem was adding a new state to the entity, and we explain that in the following section.

Enabling and disabling Artemis entities

Artemis supports reuse of entities by internally caching created entities inside the World class, however their state (which components their have) is not easily reused, and that was one of the big problems when creating a new entity, we wanted to reuse their state.

Our current solution to the problem was adding a new state to the entities, if they are enabled or not. Being enabled means the entity is processed by all interested EntitySystems, being disabled means the entity is still in the Artemis world but it is not processed by any system.

So, in our customization of Artemis we added three new methods to Entity to be called whenever you want to enable or disable an entity:

disable() : disables an entity to avoid it to be processed on EntitySystems
enable() : enables again an entity to let it be processed on EntitySystems
isEnabled() : returns true if the entity is enabled, false otherwise.

Then, we added new methods to EntitySystem API to let each EntitySystem to be aware an entity of interest was enabled or disabled:

disabled(Entity e) : called whenever an entity of this EntitySystem was disabled
enabled(Entity e) : called whenever an entity of this EntitySystem was disabled

In our case, we are using them to enable and disable Box2D bodies in our PhysicsSystem, and also to remove them from our render layers in our RenderSystem.

As an example, we have a nice video of Vampire Runner we made by changing the zoom of the camera to see the behind the scenes:

As you can see, when entities like wall, fire and Christmas stuff are behind the main character, they disappear. That is because they are disabled and moved again to their stores so they stop being processed by Artemis, in particular, stop being rendered.

Conclusion

By combining both solutions, we have an easy way to reuse created entities of one kind, like our obstacles tiles in Vampire Runner, while at the same time we can disable them when they are on a store to avoid them being processed.

In case of Vampire Runner, this solution improved Vampire Runner performance since we now pre create a lot of entities we need during the game and then disable them and enable them only when needed, in this way, we could avoid creating a lot of entities in one update after the game was started.

This is a first approach solution to the problem and seems good for our current games but it may not fit other type of games or bigger games, we don't know that yet.

If you use Artemis and you had this problem too, hope this blog post is helpful to you.

Lately, animation4j API received some love by removing a lot of unused classes and improving a bit how things are used. Now both Transitions and Timelines (hence the animations based time lines) work over mutable objects only.

To illustrate some of the changes there are two examples shown in the next sections.

TransitionBuilder

TransitionBuilder changed its interface to create transitions specifying the object to be modified. It now also provides some methods which lets you specify the start and end values with a float[] by using var args, it is convenient if you want to write less code (you could avoid new Object(..)) but will generate garbage as new Object() does. The recommendation to avoid that is to reuse the end/start values, for example, if you want a Transition of a color from yellow to red, create the yellow and red colors and store them somewhere (maybe static final fields) and reuse them each time you need a new Transition.

Animations

This example shows how to create an Animation which uses a Timeline:

// using the same classes we defined before
MyObjectTypeConverter myObjectTypeConverter = new MyObjectTypeConverter();
MyObject myObject = new MyObject();
Animation animation = Builders.animation(Builders.timeline() //
.value(Builders.timelineValue(myObject, myObjectTypeConverter) //
.keyFrame(0f, new MyObject(50, 50)) // at the beginning of the Timeline, the object should be at 50, 50
.keyFrame(2f, new MyObject(100, 100)) // two seconds after that, it should be at 100, 100
.keyFrame(10f, new MyObject(200, 200)) // eight seconds after that, it should be at 200, 200
)) //
.speed(2f) // we want the animation to run at double speed
.build();
animation.start(1); // starts the animation with 1 iteration.
animation.update(1f);
// this should print 100,100 since the update we asked for double speed.
System.out.println("" + myObject.a + "," + myObject.b);
animation.update(4f);
// this should print 200,200
System.out.println("" + myObject.a + "," + myObject.b);

(note: if you want more examples, there is an examples project with the project, some of the examples needs to be simplified but the idea of how to used animations and transitions should be clear enough)

Animation interface is very rich, it has methods to start the animation specifying the iterations you want, if you want to alternate directions or not, etc.

Immutable Objects

As I said before, animations and transitions can only be performed over mutable objects. This means you can't animate a java.lang.Float or a java.awt.Color since you have no way to change their values without creating a new instance. To animate immutable objects the idea is to create your own mutable objects with the corresponding variables, animate them and then, when needed, create a new instance of the required immutable object using the values of the mutable instance, for example, new java.awt.Color(values).

Conclusion

All the changes were made to improve performance and reduce garbage generation, mainly because we are using the project on our Android games. The changes also improve the usability of the library since they reduce a lot of noise and reduce what you need to use. For example, all the modules slick2d, java2d and componentsengine were removed from the project since they had unused code and they depended on libraries that aren't on maven central.

I wanted to share a bit the changes but, as things keep changing, for now all this stuff is on an unstable 0.2.0-SNAPSHOT version and wasn't released on maven central yet.

On the last weeks I was a bit distracted working on Vampire Runner and with Mad Jetpack so I ended up kinda leaving Super Flying Thing abandoned, I also have some doubts about which features to work on so I preferred to dedicate time on other projects while deciding what to do with the game.

Super Flying Thing is really fun to me, I love the concept but right now the game could be a bit boring and I want to improve that, not so sure how, but I want to try some ideas I have in mind.

About levels

The main idea of the game is you have to master your flying skills and for that you have to try and fail a lot of times. For that reason, I want to modify the levels to be smaller and harder but not frustrating since you can quickly try again and again.

Random levels are now generated using pre generated tiles (I want to talk about this in a dedicated post), so they are a bit more interesting, however they don't transmit the idea of try and fail a lot of times yet, so I have to work a bit on level generation.

About game modes

The practice mode will be removed since you can practice in both challenge and random modes. However, for starters I want to add a Tutorial where you can test the controls and learn how to play to mitigate the change I plan to do over the levels.

Also, we want to try an Endless mode where you have to go as far as you can, playing through different challenges each time harder and harder.

About content

On some levels there are lasers, moving obstacles and even portals. Despite I love all this stuff, I will probably remove them until I see how they really fit in the game.

Stars will be probably removed as well since they don't contribute nothing to the game for now. Again, this will be probably temporary until it fits in the game.

About game objective

On normal game mode, the main objective will remain the same, travel from one planet to the other. However, I want to add a second objective to add challenge factor to the game, something to make the player want to try again the same level several times. One possibility is to add some kind of local competition, for example, improve the time to reach the destination planet, play against your best time, or something like this. Going further with that possibility, maybe publish that replay/best score online and compete with others.

We have to dig further in this subject since it can contribute with re playability factor.

About controls

Now that we fixed the game behaving different on different devices I will rip off the AxisController and the TiltController and probably one more, and leave only the original one plus maybe some other.

The original control was modified a bit in order to let the player control the ship better based on how new levels are going to be.

Conclusion

That's all for now, the idea of this post is to let you know that I want to to continue this game.

As introduced earlier, Vampire Runner is a Canabalt like game where you have to run as far as you can, in this case as you are a Vampire you have to run from the sun light.

Here are some game screenshots:

For now the game has some issues with of text location on small screen devices, I didn't want to scale everything because fonts look bad when scaling them but could be the only way of making things screen independent.