Hey everyone. So, I have all the basic functionality of the engine worked out (window, video, scripting, models, physics, etc), now I need a client/server model to get everything running. Now I have never designed anything client/server related, could someone give me an insight as to how is it going to work? Where do I keep my scene graph? How does the client talk to the server (not sockets and stuff, but in general), when do they communicate? How will it work if the game is ran on localhost? Pretty much, if someone could walk me through it like I'm a 2 year old, that'd be great. Paper/Tutorials are welcome too. Hope Im not being too vague, Tim

So it's not about networking, yet there's localhost? I'm confused...

Quote:Where do I keep my scene graph?

On server and on client, representations of scenegraph will likely differ, since server doesn't do rendering. Client sends the changes it made to server and temporarily simulates its own local copy. Server receives changes, applies them, and sends authoritative state. Client verifies that the changes it performed are same as server's state. If not, it undoes them and applies server's state.

Basically, server and client keep several past frames of state (could be scenegraph), and if there's a problem, the discard as many as needed, and run the simulation from that point again.

Quote:How does the client talk to the server (not sockets and stuff, but in general)

Asynchronously. On each tick, it sends the actions it performed during last update, such as user input. It then proceeds to execute actions to keep simulation running.

Quote:when do they communicate?

Networked game loop is:

while (true) {  if (isClient()) checkInput(); // interpret keys, mouse, the stuff  sendOutgoingData();     // send input, and perhaps some other data  checkForIncomingData(); // read what server had to say,                           // perhaps adjust local state,                          // perhaps roll-back to some previous frame                          // if server says your actions weren't valid  updateLogic();          // catch up to current time                          // may need to simulate several past frames to                           // correct for illegal actions as determined by server  if (isClient()) render(); // duh...}

Quote:How will it work if the game is ran on localhost?

Exactly the same as over network, by opening a socket to server. The only difference may be that instead of utilizing network adapter, OS may choose to send the data between processes via some local memory buffer.

Minimal implementation. It talks about MMO, but it's just a generic networking model. While implementation would differ slightly for FPS, the basic idea remains the same.

Ok. I understand virtually everything that is being said, now I have no clue as to how to implement it. I can't wrap my head around it and I don't know where to learn. The minimal implementation link you gave me, to be frank - I don't understand, it doesn't make it clear to me (nothing specific, I just don't see the big picture).

I don't understand how "input" that is being sent between c/s going to be shaped. What is "input"? Straight keyboard/mouse snapshot? Commands? I don't even have any commands that I could send :(

How is the world organized and stored on both client and server?? Not to mention how the entities and players are going to be squeezed into the whole painting. What goes into packets?

I don't mean to be ambiguous but I just can't get it.

How does everyone else learn it?

This is very frustrating to me.

- Timo

How much experience do you have with event driven programs? At its core its nothing more than than event handlers ( code which consume events ) and event producers ( whatever code which create events ) and code which transports and hold events inbetween.

There are reasons for using events vs say direct function calls or holding the objects directly. They are losely coupled ( ie the only relation ship between the consumer and producer are the events, usually ), they are asyncrhonous ( you can produce events on one thread and consume it on another, also you can record events and make a replay system ), due to the loose coupling and their compisite nature (ie instead of using inheritance to define beahvior u you compsition ie. the types of event handlers you have define your beahvior ) their beahviors can be extended at runtime ( ie. by adding/removing event handlers you change the behavior of an object easily ). There are im sure other reason, but these are the main ones i know of.

How is this related to server-client programming? Well server-client programs when they reside within a single applciation are ususaly called someother paradigm, like MVC (model-view-controller), thats more apt. They break down the applciaiton into the same basic structure.

This should get you started, just wiki some of those ideas and terms.

Good Luck!

-ddn

Sounds perfect, great. This should definitely give me a starting point to push off.

Thank you very much, your post was quite insightful.

-Timo