Filozofia projektowania gier.

0

Myślę że z zaimplementowaniem samej gry/gier nie będę miał problemów, często mam problem z wymyśleniem odpowiednich mechanizmów. Fajnie byłoby gdyby ktoś mógłby na nie odpowiedzieć.

Celuję w jak najprostszy kod, i server obsługujący ~ 5-10 graczy.

  • Czy UDP <ort>na prawdę</ort> jest konieczny, nawet dla gier akcji? Wydaje mi się że ten "wolny" TCP nie będzie aż taki zły, ponieważ jest more reliable i połączeniowy poza tym, jaka może być różnica w 50 pakietach na sekundę? (Mogę się mylić). Próbowałem znaleźć jakieś testy na internecie ale nie dostałem informacji o rzeczywistych stosunkach w różnicach szybkości obu. Poza tym, wolałbym implementować tylko jeden protokół (a TCP jest konieczny dla akcji które muszą być 100% dostarczone, jak wiadomości chat).

  • Skorzystać w końcu z UDP czy z TCP? Wydaje mi się że z UDP mógłbym broadcastować pakiety do wszystkich na raz, a przy TCP trzeba robić osobny wątek dla każdego połączenia (nie? chyba)? Ale i tak raz wysyła się różne informacje do różnych graczy. Nie wiem, i need help.

  • W jakiej postaci wysłać np. zmiany położenia gracza do servera? Zastanawiałem się nad:

    1. Wysłanie absolute position (otwarte na hacksy typu "teleporty" i takie tam, ale raczej nikomu nie będzie się chciało hackować mojej gry) oraz błąd obliczeniowy doubli - na różnych maszynach pozycje/kolizje mogą być obliczane troszkę inaczej.
    2. Wysłanie relative position czyli np. 10 jednostek w prawo od ostatniego położenia. Co jeśli pakiety dotrą w innych kolejnościach (i ruch będzie wyglądał "prawo lewo" zamiast "lewo prawo")? Czy różnice będą zauważalne dla 50 pakietów/sek?
    3. Wysłanie naciśniętych klawiszy do servera - tak by po czasach otrzymania pakietu server sam obliczył zmianę pozycji, i odesłał do klienta pozycję. (klient od razu ruszy postać zależnie od klienta, a potem dostanie potwierdzenie od servera).
  • Czy wysyłać "heartbeat"? Tzn czy klient ma wysyłać info do servera i z powrotem dopiero kiedy coś się stanie, czy raczej constantly? Gdyby były wysyłane non-stop mógłbym prawie natychmiast wykryć zerwanie połączenia i wyświetlić stosowny komunikat, nie wiem jednak czy nie spowoduje to zwiększonych ruchów między serverem a klientami.

  • W jakiej postaci chermetyzować kod? (Nie wiem czy tak się to nazywa) Czytałem o mvc i zawsze starałem się wkładać różne części programu do osobnych namespaców/packagy (tak że model miał dwa pola view i controller które dostawały referencję do modelu w konstuktorze (tak się to robi?) (offtop: skoro i tak jest jeden model, jeden view i jeden controller na program to czemu nie robi się ich klasami statycznymi i wtedy nie ma potrzeby robić referencji ani nic?)).

  • Czy GUI możebyć w nieskończonej pętli? Do tej pory jak robiłem gry singleplayer to tworzyłem okno a potem odpalałem nieskończoną pętlę która pobierała aktualny czas, wywoływała update(); (który brał informację z innych klas World etc i ogarniał logikę) dokładnie 100 razy na sekundę niezależnie od prędkości kompa w miarę równych odstępach czasu, a potem render(); (który brał info z jeszcze innych klas opisujących animacje, klasy od trzymania i obracania i przycinania obrazków, oraz klasy do ładowania plików z dysku) wtedy kiedy dał radę (czyli update(); zawsze 100 razy, a render(); kiedy się da). Noii, w tej nieskończonej pętli pobierałem też stan klawiszy (i dziwne, ale ta nieskończona pętla nie blokuje ani pobierania klawiszy (podejrzewam że addEventListener może być asynchoniczny ale nie wiem), ani wyświetlania rzeczy w oknie, ale coś mi mówi że to może nie być najlepszy sposób na wświetlanie grafiki w oknie). Miałem plan na to żeby jednak komunikację z serverem dać do osobnego wątku na wypadek jakieś timeoutu na 1 sekundę, żeby nie było wrażenia zacięcia gry. ** Na tym punkcie mi najbardziej zależy, czy robię wszystko ok**.

