[Mattiopl]

Hej, piszę gre sieciowa unity. Sieć opieram o DarkRift2. Wydaje się świetny bo zostawia wszystko w moich rękach. Nie wiele dzieje się pod spodem bez mojej wiedzy i jestem z tego bardzo zadowolny.
Jednak z moim doświadczeniem troche boje się podejmowanych decyzji, które później może być piekielnie ciężko cofnąć bez przepisywania połowy gry dlatego szukam porady.
Jako, że nie chciałbym, żeby wszystko było client side liczone, a reszta graczy miałaby uwieżyc w to co każdy wysyła wymyśliłem coś takiego:

Gracz-Host <---> Server <---> Gracz1
Gracz-Host <---> Server <---> Gracz2
Gracz-Host <---> Server <---> Gracz3...

Jako, że serwerem jest C# apka wydaje mi się, że bardzo ciężko byłoby kontrolować graczy. Przede wszystkim wszelkie skrypty liczące ruch musiałbym mirrorować na serwerze. Nie mówiąc o danych dotyczących mapy, liczeniu kolizji etc., więc wymyśliłem, że jeden z graczy będzie hostem i to "on będzie miał racje", a reszta graczy do niego będzie wyrównywać.

W takim przypadku w ostateczności mógłbym hostować gry z hostem nie-graczem, który tylko będzie obsem i zapewnić uczciwą rozgrywke. Jednak wydaje sie to super obciążającym wyjściem i tylko niektóre gry byłbym wstanie hostować.
Jednak zachowuje cały szereg zalet posiadania serwera - przekazywanie hosta, reconnecty, cały ruch przechodził by przez hosta, nikt by nie znał swoich adresów i wiele więcej. Wadą jest, że jeśli nie ja będę hostował gre to muszę zaufać hostowi... do tego każdy lag po stronie hosta będzie lagiem dla reszty.

Co o tym myślicie? Są jakieś inne sensowniejsze rozwiazania dla Unity?

#gamedev

[Sinti]

@Mattiopl: Czyli host hostuje grę jednocześnie nie łącząc się bezpośrednio z innymi graczami tylko pośrednio przez server? Pakiet leci przez trasę: gracz -> server -> host i odpowiedź leci z powrotem?
Może być lipa z pingiem i ogólną synchronizacją jeśli to dynamiczna gra.

[jigsaw96]

@Mattiopl: poczytaj jak to się robi w grach AAA. Szczególnie polecam gafferongames.com (artykuły o State synchronization i State interpolation) i dokumentację Source Valve'a.

[H.....s]

@Mattiopl: Serwer będzie działał na c#, czyli systemem będzie Windows? Nie myślałeś czy napisanie serwera, np w c++ i postawienie na Linuxie (np ubuntu server, centOS) nie byłoby bardziej efektywne pod względem wydajności, czy możliwości dokładnego filtrowania niechcianego ruchu przez Iptables?

[Mattiopl]

@HomeMadeGames: Nie znam za dobrze linuxa, ani c++. Do tego darkrift jest C#, ale pomysle o tym

[tlustywalec]

@HomeMadeGames: O ile serwer będzie napisany w .NET Core to można go postawić na linuxie i nie trzeba będzie się wtedy uczyć c++
@Mattiopl: Nie znam się za bardzo na pisaniu takich rzeczy, ale czy to że jeden z graczy "ma zawsze rację" nie da dużego pola manewru dla różnego rodzaju cheatów dla hosta? Myślę że mimo wszystko na serwerze powinieneś robić sprawdzenie czy np. gracz nie poruszył się za

[Mattiopl]

@tlustywalec: Wersja pro darkrifta jest w dostepna chyba w .net core, wiec jest taka opcja. Narazie nastawiam sie na serwisy w chmurze, ale nic w tym temacie kosztów sie nie orientowalem, wiec zobacze.

Aktualne rozwiazanie zaklada ze bedzie w stanie ruszyć unity w headless mode (bez grafiki) po stronie serwera i zrobic hosta nie-gracza, co nie powinno wymagac wielu zmian. Wiec jest opcja na hostowanie gier po mojej stronie, ale jeszcze

[Mattiopl]

@jigsaw96: Dobry blog, sporo wiedzialem, ale też paru kluczowych kwestii nie bylem swiadom. Dzieki!