Mikroserwisy - symulacja gry pub/sub

0

Chciałbym zbudować w kilku kontenerach cos na zasadzie rozgrywki strzelających do siebie cowboy-ow.

W skrócie:
Otóż jest np. 5 cowboy-ow ktorzy beda do siebie strzelać - start strzelania w tym samym momencie czasu.
Kowboj nie może strzelać sam do siebie i nie może strzelać do zabitego już kowboja. Kazdy kowboj ma inne obrazenia i inne zycie juz na starcie rozgrywki.
Po oddaniu strzalu kowboy czeka 1 sekunde w sensie nie moze strzelac od razu tylko po 1 sekundzie.

Kombinuje kombinuje i przekombinowalem;
Wiec mam np. 5 klientów (cowboye) i server rozgrywki. Zeby powiadamiac cowboyow do strzalu w tym samym czasie pomyslalem ze moga nasluchiwac konkretnego 1 kanalu z Redis-a (chyba to taki PubSub mozna to tak nazwac). Zas cowboye wysylaja zwykle requesty HTTP po API do serwera.

Wiec kowboje mi sie zglaszaja na starcie rozgrywki na serwerze przez HTTP i czekaja na sygnal startu do rozgrywki - serwer robi 'START' na channelu w Redis i wszyscy beda strzelac wysyslac request do servera no i teraz server sobie uaktualnia status rozgrywki (odejmuje od zycia obrazenia itp itd) np. w postgresie no i serwer powinien synchronizowac rozgrywke.
W sensie mysle ze za utrzymanie odstepu 1 sekundy pomiedzy strzalami kowboyow odpowiedzialny powinien byc serwer a nie kazdy cowboy z osobna. To raczej ""bezpieczniejsze" i unikniemy sytuacji ze cowboy "wystrzeli" za szybko.

No i tutaj jest moj problem z tym mechanizmem synchronizacji. Niejako troche taka "gra turowa" to jest w sensie jak to rozsadnie zrobic zeby serwer dal sygnal do nastepnego strzalu jak 1 tura bedzie w bazie danych tj. bedzie skonczona. Razem z sygnalem strzalu musze kazdemu cowboyowi zwrocic jego potencjalne cele - czyli serwer powinien odeslac potencjalne cele bez samego siebie i bez juz zabitych.

No. mam kilka pomyslow i metlik w glowie.

  1. Liczyc counter strzalow dla danej "tury" i jak wszystkie strzaly serwer zarejestruje to na tym 1 channelu wyslac wszystkim mapping z wszystkimi informacjami
    i kazdy cowboy sobie odczyta jesli jestes A to mozesz strzelac do (B, C) jesli jestes B to mozesz strzelac do (A,C) itp - no srednie to jest bo trzeba w takiej opcji pchac wszystkie dane do kazdego kowboya mimo ze on potrzebuje malego wycinka

  2. jednak nalezaloby stworzyc dynamicznie tyle channelii na Redisie ile cowboy-ow i serwer tak samo liczy counter i jak osiagnie counter strzalow dla tury to dla kazdego cowboya wysle to coo akurat dany cowboy potrzebuje tj. Channel 1 (B, C) , Channel 2 (A, C) itp itd - to chyba zly pomysl bo srednio mi sie widzi takie dynamiczne tworzenie wielu channeli a co jak bedzie bardzo duzo cowboyow

  3. Chyba blednie zalozylem ze cowboye do serwera beda wysylac requesty po API a serwer do cowboyow na channelu w Rediis. Moze powinny byc 2 kanaly w sensie :1) serwer -> kowboye (sygnal strzalu), i 2) serwer <- kowboye (sam strzal) tylko znowu wraca temat jak wyzej 1 i 2 ;/ 1 vs wiele channel i jak zwracac te potencjalne cele do wykonanai strzalu

Mam metlik w glowie i chyba mam klapki na oczach i zafiksowalem sie na jakis schemat i nie dostrzegam nic poza.

0

Najprosciej by bylo, zeby kazdy klient pollował serwer o aktualny stan gry. Potem mozesz optymalizowac wprowadzajac broadcast i inne mechanizmy. Problem wydaje sie izomorficzny do czata.

1 użytkowników online, w tym zalogowanych: 0, gości: 1