I wrote a VR GMod clone[1] based on Source2/SteamVR Environments, mostly in lua, with some basic HTML/JS/CSS for Panorama UI components, incorporating the usual art assets updated/ported for Source2 made by kind artists from the community with their permission. My work was mostly to re-write the physics gun and toolgun with UI/controller input bindings to the physics engine and my custom UI. Of course, all of the hard work is credit to the teams at Valve.
[1] https://steamcommunity.com/sharedfiles/filedetails/?id=20429...
I'm also the author of Planimeter's (previously Team Sandbox's) Half-Life 2: Sandbox reference implementation, which was the first Source engine game to use LuaJIT.
We also ported the base code to allow users to use Lua in other games as a Valve Server Plugin. It relied heavily on reverse engineering.
Once it's not prohibitively expensive to run raytracing in VR, we're going to see some cool stuff.
> The story is similar for networking. Ultimately we will have a built in api, but we're focused on more fundamental things at the moment. There are _tons_ of community-developed networking plugins though: https://bevyengine.org/assets/#networking
That is, we do definitely want to make multiplayer work properly, and our data design should give us inherent advantages here. But it hasn't been a priority so far, as we've had other more pressing requirements (e.g. animation this release).
But a lot of what you want should in the medium term be provided by external crates; our use of systems as the unit of logic should make this viable, as behaviour implemented by the engine is not special. These external crates could potentially be made official if that made sense, but that's for much longer time scales.
https://github.com/peterholko/bevy_tokio_tungstenite/blob/ma...
So, doing something like:
entity:networkVar( "health", 10 )
-- ...
local health = entity:getNetworkVar( "health" )
entity:setNetworkVar( "health", health - 2 )
You can set the console variable `tickrate' and, that too, does exactly what you'd expect.
It's like saying "The problem is difficult," it doesn't inform anyone and no one learns from it.
Further, most advanced engines simply allow you to construct payloads and `setReliable( true/false )` or something similar.
It's nice that you've found your niche, but Bevy attempting to follow would be a big mistake.
The abstractions you use work OK in a world where everything looks like Quake, but they're simply not universal.
An engine like yours should be built on top of Bevy, it shouldn't be part of Bevy.
And that feeling that it needs to be abstracted/genericized might be the same reason why it never gets done.
I don't think there's a whole lot of value in that design, but that's my personal opinion having built an engine for the Lua community that did somethings no one else was doing.
Mainly, providing an out of the box experience for, typically, hobbyist developers who don't actually know anything about multiplayer serialization or prediction, etc.
The sort of younger developers and people who are playing around with code and posting on Reddit and such.
A lot of engines are just wrappers around popular libraries and I don't know if there's a tremendous value around that sort of thing.
Consider, for example, audio. It's really easy to provide audio bindings to, I don't know, let's say OpenAL, because I don't know what else is used these days. But game developers eventually mature enough where they don't just care about playing audio.
What they'll eventually want is to play a sound, with DSP, and have that audio automatically networked by the engine to play on different connected client's based on visibility rules or at least a simple emit sound networked event.
There's an entire class of hobby engines that don't consider these things, and leave it as an exercise for the user to implement. They are entirely non-trivial features that the users will never implement, though, and instead just never pursue that feature because the engine doesn't provide it.