5 ms·

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 millisecon

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.

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.