Is this much different from croquet.io?
Reflect – Multiplayer web app framework with game-style synchronization
121–130 of 159 posts
Re: Reflect – Multiplayer web app framework with game-style synchronization
#122As someone who's casually been eyeing up CRDTs for two years I've wondered continually what the story for authorization is, and this article seems to suggest (in line with my own understanding) that a CRDT library on its own like Y.js can't really handle applications where mutations need to be checked for authorization because it lacks a central authority (i.e., the server) while Reflect assumes that a server will be…
One way to do authorization is to sign each operation/message and then verify the signature to match a public key in an access control list. This also enables CRDTs to work in a peer to peer context.
But as aboodman says in a sibling comment, if there’s a server as an authority, it can simply reject messages from unauthorized clients.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#123Looks great for a hobby project. Has anyone done the cost + risk assessment of building a for-profit product on top of this? Would love to know, as I am working on a web IDE with collaboration. There’s also the matter of obscuring client data from 3rd and even 1st party.
A risk assessment? Just go and try it out in a prototype and see if you can make money with it. You can always replace it once successful.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#124When will it finally be possible to use UDP protocol within browsers?
TCP got way too big overhead. A multiplayer engine in which you send 30 messages per second for 128 users is what i need. Not possible with websockets withput having super computers.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#125When will it finally be possible to use UDP protocol within browsers? TCP got way too big overhead. A multiplayer engine in which you send 30 messages per second for 128 users is what i need. Not possible with websockets withput having super computers.
WebRTC makes this possible, but server implementations are quite difficult to set up. I recommend you check out Pion (Golang) as a good implementation that's also easy to deploy and integrate with Node (presumably your game server is implemented in JS).
Re: Reflect – Multiplayer web app framework with game-style synchronization
#126The demo at the top of the homepage ( https://reflect.net/ ) is a lot of fun. While I was watching, every time the puzzle got completed, people would shake their cursor in excitement, like saying, "yay we did it!!"
I don't think this demo is a good demonstration of the features this library can offer. Once you grab a piece, you seem to lock it for only you to use? This means there are no conflicts to resolve, the only conflict is when two people pick a piece at the same time, from which the only resolution is to give it to the user that picked the piece first. I'd want a demo that shows a much better example of conflicts occuri…
Are you sure about that - when I landed on that page, folks were moving pieces around but didn't recognize that they had to fill up the ALIVE text - and I was able to easily grab a piece that another user had grabbed before and place it in the text - which triggered a eureka moment among other players and we finished the puzzle...
Re: Reflect – Multiplayer web app framework with game-style synchronization
#127Earlier quoted context omitted.
Hi! Thanks for the thoughtful question. >List operations just work: Fair point. Will change. What I really meant here was "(Many) list operations just work" (just like above I said "all kinds of things just work". > All updates reach the server at the same time. What is the solution to that? Timestamps? Fallback to LLW? There are a number of issues you might be pointing out, and I'm not sure which one you mean. In ge…
>nothing can fix this Exactly. >For these problems, undo and presence indicators go a long way to avoid these problems through human/social mechanisms. x1,000 to this. This guy builds . That's exactly my takeaway as well from years working on this; provide a solid (by that I mean clearly defined) deterministic algo, and solve the rest w/ UX.
If you actually look at how people use most multiplayer editing tools they tend to avoid conflicts anyway. It’s extremely painful to have two people editing the same sentence in Google Docs let alone more than that even if it sort of works. Collaboration tends to be negotiated so you end up with I-go-you-go, reviews and other patterns forming around the use of the tools. People can also see and resolve conflicts in real-time.
That said this sort of reconciliation can be extremely painful if people are working separately offline for any length of time as arbitrarily resolving many conflicts doesn’t necessarily result in coherent results. But as I understand it that’s also an issue for other ways of solving the issue as well.
Another missing piece is signalling failure. For example two people trying to fill the last slot of a limited resource. Having to infer from the state that comes back whether your operation succeeded or not is not a fun way to write multiplayer code.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#128I worked extensively on this (also implemented it on JS) about 15 years ago, to escape boredom while on my grandma's place. I wish I had open sourced something, but back then I was a young boy with no ulterior motivations :^). Anyway, I want to comment on this: >For example, any kind of arithmetic just works: Of course, it is extremely trivial to set those up as idempotent operations. >List operations just work: Nope…
In a collaborative application the server could resolve the three operations in any order. The three users observe the result, realize that they are operating on the same data at the same moment and messed with the state. Then they fix it. Think about editing a document.
If they can't see each other working on the data together they could be surprised but they could eventually fix the data to the desired state.
If they don't check the result or can't check the result, the state won't be OK. However it's not what probably happens in interactive apps like collaborative editing or games.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#129For reference, this strategy is called "deterministic lockstep" in the gamedev world, and is used especially often in games which have many entities which need their state synced. The canonical example is rtses, which pretty much all use it.
Hey wheybags, this is not deterministic lockstep. That is an algorithm for peer-to-peer games, where each peer waits for the input from all other players before advancing the game simulation. The deterministic part is because players share inputs (not simulation results) AND the simulation is deterministic for the same inputs. The lockstep part is because all clients advance at a coordinated pace. The Age of Empires…
Yes, I know there's some differences in what you're doing here from classic deterministic lockstep, but the fundamental concept of syncing a queue of inputs from which the game state can be derived, instead of syncing the game state itself is the same, which is why I mentioned it.
Also, while deterministic lockstep can be used peer to peer, it is not fundamentally a peer to peer model. Factorio for example, uses server authoritative deterministic lockstep, and has lag compensation (but only for certain actions like movement).
Re: Reflect – Multiplayer web app framework with game-style synchronization
#130When will it finally be possible to use UDP protocol within browsers? TCP got way too big overhead. A multiplayer engine in which you send 30 messages per second for 128 users is what i need. Not possible with websockets withput having super computers.
Why does TCP have so much overhead? 30 messages that you don't batch is 30 packets either with TCP or UDP.