Projektując grę sieciową dla wielu graczy, w której jeden gracz hostuje, a inni się łączą, istnieją dwie strategie:
- Niech gra gospodarza-gracza będzie autorytetem , a wszyscy inni gracze jako głupi klienci będą próbowali nadrobić obecny stan gry. W kodzie będzie musiało być wiele specjalnych przypadków, w zależności od tego, czy bieżący gracz jest gospodarzem, czy nie.
- Uczyń hosta głupim klientem, jak wszyscy inni, uruchamiając ukryty dedykowany serwer w innym wątku. Serwer dedykowany będzie autorytetem, a host połączy się z nim jak wszyscy inni (przez localhost).
Jakie są zalety / wady każdego z nich? Który jest najczęściej używany (czy różni się w zależności od rodzaju / wielkości gry)?
game-design
networking
multiplayer
BlueRaja - Danny Pflughoeft
źródło
źródło
Odpowiedzi:
Podejście „głupi klient” jest najlepsze z czysto projektowego punktu widzenia - mocno ogranicza ilość różnych kodów potrzebnych między hostem a klientami i pozwala serwerowi działać asynchronicznie. Minusem jest to, że maszyna hosta wymaga dodatkowych zasobów - ale myślę, że zawsze tak było.
źródło
Pomiędzy tymi dwiema opcjami podejście głupiego klienta jest z pewnością najlepsze z powodów, o których wspomina DeadMG.
Istnieje inna opcja, która sprawia, że każdy klient staje się autorytetem, ma tę zaletę, że głupi klient, że wszyscy uczestnicy współużytkują ten sam kod. Inną zaletą jest to, że może być o wiele bardziej sprawiedliwe, jeśli ustawisz właściwe reguły, ponieważ nikt nie ma przewagi 0-lag-to-server.
Może to być dość trudne do wdrożenia w zależności od rodzaju gry. Twój protokół będzie musiał radzić sobie z rozwiązywaniem konfliktów między rówieśnikami, prawdopodobnie przy użyciu pewnego rodzaju schematu własności. Pozostawiając tylko konflikty, w których 2 peerów rości sobie prawo własności do tego samego obiektu gry.
Protokoły wieloosobowe Google Peer-2-Peer mogą dać ci więcej szczegółów na temat tego podejścia.
źródło