Eventually, the core game logic should be separated from the client. This separation is already partly implemented throughout the codebase with things like Thing vs PerceivedThing. The idea is that the server can be running on a different machine, and there should be a network protocol for communication between the two binaries.
The server knows all true information.
The client knows only what is published to it through game events representing the characters sensory awareness. Everything the client knows it should try to convey to the player somehow through the UI.
The swarkland philosophy on client/server design is that any and all information the client gets over the network is fair game for making decisions. This is in contrast to the Minecraft philosophy where the client is given complete information of the ores buried beneath them and it's up to clients to implement line-of-sight limitations so the human doesn't immediately know where all the diamonds are buried. In Legend of Swarkland, the line-of-sight algorithm is implemented in the server, and the client will only be told what the human is allowed to see due to their character's vision capabilities.
This concept of not leaking information to the client extends to every aspect of the game, not just line-of-sight algorithms. For example, the client shouldn't be told about an enemy's mental status effects unless the character is supposed to be aware of them. The client shouldn't be told about an enemy's existence or non-existence unless the character is supposed to know about it. The client shouldn't know about the precise passage of time unless the character is supposed to know about it. Even something as trivial-sounding as hashtable traversal order should not leak to the client (for a number of reasons, but relevant here is) because the client could deduce some things about entity ids, and then deduce things about when entities are added and removed from the table or when the table expands its capacity, or whatever; we don't want that information to leak.
Information leaks are bugs. If information is published to the client intentionally, then the client should communicate the information to the player (if it'd be useful). For example #39 talks about when entity ids should be published to the client and when they shouldn't. If the client should know about an entity's id, then maybe it should display it to the human? or maybe that'd be too much information, idk.
Movitation
The primary motivation for separating the code into two binaries is to make sure there's no information leakage. Currently, in the monolithic binary, there's plenty of opportunities for information leakage bugs. Here's an example.
However, this is going to make developing new features a little harder, so I've been putting this off for a while. Also, the current algorithm for publishing vision information to the client is not well suited for a network protocol. Also, the "full visibility" cheat, which is a very helpful debugging tool, relies on violating the rules about fair information, so we'd need a formal solution to implement that.
It's going to take some effort to implement the client/server separation, and the immediate benefit is rather small. However, this is part of the plan, and I wanted to create this issue to document the motivation, philosophy, intention, etc.
Eventually, the core game logic should be separated from the client. This separation is already partly implemented throughout the codebase with things like
ThingvsPerceivedThing. The idea is that the server can be running on a different machine, and there should be a network protocol for communication between the two binaries.The swarkland philosophy on client/server design is that any and all information the client gets over the network is fair game for making decisions. This is in contrast to the Minecraft philosophy where the client is given complete information of the ores buried beneath them and it's up to clients to implement line-of-sight limitations so the human doesn't immediately know where all the diamonds are buried. In Legend of Swarkland, the line-of-sight algorithm is implemented in the server, and the client will only be told what the human is allowed to see due to their character's vision capabilities.
This concept of not leaking information to the client extends to every aspect of the game, not just line-of-sight algorithms. For example, the client shouldn't be told about an enemy's mental status effects unless the character is supposed to be aware of them. The client shouldn't be told about an enemy's existence or non-existence unless the character is supposed to know about it. The client shouldn't know about the precise passage of time unless the character is supposed to know about it. Even something as trivial-sounding as hashtable traversal order should not leak to the client (for a number of reasons, but relevant here is) because the client could deduce some things about entity ids, and then deduce things about when entities are added and removed from the table or when the table expands its capacity, or whatever; we don't want that information to leak.
Information leaks are bugs. If information is published to the client intentionally, then the client should communicate the information to the player (if it'd be useful). For example #39 talks about when entity ids should be published to the client and when they shouldn't. If the client should know about an entity's id, then maybe it should display it to the human? or maybe that'd be too much information, idk.
Movitation
The primary motivation for separating the code into two binaries is to make sure there's no information leakage. Currently, in the monolithic binary, there's plenty of opportunities for information leakage bugs. Here's an example.
However, this is going to make developing new features a little harder, so I've been putting this off for a while. Also, the current algorithm for publishing vision information to the client is not well suited for a network protocol. Also, the "full visibility" cheat, which is a very helpful debugging tool, relies on violating the rules about fair information, so we'd need a formal solution to implement that.
It's going to take some effort to implement the client/server separation, and the immediate benefit is rather small. However, this is part of the plan, and I wanted to create this issue to document the motivation, philosophy, intention, etc.