I’ve been going about making a small, multiplayer game for about a few weeks now. Before then, I was using a Java server and just connecting my client up with the socket module. But recently I’ve been having a few questions about the built in server-client architecture P3d has.
who(client or server) handles the zones, worlds, characters etc… in most multiplayer games
is it possible for the actual server to hold the world and have all the clients just connect to that same world(they’re actually viewing the same thing)? I before thought the clients held everything and just sent their current state and location and drew each other to the screen.
are there any good examples of a server/client in P3d? If so, are there any that implement the above?
I’m new to game dev, but not new to programming in general. Any answers are appreciated.
I don’t know if there is an unique answer to what you wish.
I develop recently such architecture for a multiplayer game using panda.
From my observation of existing AAA games, I decide to use this architecture:
One server (program) dedicated to be :
– server on which users connect
– server redirects to the right zone server
– server handles world transaction, chat, …
One server (program) to handle/manage a zone. I will launch X times this program on different physics server to handle my x zones.
– server manage physics
– server broadcast all NPC and players movements and decision
Client will connect a first time to world server to have information to connect to the right zone server.
When you change of zone, you disconnect (close the socket) from the zone server, and you ask to world server the information to connect to the new zone server (IP + port), and so on.
I choose to communicate with TCP communication on world server, because light messages, and relevant ones.
With zone server, I use TCP for important message (new player, new NPC,…), and UDP for movement, because there are lot of message, and if you miss one message, another one will be sent all 0,25 seconds.
Do you need other information?
ps: I talk to you architecture, and it is independant from technology.
When I said zone, I meant area - sorry for the bad wording. The context of zones in which you’re using it is a replacement for the word server. No, I know how to manage multiple servers. Zones in the case I meant are just areas a user could go to, teleport etc… that are separate .egg files in the same server.
Still, do you(or anyone else) know of good tutorials that demonstrates P3d’s networking capabilities? Like before, any responses are appreciated.
And, thanks @shimrod. I’ll think over what you’ve said.
The manual includes some basic implementation demos like Client-Server_Connection, but you could also consider implementing your networking using just python; the socket library is fairly straight forward. I’ve been working on my own server/client based game for awhile now and I have a basic setup working, though still crude. If you’re interested in trying that route I can share a basic example, but in answer to your general questions just some thoughts (keeping to single server setups for simplicity) :
how the workload is split is dependent on the type of game but usually the server has the final say in terms of basic physics, i.e. it contains the master state to which all the clients adhere as best as possible.
however offloading everything onto the server is often undesirable in terms of the workload this would entail (handling all collisions, etc) and the lag users would experience when moving their own player (since they would have to wait for the server to respond to their input.)
generally the client also does its own physics (i.e. local collision detection) and/or uses some kind of predictive mechanism to prevent lag or stutter while waiting for server delays.
above all, client and server state must be synced somehow, usually this means the server having the final say and (gracefully) overriding the client when they get out of sync.
the server contains the world and areas, and the clients connect to that. The clients are little more than dumb terminals except they handle collision detection and prediction
the display of the server and the client needs to be the same - the server has the last word.
Although I still have a question. Like, how would you implement this kind of setup in a practical way? It seems to me to capture all the client’s actions and send them to the server in a json message to be processed. But then, how would the client and server be looking at the same thing? How would I go about setting that up? Also, how would the client do collision detection if the map is on the server?
Let me know if I missed anything or if there’s anything left to add.
A general starting setup might be (concentrating on only core game services):
server:
receives connection from client and stores contact info like address (host, port).
uses Panda3d objects (Vec3, Point3 - for state) and other panda services (collisions, etc).
doesn’t open a graphics window or load models for display, but loads collision meshes of the world and objects in it.
runs a main loop that updates and maintains world state based on whatever forces/rules you need (i.e. gravity), including collisions.
runs a separate thread that continuously loops, reads this state, and sends it via UDP to clients.
receives commands from clients (i.e. move char forward, left, right, and so on) and integrates the results of applying these commands into the world state.
client:
loads both models and collision meshes; as well as launching the display window.
contacts server and exchanges relevant info (via TCP)
maintains both a server based “world” state and a local “deviation” state (used for predictions and such.)
runs a main loop for receiving and handling commands from both the user and the server and handling local collisions.
listens for server commands on a separate thread (via UDP), converts these cmds into python data types and stores them as the authoritative world state from the server.
listens for user commands and sends them (via UDP) to the server but also applies their results to the local deviation state (using the same rules as on the server).
during each main loop it loops through all relevant local objects and updates their positions, rotations, etc in the scene graph by applying a combination of the world server state and the local deviation state.
the deviation state just adds little adjustments when applicable to hide lag and stutters etc.
for example if you move your char forward 1 meter, rather than waiting for the server world state to update and then broadcast back to the client; you add the same amount for your char to the local deviation state which then gets immediately applied on top of the client’s copy of the world state resulting in instantaneous movement.
the key is managing your local deviation state so that the command has been cleared by the time the server’s world state is updated and returned to the client (or they’ll combine and your char will now be 2 meters ahead.)
This is essentially where I’m at; though I’ve only been working on a LAN with a few computers, no real testing yet.