> Lets count the number of comercial sucesful released games that don't use mutability or object orientation....
1) I suspect game engines that Carmack designed towards the end of his career are built in a largely-functional style. He's on record [0] as thinking that writing code in a functional style is generally a good thing to do.
2) Running on the BEAM doesn't mean that you give up mutability. In my experience with Erlang, functions that return updated state are very, very, very common. Similarly, functions that mutate state external to the function [1] are also common... it's rare that a program that has no visible effect on the outside world is useful.
It's generally quite a lot easier to understand what your program does when most or nearly all of its functions take input and return output without mutating external state as a side effect.
[0] There's some Twitter thread of his that I CBA to find saying -in effect- "Writing in a functional style makes your code much easier to understand. Obviously, if you're writing a video game, you have to pass around pointers for efficiency reasons, but that doesn't preclude writing most of your code in a functional style."
[1] Such as in an ETS table, a external database, with a network call to a remote system, or even writing data to disk.
Oddly enough, you can write in a functional style in most any programming language. It's true!
And (as a fun fact) did you know that Crash Bandicoot, Jax and Daxter, and many other Naughty Dog games were written in Lisp? I expect that more video games sold at retail back in the day were -whether entirely or just in part- written with weird languages and runtimes than we would expect.
But, to answer your question: I don't pay much attention to who's doing what in video games, so I don't know for sure. Folks often talk about using Erlang for video game servers, but not so often about video game frontends.
I do know that Erlang's said to be a pretty bad fit for -say- 3D video games that require high raw performance. Sections 1.3 and 1.4 of the Erlang FAQ [0][1] provide a decent idea of the sort of things for which it is and is not a good fit. Particularly relevant would be these excerpts:
What sort of applications is Erlang particularly suitable for?
Distributed, reliable, soft real-time concurrent systems.
...
What sort of problems is Erlang not particularly suitable for?
...
The most common class of 'less suitable' problems is characterised by performance being a prime requirement *and* constant-factors having a large effect on performance. Typical examples are image processing, signal processing, sorting large volumes of data and low-level protocol termination.
...
Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic.
But you should really read those sections of the FAQ for yourself (while remembering that they were written like twenty years ago).
Also relevant is this excerpt from Learn You Some Erlang's introduction chapter in the "Don't drink too much Kool-Aid" section, written in ~2010: [2]
Erlang is no silver bullet and will be particularly bad at things like image and signal processing, operating system device drivers, etc. and will shine at things like large software for server use (i.e.: queues, map-reduce), doing some lifting coupled with other languages, higher-level protocol implementation, etc. Areas in the middle will depend on you. You should not necessarily wall yourself in server software with Erlang: there have been cases of people doing unexpected and surprising things. One example is IANO, a robot created by the UNICT team, which uses Erlang for its artificial intelligence and won the silver medal at the 2009 eurobot competition. Another example is Wings 3D, an open source 3D modeler (but not a renderer) written in Erlang and thus cross-platform.
Having said that, I play a lot of video games. Based on what I've seen, I expect that most indie video games these days could easily eat the constant factor introduced by using Erlang for coordination.
Having said that, with the existence of Unity and Unreal Engine, along with the documentation and assets built for both, why would you?
[1] Those FAQ sections have remained largely unchanged for something like twenty years. Computers have gotten much faster (and the Erlang VM and compiler have gotten much better) over that time, making the "constant factors" introduced by Erlang smaller than they once were.
> The example you gave about how functional laguages can make comercial videogames...
No. As I said:
> I expect that more video games sold at retail back in the day were -whether entirely or just in part- written with weird languages and runtimes than we would expect.
I can't find any.