> is C# really a good choice when developing on Mac or Linux
No, not for game development.
And who is saying that C++ is so bad? It is a really powerful language with lots of libraries. If you already know C++ then I think it is a natural choice to use it for game development.
C++ compiles into a fast and optimized native code while C# compiles into byte-code then being interpreted - so the programs can't be as fast as the native programs. And the GC (Garbage Collection) also slows the things down.
C# compiles into byte-code then being interpreted - so the programs can't be as fast as a native programs.
None of this is really true, but it is true that you can often have strict FPS requirements when making a game and dealing with GC pauses can be very difficult.
Overall, I would not recommend that a novice attempt to make a game with very strict real time dependencies in C#. If you understand C# and CLR interactions well you can do it, but the coding style and optimization techniques are not for the uninitiated.
C++ really is your best bet for something with these types of requirements.
The interesting thing is that sometimes, interpreted bytecode is faster than native instructions. First of all, bytecode isn't usually interpreted but rather Just In Time (JIT) compiled. This means that it's a little bit slower the first time you call a function as it's being compiled. The compilation times aren't huge however as the bytecode has already been optimized and it maps fairly straightforwardly to machine code. In a game, most of the time is spent in a few functions called by the game loop. After these functions are called once, they are usually as fast as the compiled version.
The area in which bytecode can gain an edge is with sse instructions and aggressive inlining. When you compile your game for the i386, you can't assume that the processor you target has all the new SIMD (single instruction multiple dispatch) available. Now this isn't a problem on consoles since you know your target but it is on the PC. The JIT compilation can take advantage of these instructions since they can detect their availability at runtime (which is also compile time).
The other neat trick that JIT compilation can do is profile the code as it is running (less costly than it sounds) and inline hot functions. You can't do this with c++ because you can't unlink the code easily. A good example of this technique is found in the V8 javascript engine.
This isn't to say that bytecode is always faster but rather to point out that using intermediate bytecode doesn't always carry a high performance penalty. What kills C# are the GC pauses. Also keep in mind that nothing can ever beat well optimized assembly for a target processor but the people who can do this are rare and valuable.
It depends on the kind of game you're making, but C# is a less ideal language because of garbage collection. Fighting GC pauses are no fun when you're trying to make a real-time game.
C++ is largely used because of speed, memory control, and momentum with tools, libraries and experience.
At this point there isn't one language for game devs. Even companies that strictly develop for PC tend to do their engine in C++ and then extend the ide with a scripting language like lua or python. Civilization 4 is a great example of it because they put the python api out as the user-moddable part of the game and it spawned this huge community. Other platforms like android (with its giant installed base) are basically java. So C++ isn't really the only answer to begin with.
Based on what I've been messing around with lately I'd look at go for maybe being a good complement or replacement for C++. Most of the time I'm making something with two major loops: game logic and rendering. Because of the way go interacts with C++ it's not hard to do the game logic in go, where I get massive benefit from "free" concurrency and pretty nice execution speed and then render in C++ where you can get back down to pointer arithmetic if you have to. This is outside of supporting any kind of scripting api/ide which I typically don't deal with but just for familiarity's sake and expecting others to use it later I would probably do in python.
When dealing with games you will most likely want great responsiveness and performance.
to trigger both of these you will want to go to the lowest possible level, this can give absolute control over what happens in your game- (mostly for the graphics and the logic engine - A.Is and such).
you will also probably want better control over the memory usage, which (mostly) can be just easier in low level which c / c++ offers.
C++ isn't bad. It's just ugly. If you can deal with the ugly, it's the usual way to do it and it'll work. If you have high performance demands, well, C++ will work if anything will. Not to say other langs won't handle it, but there's not a whole lot of exemplars in anything else. You clearly can write games in Java or C# or Python, but you might think twice before trying to do the modern equivalent of Quake in one of those. If you did, you'd be trailblazing.
Engine in C/C++ and logic/controls in Python (or Lua) seems to be a common architecture. Lets you have machine speed at the core and human speed elsewhere. Creates an easy way to do a 3rd party scripting interface while you're at it. (If you think performance demands won't be high, you could just write the whole thing in Python and optimize the most-used parts out to C after profiling.)
I think Go is interesting for games, given modern CPU architecture. It could potentially rock the socks off in a game engine, but it's not been done yet. A commercial game developer would have to be pretty daring to try; an open source game would be safer.
A few of the larger studios have experimented with using Go in place of Python for the frontend. Unfortunately I think they're missing the point. As you said, Go would make an incredible game engine. Since it's so idiomatic, it could also potentially be used for the frontend, allowing developers to use the same language throughout the full-stack.
The biggest barrier for most studios is the current investment in C++. The majority of engines and most associated libraries are written in C++. Regarding the libaries, it's possible to write C wrappers around the C++ APIs and then access them through cgo, but the developer time required likely isn't worth it.
I'm hoping that a smaller studio will create some proof-of-concept, but we'll see. There was an interesting kickstarter for a game written in Go that ultimately failed, giving the language quite a bit of bad press in the community (http://www.kickstarter.com/projects/2066438441/haunts-the-ma...).
A few of the larger studios have experimented with using Go in place of Python for the frontend. Unfortunately I think they're missing the point. As you said, Go would make an incredible game engine. Since it's so idiomatic, it could also potentially be used for the frontend, allowing developers to use the same language throughout the full-stack.
The biggest barrier for most studios is the current investment in C++. The majority of engines and most associated libraries are written in C++. Regarding the libaries, it's possible to write C wrappers around the C++ APIs and then access them through cgo, but the developer time required likely isn't worth it.
I'm hoping that a smaller studio will create some proof-of-concept, but we'll see. There was an interesting kickstarter for a game written in Go that ultimately failed, giving the language quite a bit of bad press in the community (http://www.kickstarter.com/projects/2066438441/haunts-the-ma...).
C++ is not so bad, not at all. You could to use it on game development; but I recommend you look at D language someday (not so far away)... answering the second question, they aren't good canditates to such a job.
Like others have said, your best bet is to probably build your framework in C++, and use a scripting language (e.g. python) for the high level game dynamics. I see no reason to use C. C# will probably get you fighting with mono. Java may have issues if you have high graphics requirements (you really don't want to GC pause for 50ms).
22 comments
[ 0.32 ms ] story [ 53.7 ms ] threadNo, not for game development.
And who is saying that C++ is so bad? It is a really powerful language with lots of libraries. If you already know C++ then I think it is a natural choice to use it for game development.
None of this is really true, but it is true that you can often have strict FPS requirements when making a game and dealing with GC pauses can be very difficult.
Overall, I would not recommend that a novice attempt to make a game with very strict real time dependencies in C#. If you understand C# and CLR interactions well you can do it, but the coding style and optimization techniques are not for the uninitiated.
C++ really is your best bet for something with these types of requirements.
The area in which bytecode can gain an edge is with sse instructions and aggressive inlining. When you compile your game for the i386, you can't assume that the processor you target has all the new SIMD (single instruction multiple dispatch) available. Now this isn't a problem on consoles since you know your target but it is on the PC. The JIT compilation can take advantage of these instructions since they can detect their availability at runtime (which is also compile time).
The other neat trick that JIT compilation can do is profile the code as it is running (less costly than it sounds) and inline hot functions. You can't do this with c++ because you can't unlink the code easily. A good example of this technique is found in the V8 javascript engine.
This isn't to say that bytecode is always faster but rather to point out that using intermediate bytecode doesn't always carry a high performance penalty. What kills C# are the GC pauses. Also keep in mind that nothing can ever beat well optimized assembly for a target processor but the people who can do this are rare and valuable.
C++ is largely used because of speed, memory control, and momentum with tools, libraries and experience.
Many games have fairly strict FPS/real time requirements, so any type of GC can get in the way more than it can help.
Once you restrict yourself to non-GC languages, your options are pretty limited. I would choose C++ for the library and platform support, personally.
[1] I'm assuming you want a mainstream language, not some experimental typed language with region memory inference or similar esoteric solutions.
Based on what I've been messing around with lately I'd look at go for maybe being a good complement or replacement for C++. Most of the time I'm making something with two major loops: game logic and rendering. Because of the way go interacts with C++ it's not hard to do the game logic in go, where I get massive benefit from "free" concurrency and pretty nice execution speed and then render in C++ where you can get back down to pointer arithmetic if you have to. This is outside of supporting any kind of scripting api/ide which I typically don't deal with but just for familiarity's sake and expecting others to use it later I would probably do in python.
Engine in C/C++ and logic/controls in Python (or Lua) seems to be a common architecture. Lets you have machine speed at the core and human speed elsewhere. Creates an easy way to do a 3rd party scripting interface while you're at it. (If you think performance demands won't be high, you could just write the whole thing in Python and optimize the most-used parts out to C after profiling.)
I think Go is interesting for games, given modern CPU architecture. It could potentially rock the socks off in a game engine, but it's not been done yet. A commercial game developer would have to be pretty daring to try; an open source game would be safer.
The biggest barrier for most studios is the current investment in C++. The majority of engines and most associated libraries are written in C++. Regarding the libaries, it's possible to write C wrappers around the C++ APIs and then access them through cgo, but the developer time required likely isn't worth it.
I'm hoping that a smaller studio will create some proof-of-concept, but we'll see. There was an interesting kickstarter for a game written in Go that ultimately failed, giving the language quite a bit of bad press in the community (http://www.kickstarter.com/projects/2066438441/haunts-the-ma...).
The biggest barrier for most studios is the current investment in C++. The majority of engines and most associated libraries are written in C++. Regarding the libaries, it's possible to write C wrappers around the C++ APIs and then access them through cgo, but the developer time required likely isn't worth it.
I'm hoping that a smaller studio will create some proof-of-concept, but we'll see. There was an interesting kickstarter for a game written in Go that ultimately failed, giving the language quite a bit of bad press in the community (http://www.kickstarter.com/projects/2066438441/haunts-the-ma...).
Like others have said, your best bet is to probably build your framework in C++, and use a scripting language (e.g. python) for the high level game dynamics. I see no reason to use C. C# will probably get you fighting with mono. Java may have issues if you have high graphics requirements (you really don't want to GC pause for 50ms).
D is link-compatible with C, and it allows you to go as low-level as you wish.
Yet D also supports all the latest/greatest language features, and can be used to write high-level script-style code.
D is clean, simple, and is a high-productivity language.
D is what C++ should have been, and eliminates the complexities and problems of C++, without detracting from its expressiveness.
There is no better choice than D.