you're making this harder than it sounds...

i had 7 "friends" (although i refer to them as just "people i know"), and about 30 of their friends and their friends and so on...all of us where connected via IP: barely any lag at all. the only time i ever got any lag was when we where all in the same viewport. (it took me like two weeks to arrange all of this...i had to make a few phone calls and email/upload my mmorpg demo about 10 times)

each of my yi.org servers can handle an unlimited amount of users...however my server program hasnt been tested to the full limits. so hopefully once it's done i can get a whole boatload of people on their to test. if it crashes: oh well, i'll get a few more server IPs and split people up into "shards" (ala UO).

and a database for maps? geez. make one BIGARSE map file and include it with the game (again, ala UO).

ITS NOT COMPLICATED AT ALL!

client:
if(player has moved)
{
sendtoserver = playerlocation(x, y);
}

server
if(message has been recived)
{
if(message_id == player has moved)
{
relay new player location to all clients within the players viewport;
}
}

it works exactly like that. dont try to make things more complicated than they have to be.

i'll be on the edge of my seat waiting 3 to 10,000 years for someone to make another bloatware MMORPG. ive only been working on this for about 7 months now...take that.

but other than that, its mostly design with the player in mind. ive decided that i'm going to have about 4 servers: each with their own rules and functions. one supports PvP and one doesnt, ect.

yeah, yeah. all of you "bigshot" programmers think that this is all unorganized and sloppy...well you should see the HUGE pile of computer printouts and scratch paper sitting on my desk. i have planned this out very well, and so far i havent been dissapointed (exept for a few days where i was pissed at my code for not working correctly ).

maybe i'm making too much out of this, but i take hobbies like programming seriously (considering that programming is basicly my life now).

and i AM right. a MMORPG is a RPG with client/server. there is no other way to do this. you can try client/server (MUD, bsicly) first and then add in graphics, but this has yet to be accomplished to the best of my knowledge.

(puts on his flame-proof bodysuit and awaits a flamewar from those "bigshot" programmers.)

Edited by - gameprogrammerwiz on July 3, 2000 7:04:01 PM

Edited by - gameprogrammerwiz on July 3, 2000 7:06:31 PM

Well first off, I should clarify that I''m not trying to flame anyone, and I''m not trying to be a know-it-all either. I''m just knee deep in this stuff right now, and have well-developed opinions. One of the points I was trying to make was that I personally do not believe that it would be easier to design a single player RPG and then upgrade it to a massive multiplayer one, for there are major design DIFFERENCES in some key parts between the two. Not that its harder , but different.

If you got something working with 30+ people, I''m impressed. I still would wager that under higher loads(say 3000?) you results may vary drastically from what you currently have. Witness poor Blizzard this week, 1.5 million copies of Diablo II sold, and Battle.Net is still groaning under the burden(not quite the same I know, but just a point).

Why are we using a database system rather than our own file routines? Simplicity. I want to have server side map files that are multi-gig if need be(not distributed to clients neccessarily). Anyway, if I have several HUGE files of information, swap will not cut by loading the entire thing into memory, and writing blocks of data and quickly indexing whats needed would be problems as well. Your production quality DB servers already do this, and are easily interfaced by ODBC, ADO, or whatever your favorite is. Another reason for a DB server is that it doesn''t have to be on the same machine that your players are logging into. It would be entirely transparent to our current setup to make 10 login/play servers on a load balanced switch/router with 2 replicated DB servers on a private backend network. No change to our simple codebase. Another serverside danger to look out for is memory leaks. Memory leaks on a server running 24/7 will eventually suck down all of the available memory, and even the best of us make mistakes(unless your using a garbage collector, then who cares .

I will grant that you are right about the RPG and the client/server being inextricably tied, but if I were designing this game to be played single on one machine, I would have made some vastly different decisions that would simplify some areas of code.

I''ve shared some the design decisions my team has made, and I would be curious to hear yours. This is a discussion board, and rather than turning into an all out flame war(which I may be provoking , how about talking about what kind design decisions some of these other people have made who are actually working on MMORPG?

quote: Original post by gameprogrammerwiz
+snip+
a MMORPG is a RPG with client/server. there is no other way to do this. you can try client/server (MUD, bsicly) first and then add in graphics, but this has yet to be accomplished to the best of my knowledge.
+snip+

When someone says EQ, I think of a MUD with graphics.

I agree with gameprogrammerwiz, I think that we sometimes make these things harder than it is. I have been coding Winsock apps for about two years. It could have been 4 or 5, but I always thought that it was too difficult... doh!

On the other side, I have learned some things along the way.
My last server app was a limited database server. The company used a proprietary ISAM file format. My server located and returned the data requested. I had originaly writen it singly threaded and it bombed. As this server was "hit" by a CGI process from the web, it needed to respond in a timely manner.
I then determined that it would be best if I redesigned the code to spawn threads to handle each client request, and all was well.

I''m currently writting my reliable UDP code, and "making this thing harder than it has to be."

Just remember K.I.S.S.



Dave "Dak Lozar" Loeser