C# not for games?

Hello. Just trying out MOGRE since Axiom just is not even compaitable with alot of stuff.

I was just wondering why no games in development are written in C#. Is it that no competent engines are written in C# or that no one wants to convert over to C# or that C# just is not strong enough yet to make a good game?

Can someone tell me?

We are using Mogre engine for our Wings of Fury 2 remake. You can learn more on our page http://wingsoffury2.com where you can watch some movies and download the demo. I think it will give you a clue what can currently be achieved with Mogre.

You can use C# or even Java for make high-quality games.. the problem is not the language, the problem is the history, "everybody" in past has made all games using pure native languages, like C or C++ this make a pre-judgment in mind of new programers.

If u have a right design of your games and programming patterns, u can even make game with higher performace thant C++ and very high quality in much less time. Remember with already has all the gained power of C++ through OGRE, and all the flexiblity and RAD tools of C#, you can focus all your time and knowlegde in your game specific logic, and not in specific language problems like memory handle and slowers compile times.. its matter of time to start looking good games made it in C#

PD: Sorry my english xD

By using C# or any other .NET languages you force your consumers to install .NET framework on their PCs. The same considering java runtime if you are using java for development. For small casual games it matters. Besides, .NET assemblies can be very easily disassembled and reverse-engineered.

www.blade3d.com

www.visual3d.net

www.truevision3d.com

www.dxstudio.com

Just to name a few.

By using C# or any other .NET languages you force your consumers to install .NET framework on their PCs. The same considering java runtime if you are using java for development.

That is not really a decisive argument. You could argue that for DirectX in the early days. If it's really worth it (which in itself is a different story), then dependency installation will quickly become secondary. Also, the installation itself can be made quite transparent with the game installer, as done with DirectX.

For small casual games it matters.

Actually, it's surprising to find that users of casual games often have the .NET framework already installed for other applications besides your game.

Besides, .NET assemblies can be very easily disassembled and reverse-engineered.

If you're so much into commercial investment and commitment that you worry about reverse-engineering (e.g. usually not true for casual game distributions), then you can invest in Obfuscation solutions. Basically these are frameworks which scramble reflected code.

In some of the more sophisticated solutions, scrambled code can be even worse than C++ binaries, whose patterns can be discerned by the experienced Hex disassembler hacker.


That said,

C# can be an extraordinary productivity booster, especially if you're just starting a new venture or company.

Lots of effort has been made with integrating some of the most useful design patterns into the language itself making it extremely easy to naturally "fall" into good design practices.

Also, the enormous (and growing) availability of powerful tools and frameworks from Microsoft make it increasingly more interesting for serious game development.

Domain-Specific Languages for rapid prototyping and development of game design tools, Parallel FX framework for multi-core programming, LINQ for abstracting out data-base and general data-set access (which by the way is extremely interesting for large game-worlds).

Join that with the possibility of fast integration of unmanaged code via Managed C++ with a minor hit on performance (from our experience), lots of free tools and frameworks from MS itself (and from dedicated open-source efforts like Mogre itself ) and you've got the best bang for buck for starting game development companies.

Just my two cents,

Gonçalo

Some interesting arguments here.

I agree that they are all contributing factors. I'm a heavy C# developer, mostly for business applications with an interest in Ogre as a hobby (for now )

I think that development time is the key factor in most cases. C# typically speeds up development time because of it's rich set of libraries and managed code prevents a lot of headaches.

However, when developing a game it's important to consider all of the required code. You might need sound, networking, AI, physics, GUI and so on..

In my experience, there is a diverse selection on libraries in C++ but in C# the game related code is limited. It's not that you couldn't make a game in C# but how much of the wheel do you need to reinvent? It's likely that if you have to implement lots of extra code the benefits of a modern language won't be so great.

Personally, I would like to see more games developed in C# and MOGRE seems a step in the right direction. I've decided to use it for developing tools, such as a level editor. As for a game, I'm not so sure yet.

The biggest impediment to using C# in games is the lack of decent libraries. Name a component of a game engine, heck sometimes of a game genre, and someone has already written a decent free library for it in C++, often times better than what you would produce yourself in the time you'd take. C# on the other hand you're either reinventing the wheel or wrapping, neither good options.

