I've been making games for ~30 years, and I'm always curious about how people like to apply functional concepts to game development...and yet, when I look at this, I think "Why?"
As far as I can tell, it just starts out with a React tree and then says "put the game in the middle part." Meaning that how you write the game is almost orthogonal to any of React's key concepts like one directional data flow. Except that things like collisions seem to be handled at the global level, meaning that you have to filter them back down to the individual objects involved -- which is strictly worse than letting objects respond to their own collisions, and encourages the creation of "god objects" at the top level that are completely opaque.
There are far more capable game engines out there, ones that give you sprites, canvas or WebGL rendering, and far more sophisticated control of game objects.
Basically all game engines work in a "display the current state" manner (except for old school "put your draw function here" engines like Love2d), and many have built in physics abstractions as well. Can't see any reason to use React for something it's clearly not well matched to.
You're spot on. This doesn't seem like something built to actually build games. The reasoning here seems almost backwards.
This seems like shoehorning technology where it needn't be. Instead of approaching the problem from the perspective of, "I'd like to build games," it was approached from, "I'd like to use React," followed by, "... and build a game." Canvas / WebGL are far, far better suited.
As somebody who started with game development in Visual Basic, it reminds me of the first game I made on a VB form, moving pictures around over the default grey background. My eyes were opened to the DirectX APIs shortly thereafter, realizing I should scrap pretty much everything I'd built.
That said --- all innovation and experimentation is great. I'm sure the author worked very hard and I'd be interested to see what games they've built with it (that would certainly be more convincing than a README)!
Edit: Found a demo in the other comments. Neat-o. :)
I understand you. But you're taking this way too seriously. People don't do things hoping it becomes the next Unity. Sometimes they do it because they can. To have fun. To experiment. And Ken Wheeler is definitely that kind of person.
In any case, these explorations are important. They are small experiments showing us new ideas.
Mind not blown. It looks to me like an old PC-XT CGA game. If you want to experiment with making games on the web, you're much better off, I think, using something like http://www.pixijs.com/ Just the landing page is way more mind blowing than that React "game" demo.
That is not mind blowing. Sorry. Also is pretty broken on Firefox, unfortunately, but even looking at it on Chrome, and looking at the far too verbose setup for, well, everything, compared to how things work in a game engine?
Maybe it's useful to React developers who have never seen game engine concepts. Most web developers have zero idea of how games are developed, after all, and teaching them a little bit about how to develop a game is going to expand their minds. Sure, that's a good thing.
But I haven't even scratched the surface of how many things are missing from React Game Kit, any of of which would be a showstopper. As another comment mentions, Pixi.js [1] is incredibly more useful in all ways.
It's a cute "Look at the bears dance!" demo, and criticizing the bears for not dancing well is possibly beside the point. But I also feel it needed to be said that no, one should not pick this up and try to use it as a game development platform. This is Hacker News, a site with lots of web developers who have never made a game or seen a game engine, and they may mistake the dancing bears for a ballet if they've never seen the latter.
On chrome there's a bug showing the console that's preventing it from going beyond the start screen.
On Firefox when using the arrow keys to read through the next, a single click renders two screens of text too quickly for me to read the first of them.
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:
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.
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.
> 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.
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
>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"
I can't even fathom the reasoning here. I'm using react in a game, but it's strictly a ui thing. You know, the thing react is designed for. The game is completely orthogonal, as you said.
I would think that maintaining a "world state" data structure and then dynamically generating the render tree based on the contents of the world state would be a much better logical fit for using React.
I'm curious about functional approaches to game programming. I don't have those ~30 years of experience though.
One of the key differences between React and an Entity Component system is that React encourages a single source of state to be passed into the top of the tree, and then that state filters down to leaf components. A component can be said to only be coupled to the abstract contracts of its children.
What I understand of an Entity Component system is that entities are largely responsible for managing their own state. From what I've seen, this leads to a fair bit of undesirable code, with entities trying to discover state from other entities, leading to some unfortunate coupling.
I might be wrong though, so would be interested to hear if that's the case, and if anyone knows of any pointers to interesting approaches.
> So in a way this is game programming without the concept of time.
A. You can't have a real time game without the concept of time. If you're making a turn based game, time is ignored equally in a traditional game engine.
B. Most game engines that have a built-in physics engine abstract away time to the exact same degree that React Game Kit does. Everything is about responding to collision events, applying forces, spawning animations, etc.
I have a game development background. Did 8 years of C/C++ games for PCs/Consoles. I then switched to web/server development. I've thought of doing something similar as I'm super into React/Redux, but....
Redux can be used without react, just rendering your game graphics all the time is fine, a moving game basically causes that to happen anyway. I think taking something like Pixi.js and using redux for your app state container would give you all the hot code reloading you need.
I'd maybe vote for using React for your settings/menus and such, but then again Pixi.js is going to give you much richer, and faster rendering APIs.
I've often thought React would be perfect for creating games with. Even attempted my own framework similar to this using the canvas but it fell down when it came to rendering. I felt like React really didn't suit the update/render loop approach. It doesn't seem to talk about it on the project page so I wonder how this works. Using the DOM?
I had a quick look into the code base, and it is indeed targeting the DOM, rather than canvas or webgl. It has a sprite component which is just an absolutely position img element wrapped in a div.
This is cool. I feel like it's more interesting and practical to apply Redux to game development instead of React though. Redux's "Time Travel" idea is really neat - I want to see something like React that acts as a view layer and uses Redux to model game state.
I've been playing around with some ideas like this. It's hard, as most graphics APIs usually have their own concept of bindings and state to maintain. As an example you create a binding to a vertex buffer, and then you need to maintain that over multiple draw calls. It's maybe similar to React maintaining DOM nodes, but the data involved is a lot more complex. I feel like a lot of the work is building abstractions (or the right models) to be able to handle those aspects of graphics programming in a functional and reactive way.
I had a black screen when I first walked into a building. After refreshing, they all started working after I entered the Physics building. They just show a slideshow, then send you back out into the street.
This would be OK for "Powerpoint" games. If it is real time, forget about it. Even real time WebGL kind of sucks on most devices, triggering DOM manipations and repaints isn't going to help.
What are you calling a "'Powerpoint' game"? To me that implies some level of simplicity, but I play plenty of complex games that could be implemented with this. Not that they should be, mind you...
React is the really the ideal rendering engine (though much less optimized than something like Unity). An immediate mode API abstracting over a retained mode renderer lets you think about a program as a state machine, while not sacrificing performance.
He's comparing it to Unity, which makes no sense to me at all. If there was a statement more like comparing apples to oranges, I haven't heard of it yet.
As far as I can tell, it just starts out with a React tree and then says "put the game in the middle part." Meaning that how you write the game is almost orthogonal to any of React's key concepts like one directional data flow. Except that things like collisions seem to be handled at the global level, meaning that you have to filter them back down to the individual objects involved -- which is strictly worse than letting objects respond to their own collisions, and encourages the creation of "god objects" at the top level that are completely opaque.
There are far more capable game engines out there, ones that give you sprites, canvas or WebGL rendering, and far more sophisticated control of game objects.
Basically all game engines work in a "display the current state" manner (except for old school "put your draw function here" engines like Love2d), and many have built in physics abstractions as well. Can't see any reason to use React for something it's clearly not well matched to.