Zweeds bedrijf werkt aan mmo-server voor duizend spelers

Het Zweedse netwerktechnologiebedrijf PikkoTekk maakt serversoftware om duizend spelers tegelijk in een spelwereld te laten spelen. PikkoTekk bouwt een mmo-fps die in de browser wordt gespeeld om de technologie te demonstreren.

De demo zal 'Tanks versus Robots' heten en moet de werking van Pikko Server aantonen. PikkoTekk mikt erop dat duizend spelers tegelijk in dezelfde wereld met elkaar de strijd kunnen aangaan zonder merkbare vertraging. Het Zweedse bedrijf wil dit bewerkstelligen door de spelwereld te verspreiden over verschillende cell-servers, die worden aangestuurd door een centrale Pikko Server.

Voor de demo maakt PikkoTekk gebruik van de Unity Web Player, die is omgebouwd om gebruik te maken van Pikko Server. Volgens het bedrijf kunnen zo ook andere game engines worden omgebouwd en is de aanpassing relatief eenvoudig. Er worden acht cell-servers ingezet, die samen 1000 spelers moeten accommoderen. De client zal van de 125 dichtstbijzijnde spelers 15 world state snapshots per seconde ontvangen; de updates van de overige spelers komen drie keer per seconde binnen. Dit resulteert volgens PikkoTekk in 11,6 kilobyte per seconde aan dataverkeer. Wanneer Tanks versus Robots te spelen is, is nog niet bekend.

PikkoTekk heeft inspiratie opgedaan bij de telecomwereld om een naadloze spelwereld neer te zetten. Volgens het bedrijf is een cell-server te vergelijken met een telefoonmast voor mobieltjes, die een deel van de virtuele wereld voor zijn rekening neemt. De gebieden die door cell-servers worden afgehandeld overlappen elkaar gedeeltelijk, zodat een handover van de ene naar de andere server naadloos verloopt. Dit werkt niet alleen voor spelers, maar ook voor bijvoorbeeld afgeschoten kogels. De 'mast' van een cell-server kan live in de spelwereld worden verplaatst om cell-servers in drukkere spelgebieden te ontlasten. De centrale Pikko Server stuurt deze processen aan en bezorgt complete updates van de spelwereld bij de spelers.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (100)

[Dooxed]

Interessant.. 125 users keer 15 updates per seconde plus de overige spelers (1000-125) keer 3 keer per seconde is 4500 updates per seconde. De hoeveelheid data per seconde is 11,6 KB, dit betekent dat een update ongeveer 2,5 byte is. Lijkt mij erg weinig voor een nuttige update!

Tenzij de wereld 1 dimensionaal is en het spel heel erg saai, want dan hoef je alleen maar verschillen in locatie door te geven..

Edit: Bron geeft het antwoord, het is 11.6 KB per update. Is ook raar, want dat is bij 4500 updates 50 MB/s. Misschien zijn er verschillende typen updates.

Edit: filmpje laat een 2D wereld zien (als de saucers niet mee vechten, en daar lijkt het op), dat zijn dus twee coordinaten plus een rotatie. Verder is er nog een tijd van schieten nodig (denk ik, ik heb geen ervaring in game design / programmeren) dus een totaal van 4 variabelen die geupdated moeten worden. Variabelen die enigzins nauwkeurig moeten zijn, dus dat zou niet echt in 2,5 byte kunnen passen, imho.

Edit 2: En ik heb overhead van de verbinding / datastructure nog even buiten beschouwing gelaten, dus in principe is er nog minder over voor de daadwerkelijke update.

[Reactie gewijzigd door Dooxed op 22 juli 2024 18:54]

[sdk1985]

"Edit: Bron geeft het antwoord, het is 11.6 KB per update. Is ook raar, want dat is bij 4500 updates 50 MB/s. Misschien zijn er verschillende typen updates."

Je hebt het niet goed begrepen. Het is dus 3 pakketten voor ALLE 875 andere spelers, en niet 875 x3 en het is ook geen 50MB/s per speler. Je haalt ook down en upstream door elkaar. Downstream is 420 kbits/s per speler.

In dezelfde bron:
"Total bandwidth downstream perplayer 420 kbit/s"
"World state snapshots per second, sent to all clients[1] 15 (for the 125
avatars closest to your avatar) 3 (for the other 875 avatars)
[1]=Includes for example the position, rotation and velocity for all avatars in one game server."

Overigens blijkt een client zelf 11 acties aan de server door te geven; 10 x movement en 1x fire.

Ik heb ooit vastgesteld dat 100 spelers op een world of warcraft server emulator nauwelijks upload verbruikt. Het grote probleem was toen processorkracht en geheugen. Een teamspeak 3 server gebruikt overigens ook slechts 1.59- 4.03 KiB/s per client en daar gaat heel wat meer overheen dan alleen ruwe coordinaten.

[Reactie gewijzigd door sdk1985 op 22 juli 2024 18:54]

[Caelorum]

De wereld is 3d. Er zijn namelijk ook hoogte verschillen te zien in het filmpje.
Er zijn waarschijnlijk meer variabelen nodig waaronde bijv. Health, Ammo, positie, verplaatsingsvector, actie die wordt ondernomen etc.

