Three years ago, we were almost laughed out of the Game
Developer Conference Show floor.

C# as the heir to C++ back then was mostly an academic
discussion. And there were only a few anecdotal examples of
developers using C# for fast and safe scripting in games such
as Second Life and Unity.

Three years ago, C# as a scripting language for games had
shared the reputation that Javascript had before the Ajax
and Web 2.0 revolutions. It was a bad word. Anything short
of C++ and assembly language was not up to the taste of most
game developers. Ironically, developers were willing to
take the hit of an interpreted languages to drive their
games.

It was perhaps Unity Technologies that started to change
this when they adopted Mono as their scripting engine, giving
their developers a choice of C#, strongly typed Javascript and
Boo as programming languages to author their game's logic,
effects and behaviors. They got the benefits of high-level
languages, with the added performance of being compiled:

A New Generation of Game Developers

In the past years, a new generation of game developers have
entered the stage. These are developers that have cut their
teeth with Unity, XNA and frameworks like PyGame.

They value malleability, rapid iteration and safe
environments without crashing over raw performance. They have
grown used to profiling their software and tuning the
hot-spots instead of depending on hunches that lead to
premature optimizing.

This year things were very different at our booth. Lots
of happy Unity users came by to talk about MonoDevelop, about
the new soft debugger, and about the joy of using C# to build
applications with Unity. Lots of people are working on big
and small game titles using Mono.

MonoTouch and MonoDroid also helped us gain visibility in
this space. Lots of existing users, and users-to-be came to
discuss Mono's state.

But Mono has now spread its wings from being a pure
extension system for C++-based systems (like Unity or the
Sims3), to be used as the main language for building game
engines and game frameworks.

There is the
2D MonoGame (an
open source effort previously known as XNAtouch) which
supports iPhone, Android (and they are working on Windows and
Mac backends).

At the show,
both DeltaEngine
and Silicon
Studio were showing pure C#-based 3D game engines powered
by Mono. There were as well a number of stealth-mode
projects and startups using Mono either as their scripting
engine or the main runtime.

Walking around the GDC show-floor, you could see Mono
running in many booths thanks to Unity's overwhelming
popularity.

Perhaps my favorite Unity game at the show was Rochard, an
upcoming PS3 game with interesting puzzles and the level of
polish that you expect from a game like Ratchet and Clank
(videos,
screenshots).

Helping Game Developers

In the past couple of years we have made some changes to
Mono that help developers use Mono as either a scripting
system for an existing C or C++ code base, or for those using
Mono as their main runtime.

We still deliver all the bonus features that come from
using C# and the CLI, like lambda functions, functional
style-programming, garbage collection, type safety, iterators,
generics and improve upon the basics to include:

Mobile profile: a minimal profile of class
libraries that is better suited for mobile, embedded
and console uses.

LLVM-based code optimizer: in addition to our
standard code generator designed for JIT compilation,
we now offer developers a choice to use
the LLVM optimizing
compiler to generate code. Modulo a handful of
issues, the code generated is as good as the one you
would get by doing low-level programming with C++.

SIMD
intrinsics: we treat the
various Vector
data types in the Mono.Simd namespace as
first-class types recognized by the JIT and mapped
directly to hardware supported SIMD operations:

Unsafe execution: some of our users wanted to
continue using Mono and C# for their code for compute
intensive operations. We now offer an unsafe
option that will remove all arrays bounds check from
the code. This, needless to say, is incredibly unsafe
as it would open the doors to the sort of bugs that
are common in C++. But if you are dying to squeeze
the last bit of performance and treat C# as a nicer
C++ and are ready to make a commitment to debug
memory-corruption bugs, we got you covered.

Runtime
Continuations: to create lightweight co-routines
that are not bound to threads and allow developers to
suspend execution at any point without having to
change their code, or require new compilers. Silicon
Studio's Homei system uses it.

Additionally, many developers are doing a little bit of
embrace-and-extending the Mono runtime in creative ways to
extend the CLI in new ways.

We want for example to introduce both a [ForceInline] and a
[UnsafeCode] attributes that can be applied to methods to hint
the code generation engine to always inline a method, and to
remove arrays-bounds-checking on a per-method basis.

Hot Topics

A hot topic at the GDC was when we would bring the
new C#
5 "await" feature to Mono.

C# Await is beautiful in that it integrates directly into
the language and allows developers to focus on the algorithm
and not in the administrivia of suspending execution and the
boilerplate involved.

Which leads me to F#. The C# await functionality is
based
on F#'s
Asynchronous Workflows which is available to everyone
(thanks to Microsoft open sourcing the F# compiler and
runtime).

What is fascinating is what some people are doing with F# in
games: they can use F# to express the game AI in more succinct
terms than any other scripting language can do. Not being a
game designer, I do not quite understand the domain space, but
apparently F# is just what the doctor ordered for complicated
AI behaviors.

This coupled with async execution is a game engine
developer's dream. But F# is not for everyone, there is a
learning curve for getting to express problems in F# that is
not suitable for game developers that have simple needs for
their in-game logic.

WPF: A Recurring Topic

Many tool vendors (animation, pipeline, version control)
have used WPF for their software or are planning on using it
for new projects. These vendors have historically only
supported Windows and are now looking at adding either Mac or
Linux. This became almost a FAQ at the Mono booth: when are
you going to ship WPF on Mac/Linux.

We have no plans on building WPF. We just do not have the
man power to build an implementation in any reasonable
time-frame.

Today, we offer a few suggestions to developers. Feel
free to pick and choose:

Use Gtk# if you want to share the same code across
all three platforms.

Split your UI code from the non-UI code and build
a UI per system. On Windows, use WPF, on Mac use
MonoMac, on Linux Gtk#. Or use gtk# on Mac and Linux.

For tools that are mostly OpenGL/DirectX based,
use Windows.Forms, keeping in mind that some bug
fixing or work around on their part might be needed as
our Windows.Forms is not actively developed.

If you can afford building two or three UIs

Those are the toolkits you can use today to get your
.NET-based tools working on multiple platforms. There are a
number of longer-term options in the horizon that could be
useful, but would require a concerted effort by the community
to complete:

Monomac.Winforms:
assist the effort to have a Winforms look-alike API
that happens to be based entirely on MonoMac and
provides a native experience at the expense of
dropping compatibility with some Winforms features.

Create an SWT-like toolkit, like Eclipse did for
Java, but this time for .NET. Mapping UI components
to Cocoa, Gtk+ or WPF depending on the platform.

Use Silverlight on Windows. And then use a
modified version of Moonlight on Linux (and assist
porting Moonlight to Mac) to get enough support to
integrate with the native OS (menus, file dialogs,
file system access) and to access and embed OpenGL in
their applications.

WPF implementation: not impossible, but this will
require someone to fund some 15-20 developers to
implement this enormous stack and some 2-3 years of
work.