25 Feb

RenPy: Games, Rationale and The Power of a Well-Crafted Engine

More than 1 year after releasing NagiQ, I’d like to share a few bits of our experience with NagiQ, and of course, with the engine we used to build it: RenPy. First, we want to express our gratitude to RenPy’s author, PyTom, and to all of the RenPy contributors, including the kind people of the RenPy forums, who are always ready to provide useful feedback and answer our questions.

RenPy is a wonderful engine. What I like the most about RenPy is its robustness and cross-platform wonders. It feels like it might run anywhere and without ever crumbling. In fact, we released NagiQ for Windows, Mac and Linux, and deployment was incredibly easy: RenPy smoothly abstracted the differences among operating systems, and the game runs and behaves exactly the same way on all these 3 platforms. Besides, I think that several games built with RenPy have found their way into Steam and Google Play. I especially recommend RenPy for people creating its first game (NagiQ, developed in 2011, was our first title), because RenPy allows you to focus on what really matters for your game (gameplay, spaces, visuals and story.) As suggested, abstraction is a key concept for RenPy: abstraction is everywhere, it’s high-level and indeed powerful. For instance, right now I’m thinking of RenPy’s ATL, which is a very powerful way for showing displayables and applying several visual transformations (rotation, zoom, etc.) to them. And that’s sweet, really sweet. More so if you’re submitting games to publishers for the first time.

I don’t know of an engine better than RenPy for creating visual novels, and generally speaking, games in which pairs (image, text) are first-class citizens for scene design. NagiQ isn’t a visual novel, but a word game. As a word game, NagiQ is mostly based on simple images and strings. Handling images and strings with RenPy is a breeze. And not just strings. In RenPy you can show images and play music with a single line of code. A single line. You work fast, and you work safe. Further on, you might apply a tiny bit of ATL for achieving a richer presentation.

As RenPy is open-source, you can browse and study its code. You’ll end up learning quite a lot. Furthermore, knowing how things are done internally will allow you to find pathways for implementing any specific feature you might need. For example, several publishers require special handling of the quit message (Alt+F4 on Windows, CMD+Q on Mac OS X.) By knowing RenPy internals you’ll be able to handle this message as needed.

Overall, organizing your game’s scenes in RenPy is pretty straightforward. And you can even use neat transitions between scenes with a single line of code too. Normally, you’ll want a splash scene, a main menu scene, a level selection scene, and of course, the scenes implementing your main gameplay. Several of these scenes might require a lot of UI components whose creation is a piece of cake with RenPy. You’ll have the valuable help of Screens and Screen Language, which will simplify implementation and handling of your game’s screens.

RenPy is extensible. For the levels of NagiQ we required boards made of clickable cells. For doing that, we created a custom Board class in Python. And, again, RenPy proved golden: you can extend RenPy as you wish. We coded our Python class and integrated it to a RenPy scene pretty easily.

Summarizing, RenPy promotes creativity. It’s a very flexible and dynamic system, which doesn’t impose tight restrictions on the way you show and structure your content. The powerful ATL and the Screen Language are dreamy features, an outstanding support for unbounded creativity.

In retrospective, RenPy was indeed the best choice for building NagiQ: it was such a fun experience. And that’s what really matters. Long life to RenPy.

21 Feb

A few remarks on LWJGL for OS X and LibGDX

This little post is an answer to a comment in Hacking LWJGL, LibGDX and The Rainbow Machine. By the way, please note that the workarounds discussed on such post are not needed anymore, as LWJGL team has fixed the reported issues.

Warning

LWJGL for Mac OS X (using Java 7) is still labeled as experimental. It might contain bugs. As of this writing, there is no official release yet. Thereby, please be very careful if you’re planning to use this experimental branch, and test your game thoroughly. Read this thread to understand what’s the current status of this branch.

Where to get the experimental build for LWJGL?

In the above referred thread you can find the germane links.

Using this experimental branch with LibGDX

Download the experimental branch of LWJGL as explained above. Use the latest binaries, or build it from sources. Now there are several ways to update your LibGDX. What I recommend is to download the sources of the latest version of LibGDX and build it. Before building, update these files:

lwjgl.jar located in libgdx/backends/gdx-openal/libs/
gdx-backend-lwjgl-natives.jar located in libgdx/backends/gdx-backend-lwjgl/libs/

