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?
"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.
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.
I second that. Having spent almost a decade writing commercial C++ code, I recognize everything horrific about the language as documented in the FQA.
The thing is, it doesn't matter. The fact that it's the leading language in your domain is much more important than its abstract quality. Availability of libraries, co-workers who understand it, examples of how to solve common domain problems in the language, these all outweigh the pitfalls and ugliness of the syntax.
Don't be seduced by the language wars. It's like spending days optimising a function that only takes 10% of your run time. Unless you're interested in the learning exercise (which I'm not knocking if you have time) pick one of the dominant languages in your domain, and spend your time worrying about everything else.
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?
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.
Personally, I would like to see a commercial game developer use FORTH.
from: http://www.economicexpert.com/a/Forth:programming:language.h...
"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."
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.
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 ...
yay! Python + PyOpenCL + ... is on my shortlist for the next project.
D is a dream to program in. The templates, especially, are so much nicer than C++ that I hate coding in C++ for a few days after doing D. OTOH, it's the same thing wrt runtime. Why spend a few days getting other people's crappy wrapper code working, FOR EACH LIBRARY, when you already know how to use, debug, and optimize those libraries for C/C++. It wastes a lot of time!
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.
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)
Lua is pretty popular because it is a simple scripting language that you can either run in an interpreter, or compile to C. The interpreter is easily embeddable, and you can call C functions from it. All of this makes for pretty rapid development without sacrificing speed for the things that it is suitable for.
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.
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.
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++.
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.
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 :-)
A Scheme compiling down to C for game development? That sounds incredibly fun! Gambit even looks mature. (I did some Common Lisp but have no experience with Scheme... wtf, no Scheme books on my mysafari?!)
Damn you, pusher! I don't have time for hobbies! Uhm, I mean -- thanks for a really informative post. :-)
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).
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.
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.
[+] [-] Maro|16 years ago|reply
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|16 years ago|reply
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|16 years ago|reply
[+] [-] petewarden|16 years ago|reply
The thing is, it doesn't matter. The fact that it's the leading language in your domain is much more important than its abstract quality. Availability of libraries, co-workers who understand it, examples of how to solve common domain problems in the language, these all outweigh the pitfalls and ugliness of the syntax.
Don't be seduced by the language wars. It's like spending days optimising a function that only takes 10% of your run time. Unless you're interested in the learning exercise (which I'm not knocking if you have time) pick one of the dominant languages in your domain, and spend your time worrying about everything else.
[+] [-] derefr|16 years ago|reply
[+] [-] omouse|16 years ago|reply
You can justify using any language by saying that. Such a vague statement.
[+] [-] timr|16 years ago|reply
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|16 years ago|reply
from: http://www.economicexpert.com/a/Forth:programming:language.h... "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|16 years ago|reply
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|16 years ago|reply
[+] [-] JabavuAdams|16 years ago|reply
D is a dream to program in. The templates, especially, are so much nicer than C++ that I hate coding in C++ for a few days after doing D. OTOH, it's the same thing wrt runtime. Why spend a few days getting other people's crappy wrapper code working, FOR EACH LIBRARY, when you already know how to use, debug, and optimize those libraries for C/C++. It wastes a lot of time!
[+] [-] ginkgo|16 years ago|reply
[+] [-] kazuya|16 years ago|reply
[+] [-] mrshoe|16 years ago|reply
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|16 years ago|reply
[+] [-] s-phi-nl|16 years ago|reply
[+] [-] Meatshoes|16 years ago|reply
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] henrikschroder|16 years ago|reply
[+] [-] JulianMorrison|16 years ago|reply
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|16 years ago|reply
[+] [-] olliesaunders|16 years ago|reply
[+] [-] chipsy|16 years ago|reply
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|16 years ago|reply
[+] [-] pmjordan|16 years ago|reply
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...
[+] [-] huhtenberg|16 years ago|reply
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 :-)
[+] [-] berntb|16 years ago|reply
Damn you, pusher! I don't have time for hobbies! Uhm, I mean -- thanks for a really informative post. :-)
[+] [-] InclinedPlane|16 years ago|reply
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|16 years ago|reply
[+] [-] danek|16 years ago|reply
i haven't used either, just conjecturing based on what i've heard through the grapevine.
[+] [-] ygd_coder|16 years ago|reply
[+] [-] aceofspades19|16 years ago|reply
[+] [-] artsrc|16 years ago|reply
[+] [-] wicknicks|16 years ago|reply
[+] [-] mark_l_watson|16 years ago|reply
C++ is fine when you need high performance and can live with more expensive development.
[+] [-] iamwil|16 years ago|reply
http://love2d.org/