Multiplayer gameserver ontwikkelen

[TheNephilim]

Situatie

Als ontwikkelaar wil je soms wel eens wat nieuws proberen. In mijn situatie ontwikkel ik eigenlijk alleen websites/-applicaties middels HTML/CSS/JS en PHP, altijd stateless dus, op wat werk in Vue (JS) na.

Een tijdje geleden heb ik al eens wat met Unity geprobeerd te maken en later eens een NodeJS server met JS WebGL client. De Unity poging eindigde vooral in frustratie nadat het niet lukte een fatsoenlijke isometrische view te bouwen waarbinnen je (net als in bijv. Age of Empires) over een map kan scrollen. Bij de NodeJS server vond ik het erg lastig te bepalen wat die game-loop nu precies moet doen en de communicatie van server naar JS WebGL client was ook wel even lastig.

Conclusie

Mijn conclusie was dat ik te weinig van de basisconcepten weet, waardoor het aan elkaar knopen van de verschillende onderdelen erg lastig wordt. Ik werk overigens graag gewoon wat uit; een simpel basis principe van wat ik wil doen leert voor mij makkelijker dan het één helemaal uitkauwen en dan verder naar het volgende onderdeel. Nu zou ik graag wat meer weten van enkele principes en welke oplossingen er allemaal zijn.

De vragen

1. Een server in NodeJS bouwen leek me een prima begin, omdat ik wat kan met JS en er genoeg libraries te vinden zijn die aansluiting met bijv. WebSockets op een client heel makkelijk maken. Maar... is een NodeJS server snel genoeg of moet ik überhaupt denken aan het ontwikkelen van een server in een andere taal (Rust bijv.)?

2. De game-loop! Wat doe je allemaal in de game-loop? In mijn probeersel had ik een 'resource', deze 'resouce' wordt gefarmed en daar hangt een getalletje aan, bijv. +3 per minuut. Moet ik dan in de gameloop bepalen (aan de hand van de delta) hoeveel dat per tick is en dat optellen? Zie onderstaande code als simpel voorbeeld.

code:

const id = gameLoop.setGameLoop(function(delta) {
    
    // `delta` is the delta time from the last frame

    primus.forEach(function (spark, id, connections) {

        user.resources.water.amount = floor(user.resources.water.amount + (user.resources.water.accumulating * delta), 4);

        let data = {
            resources: user.resources,
        };

        spark.write(data);
    });
    
}, fps);

3. Server -> Client communicatie; stuur ik bij elke server tick een update naar de client?

4. Server -> Client communicatie; Het betreft een multiplayer game, spelers zullen elkaar op bepaalde plekken kunnen zien lopen (oid.). Splits je die 'movement' gegevens op naar een 'publiek' kanaal en bijv. 'resources' naar een 'privé' kanaal?

5. Server persistence; Dingen die je per tick doet, sla je die meteen op in een database? In mijn 'resource' voorbeeld zou dat te gek worden denk ik, zelfs als je een in-memory database gebruikt (Redis oid.).

6. Client -> server events; stel een client verplaatst zijn poppetje naar een andere positie, dan zal ik een event naar de server sturen dat poppetje van A naar B verplaatst moet worden. Maar gaat die server vervolgens in de game-loop een 'movement' update sturen naar alle clients, of stuurt de client die naar alle andere clients?

Tot slot

Wellicht hebben jullie wat aanwijzingen en/of steekwoorden waarop ik verder kan Googlen en dergelijke. Ik heb al wel wat rondgekeken, maar vind nergens een samenhangend verhaal. Daarnaast ben ik ook erg geïnteresseerd met welke verschillende oplossingen jullie komen. Er is nooit één manier om iets te doen, maar bepaalde patronen zullen in ieder geval terugkomen.

[xzaz]

Gameservers zijn meestal C++ en relatief simpele sockets, ze verdelen taken in UDP (bv. movement) en TCP (bv. chat).

[Ryada]

Zoals xzaz hierboven zegt word C++ meestal gebruikt voor gameservers mits je die zelf helemaal van scratch maakt.

Nu zal het waarschijnlijk niet fijn zijn dit te horen maar, probeer eerst een goede basis te creëren op de game client kant zonder multiplayer.
Begin simpel en maak bijvoorbeeld een 2d platformer om de API van Unity/Unreal te ontdekken. Servers binnen gamedev zijn nog een niveau hoger dan de client logic zelf omdat je vooral ook rekening moet houden met server authority (je wilt niet dat iedere script kiddie unlimited health op zijn character kan gooien bijvoorbeeld) ook moet je validation etc erin gaan verwerken en zorgen dat het allemaal in sync blijft lopen.
Of hoe wil je interpolation and extrapolation gaan behandelen (client of server sided) en hoe wil je lagcompensation doen, zonder dat je een goede basis hebt over hoe de game client met data omgaat?

