I\'ve been working on a document that just contains some undeveloped ideas for a MMORPG structure that would allow people to do things such as bringing their own models; sharing datafiles accross servers; and transferring sounds, models, and real-time speech without putting too much load on the server.
I\'m willing to share it but should I put it all here? It\'s quite large... I\'ll put a small piece of it here. Keep in mind, the thing was written with .hack in mind; it\'s basically a partial clone of \"The World.\" I started out that way but changed my mind on that approach and really am going for a flexible specification. Still, character classes, items, and skills should be defined to allow for character data to be shared between different, unassociated networks :) (At least those that support this).
First is the TOC. Notice the Anti-Cheat stuff? I want the client to hold his own saved data, to take space demands off the network.
--CUT: mmorpg.plan--
FEATURE LIST TOC
[v1.0 features]
- Anti-Cheat
- Network/Server Issue Binaries
- Compilation on Client
- Cyphered Data Files
- Cross-Network Translation of Data Files
- Execution
- Server
- Client
- Client Load Bearing Structure
- Data Storage
- Object Orientation
- Cyphering
- Interface and World Control
- World Creation
- Elements
- Construction
- Dungeon
- Monsters
- Character Interaction
- Conversations
- Parties
- Sale and Trade
- Battles
- Message Boards
- Selected Interface Download
- 2D
- 3D
- Character Motion
- Caching and Control
- X-Space
- Items
- Items
- Weapons
- Armor
- Elements
- Fire
- Ice
- Lightening
- Water
- Air
- Earth
- Bane
- Virtue
- Character Classes
- Mage
- Black Mage
- White Mage
- Sorcerer
- Elemental Sorcerer
- Swordsman
- Maji
- Heavy Swordsman
- Tech
- Axman
- Bowman
- Ninja
- Martial Artist
--END CUT: mmorpg.plan--
3D is all done with .blend blender models, and motion with python scripts. The idea is that you can call functions to manipulate bones in python scripts. Then you just adjust the position and angle of the model, and the client renders it fine. :)
I\'ll also share the CLBS section right now.
--CUT: mmorpg.plan--
===============================
=Client Load Bearing Structure=
===============================
If there\'s one thing that is going to be laughed at, it\'s the X-Space
CLBS system. CLBS is a completely voluntary structure for sharing load in an
attempt to share resources and decrease game latencey.
CLBS is simply a concept, not a protocol. The idea is that each client
shares some of the data transfer load from the server if it can. It is meant
to allow servers to run without having expensive, high-end machines and
outrageous connections. In essence, it\'s an attempt to bring the load on the
servers down enough to allow advertisement-supported (\"free\") services. Here is
a rough outline.
First, clients get their link tested. The client uploads, for caching,
its entire set of data (speech synthesis models, graphics, and character data)
to all servers on the network simultaniously. The total average upload speed
is noted; the user may adjust if he knows what he is doing. This value is
automatically recalculated with stats taken whenever the client\'s upload to the
server or other clients is under heavy stress, especially if it starts to
choke.
Next, the download (incoming) speed gets tested. If it is higher than
the upload speed, it is assumed that uploading is capped, and that the last
bit of this download speed is shared with uploading. If it is lower, it is
assumed that the link is the speed of the upload measurement, and that the link
was measured with error. The user is prompted and may choose to average these
values or take the higher value (upload speed) as the true speed.
Once it is known how much load the link can handle, the client is
allowed to adjust how much it will allow. It may adjust up to this calculated
upload and download speed for each direction to use for CLBS.
When a player is near other players, his client periodically checks
their CLBS settings. The ones with CLBS enabled are pinged periodically.
When persistant data download--character models, world models, and
such--is needed, the higher-range pings are checked for bandwidth availability.
If they have the necessary upload and download bandwidth available, they are
used to transfer part of the data.
When realtime data download--voice data for example--is needed, the
lower-range pings are checked for bandwidth availability. The sender transmits
to the lowest first, up to his maximum free upload bandwidth. They get to hear
the speech with that latency. They transfer out to others specified in a list
that comes with the data. Each one of them gets a list of which to transmit
to. They transmit to as many as possible, up to their own available upload
bandwidth, favoring lowest ping CLBS capable clients first (excluding those who
have already gone through this). They pre-calculate if they have enough to
send to everyone on their list; if not, they split the list up and transmit to
all of the CLBS capable clients first, then any not capable last. Once the
list reflects that all nearby CLBS capable clients have been used, any
remaining clients have the misfortune of sharing a laggy connection. However,
the server itself may be a last-resort CLBS relay, and be used in such a case.
This may be calculated for by the initial sender.
Here is a tree illustrating the process and latency [ping,dl,ul] with
twelve characters around (NEED FIXED WIDTH FONT!):
sender = [0,0,2]
/a \\b i
[9,5,3] [11,1,4]---[13,3,1]
c/ d/ e/ f\\ g\\h\\
[14,3,2] / / [15,1,3] \\ \\
j/k/ [15,2,2] / [12,2,3] \\
/[14,2,1] [15,2,2] [10,4,2]
[10,2,1] l/
[12,2,1]
Summary: [link] - [Latency], [Clients]
a - 9, c d e i j
b - 11, f g h i l
c - 23, j k
d - 24, none
e - 24, none
f - 25, none
g - 23, none
h - 21, l
i - 24, none
j - 33, none
k - 37, none
l - 33, none
Notice that the latency adds as the signal propogates. Also notice that
the signal is propogated mainly through those clients with the lowest latency;
only those paths with total pings of 9, 11, 23, and 21 were used. Only one
download space and one upload space is needed for a CLBT sharing rely; in worst
case, each client may have only enough bandwidth dedicated to be streamed
through as a single relay. A \"space\" is a chunk of bandwith large enough to
handle the stream.
CLBS is most useful for realtime data streaming to large numbers of
clients, especially voice. However, if a lot of data is being downloaded from
the server--for example a player walking into a crowded town must have his
model downloaded by everyone nearby--the server may request that clients with
enough bandwidth who have said data cached aid in distributing the data. Also,
it is likely most useful to allow the sender to stream data down to as many
relayers as the sender can handle, and only give them as many targest as they
can handle. The sender should in this event keep one spot free himself, so
that he may give the rest of the list and the data to the server for relay.
Another supported and interesting variation is to allow the server to
keep a list of high-bandwidth clients around, and to keep each client in
constant awareness of these. This would allow something other than the server
as a fallback.
Remember, CLBS is a voluntary system. If an implimentation forces the
system on its users, that network can expect a very low user count.
--END CUT: mmorpg.plan--
EDIT: The full document is 42.5kb, should I post it here?
--Bluefox
