Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Why MP DLL's?

Author
Message
XFS Illusion
18
Years of Service
User Offline
Joined: 20th Apr 2006
Location:
Posted: 5th Nov 2007 19:16
I've been messing with a few Multiplayer Plugins, such as tempest and Multisync. These plugins are pretty easy to use from the looks of it. My question is, since DBP has it's own set of MP commands that appear to do the same thing, what is the benefit of using these Plugins? If there is a real benefit over the standard DBP MP Commands, what plugin would be recommended and why? Do they just make it easier or is it a performance issue?

dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 5th Nov 2007 19:26
DBP's MP commands SEUCK. End of. Story.

Also I recommend Multisync because I made an awesome demo for it with zombies, guns, shooting, headshots, did I mention zombies?

Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 5th Nov 2007 19:34 Edited at: 5th Nov 2007 19:35
In terms of functionality, DBP's MP commands are lacking as in order to construct messages you have to use memblocks, whereas with my plugins there are commands to construct the messages, which makes reading/writing them much simpler.

Another personal issue I had with DBP's multiplayer system is that it always seemed to take on average 10 seconds to initiate a connection, even with the server and client on the same machine. My plugins can do it pretty much instantly.

Lastly DBP's multiplayer system uses a range of ports (which can change depending on the version of DirectPlay used), which makes configuring routers more difficult. My plugins only use a single port.

Of course, other MP plugins that are around probably also don't have these problems, though I haven't checked.

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
XFS Illusion
18
Years of Service
User Offline
Joined: 20th Apr 2006
Location:
Posted: 5th Nov 2007 19:39
So which is better, Tempest or MultiSync? I noticed u created them both. I actually like Tempest, commands are easy to understand...Does MultiSync have features/abilities that Tempest doesn't have?

Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 5th Nov 2007 19:52 Edited at: 5th Nov 2007 19:52
It depends what you want to use them for. Overall I prefer the stability of Multisync, it's better coded.

Multisync uses TCP, which gives you a reliable, ordered data transfer system that automatically controls its own speed to avoid network congestion. The features that TCP implements do however create some overhead. I'd suggest this plugin be used for anything apart from where you will be sending a lot of the same kind of data at a fast rate, which UDP is better suited.

Tempest uses UDP, which lacks many of the features of TCP but as a result has less overhead. I would only recommend this for games where you must constantly send out new data to update player positions and such (first person shooters and the like).

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
XFS Illusion
18
Years of Service
User Offline
Joined: 20th Apr 2006
Location:
Posted: 5th Nov 2007 20:21 Edited at: 5th Nov 2007 20:25
It sounds like Tempest is better suited for my project after reading your descriptions. It's a 3D space shooter, so i'll be sending alot of floats to update player positions as they will be changing constantly. I'm not totally clear on what you mean by overhead, I assume it's TCP's need to constantly verify everything, but from the sound of it, tempest is probably my best bet unless anyone here feels otherwise on that. However, after reading the definitions of each, TCP does sound more reliable. Does this basically mean that UDP might send the packets out of order? If so, I wonder how this might affect a looped program counting on these packets.

Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 5th Nov 2007 20:32
Quote: "Does this basically mean that UDP might send the packets out of order?"

It's possible, although if you label all of your packets this shouldn't be too much of an issue. You can use a timestamp or sequence number to ignore old packets, if necessary.

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
XFS Illusion
18
Years of Service
User Offline
Joined: 20th Apr 2006
Location:
Posted: 5th Nov 2007 20:39
I wasn't aware that I could label my packets, this would have prevented some headaches lol

Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 6th Nov 2007 12:19
@Benjamin -
Do you know how much data a multiplayer game is usually sending out? Like, amount and how often?

Also, is the UDP 64 player limit arbitrary or imposed for a reason?


Come see the WIP!
Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 6th Nov 2007 17:41
Quote: "Do you know how much data a multiplayer game is usually sending out? Like, amount and how often?"

I can't really give a figure for this as it depends on the type of game and how things are handled. If you give me an example I can probably make a guess.

Quote: "Also, is the UDP 64 player limit arbitrary or imposed for a reason?"

It's just a limitation of Tempest. I could change it, but seeing as my next plugin will incorporate both TCP and UDP, I don't see it as a worthwhile investment in time.

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 6th Nov 2007 20:47
An MMORPG, of course

I have no immediate need for a plugin, but eventually I will want to create an online game. The next incarnation of your plugin sounds like just the thing.


Come see the WIP!
Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 6th Nov 2007 22:09 Edited at: 6th Nov 2007 22:14
Well I can only speculate as I have yet to code a MMORPG, so here is what I think, based on some assumptions. Let's take a style like Runescape for example, where you click a destination and your character moves across a plotted course to the destination.

Assume TCP is being used and headers and packet identification come to 45 bytes a packet.
Assume each movement will use an average of 5 waypoints.
Assume there are 25 players in a single area that all see each other.

The client sends a destination to the server, and the server replies with a plotted course, 5 sets of X/Y coordinates, both coordinates being floats. This is 80 bytes, but let's say 80+2 when the character's ID is added.

When the player wants to move, they click a destination. The client then sends this destination to the server, so that the waypoints for the path can be calculated.

Every update period (let's assume 1 second) the server gathers the data of the players who have requested to move since the last period, and puts it into a single packet to send to all the players. Assuming half (12) of the players are moved, each packet will be 1029 bytes. Now you want to send this data to all the players that can see each other, which in this case is 25. This update costs 25KB. If all of the players have moved in this period, it costs 50KB. Of course this isn't a sensible example as you don't expect 5 waypoints to be covered in under each second, but you get the idea. Let's just pretend the players can't decide where to go and pick new destinations every second.

Here is that rather crude equation:

CostInBytes = (((Waypoints * 16 + 2) * PlayersMoved + 45) * PlayersInArea)
KBps = (CostInBytes * UpdatePeriod) / 1024

As I said before this is just speculation, so take these values with a pinch of salt (or an entire salt shaker if you forget to screw the lid on properly).

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)

Login to post a reply

Server time is: 2024-11-25 12:51:37
Your offset time is: 2024-11-25 12:51:37