[Story] Create campaign populates a default GameSession

User Story

As a player, I can create a campaign. Doing so generates a linked persistent Game Session that uses the red keep map and has a number of tokens on it.

IMPORTANT

This is another very large story. When working on this, consider doing one of the following

Using tasks

Create a subtask from this story and then branch from it

git checkout -b issue/82-step-1-for-story-48

Merge each completed step into master

Branch for task

Create a subtask from this story and then branch from it

git checkout -b issue/48-step-2-decoupled-campaign-data

Merge each completed step into master

Details

When a campaign is created via the Campaign Management APIs, it should also initialize a base state for a campaign and save it to persistent storage. Currently, this base state is represented by data_demo.js on the front end.

On the back end, we need to store a session template with the map and some default icons (use the existing data_demo.js for reference). We need this template to be copied and linked to a campaign ID when a new Campaign is created. When the front end requests a Live session for that campaign ID, the back end should provide the session template as the initial state.

The front end should request the Live session for each campaign, rather than the Demo live session.

Explicitly out of scope for this story:

  • Persisting further changes to the Game State
  • Limiting visibility of state changes within the campaign (covered by #49 (closed)).

Suggested Steps

The goal of this to help build an API that will allow the server to populate the map. The end result to the user should not change. The following steps will help ensure that these changes do not impact the end user.

At each of these steps, the system NEEDS to be tested to ensure it's still functioning as expected.

  1. Find and document all data used to populate the map and tokens in-game
  2. Build a decoupled data representation of available data. It can be hardcoded in json for this step.
  3. Replace the inline data from step one with a reference to the data made in step two.
  4. Draft an API to fetch campaign data. This API MUST take a campaign ID
  5. Have the campaign data URL return the fake data from step 2
  6. Make sure the campaign ID is sent from the server when a user enters the campaign
  7. console log the campaign id onload of the in-game interface
  8. Replace the reference created in step three with a call to the new campaign data API
  9. Add a step in the create campaign controller to initialize a campaign data object based on the data in step two. Randomize the positions of the tokens in the campaign.
  10. Change the API hardcoded in step five to reference the campaign data initialize
  11. Verify that loading into campaigns shows the correct state - campaign A's tokens should be positioned differently from campaign B, but campaign A's tokens should keep the same position on a reload

Acceptance Criteria

  • After creating a new Campaign, players can click the Play link to go to that campaign's instance of the game session.
  • Clicking the Play link on a different campaign will take players to a different game session instance.
  • Player can load into one campaign, move a token, load into a different campaign, note the token appears to be at its original location and then load into the first campaign and see the token in the new location.
  • Player can load into one campaign, roll a dice, load into a different campaign, note and empty dice log and then load into the first campaign and see the dice he had rolled earlier.

Data concerns

Should the initial game state be stored under the Campaign document, or in a separate document linked by ID? I lean towards the latter, to allow the live session data to be split it into a separate service in the future, but am open to alternatives.

Security concerns

Users should only be able to join the game session if they are an Owner or a Player.

Stages

  • Planned accepted
  • Code Complete
  • Contains tests
  • Documentation updated
  • Contains log changes
  • Analytics included
  • Deployed to edge
  • Announced
Edited by Marc Faulise