Skip to content

USE CASE: MULTIPLAYER

In grote lijnen is multiplayer een eenvoudig concept. Gebruikers moeten gegevens naar andere gebruikers kunnen verzenden en ontvangen. Dit toepassen op het expertisegebied van de klant was vrij eenvoudig.

Mensen die binnen fietsen en een virtuele fietstocht maken, moeten anderen op dezelfde weg kunnen zien als zij. Op een GPS-kaart moeten ze ook andere mensen om zich heen zien fietsen, niet noodzakelijk op dezelfde weg als zij.

Het moeilijke deel is natuurlijk om de gegevens van de ene gebruiker naar de andere te brengen. Het moet ook heel snel gebeuren, zodat iedereen alle anderen ziet op de positie dat ze effectief zijn. En bovendien zou alles moeten werken voor duizenden gebruikers die hetzelfde ding tegelijkertijd doen.

In grote lijnen is multiplayer een eenvoudig concept. Gebruikers moeten gegevens naar andere gebruikers kunnen verzenden en ontvangen. Dit toepassen op het expertisegebied van de klant was vrij eenvoudig.

Mensen die binnen fietsen en een virtuele fietstocht maken, moeten anderen op dezelfde weg kunnen zien als zij. Op een GPS-kaart moeten ze ook andere mensen om zich heen zien fietsen, niet noodzakelijk op dezelfde weg als zij.

Het moeilijke deel is natuurlijk om de gegevens van de ene gebruiker naar de andere te brengen. Het moet ook heel snel gebeuren, zodat iedereen alle anderen ziet op de positie dat ze effectief zijn. En bovendien zou alles moeten werken voor duizenden gebruikers die hetzelfde ding tegelijkertijd doen.

1. Vereisten

Er zijn enkele beperkingen om rekening mee te houden. Ten eerste is het onmogelijk om gegevens direct over fysieke afstanden te verzenden. Het kost ook enorm veel tijd om iets te maken dat oneindig schaalbaar is. En tot slot vereist het snel verzenden van grote hoeveelheden gegevens een stevige internetverbinding.

Omdat we de multiplayer zo toegankelijk mogelijk wilden houden, moesten we beslissen welke marges acceptabel waren. We hadden niet de tijd, noch de middelen om de beste multiplayer ter wereld te bouwen. We zouden er echter een kunnen bouwen die aan de onmiddellijke en toekomstige behoeften van de klant zou voldoen.

Om dit te doen, moesten we de vereisten neerleggen waaraan het multiplayersysteem moest voldoen:

  • De apps moesten 2 updates per seconde verzenden en ontvangen
  • Het systeem zou 10.000 gebruikers tegelijkertijd moeten kunnen ondersteunen, met de mogelijkheid om in de toekomst verder te groeien
  • De kosten per gebruiker moesten lager zijn dan € x per maand

2. De zoektocht naar een goede netwerktechnologie

Een multiplayer staat of valt met zijn netwerktechnologie. We zijn niet zo trots om toe te geven dat echte netwerkingenieurs veel meer van deze dingen weten dan wij, dus in plaats van te proberen onze eigen netwerktechnologie te creëren om gegevens van A naar B te krijgen, hebben we besloten om te zien of er producten beschikbaar waren die precies dat deden als hun belangrijkste focus.

We hebben een volledige lijst van mogelijke technologieën gemaakt en een paar belangrijke functies van elk genoteerd (indien beschikbaar). Vervolgens stelden we een paar sterke kandidaten voor om deze nader te bekijken. In overleg met de klant hebben we twee zeer sterke kanshebbers gekozen. Op papier waren ze allebei even goed, maar toch moesten we er een kiezen. We besloten om ze allebei aan een vuurproef te onderwerpen.

uLink/UnityPark
Photon
SmartFoxServer
AppWarp
Lidgren
KBEngine
Forge
RakNet
Nakama
Colyseus
Badumna
ElectroServer
RedDwarf
NetDog
PikkoServer
Player.IO
SlimNet
Union
Orbit
Gamooga
Azure Gaming – Playfab

 

3. Proof of concept

Er werd een test-appje gemaakt dat stippen op een GPS-kaart liet bewegen over een vooraf ingestelde route. De gegevens voor deze stippen werden via het netwerk verzonden en kwamen dan terug om deze daadwerkelijk te verplaatsen. Er konden meerdere apps op verschillende pc’s worden uitgevoerd en ze moesten allemaal dezelfde punten op dezelfde locaties zien. Bovendien zou elke app meerdere stippen moeten kunnen maken en ze zouden op hun beurt ook te zien zijn in andere apps. Van deze app werden vervolgens twee versies gemaakt, één voor elke netwerktechnologie, zodat we konden zien welke beter presteerde in een real-life scenario.

