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.

04 Jan

Happy New Year!

Happy New Year everyone! We wish you a happy, healthy and prosperous new year! Our best wishes to all! 2012 was such a great year for @superikigames. Our first game, NagiQ, reached more than 100 distribution channels worldwide! And our second title, The Rainbow Machine, was also released in 2012. Oh, and we also changed our web site from the ground up 🙂

This year we’re planning to release the following:

  • iOS and HTML5 versions of The Rainbow Machine
  • Translations of the android version of The Rainbow Machine into French and Spanish
  • NagiQ 2

That’s a ton of work! So we’d better start working right now! Again, happy new year 2013! See you on Twitter, FB and Google+.

27 Nov

Coming soon: revamped website

Hello everybody! We’re working on a new desing for the website, including an improved portfolio and further integration with social networks. The new website should be active this december. Stay tuned!

P.S. For the time being, you might want to follow us on twitter (@superikigames).

25 Jul

New Project: T3C

After completing NagiQ, we’re embarking on the development of a brand-new game, whose prototype is codenamed T3C. This will be a game for mobile devices, fun and educational. Our project planning estimates up to 14 months for completion of T3C. Stay tuned!

02 Jul

NagiQ released!

Thinking of words, connecting them, conquering tiles, having fun! NagiQ is our newest project, a family-friendly word game suited for brain fitness. NagiQ is full of cartoon graphics and challenging levels. Here are a few screenshots of the game:

For more information about this new game, please take a look at NagiQ’s page.

28 Jun

Pedagogical Approach for Educative Games

Recently, we’ve been reviewing our design guidelines for educative games. Regarding this matter, we’ve decided that our approach for creating educative games should be based on the following aspects:

  1. Pedagogical Approach: This comprises aspects such as the pedagogical philosophy of the application, the user’s motivation, and the employment of multimedia resources according with the pedagogical philosophy and the topics developed.
  2. Content: It’s related to the information presented by the game, and also the goals of the project.
  3. Language, Grammar & Style: This aspect covers all the things related to grammar, ortography, definitions, localization and format.
  4. Aesthetics and presentation: It includes all the details related with the application’s aesthetics, the way content is organized and displayed, and the user interface.
  5. Evaluation: It refers to the mechanisms employed by the application in order to verify the learning results.
  6. Internal Aspects of the System: It comprises all the functions invisible for the user, related to security, data backup, fault-tolerance, among other internal aspects.

The approach must strive for fast and high-quality software deliveries, balancing speed, quality and price. Software requirements and goals are a very volatile matter, and as such, we must structure our work in order to cope with our clients’ new expectations, i.e., we’ll be following a highly dynamical software development approach.