C# in the future

#1 I think that your sources are incorrect.

C# is a cool language because it makes Windows things like COM integration and such very easy to do. However I don't see this language being used for serious game development. Ever.

#2 I'm not so sure I mean why else would they put such an effort on managed direct x, it's so it can integrate into the Net framework, in comes c#. Also there's a bunch of independent efforts like www.bunnz.com/index.php and www.axiom3d.org/ and tons of books, I dunno.

#3 There is RealmForge GDK Overview which is written in C#. They also talk about using the mono project to make it Portable to Mac, Linux as well as Windows. In the FAQ they compare themselves to Torque

... well they just badmouth Torque. They don't really compare features which doesn't suprize me. I downloaded there stuff and tried the demo. It ran but only a few things worked and certainly not the game. The best I could do was show the "world editor" which was just a tree listing. It didn't even show so much as a model. Maybe I had things setup wrong, but it didn't give me any warnings.

As far as C# goes, I would expect for games it would be as well used as VB was used for games. You could make puzzle games or tetris. C# is (and always will be) slower than native (unmanged C++ code) because C# is interpreted. As a result, games that care about speed will want the fastest. C++ will bring that. Basically I agree with Pat.

Although one can program in C# and access unmanaged code which would possible make the task easier....but thats getting a little bit off topic.

#4 Personally, I think that C# and the .Net platform will probably be used a lot for serious games development but it may take years for it to catch on. Microsoft is now forcing DirectX programmers to upgrade to Visual Studio .Net, which includes C#. Also, Microsoft is streamlining the hooks to integrate C++ with .Net. Once C# and .Net are standard on all PCs, and well integrated with DirectX, I think that game developers will flock to it. C++, however, will still be there, just as assembly language is today.

#5 @Dan
I see what you mean, I've been trying to get some more info on the real difference on performance comparing c++ and c# but all I've gotten is really bogus, some say 25 % some say 2%, am guessing there's a lot of "marketing" focused numbers and it's hard to find some real ones.

I saw a quake 2 port into managed code, and it ran great, but quake 2 isn't a very good benchmark now a days.

@Louis
That's exactly what I'd heard, that by making net an integral part of longhorn it would run a lot faster and then be a viable option for game development.

#6 Pablo,

From what I have heard, managed C++ will be faster than Managed C#. Specifically C# lacks (for example) the ability to specify inline functions and destructors that are guaranteed to run at particular points in the code. As a result, if you care if a loop runs 1000 or 1020 times in those intances, C++ will remain king. (Compared to C#)

Don't get me wrong. I program in C++ and C#. When I create a GUI application I used C#. Very nice language.

Also I see the engine I quote uses the www.axiom3d.org engine at its core.

#7 Guys, seriously. People who talk about using C# to program games are the same crowd who want to use VB to program games. I'm going to say this bluntly...get a real language. Can I do inline assembly to marshall call data across a network so I can unpack it on the other side and execute the function? No. Can I write optimized, byte-aligned structures? No. Can I take advantage of SIMD instructions? No.

Any time spent on thinking you are cutting edge and awesome because you are going to use the latest, greatest, flavor-of-the month language to write your game engine is wasted. Hell when Java came out people were trying to argue that using JIT it was fast enough to do a game in. It's bullshit, guys. C# is not a viable language for game development, and .NET is not a viable platform for game development. If everything I do is 2% slower in C# (which I think is grossly understated), I'm going to use C++, and so is every other serious game developer on the planet.

#8 Pat, Agreed. C# is my replacement for VB. GUI developement only.

#9 Pat.. Delphi can do all that, but everyone told me that wasn't a real language.

- Brett

#10 @Pat
Am guessing you got real mad about leaving assembly and using c, right?

I mean am sure someday there'll be a replacement for c++, maybe it's not c# but there will be.

And if you look around you'll see c# is widely used for professional game tools, so it's not vb (am a vb hater myself).

#11 @Pat: The other day I mentioned that I dislike TorqueScript because it's slower than C++, but many people here were quick to defend it. I'm just saying this cause it's a big jump from C++ to C#, but from scripting language to C#, well, that seems a much smaller step.

I'm with you, though; C# may be a nice language, but I prefer the precision of C++.

#12 Pat,

I agree that programming in a native C++ environment is currently the way to go for the types of examples that you mentioned. I certainly don't think that C# is a general replacement for C++; C++ is here to stay, but we won't code everything in C++ forever. I do think that C# has promise for coding graphics and AI algorithms, among other tasks, and that it'll become more popular as it and the .Net platform mature.

#13 I agree with Louis.

As long as windows is the big boy,C# will continue to pick up speed. And with the ever changing nature of DirectX I think that you will see it become a more used language for graphics in the future.

I am not saying that it is better then C++. The thing is that better doesn't always win.
When people can program in a more visual enviroment with maybe a marginal speed decrease, then we may see C# take over.

After all most businesses want a quality program 2 days before they even tell you about it. So it's only natural to think that developers will head in that direction after time.