That should suffice. Remember, though, it’s an experimental branch. It might contain bugs.

05 Feb

Hacking LWJGL, LibGDX and The Rainbow Machine

For a couple days I’ve been busy browsing and modifying source code. The best part of this work is that I’ve learned quite a lot by reading the internals of LWJGL and LibGDX: the authors of such libraries are really clever people. And definitively, the good design in these libraries makes them easier to understand. What I’ve been up to lately is porting The Rainbow Machine to Mac OS X, but using Java 7. The problem: LibGDX is based on LWJGL (for Desktop versions), and LWJGL was not working on Mac OS X with Java 7. However, the LWJGL gurus are already working on an experimental branch which has made great progress. It’s still labeled as experimental, though. I downloaded that version of LWJGL, compiled it, and updated my version of LibGDX. So far, so good. Now, time to change The Rainbow Machine project. I replaced my “official” LibGDX libraries with the ones I had just compiled… and after that the game refused to run.

Further tests showed that LibGDX was getting locked in Display initialization. This lock can be prevented if we ensure that AL.create() is called after Display initializaton. This is a LWJGL thing, because the following simple LWJGL program won’t run either:

public class Main {
  public void start() {
        // AUDIO INIT
        try{
            AL.create();
        } catch (LWJGLException le) {
            le.printStackTrace();
            System.exit(0);
        }
        // END AUDIO INIT

        // DISPLAY INIT
        try {
            Display.setDisplayMode(new DisplayMode(800,600));
            Display.create();
        } catch (LWJGLException e) {
            e.printStackTrace();
            System.exit(0);
        }
        // END DISPLAY INIT

        Display.destroy();
    }

    public static void main(String[] argv) {
        Main m = new Main();
        m.start();
    }
}

There is a clear workaround: swap audio and video initializations. I did the germane modifications in LibGDX (I changed LwjglApplication.java), et voilà, the game runs nicely.

Then I kept playing for a while and did not notice any issues until I decided to close the game by pressing CMD-Q: the game was immediately killed, and that’s not the desired behavior. I want The Rainbow Machine intercepting CMD-Q and behaving as if the red X close button was clicked. In fact, closing the game by means of the menu has a similar effect to CMD-Q. After reviewing LWJGL and the Java source code, I found a simple workaround. I was expecting windowShouldClose in org_lwjgl_opengl_Display.m to be called whenever CMD-Q was pressed. However, windowShouldClose is only called when the window is going to be closed. The window, not the app. If I close the app by clicking on the red X close button, windowShouldClose is indeed invoked. But CMD-Q does not trigger it.

Then I took a look at QuitStrategy, and set it to CLOSE_ALL_WINDOWS (the default action being SYSTEM_EXIT_0… that’s how the app responds, a direct exit(0).) However, modifying QuitStrategy had an unexpected outcome: CMD-Q stopped working, i.e., now the game would not close by pressing CMD-Q. A quick glimpse at Java’s source code revealed that Java dispatches a WINDOW_CLOSING event to the Frames of the game. It seems our game does not receive such notification, or I have yet to learn how to capture it. Thereby, I defined my own QuitHandler in createWindow (file MacOSXDisplay.java):

Application.getApplication().setQuitHandler(new QuitHandler() {
  @Override
  public void handleQuitRequestWith(QuitEvent event, QuitResponse response) {
    response.cancelQuit();
    doHandleQuit();
  }
});

This handler simply cancels the game quit, and notifies MacOSXDisplay’s handler about the quit request. And that’s it. The discussion on this widely popular thread revealed that the LWJGL team was thinking of using CMD-Q for effectively killing apps immediately, as an option to kill a crashed LWJGL app (for instance, to avoid mandatory full reboots for crashed fullscreen apps.) However, they’ve noticed that holding CMD-Shift-Option-Esc for 3 seconds kills the app too. Therefore, CMD-Q won’t have to kill the app.

In the following days I’ll keep testing The Rainbow Machine. However, of course I’ll be waiting for a non-experimental release of LWJGL on Mac OS X. Specifically, I’d rather not to modify LibGDX: that’s a philosophical issue, suitable to internal workflow here in IKIGames. BTW, if you liked this post you migth want to follow us on twitter.