4 ms·

I love Clojure, but isn't a functional language with immutable data structures an odd choice for developing a video game?

by kleiba 2y ago

Vekz 2y ago
High performance real-time games it is questionable. Any genre that is more static turn based can be a great boon.
- resatori 2y ago
  Check it out, it is handling hundreds of entities at >>60 FPS. And I still did not do much performance optimization (there are still many lazy seqs around and unoptimized code). Also most of the sprite rendering is the main problem, which an atlas texture could also improve even more. (Right now all creature animations are separate texture files). And you can always step down a level to java if the need arises!
  - virtue3 2y ago
    the issue with JVM/java was always that when that GC triggers you are just absolutely hosed. C# tends to be a bit more forgiving about when it triggers GC and how. The generational garbage collector in C# will tend to be more reliable or at least I never ran into super huge issues with the places I've used C# for game dev. The JVM GC has this unfortunate effect of having very bad pauses occasionally. And appears to do so regardless of the type of GC you are using. There are some techniques you can use to get around this -> re-using entities. Using C# structs. Not doing allocations/deallocations inside the main game loop if you can. For small enough games it is irrelevant but as soon as you start to get a larger game with lots of memory allocations/deallocations it really crushes performance.
    - kleiba 2y ago
      Minecraft is written in Java, it doesn't look like the choice of platform kept it from becoming a success.
      - jsheard 2y ago
        It was however completely rewritten in C++ when they needed to port it to more constrained platforms, every mobile and console version uses the C++ codebase while PC has both versions in parallel. If you ever intend to release your game on multiple platforms then Minecraft isn't an example to follow unless you're up for starting over from scratch at some point.
        pjmlp 2y ago
        A side effect from specific platforms not allowing Java, and Microsoft buying Mojang. Notch surely isn't sorry for having coded it in Java.
        jsheard 2y ago
        It worked out for Notch, sure, but most indie devs don't get the luxury of only considering console ports after they're already set for life from initially only releasing on PC. Planning for cross-platform from the start is table stakes, especially now the Switch has become just as if not more of a popular platform for indie games than PC is.
        pjmlp 2y ago
        Most indie devs already strike gold if they manage one platform at all. Too much is wasted on what language, or engine to use, instead of what actually make as a game. And even when everything is done right, it is a drop in the ocean of daily released titles.
      - mrkeen 2y ago
        Bad performance did delay one of the big new-biome-type releases in the Java version.
      - SkiFire13 2y ago
        If anything using Java made it extremely moddable and is IMO part of the reason why it became a success.
    - jay_kyburz 2y ago
      Unity's new incremental gc saved our bacon.
  - lupire 2y ago
    60 FPS of 3D objects in a 3D world?
