6 ms·

Does game programming require C++? Ocaml can be just as performant, and Clojure might also be a good candidate (high-level functional programming, potential to

Does game programming require C++? Ocaml can be just as performant, and Clojure might also be a good candidate (high-level functional programming, potential to get strong performance). I admit that, for Java, the gain in language expressiveness isn't worth taking the performance hit, because the former is so minimal. On the other hand, moving to a truly high-level language with half-decent performance (e.g. Ocaml, Clojure) might ameliorate the schedule slippages for which that industry is known.

willvarfar 13y ago
I'm part of the small but growing crowd that thinks Javascript is a good way forward, at least for small Indie developers and Ludum Dare entries. There is nothing worse in LD than seeing the voting screen filled with Windows binaries you don't want to download. Here my entry this time if anyone's interested ;) http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=10313 http://www.ludumdare.com/compo/ludum-dare-27/?action=preview...
pandaman 13y ago
The AAA game industry is extremely risk averse - if you are using something it either has to be successfully used before or you need to make a demo that proves its viability. For graphics or physics it's easy to make a demo - you render a spinning buddha or simulate a hundred balls, show how much CPU and GPU it takes and everyone can extrapolate this to the full game. I don't know what could be a sufficient prove of Ocaml viability other than a full game written in Ocaml. I am not familiar with indies or mobile but I imagine, they are even less likely to risk as their chance for success is already pretty low and it would be rather reckless to add more unknowns from an untested technology.
simcop2387 13y ago
I have looked at clojure for doing this somewhat recently (about 8-10 months ago) and the main issue I ran into was lack of bindings to some of the more necessary APIs for doing it these days (SDL, OpenGL, etc.). Some of them existed but were very badly documented/maintained which put me off of it a bit, but I do think that there are some definite things that could be gained with using Clojure at least (Of course you can use the JVM bindings directly, but that was starting to look very ugly as I played with doing so).
- FreezerburnV 13y ago
  While Clojure-esque bindings don't exist (that I know of), you can always just use direct calls to OpenGL functions via the LWJGL library. Even write a nice wrapper around them that could be open-sourced. Clojure has complete interop with Java libraries, remember :) You can also check out the nice wrapper around the Processing library called quil: https://github.com/quil/quil https://github.com/quil/quil
  - vikas0380 13y ago
    Or Try libGDX http://libgdx.badlogicgames.com http://libgdx.badlogicgames.com It is a framework developed around LWJGL for the desktop and also has an Android backend. libGDX lets you use OpenGL without worrying about how OpenGL works.
  - ajuc 13y ago
    Last time I've checked (a few years ago) Penumbra was nice clojure-sque OpenGL wrapper. But it seems it's abandoned. Shame, it was really nice, even had clojure DSL to write shaders. https://github.com/ztellman/penumbra https://github.com/ztellman/penumbra
FreezerburnV 13y ago
While Java might not be as expressive as Clojure, you definitely take an even harder penalty to performance when using it over using Java. And you can gain some pretty strong benefits of using pure Java these days, what with Java 8 having lambdas, streams (parallel and synchronous), and all the wonderful libraries out there that help with concurrency. (RxJava, quasar, etc.) Among other things, such as a very nice wrapper over the OpenGL library. (LWJGL is utterly fantastic) You do lose a nice matrix library (glm) though. Of course, Clojure has wonderful concurrency as well, so you can ameliorate the cost of using Clojure by spinning up more threads. However, games are a tricky thing to parallelize, from what I know. Especially as the only place you can actually make OpenGL calls is from the thread a program is started from. I wouldn't recommend Ocaml for games though. Use Haskell or Go instead. Ocaml might be speedy, but it has a GIL, a la Python or Ruby. Also as far as I've found, there are basically no bindings libraries out there for opening windows or making OpenGL calls. And I might be misremembering, but the libraries that did allow you to use OpenGL used 1.x or 2.x versions, meaning you can't use a modern pipeline.
moconnor 13y ago
Just to dispel a common myth: in general, Ocaml cannot be as performant as C++ today. As far as I'm aware, no Ocaml compiler performs auto-vectorization of loops, which means no SSE for you, leading to a 3-4x slowdown on last-generation CPUs and even more on future CPUs. Vectorization is a big deal if you want to maximize performance. I do agree, however, that this doesn't make C/C++ necessary for game programming. That's probably why modern game engines let you write a great deal of the game logic in a scripting language. Of course, most C++ code I see - even in language performance benchmarks - doesn't vectorize either. g++ isn't particularly good at it and most people don't know how to do it.
- zurn 13y ago
  3-4x game perf differences from CPU code autovectorization sounds way high? From what I've seen you'd be pretty lucky to average 3x speedups on isolated vector-friendly loops with hand rolled ASM, translating to much smaller whole app speedups.
epsylon 13y ago
It depends on which type of games you're talking about. AAA game engines are still all about performance and tight memory budgets due to the nature of the platforms they're developing on - consoles and PCs. Hence the aversion to garbage collected languages, although higher level languages usually make it in the engines as scripting languages for game logic: UnrealScript for UDK, C# and UnityScript for Unity, Lua for CryEngine... The industry is traditionally oriented towards C++ and imperative / OO languages, but there's a lot of potential for functional languages in the "embedded scripting" area. In his 2013 QuakeCon keynote [1], John Carmack talks a bit about his experience with functional languages, and how, for example, Scheme could be an ideal candidate as an embedded scripting language. As far as smaller teams are concerned, and especially indie development, there is a lot of potential for OCaml, Clojure and other functional languages. Many mobile and indie dev teams already use a heck lot of C#, Python, Java and other specialized tools like Haxe, ActionScript. But all these languages have well liked and mature frameworks geared towards game development (XNA / MonoGame, PyGame, OpenFL, libgdx, ...), which is maybe what Clojure and OCaml are missing right now. [1] http://www.youtube.com/watch?v=1PhArSujR_A http://www.youtube.com/watch?v=1PhArSujR_A
ajuc 13y ago
It's hard to write game in a language without side effects, even if you don't care about performance. Games are made in iterative process, you change sth, test, etc. You don't know if something is fun and looks good without testing it. And it's really hard to upfront design for fun. Without side effects most of the time programming in this way is spent maintaining long arguments lists and passing them around to be able to add even very small features. You want to play sound when player leveled up? Pass soundManager through this 7-functions-long callstack. Now you also want to shoot stars around the player on the occassion? Pass this ParticleEffect handle too. Oh, but the effects should vary depending on the region the player is in? Pass that information to that function too. And time of the day, while you're at it, so stars can be blue at night and yellow at day. In the end you give up and pass WorldState variable to every function. I don't think pure functional programming is good for prototyping games. I thought about this problem a little, and I think this could be solved by structuring the WorldState variable into a tree, and writing a script that you run after the game is done, that looks inside functions for which parts of the WorldState they really need, and changing them accordingly, so the code is easy to read and functional after the experiments are done.
- cgag 13y ago
  Just for the record, Clojure has a good system for managing mutable state when you need it, of course has java interop so there's nothing from stopping you from mutating java objects. Edit: Here's a guys experiences from making a game in Clojure a year ago: http://stackoverflow.com/questions/9755882/are-functional-programming-languages-suitable-for-graphics-programming http://stackoverflow.com/questions/9755882/are-functional-pr... http://clojurefun.wordpress.com/2012/09/03/ironclad-steam-legions-clojure-game-development-battle-report/ http://clojurefun.wordpress.com/2012/09/03/ironclad-steam-le...
  - ajuc 13y ago
    Thanks for the links, very interesting. I see the guy behind this had the same problem: > Long parameter lists – I struggled a bit with this, and still don’t have a great solution.
cpeterso 13y ago
Have you seen the slides from Tim Sweeney's "Next Mainstream Programming Language: A Game Developer’s Perspective" talk? Sweeney worked on Epic Games' Unreal engine (C++) and discusses how functional programming could benefit game programmers. He doesn't mention OCaml by name, but he mentions Haskell a couple times. http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... Lambda the Ultimate has more discussion of the talk, including comments from Tim Sweeney: http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277

willvarfar 13y ago

I'm part of the small but growing crowd that thinks Javascript is a good way forward, at least for small Indie developers and Ludum Dare entries. There is nothing worse in LD than seeing the voting screen filled with Windows binaries you don't want to download. Here my entry this time if anyone's interested ;) http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=10313 http://www.ludumdare.com/compo/ludum-dare-27/?action=preview...

pandaman 13y ago

The AAA game industry is extremely risk averse - if you are using something it either has to be successfully used before or you need to make a demo that proves its viability. For graphics or physics it's easy to make a demo - you render a spinning buddha or simulate a hundred balls, show how much CPU and GPU it takes and everyone can extrapolate this to the full game. I don't know what could be a sufficient prove of Ocaml viability other than a full game written in Ocaml. I am not familiar with indies or mobile but I imagine, they are even less likely to risk as their chance for success is already pretty low and it would be rather reckless to add more unknowns from an untested technology.

simcop2387 13y ago

I have looked at clojure for doing this somewhat recently (about 8-10 months ago) and the main issue I ran into was lack of bindings to some of the more necessary APIs for doing it these days (SDL, OpenGL, etc.). Some of them existed but were very badly documented/maintained which put me off of it a bit, but I do think that there are some definite things that could be gained with using Clojure at least (Of course you can use the JVM bindings directly, but that was starting to look very ugly as I played with doing so).

FreezerburnV 13y ago
While Clojure-esque bindings don't exist (that I know of), you can always just use direct calls to OpenGL functions via the LWJGL library. Even write a nice wrapper around them that could be open-sourced. Clojure has complete interop with Java libraries, remember :) You can also check out the nice wrapper around the Processing library called quil: https://github.com/quil/quil https://github.com/quil/quil
- vikas0380 13y ago
  Or Try libGDX http://libgdx.badlogicgames.com http://libgdx.badlogicgames.com It is a framework developed around LWJGL for the desktop and also has an Android backend. libGDX lets you use OpenGL without worrying about how OpenGL works.
- ajuc 13y ago
  Last time I've checked (a few years ago) Penumbra was nice clojure-sque OpenGL wrapper. But it seems it's abandoned. Shame, it was really nice, even had clojure DSL to write shaders. https://github.com/ztellman/penumbra https://github.com/ztellman/penumbra

FreezerburnV 13y ago

While Java might not be as expressive as Clojure, you definitely take an even harder penalty to performance when using it over using Java. And you can gain some pretty strong benefits of using pure Java these days, what with Java 8 having lambdas, streams (parallel and synchronous), and all the wonderful libraries out there that help with concurrency. (RxJava, quasar, etc.) Among other things, such as a very nice wrapper over the OpenGL library. (LWJGL is utterly fantastic) You do lose a nice matrix library (glm) though. Of course, Clojure has wonderful concurrency as well, so you can ameliorate the cost of using Clojure by spinning up more threads. However, games are a tricky thing to parallelize, from what I know. Especially as the only place you can actually make OpenGL calls is from the thread a program is started from. I wouldn't recommend Ocaml for games though. Use Haskell or Go instead. Ocaml might be speedy, but it has a GIL, a la Python or Ruby. Also as far as I've found, there are basically no bindings libraries out there for opening windows or making OpenGL calls. And I might be misremembering, but the libraries that did allow you to use OpenGL used 1.x or 2.x versions, meaning you can't use a modern pipeline.

moconnor 13y ago

Just to dispel a common myth: in general, Ocaml cannot be as performant as C++ today. As far as I'm aware, no Ocaml compiler performs auto-vectorization of loops, which means no SSE for you, leading to a 3-4x slowdown on last-generation CPUs and even more on future CPUs. Vectorization is a big deal if you want to maximize performance. I do agree, however, that this doesn't make C/C++ necessary for game programming. That's probably why modern game engines let you write a great deal of the game logic in a scripting language. Of course, most C++ code I see - even in language performance benchmarks - doesn't vectorize either. g++ isn't particularly good at it and most people don't know how to do it.

zurn 13y ago
3-4x game perf differences from CPU code autovectorization sounds way high? From what I've seen you'd be pretty lucky to average 3x speedups on isolated vector-friendly loops with hand rolled ASM, translating to much smaller whole app speedups.

epsylon 13y ago

It depends on which type of games you're talking about. AAA game engines are still all about performance and tight memory budgets due to the nature of the platforms they're developing on - consoles and PCs. Hence the aversion to garbage collected languages, although higher level languages usually make it in the engines as scripting languages for game logic: UnrealScript for UDK, C# and UnityScript for Unity, Lua for CryEngine... The industry is traditionally oriented towards C++ and imperative / OO languages, but there's a lot of potential for functional languages in the "embedded scripting" area. In his 2013 QuakeCon keynote [1], John Carmack talks a bit about his experience with functional languages, and how, for example, Scheme could be an ideal candidate as an embedded scripting language. As far as smaller teams are concerned, and especially indie development, there is a lot of potential for OCaml, Clojure and other functional languages. Many mobile and indie dev teams already use a heck lot of C#, Python, Java and other specialized tools like Haxe, ActionScript. But all these languages have well liked and mature frameworks geared towards game development (XNA / MonoGame, PyGame, OpenFL, libgdx, ...), which is maybe what Clojure and OCaml are missing right now. [1] http://www.youtube.com/watch?v=1PhArSujR_A http://www.youtube.com/watch?v=1PhArSujR_A

ajuc 13y ago

It's hard to write game in a language without side effects, even if you don't care about performance. Games are made in iterative process, you change sth, test, etc. You don't know if something is fun and looks good without testing it. And it's really hard to upfront design for fun. Without side effects most of the time programming in this way is spent maintaining long arguments lists and passing them around to be able to add even very small features. You want to play sound when player leveled up? Pass soundManager through this 7-functions-long callstack. Now you also want to shoot stars around the player on the occassion? Pass this ParticleEffect handle too. Oh, but the effects should vary depending on the region the player is in? Pass that information to that function too. And time of the day, while you're at it, so stars can be blue at night and yellow at day. In the end you give up and pass WorldState variable to every function. I don't think pure functional programming is good for prototyping games. I thought about this problem a little, and I think this could be solved by structuring the WorldState variable into a tree, and writing a script that you run after the game is done, that looks inside functions for which parts of the WorldState they really need, and changing them accordingly, so the code is easy to read and functional after the experiments are done.

cgag 13y ago
Just for the record, Clojure has a good system for managing mutable state when you need it, of course has java interop so there's nothing from stopping you from mutating java objects. Edit: Here's a guys experiences from making a game in Clojure a year ago: http://stackoverflow.com/questions/9755882/are-functional-programming-languages-suitable-for-graphics-programming http://stackoverflow.com/questions/9755882/are-functional-pr... http://clojurefun.wordpress.com/2012/09/03/ironclad-steam-legions-clojure-game-development-battle-report/ http://clojurefun.wordpress.com/2012/09/03/ironclad-steam-le...
- ajuc 13y ago
  Thanks for the links, very interesting. I see the guy behind this had the same problem: > Long parameter lists – I struggled a bit with this, and still don’t have a great solution.

cpeterso 13y ago

Have you seen the slides from Tim Sweeney's "Next Mainstream Programming Language: A Game Developer’s Perspective" talk? Sweeney worked on Epic Games' Unreal engine (C++) and discusses how functional programming could benefit game programmers. He doesn't mention OCaml by name, but he mentions Haskell a couple times. http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... Lambda the Ultimate has more discussion of the talk, including comments from Tim Sweeney: http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277