I guess it's going to be a big wait and see.

#14

Quote:
As long as windows is the big boy,C# will continue to pick up speed

Actually alot of C# momentum isn't coming from Windows, or even Microsoft. the Mono Project is pushing driving C# as a multi-platform development language.

#15 "Actually alot of C# momentum isn't coming from Windows, or even Microsoft."

When you're involved in such communities, sure, it might seem as much.

Snazzy homepage and vocal fanbase aside, I'd venture to say that the project is barely on the radar.

#16 Most professionals I know who have .net on their radar also have the mono project on the Radar. That would be non-gaming professionals.

One thing to note about the .net enviroment is that in some respects its language independant. One could write all their fast code in C++ taking advantage of the things noted in this thread, and perform other action in other languages better suited for their tasks. It would all compile together down to one exe. A powerful thing. It would be very nice to have an engine were the core is some good fast code and the "scripting language" could be VB, C#, C++, or whatever other language I am most comfortable and productive with.

The language independance makes for interesting forums. The forums have .net topics which VB, C# and C++ people post in and the indivual language forums are for sytax only.

Having said that, once again C# (for now) is my replacement for my VB work. Works great for me in that manor.

#17 Even if the stars come into alignment wth C# 2.0, Mono 2.0, and there is further increased demand for Linux and Mac game titles (something I do not think is a given as MS has something to say about that :-), then there is still one big missing thing: consoles.

Currently, most script engines are written in house or are open source. The source is C or C++ and usually fairly portable since they were written with portability in mind. Therefore most are not difficult to get working on a console and most of the good ones have already been ported. Even the most complex script hosts are simplistic compared to the .Net runtime and supporting libraries.

Writing a .Net runtime for a console is a BIG DEAL. The amount of effort is insane, and the result has a large footprint compared to even a complex script engine.. Middleware providers will have to have a very compelling reason to do this. MS will not do it. It is not in their best interest to make it easier to write portable entertainment content for non-Windows platforms. Lack of game titles is one of the biggest things holding the Mac back.

I for one think C# will eventually have a major part in professional game development along side C++; as C++ will be relegated to middleware / reusable libraries and services which are by nature lower level and closer to the metal and where you app spends all of it's time anyway cycle-wise. C# is more productive and it is almost as fast (much faster than most script engines), so it makes perfect sense to use it in the majority of the game logic where speed is not as critical.

In fact, we currently already do this. It's called script. And some titles have many tens of thousands of lines of this untyped mess. I see C# or similar filling a very broad layer between our native platform plugins built with ASM/C/C++ and the 100% interpreted unsafe script. There will still be script, but there won't be as much.

There is no doubt that some games today rely too much on script, but there is no other choice since working with C++ is not an option for some of those who are writing the script. What you need is a friendlier, more forgiving, and more productive C++ which is portable like script and you can change on the fly while debugging without recompiling or leaving the game. C# meets these needs.

There is nothing preventing this today other than such an architecture would prohibit easy console portability. If that issue is ever addressed (and it never may), then I don't think you will see huge C# adoption on many AAA titles since console portability is often an issue. But even so, indies will (and already have) found it useful.

- Rhino

#18 What I was getting at with my comments has to due with longhorn itself.

It's the first OS completely written in managed code. It's completely built around the .net framework. Hell the entire graphic level has been rewritten to be accesable easily.

With that in mind, it's going to be a .net world eventually.

#19 There is a new engine out there from some company or another that allows you to script the engine with any .net language.

Someone wrote in a plan about using it. It look's really damn good but it's probably going to be in the 5 or 6 digit range.

I guess we will see when a game fully comes out with it. I'll post a link on it when I find it again

#20 Just to correct you all, C# is not an SCRIPTED LANGUAGE, neither is VB.Net and the speed difference between C++ and C# depends on what your are doing.
Once compiled it turns into a special series of machine like commands that can run on any platform (in theory) this byte code is what is run and it is compiled into machine code the first time the app is run (hence the slowness). Once this machine code is built your near enough to C++ speeds. Also tweaking the IL code (or if ms tightens it up) produces a big speed increase. Most of the processing is done by the GPU nowadays anyway for 3d apps. The slower performance comes from the added safety of the process and bounds checks and the memory heap.
The same reason most game engine are hacked and tweaked to death is that OOP adds a processing overhead that DOES slow everything down. Chained calls and iteration through a tree of objects will always be slower than just using unmanaged code and .Net is completely OOP from the ground up.
Another point is that most of an apps codebase is usually not run very often. If you profile any application you will see that most of it is only run once or twice and (random guess) only 20% will be constantly running.

@Pat Wilson

Quote:Guys, seriously. People who talk about using C# to program games are the same crowd who want to use VB to program games. I'm going to say this bluntly...get a real language.

I though all this REAL language crap went out when people left school! How can you sit there and say that when torque depends on a scripting language that is converted to some form of byte code? If its wrong why does torque do it Pat?