Maze and Multiplayer Mode

Comment 1

The moment we say the site is memory, other people must be able to exist in this memory. The crucial point is that these others will also have their own memory, which means the "other" visible to me and the actual other are inevitably distinct. There can be two versions of the other as I know them: one is the other as a phantom generated by my client, and the other is the other as information received from the server. The other generated by the client can be called a phantom imitating the other person. As for the information about the other received from the server, although it was not generated directly, from an individual's perspective there is no way to know the exact origin of this information (even if it originated from the other person, there is no guarantee it has not been tampered with), so it is also possible to regard this as a kind of phantom.

Comment 2

The moment multiplayer is supported, oneself and others are replicated and exist in as many copies as the number of clients and servers where they exist. What is interesting is that since it is the client that visualizes these entities, if I and others exist in any visualized form, the information about that existence is entirely dependent on the client. As a very simple example, suppose my character has a name that other people can see, and I change this name. Then the following steps proceed in order:

1. My name is modified.
2. The server is notified of the modification.
3. The server provides the modified information to other clients.
4. The client displays the name. Now let us imagine situations where problems occur at each step.

Scenario 1: Error During Name Modification

If a problem occurs during the name modification process, the modification will either fail and revert to the original state, or the program will crash during modification and you will be kicked from the game. In both cases, nothing particularly interesting happens.

Scenario 2: Error While Notifying the Server

If the name is modified on my client but a problem occurs while notifying the server, the modification is applied only locally and is as if nothing happened on the server and other connected clients. Since the server was not affected from the start, the service is safe as long as the client that modified the name does not send data related to the modified name that could spread contamination. On the client that modified the name, the user may see themselves with the modified name, while other clients will see the original name. To prevent issues in such situations, it would be advisable to write defensive logic that checks the name on both the server and client sides. For example, at the moment the client tries to take some action involving the name, it could fetch the server's known name for that character and apply the server's name if the data does not match.

Scenario 3: Error When the Server Notifies Other Clients

This is the case where the server knows the modified name of the character but fails to notify other users. Typically, such a problem is resolved when the other party closes and reopens the client, or takes an action that requires checking the other player's name, at which point the modified name will display correctly.

Scenario 4: Error When the Client Displays the Modified Name

Since it does not affect the service itself, it is not particularly interesting, while simultaneously anything could happen, making it potentially quite interesting. Think of it as creating a mod that lets you arbitrarily change other characters' names as seen only on your client.

Comment 3

Can other people enter a maze that is constantly being regenerated? This would require a very well-designed system.

Coordinate System

It must be possible to synchronize the position of my character with the positions of other characters. For this, the game must be designed so that all players exist on a shared coordinate system.

Regeneration: Logic

In the existing Maze logic, the area "I am not looking at" is regenerated. Then, to extend this game to multiplayer mode, should only the areas that no players are looking at be regenerated? If so, when many players are at a single location, would the map never be regenerated? Furthermore, in the existing logic, newly generated corridors could never overlap with each other, which was possible only because there was a single player. Expanding to multiplayer mode could result in overlapping corridors, and a way to work around this may also need to be devised.

Regeneration: Delay

Thinking about the corridor regeneration problem within a server-client architecture makes things more complex. Previously, the client handled all decisions and generated corridors, but if multiple people are in the same space, it seems better to run the corridor generation logic on the server and distribute the results to clients. The problem, however, is that there can be delay in server-client communication. For the server to calculate corridors, it needs to know the positions and viewing directions of multiple characters. Between the time the server finishes calculating corridors and distributes them to clients, the players' positions and viewing directions may have changed significantly, which can cause problems. In this case, areas that were originally supposed to be modified only when no character was looking at them might suddenly have corridors the user was looking at transform, or in the worst case, the corridor the user was standing on might be removed entirely.