One player game

[MarcoAJanssen]

Oneplayer.zip

In the Zipfile you find a word document explaining the one player game and a Netlogo file where we simulated outcomes with a player who did pretty much making random decisions (I use a zip file since nlogo files are not recognized by Github). I did not include the academic reasoning why we do certain treatments in the word document.

[sgfost]

Some implementation notes:

• Game configuration/treatments should be handled in such a way that:
  1. The distribution of configurations for all played games is roughly even
  2. The distribution of configurations for (at least the first 12) games someone plays is even
• Event card design and UI design should be the 2 main areas to focus on when trying to make the game engaging
• Likely much easier to implement the game client-side since there's no multiplayer to worry about and just send the game state off. How and how often to do this depends on what exactly we are storing and whether recovery is a priority (probably not)

[alee]

@MarcoAJanssen

for Treatment 1: risk vs uncertainty what exactly are we revealing to the player in the "known" condition? The exact state of the event deck, the distribution and composition of the event deck (all possible event cards that could occur and their probabilities or frequencies within the deck), or something in between?

[alee]

also the event deck described in page 2 indicates 20 cards out of 30 possible but later on it seems that there are between 30-40 cards, I assume we should use the later description?

The basic aspect of the model is the deck of event cards that is generated at the start of each simulation.
For a game there are 10 to 20 Life as usual cards (we draw a random value from a uniform distribution).
The next 20 cards are (values are drawn from uniform distributions):
    • Reduce the number of time blocks between 1 and 8 units
    • Increase the number of time blocks between 1 and 8 units
    • Invest at least between 5 and 10 timeblocks into system health
    • Reduce system health between 1 and 10 units (4 cards with randomly drawn numbers)
    • Increase system health between 1 and 10 units (4 cards with randomly drawn numbers)
    • Reduce points gained between 1 and 10 units (4 cards with randomly drawn numbers)
    • Increase points gained between 1 and 10 units (4 cards with randomly drawn numbers)
    • Murphy’s Law, draw 2 more event cards

[MarcoAJanssen]

In the "known" condition, the participants see the card deck like the figure below. This is the risk condition. It is like we do in traditional experiments, flipping a coin or throwing a dice, the participants know the possible outcomes. In the uncertainty condition, the card deck is not known (this is the standard option in POM).

Yes, the later description is correct. Basically, the variation of the number of cards is caused by the number of Life as usual cards that are drawn.

[sgfost]

We've still got a couple options regarding the client-server architecture for this: either using colyseus for an authoritative server, or cutting that out completely and having something like an initial config sent to the client followed by communication back and forth for player actions/events.

Using the colyseus game server almost seems simpler in that we'd want to keep track of game state anyhow to make sure that requests are valid, events get applied correctly, etc. Also the potential for reusable code/already having an example in place for implementation.

@Tkawamura02 @sabrinanel3 Thats my current line of thinking, lmk if you have any thoughts either way

[Tkawamura02]

@sgfost If there's already somewhat of a background with colyseus then I wouldn't mind using that framework! Following your post, I agree with your line of thought

[alee]

• leaderboard with max points earned in a single game run
• rotate through treatments even in defeat
• add solo games to player personal history

[sgfost]

rotate through treatments even in defeat

The logic for picking treatments doesn't distinguish between failed/successful games so this should be the case. One of the things to have tests written for though

[Tkawamura02]

Not sure where to add this but will add here: potential issue with maxRounds?

[sgfost]

Client will normally have a gameover screen before that ticks over but it wouldn't hurt to prevent the round from incrementing before doing the 'end game' routine on the server