Połączenie nie jest jeszcze wspólną rozgrywką
Dwie przeglądarki mogą wymieniać wiadomości i nadal pokazywać sprzeczny stan gry. W projekcie wieloosobowym trzeba określić, kto podejmuje ostateczną decyzję o ruchu, punkcie lub zakończeniu rundy. Dla wielu gier rozsądnym modelem jest serwer utrzymujący stan, do którego urządzenia wysyłają polecenia. Wtedy lokalny ekran nie jest jedynym źródłem prawdy o wyniku.
Zacznij od mechaniki o niewielkiej liczbie współdzielonych decyzji. Przykładowa gra turowa dwóch osób potrzebuje innego rytmu wymiany danych niż scena zręcznościowa. Nie dobieraj infrastruktury tylko do maksymalnej liczby użytkowników zapisanej w planie. Ustal, ile aktywnych pokoi będzie działało jednocześnie i jak często każdy z nich zmienia stan.
WebSocket jest kanałem, nie gotowym silnikiem gry
Interfejs WebSocket pozwala utrzymywać dwukierunkowe połączenie między przeglądarką a serwerem. Ułatwia przesyłanie wiadomości bez rozpoczynania osobnego żądania dla każdej zmiany. Nie zapewnia jednak automatycznie reguł pokoju, punktacji ani odzyskiwania stanu. Dokumentacja zwraca także uwagę na brak wbudowanego mechanizmu backpressure w tradycyjnym interfejsie WebSocket.
Przy dużej liczbie komunikatów aplikacja potrzebuje limitów i świadomego sposobu przetwarzania. Nie każda pośrednia pozycja obiektu musi być dostarczona do ekranu, który ma już nowszy stan. Z kolei decyzji o zakończeniu rundy nie można potraktować jak zbędnej klatki animacji. Rozdzielenie typów wiadomości jest jednym z pierwszych zadań projektu protokołu.
Opisz polecenia i odpowiedzi
Każda wiadomość powinna mieć określony typ, identyfikator rozgrywki i wymagane dane. Polecenie „wybierz pole” powinno wskazywać pole oraz kontekst rundy, nie zawierać dowolnej nowej tabeli punktów. Serwer sprawdza, czy działanie jest dopuszczalne w bieżącym stanie i czy osoba należy do pokoju. Błędy protokołu nie powinny prowadzić do wykonania części operacji.
Przyda się numer kolejnej zmiany stanu. Pozwala rozpoznać spóźniony komunikat i ustalić, czy urządzenie potrzebuje pełnego obrazu rozgrywki. Nie zakładaj, że gracz po ponownym połączeniu pamięta wszystkie wcześniejsze zdarzenia. Projektuj odbudowę widoku z potwierdzonego stanu, zamiast polegać wyłącznie na długim łańcuchu lokalnych animacji.
Uwierzytelniaj połączenie i sprawdzaj działania
Samo ustanowienie połączenia nie daje uprawnienia do dowolnego pokoju. Potrzebne są kontrola pochodzenia połączenia, autoryzacja wiadomości, limity oraz reakcja na wygaśnięcie sesji. OWASP opisuje te zagadnienia jako osobne elementy ochrony WebSocket, a nie skutek samego użycia szyfrowanego transportu.
MyTworzymy.pl obsługuje klientów z całej Polski i może być partnerem przy planowaniu gry webowej z komunikacją na żywo. W briefie warto jasno oddzielić prototyp dla kilku osób od produktu utrzymującego wiele jednoczesnych rozgrywek. To pomaga dobrać zakres testów, zaplecze serwerowe i sposób rozwoju bez obiecywania infrastruktury na każdy możliwy scenariusz.
Pokaż opóźnienie bez tworzenia fałszywej pewności
Gracz powinien odróżniać wykonanie lokalnej animacji od potwierdzenia ruchu przez serwer. W grze turowej można oznaczyć oczekiwanie i zablokować sprzeczne polecenia do otrzymania odpowiedzi. W szybszej grze stosuje się bardziej złożone techniki przewidywania i wygładzania, ale trzeba wtedy obsłużyć korekty. Płynny obraz nie oznacza braku opóźnienia w sieci.
Ustal, jak długo interfejs może czekać i co pokazuje po przekroczeniu tego czasu. Unikaj nieskończonego komunikatu „łączenie”. Gracz potrzebuje informacji, czy nadal jest uczestnikiem, czy runda została zakończona i czy może spróbować ponownie. Dobrze opisany stan awarii bywa ważniejszy niż dodatkowy efekt wizualny w idealnie działającym połączeniu.
Zaprojektuj rozłączenie jako normalny scenariusz
Odświeżenie karty, zmiana sieci i uśpienie telefonu mogą przerwać połączenie. Ustal, czy miejsce gracza pozostaje zarezerwowane, jak odzyskuje on udział i co dzieje się z przeciwnikiem w tym czasie. Token powrotu musi być ograniczony do właściwej rozgrywki i osoby. Nie pozwalaj, aby przypadkowo poznany numer pokoju wystarczał do przejęcia czyjegoś miejsca.
Przy projekcie z MyTworzymy.pl warto odebrać od razu scenariusz ponownego wejścia do aktywnej rundy. Daje to praktyczny obraz zakresu systemu, szczególnie gdy odbiorcy będą łączyć się z różnych miejsc w Polsce. Utrzymanie gry wieloosobowej wymaga uwzględnienia sieci i serwera; zwykły hosting dobrany wyłącznie do statycznej strony nie powinien być zakładany jako wystarczający bez sprawdzenia możliwości.
Testuj pokoje i sprzątanie zasobów
Sprawdź, czy wiadomość jednego pokoju nigdy nie trafia do innego, a rozłączone sesje przestają zajmować zasoby po przewidzianym czasie. Symuluj serię wejść, wyjść i ponowień, nie tylko dwóch graczy kończących rundę bez przeszkód. Monitoruj liczbę połączeń, czas obsługi komunikatów i błędy odtwarzania stanu. Dane diagnostyczne nie powinny zawierać sekretów sesji.
Osobno zaplanuj restart serwera. Może oznaczać bezpieczne zakończenie rund albo odtworzenie części stanu, lecz musi być świadomą decyzją. Multiplayer nie kończy się na działającym oknie czatu między dwiema kartami. Jego podstawą jest spójna odpowiedź na pytanie, co naprawdę wydarzyło się w grze i kto może kontynuować ją po przerwie.