@YopY: Klopt. Ik wilde alleen maar aangeven dat zelfs voor een klein spel er soms best veel data over de lijn heen kan gaan (en dan voornamelijk naar de client toe).

[Reactie gewijzigd door Caelorum op 22 juli 2024 18:54]

[YopY]

Variabelen wel, maar bij het merendeel van de updates wordt daar niks mee gedaan (health / ammo / actie) totdat die daadwerkelijk verandert (en om de zoveel tijd een synchronisatieslag om evt. gemiste updates recht te trekken).

[Dooxed]

De wereld is 3D, maar als de tanks / aliens alleen op het oppervlak rijden, heb je maar 2 coordinaten nodig om precies de locatie te weten. De hoogte volgt dat automatisch uit de map.

[Ventieldopje]

Klinkt awesome maar zo bijzonder is het niet...

http://massively.joystiq....eve-onlines-server-model/

[Sissors]

Eve is compleet niet seamless (zo ongeveer het omgekeerde), wat het heel veel makkelijker maakt. Daarnaast is het ook nog eens compleet onmogelijk om load dynamisch te verdelen en moet (serieus) de complete cluster offline gehaald worden om dat te veranderen.

[Ventieldopje]

Ohja? Ik meen dat dit tegenwoordig toch al echt dynamisch geregelt is Let er op dat het artikel wat ik plaatste al vrij oud is he, er zijn heel wat veranderingen geweest sinds die tijd, zelfs een heuse verhuizing

[Sissors]

Ja en load balancing is onafhankelijk van je aantal smileys nog lang niet dynamisch geregeld. Waarom denk je dat fleet fight notifications minstens 24 uur vantevoren binnen moeten zijn? Omdat er bij de volgende downtime dan systemen naar andere nodes gemapped kunnen worden, dat kan niet dynamisch gebeuren als dat systeem er problemen mee krijgt.

[Abom]

Ik ben ook niet zo heel erg impressed. Turbine had vergelijkbare techniek al in 1999 met hun mmorpg Asheron's Call. Sterker nog, bij die engine wordt de wereld dynamisch verdeeld over de verschillende servers. Is het op plek X druk, dan wordt de wereld herverdeeld en meer servers ingezet om plek X te verwerken. Ik heb wel situaties gezien van honderden spelers op een bepaalde plek, maar 1000 zal men destijds niet gehaald hebben, dan werden mensen weggeteleporteerd om de load toch te kunnen afhandelen. Maar er zijn vast wel momenten geweest dat er meer dan 1000 spelers tegelijk in de seamless wereld rond hebben gelopen.

[Reactie gewijzigd door Abom op 22 juli 2024 18:54]

[Verwijderd]

We've now reached a new milestone in EVE Online, with 60,453 pilots logged in today during Alliance Tournament VIII. Our thanks goes out to the many players who made this happen. The bar has been raised and we look forward to what the coming weeks will bring in tandem with Alliance Tournament VIII and the Planetary Interaction land rush.

Dat zijn dus 60k+ spelers in dezelfde spelwereld. Als er 1000-1500 mensen vechten in een system wordt het wat lastiger... maar er zit verbetering in.

[Caelorum]

De wereld van Eve Online is echter verre van seamless met zijn jumpgates of hoe die dingen ook worden genoemd.

[Ventieldopje]

Dit zou best seemless gemaakt kunnen worden, achter Jita hangen ook dynamisch meerdere servers terwijl je daar niks van merkt

[Sfynx]

Jita draait gewoon op 1 server, net zoals alle andere solar systems. Alleen jita heeft gewoon een dedicated server waar geen andere solar systems op draaien.

Met de methode hier beschreven zou je de load van Jita kunnen verdelen over alle servers. En ook de load van dat ene gigantische gevecht op die ene onverwachte locatie ergens in een uithoek van het universum. Zonder notificatie aan CCP vooraf en een bijbehorende remapping tijdens downtime. Die remapping vindt plaats als het gevecht begint, ongemerkt. Nooit meer de situatie dat 1 server compleet over z'n nek gaat terwijl de andere uit hun neus staan te vreten. Zoals het een echt gedistribueerd systeem betaamt.

Hey CCP, ik zeg: doen.

[Reactie gewijzigd door Sfynx op 22 juli 2024 18:54]

[Caelorum]

Die zullen zeer waarschijnlijk als 1 alles afhandelen. Waarbij bij dit systeem elke server verantwoordelijk is voor 1 klein deelgebied, welke ook nog eens live kan worden verplaatst.

[Abom]

Bij WoW zitten ook veel spelers in dezelfde wereld, maar daar zijn overal portals die je naar andere delen van de wereld brengen of naar een instance. Bij AC is het een echte seamless wereld, daar kun je dus een rondje lopen over de hele wereld (waar je een dag mee zoet bent) en hoeft door geen enkele portal te lopen, je wordt wel van server naar server getransporteerd, maar dat gebeurt seamless.

Ik ken EVE Online verder technisch niet. Maar wat ik in het artikel lees heeft EVE dezelfde problemen als AC bij densly populated spaces.

[YopY]

Maar dan heb je het ook over 1999 - sinds die tijd heeft de technologie niet stilgestaan, en zou je met dezelfde software meer gebruikers af kunnen handelen.

[Sfynx]

