2011: Current And Future Programming Languages For Videogames(c0de517e.blogspot.com)
c0de517e.blogspot.com
2011: Current And Future Programming Languages For Videogames
http://c0de517e.blogspot.com/2011/04/2011-current-and-future-programming.html
6 comments
The more I see of Rust the more I like it. Sometimes C is just too low level and C++ has gotten unwieldy. C++'s stranglehold on systems programming needs to end.
I've actually done a fair amount of thinking (and even a little implementation) on this topic so I'll share my thoughts.
I've come to the conclusion that my ideal 'game programming' language would actually be 3 different languages that are tightly coupled. It would consist of the following:
- A low level language, similar to c/c++/d
- A scripting language that is tightly coupled with the low level language.
- A scripting preprocessor that's run as a preprocessor for the low level language (effectively replacing templates and the C preprocessor)
Low Level Language:
Games need to be fast, that's why they're written in C or C++. At the end of the day, when you're trying to squeeze those extra cycles out of your console, you need to be able to have precise control over how your data structures are arranged in memory, how things get copied around, what data is preloaded into the cache, etc.
It's okay for this language to be garbage collected, but the programmer needs to have full control over the garbage collector, ideally the garbage collector is of a variety that doesn't require stop-the-world collection. You'd probably also want manual memory management to be an option.
Scripting Language:
In game development, having a low-cost for iteration is also extremely important. If it takes your game designers 20 minutes to tweak something simple, the end product is likely not going to be very good. This is where scripting languages come in, you load all your resources (textures, models, etc) and then you iterate on the game logic without having to load everything from scratch. Loading can actually eat a very large portion of your development time if you don't have hot-reload or your game logic doesn't exist in script.
By tightly integrated I mean make the two languages intimately aware of each other's details. They each need to know how the other is storing data, it needs to be _simple_ (as in just a keyword simple) to call into and out of one from the other. This way the way they communicate can be fast, and a lot of the process can be automated by the compiler so you don't have to do it by hand.
A cool thing here would be having the ability to compile the scripting language to assembly or the low level language when it's time to lock things down for ship.
Scripting Preprocessor:
Embedding scripting languages into lower level languages can be a bit of a pain. In C++, you have a code generator do it, you use templates, or you do it by hand.
Templates are way too complicated for what they accomplish (code gen), the preprocessor is usually used in the same way (code gen). If you're not using these two methods to generate code you've probably written a code generator in an external scripting language that's parsing your C/C++ (yuck) and spitting out C/C++.
What we need is a preprocessor that is actually a scripting language in its own right. The scripting preprocessor gets run before the low level compiler, and just spits out code in the low level language. You have to jump through hoops to 'loop' or 'if' with templates, it's about time we gave ourselves a fully featured language to do our meta-programming in.
I've come to the conclusion that my ideal 'game programming' language would actually be 3 different languages that are tightly coupled. It would consist of the following:
- A low level language, similar to c/c++/d
- A scripting language that is tightly coupled with the low level language.
- A scripting preprocessor that's run as a preprocessor for the low level language (effectively replacing templates and the C preprocessor)
Low Level Language:
Games need to be fast, that's why they're written in C or C++. At the end of the day, when you're trying to squeeze those extra cycles out of your console, you need to be able to have precise control over how your data structures are arranged in memory, how things get copied around, what data is preloaded into the cache, etc.
It's okay for this language to be garbage collected, but the programmer needs to have full control over the garbage collector, ideally the garbage collector is of a variety that doesn't require stop-the-world collection. You'd probably also want manual memory management to be an option.
Scripting Language:
In game development, having a low-cost for iteration is also extremely important. If it takes your game designers 20 minutes to tweak something simple, the end product is likely not going to be very good. This is where scripting languages come in, you load all your resources (textures, models, etc) and then you iterate on the game logic without having to load everything from scratch. Loading can actually eat a very large portion of your development time if you don't have hot-reload or your game logic doesn't exist in script.
By tightly integrated I mean make the two languages intimately aware of each other's details. They each need to know how the other is storing data, it needs to be _simple_ (as in just a keyword simple) to call into and out of one from the other. This way the way they communicate can be fast, and a lot of the process can be automated by the compiler so you don't have to do it by hand.
A cool thing here would be having the ability to compile the scripting language to assembly or the low level language when it's time to lock things down for ship.
Scripting Preprocessor:
Embedding scripting languages into lower level languages can be a bit of a pain. In C++, you have a code generator do it, you use templates, or you do it by hand.
Templates are way too complicated for what they accomplish (code gen), the preprocessor is usually used in the same way (code gen). If you're not using these two methods to generate code you've probably written a code generator in an external scripting language that's parsing your C/C++ (yuck) and spitting out C/C++.
What we need is a preprocessor that is actually a scripting language in its own right. The scripting preprocessor gets run before the low level compiler, and just spits out code in the low level language. You have to jump through hoops to 'loop' or 'if' with templates, it's about time we gave ourselves a fully featured language to do our meta-programming in.
I've had my eye on D for a few years. But, I never manage to work it into the grand plan. For scripting, I have a slimmer of hope for Rite, from Matz (of Ruby).
Strangely, IMO, I find most of my fellow gamedevs are not PLgeeks.
Strangely, IMO, I find most of my fellow gamedevs are not PLgeeks.
In the off-chance that you've not seen this talk by Tim Sweeney: http://lambda-the-ultimate.org/node/1277
Yep, have definitely seen it. Thanks!
Although I've just started learning it, Haskell seems to be a worthy language for games (even has PPC support?). Even as a low-level "scripting" language of sorts, using FFI...although I'm not sure how easy it is to bind with C++ at the moment.
I was surprised to see CLI listed as the current champ for games instead of c++. Is it really widely used on other consoles, or for non-windows games?
Is Unity and XNA enough to crown CLI as king?
Is Unity and XNA enough to crown CLI as king?
Even more odd is that he crowns the CLI as king over Java because it "does not have any technological advantage over [CLI]." The he turns around and lists Mono as a C# advantage over the JVM.
I have zero love for the Java programming language but the JVM is the platform at this point. Everything from Java, to Clojure, to Ruby run on the JVM. You also get the wealth of the Java libraries (though, admittedly, are enterprise-y). There is also the culture around these two platforms that makes me scared of the CLI as a 'best of breed' platform.
I have zero love for the Java programming language but the JVM is the platform at this point. Everything from Java, to Clojure, to Ruby run on the JVM. You also get the wealth of the Java libraries (though, admittedly, are enterprise-y). There is also the culture around these two platforms that makes me scared of the CLI as a 'best of breed' platform.
The champ among "higher-level languages" (but not "scripting") only.
Vala could be a contender on the "system languages" list -- it's runtime is just GLib, which has already been ported to all sorts of platforms and optimized quite well, and Vala is quite a nice language in and of itself.
http://live.gnome.org/Vala
Also, I don't think he gives the game-oriented scripting languages quite enough credit. They're not as mature as Lua, but almost all of them seem like more likely competitors with Lua than Stackless Python or Io, much less Tcl or Javascript (all of which except V8 are slower than Lua, and when Lua's performance is already an issue that's not encouraging) -- most of the game-oriented languages solve one of the biggest Lua gripes quite handily, which is that Lua's exclusive use of floating-point arithmetic makes it a pain (okay this is hearsay) on ARM-based platforms without floating point units (which is most of them). The good news is that LuaJIT now has a port to powerpc along with the mainstream i386 and amd64 ports, and to my knowledge an arm port of the interpreter is in the works as well.
http://live.gnome.org/Vala
Also, I don't think he gives the game-oriented scripting languages quite enough credit. They're not as mature as Lua, but almost all of them seem like more likely competitors with Lua than Stackless Python or Io, much less Tcl or Javascript (all of which except V8 are slower than Lua, and when Lua's performance is already an issue that's not encouraging) -- most of the game-oriented languages solve one of the biggest Lua gripes quite handily, which is that Lua's exclusive use of floating-point arithmetic makes it a pain (okay this is hearsay) on ARM-based platforms without floating point units (which is most of them). The good news is that LuaJIT now has a port to powerpc along with the mainstream i386 and amd64 ports, and to my knowledge an arm port of the interpreter is in the works as well.
I'm thinking about mailing a dead fish to Microsoft HQ for every time I see the term CLI used on a web page and it's the .NET thing and not the should-have-been-well-known--to-them-already abbreviation for command line interface. And don't get me started on the names .NET or C# either (sharp? really? when serious programmers/sysadmins already would have expected hash or pound? really?!).
Other than that, good article. Nice little survey and perspective.
Other than that, good article. Nice little survey and perspective.
Pretty silly to expect exclusivity on three-letter acronyms. There are only so many of them to go around.
(If "serious programmers/sysadmins" are such dull people as to be taken aback by cultural references to anything outside their jobs, so much the worse for them!)
(If "serious programmers/sysadmins" are such dull people as to be taken aback by cultural references to anything outside their jobs, so much the worse for them!)