Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Simparadox

Multiplayer Online Game Client

This topic is 6107 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

(Sorry if this should've been posted in a design forum, but I figured even though the question is abstract it's closer related to the technical aspects of design than it is to building game mechanics and such) Hey everyone, First of all, I know that subject probably made some of you immediatly think "Oh, boy.. another amateur developer getting in over his head". Well, whatever you're thinking... you're right . I'm currently designing a pretty damn ambitious project with a fairly small group of people. Our intent is to develop a commercial-level Massive Multiplayer Online World, or MMOW, within 2 to 2 1/2 years. It started as a project for a network programming class, but now it's snowballed into this. Our goal is to attract the attention of and pick up a publisher by the time we're ready to go to beta and, if we can't do that, scrap the project all-together. Now, since I'm technically the most experienced programmer in the group I've been charged with planning everything ([sarcasm]yay[/sarcasm]). And while everyone else is off doing the fun stuff like figuring out game mechanics and features, I'm left figuring out how the hell we're actually going to code this thing. So, here's my question... Since we want to give ourselves at least 4 to 6 months of pure design time before actually programming begins, I've started to figure out how the client- and server-side programs will work and interact in abstract terms. I've come up with a very basic outline for the client program, and it seems to be the most efficient method. Of course, since this is my idea I'm a bit biased. So, without further ado, here's my outline. Suggestions, criticisms, and even flames starting with "You idiot! You're doing it all wrong!" are totally welcome. (Short note: This is an abstract plan. The components here don't represent objects, procedures, or anything else concrete. They are simply "parts" of the whole.) *Graphics Engine - Should be obvious. This is the 3d, first person engine that'll be used to display the world to the player. *Physics Engine - Basically a back-end to the graphics engine. Stores rules for object movement and such within the game environment. *Sound Engine - Do I really have to describe this one? *Music Engine - Er, well... handles the game's music and switches between tracks at appropriate times. *Interface - The "tools" and "commands" the player uses to interact with the world. In my mind, interface means everything from the keys the player uses on the keyboard to the on-screen windows that display information. The interface "uses" the graphics engine, but is not "part" of it. *Player/Entity/Object Information - The client is going to store information about the player, nearby characters, objects, etc. locally. Only information the player would reasonably have access to (information about his own character or nearby objects/characters) will be stored here, and it will be checked against the server DB information constantly. *Network component - Finally, the big one. First of all, this is only half of how I intend the program to handle communication with the server. The other half is in the "interpreter" below. The network component will receive messages from other components and use them to send server requests. It will then receive server messages and pass them along to the interpreter. The network component will also determine latency between the server and client and notify the player should the connection be broken. *Interpreter Component - I spent some time thinking about whether it would be best to immediatly interpret messages from the server, or to pass them along to a dedicated component that could queue them up and act on them as necessary. In the end, I decided to seperate the interpreter. The basic purpose of this component is to take any messages received from the server and pass them out to the component that can handle them. If the player's stats need to be updated, for example, it'll pass the message along to the player information component along with the new stat and that component will update it. If a chat message is received it'll be given to the interface component, which can correctly display it. And so on. Well, that's about it. The only thing that isn't included here is any sort of actual "gameplay" component. The reason I've omitted this is because I'm not sure as to whether it would be prudent to even include it as a part of the client. It makes more sense for any gameplay calculations (hit/miss on attacks, damage, skill checks, and so on) to be done server side with the result being passed along to the client. In this way any actual gameplay code would be divided among the various components. If a "damage received" message is sent from interpreter to interface the interface component would know to update the player's stats and print a message, for example. So... suggestions? Comments? Flames? :-D EDITED: Stupid, damn, !@$!@#!@#)) typos Edited by - Simparadox on September 9, 2001 2:20:07 PM

Share this post


Link to post
Share on other sites
Advertisement
I havnt designed a full scale engine yet but I have 2 statements...

First, i dont see why you break up your sound and music into 2 different "engines"... seems a little redundant to me.

Another part is the network and interpretor engines. Why not simply have the network code interpret the messages instead of sending them elsewhere... as above, seems a little redundant to me.

Have you choosen the graphics api yet? dx8 or opengl?

have you choosen the network api yet? dplay8 or winsock?

Share this post


Link to post
Share on other sites
When you choose a network API consider the style of game that you are intending to produce. If it is slow paced, turn based or simple not that complex Direct Play would be well worth considering since it would save a load of time.

But if you are looking at RTS, fast paced action, good sync''ing go the Winsock route. There will be more work involved but ultimately you will have more control over the system and be able to work in your own optimisations.

Share this post


Link to post
Share on other sites
quote:
Original post by GalaxyQuest
I havnt designed a full scale engine yet but I have 2 statements...

