
Ask HN: If C++ is so bad, what should game developers use? - olliesaunders
I've been reading some of the C++ hate that's been on HN of late. I've been successfully convinced (not that it was hard) that C++ is a really terrible language. But, if that's the case, then what else are commercial game developers to use? Is pure C sufficient? What about Haskell, or is that too slow?
======
Maro
"C++ sucks" because it is widely used, its socio-techical landscape is well
explored, _including_ the "sucks" segment. In other words, most other
languages suck as much as C++, they're just not that widely used, or have not
been around as much.

If you're writing your own game project you can use a sane, minimalistic and
syntactically pleasing subset of C++ and gain all the pedal-to-the-metal
advantages. Don't discard C++ because other people say it is terrible. Other
people are usually wrong. Make up your own mind.

For example, the Keyspace code is organized into classes; we use inheritance
and polymorphism; we use templates in a few select cases; but we completely
avoid exceptions, operator overloading (actually operators) and the STL
altogether (we implement our own containers). It doesn't matter what others
think about this specific subset - it works for us, we work well in this
formalism, make few mistakes and produce good code that runs fast.

~~~
dkarl
Very good points. Since C++ is a good match for the way people are taught to
think about programming, it's obvious that anything good programmers can't
easily and consistently get right is the fault of the language. With Haskell,
you can't rule out unfamiliarity as the cause of any difficulties until you're
already heavily invested in it. Most people really have no basis for
challenging the statement that Haskell is perfectly suited for game
programming in the hands of a competent programmer.

Pragmatically, for the OP, I think it's safe to say that C++ and Haskell are
both very challenging languages that take a long time to master. The advantage
of C++ is that there's ample evidence of its suitability for various domains.
The advantage of Haskell is that you'll learn a different way of programming.
The decisive factor may be whether it's your own money on the line.

------
ComputerGuru
Don't let them scare you away... C++ is fine if you use what you need and take
the time to actually understand the tools you're using.

~~~
derefr
Why is C++ suddenly "fine" when you have no other options? There could easily
be a language with all the close-to-the-metal advantages and none of the
baroque, redundant complexity of C++; why must we be content to use the same
language as everyone else in the industry, rather that scratching this itch
and building a newer, more productive one?

~~~
eli
"Newer" isn't necessarily better or more productive. Especially given the
monumental task of having to write a game without the benefit of any of the
libraries developed over the past few decades.

Perhaps the reason there are no other viable options is because C++ is pretty
well suited to the task?

~~~
derefr
Why would you have to lose the libraries? .so files are .so files; it doesn't
matter what language they were written in, as long as they expose an API that
can be cleanly wrapped by your own language.

~~~
nicolas314
... and a standard ABI, otherwise you will never be able to link. C++ did not
have standard name-mangling conventions until recently, which forced you to
use the very same compiler to compile both your libraries and your own code.
This is still unfortunately very much a concern with all these legacy systems
out there. Your only solution is to expose your API as a C library or
distribute your source code.

------
timr
If you let the language trolls on proggit and HN convince you that you _must_
avoid C++ -- particularly whatever 'subset' of C++ scratches your itch with
minimal complexity -- you've made a classic pointy haired boss mistake:
letting the whims of the crowd make a technical decision for your project.

Don't buy into the nonsense. C++ is a fine language. People have been using it
for _decades_ to do real work, and they probably still will be in another two
decades, long after Ruby and Haskell and Blub have been discarded as 'archaic'
by the next generation of 20-year-old language snobs.

------
csmeder
Personally, I would like to see a commercial game developer use FORTH.

