This is why I originally was against the idea all together. However, if you do it right, and keep the visuals simple enough to process, I believe it would be doable. It’s definitely something you would need to experiment with, and only use if you find a performance cheap way to visualize bullets.
You will also notice, that games that do this, don’t have guns with a super fast fire rate. Games like Arsenal, would never attempt visualizing bullets on the Server, as with the crazy fast speed of their guns, it would break the game.
1 Like
Right, thats alot of toying around, as long as you stay organized and constantly stress test you should be able to do it, take ACS for example.
2 Likes
Bullets do not need to be rendered by the server. Quite literally the only thing the server needs to process is hit detection, damage, and replicating these changes to other clients.
Ideally the client will raycast first. If it hits, then it will render the bullet for the client only and tell the server that the gun has been fired. You should pass the mouse position to the server when doing so. The server then fires it’s own raycast to “verify” this bullet and apply any stats necessary server sided. Lastly the server will fire a remote to all clients (excluding the one who shot the bullet). This remote indicates that the other clients should render the bullet (usually only within a certain distance). This remote can also pass other valuable information such as what the bullet hit. This is useful for playing sounds or effects + the client that got hit by the bullet can render those effects as well.
You should delegate almost everything to the client that doesn’t need accurate verification.
2 Likes