-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add optional server component to coordinate games #68
Comments
I want to tackle this (but probably not for a few months). I'll start out with the simple version and then try to write the more server-dependent version if no one is working on it by then. I think it would be good to have both implementations available. |
I've been thinking about this a bit and I don't think I care about the backend technology. The thing I want to make sure we get right is the interface with the backend so it's possible to have multiple backend implementations. What are you envisioning that interface will look like? |
I don't have any experience building backends, so I'm not really sure how to write such an interface yet. (Part of the reason I want to give myself a few months is to spend a good chunk of time exploring this area before making a serious attempt). I apologize if any of the following is super uninformed: I'm thinking the interface (for the simple server, at least) would be a RESTful API that represents the game id, current player, current turn, and the board. I'm guessing you wouldn't need to represent moves if they're entirely handled client-side? Users should also be able to search for other users who are searching for a new game, so something like |
A RESTful interface sounds reasonable on the server side, but there's also the client side interface to think about. I'd like to be able to plug in multiple server implementations (RESTful or otherwise) into a single client side interface. Right now I'm thinking these server implementation will function as a type of "player" (similar to the way AI works). I'm thinking through some of this now because it has some relevance for the CLI interface too (game logging will probably also happen through a "player"). I'll update this issue as I get more ideas and make modifications for the CLI. Also, on the server side, it might be useful to try specking out your interface with OpenAPI. That might help you think through all the resources and methods, and would be useful for further design review. |
A simple version of this would just serialize the game state and store it in a key value store. A more complex version would keep track of actions and support replay. An even more complex version would evaluate game logic on the server side to prevent cheating. Whatever eventually gets implemented, it should always be optional since the desire for simple hosting requirements is one of the main reasons Zetawar exists in the first place.
The text was updated successfully, but these errors were encountered: