Add server side game developer roadmap

src/data/roadmaps/server-side-game-developer/content/100-roadmap-note.md

@@ -0,0 +1,3 @@
+# Note
+
+These roadmaps cover everything that is there to learn for the paths listed below. Don't feel overwhelmed, you don't need to learn it all in the beginning if you are just getting started.

src/data/roadmaps/server-side-game-developer/content/100-server-side.md

@@ -0,0 +1,3 @@
+# Server Side
+
+The term "server-side" refers to operations that are performed by the server in a client-server relationship in a computer network. In games, the server-side is responsible for the logic and rules of the game, data persistence, security, and synchronization of the game state among all connected clients. It essentially handles all processing that isn't done on the client-side. Code run on the server-side can be written in various programming languages, but it's often in PHP, Ruby, Python, .NET, Java, or JavaScript (Node.js). Knowing server-side programming is critical for any game developer to create maintainable, scalable, and secure online games.

src/data/roadmaps/server-side-game-developer/content/101-tcp/100-checksum.md

@@ -0,0 +1,3 @@
+# Checksum
+
+A **checksum** in TCP (Transmission Control Protocol) is a 16-bit field in the TCP header used to perform error checks on the segments. TCP stack computes the checksum value for the data transmitted and sends it along with the data to the receiving system. The receiving system re-computes the checksum and compares it with the value sent along with the data. If both the computed values match, the data is assumed to be free from transmission errors. However, if the computed values don't match, TCP will detect a possible change in received data, and the receiver will request for the re-transmission of the lost or corrupted data packets. Please note that while the checksum operation helps to ensure data integrity, it is not entirely foolproof as it might not detect all possible errors, particularly those that involve multiple bit changes.

src/data/roadmaps/server-side-game-developer/content/101-tcp/101-segment-structure.md

@@ -0,0 +1,3 @@
+# Segment Structure
+
+TCP (Transmission Control Protocol) uses a method called "segmentation" to manage data transmission. In this approach, TCP divides a stream of data into smaller parts, known as "segments". Each of these segments is then independently sent over the internet. A basic TCP segment consists of a header and the data section. The header contains various fields such as source port, destination port, sequence number, acknowledgment number, data offset, reserved section, control bit, window, checksum, urgent pointer, and options. The rest of the segment is occupied by the data transferred by TCP. Understanding the structure of these segments is crucial for understanding how TCP, and thereby much of the Internet, operates.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/100-connection.md