Microsoft sure didn't help when they killed MDX in favor of XNA. No one serious uses XNA for anything, and never will. If you're making an Xbox title you're likely targeting multiple platforms and so won't use it for that reason. And if you're targeting PCs you don't want to be limited by it as everything in XNA is scoped to the lowest common denominator which is the Xbox.

MDX on the other hand aside form the very minor performance hit was perfectly good, and had it been updated with 2.0 and 3.5 features would have been something really special and might have actually caught on commercially, at least for PC games.

With MOGRE and the Tao Framework, there is very little you can do in C++ that you can't do in C#.

If you do need a specific C++ library, it's not THAT hard to wrap a Managed C++ aggregate wrapper around it. In the case of a C library, you can do exactly what Tao does and bind the functions directly in C#.

In response to the comment about the code being easily reverse engineered, it's very easy to get around: Ngen your assemblies as part of your install process. You should do this anyway for performance reasons, but it also causes the images to become binary native code.

Tao is great and all but it's a tiny drop in the bucket compared to what's out there in C++. However it is a step in the right direction, the more Taos we have the easier it becomes to develop in C#, I just don't think one is enough to really turn the tide towards managed code.

And yes you can wrap stuff, and no it's not that hard. But its tedious and often ends with less than stellar results. The whole point of C# is to avoid having to deal with pointers, memory allocation, and generally speed up implementation. By wrapping a C++ library suddenly all that is back in play and once you're done wrapping, debugging, and maintaining the wrapper to the latest version you might as well be writing in C++.

Tao is great and all but it's a tiny drop in the bucket compared to what's out there in C++. However it is a step in the right direction, the more Taos we have the easier it becomes to develop in C#, I just don't think one is enough to really turn the tide towards managed code.

And yes you can wrap stuff, and no it's not that hard. But its tedious and often ends with less than stellar results. The whole point of C# is to avoid having to deal with pointers, memory allocation, and generally speed up implementation. By wrapping a C++ library suddenly all that is back in play and once you're done wrapping, debugging, and maintaining the wrapper to the latest version you might as well be writing in C++.

How so? I recently wrapped a C++ library, and the Managed C++ code I generated is less than 2% of my total game system code. So your comment that you should "just program in C++ anyway" is sort of silly. How many libraries do you REALLY use when you are making a game?

Sound: Tao covers this. If you want FMOD, there is a .NET wrapper for that as well

Networking: The .NET networking package is awesome. It allows you to tap in to things like IOCP's on Windows without actually having to understand how async I/O works. If you need something "bigger" like HawkNL or RakNet, simply P/Invoke it or wrap it, it's going to end up a very small chunk of your total code.

Input: MOIS. 'Nuff said.

Physics: Nearly every major physics package already has a .NET binding.

Scripting: Tao has Lua, there is a .NET Ruby binding floating around, there is IronPython if you want to use Python. In a .NET environment, you could just as easily use C# as your scripting language and compile it on the fly (because all the compiler services are exposed as part of the framework, huge advantage over C++).

So what libraries are you really missing here? Boost? Everything Boost does is covered somewhere in the .NET framework, for the most part. Much of Boost is irrelevant outside of a C++ environment anyway. Some OGRE plugins you want to use, like ETM? Many of them have already been wrapped, and wrapping them is super easy if they haven't.

I'm not trying to start a fight here, but the third party library argument is becoming tired and irrelevant. So many libraries are exposing .NET bindings now, and .NET makes it so easy to write your own bindings, it's simply not that big of a concern anymore.

People are going to use what they like, and for many people that's C++, and that's fine. My point is: There is nothing, NOTHING, stopping someone from releasing a top quality, AAA title, written with managed code. Nothing. It simply hasn't been done yet.

It can be a tiny fraction of your code in terms of lines or execution time but take up an inordinate amount of development time to utilize and maintain.

