As soon as VR gaming started, people wanted to interact with objects in multiplayer environment.
The implementation here is extremely valuable. One can go and just make VR volleyball or any other VR application wixh requires multiple people to participate.
If I already didn’t work on VR MP game. I would do VR lego where you can build models out of pieces with other people.
Has been done, lookup Tabletop Simulator and the LEGO mod.
https://steamcommunity.com/sharedfiles/filedetails/?id=96143...
The important issue is that sticking them together is not intuitive, you can stack them, no problem but if you pick up the structure they can slide off. You need to manually stick them together with a tool or some command. Ideally this would be a gesture or button click.
Tabletop Simulator in itself is a nice program for simulating tabletop games, next to Bigscreen it's my go to VR app for board games I love. There are mods chess, card and flicking games and my favorites, Gaia Project, Scythe and Neandertal.
We are indeed! We have written at length about distributed physics in these blog posts [0] [1]. We also have a multiplayer VR starter project for SpatialOS in Github [2], which you can start playing with immediately :)
They had a demo thing, but a lot of developers didn’t like it.
The problem is that their networking layer API sits too high. Like if I want to implement the throw mechanic, I really don’t want to call Improbable.blah.
Glen always focuses on principles and techniques, so one can easily use these lessons to create network behaviours for own projects in a given environment.
Also love attention to detail, edge cases and push to perfection, rather then good enough.
> Each cube would have authority, either set to default (white), or to whatever color of the player that last interacted with it. If another player interacted with an object, authority would switch and update to that player. I planned to use authority for interactions of thrown objects with the scene. I imagined that a cube throw by player 2 could take authority over any objects it interacted with, and in turn any objects those objects interacted with, recursively.
> Ownership was a bit different. Once a cube is owned by a player, no other player could take ownership until that player reliquished ownership. I planned to use ownership for players grabbing cubes, because I didn’t want to make it possible for players to grab cubes out of other player’s hands after they picked them up.
I’ve previously been thinking about a shared multi-user 2D desktop - one computer with one or more displays with two or more keyboards and mice attached, and this is somewhat like how I concluded that interaction should work there as well by default.
Additionally in a 2D environment where the objects are program windows, each user would be able to give permission to other users to enter a window owned by them so that they could collaborate on a text document for example, or they could give access to the underlying file so that the other person could edit the file in a separate window ala Google Docs. By default users cannot obscure other peoples windows, and each user can take up no more than 1/nth part of the screen where n is the number of users currently present.
I've just finished two-hour presentation to the dev team on our new distributed authority networking model - and it's very surprising and reassuring to see other people come up with almost exactly the same model!
One thing that I warned our game designers, though, was that physical interaction between objects that were being simulated on different computers could end up looking weird. I guess that may be it might not be as bad after all.
This is not related to the article directly but it's fun.
A while ago I read a paper about how to handle networked physics with many users, and they suggested using time dilation (like Eve Online) but in one continuous space, so that crowded regions would slow down time in order to handle the load better. I was curious what time dilation would do to your physics engine -- because a 'body' could literally have two or more different tick rates at once -- so I rigged up two point masses connected by a spring-force and applied time dilation. What this ended up doing is modulating the spring-force in such a way that there was a net force on the point-masses that 'pulled' them to the time-dilation center. I thought it was pretty interesting that a mechanism used to handle the propagation of information could end up creating something that behaves like gravity.
17 comments
[ 32.9 ms ] story [ 1379 ms ] threadAs soon as VR gaming started, people wanted to interact with objects in multiplayer environment.
The implementation here is extremely valuable. One can go and just make VR volleyball or any other VR application wixh requires multiple people to participate.
If I already didn’t work on VR MP game. I would do VR lego where you can build models out of pieces with other people.
Tabletop Simulator in itself is a nice program for simulating tabletop games, next to Bigscreen it's my go to VR app for board games I love. There are mods chess, card and flicking games and my favorites, Gaia Project, Scythe and Neandertal.
https://en.m.wikipedia.org/wiki/Open_Cobalt
[0] https://improbable.io/company/news/2016/01/22/dynamically-di...
[1] https://improbable.io/company/news/2016/01/27/distributed-ph...
[2] https://github.com/spatialos/VRStarterProject/tree/master
The problem is that their networking layer API sits too high. Like if I want to implement the throw mechanic, I really don’t want to call Improbable.blah.
Glen always focuses on principles and techniques, so one can easily use these lessons to create network behaviours for own projects in a given environment.
Also love attention to detail, edge cases and push to perfection, rather then good enough.
> Ownership was a bit different. Once a cube is owned by a player, no other player could take ownership until that player reliquished ownership. I planned to use ownership for players grabbing cubes, because I didn’t want to make it possible for players to grab cubes out of other player’s hands after they picked them up.
I’ve previously been thinking about a shared multi-user 2D desktop - one computer with one or more displays with two or more keyboards and mice attached, and this is somewhat like how I concluded that interaction should work there as well by default.
Additionally in a 2D environment where the objects are program windows, each user would be able to give permission to other users to enter a window owned by them so that they could collaborate on a text document for example, or they could give access to the underlying file so that the other person could edit the file in a separate window ala Google Docs. By default users cannot obscure other peoples windows, and each user can take up no more than 1/nth part of the screen where n is the number of users currently present.
https://www.youtube.com/watch?v=dJcakDNtHDA
One thing that I warned our game designers, though, was that physical interaction between objects that were being simulated on different computers could end up looking weird. I guess that may be it might not be as bad after all.
?
"The phrase ... may also connote an importune, unfounded, and vain effort against adversaries real or imagined for a vain goal."
A while ago I read a paper about how to handle networked physics with many users, and they suggested using time dilation (like Eve Online) but in one continuous space, so that crowded regions would slow down time in order to handle the load better. I was curious what time dilation would do to your physics engine -- because a 'body' could literally have two or more different tick rates at once -- so I rigged up two point masses connected by a spring-force and applied time dilation. What this ended up doing is modulating the spring-force in such a way that there was a net force on the point-masses that 'pulled' them to the time-dilation center. I thought it was pretty interesting that a mechanism used to handle the propagation of information could end up creating something that behaves like gravity.
Code and sim here: https://github.com/pfrazee/gsim
Well at least the set the FermiVariable to 1.
How would such a mechanism behave with a singularity?