Stel je de EVE cluster voor, maar dan ook de load van de solar systems en zelfs van de aparte grids in solar systems verdeeld tussen meerdere servers. Dan heb je ongeveer waar het hier over gaat. Nu draait een solar system altijd op 1 server.

[Herko_ter_Horst]

Mooi systeem, ben wel benieuwd wat dit gaat doen voor de lag/nauwkeurigheid.

[Verwijderd]

Inderdaad. De route Speler A - Server - Speler B is een standaard dilemma. Calculatie bij de client zorgt voor manipulatie (cheats) en calculatie op server heeft vertraging als gevolg omdat die data weer terug moet naar de clients.

Het kunnen afsplitsen van drukke gebieden is wel een voordeel maar heeft weer een extra tussenstap tot gevolg. De lag wordt hierdoor nooit kleiner. Het ontlast wel weer servers. Of dit gedaan moet worden door de gameserver of door het besturingssysteem is een heel ander verhaal.

Ik ben niet overtuigd van het concept maar heb wel bewondering voor het feit dat ze iets niet-standaard proberen.

[YopY]

Niet-standaard? Het is al jaren gemeengoed in mobiele telefoonnetwerken, zoals het artikel aangeeft, dus het is al wel gebaseerd op bewezen technologie / ideeën.

[Verwijderd]

Zo kan je alles generaliseren. Alle data is niet meer dan eentjes en nulletjes...

Het "niet-standaard" heeft betrekking op de toepassing (gameservers). Daar is het niet-standaard en daarom heeft het dus nieuwswaarde (aldus resulterend in het bovenstaande artikel).

[Qreed]

Niet-standaard? Het is al jaren gemeengoed in mobiele telefoonnetwerken, zoals het artikel aangeeft, dus het is al wel gebaseerd op bewezen technologie / ideeën.

Nee.

Dit is wel degelijk een nieuwe techniek: in vergelijking met andere MMO's segmenteerd dit veel dieper. De vergelijking met steunpalen van mobiele netwerken beslaat maar een klein gedeelte van de complexiteit die hier bij komt kijken: ooit dynamisch steunpalen uit de grond zien groeien (en inkrimpen) op basis van het aantal aanwezige mobiles op 1 fysieke locatie?

[YaaD]

Ik weet niet zo goed wat ik hiervan moet vinden. Als ik naar het filmpje kijk word ik redelijk treurig

Verder ben ik bang dat er altijd een vertraging zal zijn. Lijkt mij dus niet haalbaar. Dan kunnen de servers nog zo goed zijn, als de speler een langzamere verbinding heeft is er al een vertraging merkbaar

11KB per seconde resulteert in ongeveer 39000KB per uur. Ongeveer 39MB wat er dan over het netwerk gaat. Oke, toegegeven is dat niet veel maar vraag me af of dat ook haalbaar is...

[freaq]

dit is een demo om te laten zien dat het werkt,
dit is 99% programmer/ standin art, waar het om gaat is dat er 1000 man tegelijkertijd kunnen gamen op 1 server, en dat volgends hen relatief lagvrij kan, en dus zelfs shooters gespeeld kunnen worden in die omgeving,

dat is impressive, en dus moet je even om de graphics hen kijken en alleen kijken naar de techniek.

[Xanaroth]

Vertraging in vergelijking tot..?

Je zal inderdaad altijd de 'standaard' vertraging houden van 25-30ms (misschien kan daar nog iets vanaf, maar dat is al haast niet merkbaar), daar kan je haast niet omheen. Maar in plaats van een 100-200ms bij drukte kan het nu ook gewoon 25-30 blijven en dan heb je een behoorlijke verkleining van de vertraging.

[sdk1985]

Ze geven zelf aan dat dit systeem gehost 30 ms mediaan heeft en dat de client in het datacenter stond. Daar komt dus nog de delay tot het datacenter bij.
"7] Measured as the time it takes for a game client to send an RPC message to a game server and get a response, when
1000 players are online. Measured from a third hardware with a game client running in the datacenter."

[Reactie gewijzigd door sdk1985 op 22 juli 2024 18:54]

[MekZi]

Kan uit ervaring vertellen dat bij gevechten van 1000 man in EVE je de neiging gaat krijgen om suicide te plegen. Zo veel lag en je moet allerlei maatregelen nemen uberhoud wat te kunnen doen tijdens zo'n gevecht. (NC WI dot best dot (binnenkort R.A.G.E. member))

[Verwijderd]

Ik vraag me af wat voor verschrikkelijke lag ze hadden bij die 3600 man battle een hele tijd terug, hoorde iets van een half uur lag ofzo >.<

En CCP verbertert nog steeds, langzaam maar zeker komt de grens weer hoger te liggen (Alhoewel ze het waarschijnlijk weer ver****ken met de eerstkomende expansion).

On-topic: Intressante technologie inderdaad, nou nog ff afwachten hoe goed het in de praktijk werkt, ipv ideale lab omstandigheden.

P.S.: Goon hiero, groeten uit deklein ^^

[Sfynx]

Hallo beste buur... BFF!!!

(Ik leef in Tribute... Morsus Mihi )

[Evion]

Kijk! Dit is pas goed nieuws!

[Noxious]

Het is vernieuwend voor het soort games wat ze willen aan bedienen, maar spellen als EVE Online draaien ook met een vergelijkbaar serversysteem.