from:
[http://www.economicexpert.com/a/Forth:programming:language.h...](http://www.economicexpert.com/a/Forth:programming:language.htm)
"Forth became very popular in the 1980s because it was well suited to the
small microcomputers of that time: very efficient in its use of memory and
easily implemented on a new machine. At least one home computer, the British
Jupiter ACE, had Forth in its ROM-resident OS. The language is still used in
many small computerized devices (called embedded systems) today for three main
reasons: efficient memory use, shortened development time, and fast execution
speed.

Forth is also infamous as being one of the first and simplest extensible
languages. That is, programmers can easily extend the language with new
commands appropriate to the primary programming problem in the particular
application area. Unfortunately, extensibility also helps poor programmers to
write incomprehensible code. The language never achieved wide commercial use,
perhaps because it acquired a reputation as a "write-only" language after
several companies had product failures caused when a crucial programmer left.
In addition, the ease of implementing Forth on a given processor meant that
the barrier to self-development of a Forth system was quite low, so that
commercial suppliers were, in effect, competing head-to-head with hobbyists,
many of whom supported the idea that software should be free."

------
miloshh
You're right, C++ pretty much has no serious alternatives for games. And not
just games, anything that involves computer graphics, physical simulation,
computer vision or image processing.

Python is excellent if some good soul has already written a library that does
exactly what you need (in C or C++, obviously). The combination of
numpy+PyOpenGL+PyCUDA is great for certain kinds of research projects (I have
written a volume renderer in it) but probably far from commercial usability.

Haskell has great potential, but the community is too small and too academic
to produce the necessary libraries and tools (which is a lot of work with
minimal scientific content). The key problem is the absence of an industrial-
strength array facility - there are many kinds of arrays in Haskell, all
somewhat clunky and incomplete.

D might be a contender, but last time I looked the tools seemed very basic and
it did not even support 64-bit systems.

~~~
zentux
I absolutely agree !! I hate C++ too, but as you said , there is no real
alternative for it. Mixing C and python is a good idea ,but real world
applications in my area (computer vision) use C++ widely ...

------
ginkgo
There is a very interesting talk by Tim Sweeney to this topic: <http://lambda-
the-ultimate.org/node/1277>

~~~
kazuya
His point about fp appears to get no traction in video game developers around
me. I heard some iPhone app developers are trying to use Haskell to create
games, though.

~~~
fpgeek
They are. Ryan Trinkle (one of the developers behind this) gave a talk about
why they are using Haskell (echoing Tim Sweeney's talk, but adding his own
perspective) at a meeting of BostonHaskell. Among other things, they've made a
custom iPhone cross-compiler port of GHC that is quite impressive (in the
waltzing bear sense)

Since their basic approach is applicable to other platforms, it will be
interesting to see if GHC ends up with clean, extensible support for mobile
cross-compilation in the future.

------
mrshoe
C++ violates the Zen of Python's axiom that "explicit is better than implicit"
all over the place. C does not; it is very explicit.

I would write as much as possible in Python and use C for the performance
critical stuff (which, for a game, is a large portion).

~~~
nickpp
I see that you would, but have you? Or did _anybody_?

~~~
mrshoe
I have worked on major console games and written games in both C and C++. I
also maintain an open source raytracer which I've implemented in C, C++, D,
and python. So yes, I speak from experience.

Eve online is a great example of a game for which almost all game logic is in
python (stackless). The "engine" is in C++, I think (not sure on that one). So
I would adopt their model but use C instead of C++.

~~~
bd
Also Civilization 4 used Python extensively:

<http://www.python.org/about/quotes/> (look for "Firaxis Games")

------
s-phi-nl
I am under the impression that Lua is widely used for video games.

~~~
Meatshoes
Lua is often used as an embedded scripting language within level editors, for
example to keep track of the progress made on a quest or to trigger an event
when the character reaches a certain point. Lua isn't used to code the game
engine itself (in the vast majority of cases, there may be some obscure
examples of game engines written in Lua)

~~~
kiba
You need some LÖVE!

<http://libregamewiki.org/LOVE>

"LÖVE is a cross-platform, 2D game engine. The latest version of the engine is
0.5.0 released on September 9th, 2008.[1] It uses the SDL library, OpenGL
hardware acceleration and the Lua programming language to program games.[2] It
is licensed under the Zlib license. "

------
JulianMorrison
I'm not sure how ready it is now, but Haskell's nested data parallelism might
be worth looking into as a forward strategy for things like physics and in-CPU
graphics engines, since it should make very effective use of many-core
processors and is expected to later (transparently) gain the ability to
distribute work onto the GPU. This is if you want to do something more fancy
than OpenGL, such as ray-trace or use splines.

Haskell's extreme facility with small light threads and its implicit parallel
"strategies" could also make updating a rule based game board an almost
mathematical, rather than detail-grovelling exercise.

You will not be able to get monkeys to program in Haskell. Whether this is a
problem depends on your plans.

------
Fargren
XNA is great, but your games will only be compatible with windows(and xBox).
Haskell is definetely not a good idea.

~~~
olliesaunders
Why is Haskell a bad idea?

~~~
Fargren
Well, for once, it's not particulary fast, but that's not a concern for all
games(it's not slow either, but it's quite hard to optimize). The real deal is
that it's a completely functional language with not much support, as far as
games go. You won't find any graphics libraries, so you'll have to make them
from scratch. Unless you have been programing in funcitonal languages for a
long time, this will take an absurd ammount of time, and you probably won't be
able to do it at all. Haskell is great for math-oriented programs, but I
wouldn't recommended for much else, in my opinion.
<http://hackage.haskell.org/> is suppossed to be a good source for libraries,
if you are intersted, but I can't get it to load.

~~~
gaius
_You won't find any graphics libraries, so you'll have to make them from
scratch_

Haskell has OpenGL bindings: <http://www.haskell.org/haskellwiki/Opengl>

So does OCaml: <http://glcaml.sourceforge.net/>

~~~
substack
I've used Haskell's OpenGL libraries some, and definitely recommend them over
C++. OpenGL's callbacks feel much more natural in a functional language and
the monadic do notation works very well at managing nested matrix
transformations. Also, having an interpretive shell to play around with the
types of functions is very useful.

------
chipsy
I would take a data-oriented view.

Most of the performance of a game stems from finding a sweet spot combination
of data structures and data relationships so that data is processed at real-
time rates, is accessible everywhere, and can be immediately applicable to the
algorithms you plan to use.

If you design relationships-first, the way you would design a database, you
can figure out a data layout that doesn't involve any high-level semantics to
speak of, just classic data structures from CS: lists, arrays, graphs and
trees to order things, records and hashes to name them. Go through each type
of value and cross-index it across all the structures it needs to be accessed
by.

Then write intersectable queries into the structures to express a complex
gameplay question like "Find all the enemy actors that are near mission
objective X" as the composable "Find positions between boundaries A,B,C,D,
that belong to actors of the enemy type, where A,B,C,D are some distance
relative to the position of the objective entity with the name of X." Since
you aren't writing a generic all-purpose database, this isn't a _hard_
problem. It's just time-consuming to nail down the data model that captures
all of it.

I think you will agree that a fancy language isn't necessary to implement such
an approach to game programming. Done that way, data mostly ends up being
pointers.

If your game is processing-light(which with today's desktop hardware primarily
means avoiding 3d computation), you don't need a fast language: I'm most
familiar with doing game code for Python and Flash and they can do just fine
on modestly-sized datasets too.

------
jomohke
The D programming language [<http://www.digitalmars.com/d/>] was designed
primarily to be a better C++. It has C-style syntax, a vaguely similar OO
model to Java, and compiles directly to machine code, with performance as
priority (it even allows you to drop to assembly if desired). The lack of C
backwards compatibility allowed them to clean up a lot of the uglier areas of
C++.

------
pmjordan
I've been contemplating this, too. C++ was my main language for a long time
(~1999-2007) and about 30% of my consulting work is still in C++ (game
development). I've found that while C++ code can be very clean and concise, it
usually requires a lot of behind the scenes scaffolding, and it's very easy to
get wrong even if you know the damn thing inside out. Programming in more
expressive languages has certainly improved the quality of my C++ code, but
there's only so much you can do.

My use of other languages has therefore gradually increased - I currently use
Clojure where I can, but I'm pretty flexible (PHP being the only language on
my blacklist so far).

For projects on which I'm a lone programmer, I'm free to use whatever language
I want in theory; sometimes the customer has a preference, usually not, so the
main restrictions are technical and legal:

I'd like to use Clojure a lot more, but for game dev, it's problematic.
Performance is the least of my worries, as I can drop to Java or even JNI for
the rough bits. It's also a fantastic choice for server-side programming on
multiplayer games. However, the JVM isn't allowed on the iPhone, say, and
unrealistic or disallowed on consoles. (the Nintendo DS has 4MB of RAM, for
example; licensing/porting is an issue) For pure PC/Mac game dev it's probably
fine, although if by any chance you want to port later, good luck.

There was a submission on HN a few months back about using Gambit Scheme for
iPhone and Mac programming. Googling easily retrieves some useful information
on this, but the general idea is that it compiles to C, and you can actually
write Scheme functions with inline C/C++/Objective-C code, so you're using a
2-stage compilation process and retain full control while using a very
expressive high-level language. I'm going to try this with my next iPhone
game, as I'm not all that impressed with Objective-C so far. It looks
extremely promising.

There are of course other languages which have compilers that generate C; I
believe there are some Common Lisp implementations, although especially for
game dev I'm not sure if there's any advantage in using CL over Scheme.

If using a full-blown Lisp feels too high level, there are some Lispy efforts
that are essentially very fancy C preprocessors, e.g. BitC[1] or SC[2]. The
latter is literally C with an S-Expression syntax; I'd be interested how
compactly all of C++'s features could be expressed in such a language. Not
that you'd want the arcane contortions of C++ templates when you have real
macros.

Moving away from C a bit more, there are of course Forth and other languages
in a similar vein.

As I've mentioned, I'll be going down the Gambit Scheme route in future
projects, as it has a very nice interface to C/C++ (this is critical when
dealing with game development oriented libraries - I'd probably make this the
top priority in choosing a language for this purpose), it's very stable and
mature, and it's a Lisp. I'll try and write a postmortem of some sort when the
time comes.

My main worry is the behaviour of GC in an environment with hard memory limits
(no virtual memory or paging), but if the allocator and GC are well written it
should be less risky than explicit memory management.

[1] <http://www.bitc-lang.org/>

[2]
[http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index-e.htm...](http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index-e.html)

~~~
huhtenberg
Same here, except that after using C and C++ for over a decade I find
switching to another language quite trying. The habit of constantly thinking
what machine code is generated from the higher language constructs is _really_
hard to ignore.

Moreover, I actually like C. But it is inconvenient. On the other hand C++ is
convenient, but I don't like it. So I started playing with developing a
dialect of C that adds support for parametrized code, closures, _this_ pointer
and type inference. All the stuff that I use or would like to use in C++, but
in a syntactically cleaner way and without all the blubber that C++
accumulated through a design by committee. A hobby project, nothing too fancy
:-)

