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.
As we were having some performance issues with Vampire Runner and we didn’t have a clear idea of what was happening, we started trying some improvement techniques. The first one we implemented was a basic frustum culling technique to avoid trying to render objects outside of the screen.
Basic implementation
First, we created an Artemis component named FrustumCullingComponent with a Rectangle representing the bounds of that entity to easily detect if the entity is inside the screen or not. For now, as it is a basic implementation, the rectangle was only modified when the entity was created. So, for example, if we know an entity was able to rotate during the game, then we create a bigger bounding box using box diagonal.
Then, we added a method to our custom 2d Camera implementation to get the camera frustum (by making the corresponding transformations).
Finally, we modified our Artemis render system to check before rendering if an entity has or not a FrustumCullingComponent, if it hasn’t one, then we perform the render logic as we always did. If it has one, then we check if the bounds of that entity overlaps with the camera frustum, if it does, then we render as we always did, if it doesn’t, then we avoid rendering that entity.
Here is an example of the bounds and the frustum of the camera:
In the image, the element (a) and (b) are rendered because their bounds overlaps with the camera frustum. The element (c) is not rendered because its bounds are totally outside the camera frustum.
Conclusion
For Vampire Runner, we didn’t notice the difference of having this technique enabled or not since the game always render fast (on our devices) and we had no metrics of the render process time. However, as it was really easy to implement this basic version of the technique, we believe it should help to maintain render performance, and we can reuse the logic for all of our games.
In this post we want to share how we simulated parallax scrolling in Vampire Runner, a simple technique that could be used in any 2d game.
Introduction
The basic idea to simulate parallax is to work with different render layers and to move them at different speeds.
To easily understand the post, we will work with a basic example based on Vampire Runner graphics where we have three layers, the first layer is the background which is static, the second layer are the mountains and the third layer is the world layer where the main character runs.
In Vampire Runner, the main character is the center of the world, despite being running, he is in a fixed position on the screen while all the other objects move accordingly to give the correct idea.
To simulate the parallax, each layer of objects moves at different speeds to give the correct idea of depth. In case of Vampire Runner, the background layer is static, the mountains layer moves at 1/12 the speed of the main character and the world layer moves at the speed of the main character.
Simulating movement with cameras
We said before that the character is in a fixed position on the screen, however the real entity of the character is moving around the world, even more, he is running!.
To simulate him being in a fixed position, we have a camera following the character, so the player always see the character in the same position.
However, as all the other objects (obstacles, trees, etc) have a fixed position in the world when the camera follows the main character they move in the opposite direction. That is how we move the world layer and the mountains layer. The only difference is we move the mountains layer camera slower.
In conclusion, we have one camera for each layer and two of them move following the main character.
Using OpenGL model view matrices to configure the cameras
As we are using OpenGL through LibGDX (and LWJGL on desktop), we need to translate all the previous camera behavior to OpenGL.
In OpenGL, to simulate a world camera what you typically modify the model view matrix and then render the objects.
So, for Vampire Runner, we had three different matrices to render each layer, and the render method was something like this:
1.1 configure background layer camera
1.2 render background layer
2.1 configure mountains layer camera
2.2 render mountains layer
3.1 configure world layer camera
3.2 render world layer
In the update method we only had to update the cameras depending on the character position.
To simplify the work, if you are using LibGDX, you can use the Camera class which comes with a proper class for 2d games named OrthographicCamera. In our case we used a custom implementation which provided a nicer API to work with.
Conclusion
Working with different cameras with OpenGL is not so hard and it let you achieve a correct feeling when moving across the world.
We wanted to make something special for our most successful game and our players so we added some Christmas happiness to Vampire Runner:
The changes for this version were:
Christmas Theme – Presents, Trees, Christmas Hats, and Snow.
Musics are disabled the first time you run the game, to avoid a bug between OpenFeint dialog and LibGDX (you can enable the music in the main menu screen).
For the Android Version – We now support paging on our highscore screen so you can see more scores.
We were working hard to make a new release of Vampire Runner with some big changes.
Mainly, all graphics assets were remade by Estudio Egg, so the game looks tons of times nicer now. Take a look:
Then, we also improved game mechanics by adding different transformations to the vampire to move through different obstacles, so the game is a bit more interesting now.
Finally, if you play the game on Android, we also added OpenFeint integration, so if you already use OpenFeint with friends, you can compete with them to be the best Vampire Runner.
Here is the QR-code if you want to easy access from your Android device:
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.
Vampire Runner was #290, not so good as other of our previous Ludum Dare games, but on the other hand there was a lot of games in this one, almost three times the games of the previous Ludum Dares.
Here are the scores Vampire Runner got in this Ludum Dare:
Position Category Score
#87 Community 3.22
#144 Coolness 4%
#159 Fun 2.94
#168 Humor 2.18
#290 Overall 2.75
#305 Graphics 2.50
#339 Audio 1.29
#345 Innovation 2.38
#450 Theme 2.00
Now, I want to share a small post mortem of the game and explain why I feel the score is what I expected.
What went wrong
As the game started like some kind of Canabalt clone, because my lack of imagination, I was a bit unmotivated so Saturday progress was really slow and unproductive.
I feel I lost too much time making the vampire animations and forgot about the environment assets.
The game lack of audio and that goes against the Ludum Dare score.
I forgot to reflect inside the game the connection with Ludum Dare’s theme.
Missing on-line high scores: it shouldn’t be so hard to add it as I have Face Hunt (and other games) experience but I was a bit lazy and didn’t. One reason to have this one is to make the game more competitive and also to know who is playing the game.
What went right
On Sunday, I almost restarted the way I was making the game and focused on making it really small and fun. It kinda worked.
Making the game available on a lot of platforms: Linux, Mac, Windows and Android.
Conclusion
I totally agree with the score of the game because I started with no motivation and for that reason I didn’t tried so hard, obviously that goes against making a good game. Here is a list of why I agree or not with each score.
Community: I shared a lot of stuff: source code, timelapse, made it work on multiple platforms. I believe that counts as community rating, so 3.22 is right for me.
Fun: Game IS fun (at least I feel that and some other people does), so 2.94 is right for me (maybe a bit more).
Humor: Game has a bit of humor when the vampire explodes, and maybe the vampire graphics are funny too, but only that, so 2.18 is right for me (even more than I expected).
Graphics: Only the vampire animation is something worth to value here, the background and obstacles are not so cool, so 2.50 is around what I expected.
Audio: Game has no audio, I am not agree with the score of 1.29.
Innovation: Game is almost a clone of Canabalt with some modifications, it has a bit of innovation but not too much, so I agree with a score of 2.38.
Theme: If you read the game description, it says what was the intention of the theme connection but as I failed to reflect that inside the game I believe 2.00 is right for me.
