Skip to content
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

Open
djwhitt opened this issue Apr 4, 2017 · 4 comments
Open

Add optional server component to coordinate games #68

djwhitt opened this issue Apr 4, 2017 · 4 comments

Comments

@djwhitt
Copy link
Contributor

djwhitt commented Apr 4, 2017

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.

@tbeddy
Copy link
Contributor

tbeddy commented Jan 30, 2018

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.
In this early brainstorming session, I'm wondering if you have strong thoughts about whether to use JVM Clojure or go full CLJS/Node for the backend(s)?

@djwhitt
Copy link
Contributor Author

djwhitt commented Feb 4, 2018

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?

@tbeddy
Copy link
Contributor

tbeddy commented Feb 9, 2018

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 GET /search/parameters?

@djwhitt
Copy link
Contributor Author

djwhitt commented Feb 18, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants