I am using exactly 20 unreliable updates a seconds. I experimented doing
one reliable per second with ~10-15 unreliable but I think this is a
better compromise. My player object updates, for example, are pretty
small at 12 bytes. I think with a system like this you run the risk of
making too many small packets too quickly than anything else. It even
works well over a high latency (cellular) connection. It is also worth
noting my system is only one step removed from a dumb terminal with
minimal dead reckoning.
Bandwidth is not the issue it used to be. Know your target audience and
then it becomes even less of an issue. With some types of games you
could go a lot lower if you do a lot of specialized dead reckoning. Some
game types-- turn-bases games, for example-- run the risk of timing out
more than they run the risk of sending too many packets.
On a semi-related note check out how it was done in Quake 3. The short
of it is that a base line game state (including all game objects) is
calculated when a client connects. Each update after that is all deltas
(changes since the base line) since the last acknowledged update (thus
creating a new base line). There are a few things Carmack intentionally
ignored (UPD packets getting too large, ect) but with ENet such a thing
is not an issue.
Experiment with a few ways of doing the same thing. What works for my
game may suck for yours.
------------------------------------------------------------------------
Nicholas J Ingrassellino
LifebloodNetworks.com <http://www.lifebloodnetworks.com/> ||
[email protected] <mailto:[email protected]>
"The idea that I can be presented with a problem, set out to logically
solve it with the tools at hand, and wind up with a program that could
not be legally used because someone else followed the same logical steps
some years ago and filed for a patent on it is horrifying."
- John Carmack on software patents
On 11/23/2010 05:57 PM, Jay Sprenkle wrote:
I've read several interesting discussions about lag in online games.
They tried to avoid sending that much network traffic if possible for
many reasons.
On Tue, Nov 23, 2010 at 4:22 PM, Chris Meub <[email protected]
<mailto:[email protected]>> wrote:
Does anyone have experience using enet with a multiplayer game sending
reliable packets ~20 times a second or more?
I imagine most people sending that many packets are using unreliable.
On Sun, Nov 21, 2010 at 6:01 PM, Lee Salzman <[email protected]
<mailto:[email protected]>> wrote:
> No, the point is to get all available packets in this frame and
not stall,
> i.e. it is polling. You wouldn't use a non-zero timeout in a
game's client
> loop like that.
>
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