4. Serverarchitectuur

De klant stemde ermee in toen we voorstelden deze multiplayer-oplossing in de cloud te gebruiken. Dit bracht een aantal interessante voordelen met zich mee, zoals betere schaalbaarheid en de mogelijkheid voor gebruikers om verbinding te maken met een datacenter in hun buurt.

Een ‘kamer’ (of room) is een verzameling gebruikers die elkaar kunnen zien. Gebruikers mogen alleen updates ontvangen van andere gebruikers die ze kunnen zien. Dit beperkt de bandbreedte tot een minimum. Een gameserver kan één of meer van dergelijke ruimtes hosten. Wanneer meer capaciteit nodig is, kunnen we gewoon een nieuwe gameserver toevoegen om de verhoogde belasting aan te kunnen.

Er bleven echter twee problemen. Afhankelijk van de timing konden gebruikers op dezelfde weg in verschillende kamers worden geplaatst, waardoor ze elkaar niet konden zien. Dit kwam voort uit het feit dat de app de server eerst vroeg of er ruimte beschikbaar was. Als die er niet was, werd de ruimte aangemaakt en werd er deelgenomen. Als dat wel zo was, werd er gewoon deelgenomen.

Dit kon ertoe leiden dat twee clients tegelijkertijd om een bepaalde kamer vroegen, voordat een van hen een kamer kon creëren. De server vertelde ze allebei dat zo’n kamer niet bestond en dat ze er een moesten aanmaken. Beide clients maakten vervolgens een kamer voor dezelfde route. Het resultaat was dat ze elkaar niet konden zien.

Als we een enkel punt lieten beslissen wanneer we een kamer wilden creëren en wanneer we lid wilden worden van kamers, zou dit altijd consistent zijn, omdat het punt weet wanneer het een kamer heeft gecreëerd en dat gelijktijdigheidsproblemen kunnen worden opgelost.

Enter de matchmaking-server…

Het andere probleem was dat standaard elk bericht dat een app verzond, werd gedupliceerd en naar elke andere client verzonden. Hoewel dit oké lijkt, zelfs logisch, wordt het probleem eerst duidelijk wanneer we wat wiskunde toepassen.

n = aantal gebruikers
Aantal berichten verzonden naar server = n
Aantal berichten verzonden door server = n * (n – 1)

Als we 100 spelers op dezelfde route hebben die 100 berichten naar de server sturen, komen er 9900 berichten terug. En we willen graag twee berichten per seconde, wat neerkomt op 19800 berichten per seconde. Dat is een beetje veel.

Dus hebben we wat custom logica gemaakt om op de server te worden uitgevoerd. Code die updates bundelt en alleen een bericht naar de client verzendt met een ingesteld interval. We gingen zelfs nog een stap verder: we verzenden alleen welke gegevens nieuw zijn voor die specifieke app, zodat er geen onnodige gegevens worden verzonden. Dit vermindert het gebruik van bandbreedte aanzienlijk.

5. Implementatie in alle apps

Nu we wisten hoe, creëerden we de serverconfiguratie en -implementatie, met behulp van de proof of concept-app om te testen. Toen we er zeker van waren dat alles “up and running” was, was het tijd de nieuwe multiplayer te laten implementeren en gebruiken in de end-user apps. Er werden meerdere apps ontwikkeld en onderhouden door verschillende teams. Om ervoor te zorgen dat alles zo snel mogelijk geïmplementeerd kon worden, hebben we uitgebreide documentatie gemaakt:

  • Een overzicht van elke multiplayer component en hoe deze op hoog niveau werkt
  • Een gegevenscontract dat beschrijft welke berichten moet worden verzonden en ontvangen van de multiplayer, tot op niveau van bits en bytes
  • API-documentatie van de matchmaking-servers, waarin wordt beschreven hoe HTTP-oproepen kunnen worden gedaan en hoe de antwoorden eruit moeten zien
  • Een gegevensdiagram van alle velden die in het multiplayersysteem worden gebruikt en waarvoor ze dienen

6. Resultaat

Deze multiplayer werd gereleased voor het publiek, net voor het drukke seizoen van onze klant in 2019. Hij loopt sindsdien ononderbroken en zonder grote problemen. De nieuwe multiplayer leidde tot een record aantal online gebruikers, een ongekende groei en behoud van abonnees, doordat gebruikers kunnen genieten van samen te fietsen vanuit het comfort van hun eigen woonkamer.

We beantwoorden graag al je vragen!