Sign in to follow this  
sankrant

Is there any chance of C# bieng adopted by the AAA game studios, as a replacement to C++?

Recommended Posts

[quote name='sankrant' timestamp='1354298843' post='5005758']
Can you please name a few? It will be very kind of you....
[/quote]
I'm not sure what I can point out without breaking NDA, but it is public knowledge that The Sims 3 used C# for the objects and interactions code, and the SIms3 modding community apparently love it.

I know of three other engines that do, but I can't find references to any of those three on Google so I'm not posting them.

Second Life also used C# for scripting.

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1354307971' post='5005833']
The only obstacle to this - and I emphasize [b]only[/b] - is adoption by console manufacturers. Until C++ is displaced there, it will continue to be heavily used for major game development that involves consoles.
[/quote]We use mono on the consoles. It is a little more difficult to debug, but not so much more than C# using the various awful debuggers out there.

Share this post


Link to post
Share on other sites
[quote name='frob' timestamp='1354308881' post='5005841']
We use mono on the consoles. It is a little more difficult to debug, but not so much more than C# using the various awful debuggers out there.
[/quote]
C++ debuggers?

Share this post


Link to post
Share on other sites
@frob Frostbite does uses C#; only the game editor is writern in C#, rest pipeline (c++), render engine (c++), etc.
If you have any solid link about, that would be too nice of you...

Also, in sims 3 the main game logic (upper level) is C#, but the core engine (renderer etc) is C++...

Share this post


Link to post
Share on other sites
C# has support for some things that are considered staples of functional programming (lexical closures, first class functions, etc.) but it's an eagerly evaluated language so accomplishing true lazy evaluation semantics can be messy. Generally it isn't designed to be programmed in the same way as, say, Haskell. They're just different thought models.

Share this post


Link to post
Share on other sites
[quote name='frob' timestamp='1354308881' post='5005841']
[quote name='ApochPiQ' timestamp='1354307971' post='5005833']
The only obstacle to this - and I emphasize [b]only[/b] - is adoption by console manufacturers. Until C++ is displaced there, it will continue to be heavily used for major game development that involves consoles.
[/quote]We use mono on the consoles. It is a little more difficult to debug, but not so much more than C# using the various awful debuggers out there.
[/quote]

I've seen mono on... well, let's say, "certain non-PC platforms." It's not terrible - has some ways to go - but the obstacle I perceive isn't technical feasibility, it's political buy-in. Until those tools get first-class status from the manufacturers, C++ will be preferable in many cases, just because it's the path of least resistance.

Share this post


Link to post
Share on other sites
C# is used often in middleware since it makes programming GUIs for Windows so much easier. My guess is a significant percentage of middleware development is in C# if their development platform is Windows based ( some arn't ). Good tools engineer use a variety of programming languages to get the job done of course, Python, Ruby, Perl, etc. What'ever works.

Share this post


Link to post
Share on other sites
After a kind of resistance in microsoft C# feels like a lag...

Edit : Hey people, I got the answer

No language can replace any other language.
Nothing matches C++ when CREATING a game-engine, and C# is strong at USING that game engine, and tools.

Share this post


Link to post
Share on other sites
[quote name='sankrant' timestamp='1354331415' post='5005927']
After a kind of resistance in microsoft C# feels like a lag
[/quote]

What?

[quote name='sankrant' timestamp='1354331415' post='5005927']
Nothing matches C++ when CREATING a game-engine
[/quote]

Maybe for you this is the case, but others have quite happily created their engine either mixing C++ in their code or created purely in some other language WITHOUT issues.

Share this post


Link to post
Share on other sites
[quote name='Dynamo_Maestro' timestamp='1354355612' post='5005988']
[quote name='sankrant' timestamp='1354331415' post='5005927']
After a kind of resistance in microsoft C# feels like a lag
[/quote]

What?

[quote name='sankrant' timestamp='1354331415' post='5005927']
Nothing matches C++ when CREATING a game-engine
[/quote]

Maybe for you this is the case, but others have quite happily created their engine either mixing C++ in their code or created purely in some other language WITHOUT issues.
[/quote]

Other than C++? I like Haskell. Working on mastering it :)

Share this post


Link to post
Share on other sites
The C# use in AAA games will only increase, is my prediction based on the high quality of the language and the crop of C# programmers which will come to maturity in their fields in the coming years. The .Net Framework is here to stay and C# is the core of it - make no mistake about capabilities, too.


Clinton

Share this post


Link to post
Share on other sites
[quote name='3Ddreamer' timestamp='1354557273' post='5006691']
The .Net Framework is here to stay and C# is the core of it
[/quote]

I hope this is the case, but I'm not as confident as you are. MS are no longer pushing .net the way they were. Look at the failure of WPF, and the subsequent return to C++ in winRT.

I know these aren't related to games directly, but this is microsofts bread and butter. If it's not working for them there, you have to wonder if they'll continue to push .net.

Personally I hope they do, as C# is a much nicer language to work in that C++.

Share this post


Link to post
Share on other sites
That's true, yet we have the limit of being on the outside of major decision making. Several years ago or more, OpenGL was surging and some people were complaining about DirectX and wondering if MS was getting ready to either kill support or starve it to death. Both OpenGL and DirectX are going strong now.

