Open djwhitt opened 7 years ago
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)?
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 GET /search/parameters
?
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.