If you build your game around these myths, then your development progress will slow as you focus on increasingly complex and fragile netcode. Players will become frustrated when the game\u2019s netcode doesn\u2019t mesh with their gameplay expectations. And you\u2019ll be disappointed when your investment in myths doesn\u2019t pay off with your players\u2019 enjoyment.<\/p>\n\n\n\n
You need a way to reason about netcode, instead of blindly believing in myths.<\/p>\n\n\n\n
Network dreams<\/a><\/h2>\n\n\n\nIn an ideal world, you wouldn\u2019t have to think about TCP or UDP at all. On a perfect network, every packet sent would be received. There would be no reason to ever confirm receipt of a message. You could trust <\/em>that the network delivered your message anywhere on Earth, in order and in less than about 70ms. Lag and packet loss? Unheard of.<\/p>\n\n\n\nThe bad news is that we don\u2019t live in a perfect world with perfect networks. Network conditions vary and protocols serve different needs. Should you choose TCP or UDP? It\u2019s impossible to say. There\u2019s no optimal choice when it comes to your transport layer.<\/p>\n\n\n\n
But there\u2019s good news: there\u2019s no optimal choice when it comes to your transport layer. TCP and UDP can satisfy different needs, often within the same game. We don\u2019t have to choose one true protocol. Instead, we can write netcode in concert with game design, minimizing the significance of protocols entirely.<\/p>\n\n\n\n
Netcode and game design are intertwined<\/a><\/h2>\n\n\n\nWhen you think about the relationship between your game\u2019s design and netcode, you\u2019re often thinking in terms of interactivity. What happens when a player makes a decision and acts on that decision? Does the game respond to the player and how does it feel?<\/p>\n\n\n\n
Netcode and the network itself are part of that interaction loop. In a first-person shooter, slow messages might give a sluggish or jerky feel to movement. But in a deck-building game, slow messages might heighten the drama and anticipation of the player\u2019s next move.<\/p>\n\n\n\n
Of course, few game designs fit neatly into “fast” or \u201cslow\u201d interactivity. Most games have a mix of more or less interactive gameplay elements, each with different networking requirements. A deck-builder might have real-time voice chat in addition to turn-based mechanics. A first-person shooter might have discrete, punctuating events, such as matchmaking or consuming an inventory item, alongside a fast, continuous simulation.<\/p>\n\n\n\n
Some messages are mandatory (and some aren\u2019t)<\/a><\/h2>\n\n\n\nIf your game has more than one mode of interaction, then it doesn\u2019t make sense that your game would have just one way of sending messages over the network. The content of the messages\u2014the type of gameplay that the messages support\u2014can give us a way to reason about how to use the transport layer.<\/p>\n\n\n\n
Any one message, depending on its contents, might have more or less impact on your player. If a single frame of voice chat audio is dropped, then it\u2019s unlikely that your player will notice the loss. Some messages, if lost, may be highly aggravating: a lost store purchase confirmation may lead a player to an unwanted repeat purchase. Other messages may fall in-between these extremes: the movement of a projectile might be highly consequential or nearly irrelevant, depending on whether it\u2019s traveling near the player.<\/p>\n\n\n\n![\"Gradient](\"https:\/\/web.archive.org\/web\/20210415231950im_\/https:\/\/heroiclabs.com\/docs\/images\/nakama-tcp-or-udp.png\" "\\"Gradient")
<\/figure>\n\n\n\nIf some messages must <\/em>be received while others are merely nice to have, then the game\u2019s networking code must support a gradient of reliability.<\/p>\n\n\n\nReliability is a gradient<\/a><\/h2>\n\n\n\nTransport layer protocols partly map to the gradient by setting distinct expectations for message delivery.<\/p>\n\n\n\n
UDP offers few reliability guarantees. It\u2019s a more trusting protocol that expects that a message will be delivered. If it\u2019s not delivered, the protocol won\u2019t hear or do anything about it. It also doesn\u2019t make any assumptions about when the message is delivered. UDP makes no effort to ensure the order of delivery. The first message you sent may not be the first received. When it comes to reliability, UDP is relaxed.<\/p>\n\n\n\n
TCP offers robust reliability guarantees. It goes to some effort to confirm that a connection between the sender and recipient is established, that the recipient is prepared to receive messages, and, after the messages are sent, that they are delivered completely and in order. When it comes to reliability, TCP is a strict micromanager.<\/p>\n\n\n\n![\"UDP](\"https:\/\/web.archive.org\/web\/20210415231950im_\/https:\/\/heroiclabs.com\/docs\/images\/nakama-tcp-vs-udp.png\" "\\"UDP")
<\/figure>\n\n\n\nA Tale of Four Messages<\/a><\/h3>\n\n\n\nUnder good network conditions, it\u2019s actually quite hard to tell UDP and TCP apart in terms of reliability. But if conditions are poor, it\u2019s easier to see how reliability tradeoffs emerge. To illustrate, suppose your game needs to send four messages sequentially (but let\u2019s ignore their contents and importance, for now).<\/p>\n\n\n\n
In good conditions, messages arrive intact, promptly, in-order, and just once. In poorer conditions, none of these assumptions hold. How do the different protocols cope?<\/p>\n\n\n\n
With UDP, send the four messages, M1, M2, M3, and M4, each one after the other. What happens to each?<\/p>\n\n\n\n![\"Visualization](\"https:\/\/web.archive.org\/web\/20210415231950im_\/https:\/\/heroiclabs.com\/docs\/images\/nakama-udp.png\" "\\"Visualization")
<\/figure>\n\n\n\n- M1 gets lost along the way. It never arrives.<\/li>
- M2 eventually arrives, but the routing is so convoluted, it\u2019s last to arrive.<\/li>
- M3 arrives first!<\/li>
- M4 arrives, but a router along the way spontaneously duplicated the message in transit, so it arrives twice<\/em>, once in second place and once in third.<\/li><\/ul>\n\n\n\n
As far as UDP is concerned, this is how it\u2019s supposed to happen. It\u2019s “best effort” but at least it\u2019s low overhead. The protocol doesn\u2019t require the receiver to notify the sender of any problems. If anything is to be done about this network hiccup\u2014to make sense of out-of-order delivery, repeated delivery, or the lost message the receiver didn\u2019t even know about\u2014it has to be done at the application layer, in your game.<\/p>\n\n\n\n
Let\u2019s rewind things and play this scenario out again over TCP. TCP is a more complex protocol and we\u2019ll have to tell a more complex story. But let\u2019s send those messages again, assuming that we\u2019ve already completed the three-way handshake and we\u2019re in the ESTABLISHED state. What happens to each?<\/p>\n\n\n\n![\"Visualization](\"https:\/\/web.archive.org\/web\/20210415231950im_\/https:\/\/heroiclabs.com\/docs\/images\/nakama-tcp.png\" "\\"Visualization")
<\/figure>\n\n\n\n- M1 gets lost along the way. Eventually resent (more on this later), it arrives last.<\/li>
- M2 eventually arrives, but the routing is so convoluted, it arrives after M3 and M4.<\/li>
- M3 arrives first!<\/li>
- M4 arrives, but a router along the way spontaneously duplicated the message in transit, so it arrives twice<\/em>, in second and <\/em>third place. TCP is clever though and knows to discard the duplicate M4.<\/li><\/ul>\n\n\n\n
TCP wants to protect you from this wrong and incomplete order, however. As M2, M3, and M4 arrive, TCP holds those messages until M1 arrives (this is known as head of line blocking<\/em>). While M1 is lost, TCP waits for a while to acknowledge what it has received (delayed ACK) and then waits some more while M1 is resent. Eventually, all four messages are received and TCP hands off the data to your application.<\/p>\n\n\n\nAs far as TCP is concerned, this is how it\u2019s supposed to happen. It\u2019s more reliable, but has noticeably more overhead in the form of round-trip exchanges. There are adjustments that can be made to minimize some of the more problematic features (such as turning off delayed ACK), but to get the guarantees of TCP, your application must necessarily submit to these constraints.<\/p>\n\n\n\n
Unfortunately, the protocols themselves only represent two points on the reliability gradient. TCP doesn\u2019t have a reduced guarantees mode and UDP doesn\u2019t have an opt-in for more reliability. If our only choices involved choosing TCP or UDP, we\u2019d face a hard decision between the risks of UDP\u2019s best effort and the restrictions of TCP. Luckily, your game has a say in the reliability story, too.<\/p>\n\n\n\n
Optionally reliable<\/a><\/h2>\n\n\n\nYour game, as a networked application, can choose how to use the network.<\/p>\n\n\n\n
In general, your game is not fixed to a single protocol: you can use UDP when you don\u2019t require the reliability guarantees of TCP and you can switch to TCP when you do. Under good network conditions (low latency and packet loss), this won\u2019t matter much. But if things get shaky, then you\u2019ll avoid some misadventures associated with lost messages.<\/p>\n\n\n\n
For points on the gradient between optional and required, there\u2019s a strategy called optionally reliable UDP<\/em>. This is when you build additional guarantees in your application, rather than relying on the protocol. In outline, this is sending UDP packets that require some response from the recipient; the message is re-sent until the expected response is received.<\/p>\n\n\n\nBut whether you choose UDP or TCP or optionally reliable UDP comes down to the content<\/em> of your messages and what they mean to your game and players.<\/p>\n\n\n\nStart with your payloads<\/a><\/h2>\n\n\n\nThe content of your messages matters more than the vehicle they travel in. Start by focusing on your payloads, then figure out how to get them there.<\/p>\n\n\n\n
Before you start sending messages, make sure you know what you need to send over the wire<\/strong> (and what you don\u2019t). For example, in an action game, your player\u2019s movements will probably be sent to the server many times per second, while your player\u2019s inventory status only needs to be sent when it changes. Smaller data structures are less likely to pay fragmentation penalties. The fastest packet is the one you never send.<\/p>\n\n\n\nKnow your player\u2019s context<\/strong>. Your netcode should reflect when and how your player is interacting with the game. This starts with the player\u2019s physical environment, such as playing on a desktop computer with a high-quality wired connection versus playing from a mobile device on a spotty mobile network. It also includes the game context; the game state may make certain kinds of messages more likely than others.<\/p>\n\n\n\nKnow what messages, if lost, would annoy the player<\/strong> (or worse), what they\u2019d never notice, and what\u2019s in between. Each message\u2019s place on the reliability gradient is key. If you know that prediction, interpolation, or other strategies can gracefully hide the occasional lost message, then that gives you more options for sending that message.<\/p>\n\n\n\nStand on shoulders of giants<\/a><\/h2>\n\n\n\nIf you\u2019re thinking that this only begins to dig into thinking about net code, then you\u2019re right. As you build out your games netcode, you\u2019ll need to learn more about different aspects of prediction, interpolation, serialization, and beyond.<\/p>\n\n\n\n
Read Ruoyu Sun\u2019s Game Networking Demystified<\/em><\/a>, which takes a closer look at game states and client inputs and how they relate to cheating, server authority, and game genre.<\/p>\n\n\n\nAnother great read is Peeking into VALORANT’s Netcode<\/a><\/em> from Riot Games, which goes in-depth on how product design goals can lead to specific decisions in netcode design.<\/p>\n\n\n\n
The bad news is that we don\u2019t live in a perfect world with perfect networks. Network conditions vary and protocols serve different needs. Should you choose TCP or UDP? It\u2019s impossible to say. There\u2019s no optimal choice when it comes to your transport layer.<\/p>\n\n\n\n
But there\u2019s good news: there\u2019s no optimal choice when it comes to your transport layer. TCP and UDP can satisfy different needs, often within the same game. We don\u2019t have to choose one true protocol. Instead, we can write netcode in concert with game design, minimizing the significance of protocols entirely.<\/p>\n\n\n\n
Netcode and game design are intertwined<\/a><\/h2>\n\n\n\nWhen you think about the relationship between your game\u2019s design and netcode, you\u2019re often thinking in terms of interactivity. What happens when a player makes a decision and acts on that decision? Does the game respond to the player and how does it feel?<\/p>\n\n\n\n
Netcode and the network itself are part of that interaction loop. In a first-person shooter, slow messages might give a sluggish or jerky feel to movement. But in a deck-building game, slow messages might heighten the drama and anticipation of the player\u2019s next move.<\/p>\n\n\n\n
Of course, few game designs fit neatly into “fast” or \u201cslow\u201d interactivity. Most games have a mix of more or less interactive gameplay elements, each with different networking requirements. A deck-builder might have real-time voice chat in addition to turn-based mechanics. A first-person shooter might have discrete, punctuating events, such as matchmaking or consuming an inventory item, alongside a fast, continuous simulation.<\/p>\n\n\n\n
Some messages are mandatory (and some aren\u2019t)<\/a><\/h2>\n\n\n\nIf your game has more than one mode of interaction, then it doesn\u2019t make sense that your game would have just one way of sending messages over the network. The content of the messages\u2014the type of gameplay that the messages support\u2014can give us a way to reason about how to use the transport layer.<\/p>\n\n\n\n
Any one message, depending on its contents, might have more or less impact on your player. If a single frame of voice chat audio is dropped, then it\u2019s unlikely that your player will notice the loss. Some messages, if lost, may be highly aggravating: a lost store purchase confirmation may lead a player to an unwanted repeat purchase. Other messages may fall in-between these extremes: the movement of a projectile might be highly consequential or nearly irrelevant, depending on whether it\u2019s traveling near the player.<\/p>\n\n\n\n<\/figure>\n\n\n\nIf some messages must <\/em>be received while others are merely nice to have, then the game\u2019s networking code must support a gradient of reliability.<\/p>\n\n\n\nReliability is a gradient<\/a><\/h2>\n\n\n\nTransport layer protocols partly map to the gradient by setting distinct expectations for message delivery.<\/p>\n\n\n\n
UDP offers few reliability guarantees. It\u2019s a more trusting protocol that expects that a message will be delivered. If it\u2019s not delivered, the protocol won\u2019t hear or do anything about it. It also doesn\u2019t make any assumptions about when the message is delivered. UDP makes no effort to ensure the order of delivery. The first message you sent may not be the first received. When it comes to reliability, UDP is relaxed.<\/p>\n\n\n\n
TCP offers robust reliability guarantees. It goes to some effort to confirm that a connection between the sender and recipient is established, that the recipient is prepared to receive messages, and, after the messages are sent, that they are delivered completely and in order. When it comes to reliability, TCP is a strict micromanager.<\/p>\n\n\n\n<\/figure>\n\n\n\nA Tale of Four Messages<\/a><\/h3>\n\n\n\nUnder good network conditions, it\u2019s actually quite hard to tell UDP and TCP apart in terms of reliability. But if conditions are poor, it\u2019s easier to see how reliability tradeoffs emerge. To illustrate, suppose your game needs to send four messages sequentially (but let\u2019s ignore their contents and importance, for now).<\/p>\n\n\n\n
In good conditions, messages arrive intact, promptly, in-order, and just once. In poorer conditions, none of these assumptions hold. How do the different protocols cope?<\/p>\n\n\n\n
With UDP, send the four messages, M1, M2, M3, and M4, each one after the other. What happens to each?<\/p>\n\n\n\n<\/figure>\n\n\n\n- M1 gets lost along the way. It never arrives.<\/li>
- M2 eventually arrives, but the routing is so convoluted, it\u2019s last to arrive.<\/li>
- M3 arrives first!<\/li>
- M4 arrives, but a router along the way spontaneously duplicated the message in transit, so it arrives twice<\/em>, once in second place and once in third.<\/li><\/ul>\n\n\n\n
As far as UDP is concerned, this is how it\u2019s supposed to happen. It\u2019s “best effort” but at least it\u2019s low overhead. The protocol doesn\u2019t require the receiver to notify the sender of any problems. If anything is to be done about this network hiccup\u2014to make sense of out-of-order delivery, repeated delivery, or the lost message the receiver didn\u2019t even know about\u2014it has to be done at the application layer, in your game.<\/p>\n\n\n\n
Let\u2019s rewind things and play this scenario out again over TCP. TCP is a more complex protocol and we\u2019ll have to tell a more complex story. But let\u2019s send those messages again, assuming that we\u2019ve already completed the three-way handshake and we\u2019re in the ESTABLISHED state. What happens to each?<\/p>\n\n\n\n<\/figure>\n\n\n\n- M1 gets lost along the way. Eventually resent (more on this later), it arrives last.<\/li>
- M2 eventually arrives, but the routing is so convoluted, it arrives after M3 and M4.<\/li>
- M3 arrives first!<\/li>
- M4 arrives, but a router along the way spontaneously duplicated the message in transit, so it arrives twice<\/em>, in second and <\/em>third place. TCP is clever though and knows to discard the duplicate M4.<\/li><\/ul>\n\n\n\n
TCP wants to protect you from this wrong and incomplete order, however. As M2, M3, and M4 arrive, TCP holds those messages until M1 arrives (this is known as head of line blocking<\/em>). While M1 is lost, TCP waits for a while to acknowledge what it has received (delayed ACK) and then waits some more while M1 is resent. Eventually, all four messages are received and TCP hands off the data to your application.<\/p>\n\n\n\nAs far as TCP is concerned, this is how it\u2019s supposed to happen. It\u2019s more reliable, but has noticeably more overhead in the form of round-trip exchanges. There are adjustments that can be made to minimize some of the more problematic features (such as turning off delayed ACK), but to get the guarantees of TCP, your application must necessarily submit to these constraints.<\/p>\n\n\n\n
Unfortunately, the protocols themselves only represent two points on the reliability gradient. TCP doesn\u2019t have a reduced guarantees mode and UDP doesn\u2019t have an opt-in for more reliability. If our only choices involved choosing TCP or UDP, we\u2019d face a hard decision between the risks of UDP\u2019s best effort and the restrictions of TCP. Luckily, your game has a say in the reliability story, too.<\/p>\n\n\n\n
Optionally reliable<\/a><\/h2>\n\n\n\nYour game, as a networked application, can choose how to use the network.<\/p>\n\n\n\n
In general, your game is not fixed to a single protocol: you can use UDP when you don\u2019t require the reliability guarantees of TCP and you can switch to TCP when you do. Under good network conditions (low latency and packet loss), this won\u2019t matter much. But if things get shaky, then you\u2019ll avoid some misadventures associated with lost messages.<\/p>\n\n\n\n
For points on the gradient between optional and required, there\u2019s a strategy called optionally reliable UDP<\/em>. This is when you build additional guarantees in your application, rather than relying on the protocol. In outline, this is sending UDP packets that require some response from the recipient; the message is re-sent until the expected response is received.<\/p>\n\n\n\nBut whether you choose UDP or TCP or optionally reliable UDP comes down to the content<\/em> of your messages and what they mean to your game and players.<\/p>\n\n\n\nStart with your payloads<\/a><\/h2>\n\n\n\nThe content of your messages matters more than the vehicle they travel in. Start by focusing on your payloads, then figure out how to get them there.<\/p>\n\n\n\n
Before you start sending messages, make sure you know what you need to send over the wire<\/strong> (and what you don\u2019t). For example, in an action game, your player\u2019s movements will probably be sent to the server many times per second, while your player\u2019s inventory status only needs to be sent when it changes. Smaller data structures are less likely to pay fragmentation penalties. The fastest packet is the one you never send.<\/p>\n\n\n\nKnow your player\u2019s context<\/strong>. Your netcode should reflect when and how your player is interacting with the game. This starts with the player\u2019s physical environment, such as playing on a desktop computer with a high-quality wired connection versus playing from a mobile device on a spotty mobile network. It also includes the game context; the game state may make certain kinds of messages more likely than others.<\/p>\n\n\n\nKnow what messages, if lost, would annoy the player<\/strong> (or worse), what they\u2019d never notice, and what\u2019s in between. Each message\u2019s place on the reliability gradient is key. If you know that prediction, interpolation, or other strategies can gracefully hide the occasional lost message, then that gives you more options for sending that message.<\/p>\n\n\n\nStand on shoulders of giants<\/a><\/h2>\n\n\n\nIf you\u2019re thinking that this only begins to dig into thinking about net code, then you\u2019re right. As you build out your games netcode, you\u2019ll need to learn more about different aspects of prediction, interpolation, serialization, and beyond.<\/p>\n\n\n\n
Read Ruoyu Sun\u2019s Game Networking Demystified<\/em><\/a>, which takes a closer look at game states and client inputs and how they relate to cheating, server authority, and game genre.<\/p>\n\n\n\nAnother great read is Peeking into VALORANT’s Netcode<\/a><\/em> from Riot Games, which goes in-depth on how product design goals can lead to specific decisions in netcode design.<\/p>\n\n\n\n
If your game has more than one mode of interaction, then it doesn\u2019t make sense that your game would have just one way of sending messages over the network. The content of the messages\u2014the type of gameplay that the messages support\u2014can give us a way to reason about how to use the transport layer.<\/p>\n\n\n\n
Any one message, depending on its contents, might have more or less impact on your player. If a single frame of voice chat audio is dropped, then it\u2019s unlikely that your player will notice the loss. Some messages, if lost, may be highly aggravating: a lost store purchase confirmation may lead a player to an unwanted repeat purchase. Other messages may fall in-between these extremes: the movement of a projectile might be highly consequential or nearly irrelevant, depending on whether it\u2019s traveling near the player.<\/p>\n\n\n\n If some messages must <\/em>be received while others are merely nice to have, then the game\u2019s networking code must support a gradient of reliability.<\/p>\n\n\n\n Transport layer protocols partly map to the gradient by setting distinct expectations for message delivery.<\/p>\n\n\n\n UDP offers few reliability guarantees. It\u2019s a more trusting protocol that expects that a message will be delivered. If it\u2019s not delivered, the protocol won\u2019t hear or do anything about it. It also doesn\u2019t make any assumptions about when the message is delivered. UDP makes no effort to ensure the order of delivery. The first message you sent may not be the first received. When it comes to reliability, UDP is relaxed.<\/p>\n\n\n\n TCP offers robust reliability guarantees. It goes to some effort to confirm that a connection between the sender and recipient is established, that the recipient is prepared to receive messages, and, after the messages are sent, that they are delivered completely and in order. When it comes to reliability, TCP is a strict micromanager.<\/p>\n\n\n\n Under good network conditions, it\u2019s actually quite hard to tell UDP and TCP apart in terms of reliability. But if conditions are poor, it\u2019s easier to see how reliability tradeoffs emerge. To illustrate, suppose your game needs to send four messages sequentially (but let\u2019s ignore their contents and importance, for now).<\/p>\n\n\n\n In good conditions, messages arrive intact, promptly, in-order, and just once. In poorer conditions, none of these assumptions hold. How do the different protocols cope?<\/p>\n\n\n\n With UDP, send the four messages, M1, M2, M3, and M4, each one after the other. What happens to each?<\/p>\n\n\n\n As far as UDP is concerned, this is how it\u2019s supposed to happen. It\u2019s “best effort” but at least it\u2019s low overhead. The protocol doesn\u2019t require the receiver to notify the sender of any problems. If anything is to be done about this network hiccup\u2014to make sense of out-of-order delivery, repeated delivery, or the lost message the receiver didn\u2019t even know about\u2014it has to be done at the application layer, in your game.<\/p>\n\n\n\n Let\u2019s rewind things and play this scenario out again over TCP. TCP is a more complex protocol and we\u2019ll have to tell a more complex story. But let\u2019s send those messages again, assuming that we\u2019ve already completed the three-way handshake and we\u2019re in the ESTABLISHED state. What happens to each?<\/p>\n\n\n\n TCP wants to protect you from this wrong and incomplete order, however. As M2, M3, and M4 arrive, TCP holds those messages until M1 arrives (this is known as head of line blocking<\/em>). While M1 is lost, TCP waits for a while to acknowledge what it has received (delayed ACK) and then waits some more while M1 is resent. Eventually, all four messages are received and TCP hands off the data to your application.<\/p>\n\n\n\n As far as TCP is concerned, this is how it\u2019s supposed to happen. It\u2019s more reliable, but has noticeably more overhead in the form of round-trip exchanges. There are adjustments that can be made to minimize some of the more problematic features (such as turning off delayed ACK), but to get the guarantees of TCP, your application must necessarily submit to these constraints.<\/p>\n\n\n\n Unfortunately, the protocols themselves only represent two points on the reliability gradient. TCP doesn\u2019t have a reduced guarantees mode and UDP doesn\u2019t have an opt-in for more reliability. If our only choices involved choosing TCP or UDP, we\u2019d face a hard decision between the risks of UDP\u2019s best effort and the restrictions of TCP. Luckily, your game has a say in the reliability story, too.<\/p>\n\n\n\n Your game, as a networked application, can choose how to use the network.<\/p>\n\n\n\n In general, your game is not fixed to a single protocol: you can use UDP when you don\u2019t require the reliability guarantees of TCP and you can switch to TCP when you do. Under good network conditions (low latency and packet loss), this won\u2019t matter much. But if things get shaky, then you\u2019ll avoid some misadventures associated with lost messages.<\/p>\n\n\n\n For points on the gradient between optional and required, there\u2019s a strategy called optionally reliable UDP<\/em>. This is when you build additional guarantees in your application, rather than relying on the protocol. In outline, this is sending UDP packets that require some response from the recipient; the message is re-sent until the expected response is received.<\/p>\n\n\n\n But whether you choose UDP or TCP or optionally reliable UDP comes down to the content<\/em> of your messages and what they mean to your game and players.<\/p>\n\n\n\n The content of your messages matters more than the vehicle they travel in. Start by focusing on your payloads, then figure out how to get them there.<\/p>\n\n\n\n Before you start sending messages, make sure you know what you need to send over the wire<\/strong> (and what you don\u2019t). For example, in an action game, your player\u2019s movements will probably be sent to the server many times per second, while your player\u2019s inventory status only needs to be sent when it changes. Smaller data structures are less likely to pay fragmentation penalties. The fastest packet is the one you never send.<\/p>\n\n\n\n Know your player\u2019s context<\/strong>. Your netcode should reflect when and how your player is interacting with the game. This starts with the player\u2019s physical environment, such as playing on a desktop computer with a high-quality wired connection versus playing from a mobile device on a spotty mobile network. It also includes the game context; the game state may make certain kinds of messages more likely than others.<\/p>\n\n\n\n Know what messages, if lost, would annoy the player<\/strong> (or worse), what they\u2019d never notice, and what\u2019s in between. Each message\u2019s place on the reliability gradient is key. If you know that prediction, interpolation, or other strategies can gracefully hide the occasional lost message, then that gives you more options for sending that message.<\/p>\n\n\n\n If you\u2019re thinking that this only begins to dig into thinking about net code, then you\u2019re right. As you build out your games netcode, you\u2019ll need to learn more about different aspects of prediction, interpolation, serialization, and beyond.<\/p>\n\n\n\n Read Ruoyu Sun\u2019s Game Networking Demystified<\/em><\/a>, which takes a closer look at game states and client inputs and how they relate to cheating, server authority, and game genre.<\/p>\n\n\n\n Another great read is Peeking into VALORANT’s Netcode<\/a><\/em> from Riot Games, which goes in-depth on how product design goals can lead to specific decisions in netcode design.<\/p>\n\n\n\n<\/figure>\n\n\n\nReliability is a gradient<\/a><\/h2>\n\n\n\n
<\/figure>\n\n\n\nA Tale of Four Messages<\/a><\/h3>\n\n\n\n
<\/figure>\n\n\n\n<\/figure>\n\n\n\nOptionally reliable<\/a><\/h2>\n\n\n\n
Start with your payloads<\/a><\/h2>\n\n\n\n
Stand on shoulders of giants<\/a><\/h2>\n\n\n\n