resatori 2y ago
I find it very natural to work with because clojure is based on the JVM so the project uses libgdx under the hood (deploys to all platforms, huge library) and I can use lisp for everything else to do basically anything. Combined with clojures way of handling immutable datastructures so well & the excellent protocol system (https://www.freshcodeit.com/blog/clojure-protocols-and-the-expression-problem https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...) I could separate the whole game easily into separate components.
- kleiba 2y ago
  Sorry, but I feel like your comment does not actually address my concern of whether having to deal with immutable data structures in a functional way would lend itself especially well to video games. Of course, the Clojure approach is great for a lot of use cases, but video games traditionally do a lot of mutable changes to components. That doesn't mean, of course, that it cannot be done any other way, but it would certainly be a different approach.
  - resatori 2y ago
    I don't understand your concern. Would you mind phrasing it differently?
    - deleted 2y ago
      [deleted]
  - kleiba 2y ago
    Oh, and allow me to add: I'm not criticizing, I'm just putting a possible concern out there for discussion. That's why my original post was worded as a question.
  - kelseyfrog 2y ago
    It's important to keep in mind that Clojure uses persistent data structures. It's easy for folks with a background in other languages to assume that immutable data structures require a deep copy to modify when in fact they don't. In my experience, it slightly favors wide rather than deep game state because wide game state implies fewer nodes that need to be re-created when creating a new state. Since the author is using ECS, it's probably wide enough already. A bit more in the weeds and if one was using a deep game state, careful structuring of assoc-in and update-in calls might be warranted. Ideally each node would only be copied once to arrive at the next game state. Sometimes it can be more efficient to build a list of changes and then property sequence the application of the changes to the state. At the end of the day, people don't have to use a single atom like the author either. A game state can consist of multiple mutable data structures. It's not like the Clojure-police are going to arrest anyone for it.
runeblaze 2y ago
It's not that weird -- your next AA game or AAA game will probably not use it, but in React (reducer, or Redux), very interactive stuff, immutability is often seen. Also Clojure has better performance prospects than Ruby and Python, both have seen "real" usage in commercial indie games.
- Jare 2y ago
  It's a lot easier to embed Python than Clojure. Oldest examples I recall are Severance: Blade of Darkness by Rebel Act Studios, and (coincidence, nothing to do with the previous) Blade 2 by Mucky Foot, about 25 and 22 years ago.
dagmx 2y ago
Tim Sweeney seems to be betting that’s the direction with UEFN where Verse is a more approachable take on Haskell.
thesuperbigfrog 2y ago
It is completely possible and has interesting trade-offs. Here are some of my favorite blog entries related to functional game development: https://prog21.dadgum.com/228.html https://prog21.dadgum.com/228.html https://prog21.dadgum.com/23.html https://prog21.dadgum.com/23.html https://prog21.dadgum.com/24.html https://prog21.dadgum.com/24.html https://prog21.dadgum.com/25.html https://prog21.dadgum.com/25.html https://prog21.dadgum.com/26.html https://prog21.dadgum.com/26.html
- sph 2y ago
  After doing functional programming for a while now (6 years of Elixir) it seems obvious to me that it is possible and no more complex than using imperative logic. In fact I would go so far as to say that managing complexity (i.e. state) is much easier to do in a functional style than imperative. Functional is all about transformation of data structures, and a game is nothing more than a function that takes {state, mouse, keyboard} as input and returns {new_state, output} where output is a set of Vulkan commands, or pixels that you bitblt to screen. Rinse and repeat in an vsynced infinite loop. I think the linked articles above betray the fact that they were written 15 years ago when functional programming was a niche quasi-academic idea and no one was used to building stateful programs with it. 15 years ago it was all about Java and C++. Lisp was as forgotten as it is today. In 2024 most above average programmers have experience in functional logic, and it is not that arcane of an idea. The reason that it is not widely adopted is that functional programming is not as performant as imperative semantics, and you need all the speed you can get. On the other hand, imperative often means buggy mess as game complexity grows and painful debugging session trying to understand who and why changed this state variable.
  - smellybigbelly 2y ago
    Could an expert strong man the argument that functional programming languages like Haskell could in theory be more performant than C because of the nice properties of pure functional languages?
    - sph 2y ago
tinyspacewizard 2y ago
Functional Programming hasn't even been tried for game development, really. There is a lack of overlap between the game dev industry and academia. The studios are (rightly) risk averse and try to use the same broad strategies to build games - OOP, maybe ECS for large swarms, etc. Personally, I think that FP could be a great fit, but we first need to come up with architectures that solve real game development problems. We have to do this with small scale experiments first (game jams are perfect for this) and then scale up only if they succeed. This project is exactly that - kudos to the author.
- CyberDildonics 2y ago
  Game programmers are mostly extremely skilled and well aware of functional languages, how they work and what they do. They aren't using them because they aren't a good choice for delivering games that need to run fast and consistently in real time. Immutable data structures and garbage collection might be nice for people writing something, but that isn't what someone buying software wants, they want smooth and fast.

I love Clojure, but isn't a functional language with immutable data structures an odd choice for developing a video game?

by kleiba 2y ago

I love Clojure, but isn't a functional language with immutable data structures an odd choice for developing a video game?

Vekz 2y ago

High performance real-time games it is questionable. Any genre that is more static turn based can be a great boon.

resatori 2y ago
Check it out, it is handling hundreds of entities at >>60 FPS. And I still did not do much performance optimization (there are still many lazy seqs around and unoptimized code). Also most of the sprite rendering is the main problem, which an atlas texture could also improve even more. (Right now all creature animations are separate texture files). And you can always step down a level to java if the need arises!
- virtue3 2y ago
  the issue with JVM/java was always that when that GC triggers you are just absolutely hosed. C# tends to be a bit more forgiving about when it triggers GC and how. The generational garbage collector in C# will tend to be more reliable or at least I never ran into super huge issues with the places I've used C# for game dev. The JVM GC has this unfortunate effect of having very bad pauses occasionally. And appears to do so regardless of the type of GC you are using. There are some techniques you can use to get around this -> re-using entities. Using C# structs. Not doing allocations/deallocations inside the main game loop if you can. For small enough games it is irrelevant but as soon as you start to get a larger game with lots of memory allocations/deallocations it really crushes performance.
  - kleiba 2y ago
    Minecraft is written in Java, it doesn't look like the choice of platform kept it from becoming a success.
    - jsheard 2y ago
      It was however completely rewritten in C++ when they needed to port it to more constrained platforms, every mobile and console version uses the C++ codebase while PC has both versions in parallel. If you ever intend to release your game on multiple platforms then Minecraft isn't an example to follow unless you're up for starting over from scratch at some point.
      - pjmlp 2y ago
        A side effect from specific platforms not allowing Java, and Microsoft buying Mojang. Notch surely isn't sorry for having coded it in Java.
        jsheard 2y ago
        It worked out for Notch, sure, but most indie devs don't get the luxury of only considering console ports after they're already set for life from initially only releasing on PC. Planning for cross-platform from the start is table stakes, especially now the Switch has become just as if not more of a popular platform for indie games than PC is.
        pjmlp 2y ago
        Most indie devs already strike gold if they manage one platform at all. Too much is wasted on what language, or engine to use, instead of what actually make as a game. And even when everything is done right, it is a drop in the ocean of daily released titles.
    - mrkeen 2y ago
      Bad performance did delay one of the big new-biome-type releases in the Java version.
    - SkiFire13 2y ago
      If anything using Java made it extremely moddable and is IMO part of the reason why it became a success.
  - jay_kyburz 2y ago
    Unity's new incremental gc saved our bacon.
- lupire 2y ago
  60 FPS of 3D objects in a 3D world?

resatori 2y ago

I find it very natural to work with because clojure is based on the JVM so the project uses libgdx under the hood (deploys to all platforms, huge library) and I can use lisp for everything else to do basically anything. Combined with clojures way of handling immutable datastructures so well & the excellent protocol system (https://www.freshcodeit.com/blog/clojure-protocols-and-the-expression-problem https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...) I could separate the whole game easily into separate components.

kleiba 2y ago
Sorry, but I feel like your comment does not actually address my concern of whether having to deal with immutable data structures in a functional way would lend itself especially well to video games. Of course, the Clojure approach is great for a lot of use cases, but video games traditionally do a lot of mutable changes to components. That doesn't mean, of course, that it cannot be done any other way, but it would certainly be a different approach.
- resatori 2y ago
  I don't understand your concern. Would you mind phrasing it differently?
  - deleted 2y ago
    [deleted]
- kleiba 2y ago
  Oh, and allow me to add: I'm not criticizing, I'm just putting a possible concern out there for discussion. That's why my original post was worded as a question.
- kelseyfrog 2y ago
  It's important to keep in mind that Clojure uses persistent data structures. It's easy for folks with a background in other languages to assume that immutable data structures require a deep copy to modify when in fact they don't. In my experience, it slightly favors wide rather than deep game state because wide game state implies fewer nodes that need to be re-created when creating a new state. Since the author is using ECS, it's probably wide enough already. A bit more in the weeds and if one was using a deep game state, careful structuring of assoc-in and update-in calls might be warranted. Ideally each node would only be copied once to arrive at the next game state. Sometimes it can be more efficient to build a list of changes and then property sequence the application of the changes to the state. At the end of the day, people don't have to use a single atom like the author either. A game state can consist of multiple mutable data structures. It's not like the Clojure-police are going to arrest anyone for it.

runeblaze 2y ago

It's not that weird -- your next AA game or AAA game will probably not use it, but in React (reducer, or Redux), very interactive stuff, immutability is often seen. Also Clojure has better performance prospects than Ruby and Python, both have seen "real" usage in commercial indie games.

Jare 2y ago
It's a lot easier to embed Python than Clojure. Oldest examples I recall are Severance: Blade of Darkness by Rebel Act Studios, and (coincidence, nothing to do with the previous) Blade 2 by Mucky Foot, about 25 and 22 years ago.

dagmx 2y ago

Tim Sweeney seems to be betting that’s the direction with UEFN where Verse is a more approachable take on Haskell.

thesuperbigfrog 2y ago

It is completely possible and has interesting trade-offs. Here are some of my favorite blog entries related to functional game development: https://prog21.dadgum.com/228.html https://prog21.dadgum.com/228.html https://prog21.dadgum.com/23.html https://prog21.dadgum.com/23.html https://prog21.dadgum.com/24.html https://prog21.dadgum.com/24.html https://prog21.dadgum.com/25.html https://prog21.dadgum.com/25.html https://prog21.dadgum.com/26.html https://prog21.dadgum.com/26.html

sph 2y ago
After doing functional programming for a while now (6 years of Elixir) it seems obvious to me that it is possible and no more complex than using imperative logic. In fact I would go so far as to say that managing complexity (i.e. state) is much easier to do in a functional style than imperative. Functional is all about transformation of data structures, and a game is nothing more than a function that takes {state, mouse, keyboard} as input and returns {new_state, output} where output is a set of Vulkan commands, or pixels that you bitblt to screen. Rinse and repeat in an vsynced infinite loop. I think the linked articles above betray the fact that they were written 15 years ago when functional programming was a niche quasi-academic idea and no one was used to building stateful programs with it. 15 years ago it was all about Java and C++. Lisp was as forgotten as it is today. In 2024 most above average programmers have experience in functional logic, and it is not that arcane of an idea. The reason that it is not widely adopted is that functional programming is not as performant as imperative semantics, and you need all the speed you can get. On the other hand, imperative often means buggy mess as game complexity grows and painful debugging session trying to understand who and why changed this state variable.
- smellybigbelly 2y ago
  Could an expert strong man the argument that functional programming languages like Haskell could in theory be more performant than C because of the nice properties of pure functional languages?
  - sph 2y ago

tinyspacewizard 2y ago

Functional Programming hasn't even been tried for game development, really. There is a lack of overlap between the game dev industry and academia. The studios are (rightly) risk averse and try to use the same broad strategies to build games - OOP, maybe ECS for large swarms, etc. Personally, I think that FP could be a great fit, but we first need to come up with architectures that solve real game development problems. We have to do this with small scale experiments first (game jams are perfect for this) and then scale up only if they succeed. This project is exactly that - kudos to the author.

CyberDildonics 2y ago
Game programmers are mostly extremely skilled and well aware of functional languages, how they work and what they do. They aren't using them because they aren't a good choice for delivering games that need to run fast and consistently in real time. Immutable data structures and garbage collection might be nice for people writing something, but that isn't what someone buying software wants, they want smooth and fast.