React Game Kit
github.com
github.com
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.
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. :)
In any case, these explorations are important. They are small experiments showing us new ideas.
Look at this: http://reactnext.surge.sh/
That _is_ React. mind blown
I won't be making a game with it anytime soon. But maybe I'll borrow concepts and ideas from it, and make something else.
So don't worry. Don't let it puzzle you. Just sit back, relax, and stay tuned for what's next.
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.
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.
Building a game declaratively... shudder
Tons of games have been build declaratively. What's the supposed problem with that?
[citation needed]
I'm assuming they mean instead of imperatively. And I'm also assuming they mean something more complicated than a solitaire/card game.
"A Worst Case for Functional Programming?" 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.
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.
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.
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"
And that's also clearly not the target of React Game Kit, or why would there be a physics engine and a real time game loop?
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.
The core idea of react is (simplified) that "time is eliminated"* as mental concept to keep track of.
So in a way this is game programming without the concept of time.
( * Essentially you focus on state and could thus create/display any component in any state )
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.
- https://github.com/Izzimach/react-pixi - https://github.com/Izzimach/react-three
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.
It's also a powerful metaphor for charting - https://github.com/recharts/recharts.
Compared to what?