Playing a game

This document discusses how a game should run

Connecting

• A client opens up the game and is connected to the server.
• A list of the current games are shown.
• The player can connect to an existing games and is a spectator until the next game begins.
• Alternatively they can start their own game and wait for other participants.
• A maximum of N participants in a room - but for the moment we are focusing on the story of two player action.

Game cycle

Map Selection

A user may choose a map, or a map can be chosen randomly from a set.

Maps will have areas which are inaccessible (e.g. water, forest, etc) to give players opportunities for strategic benefits.

Game start

Each player is assign two or three basic units and positioned on the map a distance from the opponents.

A random player is chosen to start first, and then the order goes based on their position in the list.

Turn start - Options

To keep things simple there are a number of commands each player's can perform during their round.

Move a unit

A unit can move once per round. A unit has a limit on how far they can move - people can not move as fast as transportation, for example. Moving a unit allows a player to take a strategic position in readiness for an attack. Or they may need to retreat if they are under attack.

Order a unit to attack

A unit can attack once per round. Depending on the abilities of the unit - and the weaknesses of the target unit - they damage inflicted may be significant or poor. Some units may have the ability to attack from a distance, and so their ability to attack will depend on the distance they are from the target.

Deploy a new unit

Some matches may allow players to earn resources and increate their armies. If a player has resources, they can create a new unit. This will be available to use in the next round to use.

A unit can move and attack in the same round. The move is always be applied before the attack.

A player plans their moves on their screen and when they are done, the client batches up the actions and sends them to the server to be applied.

A set of moves might look like this:

{
  "gameId":"56c2794f-946e-4fac-b00b-33b284f0b90f",
  "player":"shiftkey",
  "commands":[
    {
      "unitId":1,
      "action":"move",
      "X":10,
      "Y":4
    },
    {
      "unitId":1,
      "action":"attack",
      "X":10,
      "Y":5
    },
    {
      "action":"create",
      "type":"archer"
    }
  ]
}

Edit: I've renamed these fields from "*-id" to "*Id fields to make parsing with dynamic easier.

Process a turn - Service Logic

The service is responsible for handling a user's commands and updating the game.

When the user receives a number of commands, the service side will apply a number of checks to the commands:

• A move is checked to confirm the unit has not moved further than its permitted range, and that the destination is accessible.
• An attack is checked to ensure the target unit is in range. The damage calculation is applied by comparing both units TODO: damage discussion.
• A created unit is added to the game if the user has enough resources.

The service will then generate a set of units which represents have been impacted by that round - and send this data to each client.

EDIT: the service will return units owned by other players - as actions such as attack will impact other players.

The results from the service might look like:

{
  "gameId":"56c2794f-946e-4fac-b00b-33b284f0b90f",
  "player":"shiftkey",
  "units":[
    {
      "unitId":1,
      "type" : "infantry"
      "health" : 90,
      "X":10,
      "Y":4
    },
    {
      "unitId":2,
      "type" : "archer",
      "health" : 100,
      "X":1,
      "Y":1
    }
}

Edit: I've renamed these fields from "*-id" to "*Id fields to make parsing with dynamic easier.

Or if an issue occurred (the first unit has moved succesfully but the create command failed):

{
  "gameId":"56c2794f-946e-4fac-b00b-33b284f0b90f",
  "player":"shiftkey",
  "units":[ {
      "unitId":1,
      "type" : "infantry"
      "health" : 90,
      "X":10,
      "Y":4
    } ],
  "errors" : [	{
		"command" : "create"
		"message" : "You do not have sufficient resources to create a new 'Archer'"
    } ],
      "notifications" : [ ]
}

Edit: I've renamed these fields from "*-id" to "*Id fields to make parsing with dynamic easier.

Handling issues

If an action is invalid (that is, the client tries to do something that the service believes it cannot support), the response from the service will indicate which moves were invalid. The user can choose to retry the move, or drop the invalid moves and finish their turn

Turn end - visualising

Any units which were eliminated in the previous round will be broadcast to all clients, with a zero value for health to indicate that they are no longer active.

The new state of the active player - rather than the deltas - are sent to all clients so they can update their map. The client interprets the results and renders it to the client, using whatever animations and effects they are capable of.

###Destroyed Once a player runs out of units, they are considered vanquished and are spectators until the game is completed. They may choose to leave the game at this point and start a new game.

{
  "gameId":"56c2794f-946e-4fac-b00b-33b284f0b90f",
  "player":"shiftkey",
  "units":[
    {
      "unitId":1,
      "type" : "infantry"
      "health" : 90,
      "X":10,
      "Y":4
    }],
  "errors" : [ {
		"command" : "create"
		"message" :"You do not have sufficient resources to create a new 'Archer'"
  } ], 
      notifications : [
         "aeoth has been eliminated" 
      ]
}

##Game end The game cycle continues to loop until there are 1 or 0 players left alive.