Porting "Blocks That Matter" to Win/Mac/Linux news

Blocks That Matter is already available on Xbox Live Indie Games, so it was developed using C# language and Xna framework. Xna is a framework only running on Xbox or PC (windows only). All of these take advantage of the .NET Framework 4.0, a Microsoft technology.

Since we really want to consider Mac and Linux users, we decided to port the game to those platforms with a single version.
There were some choices to make. I came with 2 solutions, and will see what will give the best experience on the 3 platforms.

> The ‘easy’ way

Some dev friends (Garry, Marc and Elisée) pointed me out “Mono Game”.

> Presentation

Mono Game is a cross-platform port of the Xna Framework that uses Mono instead of the .NET Framework. So, what is Mono (quiclky)?

Mono is a cross-platform implementation of the .NET Framework (including compilers). It means that if you program using Mono, you will write exactly the same code that if you were using .NET Framework itself… but your code will run on all platforms Mono supports.

Mono only deals with .NET Class/Compiler/CLS, there is no binding for libraries useful to make games (like hardware accelerated rendering, audio, gamepad input, etc).

In order to have such libraries support, Mono Game use OpenTK. OpenTK allows a .NET (and Mono) wrapping of C libraries such as OpenGL (for rendering) and OpenAL (for audio).

> Why this is the easy way?

With the last complicated paragraph, you may wondering why the hell this is supposed to be the ‘easy’ way, because it involves a lot of frameworks and libraries so far! In fact all of those libraries help you to keep your originally written C# code, all you have to do is compile against those libraries,
the syntax of your code will be the same. Sexy isn’t it?

> What I got so far with Mono Game

The Mono Game actual port take me less than a week-end. I made some modifications on the Mono Game library (which is open source) to be able to run Blocks That Matter because the library didn’t handle XML file loading/parsing, no keyboard input (only touch screen support for iPhone/Android).

There is no audio support for now in Mono Game, you’ll have to write it by yourself by using OpenTK (thanks to OpenAL binding), and make some Xna classes implementation too.

Since the sound support was not crucial for a first test, I decided to give it a try with no sound support. Here is what I got in few hours:

The rendering is a bit ‘laggy’ and this is not entirely due to the Fraps capturing. Even without Fraps, I get some very bad frametime (more than 33ms, since our game loop threshold the deltatime, knowing that a 60fps game take 16ms to deal with a frame).

I must investigate to see where is the bottleneck… maybe it’s in Mono Game… or maybe it’s simply in Mono. I don’t think it’s in the game code since the game was running well with the Xna/C#/.Net implementation, even on my crappy Mac Mini (running on Windows).

> Pros Mono Game
- Easy to maintain all the version (console, Win, Mac, Linux) since it’s the same codebase
- Not really much code to provide for the game to run with Mono Game
- Not really a port, more an ‘emulation style running’

> Cons Mono Game
- Very bad performances for now
- Not so easy to deploy on Linux (many dependencies)
- Not really a port, more an ‘emulation style running’ -(yep, that’s a cons too)

Here is the ‘hard’ way, not the ‘real hard’ one. It consists of porting the game code in Java, including an equivalent of the Xna Framework, and the functionalities brought by the .Net Framework.

> The "hard" way

> Presentation

Java is a programming language and has the particularity to be thought to ease the multiplatform deploying since it rely on Virtual Machines to run a bytecode.

Since Java is not meant to display hardware accelerated stuff, neither to play complex audio effects, a special feature allows Java to use some C or C++ libraries. It’s called JNI, and with it, some libraries like OpenGL (rendering) or OpenAL (audio) can be wrapped and manipulated from Java code.

That’s what I use through a ready to use library called LWJGL. This library eases the creation of many things (create window, OpenGL context, etc) and wraps useful library gaming oriented.

> Why this is the ‘hard’ way?

It’s the ‘hard’ way mainly because you have to rewrite some code (sometimes a lot), because Java and C# do not act the same way. Hopefully the two languages got some similarities: they both use a
managed memory system, and propose a strong Object oriented programming.

Since C# is some kind of Microsoft response to Java, the two languages share the same DNA, and it’s not rare to see some troubling similarities in the classes from the Java Classes Library and .NET.
Here is a function that says if an upgrader can open or not when the player collects a new piece.

These codes are very similar, sometimes it’s worst than that. Let’s say it’s a regular porting case.

> What I got so far with Java

Every cinematics and levels are loading. The inputs (keyboard and gamepad) are handled, the sounds are not implemented yet. Here what I get after between 2 and 3 weeks of porting the thing:

As you can see, the framerate is much better than the one obtained with Mono Game (running on the same machine with the same capture tools for the same time). There are still some stuff that are not very well implemented (like the font that are all fucked up, and the tetrobot eye positioning).

As for the Mono Game version, I didn’t implemented the sounds yet (even if part of the code have been ported).

> Pros Java
- performances are here for this little game
- sometimes really near from C# in term of code syntax
- in browser applet could be envisaged (to promote a level, or a demo)
- deploying on various platform with the same performance results (see image below)

> Cons Java
- sometimes really far from C# in term of code syntax
- have to rewrite (or copy/past and adapt) a lot of code

> What would be the "real hard" way?

The real ‘hard way’ port would have been rewrite the whole game in C++. But this mean that the rewrite would have been longer than Java, since C++ has nothing to do with C# or Java (except they are all Object oriented languages).

> What's next?

I think I will concentrate my efforts on the Java version since it’s the one with the best performances and easier deploying. The next step for me is to get the sounds working. Then correct the
little bugs here and there, replace the placeholder font handling and make some Java optimization (because there is a room for optimization, my Java is quite rusty sometimes). And of course, including new functionalities for the PC versions.

Yep, that’s a lot of work! But you, PC gamers, deserve a decent version of the game too!
And I think we will need some volunteers to run a test sample on their machine (we already got some volunteers, but we will soon ask for more!).

See you next time!

Love.