Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche.

Creating a Game is a different matter, and C# can be efficiently used in that domain...

And unity's been proving that pretty well.

[quote name='sankrant' timestamp='1354791063' post='5007717']
Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche.

Creating a Game is a different matter, and C# can be efficiently used in that domain...

And unity's been proving that pretty well.
[/quote]

Yeah, That's how it is done. And I don't see this changing any time soon... The game engines will have to get more fine tuned (thus C++), and the game itself will need to get better productively engineered (thus C# or more productive things).

People will use the right tool for the job, and will have fun.

PS: Game Engine != Game. Both are engineered differently and require different kind of skills. (C++ and C# respectively in this case)

What's funny is that 3 little additions to C# (maybe more, but 3 i can immediately think of) could keep all the C# advantages and remove the needs for the bits of C++
- Bringing support for new instruction sets faster
- Support for compiler intrinsics in C# code
- More control over CG management (ability to manually manage the GC arrays / ability to defragment the LoH)

What's funny is that 3 little additions to C# (maybe more, but 3 i can immediately think of) could keep all the C# advantages and remove the needs for the bits of C++
- Bringing support for new instruction sets faster
- Support for compiler intrinsics in C# code
- More control over CG management (ability to manually manage the GC arrays / ability to defragment the LoH)

I agree to this point, but it's highly unlikely.
Also, it will give you another C++, which is not required.
C# is looked upon as an enterprise solution by the majority. No Chance.

The ring has only one master, and that's C++. If the ring gets to C#, it will lead to the rise of *yet another dark lord*

Let C++ and C# remain the best tools in their own domain. (game-engine and game respectively)

Edit : Creating Game Engines require low level programming, thus C++ is the haven and heaven there.

That is true in general about C++ for engines and C# (or other) for games, but in the case of the languages used for scripting a game, the experience of the game developers will increase, will it not? Since game developers far outnumber game engine developers, the very skilled programmers with slowly but surely find ways - a few of them - of soaking deeper into the previously frozen tundra surface of game engine development.

The same thing happened with C++ when it was younger than its lower level siblings being used for engines. We see another set of languages today competing for higher level function in principle just like the previous period of C++ evolution did.

What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it.

If you really think deeply about it, C# is being directed by industry leaders to indeed become the game development leader to surpass C++ some day. Even if they fail at that vision, C# will almost surely be a heavy weight someday in the same ring with C++. It is a matter of growth and training - literally.

Remember to think big picture and in terms of the very real industry cycles of technological development. In the non-game world, C# is gigantic. The development software for C# is comprehensive and improving. The massive crop of C# programmers will grow to maturity, ready to harvest someday in a big way in program development. A mass that large will have a large effect, just like real world physics.


Clinton

That is true in general about C++ for engines and C# (or other) for games, but in the case of the languages used for scripting a game, the experience of the game developers will increase, will it not? Since game developers far outnumber game engine developers, the very skilled programmers with slowly but surely find ways - a few of them - of soaking deeper into the previously frozen tundra surface of game engine development.

The same thing happened with C++ when it was younger than its lower level siblings being used for engines. We see another set of languages today competing for higher level function in principle just like the previous period of C++ evolution did.

What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it.

If you really think deeply about it, C# is being directed by industry leaders to indeed become the game development leader to surpass C++ some day. Even if they fail at that vision, C# will almost surely be a heavy weight someday in the same ring with C++. It is a matter of growth and training - literally.

Remember to think big picture and in terms of the very real industry cycles of technological development. In the non-game world, C# is gigantic. The development software for C# is comprehensive and improving. The massive crop of C# programmers will grow to maturity, ready to harvest someday in a big way in program development. A mass that large will have a large effect, just like real world physics.


Clinton

C++ isn't going anywhere till we use/create game engines.
Do you want to know, why we switched from assembly? Productivity was only one of the reasons. The main reason was, that we changed the way we changed the way we created games. We introduced the concept of *game engines*. We started using C/C++, and we are going to use it for game engines until we see a radical change in the way we create games (maybe games withought game engines). Till then live happy. (very very long time).
Looking at a larger picture, only a *systems programming languages* like Rust or D can replace C++, if ever.

Till then (what? Eternity?) use C++ to write game engines, and use C# or your favurate language to write a cool game. I am doing that, and I do not/will not regret it

Well there's nothing "System Level" about game engines, so there's no reason to need a "System programming language there", a game engine is a game engine, it's not a vidcard driver and it needs no low level access by design. But i really wish they made a C# compiler switch that allowed to go more unmanaged with no hurdles, could definately make C# replace C++ fully for game engines, however i wouldn't split where you do (game in C# and game engine in C++) even today it'd probably be closer to game in C#, game engine in C#; and a tiny subset of the game engine in a small C++ dll.

Game Engine in C#? Humans are greedy creatures. Every inch of performance counts, and technically C++ will always outperform C#. Its one time investment!
System programming != Low level programming.

The day someone writes a C++ compiler, as optimised as the present ones, 'in C#'; that day I will say 'welcome new C++'.
Why would anyone want to create unmanaged C#? It will give the world another C++. Believe me, we won't switch from C++ in case of Game Engines any time soon.

Focus on creating games and use C# if you like.

PS : One day, the earth will end, and we will live on mars. But we will still remain human beings.

What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it.

sadly I don't think it'll go that way. C++ is a very closed relative of C, the 2 can mix in the same codebase and the boundaries between the 2 become quite blurred.
C++ allowed C "engine" developers to slowly get use to it without throwing away what they had and was working.. they could experiment with a little of C++ flavor here and there without compromising the structure and without feeling unsafe about it,because they knew they could just switch back to C if and when cornered.

The problem with C# is that you can't "inline" C code into it. The boundary between the "native" side and the "managed" side is VERY defined.. devs from one side can't "play" moving stuff here or there.. everything is much more "frozen"... plus you have the marshaling cost to consider every time you want to move something around.

To make C# (or any other language) a viable option to replace C/C++ in the game engine realm you need to create a compiler that can seamlessly include .c, .cpp or .cs files IN THE SAME PROJECT (warning, I said, project, not solution) . The only language that can be fooled to do this is Go, but just because it doesn't really have a concept of "project"... perhaps D can do it? ( I am not sure).

Until then, you'll have a solid and clear division between "system code" and "game code"... and every time something has to move from here to there it's going to be a big decision with lots of implications.. this will basically leave native devs firm in their camp and managed devs firm in their camp.

I have more hopes for a C++ evolving into something more C#-ish (add modules and optional GC and you're there) than the entire world to adopt C# for everything.

The performance issue of marshalling only applies when you , well, marshall, so it's a non issue when doing parts strictly managed and others strictly unmanaged, what matters to keep cost low is not going through the frontier often. However it could be all C# & no C++ if intrinsics were available directly from managed code, keeping the full managed goodness where you need it, it's not like it's impossible "by design", it's just missing from .net so far.