
If C++ is so bad, what should game developers use? - abddlt
For example, is C# really a good choice when developing on Mac or Linux?
C is too low-level.
======
jccooper
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.

~~~
zachlatta
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...](http://www.kickstarter.com/projects/2066438441/haunts-the-manse-
macabre)).

------
jacobquick
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.

------
FellowTraveler
The best language is D.

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.

------
asmman1
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.

------
informatimago
Why, Common Lisp of course! cf. Naughty Dog. irc://irc.freenode.org/#lispgames
[http://lispgames.org/](http://lispgames.org/)

------
ddp
John Camack has some interesting things to say on this,
[http://functionaltalks.org/2013/08/26/john-carmack-
thoughts-...](http://functionaltalks.org/2013/08/26/john-carmack-thoughts-on-
haskell/) and
[http://www.reddit.com/r/haskell/comments/1g1mvx/john_carmack...](http://www.reddit.com/r/haskell/comments/1g1mvx/john_carmack_on_haskell_today/)
.

------
Locke1689
I don't think there's a good answer to this right now.[1]

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.

------
bl0cky
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.

------
frankohn
I've got the impression that the D programming language is gaining some
popularity for game programming but I'm not really sure about that.

------
chris_va
What kind of game? How many developers?

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).

------
mscottmcbee
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.

------
conductor
> 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.

~~~
abddlt
Why is it not good particularly for gamedev?

~~~
conductor
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.

~~~
green7ea
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.

------
bendmorris
Haxe ([http://haxe.org/](http://haxe.org/)) is a great language, and it
compiles to C++ and flash, among other targets.

------
saejox
C++ is not bad. Code backend in c++ and use a scripting library for your game
logic.

------
adultSwim
ATS

------
fuj
Who said C++ is bad?

