kolodziejczak-sz / delayed-board Goto Github PK

Now project structure is type-centric which is simple but not comfortable to work with.

aktualnie jest tak, ze bufferSize nie jest uwzgledniany, pozycja graczy jest losowa a gre zaczyna zawsze gracz pierwszy.

jak powinno to wyglądać (opis dla 2 graczy):

1. kolejność kto zaczyna jest losowana (utils/number jest funkcja do generowania losowych liczb)

2. wybór pozycji turowo. mozna do tego wykorzystać i rozszerzyć komponent board
   2.1 pierwszy gracz wybiera pozycje
   2.2 drugi gracz widzi wybrana pozycje pierwszego, wybiera swoją (wybrana pozycja musi być wolna)

3. wypelnienie bufora turowo. karty, którymi gracze mogą zapełnić bufor to ich własne, skład talii każdego gracza definiuje plik constants/settings deckComponents. Mozna wykorzystać komponenty cards, buffer, card w nowym kontekście.
   3.1 gracz pierwszy ma za zadanie wypełnić swój bufor swoimi kartami (constants/settings buforSize). domyslnie rozmiar bufora to 5 (mozesz zmienic), gracz musi więc wybrać pięć kart i zatwierdzić wybór. kolejność kart jest ważna więc dobrze zeby wybór można było zmienić przed zatwierdzeniem.
   3.2 gracz drugi wybiera karty i zatwierdza

4. stan aktualny (to już jest), gra turowa. gdy każdy wybierze karte z bufora zdejmowana jest ostatnia i wykonywana. Karta, która jest wyjmowana z bufora po wykonaniu wraca do gracza i może być wykorzystana ponownie.

Player ma dwie listy: cards i buffer.

wykonanie ruchu przez gracza to przeniesienie wybranej karty z kolekcji cards do kolekcji buffer.

egzekucja ruchu to wybranie ostatniej karty z buffera, realizacja ostatniej karty i przeniesienie jej do kolekcji cards.

~
game.state.roundCounter = licznik rund. runda kończy się wtedy kiedy każdy z graczy włoży do buffer 1 kartę.

game.state.roundMoves = licznik ruchow podczas rundy. jezeli roundMoves === activePlayers.length, wtedy runda się skończyła

game can end in a draw. the field 'winner' and it's handlers supposed to change

1. Console is being bloated by custom logger
2. It's inconvenient compared to browser extension

This will be needed especially after #6 merge - we will have a lot more (small) state changes.

Logic inside handlers has some serious drawbacks:

1. It's harder to track changes, when they "all" occure at once -> e.g. onMove handler
2. 'It's harder to test these changes, cause lot's of data is involved
3. We can't dispatch action from handler in response to particular change, cause we're already in reducer.

new scene called like settings to edit the variables from constants/settings file