[Cergorach]

Uhm... Nee! Eve-Online mag dan wel 60.000 spelers tegelijk in het spel hebben gehad (en regelmatig 50.000+), maar dat draait niet op één server, dat is een behoorlijke cluster. Toevallig is er een enkel systeem wat dedicated op één server draait, dat is Jita, daar zitten dan wel 1500-1700 spelers op, maar daar wordt zeker niet gevochten. Er zijn altijd issues met performance en lag, ik weet dan ook niet of veldslagen met 1000 spelers momenteel mogelijk zijn, maar grote veldslagen worden (mits tijdig aangegeven bij de maker) tijdelijk verplaatst naar een dedicated server. Maar Eve-online is zeker geen FPS.

Maar zo te zien is dit ook een cluster van een hoofd server en acht sub servers.

[Rafe]

Ook daar zitten verschillen. EVE bestaat uit een servercluster met een of meerdere zonnestelsels (spelwerelden/levels/etc) op een server (node). Die zonnestelsels kunnen verplaatst worden naar andere servers als het in één sterrenstelsel heel druk wordt, om zo rekenkracht vrij te maken.

Wat deze Zweden doen maakt het mogelijk om de load van een spelwereld/zonnestelsel te verspreiden over meerdere servers. Als er dus bij planeet A en bij planeet B in stelsel X flink gevochten wordt, zou dat door bijvoorbeeld twee (of meer) cell servers kunnen worden opgevangen. Bij EVE komt die last altijd op een server terecht.

[Ayporos]

Er is een daadwerkelijk GROOT verschil tussen de multi-server hosting oplossing van EVE Online en deze nieuwe servertechniek.