I agree that the situation is improving and there are more wrappers now than there were last year. But a big part of the issue I have with the situation is that they are wrappers at all. Not from a direct performance hit standpoint, but from one of maintainability. Wrappers are typically undertaken by 3rd party individuals and not by the original producers of the library. Once that person finishes their current project utilizing it or graduates from college and suddenly has a real job taking up their time the wrapper often withers up and dies. Even if that doesn't happen they tend to lag woefully behind their C++ counterparts. Take MOGRE for example, 1.4.9 of OGRE was released what 5 weeks ago? MOGRE is still on 1.4.8 and is a royal pain to get running compared to OGRE. If we had native managed libraries or wrappers maintained by the original developers and released simultaneously it would be a different story, but we don't.

Believe me I'm not trying to champion C++ here, I love developing in C#. But given the current state of things no one is going to make a AAA game in C# any time soon. While it may be possible "in theory" there is way too much money involved to rely on 3rd party wrappers and the fickleness of the open source community.

It took me less than two hours to wrap this library in Managed C++. If you are having to spend serious development time on a purely aggregate wrapper, something is terribly wrong. The absolute worst issue with wrapping C++ libraries is dealing with strings, but you can write two simple utility functions that will cover 90% of the string conversion cases you run across.

It also seems to me that your argument is more about using open source libraries in projects, than managed code. All of the "symptoms" you listed are symptoms of open source, not of managed wrappers. Any open source library is prone to becoming a dead library because no one maintains it anymore.

I guess we will just agree to disagree on this. I think that people stick with C++ more because it's the status quo. It's more than theoretically possible to write a top quality game in a managed environment, it's quite possible. Look at some of the stuff coming out on XBLA these days that is written in C# using XNA. Currently the OGRE tool chain for managed code is not nearly as concrete as XNA, but it will firm up over time (and has already made huge leaps since I first started playing with MOGRE).

And for some libraries that's all it takes. But if you think strings are the worst things about wrapping stuff then you haven't wrapped anything really painful yet.

Yeah most of my complaints about the current slate of managed libraries is the fact that they're open source. Managed code rocks, C# rocks. The availability of quality stable libraries for game development in C# sucks, at least in part because the few that do exist are open source. I'm not saying C# shouldn't be used for game development, I'm saying why it isn't used for game development.

XBLA doth not equal AAA. XNA is kind of a joke, it's a watered down version of MDX. I can write entertaining games in BlitzMax or Flash but that doesn't mean they're going to ever be used to make mainstream games.

XNA 1 was a joke, XNA 2 and 3 are quite complete and you could write a top quality AAA game with them if you had the time and resources. I am not of the mind that quality has anything to do with budget, and some of the games coming out on XBLA are very much top quality efforts.

They're complete but why exactly would you use them for anything but XBLA development? Is there a single retail game for the Xbox or PC written in XNA? Can you give me a convincing reason to restrict your feature set and platform by using XNA. XNA had a lot of potential but the decision to make everything it does work on a non-evolving platform made it unsuitable for serious PC development. And anyone targeting the Xbox is likely going multiplatform thus making it unsuitable for that as well.

Hell the big awesome new feature in 3.0 is the ability to program for Zunes. Just what I always wanted the ability to write games for a 2nd rate MP3 player.

Gameplay quality is rarely tied to budget, often it's inversely proportional, I'll give you that. Art and often sales on the other hand tends to be very tied to budget.

Just a "C# for games" example:
Serious games maker Incredible Sims is using C# and Mogre, according to this thread:
http://www.ogre3d.org/phpBB2/viewtopic. ... b3e#265017

I digged it up. No flame, just my opinion.

Quote:
By using C# or any other .NET languages you force your consumers to install .NET framework on their PCs. The same considering java runtime if you are using java for development.


That is not really a decisive argument. You could argue that for DirectX in the early days. If it's really worth it (which in itself is a different story), then dependency installation will quickly become secondary. Also, the installation itself can be made quite transparent with the game installer, as done with DirectX.

This IS a decisive argument for casual gamers that sit in their offices without admin rights but want to play new simple but modern games from time to time. Trust me. I can see those gamers in my office every day.

I'd say most large offices push .NET 2.0 out as part of their standard XP image. All of our clients do. And Vista ships with 3.0 installed. So while a concern, it's not nearly as troublesome as it used to be and dwindling every day.