Mechanika gry multiplayer - kilka pytań

Hey, piszę małą aplikację multiplayer, mam parę pytań teoretycznych (nie chcę wyrabiać złych nawyków). Napiszę w punktach:

1. Czy dane o położeniu danego gracza (oraz wszelkie inne dane) przesyłamy ciągle w odstępach jakiegoś t czy tylko gdy się porusza? (ja stawiam na tę drugą opcję z racji mniejszego obciążenia łącza)
2. Czy sygnały i sloty są wystarczająco szybkie żeby temu podołać (powyższemu), tzn. jeżeli mam klasę Gracz (wiadomo) i klasę Klient (infrastruktura sieciowa) i gracz się porusza (w trybie ciągłym, przez określony czas) to czy wysyłając sygnał (z koordynatami) do slotu w klasie Klient nie zamulę aplikacji, tzn. nie będzie jakiś dużych nadmiarowych opóźnień?
3. Może zamiast powyższego zrobić jakąś klasę pośredniczącą, typu Bufor, w której będę trzymał kolejkę komunikatów. Obiekt klasy Klient, będzie pobierał z tej kolejki komunikat i wysyłał dopóki kolejka nie jest pusta (a obiekt klasy Gracz będzie do tej kolejki dodawał kolejne komunikaty)?

Pozdrawiam

1. Tylko delty położeń + informacja początkowa. Przydałaby się jeszcze dodatkowa synchronizacja, gdzie klient co jakiś czas informuje serwer gdzie myśli, że jest.
2. Puść sobie kilka pingów na sygnałach między różnymi wątkami ;) Jeśli nie robisz jakiegoś wielkiego serwera na tysiące graczy to bym się nie martwił, a nawet wtedy bym pierw sprawdził, zamiast tę opcję wykluczać.
3. Za komunikację i translację Message<->socket powinna odpowiadać osobna klasa. https://en.wikipedia.org/wiki/Single_responsibility_principle Przy czym Klient wydaje się tym być, więc nie widzę problemu ani potrzeby wprowadzania dodatkowego bufora.

1. Zdecydowanie lepiej przesyłać dane tylko wtedy, gdy następuje jakaś akcja (np. ruch) + weź pod uwagę stanowość wszystkich klientów.
   2 i 3. Wszystko zależy od tego, jak bardzo złożona ma być to aplikacja/gra. Generalnie sygnały Qt nie są dobrym rozwiązaniem jeśli chodzi o gry (ale mógłbyś użyć libki fastdelegate, o ile piszesz w C++).
   Polecam poczytać, jak to jest zrealizowane w "działających" silnikach, np. Unreal Engine - https://udn.epicgames.com/Three/NetworkingOverview.html

@kq, dzięki. Czyli generalnie dla "mniejszych" serwerów nie będzie problemu.

@Satirev, dzięki, obczaję linka. Co do zapodanej biblioteki, jak już uporam się z tym na pewno wypróbuję.

Naszła mnie jednak taka myśl, że jak będę miał tych standardowych 64 klientów, i jak zaczną wysyłać do biednego serwera masę requestów, to czy na tym serwerze nie zmuli przy rozdzielaniu tych wiadomości. Obecnie mam to prosto zrobione (coś jak w Examples z dokumentacji, bez użycia wielowątkowości) ale myślę że może warto zrobić coś takiego:

pseudokod po stronie serwera:

incomingMessage() {
   message = socket->read(); //w postaci strumienia bajtów
    
   //i tu zamiast rozkodowywać wiadomość, wysyłać do klienta, zrobię nowy wątek, ktory sie tym zajmie
   //dzieki czemu serwer od razu moze powrocic do nasluchiwania i glowny watek nie traci czasu na dekodowanie i wysylanie
}

dodanie znacznika <code class="cpp"> - fp

w momencie zmiany typu ruchu możesz wysyłać dane typu: pozycja początkowa, kierunek, prędkość, długość ruchu, wtedy nie trzeba wysyłać updatów z położeniem w trakcie ruchu. W przypadku anulowania ruchu w trakcie synchronizujesz aktualną pozycję.