search

mibpl / go

3 stars 0 forks source link

Opis API #7

Closed neojski closed 11 years ago

neojski commented 11 years ago

Napisałem radośnie renderowanie kamieni, które wyświetlają się po naciśnięciu planszy. Jestem świadomy, że to co napisałem odrobinę nie powinno być tak jak jest, ale to prototyp.

Powiedzmy teraz, że użytkownik klika w planszę - kto powinien to obsłużyć? Rozumiem, że to board_view wygeneruje zdarzenie (? - to chyba mierny pomysł), lecz na pewno nie ono powinno się interesować w jakim stage'u jesteśmy czy też który użytkownik zagrywa. Czy nie powinno po prostu poinformować Game, że ktoś próbuje odpalić akcję na kamieniu (i, j) a game - w zależności od tego jaki jest stage i jaki jest użytkownik - zadziała, tzn.: zaaplikuje ruch (dodanie kamienia, usuwanie kamienia w stageII) generując nowy GameState, który zostanie zapamiętany w historii.

Tylko znowuż pytanie co z gnugo?

A może powinien być Player, któremu Game mówi: teraz czekam na Ciebie, podaj mi kamień (a tu masz historię ruchów). A Playerów jest dwu: albo taki, który generuje swoje ruchy przez interfejs użytkownika albo gnugo. Jeśli Game dostanie ruch - decyduje o wszystkim, aplikuje ruch, itd. Wydaje się logicznejsze.

Dodałem do repo jak bym widział Player.

neojski commented 11 years ago

Dodałem do repo jak bym widział Player.

neojski commented 11 years ago

Dodałem do repo jak bym widział Player

mibpl commented 11 years ago

Controller. Ustaliliśmy, że gnugo nie wchodzi do tej iteracji.