(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
-George J.L.Owner of Simple Paradox Designs and Obnoxious Minor Diety
