Rapid Application Development

The primary reason for using C# is because coding in it is more productive than any other language I’ve used.  Language features like interfaces, generics and delegates make it a cleaner language than C++.  Development practices such as unit testing and dependency injection are also easier to use in C#.  This clarity translates to more readable code and less bugs, particularly when working with a larger or younger team of developers.

The second productivity gain comes from having access to the .NET framework.  From its XML handling for configuration, to built-in math libraries, many of the core functions you can think of are taken care of.  This saves you writing the code yourself and lets a reliable, tested framework do the heavy lifting in areas you don’t want to spend your time.

C# lets you focus on making a game rather than writing an engine, or learning someone else’s engine.

Unified Code – Client, Server, Tools, Scripting

• Server – I’m writing the server architecture (matchmaking, leaderboard, etc) in ASP.NET and C#.  This lets me share libraries between the client and server and makes calling web services from the client a breeze.
• Tools – All our tools are also written in C#.  This means that our tools can have rendering within them, can reuse libraries and simplifies the creation of in-game tools.
• Scripting – As I’ve mentioned in a previous article, I’m using C# for the scripting language in our game.

Better Software Development

C# supports better software development practices in a number of key ways:

• Refactoring Tools – Visual Studio has great refactoring support such as renaming identifiers and extracting methods & interfaces.
• Separation of Concerns – Splitting a project into separate .dll’s is trivial in C#.  This helps with maintainability and encapsulation of code and encourages good separation of concerns.
• Unit Testing – C# has great support for unit testing through NUnit or MSTest.  As I’ve previously discussed, unit testing fits perfectly in certain areas of game development.  The easier unit testing is to achieve, the more people are likely to adopt it.

In-Game Web Browser

As part of the game engine we are developing we decided all interaction with the server for matchmaking would be through http/html.  This reduces the need for creating such a complex in-game UI system and simplifies communication with the server.  The .NET web browser control is extremely easy to use and communication between the browser and host application (the game) is a simple.

Run-time isn’t too large

I’m currently targeting the .NET 2 framework.  This put’s the footprint at around 20MB.  The latest .NET frameworks (3.5 and 4) both have a “client profile”.  This is a subset of the .NET framework that comes in at about 30MB.  My plan is to use the .NET 4 client profile once it is released as it gives me access to all the latest language features (Linq, lambda expressions, dynamic objects, etc).  MS is currently planning to make .NET 4 client profile a windows update meaning the .NET framework will finally become (almost) ubiquitous among PC’s running windows.

Negatives

There are obvious drawbacks to using C# for a commercial game engine which we took into consideration when making our decisions.

• Not Cross Platform – While engines like Unity have proven that C# can run on multiple platforms, this does not occur out of the box.  As we’re targeting PC’s exclusively for our first release this was not a problem.
• Xbox run-time not great – C# can run on the Xbox as part of XNA game studio, however the run-time performance isn’t great.  Garbage collection is a particular problem which requires refactoring code to achieve acceptable frame rates.
• Harder to use C++ libraries – Linking to straight C++ (non-COM) libraries is not trivial like it is connecting to other .NET libraries.  Extra time is required if there is a requirement to use existing libraries such as RakNet.
• Some performance concerns – C# does have some performance concerns with garbage collection and certain double math operations.  However the algorithmic gains received from working with such a great language outweigh the small performance issues in certain areas.  As with any language, bad code will run slow.

Conclusion

C# is a great language.  I thoroughly enjoy coding for it and I find it makes me more productive when creating games.  I plan to release my MVC engine in the future as an open source project.  Until then, I’m continuing to develop our engine and I’ll keep you up to date with the progress.

For reference, here are a couple of commercial games using C#:

Arena Wars - http://www.arenawars.net

AI War Fleet Command – http://www.arcengames.com/aiwar_features.php

Sacraboar – http://www.sacraboar.com

Have you used C# for game development?  Are you sick of chasing memory leaks and crashes in your C++ applications?  Do you think game developers will move on from C++ now or in the future?