So I’ve been wondering, is it in any means a smart idea to send a notification to the server that a bullet has been spawned? It seems rather wasteful and terribly optimized in every way as a new bullet can be spawned rather fast. (GOLANG AND GODOT but this is theoretical so shouldn’t matter)
Also to add to this is handling everything in MatchLoop a smart decision? Are there any alternatives like using Goroutines or something to optimize this? I am currently not doing many calculations server-side but just thinking about checking each player’s movement, their bullets and checking for a collision on their bullets, checking and updating each AI and stuff like that makes me kinda scared how slow is that gonna get. Any ideas on this? Maybe passing the broadcaster to different threads so they can emit in their own pacing?
If anyone knows the fundamentals and the behind scenes of how it works, I’d love to know so I can better understand this.
So I’ve been wondering, is it in any means a smart idea to send a notification to the server that a bullet has been spawned? It seems rather wasteful and terribly optimized in every way as a new bullet can be spawned rather fast. (GOLANG AND GODOT but this is theoretical so shouldn’t matter)
Another approach could involve simply be notifying the server when the user has held down the fire trigger and when they have released it. If the server is checking for bullet collision and knows the map geometry, fire rate, etc., it can do the work for you.
Also to add to this is handling everything in MatchLoop a smart decision?
Yep, tracking this type of match-specific data is what the match loop was designed for.
Any ideas on this?
I don’t see anything fundamentally wrong with your approach - keep in mind you have until the next server tick to do your processing. With the stage you are at, I would give it a go and see how it runs. It will depend of course on the number of players you have and the size of your maps.
2 Likes