Make it more like Ready Player One


#1

Here are some of the things you can do in the Oasis that you can’t in High Fidelity.

Drive cars and vehicles.
image

Wage virtual war.

Attack other avatars.
image

Explode entire buildings.

What’s the ETA on all these features?
Y’know, so High Fidelity can properly piggyback off the movie’s success.

Have a look at High Fidelity’s current Steam rating for an idea of what the target audience of Ready Player One is going to think of it in its current state.


#2

This would be great, but one draw back. Right now HiFi is growing. Everyone needs patience and more content creators. Things do not get created over night.


#3

Vehicles are actually pretty difficult to build with just regular physics. Second Life uses a vehicle API that marks objects as being vehicles that have slightly different physics interactions at the simulator level. Some kind of vehicle physics API would probably be useful.

I’m not sure about allowing combat, physical damage, and mass destruction for all. A set of scripts to support combat and damage could be created for end users to voluntarily take on. And that could be implemented by users and wouldn’t require HF themselves to do anything.


#4

Not to mention, vehicles in HF would meet one critical issue: a design flaw that High Fidelity has is that physical operations are managed by the client. They ‘can’ be managed by the server to some degree, as done with an entity server script test, but the moment a client walks in, it claims ownership away and that caused absolute chaos with some projects I tried.

I know that Fluffy has made some projects and that they 100% do not use Hifi’s built in physics system for this very reason. After doing some personal testing, sadly the only way is to rewrite the wheel. What we need is the option to OWN physical operations, as in deny others from having them based on some rules.

As for combat and all… I can tell you that there’s a reason RPO is just a book and movie: good story telling, bad in actual use. I can see combat domains being a thing, but as Argent mentioned, it’d be up to the domain operator’s choice to use such systems. In a similar way, a vehicle API could also be operated by a domain operator, allowing the server to managed ‘physics’ even in the system’s current state.


#5

I’ve seen some pretty impressive client-side physics, where one client owned the physics and other clients just displayed updates. So maybe, if someone implemented a vehicle framework that used a vehicle physics model that could work.


#6

image