Archive for December, 2011

Simulating parallax scrolling for 2d game

Saturday, December 24th, 2011

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.

As always, hope you like the post.

VN:F [1.9.22_1171]
Rating: 3.0/5 (2 votes cast)

Leave me Alone!!, my game for Ludum Dare 22

Monday, December 19th, 2011

To continue with tradition, I made a game for Ludum Dare 22. In this case, the theme was "alone", and I made a game named Leave me alone!! (sadly, it seems like there are 3 or more games named that way).

I had little time to spend making the game so I targeted a simple game with almost no graphics nor sounds but fun.

The story behind the game is, you have to isolate a particle from other particles to keep the world safe, if they make contact then the world explodes in a mega hyper super duper explosion (use your imagination).

Here is a screenshot:

I recorded the timelapse but it was really boring so this time I will not upload it, however, I made a gameplay video:

I will be happy if you can play it, and rate it (if you participated ludum dare), and love it ;)

Enjoy it.

VN:F [1.9.22_1171]
Rating: 4.0/5 (1 vote cast)

Vampire Runner Christmas Edition on Android Market

Friday, December 16th, 2011

We wanted to make something special for our most successful game and our players so we added some Christmas happiness to Vampire Runner:

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.
  • Created Vampire Runners Facebook Page and added a button to go there from the Credits Screen.

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


Vampire Runner Android Market Vampire Runner Icon

Android Market

If you installed and liked the game, please rate it on the market, and share it with your friends and everyone you know.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Vampire Runner version 1.0.0 on Android Market

Tuesday, December 6th, 2011

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:


Vampire Runner Android Market

Android Market

The game changed a lot from what it was, hope you enjoy the changes.

If you installed and liked the game, please rate it on the market, and share it with your friends and everyone you know.

VN:F [1.9.22_1171]
Rating: 4.2/5 (5 votes cast)

Resizable Applets and Applications with LWJGL

Thursday, December 1st, 2011

Some posts before, in the comments section, Gornova asked me to write about resizable Applets if I had some time. As I never used resizable LWJGL Applets, I had to do some research. This post is to show what I found.

(note: LWJGL version 2.8.2 was used for all the tests I made).

Introduction

LWJGL Applets are similar to LWJGL Applications, they work using a class named Display which uses an AWT Canvas component. On desktop, you create a JFrame or similar and add inside a Canvas, on Applet you just create the Canvas and add it to the Applet. Unless you want some custom behavior, I believe that is the common usage.

(note: using fullscreen is a different case but has no meaning for this post)

How to resize an Applet

To resize an Applet on the browser, two possible ways are, use Javascript to change the applet tag sizes or just configure the HTML applet tag to adapt to its container size, so if you resize the browser window then all corresponding HTML components are resized.

The other way around, suppose you have a way inside your game to choose the game resolution, you will have to communicate that to the Browser, probably calling a Javascript function from your Applet to let the Browser react to the change.

How to handle Applet resize

If you are working with LWJGL directly, then it depends a lot of how which kind of layout are you using for the container of the Canvas object. For example, if you chose a layout which grows to the parent container size, then each time you resize the container, the Canvas will be resized. If you chose another layout, then maybe you will call Canvas.setSize() by hand.

However, you need to react to that change in your game, to do that the best way (imho) is use a similar approach LibGDX does. What LibGDX does is, its stores the current Canvas size on each iteration of the main application loop, on the next iteration, if the Canvas size is different to the stored, then it calls a resize() method to tell your game the screen size changed.

Another way is to create a ComponentListener and add that to the Canvas component so each time the componentResized() method is called you resize your game. However as all the AWT stuff runs in another thread you need to store the new size and process the resize in your LWJGL thread to avoid problems.

What to do inside your game

The very basic approach is to just modify the OpenGL viewport of your game, then the game is scaled to the new size and, in some cases, that should be enough.

	glViewport(0, 0, width, height);

However, You may want to take care about aspect ratio since just scaling the game could look ugly. One option is to modify the viewport in values to maintain the aspect ratio you want, for example:

	glViewport(0, 0, width, width / aspectRatio);

You could also provide different common aspect ratios (4:3, 16:10, 16:9, etc). However, I believe the best option is to provide fixed commonly used resolutions like 640x480 or 800x600 instead.

In some cases you could want to adapt your game elements, for example GUI stuff, where you may want to maintain the element sizes and move them accordingly over the screen instead just scaling them.

Then, you have to take care of the user input. As mouse location is dependent on the viewport size, you will have to take that in mind when interacting with part of your application, like the GUI stuff, after a size change. For example, LibGDX Camera uses the current viewport size when using project and unproject methods (which allow you to transform world coordinates to viewport coordinates and vice versa).

Not so sure as I am not an OpenGL expert but if you work different cameras (model + projection matrices) you probably need to update them in order to render everything in the correct way. I have to go deeper in this issue.

Optionally, you may want make other changes when reacting to the resize like loading HD assets if you go to a higher resolution and vice versa.

Some issues

  • You have some glitches if you do resize in real time (tested myself, but cant find references right now). However, in general nobody does this so it is not a big problem.
  • I believe Applet resizing is not working on mac yet.

Conclusion

Handling all the mentioned things when resizing LWJGL Applets and LWJGL Applications depends a lot on the game you are making, in some cases the basic approach work fine and should be easy to implement.

Despite the article was focused mainly on LWJGL Applets, great part of the findings can be applied to LWJGL Applications as well.

This post is only to show some basic experimentation I made on the subject, as I said before, I am not an OpenGL nor LWJGL expert, so some assertions could be wrong. If you have more experience and want to contribute your opinion, feel free to do it.

Thanks and hope you like the post.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)