<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Experiment with a few ways of doing the same thing. What works for
my game may suck for yours.<br>
<div class="moz-signature"><br>
<hr style="height: 1px;">
<p><span style="font-weight: bold;">Nicholas J Ingrassellino<br>
<a style="text-decoration: none;"
href="http://www.lifebloodnetworks.com/" target="_blank">LifebloodNetworks.com</a></span>
|| <a style="text-decoration: none;"
href="mailto:nick@lifebloodnetworks.com">nick@lifebloodnetworks.com</a></p>
<p style="font-size: 75%;">"<span style="font-style: italic;">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.</span>"<br>
- <span style="font-weight: bold;">John Carmack</span> on
software patents</p>
</div>
<br>
On 11/23/2010 05:57 PM, Jay Sprenkle wrote:
<blockquote
cite="mid:AANLkTinPBds0LEc-QC8DDNZJ4i2Cx7RdwC8JxeqOjY46@mail.gmail.com"
type="cite">I've read several interesting discussions about lag in
online games.<br>
They tried to avoid sending that much network traffic if possible
for many reasons.<br>
<br>
<br>
<div class="gmail_quote">On Tue, Nov 23, 2010 at 4:22 PM, Chris
Meub <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:chrismeub@gmail.com">chrismeub@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">Does anyone have experience using enet
with a multiplayer game sending<br>
reliable packets ~20 times a second or more?<br>
I imagine most people sending that many packets are using
unreliable.<br>
<div>
<div class="h5"><br>
On Sun, Nov 21, 2010 at 6:01 PM, Lee Salzman <<a
moz-do-not-send="true" href="mailto:lsalzman@gmail.com">lsalzman@gmail.com</a>>
wrote:<br>
> No, the point is to get all available packets in this
frame and not stall,<br>
> i.e. it is polling. You wouldn't use a non-zero
timeout in a game's client<br>
> loop like that.<br>
><br>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ENet-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a>
<a class="moz-txt-link-freetext" href="http://lists.cubik.org/mailman/listinfo/enet-discuss">http://lists.cubik.org/mailman/listinfo/enet-discuss</a>
</pre>
</blockquote>
</body>
</html>