Wiem że to podstawowe pytania ale dopiero teraz zabieram się za napisanie pierwszej gry multiplayer (do tej pory nie było jak) i proszę o w miarę wyczerpujące odpowiedzi (na takich mi najbardziej zależy).

Dodam że do testów mam w domu 2-3 komputery w lanie, i nie mogłem sprawdzić sobie jak to będzie wyglądać z udp lub tcp i czy domowy komputer może obsłużyć 10 połączeń na raz (ale myślę że prawie na pewno tak).

PS;

  • Czy wysyłać informacje z servera ciągle, czy tylko po otrzymaniu wiadomości od klienta? Czyli np jak klient nie wyśle pakietu przez sekundę to przez tą sekundę server nie odpowie.
3

Problemem TCP nie jest to, że jest wolny, ale że wymusza ponowne wysyłanie pakietów. Podczas gry interesuje cię tylko najświeższy stan, a nie ciągłość wiadomości. Czekanie na ponowny transfer starego pakietu i jednoczesne blokowanie przetwarzania nowego pakietu jest bezsensowne, a TCP to wymusza i robi samo z siebie. Mam na myśli tutaj oczywiście stan typu położenie na mapie (zarówno graczy jak i innych obiektów).

Czy wysyłać "heartbeat"? Tzn czy klient ma wysyłać info do servera i z powrotem dopiero kiedy coś się stanie, czy raczej constantly? Gdyby były wysyłane non-stop mógłbym prawie natychmiast wykryć zerwanie połączenia i wyświetlić stosowny komunikat, nie wiem jednak czy nie spowoduje to zwiększonych ruchów między serverem a klientami.

Wysyłaj, ale rób to sprytnie, tzn jeżeli jest ciągły ruch między klientem, a serwerem to nie dorzucaj heartbeatów. Zamiast tego wykrywaj kiedy był ostatni ruch i wysyłaj heartbeaty tylko kiedy np nie było żadnego ruchu (w tym innych heartbeatów) od ponad sekundy.

chermetyzować

ort :]

0

" In a FPS, information that is not received ASAP is not worth re-sending." Gdzieś to przeczytałem ale nie pamiętam gdzie.

EDIT
Przypomniałem sobie gdzie http://fabiensanglard.net/quakeSource/quakeSourceNetWork.php

0

Do 10 graczy i serwer w sieci lokalnej nie ma znaczenia, czy będzie to TCP, czy UDP.
Położenie gracza - wysyłanie zmiany pozycji eliminuje Ci w zasadzie UDP, chyba, że nie będzie Ci przeszkadzało, że coś po drodze zginie (choć znowu - przy 10 graczach nie ma szans zginąć) :)
Heartbeat - jak chcesz wysłać coś do/z serwera, gdy się coś stanie? O tym, że coś się stało ma powiedzieć brak tętna. Zrób tak, jak napisał Wibowit - wysyłaj, gdy nie ma innej informacji o "życiu".
Pozostałe punkty mocno zależą od użytych technologii/języków.

0

Dodałem jeszcze jedno pytanie.

1
TomRiddle napisał(a):
  • Skorzystać w końcu z UDP czy z TCP? Wydaje mi się że z UDP mógłbym broadcastować pakiety do wszystkich na raz, a przy TCP trzeba robić osobny wątek dla każdego połączenia (nie? chyba)? Ale i tak raz wysyła się różne informacje do różnych graczy. Nie wiem, i need help.

http://gamedev.stackexchange.com/questions/62190/udp-vs-tcp-connection-for-a-platformer-multiplayer (to na start)
http://gamedev.stackexchange.com/search?tab=votes&q=udp%20or%20tcp%20in%20gaming
http://gamedev.stackexchange.com/questions/96945/what-is-better-lots-of-small-tcp-packets-or-one-long-one (ciekawa i długa dyskusja)

Może pomoże

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