Mobilny pojedynek 3D z maczugami: jak zaprojektowano „Mace Duel Mobile”

Prototyp gry przeglądarkowej dla dwóch graczy

„Mace Duel Mobile” przedstawiono jako praktyczny projekt gry 3D PvP działającej w przeglądarce — zarówno na telefonie, jak i komputerze. Stos technologiczny obejmuje TypeScript, Vite i Three.js po stronie klienta oraz Node.js, TypeScript i bibliotekę ws po stronie serwera.

Założenie jest proste: dwóch graczy trafia do prywatnego pokoju i rozgrywa serię pojedynków na arenie. Walka obejmuje zwykłe uderzenia maczugą, silniejsze ataki wykonywane podczas spadania oraz ładunki wiatru, które odrzucają przeciwników.

Co liczy serwer, a co robi przeglądarka?

Najważniejszym elementem architektury jest serwer autorytatywny. Klient nie przesyła serwerowi „gotowych” informacji o zadanych obrażeniach, zdrowiu ani wiarygodnej pozycji postaci. Zamiast tego wysyła przede wszystkim wejście gracza: kierunek ruchu, obrót kamery i żądanie użycia ataku.

To serwer wykonuje symulację w stałym kroku 30 Hz i rozstrzyga:

• pozycję oraz ruch postaci,
• kolizje i trafienia,
• obrażenia oraz odrzucenie,
• zdrowie graczy,
• stan pocisków wiatru,
• wynik rundy i całego meczu.

Taki podział ogranicza możliwość prostego manipulowania wynikiem po stronie przeglądarki. Projekt przewiduje też podstawową walidację komunikatów, ograniczanie tempa żądań, heartbeat oraz mechanizmy kompensacji opóźnień przy trafieniach.

Sterowanie przygotowane pod ekran dotykowy

Projekt nie rezygnuje z klawiatury i myszy, ale szczególny nacisk położono na obsługę smartfonów. Układ sterowania ma działać wygodnie w orientacji poziomej:

• lewy wirtualny joystick odpowiada za ruch,
• przeciąganie po prawej stronie ekranu zmienia kierunek patrzenia,
• osobne przyciski służą do skoku i sprintu,
• dostępne są przyciski ataku maczugą oraz ładunku wiatru.

W takiej grze ważna jest obsługa wielu punktów dotyku naraz — przykładowo gracz może jednocześnie poruszać postacią, obracać kamerę i nacisnąć przycisk ataku. Dokumentacja MDN opisuje dotyk jako zestaw niezależnych wskaźników, co odpowiada potrzebom tego rodzaju sterowania mobilnego 1.

Zasady pojedynku

Każdy zawodnik rozpoczyna rundę ze 100 punktami zdrowia i trzema ładunkami wiatru. Ładunki odnawiają się z czasem. Mecz wymaga zdobycia trzech wygranych rund, a pojedyncza runda ma limit dwóch minut.

System walki rozróżnia dwa rodzaje ataku maczugą:

1. Zwykłe uderzenie — zadaje stałe obrażenia, jeśli przeciwnik znajduje się w zasięgu i odpowiednim kącie przed graczem.
2. Uderzenie spadające — jest silniejsze, gdy atakujący opada z odpowiedniej wysokości. Wysokość spadania zwiększa obrażenia i siłę odrzutu, do określonego limitu.

Ładunek wiatru tworzy pocisk. Po trafieniu, kontakcie z podłożem, granicą areny albo po wygaśnięciu czasu życia pocisk eksploduje i odpycha postacie w promieniu wybuchu. Nie jest to bezpośredni system obrażeń — jego rolą jest przede wszystkim zmiana pozycji przeciwnika i stworzenie okazji do ataku z góry.

Struktura projektu

W przedstawionym układzie katalogów kod rozdzielono na trzy główne części:

• client / src — scena Three.js, interfejs, sterowanie, dźwięk i prezentacja stanu gry;
• server — pokoje, pętla symulacji, fizyka rozgrywki, pociski i obsługa połączeń;
• shared — wspólne typy protokołu, stałe zasad oraz funkcje walidujące.

Wspólny moduł z zasadami definiuje m.in. szybkość ruchu, grawitację, zasięg ataku, czas odnowienia, obrażenia, promień eksplozji, długość rundy i liczbę zwycięstw potrzebnych do wygrania meczu. Dzięki temu klient i serwer mogą korzystać z tych samych definicji bez duplikowania podstawowych parametrów.

Wydajność grafiki i sieci

W warstwie renderowania wskazano użycie InstancedMesh dla elementów powtarzalnych, takich jak fragmenty podłoża. To wariant obiektu Three.js przeznaczony do renderowania wielu instancji wspólnej geometrii i materiału 2. W praktyce pomaga to ograniczać liczbę wywołań rysowania, co ma znaczenie zwłaszcza na słabszych urządzeniach mobilnych.

Projekt przewiduje także możliwość wyłączenia map cieni. Three.js udostępnia konfigurację shadowMap, a mapy cieni nie są domyślnie włączone w rendererze 4. Taka opcja pozwala potraktować jakość obrazu jako ustawienie, a nie obowiązkowy koszt wydajności.

Komunikacja w czasie rzeczywistym odbywa się przez WebSockety. Serwer utrzymuje pokoje dla maksymalnie dwóch osób, wysyła okresowe snapshoty stanu, a po rozłączeniu uczestnika może zakończyć mecz na korzyść pozostałego gracza.

Co wymaga dopracowania przed publikacją?

Opisany materiał jest solidnym szkieletem prototypu, ale przed publicznym wdrożeniem wymaga pełnej weryfikacji. Należy między innymi przetestować zachowanie przy wysokich opóźnieniach, rozłączeniach, wielokrotnych równoczesnych wejściach do pokoju oraz na szerokim przekroju urządzeń mobilnych.

Przy wdrożeniu publicznym konieczne jest również bezpieczne wystawienie połączeń sieciowych, odpowiednia konfiguracja reverse proxy i TLS, monitoring oraz testy obciążeniowe. Sama autorytatywna symulacja po stronie serwera jest dobrym punktem wyjścia, lecz nie zastępuje kompletnej ochrony infrastruktury ani testów bezpieczeństwa.

Źródła

• 1 MDN Web Docs, „Mobile touch controls - Game development”.
• 2 Three.js Docs, „InstancedMesh”.
• 4 Three.js Docs, „WebGLRenderer”.