QUIC and MoQ from the Perspective of Real-Time Game Networking

These are the presentation materials for the talk
"QUIC and MoQ from the Perspective of Real-Time Game Networking"
delivered at MoQ Meetup Japan (https://moqmeetup.connpass.com/event/406585/).

*To watch the video of the presentation, please visit https://www.youtube.com/watch?v=yUneU7UzI8Y

Transcript

1. QUIC and MoQ from the Perspective of Real-Time Game Networking Ryo Takehara, SEGA CORPORATION
2. Professional activities Previous talks  CEDEC 2025: “QUIC Adoption for Real-Time Communication in Games: Case Studies”  CEDEC 2023: “Automating and Visualizing Sound QA with the CRI ADX Profiler”  CEDEC 2021: “Dramatically Reducing Download Times: Fast Implementations and Operational Practices for Large Asset Volumes”  CEDEC 2021: “Making Automated Testing on Android and iOS Devices Easier and More Useful: Practical Know-How on Device Management, Image Transfer, Video Recording, and Related Tools”  Unite Tokyo 2019: “Handling Large Asset Volumes: A Fast Communication Implementation Using HTTP/2”  CEDEC 2018, CEDEC 2016, and CEDEC 2015: Production-related roundtables  GDC 2016 report session: “Automation and Testing Trends at GDC 16”
3. Personal activities Previous talks  CEDEC 2025: “A Roundtable Exploring the Best Real-Time Communication Protocol Choices for the Game Industry 2025”  CEDEC 2023: “A Roundtable Exploring the Best Real-Time Communication Protocol Choices for the Game Industry”  CEDEC 2020: “Become a Technical Doujinshi Author: An Example of How Engineers Can Develop Their Skills in the Era of Work-Style Reform” Books (self-published technical books)  QUIC: HTTP/3 Edition (2019)  QUIC : DATAGRAM Edition (2020)  QUIC : HTTP/3 Edition, Updated for the RFC (2022) Community organizer  Game Real-Time Communication Protocol community
4. Agenda  Diverse communication requirements in games  Application techniques for real-time game communication  QUIC use cases in games  Connections between MoQ and games, and the community's work
5. Diverse communication requirements in games
6. Diverse Communication Requirements in Games 1. Different types of communication coexist within a single game. 2. Requirements differ greatly across genres. 3. Games must work as fairly as possible in real-world environments worldwide. 4. A wide variety of client platforms must be supported.
7. Different Types of Communication Coexist Within a Single Game Gameplay synchronization, chat, and spectating or streaming coexist within a single game. Even within the same game, what needs to be delivered, by when, and how can differ.
8. Requirements for Handling Data ※These are only rough examples. Actual handling depends on the game. ※“Deadline” means a time after which the data cannot be used at its intended time, such as an audio playback time.
9. Communication Requirements Depend on Gameplay and Game Design ※ These are only rough examples. Actual handling depends on the game.
10. Games Must Work as Fairly as Possible in Real-World Environments Worldwide  Players join from home connections and wireless networks around the world.   If network delay makes them notice an opponent's action later, they have less time to react. The design should be as fair as possible, minimizing differences in competitive outcomes and experience caused by latency or jitter.  Even when prediction and correction reduce the effects of latency, their impact on other players must be considered, which makes this difficult.
11. A Wide Variety of Client Platforms Must Be Supported Consider releasing the same game on PCs, smartphones, and consoles, with players able to play together across platforms.  Development environments and restrictions on available libraries differ by platform.  Even if a suitable open-source library exists, porting, game-engine integration, testing on actual devices, and ongoing maintenance are still necessary.  On closed platforms, public information alone may not be enough to decide whether a library can be adopted. Adoption depends on both the protocol's capabilities and whether it can be implemented, tested, and maintained on every supported platform.
12. Application techniques for realtime game communication
13. Apply Your Own Input Immediately  After a button press, immediately apply the input to the character locally.  At the same time, send the input to the server, which also processes the movement.  If the results differ, correct the local result to match the server's result.
14. Delay Other Players' Movement Slightly and Interpolate Positions  Buffer position data from the recent past.  Receive the other player's latest position data.  Interpolate between positions to display smooth movement. ※ A longer wait makes jitter easier to absorb, but also makes the other player's movement appear later.
15. Predict Ahead, Then Roll Back If the Prediction Was Wrong  Predict the opponent's inputs that have not yet arrived.  Advance the game using the predicted inputs.  If the actual inputs differ from the prediction, roll back to a previous state and recompute. Prediction Standing Attack hit Now The actual input arrived and differed from the prediction, so the process was reverted to the previous state. Real Squat Attack misses Now
16. Include Inputs in Later Transmissions So Lost Inputs Can Be Recovered Include recent past inputs with the latest input to recover inputs missing due to packet loss. Data from two entries ago 120,50,10 110,50,10 100,50,10 Previous data (packet loss) 130,50,10 120,50,10 110,50,10 This data 140,50,10 130,50,10 120,50,10 Lost data can be interpolated.
17. Select and Send the Information That Is Needed 1. Reduce update frequency or the amount of information for players with little impact on gameplay.  2. For example, players who are far away or hidden behind obstacles. Increase communication frequency as their impact grows, such as when they move closer. Other Player 1 myself Since we're close, we'll send data at 0.1-second intervals! Since it's far away (and therefore the impact is small), a 1second interval is sufficient. Other Player 2
18. QUIC use cases in games
19. QUIC Use Cases in Games The following two cases are excerpts from the CEDEC 2025 presentation, “QUIC Adoption for Real-Time Communication in Games: Case Studies.” For more detail, see the https://speakerdeck.com/segadevtech/cedec-2025-gemuniokeruriarutaimutongxin-heno-quicdao-ru-shi-li-noshao-jie It includes detailed measurements from actual operation, making it a particularly valuable resource.
20. SONIC RUMBLE Overview of QUIC Adoption    Adopted QUIC in Nemofiller, a new in-house real-time networking library.  Wanted to avoid implementing RUDP ourselves.  No C# QUIC implementation was available; supporting each platform still required substantial effort. Used different QUIC facilities for different messages.  QUIC streams: `RELIABLE-MSG`, requiring delivery and ordering guarantees.  QUIC DATAGRAM: `UNRELIABLE-MSG`, without retransmission. Fall back to TCP when a QUIC connection cannot be established.  The average TCP fallback rate was 0.014%.
21. SONIC RUMBLE Did QUIC Work as a Protocol for Real-Time Game Communication? The following were observed with many connected players and frequent communication:  Relatively stable RTT values, despite some variation.  RTT values that did not differ greatly from theoretical values.  RTT values that varied with the distance to the peer. QUIC proved viable as a protocol for real-time communication in this case.
22. SONIC RUMBLE Operational Issues with QUIC DATAGRAM  A certain proportion of connections were judged to be disconnected.      For affected users, retransmissions and jitter preceded the disconnection detection. Suspected cause:  The implementation sent many messages inefficiently.  Packet counts were high relative to the amount of data; packet drops at devices along the network path were suspected. Countermeasures:  Combined in-game messages wherever possible.  Temporarily switched to UDP because of concerns about the effect of QUIC DATAGRAM ACKs. Results:  Fewer connections were judged to be disconnected.  Further message batching, without changing how the game felt, reduced the count further. Remaining requirement:  A mechanism to control whether and how frequently QUIC DATAGRAM traffic is acknowledged.  Personally, I am looking forward to ack-frequency.
23. Sphingo Background to Introducing Connection Migration  Sphingo is an in-house real-time networking library.   It has handled RELIABLE and UNRELIABLE communication through a custom SCTPbased protocol implemented over TCP and UDP. QUIC was added to the protocols supported by Sphingo.  An existing title needed communication to recover automatically when the client's network connection changed.  QUIC was added to reduce the effort of maintaining a custom protocol and provide a standard protocol as an option.
24. Sphingo Current State of Connection Migration     QUIC is designed to accommodate changes in the network path.  The practical details of the implementation are therefore important.  Implementation proved fairly difficult, even though this was anticipated. Implementation considerations:  OS networking stacks such as Winsock and NDIS can absorb changes internally, making IP address changes difficult for applications to detect.  A connection may continue despite an IP address or port change, without an explicit callback. Testing considerations:  NAT and the timing of a switch affect behavior; virtual environments alone cannot provide complete verification.  Implementation requirements vary by client environment, leading to a large number of test combinations. Conclusions:  Even with a standard specification, platform support, server support, and testing in real-world environments remain necessary.  Having a connection migration specification is valuable in itself.
25. Connections between MoQ and games, and the community's work
26. How MoQ Fits Game Use Cases ※ These are examples of mapping MoQ's model to game requirements, rather than concrete cases of MoQ adoption for real-time gameplay communication.
27. The Game Real-Time Communication Protocol Community  Purpose   Exchange information about protocols used for real-time communication in the game industry and improve the quality of real-time communication across the industry. Initial approach 1. Collect cases of QUIC adoption for real-time game communication. 2. In parallel, identify the elements needed for real-time game communication. 3. Evaluate the QUIC adoption cases against those elements. 4. If QUIC falls short, consider a protocol for games. Meeting minutes, etc. → TakeharaR/game-realtime-protocol
28. The Community's Current Direction   What we learned as the work progressed  There are few publicly documented QUIC adoption cases, so collecting enough material for comparison has been difficult.  We organized the necessary elements of real-time game communication in terms of specifications, implementations, and environments. However, a comprehensive list becomes large and is difficult to apply to an individual game's requirements. Current direction  Rather than seeking one real-time communication protocol for games, derive requirements, trade-offs, evaluation metrics, and test conditions from use cases.  Consider extensions to standard protocols or protocols for games when necessary.
29. Summary  Real-time communication requirements vary by use case, and games have a particularly wide range of requirements.  Inputs, state synchronization, events, and spectating coexist within the same game, with different communication properties.  Requirements also change greatly with game design.  Protocol evaluation needs to consider performance, effects on the game experience, and implementation and maintenance costs.  For QUIC and MoQ, the important question is which communications within a game they fit, rather than whether they can be used for games in general.