ace project writes:
> In my previous mail ("Multplayer efforts ?") We asked
> for the status on multiplayer-capabilities. We
> received responses that suggested that such an engine
> was not maintained for a while.
>
> We ourselves could use the engine for adding NPC to
> the project, but thats still a far goal.
>
> My friend and I got permission from our school to
> build such an engine as a school project. We got 100
> dedicated work days to make this happen, so wish us
> luck !
>
> Our part of the engine will be handling the
> network-traffic and status of the connection. Easy to
> use hooks to draw the plaines in the game should be
> developed by the core team, if they don't exist yet.
> If there are such hooks, plz mail them, so that we can
> tweak data-packets to them.
>
> Today we started brainstorming about what data would
> be interresting for multiplayer. As soon as this is
> finished I'll post the result for request for comment.
>
> The first prototype to be capable of hooking into the
> game should be ready within 2 months. This will be a
> kind of software "switch", wherein the clients to the
> heavy work of collision detection and such.
>
> Test-releases to test network performance and
> incompatibilities should be out by next month.
>
> Comments are highly appriciated,
Ok, here are some various thoughts ...
I agree you want to generally use UDP. I'd strongly suggest you build
everything with the plib net libraries since that makes all the
socket/net platform portability issues go away (plus as Norman
mentioned, it is patterned after a proven design.)
Even if you have a UDP "data" channel, you might also want to consider
a TCP channel for 'command' type messages ... things that the server
might only want to send once. For one application here I did this and
used an embedded http server as the command channel. That preserves
a 'connectionless' design where either side can shut down and start up
without hosing the other side.
People have talked about HAL/DIS implimentations before, but nothing
has ever been done with that. As I understand it, one thing that DIS
does to conserve bandwidth is both sides (client/server) use the same
fprediction algorithm. That way the server can know where the clients
have extrapolated the other aircraft to be. When this diverges enough
from the real position, the server can send new information.
If you are talking about building a system that can function over a
56kb modem connection, then I really doubt you will need to seriously
consider threaded vs. multiplexed performance issues. Even if this
does eventually become an issue, I'd strongly suggest starting out
with a simpler multiplexed implimentation, and some day when we have
thousands of people served off the same server, we could take the time
then to sit down and write a multi-threaded implimentation that runs
on some huge super computer with huge pipes.
Regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
