4 ms·

Any plans to provide out of the box multiplayer? Lots of engines today don't think about it at all, and instead seem to focus on the sort of feature set provide

Any plans to provide out of the box multiplayer? Lots of engines today don't think about it at all, and instead seem to focus on the sort of feature set provided by Unreal and Unity. 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.

faitswulff 5y ago
I'm no gamedev, but multiplayer seems very dependent on the use case. Is your game turn based? Real time? In the case of a fighting game, do you need millisecond resolution? I'm not sure a satisfactory out of the box multiplayer experience would be something a game engine could abstract.
- andrewmcwatters 5y ago
  It's a good point, but something is better than nothing. For instance, in our engine my team provides those mechanisms from the network variables associated with an entity/actor. So, doing something like: entity:networkVar( "health", 10 ) -- ... local health = entity:getNetworkVar( "health" ) entity:setNetworkVar( "health", health - 2 ) Does exactly what you'd expect. You can set the console variable `tickrate' and, that too, does exactly what you'd expect.
  - lwansbrough 5y ago
    Something isn’t always better than nothing. When it comes to networking, I personally think it’s better to give people who are new to the space a lay of the land before letting them choose a path. For instance, in your example: is that information sent reliably or unreliably? Why one way or the other? Would your answer change for a different piece of data? All those questions are relevant and often worth asking up front, depending on what type of game you’re developing.
    - andrewmcwatters 5y ago
      I think this is a weak answer. Too many engines simply do nothing and provide you at best raw sockets. That's not a solution, and most of the time people use arguments like this, and they're not valuable, either. 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.
      - reitzensteinm 5y ago
        I have looked through the source to both your engine and Bevy. 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.
valorzard 5y ago
I can tell you right now that there’s an entire channel in the Bevy discord server dedicated to making an out of the box api for multiplayer. If you want the current state of it, check out this RFC. https://github.com/bevyengine/rfcs/pull/19 https://github.com/bevyengine/rfcs/pull/19 I’m really excited for it when it eventually comes out.
forrest2 5y ago
Arguably needs to be abstracted out to some kind of multiplayer middleware; multiplayer sounds like one-size-fits-all but it's very nuanced. And that feeling that it needs to be abstracted/genericized might be the same reason why it never gets done.
djmcnab 5y ago
To copy from another comment[0] elsewhere in the thread from cart: > 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 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. [0]: https://news.ycombinator.com/item?id=31044108 https://news.ycombinator.com/item?id=31044108
hnuser123456 5y ago
I recognize your name from the facepunch days. I think you updated my early SWEP templates, which AFAIK were the first "full-featured" template published on the forums and proliferated everywhere. I didn't know you made your own GMod. 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=2042998461 https://steamcommunity.com/sharedfiles/filedetails/?id=20429...
- andrewmcwatters 5y ago
  I'm not sure if I edited yours. I created one of the first ports from C++ to Lua of the Half-Life 2 and Counter-Strike: Source weapons that allowed you to mod those. 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.
  - hnuser123456 5y ago
    Wow, I wish I stayed closer to gamedev. I would love to see (MP) VR dev made more accessible. The Source2 used in HL:A doesn't support MP (and still has many missing tools), and the Source2 used in SteamVR environments is very barebones and an earlier version of the engine. It looks like Garry's S&box is going to be the "most-feature-complete" version of Source2 for modding/additional development. Using Unity for VR seems silly if not used for VRchat where the social scene already is, unless making a new unique standalone title from near scratch. Using UE5 seems tempting, if a bit corporate, but I'm not sure how far their VR/VR-MP integration is, plus UE5 seems overly heavy for VR on typical hardware. Once it's not prohibitively expensive to run raytracing in VR, we're going to see some cool stuff.
izend 5y ago
I spent quite a few hours working on an example of Bevy 0.5 and Tokio for multiplayer backend server. https://github.com/peterholko/bevy_tokio_tungstenite/blob/main/src/main.rs https://github.com/peterholko/bevy_tokio_tungstenite/blob/ma...

faitswulff 5y ago

I'm no gamedev, but multiplayer seems very dependent on the use case. Is your game turn based? Real time? In the case of a fighting game, do you need millisecond resolution? I'm not sure a satisfactory out of the box multiplayer experience would be something a game engine could abstract.

andrewmcwatters 5y ago
It's a good point, but something is better than nothing. For instance, in our engine my team provides those mechanisms from the network variables associated with an entity/actor. So, doing something like: entity:networkVar( "health", 10 ) -- ... local health = entity:getNetworkVar( "health" ) entity:setNetworkVar( "health", health - 2 ) Does exactly what you'd expect. You can set the console variable `tickrate' and, that too, does exactly what you'd expect.
- lwansbrough 5y ago
  Something isn’t always better than nothing. When it comes to networking, I personally think it’s better to give people who are new to the space a lay of the land before letting them choose a path. For instance, in your example: is that information sent reliably or unreliably? Why one way or the other? Would your answer change for a different piece of data? All those questions are relevant and often worth asking up front, depending on what type of game you’re developing.
  - andrewmcwatters 5y ago
    I think this is a weak answer. Too many engines simply do nothing and provide you at best raw sockets. That's not a solution, and most of the time people use arguments like this, and they're not valuable, either. 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.
    - reitzensteinm 5y ago
      I have looked through the source to both your engine and Bevy. 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.

valorzard 5y ago

I can tell you right now that there’s an entire channel in the Bevy discord server dedicated to making an out of the box api for multiplayer. If you want the current state of it, check out this RFC. https://github.com/bevyengine/rfcs/pull/19 https://github.com/bevyengine/rfcs/pull/19 I’m really excited for it when it eventually comes out.

forrest2 5y ago

Arguably needs to be abstracted out to some kind of multiplayer middleware; multiplayer sounds like one-size-fits-all but it's very nuanced. And that feeling that it needs to be abstracted/genericized might be the same reason why it never gets done.

djmcnab 5y ago

To copy from another comment[0] elsewhere in the thread from cart: > 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 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. [0]: https://news.ycombinator.com/item?id=31044108 https://news.ycombinator.com/item?id=31044108

hnuser123456 5y ago

I recognize your name from the facepunch days. I think you updated my early SWEP templates, which AFAIK were the first "full-featured" template published on the forums and proliferated everywhere. I didn't know you made your own GMod. 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=2042998461 https://steamcommunity.com/sharedfiles/filedetails/?id=20429...

andrewmcwatters 5y ago
I'm not sure if I edited yours. I created one of the first ports from C++ to Lua of the Half-Life 2 and Counter-Strike: Source weapons that allowed you to mod those. 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.
- hnuser123456 5y ago
  Wow, I wish I stayed closer to gamedev. I would love to see (MP) VR dev made more accessible. The Source2 used in HL:A doesn't support MP (and still has many missing tools), and the Source2 used in SteamVR environments is very barebones and an earlier version of the engine. It looks like Garry's S&box is going to be the "most-feature-complete" version of Source2 for modding/additional development. Using Unity for VR seems silly if not used for VRchat where the social scene already is, unless making a new unique standalone title from near scratch. Using UE5 seems tempting, if a bit corporate, but I'm not sure how far their VR/VR-MP integration is, plus UE5 seems overly heavy for VR on typical hardware. Once it's not prohibitively expensive to run raytracing in VR, we're going to see some cool stuff.

izend 5y ago

I spent quite a few hours working on an example of Bevy 0.5 and Tokio for multiplayer backend server. https://github.com/peterholko/bevy_tokio_tungstenite/blob/main/src/main.rs https://github.com/peterholko/bevy_tokio_tungstenite/blob/ma...