this makes for some really interesting reading!!!
Yes, it is a quite interesting challenge
- How will you ensure if (for example) you have HD-Folders in the setup, that you have the same files on each side? Run a check on startup, or check files exist as-you-play and then abort if something is missing on one side?
Currently, this is not checked. I would call what I have now a (fully working!) prototype. A final version could either:
- assume that everyone has the same files (all persons could for instance unzip the same zip file)
- the client could create a checksum of the entire content before starting, an refuse starting if the content differs
- the client could in theory synchronize the contents (much more work, but simple to do).
- How will you determine which side has control of which joysticks/keyboard inputs? will one side have control of certain inputs, and "allow/block" the other side to determine the remaining? Or will you just leave it to the people setting up the configs to arrange it in a fair manner?
Currently all input events can originate from any client, and will propagate to all clients. That is, everyone can press keyboard keys and and joysticks/mouse should be handled by one player using joystick_port_0 and the other joystick_port_1. It would not be very difficult to later configure the server/game with rules concerning who gets to send which types of input. One could in theory give on player control of a specific set of keyboard keys and another player could control the rest. As I said, this is definitively not rocket-science, but I will not do this for the prototype.
(For now, it works just fine if all players agree on who controls what).
- I noticed you mentioned a 25ms ping via the server method - these seems pretty good to me from previous experience with winuae-kaillera, but will you be adding a P2P method as well?
P2P will add much more complexity without any real gain. One cannot compare "UAE netplay" to another game designed for multiplayer.
Games designed with multiplayer in mind can broadcast UDP events without guaranteed delivery, and the game can implement logic to constantly keep the game state in sync (e.g. in a FPS, all clients need not get every movement commands, since movement can be predicted based on current speed, and position can be exactly updated when a later game event arrives). The point here is that the game itself can allow missing events, or events arriving out of order, as long as it handles this in some sensible way.
This won't work with the Amiga - if two key presses are applied in the opposite order on two clients, the emulation will get out of sync! This means that someone must order the events - this is done by the server. P2P will just make it more difficult to synchronize, and you will not get the benefits from P2P that other applications can get (Events can be ordered in a distributed manner, but this is much more complex, and probably much slower). The IP traffic required to sync games is actually quite modest - the most demanding cases are mouse event propagation. Low latency is more important than bandwidth.
Regarding the ping. Yes, I tested with two clients locally which both played through a server about 12.5 ms away. In this case, you will get a minimum delay (lag) of 25 ms for input, but in practice more, since the input events also are synchronized to frame events.
I do *not* recommend using wireless network. I tested with one client on wireless, and got more jittering (it still worked properly, and not *BAD*, but significantly less smooth). The problem with wireless is packet loss. Since the synchronization protocol cannot work with missed events, or events out of order, guaranteed delivery is required (fs-uae uses TCP for this). This means that packets *must* be resent when a packet loss is detected, and if a frame confirmation event is significantly delayed (the server allows some slack), this will delay the game for all clients. When testing with ping, I saw that the computer on wireless got rounds trips to the server of either 25 ms (good), but relatively often 50 ms.
Ideal conditions for netplay:
* a server with relatively low latency connections to clients. It would be most fair for all players if everyone's latency is comparable.
* low packed loss rate (avoid wireless if possible and do not saturate the link with downloads / P2P traffic while playing).
Very excited about this. Just going to try making some auto-scripting of config files here....
The upcoming version supports overriding the memory settings (probably needed if in many cases you auto-write configs from another configuration database).
Author
Topic: EMU: New UAE Variant Released - "fs-uae" (Read 28406 times)