First, i dont see why you break up your sound and music into 2 different "engines"... seems a little redundant to me.



Well, this is just a rough list of what needs to be done for the game and so I wanted to keep each "part" distinct. The main reason I chose to seperate them, though, is because their purpose and function is so different. The music will be playing constantly (unless, of course, the user turns it off) and the program will have to switch "tracks" at the appropriate time.

Non-music sound, on the other hand, will need to be played at the appropriate time in addition to ambient sound. As far as I''m concerned, these are two very different parts of the game.

quote:

Another part is the network and interpretor engines. Why not simply have the network code interpret the messages instead of sending them elsewhere... as above, seems a little redundant to me.



Well, like I said, I wasn''t too sure about this. When I considered the job the "interpreter" would be doing I thought it would be better if there was a dedicated piece of the code that queued up the messages it received from the server and handled them at the appropriate time. The network code, on the other hand, only sends and receives messages.

quote:
Have you choosen the graphics api yet? dx8 or opengl?


Most likely OpenGL since I''m familiar with it and already have a partial 3d engine finished.

quote:
have you choosen the network api yet? dplay8 or winsock?


I''m not too sure about this yet. I''m familiar with Winsock and positive I could handle programming Winsock network code for the game. On the other hand, I''m completely unfamiliar with DirectPlay so I''m not sure what advantages it might offer over Winsock.

Share this post


Link to post
Share on other sites
I''m in the same boat. I''ve got a MMORPG group and I''m stuck with the task of figuring out the network side of things. For a game the size we plan to make, I need to find out as much as possible about what current MMORPG games out there use in the way of servers and how they are communicating to each other. I''ve heard a lot of talk about linux server farms but have no idea on how to make a robust and scalable server setup of that size. Any opinions?

Share this post


Link to post
Share on other sites
well ive been playing a large scaled mmorpg called lineage some time now, what i know of, it runs on 3 servers..

a updateserver
a game(world)server
and a npc server

it run under linux, fairly stabil also, crashed like 2~3 times in 2 years on the server i play..

it can even run about 200 ppl on a 386 the admin told me.

well, what the server should run on and how to split it im not sjure, differs i think depending on game and max clients u want to be able to play same time...

i would guess linux as server woudnt be a bad choice...


--------------
Guns dont kill people, people kill people....

Share this post


Link to post
Share on other sites
Depending on what you expect your server to do one computer should be able to handle it. Back in the days of 90MHZ computers, server farms were a must. The server for Tombstone: Vendetta takes at least 1GB of memory. In terms of what it actually does a 333 AMD can handle several thousand players no problem.

The series of development for Tombstone was:

Tile Editor
Map Editor
Single Player only
Multi Player only

Once you can display a single character walking around the game world putting in N characters over a network is easy. Whenever I add something to the client I make it independent of the server first. Once it works I link it to the server within an hour or two.

Basically get it working first. It used to take hundreds of bytes per second to just walk around. Now it takes 72. You won''t know what optimizations you can make until you have a rough working model first.

Every game is different so there is no set answer.

Ben

[Icarus Independent | Jump Down The Rabbithole | Tombstone: Vendetta ]

Share this post


Link to post
Share on other sites
What do you have store in 1GB of memory? Since this is a server program, you wouldn''t have any graphics in the memory...

Is it all character data, like positions, inventory, etc? Just wondering...It''s a huge amount of memory

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
My advice would be to start prototyping your app early on (during that 4-6 month period that you have allocated for ''pure design''). I''ve written a simple virtual environment app with basic concepts similar to the one you are describing and I think early prototyping is key to getting anywhere in the design phase.

My app was written in Java and was aimed at studying synchronization and scalability techniques on the server (the client was a simple network-driven 2d grid where player positions were updated as messages from the server arrived). Even though my app was really small I got around to making several huge design changes (such as replacing my initial network protocol, RMI, with something that was much simpler and faster to implement, serialization streams over TCP/IP) and I seriously doubt that anyone can get everything right from the start in an application as complex as a full-blown MMRPG.

ajoling, KalvinB will probably need some sort of graphical/geographical data on the server to handle collision detection for the players and pathing/line-of-sight information for NPCs.

Henry

Share this post


Link to post
Share on other sites
1GB of memory is mostly for characters. The map is only about 144MB.

The server doesn''t handle the NPCs. There''s a bot for that. They both just need a 2.7MB file which describes the tiles and the map to do pathing (not yet implemented) and collision detection. Neither the NPC bot or the server load a single graphic.

Ben

[Icarus Independent | Jump Down The Rabbithole | Tombstone: Vendetta ]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!