Ideas for allowing partial speed control online

[hrydgard]

FoxLovesYou on Discord reports that in the Phantasy Star Online community, it's common to allow using fast-forward in certain situations, as the game is quite tolerant to it. Pasting discussion below.

Would there be a convenient way of allowing a host to control the speed controls of a game during multiplayer? Phantasy Star has some rare issues with them during certain load screens, but a large portion of missions are long walks in real time that significantly benefit from one's ability to speed the emulator up to get through them. Creature behavior is controlled client-side, and only when in range of said creatures. If the speed control lock is to be enforced starting in 1.19, I may have to recommend that users who still want the feature stay on 1.18.

I recognize that not all games are as adaptive as Phantasy Star, which is why I would recommend the host have control over it's use for the session

I'm not a fan of per-game whitelisting, but it would probably be fine. The game implements player positions and other non-essential data over UDP, which allows for losses without rubber banding. Monsters AI is handled client-side, so you're more or less just sharing their HP pools when playing. Traps can be problematic, as they shoot faster when someone speeds the game up. Time limited missions don't trigger until one person reaches the limit, so it's fine as long as it's not abused in idle. Rewards aren't usually tied to time, but when they are, it usually takes the longest time for any given players. Most parties use a karma system. Use at your own discretion, and sparingly whenever necessary. Some parties prefer it authentic, with no speed controls at all. PvP matches aren't common, or particularly rewarding.

You have a socket communicating for chat and various other features, yes? Would it be viable to set a voting system of sorts? If a single member of the party has "Speed Controls in Multiplayer" disabled, all members are restricted? This would be a much better system for all games.

That method would allow less common games to implement their own rule sets for how speed controls are allowed. I can always just recommend the downgrade for users who want to continue using it. I think it would be too complicated to enforce a speed control lock during load screens

List of games where this might be relevant:

ULJM-91014 - PSP - JP Demo?
ULAS-42138 - PSP - ??
ULJM-05309 - PSP - JP Disc
ULJM-08023 - PSP - Best Edition?
ULUS-10410 - PSP - US Digital
ULES-01218 - PSP - EU Digital
NPJH-90062 - PSP2 - Digital Demo
ULJM-05493 - PSP2 - JP Disc
NPJH-50043 - PSP2 - JP Digital
ULJM-08030 - PSP2 - Best Edition?
ULUS-10529 - PSP2 - US Digital
ULES-01439 - PSP2 - EU Digital
ULJM-05732 - PSP2i - JP Disc
NPJH-50332 - PSP2i - JP Digital -- Most commonly used for emulation
HSN-0019 - PSP2i - Premium Box Edition (Disc)

[Komak57]

As many games perform most of the networking exclusively through the adhoc server, perhaps a server-specific variable and communication would be more viable. If the server admin decides they don't want it to be functional, they would be able to disable it for all clients on their servers. For games like PSP2i, one of the wiki admins hosts an adhoc server we can use for more leniency on speed controls during multiplayer.

[anr2me]

Changing the adhoc server will breaks compatbility with real PSP, since they only know legacy PRO-online (like most public adhoc servers out there)

I was thinking of a ping-measuring idea long ago (which can be done in adhoc/P2P with UDP/ICMP protocol, but some firewall/router might blocked ICMP packets, thus UDP should be safer), so all players can see their latency to other players and see the packet loss rate to identify a problematic players (this will also detects whether a player have blocked port or not, which is most of the case when having an issue playing adhoc over the internet).

This way we can use the ping packets (which are sent every 100~500ms, some games might have short timeouts but we don't want to flood either) as control packet, for example to synchronize whether one player is pausing the emulator (ie. going to PPSSPP's setting) which could cause them to disconnects in-game, unless everyone are pausing their emulator too, and other synchronization purpose like speed control, etc. (will also be possible to save state multiplayer sessions if we save the sockets state on all players at the same time and restore them later, but a bit complex).

And because it's a separated statistical feature unrelated to the game, it won't impacts compatibility with other emulators/real PSP, we will only see them as "having blocked port" since they don't have the port for the ping-measurement opened, even if they have the port open for some reason, but unable to reply the expected reply packet and got timedout it will only be considered as packet loss, where players can ignore this "warnings" if they know that player is using an old/different emulator or real PSP.

The packet's format can be something like this:
[sequential/nonce number][data] - expecting to receive the same number (16/32-bit) to be replied to calculate the latency, also as an ACK to tell that the specific packet have been received, if it's not the expected number it could be a new packet sent by other player which we should reply to.

Data can be:
[type][optional data]
[00] - just a regular ping packet
[01][version] - in case we want to add more feature in the future, so we only send packet's format supported by the version used by the other side.
[02][emulation-state] - to sync pausing/resuming emulation on all players (state can be boolean)
[03][emulation-speed] - to sync emulation speed on all players (the speed can be integer/float)

Reply data type can have the MSB set (ie. 0x02 -> 0x82), so we can differentiate between a reply data or a new packet.
We can also swapped the position of the data type with the nonce if it's easier to handle that way, since the data type is only 1 byte.

Edit: We can also use a separate line (ie. TCP) for the synchronization command, to ensure it's successfully delivered without the need to implement our own ACK.

PS: On the UI we can shows packet loss rate, and current latency number, (also optionally the graph of latency for historical view to see whether the player have unstable latency) beside each player's name (with different color for each player's name)

[Komak57]

I personally have ICMP blocked on my router, as I host services, and have found quite the number of spider bots pegging the system so long as the service appears available. Pinging from the server doesn't always provide a reliable indication of the latency of the connection, as the routes may differ SERVER->CLIENT and CLIENT->SERVER.

It looks like you want to try a route that wouldn't require a dedicated server. This would require the use of an existing connection that can accept packets outside of existing infrastructure without breaking the server/host. If it's designed well, a server should be able to handle when an unrecognized packet request is made.

I need to do more research into how ADHOC servers operate before I can validate adding a service to such servers for this communication, in case it can handle a socket connection for traffic other than ADHOC multiplayer. This could mean no additional settings would need to be implemented, and PPSSPP would check the new port for the communication of simplistic features like synchronizing, enabling, or disabling settings as a service. If the ADHOC server isn't updated to handle the new service, PPSSPP would disregard the settings channel, so ideal compatibility.

Those are some overly simplified packets, which wouldn't handle scaled changes to the system, but would work for prototyping. Would need to further document all of the traffic that would be intended short term, and long term, and work with as few packets as possible to reduce unnecessary loads. UDP is a poor choice for this, as these settings MUST to be handled. TCP has some minor delays which could make it tricky for synchronization on things like save states and pausing.

Speed controls, however, are a setting that the entire community playing would decide on. Having these at a pre-existing configurable location would be ideal. Some games would NOT play well with speed controls. Competitive titles especially. Those communities would no doubt want to disable speed controls for all players. Many PSP2i players have no quarrel with locking speed controls in multiplayer to play "authentically". I'm playing with a very regular group, and we very much enjoy using speed control to reduce an 8 hour session into 5-6 hours of real time, cycling through an inventory of up to 2000 items, or upgrading a weapon that takes a mandatory 5 second timer per upgraded 12 times in a row before we can use it in the next mission.