EVE Online heeft een aantal bladeservers (een grote 19" rackmount waar je 'servers' als insteekslot in schuift) waar per bladeserver per CPU zonnenstelsels aan toegewezen worden.
Beseft dat meerdere zonnestelsels op èèn CPU passen, maar èèn zonnenstelsel niet meerdere CPU's kan gebruiken (ook niet op dezelfde blade) wegens programmeertaal limitaties. Dit levert problemen op wanneer tijdens een grote powerblock vs powerblock oorlog makkelijk 50% van alle logged-in gebruikers zich in èèn zonnesysteem kunnen bevinden. Kijk, het punt met eve is dat je van server switcht wanneer je van zonnestelsel switcht gebruikmakend van een 'jump gate' die een vertraging/qeue/laadscherm met zich mee kan brengen en dus zeker niet 'seamless' is. Overigens is het wel zo dat binnen het zonnenstelsel er ook nog 'gebieden' zijn waarin je wel of niet vijanden kunt zien (en ermee interacten), wat wel weer 'seamless' in elkaar overloopt.. maar dit is allemaal binnen hetzelfde zonnestelsel op dezelfde CPU op dezelfde server dus niet vergelijkbaar.

Dìt nieuwe ding van PikkoTekk hevelt mensen over SEAMLESS tussen verschillende hardware servers èn gebruikt de 'dichtstbijzijnde 125' spelers, in tegenstelling tot het gebied gebonden systeem van EVE Online.


In vele opzichten is dit een beter systeem dus.. Zonder de code erachter te weten kan ik natuurlijk niet zeker zijn, maar ik kan me zo voorstellen dat het beter schaalbaar zal zijn dan de 1CPU limitatie waar CCP's EVE Online mee te krampen heeft.

[FireDrunk]

Ik speel toch echt WoW op een server met meer dan 4000 concurrent users...
En dat draait toch echt op 1 fysieke server...

[psychodude]

De WoW realms draaien niet op 1 fysieke server, maar draaien load balanced over verschillende servers. Hierdoor kan 1 server eruit knallen waardoor een deel van de wereld niet langer toegankelijk is. Ook trekt één server het slecht zodra er 200+ man binnen een kleine zone zitten, want dat wordt dan weer niet opgesplitst over verschillende servers.

Wat dit bedrijf dan weer doet is dat laatste juist weer wel opsplitsen. Waardoor je op één zo'n load balanced server 1000 man kwijt zou kunnen (en theoretisch waarschijnlijk nog wel meer als je het aantal cell servers gewoon opvoerd).

Uiteindelijk zouden dit soort combinaties van technieken en methodes er dan weer toe kunnen leiden dat MMO realms niet langer met een stuk of 5.000 spelers zitten, maar met een stuk of 50.000 zonder de tevens verdere problemen hierbij voor de server hardware zoals nog wel eens bij EVE gezien wordt in drukke battles.

Het volgende probleem is dan helaas wel weer de eventuele client side lag. Sommige mensen trekken 30 characters in Stormwind al slecht, laat staan 500 in Stormwind. Hun computers zullen waarschijnlijk direct op sterven na dood liggen.

[Navi]

Ik denk dat Firedrunk bedoelt op de niet officiele WoW private servers. Dat draait vaak op 1 bak en daar kunnen best 4k users in zitten.

[Bonez0r]

Ik denk dat de verwarring ontstaat doordat je bijvoorbeeld een character kunt maken op een 'server'. Alleen is dit niet echt een enkele fysieke server, het wordt alleen vaak een server genoemd, Blizzard zelf noemt het een realm. Elk realm (ze hebben elk een unieke naam) is een volledige wereld. Deze wereld draait echter op verschillende fysieke servers, per continent en voor instances. Met deze ouderwetse methode krijg je dus inderdaad problemen als veel mensen zich in één gebied bevinden (opening van de AQ gates in 2006 is een goed voorbeeld, honderden/duizenden mensen bij elkaar = server crashes uren achter elkaar)

[Bulls]

Als je 50.000 spelers op 1 server hebt met een MMO heb je nog meer trammelant met mensen voor dezefde quest item te pakken of te plukken, om maar niet te spreken over de boss die 1x om de 5 minuten spawned.

[Verwijderd]

Van WoW weet ik dat die dynamic spawnrates heeft. Meer spelers = snellere respawn. Dit is vooral merkbaar in de daily quest gebieden van zuidelijk Tol Barad waar npc's op een 5-10 sec respawn timer zitten als het druk wordt.
Tevens geven veel van de named kill mobs een questcomplete voor iedereen die damage heeft gedaan erop, of je hem nu tagged hebt of niet.

Als een mmo wordt ontwikkeld voor 50k spelers zullen dit soort system wel overal worden toegepast.

[Bulls]

Het beste is voor "oppak quests" is gewoon de item laten liggen voor iedereen die hem moet hebben en enkel te laten verdwijnen voor de genen die hem gepakt heeft. Of alleen het sprankeltje eromheen laten verdwijnen.

Wat heb ik me geërgerd aan bepaalde gather quests in Age of Conan, je moet 5 dingen hebben en er staan er 7, terwijl je met een team ze moet halen. Ben je zo een uur verder voordat iedereen er genoeg heeft.

[silentsnake]

Dat laatste komt puur door de grote hoeveelheid textures die van disk afgehaald moeten worden. Gooi WoW maar eens op een SSD en je kan zonder veel client side lag door een grote stad heenlopen. Natuurlijk is dit een lastig probleem aangezien je de balans moet leggen tussen textures laden en memory gebruik. Als een oud bakkie gaat swappen heb je er helemaal niks aan.

[MSalters]

Klopt. Zelfs Stormwind of Vashj'ir op Cata launch day was geen enkel probleem met een SSD. Zelfs dan heb je zelden meer dan 500 andere users binnen zichtafstand.

[Macfreakje]

Dat is niet waar volgens mij heeft WoW ook voor elke continent een aparte server draaien. Dat is mij in ieder geval opgevallen toen bijvoorbeeld de outland server crashte kon ik niet op die character in outland inloggen en mijn characters op andere continenten konden wel gewoon inloggen.

[kozue]

En alle spelers die in een vorm van instance zitten (dungeons, raids, BG, arena, etc) zitten niet in de gewone spelwereld en nemen dus geen resources van de world server in. Het zou me niks verbazen als WoW problemen zou krijgen als plotseling niemand meer in instances zit er de world server daadwerkelijk 4000 spelers tegelijk moet faciliteren.

[DrClaw]

ik heb ook wel eens nagedacht over dit soort technieken voor een mmo zoals wow.

in mijn gedachtengang bestond een continent dan uit tientallen servers, waarbij elke server een groepje spelers van een onbepaald gebied bediende. empirisch zou bepaald worden wat de spelerscapaciteit van zo'n clusternode zou zijn, maar stel nou, voor het voorbeeld, dat dat 200 zou zijn.
Die 200 spelers zitten nooit op de plek waar de game-ontwikkelaar ze wil hebben. een free-roam world daagt nou eenmaal uit om alles te ontdekken wat er te ontdekken valt. dus de clusternode moet wel met de spelers mee gaan.

even een practisch voorbeeldje: stel wow zet weer een stel seasonal quests open in 2 noordelijke provincies, dan zit het merendeel van de spelerspopulatie dus daar, en dus moeten de cluster nodes daar ook zitten.

het idee is dus, dat je het verkeer tussen de nodes minimaliseert, omdat dat nou eenmaal 'duur' is .. als je alles in het interne geheugen van de node kunt houden dan is dat nou eenmaal efficienter.

maar, je zult op een gegeven moment spelers van de ene node naar een andere moeten overhandigen. iedereen gaat nou eenmaal zn eigen ding doen. en je wilt niet, dat een speler die handoff merkt. vandaar dus de overlap van de nodes ..

wow past echter een paar truuks toe om het makkelijker te maken voor de cluster nodes. zo ijn grote steden, en instances en raid areas aparte werelden. compleet met laadtijd. maar ook bijvoorbeeld in de grote steden zoals orgrimmar en iron forge zie je vlak bij de auction houses vaak lagging, gewoon omdat die cluster nodes zo dicht op elkaar zitten (#players is groter dan de limit van de nodes daar).

en vroeger dwongen ze de spelers om grote afstanden af te leggen tussen de plekken die veel players trokken (de auction houses en de postbus bijvoorbeeld, die stonden ooit op een plek zonder line of sight, om zo makkelijker een schifting te maken in de player populatie).

enfin, om een verhaal kort te maken (!) .. de communicatie tussen de server nodes moet geoptimaliseerd worden, en die is afhankelijk van het aantal spelers per node, de handoff, en de database transactiesnelheid van elke node (want de wereld moet nou eenmaal consistent blijven).

en mijn idee van het opsplitsen van de spelerpopulatie was trouwens gebaseerd op voronoi diagrammen .. zeg maar zeepbellen. werkte prima om 'workload' te verdelen in mn virtuele clustertje, al kon ik het alleen niet op grote schaal testen capaciteitsproblemen...

[bbr]

Wow draait of verschillende servers. Aszune bijvoorbeeld zijn er ten minste al 6.
Je merkt ook als een bepaald deel offline gaat dat het andere continent bijvoorbeeld nog gewoon werkt.

Maar bij wow zijn er ~ 12.000 spelers per server, maar slechts 4-5K tegelijk online.
Dus ongeveer vergelijkbaar.

[varkenspester]

Nee, Wow draait echt NIET op 1 fysieke server per realm.
1 server per continent + aparte servers voor de instances en BGS.

[coretx]

Vergeet niet dat bijv. de market databases op dikke RAM SAN's draaien.
( 10 TB SLC Flash storage, 1,000,000 IOPS (10 GB/s) r )

Het valt mij frequent op dat mensen die EVE gillen, en mensen die iets tegen EVE hebben beiden zichzelf van verkeerde argumenten bedienen en appels met peren vergelijken.
Ook is de informatie over EVE frequent verouderd gezien ze constant aan het systeem sleutelen.

[Sgreehder]

De teller staat op dit moment op ongeveer 700 piloten op een grid (dus die elkaar kunnen zien), maar dan moet een server reinforced zijn (dit moet je vantevoren opgeven als je denkt ergens te vechten, want in de praktijk verder goed verloopt). Vanaf 1000 man wordt het vervelend, veel lag, modules die blijven haken, etc.

[Reactie gewijzigd door Sgreehder op 22 juli 2024 18:54]

[rapture]

In EVE Online worden de spelers in een zonnestelsel door 1 thread afgehandeld. Voor 50000+ zonnestelsels zet je niet 50000+ processorcores in zodat er gemiddeld 25 zonnestelsels op een processorcore draait. Dit gaat als er gemiddeld 10 man in een zonnestelsel zit en 250 man op een processor zit.

Als je een 200 man battle wilt uitvechten, dan zit er dubbel zoveel man op een processor en dat gaat niet meer zo goed. Mijn laatste grote fleet battle was 2 jaar geleden met 1600 man.

Dan moet de "node reinforced" worden, de zonnestelselthread van een geplande fleet battle wordt op een eigen processorcore gezet. Naarmate processors sneller worden en de code minder resources (bv losse identieke wapens worden gegroepeerd zodat je voor 1 ipv 8 guns berekeningen moet maken) intensief wordt, kan er meer spelers aan een grote fleet battle deelnemen.

1600 spelers die op de knoppen aan het rammen zijn, voeren eigenlijk door hun grote aantallen een DDoS op de gameservers uit. Vroeger was een groepje studenten die op F5 zaten te rammen op een EU-website als een protestactie al genoeg om wat webservers in Brussel plat te krijgen. Je kan wel voorstellen dat een zonnestelselthread of processorcore over zich krijgt.

Het is interessant om te zien of het mogelijk is om 1 gevecht (waar je alles met alles wilt synchroniseren) in meerdere threads kan opdelen zodat een 1600 man battle over meerdere cores gespreid kan worden. Dan blijft alleen de menselijke grens over. Als je 10 % van alle spelers die tegelijkertijd online zijn in een grote fleet battle kan steken, dan heb je 6000 man battles.

[MSalters]

Het is interessant om te zien of het mogelijk is om 1 gevecht (waar je alles met alles wilt synchroniseren) in meerdere threads kan opdelen zodat een 1600 man battle over meerdere cores gespreid kan worden.

Waarom zou daar een probleem mee zijn? Bij een enkel telefoongesprek moeten de CPU's van de mobieltjes aan beide kanten, en alle telefooncentrales in het midden ook al redelijk "gesynchroniseerd" zijn. En dat is voor 2 man.Maar goed, talen zoals C, C++, SDL en Erlang zijn dan ook niet toevallig door telefoonbedrijven ontwikkeld.

En om jouw voorbeeld te nemen: al die 1600 spelers sturen commando's naar de server. Al die commando's moet je checken om te kijken of ze wel mogen. Als je 8 guns hebt kun je niet met gun #9 schieten. Die checks kun je voor alle spelers in parallel doen, desnoods met 1600 threads (of in de praktijk met net zoveel threads als je cores hebt). Bovendien mag die controle overlappen met de daadwerkelijke verwerking van eerder gecontroleerde commando's.

[Sissors]

Eve online gebruikt gewoon de brute force methode, genoeg rekenkracht hebben voor een compleet systeem, en tussen systemen in is het niet seamless zoals bij deze techniek.

Sowieso schiet dit bij eve weinig op bij gevechten omdat die er juist om gaan om zoveel mogelijk mensen op één punt aan het vechten te hebben (wat ook een reden is dat dat waarschijnlijk nog voor een hele tijd zal blijven laggen).
Bij Jita kan het misschien wel helpen, maar dat is eigenlijk helemaal een andere situatie gezien dat lag daar volgens mij niet komt door wat er in space gebeurd maar door wat er aan database operaties moet worden uitgevoerd voor inventory.

En vertraging pas bij 200+ speler is enkel op dedicated nodes, zelfs nu dat de FW lag bugs en dominion problemen eruit zijn zal je op een niet dedicated node veel eerder dan 200 man tegen lag aanlopen. Zelfs op dedicated node hadden we laatst met 250 in local dat de hele handel desynced was.

[Sfynx]

Sowieso schiet dit bij eve weinig op bij gevechten omdat die er juist om gaan om zoveel mogelijk mensen op één punt aan het vechten te hebben (wat ook een reden is dat dat waarschijnlijk nog voor een hele tijd zal blijven laggen).

Als er dynamisch meerdere masten bijgeplaatst kunnen worden, kan je dus ook een crapload op de plek van een gevecht zetten om elk de load van een x aantal schepen op te vangen. Lijkt me juist ideaal voor de EVE situatie.

De vraag is wat de latency dan is, overgangen van ammo en remote effects tussen twee 'cells' e.d... maar slechter dan de minutenlange lag die we nu bij cap fights hebben zal het niet zijn

[Xanaroth]

Hoop games niet hoor. Een spel als EVE of WoW heeft merkbare vertraging als je met 50 man of meer tegelijk iets doet (zoals combat). Hier hebben ze het over 1000 (10x zoveel) zonder merkbare vertraging. Dat is behoorlijke stap voorwaarts.

[Yezpahr]

Artikel:

De 'mast' van een cell-server kan live in de spelwereld worden verplaatst om cell-servers in drukkere spelgebieden te ontlasten.

Dit wil dus zeggen dat deze servers het vooral van díe techniek moeten hebben.
Dus als al die duizend spelers letterlijk op elkaar staan, dan heb je alsnog een probleem, omdat dan de techniek niet meer van toepassing is. De 'masten' berekenen dan namelijk nog steeds alles door en alles word alsnog door naar de client gestuurd. De 11 kilobyte gaat dan niet meer op.

[roy-t]

Dat is niet waar, er staat dat masten bijgeplaatst kunnen worden. Elke mast in dat gebiedje krijgt dan een kleiner berijk en zo minder users. Dit is dezelfde manier waarop het telefoon-masten systeem werk als in: i Amsterdam staan meer masten (met kleinere range) dan als in de veluwe.

[ArmouredSPony]

In EVE: online merk je pas vertraging bij gevechten met 200 spelers. Maar dat zal per user wel anders zijn..

[Ventieldopje]

Wel iets meer dan 200 spelers hoor De beruchte "cap fights"

[Kaw]

Snap ook niet zo goed waarom dit zo enorm speciaal is.
De gemiddelde MMO-server kan al 1000 spelers aan met een lag van rond de 30ms. De meeste lag zit em niet op de server zelf, maar in de verbinding naar de server toe. Ik geloof dat zelfs de brakke private world servers van WoW in staat zijn om 1000 spelers met een software side lag van minder dan 10ms te bedienen. Oké, je hebt daar wel een zware server voor nodig, maar in dit artikel staat nergens dat de gebruikte servers lightweight zijn.
Je hebt zoveel MMO's dat er vast wel MMO's te noemen zijn die niet sterk zijn op dit punt, maar een aantal redden dit nu ook al wel om 1000 spelers te bedienen zonder overdreven (>30ms) vertraging.

Edit @ Piderman: De private servers waren toen nog zo prematuur dat het bleef bij een man of 40. Je hebt het over de servers van Blizzard zelf, maar ik weet niet hoe die qua architectuur in elkaar steken.

@drayer:

dit gaat er ook meer om dat je allemaal met elkaar in verbinding bent zonder problemen dus games met massive veldslagen bijv zonder lagg.

Als ik het stuk lees:

De client zal van de 125 dichtstbijzijnde spelers 15 world state snapshots per seconde ontvangen; de updates van de overige spelers komen drie keer per seconde binnen.

Dan gaat dat dus op voor 125 man. In the old days had je idd lag met 200 man, maar de computerkracht is sinds 2004 behoorlijk vooruit gegaan. Ik wil WoW op een Blizzard server met 125 man in een kleine ruimte wel eens zien. Durf te wedden dat het redelijk goed gaat.

[Reactie gewijzigd door Kaw op 22 juli 2024 18:54]

[piderman]

Ik geloof dat zelfs de brakke private world servers van WoW in staat zijn om 1000 spelers met een software side lag van minder dan 10ms te bedienen.

Dat niet alleen, ze doen het al sinds 2004.

[drayer]

uhm 1000 man op 1 server ja maar in verschillende gebieden dus je word pas met elkaar verbonden als je binnen een range zit (ga maar eens met 1000 man in orgrimmar rond lopen kijke of je nog vloeiend rondloopt ik denk het niet of wintergrasp in the old days 200 man in wg was een grote lagg zooi)

dit gaat er ook meer om dat je allemaal met elkaar in verbinding bent zonder problemen dus games met massive veldslagen bijv zonder lagg.

[YopY]

Lag schrijft ge met één G.

[TMon]

die 2e G was de lag

[Xanaroth]

Nee, wow kan max een 40-50 man aan tegelijk. Bij meer gaat je vertraging oplopen. Doel van dit is om dat tegen te gaan; de oplopende vertraging.

Jij alleen/rustig: 25-30ms.

Alle 1000 rondom je in een gevecht: nog nooit gebeurt in WoW aangezien de servers crashen rond de 100v100 (om maar niet te spreken over de vertraging van 5000+ms die je krijgt als de server het wonderbaarlijk op weet te houden).


Doel van deze setup is dat dus ook bij 100v100 en 500v500 er eigenlijk niks verandert rond je verbinding tegenover als je solo ergens rondloopt.

[Reactie gewijzigd door Xanaroth op 22 juli 2024 18:54]

[sdk1985]

De "truuk" die bekende mmo's zoals world of warcraft gebruiken is dat je altijd een target moet selecteren voor je een ability kunt gebruiken. Hierdoor kun je nooit missen. De server weet altijd tussen welke 2 targets het gaat en welke acties worden uitgevoerd. Dat lost nogal wat problemen op... Er hoeft bijvoorbeeld geen pad berekent te worden voor afgevuurde kogels. In games waar dit wel gebeurd is 60 spelers vaak al veel (denk aan freelancer, world of tanks, battlefield 2 , enz).

Het bijzondere aan dit voorstel is dat het dus gaat om een server die 1000 speler in een FPS aankan>>> duizenden vliegende kogels en de bijbehorende hit detection.

Overigens weet ik niet of je ooit wintergrasp hebt gespeeld in world of warcraft maar op mijn realm werd dat al snel een 'lag fest' waarbij je om de 1-2 seconde weer een paar stappen vooruit kon zetten.

[Reactie gewijzigd door sdk1985 op 22 juli 2024 18:54]

[drayer]

juist hierom ben ik blij dat dit geintroduceerd is omdat er steeds meer mmo's uitkomen met skillshots en niet target klikken en skills doen want dit vereist dan ook veel meer,
dus fingers crossed en hopen dat dit in de toekomst goed gaat werken.

[Abom]

Wat ik eerder noemde, Asheron's Call, had ook skillshots en het was mogelijk om bijvoorbeeld fireballs te 'dodgen'.

Wat hier nieuw aan is, is dat het om een 1000 man DM fps zal gaan. De actie zal dus vele malen intenser zijn dan een 1vs2, 2vs2, 3vs3 of 5vs5 PvP scenario. Ik weet niet hoe de PvP instances van WoW heten, maar ik betwijfel dat het daar om meer dan 25vs25 spelers gaat en dat draait dan op één instance en waarschijnlijk op één server.

Het ligt eraan hoe schaalbaar deze architectuur is, maar je zou in princiepe hier epische veldslagen mee kunnen draaien.

[SinergyX]

Zonder lag zeg je? Laat eens 2 spelers naast elkaar op een server bewegen, de 'commando' loopt _nooit_ synchroon met de animatie die de ander op zijn scherm ziet. Daarnaast gebruikt het gros die 'registry patch' om fictiek een bizar lage ping te hebben, maar er is niets van waar.

Zijn we de grote events tijdens LK/Cata vergeten? Moment dat er _echt_ 300 man bij elkaar zitten, de server het absoluut niet trekt, laat staan 1000 man gelijktijdig te kunnen bedienen.

[YopY]

Let ook dat lag niet alleen aan de serverkant zit. Ja, voor een gebied waar 200 man in rondlopen zal de server 200 * 200 (plusminus) updates rond moeten sturen, maar ook jouw eigen PC zal 200 updates (* aantal updates / seconde) moeten verwerken.

[drayer]

dit fenomeen kwam je al tegen by crysis 1 waarbij ik met een leuke 2 mbit verbinding in die tijd niet onder 500 ms kwam ondat het zoveel info vereisde.
en dan zal ik atm met max 8mbit niet vrolijk worden als ik 200 updates per seconde moet verwerken

[Reactie gewijzigd door drayer op 22 juli 2024 18:54]

[morrowyn]

Tja, niet echt spannend 2 jaar na dato:
http://www.eveonline.com/devblog.asp?a=blog&bid=584
CCP kon toen al 1000 concurrent users aan en met hun server omgeving gewoon 300.000 spelers met elkaar laten communiceren, handelen en oorlogje voeren.
http://massively.joystiq....eve-onlines-server-model/

[Verwijderd]

Gebruikt Rift nu ook al niet iets uniek? Vandaag in een irc chat log met developers gelezen dat hun game world ook seamless is, en het ook niet uitmaakt hoeveel spelers er op een bepaalde locatie zijn. Voor zover ik het herinner, zijn de servers dus niet geografisch gericht, maar op de verschillende processen. Dus als er een server die de AI processen draait bv er uitvliegt, verdwijnen er bepaalde npcs dan terwijl die server reboot.

[1337mhz]

Zodra ze high end graphics kunnen combineren met grote aantallen spelers per keer actief in een MMO zal er een wereld op gaan voor gamers:D

Ik geef ze 4 jaar.

[Reactie gewijzigd door 1337mhz op 22 juli 2024 18:54]

[boto]

Uh, high end graphics hebben bar weinig hier mee te maken? De server kijkt alleen waar je staat en schreeuwt naar jou waar iedereen is/of je dood bent

(wel meer dingen maar niks met graphics)

[YopY]

High-end graphics in combinatie met grote aantallen spelers is vanuit de technologie gezien al jaren mogelijk, alleen de hardware van de gebruiker(s) kunnen het niet aan, niet zonder de graphics naar beneden te schalen in ieder geval.