[MUD-Dev] Re: MUD-Dev digest, Vol 1 #438 - 22 msgs

[Phil O'Donnell]

[Justin]

> Hum, I almost think that a very large ROAM style map on each
> client would be suitable, along with random placements of
> teleporters between the various clients.  Actually creating a
> contiguous 3D world across client boundaries with client
> connections and latency (no matter how fast DSL gets it still has
> a min 30 ms latency).

Very true, however if the client controlled area is large enough(say
30x30), and with a thoeretical 2D tile map, a minimum-lag connection
would only need to be maintained between 1-4 other client for
map-travel purposes. If you can visualize that, when traveling
between two maps(clients) you need the first client and the second
client to generate the map, except at the corners, where you need
all four.

> I'm not prepared to comment on this one yet since it really looks
> like your allowing each client to maintain a piece of the 3D
> universe.  This is extremely difficult, unless of course terrain
> is developed using an algorithm wherein each client holds the seed
> values for its land.  That way if a client goes down while you are
> on it, you would have already downloaded the seeds, and the block
> would still exist (on your computer) until you left it.

That is exactly the idea. In a random number algorithim (at least
the one I am using), the numbers themselves appear random, but the
sequence of the numbers is fixed. So for a given seed, all the
clients using it will generate the same sequence. So you could
create a map using a seed value, with a few fixed modifiers for
land/water percentages and the like), and all the clients would have
it. So as a client joins, it is given the current seed and the
client assumes the map designated by the result number/seed.  Also,
if a client is needed to fill a vacant slot, it can be given the
seed of the previous map, and it will assume the spot.

I know this is confusing, but it makes sense in my head.

[Dan Macdonald]

> I too played with this for about two months and came to the
> conclusion that the two critical factors for an MMORPG on the
> technical side are Security and Scalability in that order. It is
> nearly impossible to be a commercial success without tight
> security in an MMORPG because the world is persistent and any
> hacks become permanent they don't disappear when the session
> ends. (ala Diablo type gaming)

A valid point, however I could think of a few solutions. If it was
impossible to ensure that the clients you were verifying each
operation with were part of the "hacking group", it would be
difficult to ensure that your hack would go undetected. 3 Hacked
programs in a network of 100 would not succeded easily.
 
[Snip some nice distributed system ideas]

> The only way to validate the game state is to compare it with
> other copies and if a group of players all execute the same hack
> at the same time, it's impossible to validate since they are all
> in agreement with one another.

True again, see above, that is where the random number algorithim,
random numbers, fixed sequence, comes in.  You could use the same
idea for a battle system.  Client A (Hacked) says to Client B (Not
Hacked), I used 5 as a seed and got 7, how about you? Client B
responds, I used 5 as a seed and got 8 you silly hacker. True this
is simplified, but you get the idea.  This sequence can be a very
powerful method to ensure that all clients are operating on the same
numbers.

Whew,

Philip S. O'Donnell
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev