Online beat 'em up

Started by
20 comments, last by AnonymousPosterChild 18 years, 1 month ago
Quote:Original post by Steadtler
kinda belong in networking, no?

I dont think this system is feasable for a networked beat-them up. Im having trouble explaining why in words, altough it seems obvious to me. In networked games, only the server knows the real state of the game, every client gets a varied slightly delayed view. If I hit *punch*, the client should not be able to know if the punch landed. It send a 'punch command' message to the server, which updates the game's state and send new info to the clients, who gets to see if the punch landed or not.

So lets say I have a ping of 100ms, and that I need half a second to enter a 5 key combo. That means I will have a least a 600ms delay between hitting the first punch and seeing if it lands or not. That means every combo will have to be done "blindly". That also means that combos can't really be interrupted by the opponent.

So not practicable in a real-time game.

If its Turn-based or pseudo turn-bases, then ok, altough a TB beat-em-up sounds wierd :)


Client side prediction means that you'll likely see you punch hit - even though it might miss. It works most of the time. In any case, what most games do is favor the client for those things - e.g, the server checks to see if you shot where YOU saw the player, not where the server sees the player. The latency issues are what cripple gameplay in MMO's though still - but only because of the security needed to prevent cheating. If you could give the client the benefit of the doubt, you'd be good to go. Unfortunately, you can't.

Nonetheless, I'd suggest trying a system where the server records it's last x number of states and then performs actions relative to the time that the client actually performs them. E.g., if you hit punch at 2:02:45:001, the server checks to see if your punch connected at the time that you hit (the update package sent from the client leaves with a timestamp). This way, the client behaves as if it's version of events is true and shows you hitting the enemy, and the server will ultimately ok this action because it checks your action against the state it has stored in memory. Barring huge amounts of server side slowdown, by the time the server checks your action, the simulation should not have advanced too far for it to still be plausible to update the results. E.g, unless you enemy teleports at the split second you attack him and the server lags for awhile, you should be able to hit punch and have the damage register before the opponent moves away.

There are lots of topics about CSP out there though along with networking in general. This is probably going to be moved, BTW.
::FDL::The world will never be the same
Advertisement
Quote:Original post by Nytehauq
Quote:Original post by Steadtler
kinda belong in networking, no?

I dont think this system is feasable for a networked beat-them up. Im having trouble explaining why in words, altough it seems obvious to me. In networked games, only the server knows the real state of the game, every client gets a varied slightly delayed view. If I hit *punch*, the client should not be able to know if the punch landed. It send a 'punch command' message to the server, which updates the game's state and send new info to the clients, who gets to see if the punch landed or not.

So lets say I have a ping of 100ms, and that I need half a second to enter a 5 key combo. That means I will have a least a 600ms delay between hitting the first punch and seeing if it lands or not. That means every combo will have to be done "blindly". That also means that combos can't really be interrupted by the opponent.

So not practicable in a real-time game.

If its Turn-based or pseudo turn-bases, then ok, altough a TB beat-em-up sounds wierd :)


Client side prediction means that you'll likely see you punch hit - even though it might miss. It works most of the time. In any case, what most games do is favor the client for those things - e.g, the server checks to see if you shot where YOU saw the player, not where the server sees the player. The latency issues are what cripple gameplay in MMO's though still - but only because of the security needed to prevent cheating. If you could give the client the benefit of the doubt, you'd be good to go. Unfortunately, you can't.

Nonetheless, I'd suggest trying a system where the server records it's last x number of states and then performs actions relative to the time that the client actually performs them. E.g., if you hit punch at 2:02:45:001, the server checks to see if your punch connected at the time that you hit (the update package sent from the client leaves with a timestamp). This way, the client behaves as if it's version of events is true and shows you hitting the enemy, and the server will ultimately ok this action because it checks your action against the state it has stored in memory. Barring huge amounts of server side slowdown, by the time the server checks your action, the simulation should not have advanced too far for it to still be plausible to update the results. E.g, unless you enemy teleports at the split second you attack him and the server lags for awhile, you should be able to hit punch and have the damage register before the opponent moves away.

There are lots of topics about CSP out there though along with networking in general. This is probably going to be moved, BTW.


:P wouldnt bother me in the least, I was going to open a thread in networking two days ago, but my router wouldn't let me access gamedev.
With love, AnonymousPosterChild

This topic is closed to new replies.

Advertisement