Here is why the OpenGL to DirectX comparison is relevant to .NET Framework: Cross-platform needs have given increased demand for OpenGL and derivative technologies from Google, Apple, Sony, Samsung, and others - mobile devices - mainly laptops, tablets, and smartphones. This puts pressure on Microsoft to find ways to compete [i]indirectly[/i] against OpenGL and Linux related tech. They chose .NET Framework as the mainstream for Windows application development with their flagship C# language with huge investments in money, time, talent, and reputation. They knew that they could not compete with OpenGL in quantity of market segments so they focused on quality of Windows based development and implementation.

It is much more cost effective to improve existing technologies rather than replace the whole .NET Framework fleet with another huge set of them. I believe there is evidence to consider that the Great Recession caused a temporary market saturation of .NET Framework software, applications, and end user devices during the economic downturn. Microsoft is able to track such trends with fairly good accuracy in most market segments, though the gaming industry seems to be one of the least predictable. At the time, they prioritized because of market uncertainty.

The .NET Framework has kept pace with DirectX progress. Hardware, third-party software, and chip architecture is interdependent on stable technologies of low level APIs such as DirectX and OpenGL to interface applications, from a marketing standpoint. As the frameworks have matured in growth, there is less to accomplish in innovations so most support involves customer implementation demands (such as shader upgrades), hardware compatibility, and backward compatibility. The frameworks matured so they are generally self-sustaining and needing less support. Each framework fork maintains its role in the marketplace, so why upset the flow? The .NET Framework is technologically mature and Microsoft depends on it in many ways.

The popularity of .NET with developers means that it needs to be "pushed" less. You are right about other technologies getting major effort, such as new mobiles, NVIDIA partnership, and the famous (or infamous, depending on your love or hate of MS) online store. Now the strategy of Microsoft is to get the return on their investments by these areas.

Massive sets of technologies are not easy to develop, change, or eliminate. Customers and partners depend on .NET Framework. The efficiency of development in the framework is popular. Microsoft is harvesting the crop now which grew from .NET investment of more than a decade.

More energy is now focused on marketing the products from existing technologies in this improving economic cycle, like a surfer catching the next incoming wave - good strategy for Microsoft and other companies. This is what you see actually happening.


Clinton

Share this post


Link to post
Share on other sites
[quote name='ChaosEngine' timestamp='1354572600' post='5006800']
I hope this is the case, but I'm not as confident as you are. MS are no longer pushing .net the way they were. Look at the failure of WPF, and the subsequent return to C++ in winRT.
[/quote]

Why was WPF a failure? It probably won't be used much anymore, but programming for windows 8 is pretty similar to WPF, and would probably still be considerred WPF if they hadn't made winRT so compatible with .Net.

Share this post


Link to post
Share on other sites
[quote name='way2lazy2care' timestamp='1354628147' post='5007067']
[quote name='ChaosEngine' timestamp='1354572600' post='5006800']
I hope this is the case, but I'm not as confident as you are. MS are no longer pushing .net the way they were. Look at the failure of WPF, and the subsequent return to C++ in winRT.
[/quote]

Why was WPF a failure? It probably won't be used much anymore, [/quote]

How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.

[quote name='way2lazy2care' timestamp='1354628147' post='5007067']
programming for windows 8 is pretty similar to WPF, and would probably still be considerred WPF if they hadn't made winRT so compatible with .Net.
[/quote]

There are some similar concepts, but I think replacing the entire runtime and api of a library can be considered to be a "new axe". But the most important difference is that WPF was a managed library from the ground up. From a win32 perpective it was one owner drawn window that managed everything internally. WinRT is not managed.


[url="http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/"]Good overview of the history here[/url].

Share this post


Link to post
Share on other sites
[quote name='ChaosEngine' timestamp='1354652041' post='5007183']
How was it anything but a failure? It had some nice features, but almost no-one ever used it, it was complex, memory hogging and failed to get simple things (focus, tab order) right. I spent 3 years working with it, and it used 10 times the memory of the equivalent winforms app.
[/quote]

No offence but this (as you probably already know) is a lot like the many many (far too many) whiny comparison threads between WPF and WinForms over the years (no different from the annoying C# vs C++ ones either), which almost always gets resulted in links to http://msdn.microsoft.com/en-us/library/aa970683.aspx or something VS2010 related. The extra features it has are not only overused but are likely the reason why so many people complaint about performance; element collisions, multiple effects on elements, effects created on the CPU, animations, animated layout, using media element, 3D content on the CPU are just some of the 'features' that are badly abused, it was almost like people thought WPF was used to make over pretty UI controls that were no different from game entities then apply collision and other pointless crap to them.

WPF gets considered complex, on other forums this may make sense but on a gaming forum WPFs learning curve is a small fraction of what people would have to learn to make even the simplest game, not that it makes any difference since Windows 8 uses XAML so any complexities would be unavoidable if they moved onto Windows 8 anyway.

As for your 'getting simple things right' comment, I am eager to hear what you were trying to do and how you achieved it. Now I have only been using WPF / SL / WinForms for 2 years (although that doesnt mean much since total years != total hours) and while I use all three for different things, my decision is NEVER based on memory consumption mainly because any visible lag is my own coding error and it would seem all the memory complaints after .Net 4 were to do with visual effects. If anything the only resource drainage is from XAML editor in Visual Studios, something that is non-existent in Blend

Besides if you read up on current performance issues, it is almost always to do with effects, media, animations, ink canvas effects or some other eye-candy thing that typically you wouldnt really want to do on the CPU anyway, all which can and should be done using surface sharing via SharpDX / SlimDX. I think the issue with WPF is MS advertised it as a framework for making over the top pretty apps with animations and 3D effects both of which I would never recommend doing directly from WPF. Edited by Dynamo_Maestro

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this