Hi
I have tiny little multiplayer top-down tank battle game. Im utilizing the headless server. Im not using jme networking but KryoNet to just toss messages forth and back with udp. Ive written the client extrapolation of enemies and correction of player input. My plan was to resolve collisions on the server for projectiles. When doing projectile collision on the server i planned to do player-terrain collision on the server to (it sorta felt right).
So, i see im opening a can of worms here. I understand i cant use the BulletAppState as normal on the server. As i wanna simulate stuff like
GameWorld on time = t0
translation update from player stamped at t1.
Simulate players motion up to t1.
do world simulation up t2 with projectiles
send world upate to players.
Q 1. I dunno if this is a good plan. Please give me advice on how to simulate the game world on the server atleast for projectiles - and if possible player-terrain/level. Its meant to be an action game so i do want things to run smothly. I mean, i learned that in “real” fps style games - clients are not authoritative over their position. So it would feel wrong to only rely on collisions for player-terrain.
Q 2. Can i decouple BulletAppState from game time and control the simulation myself by someting like “simulate-up-until”?
Q 3. How do “real” game do it?
The MonkeyZone example does this in a simple way. Googling the web for this topic should also yield enough information on “how real game do it”, valve for example put out lots of information about this.
Yes, in fact we had a thread on these forums a few months ago linking to some excellent information on predictive shooting etc. There was also that good GDC talk on Halo Reach as well.
http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking
From another thread:
@pspeed said:
This thread was too long to read to catch up on so I don't know if you mentioned having read these before. I consider them required reading for real-time multiplayer game programming:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
@kwidell said:
Im not using jme networking but KryoNet to just toss messages forth and back with udp.
Curious if there was a good reason for this or if it was just based on familiarity.
pspeed: Good reason
@pspeed said:
Curious if there was a good reason for this or if it was just based on familiarity.
Well.. im new to gameprogramming so i asked around for the best frameworks for all problems. Preferably i wanted something language independent but kryonet seemed to be the most famed in javaspace. So i guess i missed jme's own. Also, i wanted to tacle the problem of networking myself and not abstracting it all away.
@kwidell said:
pspeed: Good reason
Well.. im new to gameprogramming so i asked around for the best frameworks for all problems. Preferably i wanted something language independent but kryonet seemed to be the most famed in javaspace. So i guess i missed jme's own. Also, i wanted to tacle the problem of networking myself and not abstracting it all away.
I don't think the API is that different. SpiderMonkey still requires that you create and send your own messages. The abstraction level should be similar, I think.
Thanks for the replies. Im aware of all the syncing issues between client and server. And wo physics - i pretty satisfied the solution ive now implemented. Both player and “enemy players” behave smooth/correct.
My question was ONLY about collisions (ie physicis as thats how jme solves it). The links posted above are nice but are more about prediction/latency/correction stuff. That im quite down with. Id be happy if someone could explain in 3 lines a simplified explaination on how action multiplayer AAA games deal with collisions for player-terrain and player-projectiles.
Ill look at monkeyzone later tonight.
I thought the Valve articles covered it but I can’t find a nice quote.
Generally, the server should do physics authoritatively. The client should do as little as necessary for prediction. Usually just collisions with the player that would result in motion, I guess.
The above assumes that physics is a critical element of the game that requires authoritative quality in order to avoid cheating.
Yeeh. It also depends on whether you are in an FPS (i.e. 16 players per server) or MMO (thousands of players per server) situation.
In the FPS scenario typically the server runs the authoritative version and everyone else runs enough local simulation to keep going between updates.
For MMOs though more commonly the client does the more complex simulations and the server just validates what they are doing for legitimacy.
@zarch said:
Yeeh. It also depends on whether you are in an FPS (i.e. 16 players per server) or MMO (thousands of players per server) situation.
In the FPS scenario typically the server runs the authoritative version and everyone else runs enough local simulation to keep going between updates.
For MMOs though more commonly the client does the more complex simulations and the server just validates what they are doing for legitimacy.
Yeah, I should have been clearer. FPS/twitch games are the ones I was referring to. The server must be law in those cases.
MMOs tend to use a command system and the simulation doesn't have to be so authoritative. ie: clicking = "attack monster" and not "shoot the monster right where my gun is pointing when I clicked which happens to be the monster's left eye". The latter is where the deeper material in the Valve articles comes into play.