Before actions can be processed (#162), we need to make Votefinder aware of role archetypes. After some discussion, a proposed structure:
PlayerState: role_name, archetyperole_name: a freeform text field to allow for colloquialisms / dialectical differences across moderators or forum communities
archetype: explained below
Archetype: title, description, num_targets
best explained by example:
title: Investigatordescription: Commonly "Cop" or "Seer", can investigate another player per night and determine that player's alignment.num_targets: 1
RoleAction: playerstate, gameday, targetplayerstate: tied to above - so to a specific player and game ID
gameday: self-evident - an action a day~
target: targeted playerstate by ID
Question: How would we handle stuff like bus drivers who have two targets? How do we make this okay in the database? This is where if we were in nosql we could just have an array or whatever as a property of a stored object but like, we aren't, and we shouldn't be!
we do not yet have to implement action logic, that's a separate thing! some of this is groundwork for that. but this would allow us to set this up with appropriate groundwork.
We still need to ensure that we've addressed this as the correct path forward, and that we're designing correctly.
Before actions can be processed (#162), we need to make Votefinder aware of role archetypes. After some discussion, a proposed structure:
PlayerState
:role_name
,archetype
role_name
: a freeform text field to allow for colloquialisms / dialectical differences across moderators or forum communitiesarchetype
: explained belowArchetype
:title
,description
,num_targets
best explained by example:title
:Investigator
description
:Commonly "Cop" or "Seer", can investigate another player per night and determine that player's alignment.
num_targets
:1
RoleAction
:playerstate
,gameday
,target
playerstate
: tied to above - so to a specific player and game IDgameday
: self-evident - an action a day~target
: targeted playerstate by ID Question: How would we handle stuff like bus drivers who have two targets? How do we make this okay in the database? This is where if we were in nosql we could just have an array or whatever as a property of a stored object but like, we aren't, and we shouldn't be!we do not yet have to implement action logic, that's a separate thing! some of this is groundwork for that. but this would allow us to set this up with appropriate groundwork.
We still need to ensure that we've addressed this as the correct path forward, and that we're designing correctly.