Geeks With Blogs
Chris Howe

Most developers these days have moved on from C++ and its lower-level cousins. Higher-level languages are now the norm, including Java, Python, Ruby and C#. Developers have adopted these languages because of the productivity gains that are enabled by working in a higher-level language. Garbage collection frees a programmer from worrying about several common classes of bug. These languages also stress expressiveness over performance, meaning that you have to do less work to get the results that you need.

Games programming can be split neatly into two halves. There is games coding, which involves all the runtime components of the actual game, such as 3D rendering, physics and AI. Then there is tools coding, which is everything else. This commonly includes level editors, DCC plugins and backend data-processing tools.

In games development we have seen widespread adoption of .Net (and C# specifically) for tools coding, but for game coding C++ is almost the only choice. There are certain barriers to using anything other than C++ for game coding. Game coders typically have to worry about performance to a much larger extent than their tools coding colleagues. While it is true that most of the game code does not need to be optimal, there is still that 10% that does (this varies greatly depending on the specific game and the target hardware of course). The other barrier is portability. C++ is the only language that is supported on every major gaming platform, so if you are making a cross-platform game it is your only choice.

Games do make use of higher-level languages for scripting game logic, but typically this is limited to high-level game logic. Languages commonly used for scripting in games include Lua, Python and UnrealScript. If scripting is limited to a small portion of the overall code base then the productivity gains are also very limited. The gains are even further reduced by a couple of other factors. Since the use of scripting is limited there isn't much effort put into making debugging easy. Generally print statement debugging is the most you can hope for. Even some of the biggest, most-used game engines around suffer greatly from this. Since the scripting is limited to simple game logic it is often given to the designers, who won't be able to fully leverage the benefits of the language (I apologize to those rare designers who are comfortable writing code).

The use of scripting is so limited purely because it is terribly slow. If the scripts were faster then we could think about implementing more functionality in the scripts rather than in C++. Then it would become more profitable to work on proper debugging tools, which further increases productivity.

In non-games development there is a solution for this problem called Just-In-Time (JIT) compilation. Put simply, the scripts are converted to native code at runtime. So instead of parsing text or interpreting bytecode we are running actual native code.

So how do we get JIT technology into games? Since C++ is still the only language supported on every gaming platform we will have to embed a JIT scripting engine into our C++ application. There are several choices here (e.g., LuaJIT for JIT Lua scripting), but the one we are going to focus on is Mono.

Mono has the benefit of supporting several languages. Indeed any language that can be converted into CIL (Common Intermediate Language) format, can be supported by Mono. Mono currently supports C#, VB, Boo (a Python derivative) and Lua (via Lua2Il) among others. This means that we can choose our language based on the task at hand, and we can even mix several languages within the same program. Mono also has the benefit of having been ported to several different platforms, including the Wii and PS3.

If we can embed the Mono scripting engine into a game engine then we should be able to move a great deal of the game code into higher-level languages. Indeed it is feasible that most of the game could be written in a Mono language, just calling into C++ libraries where neccessary for rendering, physics, etc. This would look very similar to XNA, which is a C# platform for game creation that provides libraries to handle the lower-level tasks such as rendering.

I am currently investigating this scheme and I'm going to write about it more when I actually have some results to show. One of the key things that I want to investigate is the extent to which debugging is possible.

Posted on Thursday, August 6, 2009 8:56 PM | Back to top


Comments on this post: An argument for Mono in games

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © ChrisHowe | Powered by: GeeksWithBlogs.net