physics comments:
set stone ids as (team, stone_number) the back and sidelines should not be colliders because stones are out as soon as they touch those boundaries stop scaling the weight,…
stone trajectory data structucture should be called trajectories with shape something like {stones: [{stoneid, rotation, team, trajectory:[x,y,theta]}])
zoom out a bit so you can see the sidelines. the backline of the house only needs to be visible just above the controls.
active stones don't need to be distinct from inactive stones. they can be all be active unless they go out of bounds
on the frontend, use a skeumorphic HUD to display how many stones are left. for instance, at the start of the game, show 2 rows of 8 stones. a stone should be removed from the hud when it is thrown.
at the completion of an end, show a modal with the points scored, who has hammer next, and the updated scoreboard
don't specify stone color here, just team1 or team2, allow generalizability to choose colors. for now we will default to red and yellow
instead of a score. call it scoreboard. for each end, specify team with hammer, score for team1, score for team2. show this scoreboard on the frontend. this allows the hammer and turn_team variables to go away.
remove this, there should not be a way to have a full room. all anyone to join and choose a team. teams may have multiple clients
zoom out a bit so you can see the sidelines. the backline of the house only needs to be visible just above the controls