|
 [This is a repost from my blog, doolwind.com]
Does the title of this article make you cringe? People have mixed feelings when it comes to C# and the .NET framework. Just like many hardcore game developers 10 years ago swore that games should only be made in straight C, many developers today say that C++ is the only way to go. This article outlines my reasoning for using C# for a commercial game on PC.
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?
|
I have had two years of C++ at my game design course, and now at my last year we are learning C#. I must say that C# is such a wonderful language because it is so productive and efficient to write compared to C++. Yet I've heard that C# programs can be decompiled, do you think that this is a threat to developing?
Nick
I've heard your concern voiced by a number of people over the years. There are a number of "Obfuscators" which can protect your code and stop it from being decompiled.
An example is Smart Assembly - http://www.smartassembly.com/
http://prog21.dadgum.com/52.html
The sticking points, as I see them, have been a combination of memory-scarce console hardware in the last generation, and game engines built around an emphasis on the CPU-heavy rendering/collision tasks. Most games don't require high-performance code for the game rules or AI scripting, but games with a sizable budget continue to push the limits on real-time rendering, animation, and physics. If you can drop those requirements(and if you're going for the indie/low-budget approach, you probably can), then, magically, you can get away with a hell of a lot of CPU overhead and an old-school single-threaded architecture; if you can squander hundreds of megabytes of memory as well, "stupid" approaches to data management and VMs with massive memory overhead become palatable options too. (comparisons of VM memory consumption: http://shootout.alioth.debian.org/u32q/fun.php?d=data&calc=calculate&xfullcpu=0&
xmem=1&xloc=0 )
C# is just one of many options - I consider it one of the more conservative possibilities, but still a big step forward. I've spent a very long time on the question of "what languages would help me make games, by myself or with a very small team, better/faster?" My preferences have developed towards engine code in languages/compilers with inferred type systems (for ex. ML, haXe, Scala...C# is among them, but generally, I'm looking for full H-M inference or as close as possible, which isn't the case with C#) and then hand-rolled Forth-type DSLs on top for each domain-specific problem: UI, AI, cinematic scripting, etc. That way, the basis of the engine can benefit from type-checking and static analysis, and the design-facing parts can be iterated with compact, low-boilerplate code, since Forth-type languages are easy to implement and extend.
General-purpose scripting languages become much less interesting in this architecture - while they let you implement any algorithm in a script, if you're already using a high-level language in the engine, there isn't much reason to do so. DSLs get "to the point" of iterating on each feature and they help provide the bulk of the gameplay-related data, so you can get away with fewer and lighter-weight tools and custom data formats.
Nick: People who wanted to pirate software or steal bits of code were doing that by decompiling, modifying, and copy-pasting machine language 20-30 years ago. It's never been a difficult technique, just time-consuming and unnecessary for most "honest" coding. Compilation is just one weak form of obfuscation, and if you want to do more, as Alistair suggests, there are options to do so.
I found that learning C++ gave me a much greater insight into the memory use of a program. Programming in C# is now a no-brainer compared to C++. Therefore, in my opinion, to become a great programmer, learning C++ is not optional.
Although, I think that, once having a good foundation built, moving on to a language like C# (which I think is a spectacular language!) for reasons of productivity, clarity and ease-of-use is a wise choice.
The biggest stumbling block that is keeping more developers from making that move (ok, aside from portability) is probably stubbornness. We are a bunch of mules aren't we? Kicking and screaming when we are faced with change to something more abstract, despite the fact that it might be a fantastic tool. We feel like our pride will be destroyed. That we can no longer brag about our ub3r l33tn3$$ and pointer-to-a-pointer-to-a-pointer arithmetic. *sigh*
Great article. I hope more developers hop on this bandwagon!
It makes the feasibility of developing a game in C# more promising. That being said, it's still difficult (as mentioned in the article) to interop effectively with native code.
My personal feelings for game development are, "don't limit yourself to one language."
Each language has its strengths and weaknesses. With the right design and understanding of architecture and libraries, various languages can interact without fear.
Check out the event collaborator architecture!
"Check out the event collaborator architecture! "
Do you have a link or something? Google is failing me today. :)
http://martinfowler.com/eaaDev/EventCollaboration.html
Also, check out Unity3D. It gives you all the beauty of writing in C#, and it runs on Mac, Windows, your browser and the IPhone. Oh, and it's free.
A lot of the COM interop issues are being addressed in C# 4.0:
http://blogs.msdn.com/samng/archive/2009/06/16/com-interop-in-c-4-0.aspx
Garbage collection has been an issue, at least with video playback. If you want to sustain a solid frame rate, it does not help to have the GC pop in every several frames. Fluid motion was especially key. I wound up having to code "around" it by subclassing a BufferedImage to make a "recyclable" image class that could be re-used while shuffling data between FFMPEG and Swing.
The memory management is a key feature of managed languages and is a large part of what makes them conducive to RAD.
If it becomes an obstacle that you have to actively work around, than these advantages don't actually apply anymore.
However in this particular case it was only a tiny piece of the program and overall it has been a huge benefit using Java.
There have been other issues but they wouldn't apply to C# or .NET.
Still, between the advantages you mention and mere curiosity, I DO intend to learn C#. Who knows, maybe I'll even dig through XNA and try to make a game out of it. ;)
I agree C# is just one of the many options of "newer" languages. I personally find it's at the right abstraction level for productivity while still have enough control over performance.
A DSL for each domain would be a very interesting. This would take the regular exposing of certain functions to script a step further to empower designers even further, and reduce the technical barrier if it's more "natural" to them.
I completely agree that to become the best game programmer you can, learning C++ is a good step. The point I'm making is that C# is a better use of your time when rapidly developing games. Having memory management in the forefront of your mind is unproductive, but that is no excuse for not knowing how it works. Having a solid understanding of core programming principles and how the .NET framework acts is vitally important for all but the simplest of games.
I agree with your points about C++. Portability seems to be the biggest concern from most "older" game programmers I talk to. Stubbornness does come into the equation, but not as much as I saw from people making the switch from C to C++. I know of a number of senior programmers at studios that still swear that C is the only true option for game development. This kind of stubbornness will never die :)
I still think using a C++ graphics engine is much more profitable than using XNA, for example Ogre is actually much easier to use than XNA and has a lot of stuff XNA doesn't. (XNA is more a DirectX wrapper than a real engine)
I don't have anything against Microsoft, and C# is great for tools, but there is a risk that Microsoft can take legal action to pull the use of C# on non-Microsoft platforms. How big this risk is I don't know, but it does make me hesitant to use it outside of tools (I also worry that schools are teaching C# and not C++).
Again, not Microsoft bashing here (they're great for developers). Just something to think about.
ames.php).
@Doug: C# is not owned by Microsoft. It was created by them, but it is now a standard. As I understand it there are potentially some patent issues in the Mono implementations of various .Net libraries , but these have been largely cleared up (see the Microsoft Community Promise).
Microsoft relinquished property rights to ECMA (ECMA-334) and ISO (ISO/IEC 23270)
Thanks for the extra info on Mono. I must say I haven't spent a great deal of time looking into Mono. I'm interested to hear other people's experiences with writing a game for Mono as well as any open source projects I can use as a reference.
As for not limiting yourself to one language, I completely agree. One great advantage of targeting the .NET framework is there are now countless languages you can use. From F# to Python you have a choice of which language to use to solve each problem.
Completely agree with everything you said :)
I'd also like to add that Unity3D is a great platform (not just because it uses C#) and I'd recommend anyone creating a 3D game to look at it. My main reason for not using it (or other engines out there) is that I'm currently working on a 2D game which was going to be more pain than value in using a 3rd party 3D based engine.
Thanks guys, you beat me to it. C# is no longer owned by C# removing this issue of ownership.
execellent article again :)
My son is interested in creating computer games. What books and software do you recommend for him to get started?
Thank you!