Basic Spec

saluk on 2018/10/14 01:29 of Flowing Magic
— edited on 2018/10/14 01:30

Overview

The game will be an asynchronous digital card game. Players will download the client. From there they play the game, which actually takes place on a server. The state of a players game is saved until the game ends, either with a victory or with a player conceding. If both players are connected, it will seem as if the game occurs in real time - though like most card games players take discrete turns, each of which is made up of a series of ordered actions. However, if you connect to a game that you are involved with but had been disconnected, you will see a replay of what happened while you are gone, and can resume your turn.

Client

The client will be written in Kivy. Currently I can build something that works well for OSX or ios. I'm still working on android support - for some reason the build I have has a terrible lag for the touch inputs that really won't fly. I also should be able to do windows pretty easy - just haven't given it a shot yet.

  • Menu for how to get into a game
  • Apply model to graphical interface
  • Animate model state changes into interface
  • Send commands to server based on player input to the interface according to model
Server

The server must handle a series of ongoing games, user accounts, and then state transitions for each game. Since there is no actual synchronous play (it is all discrete state changes) I intend to use a lightweight REST server like hug to manage the networking. The general algorithm looks something like this:

  • Client sends an action command - this is tied to a specific way to change the model
  • Server checks if the player in this state is authorized to make that move
  • Server updates the model
  • Server returns an acknowledgement or an error along with the new model state
  • Clients will also periodically poll for whether the state has updated, and get the new state
Model

The client and server are somewhat dumb in this sense, where the model has the guts of the actual game implemented.

  • Contains some information about the Players involved
  • Contains a Game definition
  • Contains Spaces - these are places that Things can go. Those Things have a Position defined by the Space
  • Spaces contain Things. Things are elements like cards or tokens. Things contain both Static properties and Dynamic properties
  • Each type of object (player, game, space, thing) includes Triggers and Actions
  • Calling an Action is the only way to cause the model to transform. An action results in an updated model, or an error state
The model will exist on the server as well as the client. The client can "look ahead" by attempting to perform Actions and seeing the new state or error cases. This can help with giving feedback to players on what actions are possible in a given board state. Only highlighting cards that they have resources to play for example. In this way, the client can be made slightly more smart - but I can keep scope low by only implementing some of these things as time permits, while still enforcing the rules in a cheat-proof way on the server.

(log in to comment)

Comments

ikanreed on 2018/10/14 03:47:

Ambitious.  Is everything on the server synchronous?  Are you transmitting entire gamestate every change?

saluk on 2018/10/14 07:01:

It's way too ambitious. I can't wait to cut features :) But actually if I can get the model how I like it, the server part is pretty simple. The client is going to be the challenge, and that would be true if I went with a simpler approach.

The change from the client is just a command (one of the actions on an object, with arguments. For instance, player1.deck.draw(1). The response from the server is the entire new state yes. It may also need to include a list of the actions - if there are multiple actions we should animate them one by one so it is clear what is going on. Also, if I support more than 2 players in the future, player 4 will need to see player 1, 2 and 3's moves when they reconnect after missing a day.

The player who is idling (it's not their turn) can poll the server at a low frequency (0.5 Hz?) to determine when there is a new state to download, and also finding out when it is their turn now. (Whose turn it is would be part of the state)