|
Author Topic:   Multiplayer Networking...
Bryan T
Member
posted January 03, 2000 01:57 PM            
Yay! ROAM is complete. This has been a great forum for discussion for all ranges of expertise and topics, so I'll head off on another tangent here too.

I'm beginning the implementation of a distributed-server multiplayer networking layer. I've been reading about the current state of the art and have chosen a game-object distribution method (similar to the Unreal engine).

In this method, the program does not worry about connections, messages, etc. Rather it spawns replicated objects (like players or bullets) which are created on the server and replicated to each client. By calling functions on the replicated objects various things occur: Rendering (local), updating variables (replicated), and actions (remote-procedure calls). A good overview is given by Tim Sweeny at the Unreal Technology Site. (Tim's pretty cool too, but not as forthcoming our beloved Seumas, something about big money just kills innovation)

My experience in networking is limited so I've been reading up on sockets in MSDN. I've also seen DirectPlay and several commercial products (NetZ, RTIME).

My goal is to abstract the basic networking code to allow for new plugins (for UDP, IPX, Appletalk, etc), while the upper-level abstractions remain the same (spawing a new character or a bullet for example).

Anyone have some advanced references to multiplayer client-server networking, distributed C++, remote procedure calls, etc.?

The end product of this would be an article and source that explains this technology and how to use it in a game. (interesting note, I've not found a single article about distributed-server technologies, that would make this article a first of it's kind in public domain, excluding the nearly unreadable academia articles).

Thanks & happy coding!
--Bryan

IP:

LDA Seumas
unregistered
posted January 05, 2000 04:07 AM           
I don't know of any good references, but I can give you the gist of Tread Marks' networking model, in case it's of interest.

I added networking to Tread Marks fairly late in development, and combined with not knowing much about network object strategies, I decided to take a much simpler (in some ways) approach which leaves the brunt of the work up to the individual objects. In a nutshell, the creation and deletion of objects (entities) on client systems is managed by the server, for non-Transient objects. Object types that are deemed Transient are only created by the server, but deleted by the client. Communication between instances of non-Transient objects on the server and client is handled through generic message buffer sending and receiving functions, which transmit and process the reception of plain byte buffers. It is left up to the code for the object when to send a message to its distributed client copies, and how to format that message. It is also up to the code in the class to process incoming messages, which will of course be in the known private format that the class uses. This works fairly well for me, since not that many Entity types actually require server to client message passing. Most are one-shot, fire and forget objects, such as explosions or unguided projectiles. Objects also never communicate from client to server, only from server to client. Client to server communication happens outside of the Entity system, and is restricted to control inputs.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

Bryan T
Member
posted January 06, 2000 01:16 PM            
Thanks for the input. I also found the notes on networking that you posted earlier in this forum.

There is a method called 'content push' which is essentially a full update of the gamestate each frame followed by a response from the cient (like user input). This is the most infalable method I have found, but requires the greatest bandwidth. Everything else seems to be a subset of this method in an attempt to save bandwidth.

The abstraction of the network layer should end up bieng similar to your implementation; a set of queues on top of UDP. I'm not sure how you implemented the networking within your game objects, but it sounds like it's not too far off of what I'm looking at.

Each object is created due to a user or world action on one of the servers. This object sends packets to the other nearby servers and any clients connected to its own server. Thus the clients instantiate the entity and the physics/rules of the world act upon it.

Is the Tread Marks server actually keeping the heightmap in memory and checking tank movement against it each frame/update? I would assume this is required to keep out cheating, but would be difficult to scale beyond a reasonable amount.

Also, are guided objects 'targeted' by the client or by the server? IE: does the client send the message "Shoot the nuke at tank X" or does the client send "I'm pulling the trigger" and the server select tank X as its target?

There is also the issue of timing, if I send a rocket out at time T, and it gets to the server at T+100ms, and to the other clients at T+200ms, then the rocket is already out of sync. Does Tread Marks use an algorithm to sync a Time Counter on the clients for your prediction system?

--Bryan

IP:

LDA Seumas
unregistered
posted January 06, 2000 10:55 PM           
Yeah, I see how the Content Push analogy fits. To work over a modem you need to seriously limit what state is sent each frame though, and it must be done on a per-client basis as well, based on world proximity and/or visibility for each client. A major factor in the smoothness of TM networking is making sure that state packets for the player's own tank (and other entities very close to it) get the highest priority, so are queued up first, and aren't as likely to be thrown out due to Rate Limiting as are more distant packets.

My game objects (Entities) have two Virtual functions, one to send a block of data (a message) to its clone on all clients, and one for a clone to use to receive a block of data sent by the server Entity. These virtual functions are overridden only if an Entity class actually needs to send and receive messages (beyond creation and deletion, which is handled by the engine), which many do not. The Networking layer which handles sending and receiving Mini-Packets from the game is contained in a global object, and is highly abstracted from the app's perspective.

The Tread Marks Dedicated Server uses the very same code as the single player game (which by default is also a game server you can connect to), except that it has no player entity of its own, and does no graphical display. So yes, it loads the height map as normal, and does all physics/collisions as normal. The dedicated server uses a fairly small amount of CPU time though (25-33% on a P133 for an 8 player AI tank battle), so that isn't a problem.

For guided entities such as nukes, the server creates the non-Transient entity on the client, and the client flies the nuke as if it was local, targetting the nearest enemy using its local enemy tank positional info. The server nuke entity also sends message packets with updated position and velocity though, so if the client predicts the nuke's guidance wrong its flight path will be corrected. So yes, the client says "Fire!", and the server does all official targetting and physics.

Timing is a tricky issue... What I ended up doing in TM is only forward-predicting the Tank entities, which includes your tank _and_ the enemy tanks around you. Tank physics are predicted forwards by the Server-to-Client packet trip time, so that what you see on screen is (predictions being correct) what is happening on the server at that exact moment, as far as tanks are concerned. All other entities (projectiles, explosions, etc.) are lagged, and not predicted into the future at all. This means that you will see projectiles leave your weapon with lag, but because all tanks are predicted, if you aim exactly as you would in a single player game, you will hit the enemy. With a lagged connect, you will see your bullets hit the spot where the target tank would have been without prediction, and the explosion will appear there as well.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

KC
New Member
posted January 16, 2000 12:09 PM            
I was looking into this subject last year when I was contemplating a game server for monster truck madness on-line racing.
MTM uses the directPlay object of DirectX.
You can DL the full spec for free from the MS web page in the develpoers section, and it explains, in detail, all about how diectPlay handles multi-player network play in real time.
You may be able to gleem some insight into how to aproach your project from seeing the spec on a format that works very VERY well.

I'm no programmer (well, not a very good one), I'm a hardware guy, but hey, info is info, I hope that helps.

IP:

Kaeto
Member
posted January 17, 2000 03:27 PM            
The most lag-free gaming engine I have ever seen is activenet... I can play battlezone 1 with 7+ other people and have no lag if the host has a good connection...
I mean NO lag... I shoot, I hit, I kill... just like in single player.
Oh, did I mention I have a 24000 connection?
Gotta give activision credit...

IP:

Bryan T
Member
posted January 19, 2000 11:11 AM            
Thanks for all the responses, I've been reading up on more network technology. There's an excellent piece over at Gamasutra.com about Pluggable Factories for network programming.

I liked the pluggable architecture (it never worked with my old compiler, but VC seems to support it well). Hopefully I can get back to the network code soon, but still a few things to polish up on the landscape engine side.

I wasn't keen on Direct Play. All of the DP stuff can be easily implemented with UDP or TCP passing a simple protocol. I guess it doesn't matter, but I like to think cross-platform.

Kaeto, unfortunately lag-free with 7 people at 24K is not too impressive these days. When I crank up TRIBES and play 32 player games over a 56K modem with no lag for hours - that's impressive.

I used to write text-based arcade games for local BBSs, everything from Space Invaders to PacMan, with modem users @ 1200bps to 4800bps. Unfortunately you can't compress text streams meant for a terminal.

Activision did well for their product though, you're referring to the remake of the old 80s game, no? I was not aware of multiplayer aspect to it though.

--Bryan

IP: