4 ms·

I'm not sure if you complain just about React, or about using a functional programming approach to games in general. In case it is the latter, I strongly recomm

by vog 10y ago

I'm not sure if you complain just about React, or about using a functional programming approach to games in general. In case it is the latter, I strongly recommend reading: "A Worst Case for Functional Programming?" http://prog21.dadgum.com/189.html http://prog21.dadgum.com/189.html where the author (also a game programmer for decades) concludes: > Would it be simpler than the OOP version? Probably not. [...] But at one time I would have thought the functional version a complete impossibility, and now it feels like the obvious way to approach these kinds of problems.

lewisl9029 10y ago
Also on the topic of functional/data-oriented game programming, one of my favorites is Chris Granger's Light Table talk, where he talked through the design of a game built in ClojureScript using the Entity Component System architecture: https://www.youtube.com/watch?v=V1Eu9vZaDYw https://www.youtube.com/watch?v=V1Eu9vZaDYw
endergen 10y ago
The elm lang style architecture is very condusive to games. Collision and global state related AI planning not with standing. Though I feel like if you take the idea of a single app data structure, and you make your code deterministic with a clean event loop boundary then you basically get a lot of the redux benefits. Even hot code reloading would be fine, you just need to make sure to wait till the end of each loop before doing anything.
- SomeCallMeTim 10y ago
  > Collision and global state related AI planning not with standing. You're excluding about 50-80% of the actual game logic here you realize? Don't forget optimizations like memory locality [1] for time sensitive components like particle systems, direct messaging between various game elements, physics processing (which often needs to iterate on world state), and any other kinds of interaction where something (like a door) needs to know whether the player that's trying to unlock it has a certain item in their inventory (like a particular key). Or maybe the door only unlocks after a switch in another room has been thrown. Both are trivial in an OO design; a bit ugly in the functional approaches that come to mind. Possible; of course. But why put yourself to the extra effort? Functional is great for UIs; you could probably code the HUD and game menu in Elm. I still think functional languages aren't ideal for predominantly imperative problems. [1] https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design
SomeCallMeTim 10y ago
>about using a functional programming approach to games in general Games are predominantly imperative in structure. Using a functional approach for writing an entire game seems like a bad idea. Can games be written functionally? Of course. Turing Completeness and all that. >"A Worst Case for Functional Programming?" I read the article. If the author didn't claim to have video game development experience I'd question whether he'd ever written a game; his examples imply the kind of AI that would be needed for a real-time game, but you don't just "move a tank" like 10 meters in a physics frame. Best practice has physics running at least 100FPS; probably higher rates like 1000FPS would be better. One tank being 1/1000 of a second farther along than another isn't going to mess with the AI. If the AI is running at a lower frame rate (making decisions only about 5 times per second, or even once per second, could be totally fine) means that the decision will just affect the acceleration being applied -- and would naturally happen in its own phase, so the state of the world would be constant for all participants. Actions like firing shells, if they can be dodged, are best batched as he suggested. But you still have huge problems like how to handle collisions, which is typically best done in some kind of object oriented way, though I've seen some clever pattern matching approaches as well that functional languages could support ("If a [VEHICLE] collides with a [SHELL], then do X; if [WALL] collides with a [SHELL], do Y..."), but even then each action needs to mutate something in the world. Which brings me to the fact that, for any nontrivial game, you pretty much need mutable data in order to get even halfway decent performance; you might be able to get away with lazy modification of a "world" data structure (copying it N times for N interactions in the world is absolutely going to kill game performance), but then you're again passing a "world" around to every single operation that anything can ever do -- and unless I'm wrong, every single "shell" and "tank" in the world is going to need to dig into the structure to find "itself" or the object it's colliding with in order to actually do the thing it needs to do... No, I stand by my assertion. Functional techniques can be useful in games, and I use them. Taking ideas from functional approaches to stabilize the game and simplify the code is an awesome idea. But trying to write a pure functional game is just a bad idea -- or an exercise in watching bears dance [1]. [1] "It's not about how well they can dance, but that they can dance at all"

by vog 10y ago

lewisl9029 10y ago

Also on the topic of functional/data-oriented game programming, one of my favorites is Chris Granger's Light Table talk, where he talked through the design of a game built in ClojureScript using the Entity Component System architecture: https://www.youtube.com/watch?v=V1Eu9vZaDYw https://www.youtube.com/watch?v=V1Eu9vZaDYw

endergen 10y ago

The elm lang style architecture is very condusive to games. Collision and global state related AI planning not with standing. Though I feel like if you take the idea of a single app data structure, and you make your code deterministic with a clean event loop boundary then you basically get a lot of the redux benefits. Even hot code reloading would be fine, you just need to make sure to wait till the end of each loop before doing anything.

SomeCallMeTim 10y ago
> Collision and global state related AI planning not with standing. You're excluding about 50-80% of the actual game logic here you realize? Don't forget optimizations like memory locality [1] for time sensitive components like particle systems, direct messaging between various game elements, physics processing (which often needs to iterate on world state), and any other kinds of interaction where something (like a door) needs to know whether the player that's trying to unlock it has a certain item in their inventory (like a particular key). Or maybe the door only unlocks after a switch in another room has been thrown. Both are trivial in an OO design; a bit ugly in the functional approaches that come to mind. Possible; of course. But why put yourself to the extra effort? Functional is great for UIs; you could probably code the HUD and game menu in Elm. I still think functional languages aren't ideal for predominantly imperative problems. [1] https://en.wikipedia.org/wiki/Data-oriented_design https://en.wikipedia.org/wiki/Data-oriented_design

SomeCallMeTim 10y ago

>about using a functional programming approach to games in general Games are predominantly imperative in structure. Using a functional approach for writing an entire game seems like a bad idea. Can games be written functionally? Of course. Turing Completeness and all that. >"A Worst Case for Functional Programming?" I read the article. If the author didn't claim to have video game development experience I'd question whether he'd ever written a game; his examples imply the kind of AI that would be needed for a real-time game, but you don't just "move a tank" like 10 meters in a physics frame. Best practice has physics running at least 100FPS; probably higher rates like 1000FPS would be better. One tank being 1/1000 of a second farther along than another isn't going to mess with the AI. If the AI is running at a lower frame rate (making decisions only about 5 times per second, or even once per second, could be totally fine) means that the decision will just affect the acceleration being applied -- and would naturally happen in its own phase, so the state of the world would be constant for all participants. Actions like firing shells, if they can be dodged, are best batched as he suggested. But you still have huge problems like how to handle collisions, which is typically best done in some kind of object oriented way, though I've seen some clever pattern matching approaches as well that functional languages could support ("If a [VEHICLE] collides with a [SHELL], then do X; if [WALL] collides with a [SHELL], do Y..."), but even then each action needs to mutate something in the world. Which brings me to the fact that, for any nontrivial game, you pretty much need mutable data in order to get even halfway decent performance; you might be able to get away with lazy modification of a "world" data structure (copying it N times for N interactions in the world is absolutely going to kill game performance), but then you're again passing a "world" around to every single operation that anything can ever do -- and unless I'm wrong, every single "shell" and "tank" in the world is going to need to dig into the structure to find "itself" or the object it's colliding with in order to actually do the thing it needs to do... No, I stand by my assertion. Functional techniques can be useful in games, and I use them. Taking ideas from functional approaches to stabilize the game and simplify the code is an awesome idea. But trying to write a pure functional game is just a bad idea -- or an exercise in watching bears dance [1]. [1] "It's not about how well they can dance, but that they can dance at all"