~~~
pmjordan
I had the problem of worrying about low-level nuts and bolts for a while too;
I guess it must have been the jarring difference in expressiveness between C++
and Lisp that made me stop worrying in the end. I don't think you can
realistically wean yourself from C++'s mind pollution gradually - you have to
go cold turkey and go with a high level language, dynamic typing, garbage
collection, not especially object oriented, etc. Do a couple of smaller
projects with a language like that and you'll probably find that you don't
really want that "better C++" of yours after all.

~~~
huhtenberg
> _you don't really want that "better C++" of yours after all_

I want it because it is an interesting project in itself. But I hear what you
are saying.

------
InclinedPlane
C++ isn't bad, per se. It's an incredibly powerful and rich language, verging
on being a meta-language that allows you to create your own language. However,
that flexibility is a double edged sword. Just like Perl or Javascript, any
powerful, flexible language can, and will, be abused.

The main downfall of C++ is probably that it's too flexible in every
direction. It takes an equivalent amount of effort to do the "right" thing as
to do the "wrong" thing. In a sense, the language makes no value judgments
regarding design. Which is helpful in some ways because it doesn't lock you
into the straight-jacket that Java does, for example, but it doesn't encourage
users to fall into a "pit of success" either (which a truly good language
should, even if it is ultimately flexible enough to let you do those "wrong"
things).

