my sense is that object passing between clients/servers is generally a bad idea b/c an object is far bigger bitwise than the actual information that is strictly necessary.

example:
object passing version -
move a player on ServerA
send player object (fairly sizeable object) to ServerB
ServerB now knows where the player is

homegrown socket programming stuffs version -
move a player on ServerA
send new player location (3 floats) to ServerB
ServerB now knows where player is

the idea is that there is far more information in the player object than the other client needs to keep getting sent in order for the game to run. you don't need to update the skin name every frame, for instance. you are probably going to end up wasting a lot of bandwidth using object sharing that you could otherwise be using to make your game run faster.

but then again i have no idea how MFC / .NET object sharing stuff works. maybe it's incrediably effiecient. i kind of doubt it tho. my sense is that .NET is meant for web based information transfer where a 1second wait time is of little significance. though you could get a workable solution out of using a technology that was developed for an entirely different purpose, it's most likely not going to be as performance sensitive as you need it to be for a MMPORPG.

it's good to see that you aren't using remoting for client to server, but you probably need the same performance tweaks in server-to-server communications that you do for client->server communications...

-me

[edited by - Palidine on December 2, 2002 4:13:43 PM]

I''m going to be totally non-constructive here.

This reminds me of an article I read that found people who are completely incompotent often have no idea they are incompotent. Sorry man, but you should be taking baby steps here. You can''t just start off making a MMOG by yourself while having no clue about what you''re doing...

AP, people can pretty much start wherever they want. baby steps is best for some, jumping into the fray is best for others. i definitely fall into the latter category. my first game ever was a 3D game with an original engine. i didn''t know linear algebra/ any 3D API / or have really good concept of software architecting. worked out fine. great learning experience. whatever...

anyway, yeah, so i actually just posted my last response without any attention to reading comprehension. You''re definitely safer going with Remoting if your servers are on a LAN. but if you are going to go through all the trouble of designing your own custom network layer for client -> server anyway, why wouldn''t you just use the same thing for server -> server. you are almost definitely going to make something that''s more efficient than Remoting even if you are a novice (er...kinda loaded potentially untrue statement but just ignore if it makes you angry .

the key for network gaming stuff is to divide things between "needs to be guaranteed" (need to use TCP) versus "does not need to be guaranteed" (can use UDP). TCP is significantly slower than UDP b/c it involves back communication i.e. "sending packet" "packet recieved" type of communication. even your server -> server stuff is going to have both kinds of information.

and you really don''t want the server -> server stuff to be lagged just as much as you don''t want the client -> server stuff to be lagged. a bottle neck is still a bottleneck even if it''s on the server -> server level. make it all as efficient as possible.

i''m just knee-jerking against using something like .NET remoting b/c as i previously mentioned i really don''t think that it was designed for the type of performance that you are going to need. but then i also don''t really know anything about it cept it''s made by MS and they''re known for bloatyness that''s great for convienence but not necessarily for performance (see MFC).

-me

i dont know what kind of sharing the servers will be doing...i''m assuming it''d be a regional zone configuration. therefore, if your having the players switching servers and the transfer of info is lagged, there may be a problem lag time in your protocol for switching servers? also, if you plan on having players in zone A visible to players in zone B, that''d probably require a lot of information processing. while it may not seem like that many updates, when you have 500+ people, not to mention npcs having to be updated...you''d want an efficient stream. finally, I do not know that much about dplay but I''d assume it will be a lot slower than pure winsock (which if you look at some of the online tutorials is not very intimidating..you could probably learn it in the time it took to discuss this). you meantion all other major MMORPGs, well most of the ones I know pretty much use winsock. and also if memory is correct, AO had a horrible opening because they implemented a horrible protocol over TCP (with crap options on) and many people laged out. just trying to help, good luck with your game.