shibagani48

Weekly report July-3, 2024

Added 2024-07-19 10:28:35 +0000 UTC

Hello everyone! Thank you as always for your support. Let's take a look at this week's progress!

Illustration Work Completion and Return to Hellversus

Finally, the long and arduous illustration work is finished, and I'm back to focusing on Hellversus.

Online Implementation Efforts

Although I planned to continue bug fixing this week, I decided to tackle the most significant challenge: online implementation. The workload is enormous, and I currently don't know how to approach it or if it's even feasible. Moreover, I must consider the highly requested rollback system. Despite the difficulties, taking the first step is crucial. I began by studying YouTube videos and articles to build a foundational understanding. As a result, this week was spent on theoretical learning, and I'll share what I've learned in this development report.

Online Multiplayer Mechanics

Online multiplayer comprises two main components: the client, which refers to each player, and the server, which connects multiple clients remotely. The client sends information to the server, which processes the received data from various players and returns the results to each client. There are different patterns for the information exchange between clients, and the optimal one must be chosen based on the game system.

*Information Exchange Patterns:*

1. *Clients exchange only key input information.*

2. *Clients share the state information (coordinates, actions, etc.) of the characters they control.*

3. *The server calculates based on the key information from each client and sends the results to each client.*

While the differences might be subtle, patterns 1 and 2 involve individual calculations on each client's device, which might not always yield the same results. In fighting games, both players must always share the same results, making these patterns unsuitable. Hence, pattern 3, the server-client model, is the target for implementation.

Rollback Mechanism

Many requests for rollback implementation were made when the project started, though I didn't know what rollback was back then. So, what is rollback?

Online communication inevitably involves lag, increasing with the physical distance between players. For instance, you can feel the lag when playing multiplayer with someone from another country. Unlike other games, fighting games require precise and fair results even within 1/60th of a second (called a frame). A single frame delay in attacks can result in one player's attack landing while the other's gets canceled, causing significant damage and a knockout. This can infuriate the losing player, leading to a rage-induced frenzy. Therefore, accuracy within a single frame is crucial for fighting game players.

The ideal scenario is always sharing accurate results with players, but significant lag can prevent the computer from rendering the screen in time. Consequently, the computer calculates based on the currently available client information and displays it on the screen, leading to incorrect results. The key inputs arrive at the server by the time the screen is displayed, ignoring the player's inputs and sharing incorrect outcomes.

This is where rollback comes in. The server uses the later-received key inputs to prepare the correct calculation results, then abruptly displays the correct screen information as if the previous incorrect information never existed. This "rolling back" to the correct result explains the term "rollback." While it might seem visually jarring to suddenly switch to a different screen, human eyes typically can't perceive the change with minor lag.

However, with excessive lag, situations can arise where an attack appears to hit, but the opponent is shown guarding afterward. The attacking player might continue their attack, only to be countered and knocked out. This can lead to another bout of rage. While frightening, rollback is better than not having it, and players should improve their network conditions.

The "GGPO" programming library, freely available and compatible with Unity, helps implement rollback. I acquired it from GitHub to explore its potential.

GGPO Challenges

As a self-taught programmer, I lack formal programming theory knowledge. I usually rely on internet resources for necessary information, but there is scant instructional information about GGPO. Likely, the demand for GGPO is limited to fighting games, leading to minimal benefit from publishing detailed guides. Consequently, the official readme provided little specific implementation guidance. Despite running the included demo, the missing DLL file and non-functional batch file indicated that GGPO is designed for experienced programmers, with learning primarily through source code analysis. Basic net code knowledge is also required, making GGPO currently unusable for me.

Despite this setback, GGPO alone doesn't enable multiplayer functionality. It complements a server-client communication system with rollback functionality. Therefore, I decided to test "photon" for server-client communication before revisiting rollback.

Photon

Photon offers a multiplayer system with a certain level of free usage, providing servers for easy integration and high convenience. I previously experimented with Photon, achieving some functionality but not a complete implementation.

Interestingly, an indie fighting game called "Mer Fight" achieved rollback with Photon and is available on Steam. I previously communicated with the author on Discord, and we might exchange information, which could be beneficial.

Given these factors, Photon presents a promising potential for online implementation. While this week was spent on research, I plan to create a simple online game using Photon next week.