Co jest nie tak hmm… nie jestem specem od gier, ale coś tam wiem:
-> gry tworzy się w pewnym kanonie, pętla główna, która jest uruchomiona do czasu gdy gra działa, etc.
-> samo php jest beznadziejną technologią do stworzenia gry, która jak mniemam przypominać ma rozgrywką final fantasy
Przede wszystkim przez to, że do przeglądarki nie możesz czegoś wysłać od tak, przeglądarka musi o to zażądać oraz nie możesz się komunikować graczy na poziomie serwera tylko przez bazę danych. To będzie wymagać pollingu - mało to ciekawe.
Jeśli upierasz się na technologie webową, to może połączenie serwletów + js ? Wyjaśnię jakby to miało wyglądać dla dwóch graczy = nie jest to podejście skalowalne = jest bardzo słabe = ciągle lepsze od twojego.
W serwlecie mógłbyś komunikować dwa wywołania dzięki zmiennym statycznym - to pierwszy plus (oraz wada jeśli chodzi o skalowalność - można to zrobić lepiej ale zostawiam to już tobie = podpowiedź słowo-klucz kolejki komunikatów + identyfikatory graczy)
Co to daje?
-
Tworzysz dwa obiekty statyczne reprezentujące graczy.
-
Gracz drugi wysyła asynchronicznie komunikat “OCZEKUJE NA RUCH”. Wątek, który go obsługuje zasypia, bądź blokuje się na jakimś zamku.
-
Gracz pierwszy może powiedzmy wysłać komunikat ATAK, też asynchronicznie. Drugi wątek, który będzie przetwarzał gracza pierwszego sprawdzi sobie w obiekcie, jaką masz broń, siłe, etc. Jaki ten drugi gracz ma pancerz, życie, etc. wyliczy dmg, wykona modyfikację na obiekcie reprezentującym gracza drugiego wybudzi wątek gracza drugiego i pójdzie sam spać.
-
Wątek gracza drugiego dokończy wywołanie zwracając zawartość obiektu gracza drugiego i odpowiednio przeglądarka to przeładuje.
-
Teraz gracz drugi ma inicjatywę a gracz pierwszy czeka. Wrócić do punktu 2 tylko teraz czytając gracz 1 => 2 a 2 => 1.
*. Każde zadanie asynchroniczne po stronie widoku powinno tworzyć jakąś animację loadingu. Coby użytkownik wiedział, że czeka na ruch oponenta + może jakiś timeout = mało zabawne jak ktoś to uruchomi i pójdzie, a my gapimy się 10 minut w kontrolkę oczekiwania
Generalnie:
-
Trzeba zaprojektować jakiś protokół komunikatów
-
Przesyłać tylko komunikaty i modyfikować obiekty a graczom odsyłać kopie tych informacji celem odrysowania widoku. Dzięki temu nawet jak ktoś w js podmieni sobie życie na 102130213921, to i tak po wysłaniu ATAK w niego odejmiesz to co jest w obiekcie i mu powiesz ze ma 50. Innymi słowy stworzysz coś takiego, że przeglądarka to tylko widok, buttony + asynchroniczne wywołania stworzą kontroler, a logika będzie bezpieczna po stronie serwera. Dlaczego komunikaty? To będzie taki zbiór operacji elementarnych poza które nie można wyjść. Np. jeśli przesyłał byś coś w stylu ?DMG=50, to każdy może sobie podmienić to na 200, 500, ile chce. Przy komunikacie nie ma problemu: “ATAK”, znaczy zastosuj formułę znaną po stronie serwera, używając zmiennych po stronie serwera = większe bezpieczeństwo.
Oczywiście jak wspomniałem mało to skalowalne, ze wzlędu na static + wątek == gracz == dużo wątków. Ale można zaprojektować coś takiego jak jest w nio, podział kanałów z selektorem.
Ogólna idea: Każdy gracz ma swój id, wątek serwleta rejestruje, że jest coś do przetworzenia w jakiejś liście pod kluczem danego gracza, natomiast inny wątek przelatuje co jakiś czas listę sprawdzając czy dla któregoś z graczy można coś wykonać. Można też dodać flagę oznaczjącą cięższe obliczeniowo zadanie, i wtedy wątek oblatujący kolejkę komunikatów wywoływałby widząc falgę ciężkiego zadania dodatkowy wątek, co by nie zblokować się na długo. A przy okazji, nie byłoby sytuacji, że tworzymy wątek dla zadania, które wymaga dwóch dodawań i dzielenia. Bo koszt utworzenia wątku by to znacząco przekraczał.
