Mono and the Game Developers Conference

Last week some of us from the Mono team at Novell went to San Francisco for the Game Developers Conference. As some of my dear readers know, I was not much of a gamer a year ago, and I do not claim to understand this industry.

Mono is currently being used by a major publisher [1] to script a new version of a popular franchise (the new edition) and Mono is also the engine that drives Unity3D for scripting and SecondLife is beta testing Mono now on their beta grid.

Other than being fascinated by Unity3D and SecondLife, we had not really paid much attention to games. But in the last nine months we started to get a constant stream of requests to license the Mono runtime to power more and more games.

When Joseph Hill joined Novell in January as Mono's product manager we started to revisit some of these request. People wanted to get a proprietary license for Mono to use on the PlayStation, the XBox and the Wii and some folks also wanted Mono under non-LGPL terms (as it turns out, important to prevent cheating).

Three weeks before the GDC conference, our in-house expert on the game industry Michael Hutchinson told us that this conference existed. In a couple of days we booked some space on the show and we got things in place, we were going to promote Mono as an accelerated scripting engine.

Mono in Games

As it turns out, .NET-based tools and .NET-based scripting of tools are pervasive in the game industry.

As for the games themselves, engines are typically written in a combination of C++, C and assembly language and the high-level code is written with scripting languages. Lua is the most popular language to embed in a game (a procedural C-like language) and Python, variations on Lisp and a never ending stream of evolved batch languages.

People want to reuse Mono on games for a few different tasks. These are some of the reasons that we know about:

• Speed: as games become more complex, and people spend more money on software that takes advantage of GPUs, optimizing compilers and even special hardware for physics the weakest performance spot on a game has typically been the language that has been used to implement the high-level portions of the game.
  In a world that is increasingly green, it is a waste of perfectly healthy computer cycles to interpret your code when you can use an optimizing JIT compiler to run your code.
• Mainstream Language Support: In some cases, game companies have created their own languages, evolved or modified existing languages (modified versions of Lua are common). Some people would like to get access to more mainstream languages to develop their game logic.
  In the short term, jumping from procedural languages to object oriented languages is a first jump.
  Hopefully they will drink the functional kool-aid and use some of the C# functional features, or even F# to write their games.
• Code Sharing: C# or .NET code that is today written to run on servers, or as part of the tools being used to create games can now be easily be reused on the game itself.
• Mainstream Tool Support: Many games engines are already being developed with Visual Studio. Game developers can use the same tools to develop and debug the high-level game play scripts that they use to develop and debug the game engine.

Luckily, developers that have been writing Lua code for years will be happy to know that they can compile their Lua code to run on Mono (and get the performance boost they need) by using the Lua2IL compiler.

Update: The always great Lua developers have pointed out that the new thing is not Lua2IL but LuaCLR.

Mono and XNA

Mono does not really attempt to compete with Microsoft XNA

Microsoft's XNA is an end-to-end solution for game developers that want to create games for Windows, the XBox and the Zune, the XNA approach is to write manage code on *top* of XNA.

This works for certain kinds of games, but in the game developer space, some developers need to support more than one console and the high-end games (am sure there is a technical terms for these) end up licensing game engines, audio engines, graphics and physics from all kinds of middleware vendors.

In those cases (even when targeting the XBox) C# and .NET would not be available to the game developer.

So we basically think of the Mono runtime merely as a fast scripting engine with all of the ECMA/ISO CLI benefits and not really as providers of gaming APIs.

There has been some discussion in the #mono channel recently about whether we would create or endorse a gaming API developed by a third party. Like blessing Tao or OpenTK as the standard way of building games for Mono.

Although there is some value in having a blessed set of libraries for Mono, and I have no problem if people want to call their libraries Mono.Gaming, at this point the team at Novell is not able to dedicate any cycles to this effort (we can provide spiritual support, along the lines of yelling "Go team! Go" from the sidelines).

Intrinsics and Parallel Code

Am personally fascinated by running computational code on the GPU or taking advantage of special CPU instructions at the runtime level. Last year I wrote a bit about how we could implement this in Mono (Microsoft has already an implementation) and later we even made it part of our interviewing process.

At the conference some people asked as to whether it would be possible to take advantage of the PlayStation3 six SPE processors. During the conference I had no idea that there was already a project using Mono on the PS3 with Linux that already does this, but the idea sounded fascinating.

It is particularly fascinating because the SPEs on the PS3 do not have the same limitations than GPU computations have, these are full blown CPUs (with some memory limitations) but still general purpose computation devices.

Paolo pointed me to CellDotNet: A project to make it possible to run .NET code on the Cell architecture.. CellDotNet is basically a JIT compiler (written in entirely in C#) that can compile CIL bytecodes into native code for the PS3 SPE processors (this is a project from Klaus Hansen and Rasmus Halland).

They have ported the SciMark benchmark to use some vector operations in the SPE. Currently I am unable to report the numbers as I do not have a PS3 running Linux, but I am expensing a PS3 as we speak to be able to report these back to you dear readers.

What makes CellDotNet all the more interesting is combining C# new functional features with the the Parallel Extensions to .NET.

Two good articles to get a grasp on what this offers are: Optimize Managed Code For Multi-Core Machines and Parallel LINQ: Running Queries On Multi-Core Processors.

PLINQ is built on top of the Language Integrated Query (LINQ), and although it has been promoted mostly as a technology to do database queries, the Parallel LINQ extensions basically supports map/reduce inside C#.

These libraries are only available as a technology preview currently for .NET and they do not exist yet for Mono. Hopefully we will get these implemented at some point.

[1] Our contract with said major publisher does not allow me to disclose who they are or the the game they develop on my blog. But it allows Novell to publish the information on the Novell site. After a year of asking Novell people to put this information on the web site, the information has not yet been posted. So the mystery as to what this is will sadly continue.