Ik ben zelf ook bezig met game development en ga volgend jaar hier ook een hbo studie voor volgen, maar wat ik vooral merk is dat een basis in een game engine een stuk beter is voordat je met Networking begint van een gameserver. Het klinkt allemaal zo makkelijk maar het is echt een heel stuk lastiger dan je zou denken.

Mijn advies is: begin bij de basis en maak een simpele game in Unity/Unreal en ga van daaruit verder. (en zorg natuurlijk voor een goede basis in c++ of C# afhankelijk van of je Unity of Unreal kiest)

Edit: voor iets betere antwoorden op je vraag kan ik je doorverwijzen naar: http://cedric-neukirchen....Cedric_eXi_Neukirchen.pdf
Dit word gezien als het beste document dat bestaat over gamenetworking.

[ Voor 10% gewijzigd door Ryada op 09-05-2018 12:08 ]

[CurlyMo]

TheNephilim schreef op woensdag 9 mei 2018 @ 11:48:
3. Server -> Client communicatie; stuur ik bij elke server tick een update naar de client?

Idealiter stel je vast welke updates relevant zijn voor een specifieke client en stuur je alleen die update naar hem toe op het moment dat het zich voor doet. Dat is ook het voordeel van websockets. Bij normale AJAX requests moet je client telkens 'vragen' of er updates zijn.

4. Server -> Client communicatie; Het betreft een multiplayer game, spelers zullen elkaar op bepaalde plekken kunnen zien lopen (oid.). Splits je die 'movement' gegevens op naar een 'publiek' kanaal en bijv. 'resources' naar een 'privé' kanaal?

Als je met websockets werkt heeft elke client zijn eigen socket verbinding. Stuur alles wat relevant is voor je client gewoon over die verbinding. Het is niet zinvol om dit te splitsen in meerdere verbindingen per client.

5. Server persistence; Dingen die je per tick doet, sla je die meteen op in een database? In mijn 'resource' voorbeeld zou dat te gek worden denk ik, zelfs als je een in-memory database gebruikt (Redis oid.).

Niet per tick, maar event driven. Als er dus niks is gewijzigd is er geen event gebeurt en hoef je dus niks op te slaan.

6. Client -> server events; stel een client verplaatst zijn poppetje naar een andere positie, dan zal ik een event naar de server sturen dat poppetje van A naar B verplaatst moet worden. Maar gaat die server vervolgens in de game-loop een 'movement' update sturen naar alle clients, of stuurt de client die naar alle andere clients?

Clients kunnen niet direct met andere clients praten, dat moet altijd via de server.


Algemeen.
Het lijkt erop alsof je nog niet bekend bent met (web)socket communicatie in een server/client opstellen. Voordat je direct aan een spel begint, leer eerst dat eens kennen door bijv. een chat applicatie. Leer daarna event driven te programmeren en aan het eind een spel te maken met interacties. Als je nu direct een spel maakt, ga je door je onkunde allerlei rare dingen doen die je uiteindelijk doen vastlopen.

Javascript en NodeJS maken het erg makkelijk om event driven te programmeren en asynchrone communicatie mogelijk te maken. Probeer je daar eerst in te verdiepen.

[Ryada]

CurlyMo schreef op woensdag 9 mei 2018 @ 12:08:
[...]

Idealiter stel je vast welke updates relevant zijn voor een specifieke client en stuur je alleen die update naar hem toe op het moment dat het zich voor doet. Dat is ook het voordeel van websockets. Bij normale AJAX requests moet je client telkens 'vragen' of er updates zijn.


[...]

Als je met websockets werkt heeft elke client zijn eigen socket verbinding. Stuur alles wat relevant is voor je client gewoon over die verbinding. Het is niet zinvol om dit te splitsen in meerdere verbindingen per client.


[...]

Niet per tick, maar event driven. Als er dus niks is gewijzigd is er geen event gebeurt en hoef je dus niks op te slaan.


[...]

Clients kunnen niet direct met andere clients praten, dat moet altijd via de server.


Algemeen.
Het lijkt erop alsof je nog niet bekend bent met (web)socket communicatie in een server/client opstellen. Voordat je direct aan een spel begint, leer eerst dat eens kennen door bijv. een chat applicatie. Leer daarna event driven te programmeren of aan het eind een spel te maken met interacties. Als je nu direct een spel maakt, ga je door je onkunde allerlei rare dingen doen die je uiteindelijk doen vastlopen.

Javascript en NodeJS maken het erg makkelijk om event driven te programmeren en asynchrone communicatie mogelijk te maken. Probeer je daar eerst in te verdiepen.

toon volledige bericht

(no offense naar OP met deze reactie)
Terwijl ik het met je eens ben op een hoop punten, is het ook belangrijk dat OP niet veel kennis van single player game frameworks heeft aan de hand van dat hij zegt dat een isometric camera maken in Unity al een probleem was. Wat erop duid dat hij ook een hoop kennis van zaken mist mbt de game client. Wat een fundamenteel onderdeel is van je server logic in elkaar zetten.
Event driven en server/client zou imo pas moeten komen nadat je een relatief solide basis hebt in local only games.
Waarom ik dit zo belangrijk vind is omdat als iemand niet weet hoe de client side werkt zal de server side een drama worden omdat je dan misschien teveel informatie stuurt naar de client, en daar kunnen hacks voor gemaakt worden (even kort door de bocht). Terwijl als je weet wat een client nodig heeft, zal je alleen het minimale wat nodig is doorsturen naar de client en weten hoe je het lastig of onmogelijk maakt om simpele cheats zoals infinite ammo te maken.

[CurlyMo]

Ryada schreef op woensdag 9 mei 2018 @ 12:15:
[...]

Event driven en server/client zou imo pas moeten komen nadat je een relatief solide basis hebt in local only games.

Oftewel, aan zowel de client en server kant heeft TS een hele zwik te leren

[ThomasG]

Ik raad het gebruik van NodeJS voor (high-performane) low-latency server als een game-server af. In plaats daarvan zou je kunnen kijken naar Java, en specifiek de library Netty (netty wordt door veel grote bedrijven gebruikt, en is qua performance vrij-ongeëvenaard). Er zijn zelfs verschillende voorbeelden de vinden van websocket game-servers in Java met Netty.

[CurlyMo]

ThomasG schreef op woensdag 9 mei 2018 @ 12:19:
Ik raad het gebruik van NodeJS voor (high-performane) low-latency server als een game-server af. In plaats daarvan zou je kunnen kijken naar Java, en specifiek de library Netty (netty wordt door veel grote bedrijven gebruikt, en is qua performance vrij-ongeëvenaard). Er zijn zelfs verschillende voorbeelden de vinden van websocket game-servers in Java met Netty.

Ik denk dat je performance issues die TS gaat ondervinden voornamelijk met onhandig programmeerwerk te maken zal hebben dan met de beperkingen van de taal. NodeJS is prima om mee te experimenten als je van javascript komt.

[Ryada]

ThomasG schreef op woensdag 9 mei 2018 @ 12:19:
Ik raad het gebruik van NodeJS voor (high-performane) low-latency server als een game-server af. In plaats daarvan zou je kunnen kijken naar Java, en specifiek de library Netty (netty wordt door veel grote bedrijven gebruikt, en is qua performance vrij-ongeëvenaard). Er zijn zelfs verschillende voorbeelden de vinden van websocket game-servers in Java met Netty.

Netty heb ik niet super veel van gehoord maar hoe gedraagt het zich tov C++ en Wangle of Boost.Asio met google.protobuf als messaging protocol? Wat ik zo kan vinden is C++ toch de handigere keuze is vooral ook omdat je een stuk meer controle hebt.

Edit: Ik druk weer eens op verstuur nadat ik maar de helft geschreven heb...

[ Voor 14% gewijzigd door Ryada op 09-05-2018 12:35 ]

[Hydra]

@TheNephilim wat betreft de taal waarin je het ontwikkeld; het is een hobby project dus ik zou gewoon een taal nemen waar jij je senang bij voelt. Breng wel eerst de requirements in kaart; als je er een constante open bidirectionele connectie moet zijn moet je wel teminste een taal + framework hebben dat dit ondersteunt. Wordt het een web game, of een thick-client? Etc. Breng eerst goed de requirements in kaart en kies daarbij de taal, libraries en tools.

Ryada schreef op woensdag 9 mei 2018 @ 12:22:Wat ik zo kan vinden is C++ toch de handigere keuze is vooral ook omdat je een stuk meer controle hebt.

Dit is nogal een statement. Wat is uberhaupt "controle"? Dat voor triple-A clients de client in C++ geschreven wordt is een gegeven, daar wil je elk beetje performance uit je client kunnen persen. Maar de back-end van World of Warcraft bijvoorbeeld is Java.

[ Voor 33% gewijzigd door Hydra op 09-05-2018 13:28 ]

[Ryada]

Hydra schreef op woensdag 9 mei 2018 @ 13:04:
[...]


Dit is nogal een statement. Wat is uberhaupt "controle"? Dat voor triple-A clients de client in C++ geschreven wordt is een gegeven, daar wil je elk beetje performance uit je client kunnen persen. Maar de back-end van World of Warcraft bijvoorbeeld is Java.

Imo komt de controle neer op de controle die je krijgt dmv pointers en references. Itt de pass by value in java. Kan zijn dat anderen dat anders zien. Maar om een high performance low latency server te maken zou ik persoonlijk voor C++ kiezen omdat het zo snel mogelijk moet werken, voor de beste user experience.

Ik kan ook niet zo op google vinden dat de WoW servers in java geschreven zouden zijn. Zou leuk zijn als je een source had waar dat bevestigd word.

[Gomez12]

Ryada schreef op woensdag 9 mei 2018 @ 12:22:
[...]
Wat ik zo kan vinden is C++ toch de handigere keuze is vooral ook omdat je een stuk meer controle hebt.

Alleen in principe wil je veelal die controle helemaal niet hebben in het begin.

Je kan ook voor ultieme controle in assembly rechtstreeks tegen de chips in je netwerkkaart aan gaan praten. Alleen praktisch gezien zit er tegenwoordig een laag of 20 tussen die je van alles uit handen neemt.

Kijk voor een volgende 4k Call Of Duty game kan het handig zijn om meer controle over timings etc te hebben met C++, maar praktisch gezien kan je met elke scripttaal al een multiplayer server ontwikkelen. In het allerergste geval wordt het iets als PubG tijdens release en kijk eens wat die voor een geld hebben binnengeharkt...

[Hydra]

Ryada schreef op woensdag 9 mei 2018 @ 13:16:
Imo komt de controle neer op de controle die je krijgt dmv pointers en references. Itt de pass by value in java. Kan zijn dat anderen dat anders zien. Maar om een high performance low latency server te maken zou ik persoonlijk voor C++ kiezen omdat het zo snel mogelijk moet werken, voor de beste user experience.

Nu doe je al een aanname dat je bottleneck de taal gaat zijn. Over het algemeen is de grootste bottleneck je developer output. Die pointers en references die je volgens jou 'controle' geven, zijn ook zaken waar je jezelf enorm mee in de voet kunt schieten. Niet voor niets worden pointers in C++ over 't algemeen vermeden.

Ik kan ook niet zo op google vinden dat de WoW servers in java geschreven zouden zijn. Zou leuk zijn als je een source had waar dat bevestigd word.

Jaren geleden (als in 10 ofzo) stonden er een hoop Java vacatures open bij Blizzard voor de WoW back-end. Die ga ik niet voor je kunnen terugvinden, sorry.

[Gomez12]

Ryada schreef op woensdag 9 mei 2018 @ 13:16:
[...]
Ik kan ook niet zo op google vinden dat de WoW servers in java geschreven zouden zijn. Zou leuk zijn als je een source had waar dat bevestigd word.

Zeer waarschijnlijk zijn de WoW servers gewoon in een ratjetoe van talen geschreven zoals bijna alle grotere applicaties.

Wellicht dat een stuk net-code voor de WoW-servers in C++ is geschreven, maar een beheers app kan weer in java geschreven zijn en voor een web-interface / heartbeat kan er weer een node-js/php iets gemaakt zijn.

Er is bij iets als WoW niet 1 ding meer wat echt "de server" is, het is een hele infrastructuur die tezamen voor een heel aantal servers zorgt.

[corset]

Hydra schreef op woensdag 9 mei 2018 @ 13:22:
[...]


Nu doe je al een aanname dat je bottleneck de taal gaat zijn. Over het algemeen is de grootste bottleneck je developer output. Die pointers en references die je volgens jou 'controle' geven, zijn ook zaken waar je jezelf enorm mee in de voet kunt schieten. Niet voor niets worden pointers in C++ over 't algemeen vermeden.


[...]


Jaren geleden (als in 10 ofzo) stonden er een hoop Java vacatures open bij Blizzard voor de WoW back-end. Die ga ik niet voor je kunnen terugvinden, sorry.

Vacatures zijn irrelevant. Je beseft je toch wel dat er een stuk meer draait dan wat servertjes en de game toch? Dat er een stuk meer Java backend kan zijn?

[xzaz]

Je kan ook eens kijken naar Erlang; zelf nooit mee gewerkt maar staat nog op mijn (lange) lijstje van 'proberen'.

[Hydra]

corset schreef op woensdag 9 mei 2018 @ 13:31:
Vacatures zijn irrelevant. Je beseft je toch wel dat er een stuk meer draait dan wat servertjes en de game toch? Dat er een stuk meer Java backend kan zijn?

Het waren vacatures specifiek voor de game servers IIRC. Maar nogmaals; het was 10 jaar geleden, misschien herinner ik het me wel verkeerd. Wel vind ik het grappig dat het zo lastig voor te stellen is dat game back-ends Java zijn kennelijk.

[TheNephilim]

xzaz schreef op woensdag 9 mei 2018 @ 11:54:
Gameservers zijn meestal C++ en relatief simpele sockets, ze verdelen taken in UDP (bv. movement) en TCP (bv. chat).

Als ik me niet vergis moet ik dan heel veel zelf doen (oa. multithreading als ik met niet vergis). Ik ben vooral op zoek naar de manier waarop het één en ander gedaan wordt en niet zozeer naar de meest performante manier. Ik dacht; misschien zijn er veel 'nieuwere' talen in-play, maar dat zal dan wel meevallen inderdaad.

---

Ryada schreef op woensdag 9 mei 2018 @ 12:01:
Nu zal het waarschijnlijk niet fijn zijn dit te horen maar, probeer eerst een goede basis te creëren op de game client kant zonder multiplayer.
Begin simpel en maak bijvoorbeeld een 2d platformer om de API van Unity/Unreal te ontdekken. Servers binnen gamedev zijn nog een niveau hoger dan de client logic zelf omdat je vooral ook rekening moet houden met server authority (je wilt niet dat iedere script kiddie unlimited health op zijn character kan gooien bijvoorbeeld) ook moet je validation etc erin gaan verwerken en zorgen dat het allemaal in sync blijft lopen.
Of hoe wil je interpolation and extrapolation gaan behandelen (client of server sided) en hoe wil je lagcompensation doen, zonder dat je een goede basis hebt over hoe de game client met data omgaat?

Ik ben zelf ook bezig met game development en ga volgend jaar hier ook een hbo studie voor volgen, maar wat ik vooral merk is dat een basis in een game engine een stuk beter is voordat je met Networking begint van een gameserver. Het klinkt allemaal zo makkelijk maar het is echt een heel stuk lastiger dan je zou denken.

Mijn advies is: begin bij de basis en maak een simpele game in Unity/Unreal en ga van daaruit verder. (en zorg natuurlijk voor een goede basis in c++ of C# afhankelijk van of je Unity of Unreal kiest)

Edit: voor iets betere antwoorden op je vraag kan ik je doorverwijzen naar: http://cedric-neukirchen....Cedric_eXi_Neukirchen.pdf
Dit word gezien als het beste document dat bestaat over gamenetworking.

toon volledige bericht

Je noemt hier al een aardig aantal dingen waar ik geen rekening mee gehouden heb, dus ik heb nog veel te leren inderdaad. Ik snap dat het lijkt alsof ik het allemaal heel simpel aanvlieg; maar mijn doel is vooral het basisconcept van dit alles te begrijpen. Doel is om een 2D-game te maken waarin meerdere spelers wat kunnen doen, wellicht wijdt ik nog uit over het precieze idee trouwens.

Kennis van een client hoort er ook bij, maar ik wil zo weinig mogelijk in de client doen en ook met een server aan de slag. Maarja, misschien handig om inderdaad eerst die client in orde te maken inderdaad.

---

CurlyMo schreef op woensdag 9 mei 2018 @ 12:08:
[...]

Idealiter stel je vast welke updates relevant zijn voor een specifieke client en stuur je alleen die update naar hem toe op het moment dat het zich voor doet. Dat is ook het voordeel van websockets. Bij normale AJAX requests moet je client telkens 'vragen' of er updates zijn.

Als je met websockets werkt heeft elke client zijn eigen socket verbinding. Stuur alles wat relevant is voor je client gewoon over die verbinding. Het is niet zinvol om dit te splitsen in meerdere verbindingen per client.

Ik heb al eens wat gedaan met WebSockets; events afhandelen voornamelijk. Niet echt zoiets als van game-server naar meerdere clients.

[...]

Niet per tick, maar event driven. Als er dus niks is gewijzigd is er geen event gebeurt en hoef je dus niks op te slaan.
[/]

Oké maar mijn voorbeeld van bijv. een resource? Dan kun je toch niet anders dan per tick bepalen hoeveel erbij komt?

[...]

Clients kunnen niet direct met andere clients praten, dat moet altijd via de server.

Mja, met oog op cheaten idd wel logisch idd.

Algemeen.
Het lijkt erop alsof je nog niet bekend bent met (web)socket communicatie in een server/client opstellen. Voordat je direct aan een spel begint, leer eerst dat eens kennen door bijv. een chat applicatie. Leer daarna event driven te programmeren en aan het eind een spel te maken met interacties. Als je nu direct een spel maakt, ga je door je onkunde allerlei rare dingen doen die je uiteindelijk doen vastlopen.

Javascript en NodeJS maken het erg makkelijk om event driven te programmeren en asynchrone communicatie mogelijk te maken. Probeer je daar eerst in te verdiepen.

Zoals ik aangaf heb ik al eens iets gedaan met Websockets en events ed., dat lukt wel. Juist wat erbuiten valt, daar heb ik nog moeite mee.

---

ThomasG schreef op woensdag 9 mei 2018 @ 12:19:
Ik raad het gebruik van NodeJS voor (high-performane) low-latency server als een game-server af. In plaats daarvan zou je kunnen kijken naar Java, en specifiek de library Netty (netty wordt door veel grote bedrijven gebruikt, en is qua performance vrij-ongeëvenaard). Er zijn zelfs verschillende voorbeelden de vinden van websocket game-servers in Java met Netty.

Ga ik zeker eens naar kijken, maar doel is vooral een idee krijgen van hoe zoiets werkt. Dat idee kan ik dan later vast toepassen in iets wat een stuk sneller is. Zal eens kijken naar Netty overigens.

---

Hydra schreef op woensdag 9 mei 2018 @ 13:04:
@TheNephilim wat betreft de taal waarin je het ontwikkeld; het is een hobby project dus ik zou gewoon een taal nemen waar jij je senang bij voelt. Breng wel eerst de requirements in kaart; als je er een constante open bidirectionele connectie moet zijn moet je wel teminste een taal + framework hebben dat dit ondersteunt. Wordt het een web game, of een thick-client? Etc. Breng eerst goed de requirements in kaart en kies daarbij de taal, libraries en tools.

Helder! Ik zal me nog eens wat moeten verdiepen in de verschillende soorten netwerkopties die er zijn. Je noemt hier bi-directioneel, dat snap ik, maar constant een open connectie is inderdaad een goeie. NodeJS zou met Websockets een open connectie naar de client hebben, maar communicatie van client naar server moet daar ook overheen. Ik gebruikte tot zover https://github.com/primus/primus, ik zal eens kijken wat die doet.

---

Dus...

Eerst ga ik in Unity maar eens proberen een client te maken. Het is niets meer dan een grote 2D 'map' waar je van bovenaf kijkt en door een venster/camera slechts een deel ziet, middels muis bewegen naar rand scherm verplaats je het venster (Age of Empires idee). Dat eerst maar eens uitvogelen.

Dan door naar de server kant; simpele NodeJS oplossing die positie van verschillende spelers kan regelen.

[Hydra]

TheNephilim schreef op woensdag 9 mei 2018 @ 13:47:
Dan door naar de server kant; simpele NodeJS oplossing die positie van verschillende spelers kan regelen.

Ik zou je hoe dan ook aanraden gewoon eerst een simpele proof of concept te maken waarin je alleen dat doet. Een extreem simpele Unity client (spelers zijn gekleurde bolletjes bijvoorbeeld) en dan een simpele server die posities doorgeeft. Als je het meteen te complex maakt, helemaal in een taal die je niet beheerst, ga je het hoogstwaarschijnlijk niet afmaken.

[TheNephilim]

Hydra schreef op woensdag 9 mei 2018 @ 13:50:
[...]


Ik zou je hoe dan ook aanraden gewoon eerst een simpele proof of concept te maken waarin je alleen dat doet. Een extreem simpele Unity client (spelers zijn gekleurde bolletjes bijvoorbeeld) en dan een simpele server die posities doorgeeft. Als je het meteen te complex maakt, helemaal in een taal die je niet beheerst, ga je het hoogstwaarschijnlijk niet afmaken.

Precies, dat klinkt als goed te doen!

[Rannasha]

TheNephilim schreef op woensdag 9 mei 2018 @ 13:47:


Oké maar mijn voorbeeld van bijv. een resource? Dan kun je toch niet anders dan per tick bepalen hoeveel erbij komt?

Dat soort dingen wil je zoveel mogelijk door de client laten doen. Laat de client maar lekker bijhouden hoeveel resources er binnenkomen. Pas wanneer de client een actie met die resources wil uitvoeren, controleer je aan de server kant of het wel klopt.

Voorbeeld: Client logt in en start met 0 resources en krijgt er 10 per minuut. Na 10 minuten voert de client een actie uit die 70 resources kost. De server verwerkt dit verzoek, controleert hoeveel resources de client hoort te hebben (10 * 10 = 100), en stuurt een bericht terug met het resultaat van de actie en het huidige resource-saldo (30).

Als er een handige Harry de client weet aan te passen, of er is een bug waardoor deze actie na 5 minuten al uitgevoerd kan worden door de gebruiker, dan zal de server dit verzoek weigeren en een bericht terug sturen met het huidige resource-saldo (50).

Door zoveel mogelijk van de spel-logica in de client te houden, kun je flink bezuinigen op de load op de server. Ook kan de client dan vaak beter omgaan met korte interrupties in de verbinding. Je moet dan alleen wel goed aan de server-kant controleren of alle requests vanuit de client kloppen.

[Tk55]

@Rannasha Als toevoeging: Sommige spellen gebruiken bijvoorbeeld client side hit detection. Dit zorgt er dan weer voor dat jij als tegenstander het gevoel krijgt dat jij bijvoorbeeld al fysiek achter een muur stond en alsnog geraakt wordt. Aan de andere kant kan dit, zoals je zegt, voor een soepelere ervaring zorgen bij iets mindere verbindingen.

Je moet dus goed nadenken over wat jij in je spel wilt gebruiken!

[CurlyMo]

TheNephilim schreef op woensdag 9 mei 2018 @ 13:47:
Oké maar mijn voorbeeld van bijv. een resource? Dan kun je toch niet anders dan per tick bepalen hoeveel erbij komt?

Dan heb je dus een timer event.

Mja, met oog op cheaten idd wel logisch idd.

Niet alleen cheaten, peer-to-peer brengt weer een stuk grotere complexiteit met zich mee.

Zoals ik aangaf heb ik al eens iets gedaan met Websockets en events ed., dat lukt wel. Juist wat erbuiten valt, daar heb ik nog moeite mee.

Dat je er iets mee gedaan hebt zegt niet of je het juiste ermee gedaan hebt. Dat laatste is wat ik me afvraag gezien de vragen die je stelt, zoals deze:

NodeJS zou met Websockets een open connectie naar de client hebben, maar communicatie van client naar server moet daar ook overheen.

Je kan een socket niet afgedwongen éénrichtingsverkeer maken. Enige wat je kan doen is verkeer negeren die vanuit je client komt. Het heeft dus 0 zin om voor server - client en client - server twee socket verbindingen aan te leggen..

[TJHeuvel]

Had je deze al gevonden?

https://www.gamasutra.com...ers_on_a_288_network_.php

Overigens gebruiken een hoop Unity spellen PUN of UNET, en zit de meeste logica in de client. Met een speciale client die de verificatie doet is dat enigsinds veilig.

[Ryada]

@Gomez12
Ik zeg nergens dat het niet mogelijk is om in een andere taal (script/programmeer) een server op te zetten die best prima werkt. Ik kijk er over het algemeen een stuk kritischer naar en vraag me af waarom de industry standard dan in C++ is en wat mijn voordeel zou zijn als ik in C# (mijn main language) een server opzet.

Ook snap ik niet waarom Assembly er bij word betrokken, er werden meerdere opties gegeven: C++, Java of Node.JS dan zou ik voor C++ kiezen als ik met games werk, de reden dat ik het zou kiezen heb ik eerder al gegeven.

En ik snap dat er bij Blizzard mbt WoW gigantische infrastructuur aanwezig is en dat vast niet alles daar in dezelfde taal is geschreven. Er werd alleen een statement gegeven dat "Servers van WoW in java zijn geschreven" en aangezien mensen mijn statements helemaal uit zijn voegen trekken vroeg ik gewoon of er ergens een source voor was want ik kan me niet voorstellen dat de game servers van WoW niet in C++ zijn geschreven net zoals de client.

@Hydra
Ik neem nergens een aanname dat de taal de bottleneck is, ik geef alleen mijn standpunt over waarom ik vind dat C++ meer controle geeft dan Java. En waarom ik C++ zou verkiezen voor een server boven Java. Meer heb ik niet gezegd. Indien ik het wel ergens gezegd heb zeg het want dan kan ik mezelf verbeteren.

[ThomasG]

TJHeuvel schreef op woensdag 9 mei 2018 @ 14:31:
Had je deze al gevonden?

https://www.gamasutra.com...ers_on_a_288_network_.php

Overigens gebruiken een hoop Unity spellen PUN of UNET, en zit de meeste logica in de client. Met een speciale client die de verificatie doet is dat enigsinds veilig.

Je hebt dan wel last van client-bias. Wat bij bijvoorbeeld Battlefield enorme frustraties oplevert. Daar gebeurt de hit registratie client-side, dus als de schutter zijn client zegt dat het raak is, is het raak. Dat is een probleem met cheaters, maar ook met lag; als de schutter een hoge ping heeft, heeft hij dus een voordeel; je gaat dan door achter cover, omdat de client door zijn hoge ping jou nog in het open zag.

Client side kan handig zijn, omdat het makkelijker te implementeren is en relatief 'goedkoop'. Maar afhankelijk van het spel kan het een enorm groot nadeel hebben.

[ Voor 4% gewijzigd door ThomasG op 09-05-2018 15:09 ]

[Hydra]

ThomasG schreef op woensdag 9 mei 2018 @ 15:09:
Client side kan handig zijn, omdat het makkelijker te implementeren is en relatief 'goedkoop'. Maar afhankelijk van het spel kan het een enorm groot nadeel hebben.

Ik snap eerlijk gezegd niet goed waarom dat tegenwoordig nog zo'n probleem is. In de 90er jaren kreeg je na Quake QuakeWorld waarbij er aan prediction gedaan werd maar waar 't verder prima werkte. Daar was 't met een ping van 500ms nog best speelbaar maar hadden mensen met een hoge ping geen voordeel.

[TJHeuvel]

Jep, maar dit is een RTS. Zoals het artikeltje wat ik linkt uitlegd is Lockstep vaak de manier om voor dit genre te netwerken waardoor je daar veel minder last van hebt.

Cheaters is inderdaad een groot nadeel.

[Gomez12]

ThomasG schreef op woensdag 9 mei 2018 @ 15:09:
[...]
Client side kan handig zijn, omdat het makkelijker te implementeren is en relatief 'goedkoop'. Maar afhankelijk van het spel kan het een enorm groot nadeel hebben.

Waarom zou client-side makkelijker zijn? Ik voorzie juist een heel gigantisch scala aan problemen voor wat betreft "servers" die spontaan kunnen verbreken, onbetrouwbare server performance etc. etc. etc.

Wat is er makkelijker dan gewoon kunnen connecten naar 1 of meerdere bekende servers waarvan je zelf de specs hebt samengesteld? Connecten met willekeurige adressen waarvan de specs extreem wisselend zijn?

Het is alleen goedkoper om het bij de client neer te leggen en het voorkomt gezeik dat je als publisher de stekker er uit wilt trekken terwijl je klanten nog willen doorgaan. Maar makkelijker nee, die zie ik totaal niet.

[ThomasG]

Gomez12 schreef op woensdag 9 mei 2018 @ 17:37:
[...]

Waarom zou client-side makkelijker zijn? Ik voorzie juist een heel gigantisch scala aan problemen voor wat betreft "servers" die spontaan kunnen verbreken, onbetrouwbare server performance etc. etc. etc.

Wat is er makkelijker dan gewoon kunnen connecten naar 1 of meerdere bekende servers waarvan je zelf de specs hebt samengesteld? Connecten met willekeurige adressen waarvan de specs extreem wisselend zijn?

Het is alleen goedkoper om het bij de client neer te leggen en het voorkomt gezeik dat je als publisher de stekker er uit wilt trekken terwijl je klanten nog willen doorgaan. Maar makkelijker nee, die zie ik totaal niet.

Client-side kun je zaken als hit-registratie, collision-detection en physics veel makkelijker toepassen dan server-side. Zo kun je client-side de renderer gebruiken voor collision en hit-registratie. Dat is server-side een enorme klus, vooral als je je muren etc kapot kunt schieten. Het is dus makkelijker, en goedkoper.

[Hydra]

TJHeuvel schreef op woensdag 9 mei 2018 @ 15:22:
Jep, maar dit is een RTS. Zoals het artikeltje wat ik linkt uitlegd is Lockstep vaak de manier om voor dit genre te netwerken waardoor je daar veel minder last van hebt.

Ik weet dat dat de standaard manier is, maar dat is gewoon omdat het simpeler te implementeren is. Niet omdat het beter is. Je zou toch verwachten van een AAA game dat multiplayer vanaf de start meegenomen wordt en er niet later nog een keer ingehackt wordt. Maarja, da's te idealistisch vermoed ik

[Elfjes]

Je zou ook kunnen kijken naar Spatial OS. Een framework / stuk software / hosting om het maken van (massive) multiplayer games te faciliteren. https://improbable.io/games
Je ontwikkelt zowel voor de server als voor de client in Unity en alle networking, sharding, en authority-issues worden voor je uit handen genomen.

Je bent wel gebonden aan hun cloud en pricing-opties in productie, maar om er mee te developen is gratis

[Gomez12]

ThomasG schreef op woensdag 9 mei 2018 @ 18:04:
[...]
Client-side kun je zaken als hit-registratie, collision-detection en physics veel makkelijker toepassen dan server-side. Zo kun je client-side de renderer gebruiken voor collision en hit-registratie. Dat is server-side een enorme klus, vooral als je je muren etc kapot kunt schieten. Het is dus makkelijker, en goedkoper.

Tja, dan kom je in een discussie over wat client-side is en wat niet etc. Ik zie client-side als echt dat de consumer een server is (oftewel je hebt te maken met onbetrouwbare internetverbindingen etc)

Ga je het over code hebben dan zie ik geen reden waarom je server-side niet gewoon een soort client++ kan draaien. Dan ben je van de code-issues die jij noemt af en heb je toch wel verbindingen waarvoor SLA's afgegeven kunnen zijn etc.