For the MinimalPlugin running as fast as possible the solution is to add this resource before adding the `MinimalPlugin`: ScheduleRunnerSettings::run_loop(Duration::from_secs_f64(1.0 / 60.0))
Wow! You're absolutely right and it's in the headless example. I swear I searched and searched for this and couldn't find it. Interestingly this only works for minimal plugins and not with default plugins so I guess I never ran into it before.
This was a great resource for me. I did have one question though. For `client_receive_messages` should those fire off bevy events or be processed from the mut lists? Probably could do either but idk which way would be more manageable
Thanks for this video. It is great! I might be missing something tho... I don't see the benefit of having bevy as a dependency on both ends (client and server) and having 2 game loops... It feels like a lot of overhead IMHO don't you think?
It depends how much work the server is doing. For my projects both the client and server are heavy apps but a lighter server or different framework would also work. Bevy is pretty performant though
I haven't done much personal networking work since creating this video. Overall keeping the messages type safe and the code handling them as isolated as possible seems to be the key to keeping things clean. I would probably wrap networked messages into bevy events to fully separate the networking code from the rest of game logic but it's hard to say without making a larger project and feeling it out.
On the cheating front, for browser embedded games, it's probably kindof hard, right. Unless you bind the variables to javascript via bindgen, the user can't change any variables in the wasm itself (via browser tools), right? I haven't thought through it too much, but I feel we get away from the cheats a bit with WA. encrypt data sent if needed. Could even sign the WASM file as well.
I'm not sure on what cheating in online games looks like and how much protection renet inherently gives you. At the end of the day trusting any packet from the player (like a position) would probably be unadvisable for a competitive game but I decided against giving any advice in the video because it's well outside of the area I can competently give advice in.
Anything on the client must be untrusted. There is no way to guarantee that the client cannot modify their version of the program. Typically this is done by making changes to the running program's memory with tools like Cheat Engine. WASM doesn't make it any more difficult to cheat than any regular non-browser game. The only things that make it properly difficult are complex anti-cheat systems like BattlEye and Vanguard, which use kernel-level processes to detect modifications to the game in a way that can't easily be hidden from the anti-cheat.
4:15 Ah yes. The most logical thing to expect people to do... "Hey computer, exactly how long has it been since the universe began?" Why ask what time it is, when you could do that?
Your videos are really a gold mine. One question: When do you see a visual editor like Unity on the horizon for Bevy? I think the visualization of Unitys ECS is made quite nicely and I think something like it would work for bevy as well.
There's always a lot of talk about the bevy editor and what it will look like. There's some prototypes out there (bevy_editor_pls and the inspectors new docked example look like unity's). I would imagine this year an early official editor is created but it probably won't be useful day to day until a few more iterations after that
Wow I was literally planning on doing something similar for Bevy! I was going to implement a lockstep implementation though, but I might just use this instead. Awesome!
I believe in the comments on the source code I linked with this tutorial I have the code you need. If I remember right all the changes are in setting up the server/client resources
@@logicprojects I updated my code but it doesn't seem to work. The client isn't connecting to the server. Edit: I just had my port configured wrong. Everything works now!
This is cool, thanks for sharing. I'm planning on networking going through central server, but collisions and stuff on one of the clients, with failover to next client if first isn't reliable, and state stored on server in case failover needed (memory and db), but thought the physics would best be offloaded to a client to prevent on the processing on the server. Any thoughts on this architecture? Trying to both keep security (central server instead of p2p), but minimize server load as well. Even with WebGPU, could use compute shader on client for collision detection.
Hmm I'm not sure how to properly structure this with the goal of minimizing the load on the server. My first thought would be every client should be doing the physics calculation and then agreeing on the result through the server and the server can reject any outlier, like a super laggy client (my failsafe systems engineering is showing through here). I think rapier has a feature flag for deterministic results which might help keep all clients getting the same answers. The biggest problem is timing. Any message from one client through the server to another client might be 200ms (~15 frames) delayed so it's definitely something to take a lot of thought and care about and you'd want to test it under real world pings.
![[Outdated] Bevy Showcases: Kayak-UI](http://i.ytimg.com/vi/tdfnDrzxVTM/mqdefault.jpg)
![[Outdated] Bevy Showcases: Kayak-UI](/img/tr.png)
For the MinimalPlugin running as fast as possible the solution is to add this resource before adding the `MinimalPlugin`:
ScheduleRunnerSettings::run_loop(Duration::from_secs_f64(1.0 / 60.0))
Wow! You're absolutely right and it's in the headless example. I swear I searched and searched for this and couldn't find it. Interestingly this only works for minimal plugins and not with default plugins so I guess I never ran into it before.
PLEASE make an updated version of this tutorial!
5:14: I'm surprised and glad to see someone else using the port 42069. I use that for a lot of my projects.
Can't wait for the voxel game demo!
Neat!
If only I was working on something with multiplayer.
This looks amazingly cool! Bevy ftw
Excited to see more on this
This was a great resource for me. I did have one question though. For `client_receive_messages` should those fire off bevy events or be processed from the mut lists?
Probably could do either but idk which way would be more manageable
Absolute legend. Nice one
Thanks for this video. It is great!
I might be missing something tho... I don't see the benefit of having bevy as a dependency on both ends (client and server) and having 2 game loops... It feels like a lot of overhead IMHO don't you think?
It depends how much work the server is doing. For my projects both the client and server are heavy apps but a lighter server or different framework would also work. Bevy is pretty performant though
Awersome as always
thanks, downloaded, all works!
thank you so much , it worked
Can you recreate this video using the newest versions and if possible, cover how to use renet with the steam api? Thanks a lot
5:32 - at this point I realized renet changed too much and if you're just following along, you'll just want to look at the bevy_renet examples.
yes
Does it support UPnP so that you don't have to port forward?
Can the client be in typescript?
works gj
Great thanks. Would be interested in a server version without bevy and if this runs in wasm
I would expect a renet server would work. The bevy plugin is a thin wrapper over renet. As for wasm I haven't tried so I can't say
Is there anything that you wish were different about this implementation?
I haven't done much personal networking work since creating this video. Overall keeping the messages type safe and the code handling them as isolated as possible seems to be the key to keeping things clean. I would probably wrap networked messages into bevy events to fully separate the networking code from the rest of game logic but it's hard to say without making a larger project and feeling it out.
On the cheating front, for browser embedded games, it's probably kindof hard, right. Unless you bind the variables to javascript via bindgen, the user can't change any variables in the wasm itself (via browser tools), right? I haven't thought through it too much, but I feel we get away from the cheats a bit with WA. encrypt data sent if needed. Could even sign the WASM file as well.
I'm not sure on what cheating in online games looks like and how much protection renet inherently gives you. At the end of the day trusting any packet from the player (like a position) would probably be unadvisable for a competitive game but I decided against giving any advice in the video because it's well outside of the area I can competently give advice in.
Anything on the client must be untrusted. There is no way to guarantee that the client cannot modify their version of the program. Typically this is done by making changes to the running program's memory with tools like Cheat Engine. WASM doesn't make it any more difficult to cheat than any regular non-browser game. The only things that make it properly difficult are complex anti-cheat systems like BattlEye and Vanguard, which use kernel-level processes to detect modifications to the game in a way that can't easily be hidden from the anti-cheat.
4:15 Ah yes. The most logical thing to expect people to do... "Hey computer, exactly how long has it been since the universe began?" Why ask what time it is, when you could do that?
Your videos are really a gold mine. One question: When do you see a visual editor like Unity on the horizon for Bevy? I think the visualization of Unitys ECS is made quite nicely and I think something like it would work for bevy as well.
There's always a lot of talk about the bevy editor and what it will look like. There's some prototypes out there (bevy_editor_pls and the inspectors new docked example look like unity's). I would imagine this year an early official editor is created but it probably won't be useful day to day until a few more iterations after that
@@logicprojects Thanks for your response!
Wow I was literally planning on doing something similar for Bevy! I was going to implement a lockstep implementation though, but I might just use this instead. Awesome!
Hello, I wanted to ask how to connect to a public ip address? What do I need to change? I have port forwarded. Thanks.
I believe in the comments on the source code I linked with this tutorial I have the code you need. If I remember right all the changes are in setting up the server/client resources
@@logicprojects Thanks a lot.
@@logicprojects I updated my code but it doesn't seem to work. The client isn't connecting to the server.
Edit: I just had my port configured wrong. Everything works now!
Glad to hear you solved it! You had me worried I had spread wrong information :)
This is cool, thanks for sharing.
I'm planning on networking going through central server, but collisions and stuff on one of the clients, with failover to next client if first isn't reliable, and state stored on server in case failover needed (memory and db), but thought the physics would best be offloaded to a client to prevent on the processing on the server. Any thoughts on this architecture? Trying to both keep security (central server instead of p2p), but minimize server load as well. Even with WebGPU, could use compute shader on client for collision detection.
Hmm I'm not sure how to properly structure this with the goal of minimizing the load on the server. My first thought would be every client should be doing the physics calculation and then agreeing on the result through the server and the server can reject any outlier, like a super laggy client (my failsafe systems engineering is showing through here). I think rapier has a feature flag for deterministic results which might help keep all clients getting the same answers. The biggest problem is timing. Any message from one client through the server to another client might be 200ms (~15 frames) delayed so it's definitely something to take a lot of thought and care about and you'd want to test it under real world pings.