|
|  |
|
| eFalcon 1.0799 | -preview of future versions... |
|
|
 New Multiplayer Code |
Multiplayer Code
Since build n108, the multiplay code was updated to try host/client code. This means that multiplayer will be much more stable and much
smoother with many players.
The host is the computer that starts the game! (Enters the TE/CAMP/DF first, not the one who sets 0.0.0.0 in the IP.)
The host needs bandwidth!!
The higher the host bandwidth, the more smooth it will be and the more players will be possible. As a general rule, one client uses
33.6 baud so if there's 4 players (3 clients) the host needs to be able to produce 33.6 * 3 = 100.8 baud.
If a host with enough bandwidth is not available, you can still fly but the position update rate will suffer.
How did the original code work?
The old code was not really built for low bandwidth internet gaming, but meant more for LAN play. The big difference between LAN and
for instance a modem connection to the internet is the amount of data that you can transfer per second obviously. On a 33.6 baud modem
connection you can transfer a maximum of 40 position updates per second. In a LAN connection, F4 would send over 1000 updates per second.
In the old code the host's job was to check all the vehicles in the sim for movement and send updates to the clients about the most
important changes in the F4 world.
The host realized that it didn't have the bandwidth to send all the necessary updates to keep the world absolutely true, so it picked
the most important ones.
What it failed to realize though (in the old code), was that not all objects are as important to all players. For instance, one player
who's dogfighting with an Su-27 would need a lot of updates on that object, but another player 200nm away from that fight would not
really care about it, so he would just need a few updates on that Su-27 object.
The old code also didn't realize that if someone was close to an object, everyone would get lots of updates on that object.
The result was that some players were bombarded with position updates on objects which were hundred of miles away while only a few
getting a few on the Mig-29 10nm ahead of them. This results in what we all know as warps.
The new code realizes that not all objects are as important for all players and will send specific updates to specific players about
the objects which are of importance to them. It will not waste bandwidth on updates on objects which are of no importance (as the old
code did). This will reduce the lag very much especially when more players are in the game.
In the old code the host would not take care of sending position updates on the other players in the sim. They would have to take care
of this themselves. This meant that if we, for instance, have a game with 6 players, one client would have to send updates about his
own position to all the other 5 players in the sim. Let's see how much bandwidth he would use just for sending:
With pf 100 you would send an update 10 times a sec. 5 players * 10 = 50 updates per sec! Well, with a 33.6 conection you only have 40
available. So trying to send 50 would make you CTD and/or definitely not give you much bandwidth to receive updates from the host and
other players. As the example illustrates, this method eat up a lot of bandwidth and basicly a modem guy would use all his bandwidth
just to send his updates to the others and would have no bandwidth left to receive.
What does the new code do?
In the new code, a client only sends to the host and therefore does not care how many players that are conected to the game. It also
doesn't waste valuable bandwidth which could have been used for receiving updates.
Works as a true host/client making huge sessions possible with many players online even with low bandwidth connections.
The new code also makes sure that noone is flooded with position updates. This means that you do not have to set your bandwidth to 33.6
if your real bandwidth is higher. It will greatly increase stability and reduce CTDs. The host with a high bandwidth connection will be
able to provide games with very little lag to many players.
Code that picks the most interesting objects and differentiates between which objects are interesting to which players.
The new code will adjust the position update tolerance continuously and adjusts according to the action in the game.
So is this all good?
No, not quite. Since position updates now have to travel through the host and not directly from client to client the data will have a
further distance to travel (unless the routing is better THRU the host - it kind of varies on routing). This means that it will possibly
be delayed a little more than with the other system. F4 does not take latency into account (yet) so this might be noticeable. (This is why
other players look like they are a little behind when compared to where they are on their own screen.)
The code is still under developement and currently it will assume that all clients are connected with a 33.6 bandwidth conection, so you
will not get more updates even though you have more bandwith available for real. This is only true for the clients! The host will use all
the bandwidth he's got available.
In future updates, the host will constantly check how the network conditions are and will adjust the throughput accordingly.
/Mirv
|
|
|
|
|
|
|
| Pictures |
(Opens in a new window.)
|
| |
Copyright © 2001
eFalcon Team |
|