------
nova
I think it's more that although C++ sucks there is no realistic alternative
for this "niche".

------
danek
what about D or OCaml? OCaml can compile to machine code and supposedly can
acheive c++ level performance. D is allegedly a "fixed" c++.

i haven't used either, just conjecturing based on what i've heard through the
grapevine.

------
ygd_coder
Contrary to popular belief. Java is actually pretty good.

~~~
aceofspades19
I suppose if you like over-engineering

~~~
ygd_coder
Over-engineering? You're confusing me with one of those guys that has to do a
UML diagram before he can start coding.

~~~
aceofspades19
I was mostly referring to the language. The standard library that comes with
Java is over-engineered to the point of absurdity

~~~
lincolnq
Not _quite_ to the point of absurdity. I kinda like it. Admittedly, I dislike
it when I have to instantiate four classes to read the contents of a file. But
I have also used the same flexibility to great advantage, and been burned in
other languages when the standard library wasn't flexible enough.

~~~
aceofspades19
What languages are these? because I have never used a language where the
standard library was not flexible enough.

------
wicknicks
C++ is definitely not a terrible language. It was one of the first OO
programming mostly widely adopted (though today there are far better ways of
doing OO with other programming languages). The problem with higher level
languages is their performance. C++ sits somewhere between C and languages
like Java, Python. I would say its probably a good place to program games
which are both memory and CPU intensive.

------
mark_l_watson
I used C++ when I worked on game AI and a few Nintendo U64 games, also for
some virtual reality stuff for Disney and SAIC. Right choice for the games, in
retrospect probably not for VR.

C++ is fine when you need high performance and can live with more expensive
development.

------
iamwil
Depends on what kind of games you want to make. If you're looking for 2D
platforms, try Actionscript or Lua Love.

<http://love2d.org/>

