-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to client-server #25
Comments
The separation of engine/content would be completely orthogonal to client/server. The content files would probably land in the common library or server land, while the config files would apply to both client and server (probably need to be split into server config and client config). |
Log of an initial design discussion: 10:47 < kosmikus> mikolaj: re client/server: very funny. back when I started LambdaHack as a student project, my |
Rudimentary client-server is done in the dev version. Buggy, changing a lot and still could be more structured and more type-safe, but it works. No network in this version, but communication goes through channels, so it's transparent. To decrease network load, some work will be needed to send diffs of state, not the whole state (and only the diffs legally visible to the particular client). Anyway, the basic structure: player commands, server commands and client commands, where the latter two are sent as messages, seems to make sense and will probably stay that way. |
Server has full game state, clients have Perception, history, etc.. Server performs state changes, clients have AI and UI (both can be enabled or disabled, even partially, e.g., AI for all but 1 member of the party, or full AI control, but display of game board via UI). The clients and the server either run on different threads or in different executables and then communicate via network. Naturally many players and many independent AI parties are then possible.
The text was updated successfully, but these errors were encountered: