Happy to answer any questions as a customer :)
Reflect – Multiplayer web app framework with game-style synchronization
61–70 of 159 posts
Re: Reflect – Multiplayer web app framework with game-style synchronization
#62Anyway, 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 ... or at least, I'd have to take a closer look at your implementation, consider:
Some sort of array/list that looks like: [1, 2, 3, 4, 5]
* User A deletes the range from 2-4.
* User B deletes the range from 3-5.
* User C inserts (uh-oh) something between 3 and 4.
All updates reach the server at the same time. What is the solution to that? Timestamps? Fallback to LLW? This breaks the transactional model.
Pick any of those updates as "the winner", what do the other users see? How do you communicate this to them?
If your answer is like "we just send them the whole array again", this breaks the transactional model (x2).
Re: Reflect – Multiplayer web app framework with game-style synchronization
#63Earlier quoted context omitted.
Hey Matlin, it's true that this approach is harder to implement, but that's a one-time cost, and it's one we take on for our users and they don't have to worry about.
Also just as an FYI we do have this running live at https://reflect.net and https://hello.reflect.net/examples at 120 FPS. We are targeting 100 concurrent users at 120 FPS. Not completely there, but it is certainly achievable, and we will scale back framerate when we need to.
Maybe this is a bit out of scope of what the goal is for this project but just thought I would bring it up.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#64Re: Reflect – Multiplayer web app framework with game-style synchronization
#65This is a pedantic comment, but the terminology is confusing. Games have "players" so their sync systems are called "multiplayer," but regular software has "users" so their sync systems should be called "multiuser." The page reads strangely mixing the terms "user" with "multiplayer."
On the other hand all web software is "multiuser", which doesn't tell you anything.
Re: Reflect – Multiplayer web app framework with game-style synchronization
#66I 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…
Re: Reflect – Multiplayer web app framework with game-style synchronization
#67The 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!!"
Re: Reflect – Multiplayer web app framework with game-style synchronization
#68I 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…
Most of these systems do deletes with tombstones. Then you can safely insert after/inbetween deleted items.
a) [1, 5]
or
b) [1, , 5]
?
Re: Reflect – Multiplayer web app framework with game-style synchronization
#69Re: Reflect – Multiplayer web app framework with game-style synchronization
#70Earlier quoted context omitted.
Most of these systems do deletes with tombstones. Then you can safely insert after/inbetween deleted items.
Is the solution to that, a) [1, 5] or b) [1, , 5] ?
Most likely this would be implemented with a single mutator for each element. But if you implemented a "range delete", then it would depend on what the order of arrival was. Notably, the server has to sequence actions somehow, so there isn't going to be an issue of "all actions arriving at the same time". If C arrived last in that case, the new element would be there. But if C arrived first, you'd just be left with [1].