------
jibiki
What kind of game are you writing? If you're just a hobbyist, you might want
to try a popular choice like python. (Pygame is insanely well known.)

~~~
olliesaunders
I edited the original post. I'm interested in commercial game projects. Real
games, the kinds that you see in shops for PS and XBox etc.

~~~
smakz
If you are interested in making games for consoles you are pretty much
restricted to what the console maker's software development kit supports,
which is usually C/C++. It's usually impractical to reverse engineer the
hardware and supply your own system libraries in another language.

Computer games are another story, but the same facts are generally true, that
you should use the language which provides the libraries where most of the
work is already done for you. There are the most number of game development
kits for C++, so that's why C++ is popular for game development.

For what it's worth, I have done a few games using the ORGE rendering engine
and plugged the game elements (physics, AI) with separate libraries and it has
worked fairly well.

<http://en.wikipedia.org/wiki/OGRE>

<http://en.wikipedia.org/wiki/Havok_(software)>

<http://en.wikipedia.org/wiki/Box_2D>

~~~
plinkplonk
"If you are interested in making games for consoles you are pretty much
restricted to what the console maker's software development kit supports,
which is usually C/C++. "

Unless you want to write a lisp using that c/c++ sdk and then develop with the
lisp you wrote. (<http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp>).
So it certainly _can_ be done. Whether you _should_ is another matter.

Post acquisition (by Sony) Naughty Dog seems to have shifted to c++ but seems
to have shifted back partially to lisp (C++/ scheme combo as far as I can make
out) for their "Uncharted" games for the
PS3.([http://www.naughtydog.com/docs/Naughty-Dog-
GDC08-Adventures-...](http://www.naughtydog.com/docs/Naughty-Dog-
GDC08-Adventures-In-Data-Compilation.pdf) Warning PDF)

------
zandorg
I'd code the graphics code in C++, and the logic/game/AI code in Lisp.

------
Dilpil
What other languages are out there that compile into machine code?

~~~
anamax
> What other languages are out there that compile into machine code?

It used to be that almost all languages compiled into machine code.

And you, get off my lawn.

------
gord
any mix of : C, python, lua, scheme

------
bonecandy
Wait a couple of years and you can use MacRuby ;D

------
Zarathu
C

------
thras
I'm with you. Whatever you use, don't choose C++. Sure, everyone on your
programming team knows C++ already. Yeah, your libraries are all written in
it. And successful games have used it again and again. But if it's not one of
the "cool" languages, you shouldn't be using it.

Modern game developers should code in Ruby/Lisp. By the time you've finished
coding all of your graphics libraries from scratch, Moore's law will have made
computers fast enough to run them.

~~~
derefr
Wait, so why can't you use the C++ libraries from Ruby/Lisp?

~~~
thras
I think that best thing to do is look at 1) the libraries you'll be using, 2)
what your team is proficient at, 3) what's worked for other groups, 4)
optimization potential.

If you think that Ruby/Lisp is your answer to the above points, go for it. But
I have the feeling that it won't be for many people.

~~~
derefr
I didn't say I wanted to use Ruby or Lisp--I was simply denying the parent's
point that one would have to "write the graphics libraries from scratch."

Besides, isn't the advice for optimizing _every_ other kind of project:

1\. Start in a high-level language

2\. Port any bits that profile as slow to a low-level language, and then
interface them into your HLL code

Why, all of the sudden, when you're coding a game, is it a better idea to
_start_ in the low-level language? Because your team "knows it?" by that
argument, all games would still be being developed in assembler, because the
most senior members of the team would have more experience with that than any
new-fangled language like C++.

~~~
miloshh
That advice never works. The problem is _data structures_. If your high-level
prototype uses complex data structures of e.g. Python, you will not be able to
access them from C++. You will need to rewrite the whole thing anyway.

The only way you might get away with this approach is if your application is
essentially a number of separate scripts that communicate through files. Then
you can rewrite the key scripts in C++. But that is never the case for games.

~~~
lutorm
Part of Civ IV (mostly gui stuff) is in python. They seem to be able to
communicate with the C++ core fine.

~~~
miloshh
But I assume they did not write the game in Python and the optimize parts in
C++. Quite the opposite - they wrote it in C++ and then found that some part
(e.g. GUI) is growing in complexity while not being crucial for performance,
at which point it is a good decision to use a scripting language for it.

That is a pretty common approach, but what was suggested above (writing first
in HLL and then rewriting parts in C++) is, to my knowledge, never done in
practice.