@@ -0,0 +1,3 @@
+# Connection
+
+`Connection` in server-side game development refers to the establishment of a link between the game server and the game client (usually the player's device). This connection can either be persistent or non-persistent, depending on the game’s requirements. Persistent connections remain active as long as the user is logged in, facilitating real-time communication between the server and the client. Non-persistent connections, on the other hand, are established and discontinued as needed. This element is crucial in multiplayer games where the server handles the synchronization of data among multiple clients, enabling players to interact with each other in the same virtual environment.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/101-resource-usage.md

@@ -0,0 +1,3 @@
+# Resource Usage
+
+In server-side game development, **resource usage** broadly refers to how a game uses the server's computational power, memory, storage, and networking capabilities. These resources are crucial in assuring overall game performance and responsiveness. When monitoring resource usage, you typically pay attention to CPU usage, memory utilization, storage capacity, network bandwidth, and database performance. Server-side code must be developed and optimized with these resources in mind, as inefficient code can lead to increased resource usage, potentially causing lag, disconnections, or crashes. Key elements like scalable architecture and serverless technologies are primarily employed to efficiently manage and balance resource usage. Tools and automated solutions are commonly utilized to monitor and manage these resources in real-time, allowing developers to identify potential issues and optimize accordingly.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/102-data-transfer/congestion-control.md

@@ -0,0 +1,3 @@
+# Congestion Control
+
+`Congestion Control` is a critical aspect of any network, particularly in server-side game development where real-time data transfer is a must. It refers to techniques and mechanisms that can prevent too much data from filling the network. This excessive data, also known as network congestion, can lead to packet loss, delay in data transfer, and ultimately a poor gaming experience. Congestion control algorithms, such as TCP congestion control algorithms, are implemented to avoid such situations. They adjust the data packet transmission rate based on the perceived network congestion, reducing the rate when congestion is detected and increasing it when the network is less congested.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/102-data-transfer/flow-control/error-detection.md

@@ -0,0 +1,3 @@
+# Error Detection
+
+Error detection is a mechanism that checks the integrity of data that is being delivered or stored. In the context of server-side game development, errors can occur due to reasons like network inconsistencies, corrupted data, or server overload. To ensure smooth operation, these errors need to be detected and handled. Some common types of error detection methods include parity check, checksum, and cyclic redundancy check (CRC). Parity check adds an extra bit to the data to make the number of 1’s either even or odd. Checksum involves the sender adding up all the bits in the data and sending the sum along with data. CRC is a more complex and robust method involving binary division. These methods help detect errors but can't fix them. Once detected, errors are typically dealt with through retransmission or by using forward error correction codes.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/102-data-transfer/flow-control/index.md

@@ -0,0 +1,3 @@
+# Flow Control
+
+Flow control, often referred to as stream control transmission protocol (SCTP), is essential in server-side game development, particularly in data transfer. Flow control is basically a technique used to manage the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver. It provides an effective way to manage the amount of data that can be sent before having to receive an acknowledgment. There are two main types of flow control: window-based and rate-based. Window-based flow control allows the receiver to process a fixed set of packets before sending the acknowledgement, whereas rate-based control allows for data transfer at a specified rate. These methods make flow control indispensable in network communications.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/102-data-transfer/index.md

@@ -0,0 +1,3 @@
+# Data Transfer
+
+Data transfer in server-side game development refers to the movement of data between the server and client or among various components of the server itself. Game data, such as player scores, game states, and updates, are frequently transferred to ensure a consistent and updated gaming environment. Various methods are used for data transfer, including RESTful APIs, websockets, and protocol buffers. The choice of method often depends on factors such as the size and type of data, the target platform, and the specific needs of the game. Remember, efficient and secure data transfer is essential for providing a smooth and engaging gaming experience.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/102-data-transfer/reliable-transmission.md

@@ -0,0 +1,3 @@
+# Reliable Transmission
+
+Reliable Transmission is a service that ensures data is delivered from the source to the destination without any errors. This includes mechanisms that provide accurate, on-time delivery of all packets while managing packet loss, duplication, or out-of-order delivery. In server-side game development, protocols like TCP (Transmission Control Protocol) are often used to accomplish reliable transmission. Reliable transmission is particularly necessary for critical data where all transmitted information must arrive at the destination correctly and in the right order. TCP accomplishes this by establishing a connection before data transfer begins and using sequence numbers to track delivery and reassemble pieces in the correct order. TCP also sends acknowledgements back to the source confirming packet delivery, and implements re-transmission of lost or corrupted data. Despite its overhead and slower speed compared to other methods, such as the User Datagram Protocol (UDP), reliable transmission is vital when data integrity is a priority over speed.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/103-max-segment-scaling.md

@@ -0,0 +1,3 @@
+# Max Segment Scaling
+
+`Max Segment Scaling (MSS)` is a TCP feature that defines the maximum amount of data that can be received in a single TCP segment. It is specified during the TCP connection establishment phase. The MSS is calculated as the data link layer Maximum Transmission Unit (MTU) minus the size of the TCP and IP headers. The mechanism helps to avoid fragmentation at the IP layer, ensuring the data packets sent are optimal for the network path taken, preventing potential transmission inefficiencies or packet loss issues.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/104-window-scaling.md

@@ -0,0 +1,3 @@
+# Window Scaling
+
+Window Scaling is a mechanism in the Transmission Control Protocol (TCP) that provides support for larger receiver window sizes beyond the maximum limit of 65,535 bytes. This TCP feature is essential when dealing with high latency or high bandwidth networks (common in server-side game development), where frames might be significantly delayed or rapidly transmitted. The window size initially specified in the TCP header is augmented via a scale factor (defined during the connection setup), allowing the receiver window size to be as large as 1 gigabyte. However, keep in mind that Window Scaling can only be employed at the connection setup stage; once the connection is established, the scaling factor cannot be changed.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/105-timestamp.md

@@ -0,0 +1,3 @@
+# Timestamp
+
+A `timestamp` in server side game development is essentially a sequence of characters, encoding the date and time at which a certain event occurred. This data is particularly significant when tracking the sequence of certain events, debugging issues, logging, and when performing any sort of data analysis. The timestamp is typically generated by the server and it reflects the server's current date and time. For instance, you might find it in a server log file, indicating when each event occurred, or in a database row, showing when each row was created or last updated. Timestamps are often included in the HTTP headers to let the client know when the resource was last modified.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/106-out-of-band-data.md

@@ -0,0 +1,3 @@
+# Out-of-Band Data
+
+"Out of band" data, in the context of server-side game development, refers to data that is transmitted separately from the main data stream. This data is used for managing control information rather than actual game data, for instance, data regarding the status of the server, notifications about issues, or urgent commands. Given its importance, it's often designed to bypass any queueing or buffering systems to be delivered straight to the application, hence its name — it is "out of band" compared to the normal data transmissions in the game. Please note, out of band data needs proper handling to prevent potential vulnerabilities including security issues.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/107-selective-acknowledgement.md

@@ -0,0 +1,3 @@
+# Selective Acknowledgement
+
+Selective Acknowledgement (SACK) is a mechanism introduced in TCP to improve its efficiency in handling packet loss in the network. When TCP detects packet loss, it normally retransmits all packets sent after the lost packet, regardless of whether they were received successfully or not. SACK, however, allows the receiver to acknowledge non-consecutive packets, effectively informing the sender exactly which packets were received successfully and which weren't. By using this mechanism, TCP can selectively retransmit only those packets that were lost, saving bandwidth and improving overall performance.

src/data/roadmaps/server-side-game-developer/content/101-tcp/102-operations/index.md

@@ -0,0 +1,3 @@
+# Operations
+
+TCP (Transmission Control Protocol) is a connection-oriented protocol that ensures reliable, ordered, and error-checked delivery of data between systems over an IP network. Some of the primary operations include "Connection Establishment" that initializes a connection using a 3-way handshake, "Data Transfer" where packets of data are sent from sender to receiver, "Connection Termination" that closes the connection when transmission is complete, and "Error Control" which handles retransmission of lost data or corrupted packets. Additionally, TCP handles "Flow Control" to prevent a sender from overwhelming a receiver with data, and "Congestion Control" to manage network congestion and avoid packet loss.

src/data/roadmaps/server-side-game-developer/content/101-tcp/103-vulnerability/100-denial-of-service.md

@@ -0,0 +1,3 @@
+# Denial of Service
+
+Denial of Service (DoS) is a malicious attempt to disrupt the regular functioning of a network, service, or server by overwhelming the network or server with a flood of internet traffic. The most common type of DoS attack involves flooding the target with unnecessary requests in an attempt to overload the system. In a Distributed Denial of Service (DDoS) attack, multiple computers are used to carry out the cyber attack. For servers, these attacks can significantly affect the availability and performance of games, causing a poor experience for the users.

src/data/roadmaps/server-side-game-developer/content/101-tcp/103-vulnerability/101-connection-hijacking.md

@@ -0,0 +1,3 @@
+# Connection Hijacking
+
+`Connection hijacking`, also known as session hijacking, is a serious security threat in the realm of server side game development. It refers to the exploitation of a valid computer session, or more precisely, the intrusion of an unauthorized user into a valid connection between two nodes or endpoints. The attacker intercepts the traffic between these two nodes, thereby 'hijacking' the connection. In game development, this could involve intercepting information between a game server and a client's system. Connection hijacking could expose sensitive data, tamper with the data in transit, or even redirect clients to rogue servers. Hence, implementing necessary security protocols to mitigate such vulnerability is crucial.

src/data/roadmaps/server-side-game-developer/content/101-tcp/103-vulnerability/102-veto.md

@@ -0,0 +1,3 @@
+# Veto
+
+`Veto` is often used in multiplayer games to prevent or allow certain actions during the game. For instance, players can issue commands to block specific actions from their opponents. As a server-side game developer, you must ensure security measures are in place to validate the authenticity of these commands to safeguard against potential vulnerability. A veto vulnerability can occur when malicious players manipulate veto commands to their advantage or disrupt the game, which can lead to an unfair gaming environment or even crash the server. Therefore, your code should always verify who is sending veto commands and check the validity of these commands.

src/data/roadmaps/server-side-game-developer/content/101-tcp/103-vulnerability/index.md

@@ -0,0 +1,3 @@
+# Vulnerability
+
+`TCP` (Transmission Control Protocol) is an important protocol known for its reliability in delivering data packets, but it also has several vulnerabilities. The most significant weakness is TCP’s susceptibility to a variety of **Denial-of-Service (DoS)** attacks, such as TCP SYN flood attacks, where an attacker sends a succession of SYN requests to a target's system in an attempt to consume server resources to make the system unresponsive. Additionally, sequence prediction can be exploited where an attacker can predict the sequence number of TCP packets to hijack the TCP session. There are also risks of IP spoofing, where an attacker can forge the IP address in the TCP packet header and pretend to be another user in the network. These vulnerabilities may expose sensitive information, disrupt normal functions or allow unauthorized access, especially in the context of a server-side game developer dealing with potentially large volumes of traffic.

src/data/roadmaps/server-side-game-developer/content/101-tcp/index.md

@@ -0,0 +1,3 @@
+# TCP
+
+TCP, an acronym for Transmission Control Protocol, is a fundamental protocol in the suite of internet protocols. It is a connection-oriented, reliable, byte stream service that sits at the transport layer of the OSI Model. In simpler terms, TCP enables two hosts to establish a connection and exchange data. During this communication, TCP ensures that data is not lost or received out of order by providing error checking mechanisms and a system for retransmission of lost data. Furthermore, to ensure efficient use of network resources, TCP implements flow control, congestion control and provides a means for hosts to dynamically adjust the throughput of the connection.

src/data/roadmaps/server-side-game-developer/content/102-udp/100-reliability.md

@@ -0,0 +1,3 @@
+# Reliability
+
+Reliability refers to how consistently a data packet can be transferred from one system to another over a network. In terms of the User Datagram Protocol (UDP), it has a lack of reliability built into it. This means UDP does not guarantee that your data will reach its destination, it merely sends the packets without any acknowledgement of receipt. Unlike its counterpart, Transmission Control Protocol (TCP), which implements error-checking mechanisms to ensure data integrity and delivery. In summary, if you require high reliability in your server side game development, protocols other than UDP might need to be considered.

src/data/roadmaps/server-side-game-developer/content/102-udp/101-datagram.md

@@ -0,0 +1,3 @@
+# Datagram
+
+A **Datagram** is the basic unit of data transfer in network communication using protocols such as User Datagram Protocol (UDP). Each datagram operates independently of each other, meaning they may be received in a different order than they were sent, or they might not be received at all. Therefore, unlike TCP (Transmission Control Protocol), UDP does not guarantee that datagrams are delivered in the same order that they were sent, or even at all - hence known as connectionless protocol. However, it is faster and more efficient for applications that do not require delivery guarantees, such as voice over IP, live video broadcasts, and other real-time applications. Each datagram contains information about the sender, the intended recipient, and the data that it is intended to communicate along with its size and other specifications.

src/data/roadmaps/server-side-game-developer/content/102-udp/102-congestion-control.md

@@ -0,0 +1,3 @@
+# Congestion Control
+
+`Congestion Control` is a critical feature of TCP, but not inherently a part of UDP. The primary purpose of congestion control is to prevent too much data from being sent into the network such that it can't handle the traffic, leading to packet loss. TCP's congestion control mechanism adjusts the data send rate based on the perceived network congestion. UDP does not provide congestion control by itself. However, this does not mean congestion control can't be implemented if you're using UDP. Developers can implement a custom congestion control mechanism over UDP, but it requires substantial understanding and careful management to achieve this without creating network or server performance issues.</div>

src/data/roadmaps/server-side-game-developer/content/102-udp/103-checksum.md

@@ -0,0 +1,3 @@
+# Checksum
+
+The `checksum` is an important element in UDP that ensures the integrity and validation of the data being transmitted. It computes the total sum of all the bytes in a packet and incorporates it as an additional `checksum` field in the UDP header. When the packet arrives at its destination, this process is repeated and compared with the included `checksum`. If a match is observed, the packet is deemed valid. If not, it signifies that an error occurred during transmission possibly due to noise or any third-party interference. In such a case, the packet is simply dropped, as UDP does not initiate any retransmission or error correction procedure. This is why a perfect output cannot be guaranteed with UDP, nor can it determine whether all the recipients are receiving the packets properly.

src/data/roadmaps/server-side-game-developer/content/102-udp/104-packet-structure.md

@@ -0,0 +1,3 @@
+# Packet Structure
+
+UDP or User Datagram Protocol is designed to send messages known as datagrams over the network. The packet structure of UDP is relatively simple compared to other protocol types. Each UDP header consists of 4 fields, each of 2 bytes. These 4 fields are namely: Source Port, Destination Port, Length, and Checksum. The `Source Port` is for tracking responses and `Destination Port` is for delivering the datagram on the receiving end. The `Length` specifies the entire datagram size including the header and data while the `Checksum` is used to verify the integrity of the data and header.

src/data/roadmaps/server-side-game-developer/content/102-udp/index.md

@@ -0,0 +1,3 @@
+# UDP
+
+`UDP`, or User Datagram Protocol, is a communications protocol that sends data over the internet. Unlike TCP (Transmission Control Protocol), it's a connectionless protocol that doesn't ensure data packet delivery. It transmits datagrams – an independent, discrete packet of data – without first establishing a proper handshake between the sender and the receiver. The sender doesn't wait for an acknowledgment after sending a datagram, and the receiver doesn't send any acknowledgment upon receiving a datagram. This makes UDP faster but less reliable than TCP. UDP is used for time-sensitive transmissions where dropped packets are acceptable, such as in live video streaming, voice over IP (VoIP), and online multiplayer gaming.

src/data/roadmaps/server-side-game-developer/content/103-tcp-vs-udp/100-reliable-vs-unreliable.md

@@ -0,0 +1,5 @@
+# Reliable vs Unreliable
+
+In the context of network communication, the terms "reliable" and "unreliable" refer to whether or not data sent across the network is guaranteed to reach its destination. Reliable protocols, such as TCP, ensure that data is delivered from sender to receiver without loss. They do this by establishing a connection, dividing data into packets, sending them one by one, and waiting for acknowledgment of receipt from the receiver. Each sent packet is numbered so if any packet doesn't reach the receiver, it will be identified by the missing sequence number and resent. In this way, reliable protocols ensure data integrity and order.
+
+On the other hand, unreliable protocols, such as UDP, do not guarantee delivery. They simply transmit data without any checks to ensure it has been received. If a packet is dropped for any reason, it is not resent. These protocols do not establish a connection nor check for successful data transfer. This leads to potential data loss, but it provides a faster and more efficient transmission process which can be desirable in certain situations.

src/data/roadmaps/server-side-game-developer/content/103-tcp-vs-udp/101-ordered-vs-not-ordered.md

@@ -0,0 +1,3 @@
+# Ordered vs Not Ordered
+
+In the context of TCP vs UDP, "ordered" and "not ordered" refers to the order in which packets are received. In TCP (Transmission Control Protocol), packets are ordered. This means that the packets of data are sent and received in the same order. For example, if packet 1, packet 2, and packet 3 are sent in that order, they will be delivered and read in that exact order whether, packet 2 takes longer to send or not. On the other hand, UDP (User Datagram Protocol) is not ordered. The packets of data are independent of each other. So, if packet 1, packet 2, and packet 3 are sent in that order, they could be received in a different order such as packet 2, packet 1, then packet 3. This happens because UDP doesn't re-order packets as TCP does.

src/data/roadmaps/server-side-game-developer/content/103-tcp-vs-udp/102-heavyweight-vs-lightweight.md

@@ -0,0 +1,5 @@
+# Heavyweight vs Lightweight
+
+TCP (Transmission Control Protocol) is often described as a "heavyweight" protocol because it provides numerous features such as error-checking, guaranteed delivery, and order-of-arrival of data packets, which makes it more complex to implement in the server. This complexity results in additional server load, making it heavier in terms of processing resources and system requirements. 
+
+On the other hand, UDP (User Datagram Protocol) is known as a "lightweight" protocol. It is simpler and faster because it does not offer the same extensive features as TCP. UDP does not guarantee delivery, does not require initial handshake establishment between communicating systems, and does not put data packets in order, thereby reducing the computation and rendering it lightweight.

src/data/roadmaps/server-side-game-developer/content/103-tcp-vs-udp/103-packet-vs-datagram.md

@@ -0,0 +1,9 @@
+# Packet vs Datagram
+
+**Packet** and **Datagram** are terms used in data communication. 
+
+A **Packet** is the most general term that just refers to the encapsulated data passed across networks. It is the generic term used to describe unit of data at all levels of the protocol stack. Packets include not just the data, but also headers and footers with control information, such as source and destination addresses, error checking codes, and sequencing information. 
+
+On the other hand, a **Datagram** is a specific type of data packet. It is an independent, self-contained message sent over the network whose arrival, arrival time, and content are not guaranteed. This term is particularly associated with the UDP (User Datagram Protocol), where each transmission unit is called a datagram. 
+
+The difference between packets and datagrams depends largely on the protocol being used to transmit the data. TCP (Transmission Control Protocol) data is typically referred to as a packet, whereas with UDP it is a datagram.

src/data/roadmaps/server-side-game-developer/content/103-tcp-vs-udp/104-streaming-vs-broadcast.md

@@ -0,0 +1,3 @@
+# Streaming vs Broadcast
+
+In the context of network protocol, streaming and broadcasting are two methods for transmitting data packets. Streaming, often performed over TCP, entails sending data from one source to a single specific destination. This method is comparable to a one-to-one phone call. The streaming process is characterized by steady data transmission directly to a single receiver who has initiated a connection. On the contrary, broadcasting refers to the transmittal of data packets from one source to all possible destinations in the network. Similar to a public announcement over a loudspeaker, the data is sent to all receptive entities. Broadcasting primarily utilizes the UDP protocol and does not require a direct connection or acknowledgement of receipt from the recipients.

src/data/roadmaps/server-side-game-developer/content/103-tcp-vs-udp/index.md

@@ -0,0 +1,3 @@
+# TCP vs UDP
+
+TCP, or Transmission Control Protocol, is a connection-oriented protocol that guarantees delivery of packets to the destination router. It includes error-checking and ensures packets are delivered in the correct order. On the other hand, UDP, or User Datagram Protocol, is a connectionless protocol which doesn't guarantee delivery or ensure correct sequencing of packets. As a result, UDP is considered faster and more efficient for some applications like video streaming or online gaming where speed matters more than accuracy. So, choosing between TCP and UDP really boils down to the specific requirements and priorities of the situation - it's a trade-off between speed and reliability.

src/data/roadmaps/server-side-game-developer/content/104-ip/100-capability.md

@@ -0,0 +1,3 @@
+# Capability
+
+In server-side game development, `capability` basically refers to the potential of the server in terms of supporting the game mechanics, the players, the network traffic, and other elements that allow the game to function effectively. Hosting servers condition the player's game interface and user experience, incorporating the aspects of speed, smooth game flow, glitch prevention, and high-performance gameplay. Certain servers have higher capabilities, supporting complex games with vast virtual environments, numerous players, and extensive data traffic. Their capacity extends to facilitating updates and patches immediately. On the other hand, servers with lower capabilities might only cater to simpler games. Ultimately, the `capability` of an IP server is a key factor in developing and maintaining a successful online, multiplayer, or large-scale game.

src/data/roadmaps/server-side-game-developer/content/104-ip/101-reliability.md

@@ -0,0 +1,3 @@
+# Reliability
+
+The **Reliability** in terms of IP (Internet Protocol) generally refers to the dependability and consistency of the network connections. It's essentially about how reliable the data transfer is over the network. IP itself is an unreliable protocol, meaning it doesn't guarantee the delivery of data packets. This is where protocols like TCP (Transmission Control Protocol) come in. TCP adds a layer of reliability to IP by ensuring the delivery of the data packets, ordering them correctly and error-checking. This ensures that game data synchronizes correctly across the server and clients without any loss, providing consistency and a smooth gameplay experience. However, the full guarantees of TCP come with some additional overhead; therefore, some games might prefer to use unreliable protocols when high performance is more critical than absolute reliability.

src/data/roadmaps/server-side-game-developer/content/104-ip/102-link-capacity.md

@@ -0,0 +1,3 @@
+# Link Capacity
+
+Link capacity, also known as bandwidth, refers to the maximum amount of data that can be transmitted over a network link within a given period of time. It is usually measured in bits per second (bps), kilobits per second (Kbps), megabits per second (Mbps), gigabits per second (Gbps), or terabits per second (Tbps). The link capacity is a critical factor in determining the throughput and latency of a server, impacting the overall performance and efficiency of the network communication. Please note that link capacity can be affected by various factors such as the quality of the transmission medium, the distance between the source and destination, and the network congestion.

src/data/roadmaps/server-side-game-developer/content/104-ip/103-functions/100-datagram-construction.md

@@ -0,0 +1,3 @@
+# Datagram Construction
+
+Datagram construction is a fundamental process in server-side game development, especially when dealing with UDP (User Datagram Protocol). In this context, a datagram is a basic transfer unit associated with a packet-switched network, which typically encompasses a header and payload data. The process of datagram construction involves encapsulating the specific game data (such as player position, game state, etc.) in the datagram payload and setting appropriate values in the datagram header such as Source and Destination IP addresses, Checksum and other protocol-specific values. Constructing and parsing datagrams correctly is crucial for ensuring reliable and efficient communication between the game server and clients.

src/data/roadmaps/server-side-game-developer/content/104-ip/103-functions/101-ip-addressing.md

@@ -0,0 +1,3 @@
+# IP Addressing
+
+IP (Internet Protocol) addressing is a fundamental aspect of networking, at the core of interaction between systems in a network. Each device connected to a network must have a unique address, known as an IP address, to communicate with other devices. In version 4 of the IP protocol (IPv4), these addresses are usually represented as four numbers, each ranging from 0 to 255, separated by periods (e.g., 192.168.1.1). The newer standard, IPv6, introduced to deal with the shortage of available IPv4 addresses, employs a more complex notation using hexadecimal numbers and colons. However, the purpose remains the same: to uniquely identify each device on a network. IP addresses can be either static (permanently assigned to a device) or dynamic (assigned temporarily from a pool of addresses).

src/data/roadmaps/server-side-game-developer/content/104-ip/103-functions/102-routing.md

@@ -0,0 +1,3 @@
+# Routing
+
+In server-side game development, **routing** refers to the specification of how an application responds to a client request to a particular endpoint, which is a URI (or path) and a specific HTTP request method (GET, POST, etc.). Each route can have one or more handler functions, which are executed when the route is matched. These handler functions, often coming into play within complex multiplayer game scenarios, handle the logic needed for the route, including data transmission, game state updates, etc. The use of properly configured routes ensures the correct data is sent where it is needed, supporting seamless gameplay interactions.

src/data/roadmaps/server-side-game-developer/content/104-ip/103-functions/index.md

@@ -0,0 +1,3 @@
+# Function
+
+In server-side game development, functions are a fundamental building block of programming. These are reusable pieces of code designed to perform a particular task. Developers create functions to streamline code, improve readability, and enhance the efficiency of their program. Functions can take parameters as input and return a result. The syntax for declaring a function varies from one programming language to another. However, the basic structure remains the same. It usually starts with a function keyword, followed by the function name and parentheses `()`. Inside these parentheses, we can pass parameters. These parameters are then utilized within the function's body enclosed within curly brackets `{}`. The outputs are typically returned using a return statement. Remember, each function should ideally perform one task, and the function name should accurately represent its purpose to make the code self-explanatory.

src/data/roadmaps/server-side-game-developer/content/104-ip/104-transactions/100-arp.md

@@ -0,0 +1,3 @@
+# ARP
+
+**ARP** or **Address Resolution Protocol** is a protocol used to map an IP address to a physical address on the network, such as a MAC address. A device uses ARP when it needs to forward a packet to another device on the same network but only has the IP address. ARP broadcasts a request packet to all devices on the local network to find who owns the IP address. The device with the matching IP address replies with its MAC address. ARP maintains a cache of previously resolved addresses to minimize traffic. It is an essential protocol in network communication, but it also exposes certain security vulnerabilities like ARP spoofing.

src/data/roadmaps/server-side-game-developer/content/104-ip/104-transactions/101-dns.md

@@ -0,0 +1,3 @@
+# DNS
+
+**Domain Name System (DNS)** is an internet service that translates domain names into IP addresses. The internet uses IP addresses to locate and connect different computers, but these numerical addresses can be difficult to remember or use practically. Therefore, DNS allows users to type in a domain name, such as www.example.com, and it translates this name into the equivalent IP address, such as 192.0.2.1. It is used every time you visit a website, send an email, or connect to any service on the internet. DNS serves as the internet's phone book, ensuring that every domain name corresponds to the correct IP address.

src/data/roadmaps/server-side-game-developer/content/104-ip/104-transactions/102-dhcp.md

@@ -0,0 +1,3 @@
+# DHCP
+
+DHCP, or Dynamic Host Configuration Protocol, is an internet protocol that enables automatic assignment of IP addresses to devices on a network. Its key role in network systems is to eliminate the manual task of assigning IP addresses in a large network. DHCP can be implemented in small, medium, or large networks encompassing hundreds of computers or even more. It involves a DHCP server, which is responsible for allocating IP addresses and controlling the process. This server maintains a pool of IP addresses, which it assigns to devices as they connect to the network. DHCP also handles release and renewal of these IP addresses as devices leave and rejoin the network.

src/data/roadmaps/server-side-game-developer/content/104-ip/104-transactions/index.md

@@ -0,0 +1,3 @@
+# Transactions
+
+In server-side game development, **transactions** are critical elements that facilitate the exchange or interaction between different processes and data streams. These are usually carried out via a database or a server and are atomically treated as a single unit of work, ensuring data consistency and integrity. Transactions follow a specific pattern known as ACID (Atomicity, Consistency, Isolation, Durability) which makes sure that all intended operations within a transaction are successfully performed or none of them are, preventing disruptions in the event of an error or failure. It also ensures that concurrent execution of transactions results in a system state that would be achieved if transactions were executed sequentially. It's important for a server-side game developer to understand how to manage and control transactions to maintain the robustness of the game's backend system.

src/data/roadmaps/server-side-game-developer/content/104-ip/105-categories/100-ipv4.md

@@ -0,0 +1,3 @@
+# IPv4
+
+`IPv4`, or Internet Protocol Version 4, is the fourth version of IP (Internet Protocol). It's a foundational protocol that routes most of the Internet traffic today, even with the growing reach of IPv6. `IPv4` is responsible for identifying devices on a network through an addressing system. The `IPv4` uses a 32-bit address schema allowing for a total of just over 4 billion addresses. Most importantly, `IPv4` determines how data is sent and received over network devices. This standard of `IPv4` helps to route data between networks and has been foundational in the creation of the modern Internet.

src/data/roadmaps/server-side-game-developer/content/104-ip/105-categories/101-ipv6.md

@@ -0,0 +1,3 @@
+# IPv6
+
+IPv6, which stands for Internet Protocol version 6, is the most recent version of the Internet Protocol (IP), formulated to rectify the impending issue of IPv4 address exhaustion. Unlike IPv4, which uses 32-bit address, IPv6 employs a 128-bit address, enabling a massive number of unique IP addresses to exist. This augments the capacity of the internet to accommodate an array of networks and devices, serving as a sustainable solution for an ever-expanding digital world. IPv6 also provides enhanced functionalities including simplified header format, improved support for extensions and options, built-in security using IPsec, and better support for QoS (Quality of Service). In server side game development, IPv6 ensures smooth and lag-free game experiences to players by enabling direct peer-to-peer connections.

src/data/roadmaps/server-side-game-developer/content/104-ip/105-categories/index.md

@@ -0,0 +1,13 @@
+# Category
+
+The Internet Protocol Addresses (IP Addresses) are categorized into five different classes, namely, Class A, Class B, Class C, Class D, and Class E.
+
+**Class A** IP address is designed for large networks and ranges from 0.0.0.0 to 127.255.255.255. 
+
+**Class B** IP addresses are allocated to medium-sized and large-sized networks and ranges from 128.0.0.0 to 191.255.255.255. 
+
+**Class C** IP addresses are utilized for small-sized networks and ranges from 192.0.0.0 to 223.255.255.255. 
+
+**Class D** IP address is designed for multicast groups and ranges from 224.0.0.0 to 239.255.255.255. 
+
+Lastly, **Class E** IP address ranges from 240.0.0.0 to 255.255.255.254 and is preserved for research and development purposes.

src/data/roadmaps/server-side-game-developer/content/104-ip/106-security/100-tls.md

@@ -0,0 +1 @@
+# Tls

src/data/roadmaps/server-side-game-developer/content/104-ip/106-security/index.md

@@ -0,0 +1,3 @@
+# Security
+
+In server-side game development, the aspect of IP (Internet Protocol) security is of paramount importance. This primarily involves ensuring the safety of online gaming interactions, protection of sensitive user data being transmitted, and thwarting possible cyber-attacks or threats. This might include mitigation strategies against DDoS (Distributed Denial of Service) attacks, which are common in multiplayer gaming environments, IP spoofing, and session hijacking. Security measures often involve developing secure server architectures, encryption of data in transit and at rest, validation and sanitization of user input, and implementing comprehensive security policies and procedures. Regular risk assessment and vulnerability scanning are also crucial for identifying and addressing potential security loopholes. Therefore, for any game developer, understanding IP security protocols and integrating them into game development processes is essential to provide users with trustworthy gaming environments.

src/data/roadmaps/server-side-game-developer/content/104-ip/index.md

@@ -0,0 +1,3 @@
+# IP
+
+**Internet Protocol (IP)** is the primary method used to send and receive messages on the internet. It's a set of rules that dictate how data should be delivered over the internet. An IP address is a unique string of numbers separated by periods that identifies each device using the Internet Protocol to communicate over a network. There are two types: IPv4 and IPv6. IPv4, the most common, consists of four groups of numbers, each ranging from 0 to 255. For example, "192.168.0.1". On the other hand, IPv6, the next-generation protocol, provides about 340 undecillion addresses, ensuring the ability to provide unique IPs for every device on the planet. For instance, "2001:0db8:85a3:0000:0000:8a2e:0370:7334". Each IP address can be static (permanent) or dynamic (changeable), depending on your network configurations.

src/data/roadmaps/server-side-game-developer/content/105-programming-languages/100-c-cpp.md

@@ -0,0 +1,3 @@
+# C / C++
+
+"C" and "C++", often written as "C/CPP", are two significantly prominent and similar programming languages widely used in server-side game development. "C" is a procedural language, which means that it follows a step-by-step procedure to solve a problem, while "C++" is both a procedural and object-oriented programming (OOP) language. This dual nature of "C++" allows it to handle more complex interrelated data and functions efficiently, which is a beneficial feature in game development. Moreover, "C++" is an extension of "C", meaning that any legal "C" program is also a valid "C++" program. Both languages offer a high degree of control over system resources and memory, making them an excellent choice for building fast and efficient server-side applications, such as multiplayer game servers.

src/data/roadmaps/server-side-game-developer/content/105-programming-languages/101-c-sharp.md

@@ -0,0 +1,3 @@
+# C#
+
+C Sharp, usually written as C#, is a powerful, object-oriented programming language developed by Microsoft in the early 2000s. C# was designed to be a part of the .NET ecosystem and has its syntax foundations based on C and C++. Over time, C# has evolved to include several modern programming features like generics, asynchronous methods, and support for LINQ queries. Thanks to the .NET Core's cross-platform support, C# can now be used to write applications that run on Windows, Linux, and macOS. While it's widely used to create Windows desktop applications and games, it's also popular for developing web applications, server-side components, and even mobile applications via Xamarin.

src/data/roadmaps/server-side-game-developer/content/105-programming-languages/102-java.md

@@ -0,0 +1,3 @@
+# Java
+
+Java is an object-oriented programming language that is class-based and designed to have as few implementation dependencies as possible. It was originally developed by James Gosling at Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language's syntax has much in common with C and C++, but its object model is simpler and has less low-level facilities. Java applications are typically compiled to bytecode that can run on any Java Virtual Machine (JVM), making Java applications highly portable. Java is a general-purpose programming language and is used widely for server-side applications, particularly in high-performance environments where speed and scalability are critical.

src/data/roadmaps/server-side-game-developer/content/105-programming-languages/103-erlang.md

@@ -0,0 +1,3 @@
+# Erlang
+
+Erlang is a functional, general-purpose concurrent programming language that supports distributed computation. It originated in the late 1980s, born from Ericson Inc., with the aim to improve the development of telephony applications. Erlang has built-in support for concurrency, distribution and fault tolerance which make it a popular choice for developing large scale, real-time systems. The language is mostly used in sectors where systems must continue to work despite errors, such as banking, eCommerce, computer telephony and instant messaging. Over the years, Erlang has been employed in blockchain development, internet of things (IoT) and online gaming programming where robust server-side development is required.

src/data/roadmaps/server-side-game-developer/content/105-programming-languages/104-javascript.md

@@ -0,0 +1,3 @@
+# JavaScript
+
+JavaScript (often abbreviated as JS) is a high-level, interpreted programming language that conforms to the ECMAScript specification. It plays a key role in web development as it is one of the three core languages of the World Wide Web, along with HTML and CSS. In server-side game development, JavaScript can be utilized through runtime environments such as Node.js. Over the years, JavaScript has evolved to incorporate additional features, such as support for object-oriented and functional programming styles. It is dynamically-typed, and supports event-driven programming, which is especially handy in game development for handling user inputs and system events. Despite its name, JavaScript is not related to Java.

src/data/roadmaps/server-side-game-developer/content/105-programming-languages/index.md

@@ -0,0 +1,3 @@
+# Programming Languages
+
+Programming languages are an essential part of game development. They create the logic and rules for how your game operates. There are various types of programming languages that a server side game developer can use, such as C++, Python, Ruby, etc. These languages have different syntax and structures, as well as varying degrees of complexity. The complexity and capabilities can affect the game's performance, security, and even its potential compatibility with other platforms. Your choice of language often depends greatly on the specific needs of the project and your personal expertise. Picking up a new language can be time-consuming, so it's important to choose wisely. Markdown is another language that's popular for documentation due to its simplicity and readability, but it isn't typically used to code server-side game elements.

src/data/roadmaps/server-side-game-developer/content/106-socket-programming/100-byte-manipulation.md

@@ -0,0 +1,3 @@
+# Byte Manipulation
+
+`Byte manipulation`, in the context of socket programming, often refers to the ability to directly interact and manage bytes of data. This could involve creating, modifying, or reading individual bytes or groups of bytes. Common operations include shifting (moving bytes to the left or right), masking (using a binary AND operation to make certain bits 0), and bitwise operations (working with the individual bits within a byte). Byte manipulation commonly takes place in server side game development when dealing with network data or working with specific binary protocols. The ability to accurately manipulate bytes is an essential skill when handling and optimizing the transfer of data between a server and a client.

src/data/roadmaps/server-side-game-developer/content/106-socket-programming/101-address-conversion.md

@@ -0,0 +1,3 @@
+# Address Conversion
+
+In socket programming, address conversion functions are important for handling internet addresses. Functions like `inet_pton()` (presentation to network) and `inet_ntop()` (network to presentation) are frequently used. `inet_pton()` function converts an IP address in human-friendly format (IPv4 addresses in dotted-decimal notation or IPv6 addresses in hexadecimal notation) to its equivalent binary form. Conversely, `inet_ntop()` function does the reverse, i.e., it converts an IP address in binary form to human-friendly format. These functions are important tools when dealing with IP addresses in lower-level network programming.

src/data/roadmaps/server-side-game-developer/content/106-socket-programming/102-descriptor.md

@@ -0,0 +1,3 @@
+# Descriptor
+
+In the context of socket programming, a **descriptor** is simply an identifier for a resource. With the use of these descriptors, socket applications can interact with system resources such as network connections, files, or data streams. For instance, in C-based languages such as C++, socket programming frequently makes use of file descriptors. These are integer values used by the operating system to identify open files and network sockets. It is crucial for a server-side game developer to understand and make efficient use of descriptors to control and manage all the network protocols, ensuring seamless game experiences.

src/data/roadmaps/server-side-game-developer/content/106-socket-programming/103-api/100-bsd-socket.md

@@ -0,0 +1,3 @@
+# BSD Socket
+
+The BSD sockets API is an application programming interface (API) for network communication originally developed as part of the Berkeley Software Distribution (BSD). This API provides a set of functions for creating and manipulating network sockets in operating systems. It has been widely adopted in a variety of platforms due to its simplicity and ease of use for networking tasks. The BSD socket API supports various network protocols and is extensible to support new protocols. It allows low-level access to network services, with the facilities to manage connections, send and receive data, and handle multiple connections concurrently. The API supports both connection-oriented (TCP) and connectionless (UDP) network protocols.

src/data/roadmaps/server-side-game-developer/content/106-socket-programming/103-api/101-winsock.md

@@ -0,0 +1,3 @@
+# Winsock
+
+`Winsock` is an acronym for Windows Sockets API, a technical specification that defines how networking software should interact with TCP/IP network protocols, such as TCP, UDP, and ICMP, on a Windows Operating System. Essentially, Winsock provides an interface for developers to use when they need to write network applications. This API provides functionalities to create a socket, bind it to a specific address, listen to incoming connections, send and receive data, and finally, close the connection. Winsock also aids in handling network errors and exceptions. For developing multiplayer server-side games, it is useful in managing client-server communications, multiplayer logic, and real-time updates. Note that in the gaming context, the Winsock library is typically used for real-time, high-performance applications due to its low-level access to the TCP/IP stack.

src/data/roadmaps/server-side-game-developer/content/106-socket-programming/103-api/index.md

@@ -0,0 +1,3 @@
+# API
+
+API (Application Programming Interface) is a set of rules and protocols implemented for building and integrating software applications. APIs enable two different software applications to communicate and work together. They work as a bridge connecting two software systems, enabling them to exchange information and execute functions. In the context of server-side game development and socket programming, APIs may be used to handle connection establishment, data transmission, and other necessary network communication operations. APIs can be customized or built based on standard protocols such as HTTP for web services, or TCP/UDP for lower-level socket communications.

src/data/roadmaps/server-side-game-developer/content/106-socket-programming/index.md

@@ -0,0 +1,3 @@
+# Socket Programming
+
+Socket programming is a method of communication between two computers using a network protocol, typically TCP/IP. In server-side game development, socket programming is used to facilitate real-time, bi-directional communication between the server and client(s). The server opens a socket that waits for incoming connection requests from the client side. Once a connection is established, the server and client can exchange data until the connection is closed. This facilitates live multiplayer gaming experiences, allowing users on different computers to interact within the same game environment.```socket programming``` in Python, for example, includes modules for creating both the server side (```socketserver```) and client side (```socket```) of the conversation.

src/data/roadmaps/server-side-game-developer/content/107-serialization/100-json.md

@@ -0,0 +1,3 @@
+# JSON
+
+**JSON (JavaScript Object Notation)** is a lightweight data-interchange format that is easy to read and write for humans, also easy to parse and generate for machines. JSON is a text format that is completely language independent but uses conventions familiar to programmers of the C family of languages, including C, C++, C#, Java, JavaScript, Perl, and Python. In JSON, data is organized in name-value pairs and array data types. It is commonly used for transmitting data in server to web applications and vice versa.

src/data/roadmaps/server-side-game-developer/content/107-serialization/101-xml.md

@@ -0,0 +1,3 @@
+# XML
+
+XML, or Extensible Markup Language, is a language designed to store and transport data without being dependent on a particular software or hardware. Unlike HTML which displays data and focuses on how data looks, XML works as a tool to transfer data and emphasizes on what the data is. XML data is known as self-describing or self-defining, as it has the ability to define and describe the structure and data types itself. It uses tags just like HTML, but the tags in XML are not predefined; it allows the author to define his/her own tags and document structure. XML also supports Unicode, allowing almost any information in any human language to be communicated. It adheres to a strict syntax and is both human-readable and machine-readable, making it a widely used standard in web and server-side development.

src/data/roadmaps/server-side-game-developer/content/107-serialization/102-yaml.md

@@ -0,0 +1,3 @@
+# YAML
+
+YAML, which stands for "YAML Ain't Markup Language," is a human-readable data serialization standard that can be used in conjunction with all programming languages. It is often used to write configuration files and in applications where data is being stored or transmitted. YAML supports advanced features like referencing, merging, arrays and dictionaries. Also, it is flexible and supports various data structures like scalars, sequences, associative arrays. Though it might seem similar to JSON and XML, it focuses on data serialization rather than marking up documents, and ensures readability for humans. It uses a whitespace indentation to denote structure, which can simplify file format complexities.

src/data/roadmaps/server-side-game-developer/content/107-serialization/103-toml.md

@@ -0,0 +1,3 @@
+# TOML
+
+`TOML`, which stands for Tom's Obvious, Minimal Language, is a configuration file format that is easy to read due to its straightforward and simple syntax. The language is designed to be unambiguous and lean, intending to make it easy for a machine to parse. It supports basic data types, such as Integer, String, Boolean, and Float, Date-Time, Array, and Table. Unlike other similar file formats, `TOML` provides a more structured hierarchy. You can use `TOML` for configuration, serialization, and other similar tasks in game development.

src/data/roadmaps/server-side-game-developer/content/107-serialization/104-protobuf.md

@@ -0,0 +1,3 @@
+# Protobuf
+
+`Protobuf`, or Protocol Buffers, is a method developed by Google for serializing structured data. It's both language-neutral and platform-neutral. Google designed it to be smaller and faster than XML. You design your data structures in `.proto` files, then use the Protobuf compiler `protoc` to generate data access classes in your chosen language. Google provides support for several languages including: Java, C++, Python, Objective-C, and C#. Community developed support for even more languages is also available. This gives `protobuf` a great deal of versatility, making it a popular choice for data storage and communication between services.

src/data/roadmaps/server-side-game-developer/content/107-serialization/index.md

@@ -0,0 +1,3 @@
+# Serialization
+
+Serialization in server-side game development is the process of transforming data objects or structures into a format that can be stored, transmitted, and reconstructed later. It's significant because it enables you to save the state of a game, pass it between servers, or send it to clients. The two main types of serialization are binary and XML/JSON. Binary serialization turns your objects into a very compact binary format. XML/JSON serialization turns your objects into a textual format, which is less efficient but more human-readable and easier to debug. Depending on your specific needs, you may choose one over the other. Note also that each of these methods has its own exacerbations in terms of compatibility, performance, and security implications.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/100-thread-localstorage/100-windows.md

@@ -0,0 +1,3 @@
+# Windows
+
+In the context of server-side game development, Windows operating system offers an API for Thread Local Storage (TLS). This refers to a mechanism by which variables are allocated that are unique for each thread in a program. When a thread reads from or writes to a TLS index, it is actually referencing a thread-specific memory block. This memory block is dynamically allocated from the system heap when the thread is created and subsequently freed up when the thread is terminated. This management of memory is done implicitly by the system which can reduce complexity for developers.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/100-thread-localstorage/101-pthread.md

@@ -0,0 +1,3 @@
+# pthread
+
+`Pthread` or POSIX threads is a standard-based thread programming library for multi-threading development. It provides several functions and methods to efficiently manage multiple threads in a program enhancing concurrency and parallelism. The library enables thread creation, thread joining and cancellation, thread-specific data, and synchronization including mutex locks, read/write locks, and condition variables. Notably, Pthread is an API for C/C++ programming language providing cross-platform support for Linux, Unix, and Windows systems. It's a fundamental tool for server-side game developers to create highly responsive and concurrent applications.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/100-thread-localstorage/index.md

@@ -0,0 +1,3 @@
+# Thread Local Storage
+
+`Thread Local Storage (TLS)` is a mechanism by which variables are allocated such that each thread gets its own individually allocated variable, but the name of the variable is the same in each thread. In other words, the same variable can simultaneously hold different values for different threads. TLS is required when you need to use a global or static variable in a thread-safe manner but the data must be unique to each thread. TLS can be used in many applications, but it is particularly useful for storing per-thread state in server applications.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/101-sharding.md

@@ -0,0 +1,3 @@
+# Sharding
+
+Sharding is a type of database partitioning that separates very large databases into smaller, faster, more easily managed parts called data shards. The word shard means a small part of a whole. Each shard is held on a separate database server instance, to spread load and reduce the risk of a single point of failure. Sharding can be done on a horizontal or vertical basis. Horizontal Sharding, also known as data sharding, involves putting different rows onto different tables. Vertical Sharding, on the other hand, involves putting different columns onto different tables. It's possible to shard on the basis of certain columns, and databases can be sharded in many different ways. Sharding is a complex process, but proper planning can allow for increased scalability and performance improvements.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/102-fiber.md

@@ -0,0 +1,3 @@
+# Fiber
+
+`Fiber` is a way to manage concurrency at a more granular level than threads. While threads represent a sequence of instructions that can run concurrently with other threads, a fiber is a unit of execution which only runs on its initiating thread. Fibers are scheduled by the application, not the operating system. They are great tools for implementing co-operative multitasking where you have many tasks that you want to have run concurrently, but you want to have explicit control on when they are switched in and out. For server-side game development, fibres can be particularly useful in dealing with multiple user requests, where each request might have its own fiber.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/100-barrier.md

@@ -0,0 +1,3 @@
+# Barrier
+
+`Barrier` in server-side game development refers to a type of synchronization method that can help manage multiple threads in a game's code. When a barrier point is set, all threads that reach this point are prevented from progressing until all the threads have reached this barrier. This functionality is a crucial aspect in synchronization to prevent inconsistencies and unsynchronized access to shared resources. It allows developers to ensure all processes are completed or all information is updated before moving on to the next step in the game's runtime. Barriers can be applied in various instances such as, but not limited to, game start-up, level completion, or during more complex inter-thread communications.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/101-spinlock.md

@@ -0,0 +1,3 @@
+# Spinlock
+
+`Spinlock` is a type of synchronization mechanism that exists in a busy-wait-state (essentially, 'spinning') until the lock can be acquired. This contrasts with other locking mechanisms that might put a thread to sleep if the desired lock is not available. It's generally used in scenarios where thread sleeping (context switching) could be costlier than spinning. However, it must be handled properly. An improperly managed spinlock can cause high CPU usage, as the wait is active; it continually consumes processing capacity. Hence, their usage is more beneficial in scenarios where the wait time to acquire a lock is reasonably short.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/102-mutex/index.md

@@ -0,0 +1,3 @@
+# Mutex
+
+`Mutex`, short for mutual exclusion, is a synchronization method used by developers to prevent multiple threads from concurrently accessing some shared resource or part of code. It is a locking mechanism that enforces limits to ensure that only one thread can perform certain operations at a time. If a `mutex` is locked by one thread, the other threads trying to lock it will be blocked until the owner thread unlocks it. This tool is essential especially in multi-threaded programming environments to avoid conditions like race conditions where the program's behavior may depend on the sequence of scheduling or timings of the threads.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/102-mutex/semaphore.md

@@ -0,0 +1,3 @@
+# Semaphore
+
+A **semaphore** is a more advanced type of synchronization tool compared to mutexes. While a mutex is either locked or unlocked, a semaphore has a count associated with it and can allow multiple threads to access a resource up to a specified count. Semaphores can be used to control access to a pool of resources, not just a singular resource like a mutex. A semaphore count represents the number of resources available. Each time a thread acquires the semaphore, the count decreases. When the count hits zero, any further threads that attempt to acquire the semaphore are blocked until the count becomes positive again. Release operation increments the count, and possibly unblocks waiting threads. The key detail is that semaphores allow multiple threads to access a resource concurrently, but with a defined maximum number of concurrent threads.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/103-condition-variable.md

@@ -0,0 +1,3 @@
+# Condition Variable
+
+A `condition variable` is an object that has the ability to block the calling thread until notified to resume. It's used in conjunction with a `mutex` (or `lock`) in the synchronization of threads. A condition variable is made up of a mutex (or lock) and a waiting queue. Typically, a condition variable is used when a thread needs to wait until a certain condition is met. The thread will lock the mutex, check the condition, and if the condition isn't met, it will enter the waiting queue and unlock the mutex. When the condition is met, another thread will notify the condition variable, prompt it to wake up a thread from the waiting queue, and relock the mutex. It's important to mention that condition variables are subject to spurious wakeups and lost wakeups, hence developers need to manage them carefully.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/104-future-promises/channel.md

@@ -0,0 +1,5 @@
+# Channel
+
+### Channel
+
+In server-side game development, a **Channel** is used to simplify network coding by providing an efficient and reusable way to send and receive data. Essentially, a channel is a communication pipeline between a client and a server. They are often used in real-time multiplayer games where fast and frequent data transfer is essential. These channels can be implemented using different protocols, the choice of which usually depends on specific game requirements and usage scenarios. For example, TCP channels may be used for reliable data transfer, while UDP channels may be more applicable for fast, unordered data delivery.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/104-future-promises/coroutine.md

@@ -0,0 +1,3 @@
+# Coroutine
+
+A **Coroutine** is a special kind of function that has the ability to pause its execution while saving its local state. Unlike standard functions which start at their beginning when called and run to completion, coroutine can start, pause at any point of its execution, and then resume from the same point later. This pause and resume functionality, makes coroutines a great tool for writing asynchronous code and managing activities that are typically difficult to deal with in procedural programming such as time-dependent or event-driven operations. Coroutines are commonly used in server-side development for tasks like handling concurrent requests without the need for creating multiple threads or processes.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/104-future-promises/index.md

@@ -0,0 +1,3 @@
+# Future & Promises
+
+`Futures and promises` or simply `Promises` in programming is a pattern used for handling asynchronous operations. A `Promise` is an object that might produce a single value or error in the future either through a non-blocking way or in an asynchronous way. A `Promise` has three states - pending, resolved (success), and rejected (error). The Promise transitions from the Pending state to either an accomplished Resolved state, or Rejected state. These status changes are irreversible, meaning once the Promise reaches either Resolved or Rejected state, it cannot transition to any other state.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/103-synchronization/index.md

@@ -0,0 +1,3 @@
+# Synchronization
+
+In the context of multithreading, **synchronization** is a mechanism which ensures that two or more concurrent threads don't simultaneously execute some particular program segment known as a critical section. Concurrent accesses to shared resource can lead to race conditions. Two or more operating systems' threads can access shared data simultaneously. With synchronization, you can ensure that only one thread can access the shared resource at a time, hence avoiding any data inconsistency. Different synchronization techniques such as locks, semaphores, condition variables, monitors and signaling are used to deal with synchronization situations, each with its own pros and cons.

src/data/roadmaps/server-side-game-developer/content/108-multithreading/index.md

@@ -0,0 +1,3 @@
+# Multithreading
+
+Multithreading, a specialized form of multitasking, is the ability of a central processing unit (CPU) to manage multiple executions of instructions concurrently. This essentially means that multiple threads or mini-processes are executing independently yet sharing the resources of a single CPU. In programming, threads are a way to improve the application responsiveness and perform multiple operations simultaneously without requiring multiple CPUs or computers. Threads within a process share the same data space with the main thread and can, therefore, communicate more quickly with each other than if they were separate processes. Developers often use multithreading in server-side game development to manage complex operations with high efficiency.

src/data/roadmaps/server-side-game-developer/content/109-programming-techniques/100-design-patterns.md

@@ -0,0 +1,3 @@
+# Design Patterns
+
+Design Patterns represent best practices developed by experienced software engineers. They are reusable solutions to common problems that occur in software design and fulfill the requirement to decouple the system as much as possible. Design patterns categorize into Creational, Structural, and Behavioural types. Creational type includes patterns like Singleton, Prototype and Factory; Structural includes Adapter, Composite, and Proxy; Behavioural includes Observer, Strategy, Template, and Visitor. Every design pattern has its own particular structure defined that programmers can follow to solve a particular design problem in your programming code.

src/data/roadmaps/server-side-game-developer/content/109-programming-techniques/101-tdd.md

@@ -0,0 +1,3 @@
+# TDD
+
+`Test Driven Development (TDD)` is a development strategy in which developers write tests before writing the bare minimum of code required for the test to be passed. The process involves three stages: red, green, and refactor. In the red phase, a test is written which initially fails (since the code it's testing doesn't exist yet). In the green phase, the minimal amount of code to make the test pass is created. Lastly, in the refactor phase, the written code is improved without affecting its behavior. The process is often visualized as a cycle: "Red - Green - Refactor". This repeating process allows for smaller, more defined feature development, reduces bug emergence, and encourages simple design. TDD is primarily used in agile development environments.

src/data/roadmaps/server-side-game-developer/content/109-programming-techniques/102-dependency-injection.md

@@ -0,0 +1,3 @@
+# Dependency Injection
+
+`Dependency Injection` (DI) is a programming technique that makes a class independent of its dependencies. This is achieved by decoupling the use of an object from its creation. In this technique, instead of a class creating an object itself, an object is supplied or "injected" to the class by an external entity. The actual creation and binding of dependencies are managed by a 'container', which injects the dependencies into the respective classes. Dependency Injection can be done in three ways: Constructor Injection, Setter Injection, and Interface Injection. Each of these methods involves moving the responsibility of the object creation and binding to another class or method.

src/data/roadmaps/server-side-game-developer/content/109-programming-techniques/103-dump-analysis.md

@@ -0,0 +1,3 @@
+# Dump Analysis
+
+**Dump Analysis** is a highly useful technique in server-side game development, primarily used for debugging and troubleshooting. It involves studying the 'dump' or all the information within a system when a program crashes or fails. This dump typically includes the system's memory, the active processes, thread stacks, and more. By analyzing this data, developers can get an insight into what caused the failure. Dump analysis can be manual, using debuggers like WinDbg, lldb, gdb, or automated with tools such as Microsoft's Automatic Debugging Tool (ADPlus) and DebugDiag. Note that the complexity of dump analysis can vary depending on the nature of the program crash or the size of the dump.

src/data/roadmaps/server-side-game-developer/content/109-programming-techniques/104-functional-programming.md

@@ -0,0 +1,3 @@
+# Functional Programming
+
+`Functional programming` is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. In functional programming, functions are first-class citizens. This means that functions can be passed as arguments to other functions, returned as values from other functions, and assigned to variables. Examples of functional programming languages include Haskell, Lisp, and Scala. At the heart of functional programming are the concepts of immutability and pure functions. A pure function is a function that provides the same output for the same input and has no side effects. Immutability avoids changes to variables or objects once they've been created, which makes functional programs easier to debug and test.

src/data/roadmaps/server-side-game-developer/content/109-programming-techniques/index.md

@@ -0,0 +1,3 @@
+# Programming Techniques
+
+Programming techniques are methods that are used to write series of instructions (code) that a computer can interpret and execute. There are many ways one can write code, unique to both the individual and the programming language they are using. Techniques such as Object-Oriented Programming (OOP) involve the use of encapsulated objects and inheritance. Functional Programming focuses on mathematical functions, avoiding changes in state and mutable data. Procedural Programming focuses on the process of executing predefined steps of functions to achieve the end result, while Event-Driven programming primarily acts upon user interactions, like mouse clicks or key presses. You can choose one technique depending on the game development requirements, the development team's competence, and preference.

src/data/roadmaps/server-side-game-developer/content/110-databases/100-rdbms/100-mssql.md

@@ -0,0 +1,3 @@
+# MS SQL Server
+
+Microsoft SQL Server (MSSQL) is a relational database management system (RDBMS) developed by Microsoft. MSSQL provides an environment used to generate databases that can be accessed from workstations, the internet, or other media such as a personal digital assistant (PDA). Basically, MSSQL is a server-based SQL repository that provides back-end storage for applications. It supports a wide variety of transaction processing, business intelligence and analytics applications in corporate IT environments. MSSQL has various editions with different features to fulfill users' requirements, ranging from a free edition, Express, to the comprehensive Enterprise edition.

src/data/roadmaps/server-side-game-developer/content/110-databases/100-rdbms/101-mysql.md

@@ -0,0 +1,3 @@
+# MySQL
+
+MySQL is an open-source relational database management system (RDBMS) that uses SQL (Structured Query Language) to interact with data. It is developed, marketed, and supported by MySQL AB, a Swedish company, and is written in C and C++. Since it's open-source, you can use MySQL completely free of charge. MySQL is primarily used for online transactions and for consolidating data. You can install it on various platforms like Linux, Windows, Mac OS and so on. With its comprehensive set of features like support for full-text search, cursors, triggers, stored procedures, it is powerful enough to manage even very large sets of data, making it suitable for a vast range of applications, whether they be web-based or embedded.

src/data/roadmaps/server-side-game-developer/content/110-databases/100-rdbms/102-postgresql.md

@@ -0,0 +1,3 @@
+# PostgreSQL
+
+**PostgreSQL** is a powerful, open-source object-relational database system. It extends the SQL language combined with many features that safely store and scale the most complicated data workloads. The origins of PostgreSQL date back to 1986 as part of the POSTGRES project at the University of California at Berkeley. It has earned a strong reputation for its proven architecture, reliability, data integrity, robust feature set, extensibility, and the dedication of the open-source community behind the software to consistently deliver performant and innovative solutions. PostgreSQL runs on all major operating systems and has been ACID-compliant since 2001. It has powerful add-ons like the popular PostGIS geospatial database extender. It can handle ranges, array types and has extensive capabilities for developing at scale.

src/data/roadmaps/server-side-game-developer/content/110-databases/100-rdbms/index.md

@@ -0,0 +1,3 @@
+# RDBMS
+
+**RDBMS** or **Relational Database Management System** is a type of database management system that stores data in the form of related tables. These tables are interconnected via relational operators. Each row in these tables has an unique identifier known as its **Primary Key**, and the data can be accessed or reorganized in many different ways without needing to reorganize the tables themselves. **Structured Query Language (SQL)** is the standard language used for interfacing with RDBMS. Notable RDBMS examples include Oracle Database, MySQL, Microsoft SQL Server, and PostgreSQL.

src/data/roadmaps/server-side-game-developer/content/110-databases/101-nosql/100-dynamo-db.md

@@ -0,0 +1,3 @@
+# Dynamo DB
+
+DynamoDB is a NoSQL database service provided by Amazon that delivers reliable performance at any scale. It's a fully managed, multiregion, multimaster database that offers built-in security, backup and restore, and in-memory caching. It's meant to support applications with large scale, low latency requirements. Developers can create database tables that can store and fetch any amount of data and can serve traffic from a few requests per month to millions of requests per second. As a part of AWS, DynamoDB integrates well with other AWS services and provides developers with high availability across multiple geographical regions.

src/data/roadmaps/server-side-game-developer/content/110-databases/101-nosql/101-mongodb.md

@@ -0,0 +1,3 @@
+# MongoDB
+
+MongoDB is a source-available NoSQL database program that uses a document-oriented database model. This model supports a variety of data types and enables you to store them in one place. MongoDB uses JSON-like documents coupled with optional schemas. What distinctly characterizes MongoDB is its scalability and flexibility that allow schemas to evolve with business needs. It can run over multiple servers, the data is duplicated to facilitate keeping the system up and the data available. Also, MongoDB supports rich queries through its powerful querying and aggregation tools. These capabilities encourage fast development and iterations. However, bear in mind that like any database, MongoDB is not a one-size-fit-all solution and understanding its best use cases is crucial for maximizing its benefits.

src/data/roadmaps/server-side-game-developer/content/110-databases/101-nosql/102-cassandra.md

@@ -0,0 +1,3 @@
+# Cassandra
+
+Apache Cassandra is an open-source, distributed NoSQL database system that is designed to manage large volumes of data across a wide range of servers. It provides high availability with no single point of failure. Cassandra is often used for applications where data is distributed across multiple locations as it has superior replication mechanisms. It utilizes a peer-to-peer architecture, as opposed to master-slaves, which allows for continuous availability and scalability. Cassandra also provides robust support for clusters spanning multiple datacenters, with asynchronous masterless replication allowing low latency operations for all clients.

src/data/roadmaps/server-side-game-developer/content/110-databases/101-nosql/103-couchbase.md

@@ -0,0 +1,3 @@
+# Couchbase
+
+Couchbase is a NoSQL database technology that provides flexible data models suitable for server-side game development. It provides high-performance and easy scalability, offering a comprehensive platform for managing, manipulating and optimizing data in real-time. The technology behind Couchbase combines the powerful performance of key-value stores with the flexible querying capabilities of SQL-like querying systems. This makes it particularly valuable in gaming environments where performance and flexibility are crucial. Moreover, Couchbase also provides document database capabilities, allowing for complex documents to be stored in a format that can be easily manipulated for individual needs. With its high performance, flexible querying, and document database capabilities, Couchbase is a powerful tool for server-side game developers, and mastering it can significantly enhance your development capabilities.