On 4/9/2012 10:53 AM, David Barbour wrote:
On Mon, Apr 9, 2012 at 8:25 AM, BGB <[email protected]
<mailto:[email protected]>> wrote:
Running on a cluster is very different between having all the
intelligence on the individual clients. As far as I can tell,
MMOs by and large run most of the simulation on centralized
clusters (or at least within the vendor's cloud). Military
sims do EVERYTHING on the clients - there are no central
machines, just the information distribution protocol layer.
yes, but there are probably drawbacks with this performance-wise
and reliability wise.
There are some security and performance drawbacks. It would be easy to
`cheat` any of the simulation protocols used by military sims. But
there isn't much motive to do so; it isn't as though you win virtual
items to sell on e-bay. Some computations are many times redundant.
But it's good enough, and the extensibility and interop advantage are
worth more than efficiency would be.
yeah, probably fair enough.
though, it could be like the "Instant Messaging" network, which allows
to some extent for heterogeneous protocols (typically by bridging
between the networks and protocols).
now, why, exactly, would anyone consider doing rendering on the
server?...
Ask the developers of Second Life ;).
They basically `stream` polygons and textures to the player,
continuously, improving the resolution of your view if you aren't
moving too quickly. Unfortunately, you have this continuous experience
of it always being somewhat awful during normal movement. (In general,
that's what eventual consistency is like, too.)
actually, to some extent, I was also considering the possibility of
something like this, but I don't generally consider this "rendering" so
much as "streaming".
a very naive strategy would be, say, doing it like HTTP and using
ping/pong requests to grab things as they come into view.
better latency-wise is likely to use more of a "push-down" strategy,
where the server would speculate what the client can potentially see and
push down the relevant geometry.
in my case though, typically geometry is sent in terms of whole brushes
or mesh objects, rather than individual polygons.
presumably, client-side caching could also be done...
functionally, this already exists to some extent in the form of the
real-time mapping capabilities (which is currently handled by the client
pushing the updated geometry back to the server).
maybe textures could be sent 2-stage, with the first stage maybe sending
textures at 1/4 or 1/8 resolution, and then sending the full resolution
texture later.
say, first the client receives a 64x64 or 128x128 texture, and later
gets the 256x256 or 512x512 version (probably with a mechanism to avoid
re-sending textures the player already has).
like, unlike on a web-page, the user doesn't need to endlessly
re-download a generic grass or concrete texture...
ironically, all this leads to more MMOs using client-side physics,
and more FPS games using server-side physics, with an MMO
generally having a much bigger problem regarding cheating than an FPS.
If you ensure deterministic physics, it would be a lot easier to
transparently spot-check players for cheating. But I agree it is a
very difficult problem, unless you can control the player's hardware.
likely unworkable in practice.
more practical could be to perform "sanity checks", which will fail if
something happens which couldn't reasonably occur.
better though, reliability-wise, could be to leave the server in control
of most things where players would likely want to cheat:
general movement;
dealing damage;
keeping track of inventory and stats;
...
this way, tampering on the client end is only likely to impact the
client and make things buggy/annoying, but doesn't actually compromise
world integrity.
though Capt. Kirk's "I don't believe in the no win scenario"
line comes to mind
Same here. ;)
it is not clear that client-to-client would lead to necessarily
all that much better handling of latency either, for that matter.
Client-to-client usually does improve latency since you skip an
intermediate communication step. There are exceptions to prove the
rule, though - e.g. if you have control over routing or can put
servers between the clients.
fair enough. the bigger issue then is likely working around NAT though,
since typical broadband routers only work well for outgoing connections,
but are poorly behaved for incoming connections.
I guess the main question is whether one is measuring strict
client-to-client latency, or client-to-world latency.
client-to-client latency would mean how long before a client performs an
action and another client sees the result of this action, which would
presumably be at least: Ping1 + Ping2 + ~1/2 tick.
with a direct connection, it is likely to be a single ping measurement.
typically, in multiplayer gaming, a person is not directly interacting
with the client "as they exist right now", but rather with them "as they
are currently visible on the server".
this way, only a single ping-time matters, even if the real player being
shot at is not exactly where their model seems to be according to the
server.
some games (namely Source-Engine based games) have taken this further
though, and execute actions "as they were visible to the client
performing the action". however, some people don't like this, since it
means that they can take cover and then end up randomly taking damage
due to being shot up to several seconds later, because another player
with bad ping saw them still out in the open.
most typical FPS style games use UDP.
personally, I am using TCP, but mostly because I was feeling too lazy at
the time to bother with trying to write up an effective UDP-based
message transport (I may still do this later though).
UDP would mostly add some complexities related to reliable message
delivery, message delivery priorities, and things like being sure the
other end has a sensible message decoder state (Huffman tables,
dictionary state, ...), given that messages tend to often get lost or
arrive out-of-order.
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
