Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Ontwikkelaar beperkt laadtijd in GTA Online met bijna 70 procent met eigen code

Een ontwikkelaar is er in geslaagd door met aangepaste code GTA Online 69,4 procent sneller te laden. Dat is bereikt door het proces te vereenvoudigen van hoe het systeem de in-game items leest en verwerkt. De game is berucht om zijn lange laadtijden.

De ontwikkelaar met de naam T0ST schrijft dat hij weliswaar een verouderde computer gebruikt met een AMD FX-8350-cpu en een Nvidia GeForce GTX 1070, in combinatie met DDR3-werkgeheugen, maar dat het laden van GTA Online zes keer langer duurde dan de verhaalmodus. Die verhaalmodus nam 70 seconden in beslag, terwijl de laadtijd voor de onlinemodus zes minuten duurde. Volgens de ontwikkelaar en anderen zou dit verschil logischerwijs niet zo groot moeten zijn. Zijn verouderde Bulldozer-cpu heeft weliswaar geen hoge single thread-prestaties, wat een deel van de verklaring kon zijn, maar er bleek meer aan de hand.

Hij kwam het probleem op het spoor door het taakbeheer in Windows te openen. Daar bleek dat gedurende de eerste minuut de gemeenschappelijke elementen geladen worden die voor zowel de verhaal- als de onlinemodus worden gebruikt. Daarna bleek een proces te starten waardoor voor meer dan vier minuten het gebruik van een enkele core van zijn cpu drastisch omhoog ging, terwijl er nauwelijks of geen sprake was van het gebruik van de opslag, het netwerk, de gpu of het werkgeheugen. De ontwikkelaar zegt het vreemd te vinden dat alleen de cpu werd gebruikt.

Uiteindelijk kwam hij tot de conclusie dat er twee bugs of problemen in de code zitten. Allereerst leest de game in een JSON-tekstbestand van 10MB alle items in de game. Daar staan 63.000 entries in. Dat is een lijst met alle in het spel aan te kopen items, waarbij volgens de ontwikkelaar niet direct aan microtransacties gedacht moet worden. Na het inlezen van elk van de 63.000 items, wordt elk karakter in dat gehele tekstbestand opnieuw geteld, en dat dus 63.000 keer. Ten tweede worden voor de voorbereiding van de ingelezen itemdata zowel gegevens als de naam en de prijs van het item, en een hash van het item ingeladen. Elke keer dat GTA Online een item opslaat, wordt de hele lijst één voor één gecontroleerd, waarbij de hash van het item wordt vergeleken om te zien of het in de lijst voorkomt. Kortom, de hashwaarde van het opgeslagen item wordt vergeleken met de hashes van elk ander item dat al eerder is opgeslagen. Dit kan leiden tot (63000^2+63000)/2 controles, oftewel 1.984.531.500 stuks. GTA Online doet dit om er zeker van te zijn dat er geen dubbele items in de uiteindelijke lijst zitten, om hackers tegen te gaan.

Volgens de ontwikkelaar vormt dit proces een aanslag op de cpu en is het niet eens noodzakelijk, omdat de lijst met de hashes leeg is voordat het JSON-bestand wordt geladen. Bovendien zijn alle items in dit bestand uniek, waardoor het volgens T0ST niet nodig is om te controleren of ze wel of niet in de lijst voorkomen. Daarnaast wijst hij erop dat er zelfs een functie beschikbaar is om de items rechtstreeks in te voegen.

Op basis van zijn eigen code blijkt het mogelijk de laadtijd terug te brengen van zes minuten naar een minuut en vijftig seconden. Zijn eigen code berekent de lengte van de lijst met items slechts een keer, wat al een aanzienlijke hoeveelheid rekenwerk scheelt. Daarnaast slaat hij het checken van de hashes over, omdat er in zijn ogen geen reden is om te controleren op dubbele items. Daarmee zijn de bijna twee miljard controles niet meer aan de orde, waardoor de processor veel sneller klaar is met het laden.

De ontwikkelaar maakt duidelijk dat zijn eigen code een proof of concept is en dat het gebruik ervan en daarmee het modificeren van GTA Online kan leiden tot het schorsen van spelersaccounts.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Joris Jansen

Nieuwsredacteur

01-03-2021 • 16:43

126 Linkedin

Submitter: Rafe

Reacties (126)

Wijzig sortering
Ik ben benieuwd hoe Rockstar hier mee omgaat. Het beste antwoord zou samen gaan werken met deze persoon om dit te implementeren. Natuurlijk erg makkelijk gezegd, maar dit is pure goodwill. Zet 1 interne ontwikkelaar er op die verstand heeft van het proces, ga praten met iemand die denkt het te kunnen verbeteren, en als er iets uit komt is het win/win, desnoods geef je de persoon in kwestie publieke erkenning of ingame items. Een betaling in echt geld lijkt mij niet echt nodig.

Maar ze kunnen natuurlijk ook gewoon er niets mee doen. Zou niet slim zijn, want waarom zou je niet een enkele developer 1 (of een paar dagen) er op zetten om te checken of hier een mogelijke verbetering in zit.
Beter doen ze dat. De laadtijden zijn reden nr. 1 dat ik gestopt ben met spelen.
Het is voor mij ook de nummer 1 reden geweest om niet eens te beginnen met GTA 5 Online.

Ik heb de single player variant kapot gespeeld afgelopen jaren maar online heb ik denk ik 2 keer een aantal uur gespeeld en was ik er wel klaar mee constant die lange wachttijden. Had zelfs nog een lobby toen met een cheater erin, kan gebeuren dus ga je er gewoon uit maar als je dan net een aantal minuten hebt zitten wachten dan ben je er snel klaar mee....
Het was echt zonde, die laadtijden. In de basis zag ik potentie, maar telkens als ik 2 uurtjes had om met een maat samen te gamen dan strandden we op het laadscherm. Lang wachten en dan lukte het soms niet direct om bij elkaar in te komen, dus nogmaals lang laden.
Gewoon verschrikkelijk kut. Na 3 afzonderlijke momenten dat het zo ging ben ik afgehaakt. Leuk idee, maar niet als je binnen relatief gebrekkige tijd ook daadwerkelijk lol wilt beleven aan een spel.

[Reactie gewijzigd door nms2003 op 4 maart 2021 09:45]

Voor mij hetzelfde, ik heb het zelfs na 2 en 3 weer geprobeerd om te kijken of het al beter was.. maar nee. Het enige wat ik tegenkwam was meer hackers, en nog steeds dezelfde of langzamere multiplayer verbindingsissues. Ik snap ook niet hoe andere mensen het leuk genoeg vinden, race doen? 4 minuten + wachten op genoeg andere spelers. Geef je het op na 5 minuten? Eerst weer minuten wachten totdat het spel weer ingeladen is, weer een nieuwe race / activity, weer 4 minuten + wachten en hopen dat er mensen komen..
Ik ben benieuwd hoe Rockstar hier mee omgaat. Het beste antwoord zou samen gaan werken met deze persoon om dit te implementeren.
Op basis van deze omschrijving zou rockstar dit zonder moeite moeten kunnen implementeren. Dit komt neer op for-loopjes efficiënt nesten, wat elke eerstejaars informaticastudent hoort te kunnen. Dit soort zaken opsporen zou ook gewoon met een profiler te doen moeten zijn. edit: is ook hoe de persoon in kwestie het gevonden heeft.

Dit lijkt dus eerder een gebrek aan prioriteit dan dat ze samenwerking nodig hebben.

[Reactie gewijzigd door bwerg op 1 maart 2021 19:39]

Maar het lijkt mij dat men bij R* ook wel slim genoeg had moeten zijn om deze bottleneck te vinden. Dat deze er in zit doet mij denken dat ze mogelijks wel een reden hebben om het zo te doen.
Dat zat ik ook te denken. Wellicht is het inladen op de huidig manier iets gecompliceerder dan enkel het spel opgestart krijgen. Leuk dat het 70% sneller kan, maar wie zegt dat je dan niet op andere ( onvoorziene ) zaken stuit?
Het is natuurlijk sowieso quatsch dat je op duplicaten controleert met een O(n²) algoritme, als dat ook in O(n) kan.
Ach, ik heb het ook wel gezien, en zo lang je niet test met realistische scenarios (even een lijstje met 10 straatnamen voor een unit test) ga je het ook niet merken ook. Daarna is het een gevalletje 'prioriteiten', en ik kan me zo voorstellen dat er geen tijd/budget voor optimalisaties wordt vrijgemaakt, want het spel verkoopt toch wel, en zwaardere spellen worden helaas vaker als benchmark gebruikt, en serieuzer genomen dan goed geoptimaliseerde software.
Ach, ik heb het ook wel gezien
Ik ook. Een JSON library die de binnenkomende JSON parset en omzet in datatypes, maar voor elk teken van een string dat binnenkomt de string opnieuw alloceert. En elke keer als er een element wordt toegevoegd aan een array of object, wordt er opnieuw een interne string-respresentatie van het object opgebouwd. Dit gaf zoveel problemen op een Xbox 360 dat we uiteindelijk aan de bel hebben getrokken bij de leverancier van de middleware die gebruikt werd waar die code in zat.

Ik kan hier dus echt niet bij. Gamedevelopment loopt typisch niet zoals softwareontwikkeling waar men hier in NL bekend mee is. Testen met test-data is leuk, maar aan het eind van de dag moet er een game opgeleverd worden en is het onacceptabel als het laadscherm minutenlang duurt. Er is altijd een moment dat iemand met ervaring naar de performance kijkt en dit soort dingen eruit pikt. Ik kan me geen game herinneren waar we géén aandacht hebben besteed aan de laadtijden, en over het algemeen was ik daar zelf bij betrokken. Ik snap dus echt niet dat niemand dit laaghangende fruit (want dat is het) is opgevallen.
Tja, prioriteiten, once again, en als je baas iedereen eruit smijt die code zonder ticket instuurt (want verspilling van resources of security of bedenk maar iets), en er geen ticket komt voor laaghangend fruit, dan... heb je een probleem. Voeg daarbij een paar devs die al 50+ uur gemaakt hebben de afgelopen weken, want deadline deadline, en ik snap het wel. Het is niet goed, maar wel realiteit. Vergeet niet dat voor management de deadline heiliger is dan bugs, zeker tegenwoordig (met een marketing-hype overal omheen).
Je lijkt me te vertellen hoe het werkt, maar voor de goede orde, ik ben al een behoorlijke tijd gamedeveloper :)

Als een 6 minuten laadtijd geen prioriteit is, dan heb je gewoon een lage standaard, klaar.

[Reactie gewijzigd door .oisyn op 1 maart 2021 21:46]

Toevallig bij Horizon Zero Dawn betrokken geweest? Klasse game! En tof dat die helemaal door Nederlanders is gemaakt. :)
En heel veel expats die daar werken
Dank je, leuk om te dit soort dingen te weten. :)
HZD is een goede game die ook bij nogmaals spelen niet snel verveelt. Top gedaan vind ik.
Weet niet waar je -1 aan te danken hebt, want zit idd. waarheid in je reactie. Als developer zijnde, als mijn baas me zodanig weet te demotiveren, ga ik ook niet meer de moeite doen om laaghangend fruit aan te wijzen.
Hoe oud is GTA 5 inmiddels?... dit klinkt echt als een flinke programmeer-faal tbh.
Wanneer je game er zo dusdanig lang over doet om te laden, en het spel berucht staat om de lange laadtijden, dan zet je daar toch gewoon ff een ontwikkelaar op om dat op te sporen of daar niet aan geschaafd kan worden?... :?
Achja de beste stuurlui staan aan wal zullen we maar zeggen.
Het stukje code wat dit oplost is echt een paar regels, en dat is dan nog via een externe DLL. Inline had dit nog simpeler gekund. Dat betekent dat tijdens het laden de CPU gewoon tweederde zinloze duplicate onzin zit uit te rekenen. En met een profiler vinden waar de CPU-tijd in zit is ook niet heftig. Zeker niet voor een gigantisch dev-team wat een stuk software neer moet zetten dat goed moet performen. Wat is daar "de beste stuurlui" aan?

Dat is alsof een taxichauffeur zonder reden de sloot in rijdt en bij commentaar verdedigd wordt met "de beste stuurlui staan aan wal".

Het enige wat deze fout misschien minder fout maakt is dat het probleem is dat dit O(n2) is in de JSON en het dus waarschijnlijk nog niet zo'n probleem was in het originele spel, met waarschijnlijk veel kleinere JSON. Dan neemt deze code (ook relatief gezien) minder CPU-tijd in beslag. En dat ze de performance niet meer opnieuw analyseren jaren na het uitgeven is ook niet heel gek.

[Reactie gewijzigd door bwerg op 2 maart 2021 08:21]

Meneer doet dit nu dus door controles uit te schakelen omdat hij aannames doet. Dat hoeft totaal geen probleem te zijn, maar jij weet niet wat de standaarden intern zijn bij hun, en of zijn aannames dus wel kloppen.
Zelf ben ik ook liever voor optimale code die perfect werkt in de omstandigheden die ik onder controle heb (en dus de meeste 'uitzonderingen' niet afvangt), maar als je meer generiek bezig bent en je dus niet de omstandigheden onder controle hebt, dan zijn die controles mogelijk dus wel nodig.
Het is dus makkelijk om wel vanaf de wal te gaan vertellen hoe het gedaan moet worden, maar je weet dus niet of dat wel zomaar kan conform hun standaarden, genoeg softwarebedrijven hebben standaarden waar developers zich aan moeten houden, ook al leidt dat soms tot dit soort problemen, en dan kun je dus alleen hier van afwijken met triple handtekening etc.
Je hebt wel gelijk in dat het niet te checken is of wat meneer in dit artikel doet klopt, en of hij nog dingen over het hoofd ziet. Maar ook dan: al ziet hij iets over het hoofd, dat dit ding 4 minuten loopt te numbercrunchen op iets wat het spel ogenschijnlijk functioneel niet nodig heeft geeft op zijn minst te denken. Zelfs al moet daar even iets heel dringend gevalideerd worden.

Zelfs al gaat hier stiekem anti-cheat-detectie achter schuil dan, dan zijn de laadtijden die het geeft alsnog vrij dramatisch.

Maar laten we wel wezen: een O(n)-aanroepen als strlen in een loopje met n iteraties hint wel sterk naar gewoon niet zo'n handige implementatie, als n sterk op gaat lopen.

[Reactie gewijzigd door bwerg op 2 maart 2021 08:29]

Maar laten we wel wezen: een O(n)-aanroepen als strlen in een loopje met n iteraties hint wel sterk naar gewoon niet zo'n handige implementatie, als n sterk op gaat lopen.
Zoals ik hier al zei ligt dat aan de implementatie van sscanf(), een standaard C functie. En dat gedrag ligt helemaal niet zo voor de hand.

[Reactie gewijzigd door .oisyn op 2 maart 2021 11:37]

Ik zeg ook niet dat het voor de hand ligt. Ik geef alleen aan dat het feit dat deze performance-bug erin zit op basis van de informatie in het artikel niet ligt aan dat het allemaal heel lastig zou zijn, maar aan dat gewoon nooit iemand het gedaan heeft.

En ook dat het niet gek is dat niemand dat heeft gedaan, omdat dat vooral tijdens ontwikkeling gebeurt, en gokje de JSON is pas in de jaren daarna gegroeid. Grote kans dat deze bug direct geplet zou zijn als dit ten tijde van ontwikkeling al zo merkbaar was geweest.
niet ligt aan dat het allemaal heel lastig zou zijn, maar aan dat gewoon nooit iemand het gedaan heeft.
Maar dat is het wel. De auteur in kwestie hookt de sscanf() functie om die strlen() resultaten te cachen. Dat is natuurlijk niet iets dat je gewoon in code kunt doen, zonder hele vieze trucs uit te halen. En dan maar even een alternatieve implementatie maken van sscanf() is ook een stuk makkelijker gezegd dan gedaan.

Eigenlijk is sscanf() hier gewoon onbruikbaar, en moet er voor een andere opzet worden gekozen. Waarbij de kans ook nog eens bestaat dat deze code in een library leeft waar ze geen sourcecode van hebben, of geen rechten hebben om die aan te passen.

[Reactie gewijzigd door .oisyn op 2 maart 2021 12:44]

O(n²) complexiteit is ook wel vrij absurd. Als ik daar tijdens mijn opleiding mee aan kwam kakken mocht ik heeeeel goed gaan uitleggen waarom dat nodig is, anders kreeg ik een dikke vette onvoldoende.
Misschien dat ik het verkeerd gelezen heb, maar voor élk item wordt voor élk karakter in dat item élk item geteld.

De complexiteit is dus O((n*n_length)*n) wat véle malen erger is dan O(n^2) _/-\o_

[Reactie gewijzigd door Ayporos op 2 maart 2021 19:05]

Het enige wat deze fout misschien minder fout maakt is dat het probleem is dat dit O(n2) is in de JSON en het dus waarschijnlijk nog niet zo'n probleem was in het originele spel, met waarschijnlijk veel kleinere JSON. Dan neemt deze code (ook relatief gezien) minder CPU-tijd in beslag. En dat ze de performance niet meer opnieuw analyseren jaren na het uitgeven is ook niet heel gek.
Ik geloof ook wel dat de crux daar zou kunnen liggen; wss is ooit die JSON-load een aardig stuk kleiner (en dus veel minder impactvol) geweest, maar voor mij rest dan wel deze vraag: Als je elke keer zo'n JSON string wil inladen met het doel de in-game websites e.d. door te geven/te updaten/etc; waarom wordt dan geen-enkel deel daarvan gecached zodat enkel updates geparsed hoeven te worden? Waarom wordt niet per onderdeel of groep onderdelen info opgevraagd maar telkens een JSON van 10MB? Check wanneer de laatste update geweest is, geef het evt zelfs een hash mee, en laat dát checken; onderdelen worden wel op basis van hashes gechecked, waarom niet de mechaniek zelve?
Ook via die weg zou het mogelijk moeten zijn (m.i.) om "te voorkomen dat hackers dubbele items inladen" omdat dan die hash af gaat wijken...

Wss is die hele mechaniek nooit ontwikkeld geweest voor de hoeveelheid feature-creep die het nu na alle toevoegingen/updates heeft gekregen; maar waarom wordt zuks niet revised vóór een gebruiker het kan opmerken vind ik een goede vraag.

Tevens; als men hackers daadwerkelijk had willen aanpakken, waarom werkt het tot op de dag van vandaag met een ongecontroleerde p2p structuur waar élke willekeurige client zo goed als élke willekeurige instructie mag aanvragen? Ik heb nógal het idee dat dat argument een wassen neus is.

[Reactie gewijzigd door Annihlator op 4 maart 2021 12:07]

Waarom? Spel wordt er niet minder door verkocht.
Weet je niet. Ja het verkoopt nog beest aardig. Maar misschien verkoopt het nog beter met minder laadtijden
Ik heb tientallen reacties gelezen op Reddit die zeiden dat laadtijd een reden is waardoor ze zijn gestopt met spelen.
Maar dan hebben ze 't spel toch al gekocht?
Er word nu vooral verdiend met online transactions.. Dus gezien je het spel nu voor 5 euro kan kopen ofzo, kost het ze weldegelijk veel geld als mensen minder vaak het spel opstarten.
Als het enkel om initiële verkoop gaat en verder geen ingame verkopen of mond op mond reclame dan heb je gelijk. Ik heb ook GTA5, maar de slechte performance is de reden dat ik het niet speel. Soms ben je zelfs al dood gemaakt voordat je kan beginnen met spelen, er klopt zoveel niet aan hun code. Anders vind ik het een geweldig game waar ik goed verslaafd aan kan raken.
Maar de multi player is de melk koe. Ik werd echt ziek van de laadtijden, en dan vooral in combinatie met netwerk issues waardoor je opnieuw er naar mocht kijken en ben er dus mee gestopt.

En ik ben echt niet de enige.
Ik kan me niet voorstellen dat de mensen die veel shark cards kopen gaan stoppen met spelen vanwege de laadtijden. De laadtijden zijn absurd, begrijp me niet verkeerd. Maar ik snap dat Rockstar er geen prioriteit aan geeft.
Mensen die veel Shark cards lopen misschien niet, maar hoeveel mensen hadden Shark cards gekocht als ze nog steeds speelden?

Als de fix echt zo simpel is, dan heeft het niets met prioriteit te maken, het zit er al jaren in en ze voegen nog steeds content toe.

Ik denk dat het een reden heeft, vooral om dat RDR2 vrijwel dezelfde engine heeft en volgens mij niet het zelfde issue heeft. Dus er moet iemand tegenaan gelopen zijn.
Heel eerlijk hoop ik dat niemand ze koopt. De loading times kon ik nog omheen kijken, het VW Golfje dat 'n miljoen kost niet. De prijzen van items zijn zo idioot hoog als je 't vergelijkt met items die er op release al inzaten. Spel is een grote cashgrab. Maar dat is een ander punt.
Als de fix echt zo simpel is, dan heeft het niets met prioriteit te maken, het zit er al jaren in en ze voegen nog steeds content toe.
Ik ben het met je eens hoor, maar ze maken heus wel een soort risk assessment om te kijken of 't het waard is om zoiets te doen.
dat lijkt me niet echt iets wat je zomaar fixt of van te voren ontwerpt.
Kom op, strlen één keer aanroepen in plaats van in elke iteratie is niet iets wat je van tevoren hoeft te ontwerpen en ook niet iets wat lastig achteraf aan te passen is. Dit is echt een implementatiedetail wat met gemak te fixen is, dat heeft niets met schaalgrootte of ontwerp te maken.

Hetgeen wel bewezen is doordat deze meneer het probleem heeft kunnen opsporen met task manager en een simpele profiler, en het probleem heeft kunnen fixen in de gecompileerde code. Zelfs de meest briljante programmeur is kansloos als er een heftige architectuurwijziging nodig is in gecompileerde code. Hij wrapt de strlen-aanroep gewoon letterlijk in een paar regels code die de boel cachet, en klaar is Kees.

[Reactie gewijzigd door bwerg op 1 maart 2021 19:39]

Kom op, strlen één keer aanroepen in plaats van in elke iteratie is niet iets wat je van tevoren hoeft te ontwerpen en ook niet iets wat lastig achteraf aan te passen is.
Als ik zijn post goed begrijp stelt hij dat het in de implementatie van sscanf() zit. Tja, eerlijk gezegd, als ik sscanf() een string voer verwacht ik niet dat ie eerst op zoek gaat naar het eind van de string, dat doet fscanf() immers ook niet met een file. Sterker nog, de notie dat ie dat wel zou doen vind ik dermate abject dat ik eerder vermoed dat zijn bevinding niet klopt, dan dat er daadwerkelijk zo'n belabberde implementatie van sscanf() wordt gebruikt :)

.edit: ok net getest. Blijkbaar doet ie dat dus wel. sscanf(str, "%d", &i) op een string van 1 miljoen tekens: <1ms. 1 Miljard tekens: 36ms. 8 Miljard: 269ms :X. Ben blij dat ik die functie nooit gebruik, en ik heb toch al heel wat parsers geschreven.

VC++ 2019, 16.8.0

[Reactie gewijzigd door .oisyn op 2 maart 2021 11:36]

Ja echt respect voor het onderzoek en de oplossing door deze vent.
Het spel laadde al vanaf het begin veel te lang. Daardoor heb ik de single player veel gespeeld. Online niet eens alle opdrachten voltooid omdat ik toen hij uitkwam het niet kreeg verkropt dat iets zo vaak en lang moet laden. Vooral omdat het al een extra jaar duurde om de pc versie uit te brengen.
Ik stem door niet zo maar iets van Rockstar te kopen.

[Reactie gewijzigd door thijsjek op 1 maart 2021 18:31]

Ik ben benieuwd hoe Rockstar hier mee omgaat.
Negeren... Wat naar mijn idee slecht is maar aangezien het spel al bijna 6 jaar uit is voor de PC gaan ze daar nu echt niets meer aan veranderen.

Het is natuurlijk ook zo dat T0ST die extra controles onnodig vindt, maar misschien zit er toch meer achter dan wij begrijpen.

De lange laadtijden zijn voor mij in het verleden wel de reden geweest om het online deel links te laten liggen... Als hier in het begin een goede fix voor was geweest denk ik dat er veel en veel meer mensen waren blijven hangen.

*Alu hoedje op*
Misschien hebben ze de laad tijden wel expres heel lang gemaakt zodat het grinden nog langer duurt en mensen dus nog sneller geld in het spel proppen om "hippe" dingen te kunnen bemachtigen. :+
Zet je Alu hoedje maar af hoor. Anders hadden ze nooit een solo heist released waar je 1.5m per uur solo kan weg grinden. Terwijl je daarvoor rond de 500k zat.
Ik denk mensen die zo'n zaken vinden, best een dag mee kunnen genomen worden om mee op de werkvloer te komen meedraaien en kijken. Dat is beter dan een sollicitatie gesprek!
Als men er iets aan had willen doen, had men dat al lang gedaan... Zo'n probleem zou elke gemiddelde developer bij Rockstar kunnen opsporen en oplossen.
Dan heb je nog nooit bij een groter bedrijf als developer gewerkt. Ook al willen interne developers dit, prioriteiten kunnen elders liggen.
Natuurlijk willen developers dat. Maar die hebben daar weinig in te zeggen.
Misschien kwam het Rockstar wel goed uit, want door dit op te lossen in GTA VI kan je die promoten met extra snelle laad tijden. Zal Sony ook niet erg vinden om hun claims te onderbouwen.

Wel een enorme faal dat het er überhaupt in zat
Ik vraag me af of ze er blij mee zijn. Waarom niet ? Zou je denken. Vanuit een psychologische hoek zou het best onderdeel van de Rockstar-formule kunnen zijn. Why Some Apps Are Intentionally Slow - Cheddar Explains.
Iets met vertrouwen en binding, en in dit extreme geval ook investering.
Het laadscherm heeft wat van een psychologische geizeling waardoor je langer door blijft spelen omdat je weet dat je anders weer een poos tegen dat scherm aan staart de volgende keer.

[Reactie gewijzigd door Mushroomician op 1 maart 2021 17:33]

Mua, dan heeft het bij mij vaak een averechts effect gehad. Vaak genoeg dat ik tijdens het laden dacht: laat maar, hier heb ik geen zin in.

Soms wil je gewoon even snel kort een game spelen. Dan haak ik tijdens het laden al af zoals in GTA. Want dan denk ik: na elke missie dit scherm weer minutenlang, laat maar zitten ga wel iets anders spelen.
Kan een neveneffect zijn, maar als dat het doel is, is dat ook wel makkelijker te realiseren, lijkt me.
Ik wil best geloven dat het met kleine laad tijden is. Maar 6 min is gewoon te lang voor iets wat regelmatig terug komt.
Dit is echt beschamend vanuit een software development perspectief. Het parsen van JSON(!) wat minuten duurt. Even als context: je browser doet dit werkelijk al in seconden.
Hoe verkeerd worden de prioriteiten dan wel niet gemanaged bij Rockstar? Zo'n hoogstaande engine kunnen ontwikkelen en geen tijd vrijmaken voor een fix van maximaal een paar uurtjes. Kan me niet voorstellen dat een developer dit is ontgaan, maar eerder dat er geen tijd werd vrijgemaakt vanuit management. "Performances fixes? Mwah, deze sprint doen we nog meer skins toevoegen! $$$"
Bizar eigenlijk als je bedenkt hoeveel mensen er wellicht zijn afgehaakt door de (te) lange laadtijden en hoeveel inkomsten ze potentieel hebben misgelopen. 8)7

Super post wel met een sterk stukje reverse engineering! Voor Rockstar nu een kwestie van seconden om dit te fixen lijkt me.

[Reactie gewijzigd door KirovAir op 1 maart 2021 16:50]

Volgens mij is het niet het parsen zelf, maar wat ze ermee doen na het parsen. Dus steeds herscannen en 'ontdubbelen'. Dat eerste is gecached in de mod, en dat tweede wordt overgeslagen nu. Dus json zelf is het probleem niet echt (al kan je idd wel een slimmer formaat bedenken).
Het is beide. De tijdscomplexiteit van het inlezen is O(n²) omdat voor iedere token eerst strlen wordt opgeroepen en dan scanf. Staat mooi uitgelegd in de originele blogpost.
Maar ik doelde meer op het feit dat json gebruikt wordt. Dat is t probleem niet, alles wat erna komt wel. En ja, ik had de originele post gezien, al voordat tweakers erover berichtte.
Helaas lijkt dit tegenwoordig wel de standaard te worden.
Niet enkel in software, maar ook in hardware.

Door het overvloed aan resources zien veel programma codes er echt bloated uit.
Soms met alle gevolgen van dien.
Ik weet zelf niet of dit nu te maken heeft met gemakzucht of werkdruk?
Mijn persoonlijke ervaring met bedrijven, (mede)collega's en stagiaires is vooral het eerste.

Zelfs als project manager heb ik liever dat mensen net dat beetje meer tijd besteden.
Maar als men een houding heeft van "het werkt zo toch ook", valt dat heel lastig te regelen/corrigeren.
Dat gaat vaak goed wanneer zulke programma's worden getest op een "ideaal" (lees; snel) systeem
(onder systeem versta ik bv ook connecties, LAN, internet etc etc)

Ik ken de werkdruk bij Rockstar niet, maar ik kan me voorstellen dat ze daar andere prioriteiten hebben.
Door het overvloed aan resources zien veel programma codes er echt bloated uit.
Soms met alle gevolgen van dien.
Des te 'hoger' een programmeertaal is, des te afstandelijker/slechter de performance/analyse.

Toppertje van optimalisatie is de code door Steve Wozniak geschreven om een floppy drive in de Apple ][ aan te sturen: om kosten (elektronika) te sparen had hij het positioneren van de kop op de floppy/sector voor elkaar gekregen door cpu cycles benodigd in de code te laten matchen met de omwentelingssnelheid & track to track seeks. Een paar nuttleloze en ineffiente machineinstructies spaarden zo een paar ic'tjes uit.

Als programmeurs niet kijken hoe hogere taal programmacode resources gebruikt, tja, dan krijg je dit soort verschijnselen. Juist een klein bestand kun je memory mapped inlezen, adresseren, dan heb je geen I/O, enkel memory lookups, het wordt zelfs gestructureerd aangeleverd, waarom zo prutsen ?
Omdat je anders dingen krijgt als de inverse square root die niet bepaald heel doorzichtig zijn, en waar je je niet druk om wilt maken tenzij het echt belangrijk is. Als programmeur kom je om in de details, dus hoe meer je weg kunt abstraheren, hoe beter. In 9 van de 10 gevallen (of zelfs meer) is je performance totaal irrelevant, en in andere gevallen redt je compiler je al, door zelf dingen te cachen, te optimaliseren of gewoon te skippen als het later niet gebruikt wordt.

Pas als het fout gaat ga je zoeken. Tot die tijd bespaar je veel tijd.
Dank je voor de link, ooit eens het vak matrices op de tue gedaan, erg goed leesvoer !!!
Tja, maar tegenwoordig is het voor veel developers toch meer frameworks/modules aan elkaar koppelen ipv echt de barebones nog schrijven.
Praat me er niet van. Bij ons willen ze naar "low code". Dit heeft al geleid tot vertrek van developers uit eigen beweging zodra ze dit hoorden.
LOL, dat kan ik me goed voorstellen. Maar het is denk ik wel de toekomst, zeker waarbij dan nog meer 'highlevel' developers gewoon vervangen worden door AI.
programmeurs ... steve jobs
vziw heeft steve jobs nooit geprogrammeerd. Wel heel, heel, heel veel wortelsap gedronken. Hij zat meer in de quality control hoek, competetive programming teams, agile avant la lettre
excuses ik ging daarbij uit van foutive informatie van een andere tweaker zo blijkt
Nee, het stomme hier aan is dat het om een JSON gaat van 10 mb, met 63000 items. Dus een veelvoud aan daadwerkelijke regels. Er zijn denk ik niet veel websites die zo slecht met resources omgaan dat ze dat zouden proberen in een browser.
Valt wel mee, aangezien de JSON parser sneller is dan een object in javascript, het is beter om een object groter dan 10kb te parsen.
Off-the-shelf JSON parsing libraries kunnen honderden megabytes aan JSON per seconde inladen. Misschien niet ideaal, maar dit is zeker niet de bottleneck hier.
Mwoah, dit gebeurt met kaart/geodata toch vrij regelmatig, hoewel je daar ook steeds meer PBF-achtige zaken terug ziet komen om o.a. vector-tiling sneller te laten gaan (wat uiteindelijk niets meer is dan mega-hoeveelheden grafische data).

Json hoeft helemaal niet zo duur/lastig/single-threaded te zijn om te parsen.
Het probleem is heel simpel, en ook problematisch.

Als ik een parser/lexer schrijf, zo ik het liefst willen hebben dat bij voorbaat de syntax 100% correct is en dat kan ik alleen valideren wanneer het volledige bestand binnen is.

Het probleem als programmeur wat ik hieruit lees is dat iteraties, meerdere keren gedaan worden.

Ik hou van efficiëntie, bedrijven houden van leesbaar houd & onderhoudbaarheid. De "middleman" (of vrouw (#inclusivity) is "map/filter/reduce" in plaats van een "for loop".

Het probleem is echter, dat JSON geen multi processor heeft omdat JSON echter nooit bedoeld was om 100Mb mee te parsen (naar mijn opinie). Netzoals Google Home, Alexa of Bixby niet bedoeld was om met licht beïnvloed te worden (huh?). Maar de tijd evolueert en de techniek blijft bestaan en helaas is de maker er niet meer om dit recht te zetten.

JSON moet je kunnen parsen per sectie, deze naar een aparte "thread" kunnen gooien, en meteen die data uit het werk geheugen ontladen wanneer je klaar bent. Dit kan misschien met een paar "libraries" die waarschijnlijk al bestaan. In programmeren word er dan gebruikt van "generators" in plaats van "iterators". Waarbij elke iterator (en of sectie van de array) de waarde van de vorige iteratie zal bewaren, en een generator zal dat weggooien.

Dit betekend dat je zeer selectief moet zijn over de data die je moet analyseren en of bewerken, maar een bedrijf maakt het geen zak uit. Als jij moet wachten totdat al die 100Mb worden gedownload in je werkgeheugen, en je CPU er geen seconde op wacht ga je inderdaad een 100% CPU throttle krijgen.

Reken dat nu eens eventjes uit over de wereld, het totaal aantal laadschermen, het CPU / GPU stroom verbruik op niets af.

[Reactie gewijzigd door Xorifelse op 1 maart 2021 18:39]

Het probleem als programmeur wat ik hieruit lees is dat iteraties, meerdere keren gedaan worden.
Ik denk dat nog eens niet, eerder dat die input file stukje bij beetje ingelezen wordt. I/O is je bottleneck, een paar karakters lezen is even 'duur' in resource termen als met hetzelfde aantal I/O calls megabytes inlezen. Die blob data in het geheugen zetten (of mappen als het meer dan je beschikbare direct memory space is) voorkomt een groot aantal I/O calls.
Als ik een parser/lexer schrijf, zo ik het liefst willen hebben dat bij voorbaat de syntax 100% correct is en dat kan ik alleen valideren wanneer het volledige bestand binnen is.
Om te weten of de syntax 100% correct is, moet je de invoer eerst gelext/geparset hebben, dus een lexer/parser die er bij voorbaat van uit gaat dat invoer 100% syntactisch correct is, doet iets fout.
Het probleem is echter, dat JSON geen multi processor heeft omdat JSON echter nooit bedoeld was om 100Mb mee te parsen (naar mijn opinie).
Parsen is heel moeilijk multi-threaded te maken. Stel je hebt een json {"a": { ... }, "b": { ... }}. Dan kan je het "a" en het "b" deel niet gelijktijdig parsen omdat je eerst het "a"-deel geparset moet hebben voordat je überhaupt weet waar het "b"-deel begint.

Je zou natuurlijk in een andere thread alvast met de analyse van de parsete gegevens kunnen beginnen voordat je helemaal klaar bent met parsen, maar in dit geval heeft dat weinig zin omdat:
1. als je duplikaten wilt zoeken je alle gegevens beschikbaar moet hebben (het eerste en het laatste element zouden duplikaten van elkaar kunnen zijn); en
2. het kiezen van de juiste datastructuur en het juiste algoritme in dit geval veel meer zin hadden gehad.
Het parsen van JSON(!) wat minuten duurt. Even als context: je browser doet dit werkelijk al in seconden.
Ook raar dat ze überhaupt zoiets in een JSON bestand proppen. Een van grote voordelen van JSON is dat het human-readable is, en je het dus makkelijk kan aanpassen. Je maakt mij echter niet wijs dat er iemand met de hand een 10MB JSON file met 63k items gaat lopen editen. Als je dit in een binair formaat opslaat is het vele malen kleiner en ook veel makkelijker en sneller te parsen.
Nee maar het is wel een veelgebruikt formaat waar je letterlijk bijna alles in kunt stoppen qua data. Daarnaast is het lezen ervan razend snel! (Mits je wel de juiste library kiest).
Ook heb je niet zo heel veel aanpassingen nodig als je je object in de code aanpast.
JSON is juist relatief traag om te lezen. Er zijn ontzettend veel string-compares nodig welke duur zijn. Binaire data kan je lastig kwijt in JSON, die moet je dan b.v. base64 encoden wat de data ook weer een stuk groter maakt en decoderen trager maakt.

Er zijn zat manieren on data in een efficient en flexibel binair formaat te encoden.
Vast wel, maar 10mb json moet niet lang duren...
Ik heb net een test gemaakt in c#.
Hier doe ik random data genereren voor 100k records, dat duurt 5.5 seconden.
Daarna serialiseer ik dit naar Json, dit duurt 704ms en het resultaat is een json-string van 178mb.
Daarna deserialiseer ik het weer naar het object in mijn code en dat duurt 791ms.
Hiervoor gebruik ik Newtonsoft.Json.
Ik neem aan dat er voor c/c++ vast ook wel snelle of zelfs snellere oplossingen zijn om json te parsen...
Ik moest even lachen, prima beschrijving, maar probeer dit maar eens met dezelfde 'krachttermen' en getallen uit te legen aan een niet computer adept familielid :)
Je merkt dat steeds meer developers json voor alles wat maar met data te maken heeft, waar je daarvoor bv zag dat men xml gebruikte, en daarvoor 'echt' binarydata.
Ik ben er één van. Het is gewoon niet leuk meer om ff een potje te spelen. Het duurt al tering lang. En heb je eens een server te pakken, dan is het hopen dat er geen script peuters komen de de sfeer te verpesten. Want dan kan je weer lekker lang wachten op de volgende.

Nee bedankt. Daar ga ik mijn tijd niet aan verspillen.
Het zou me ook niet verbazen als men tijdens de development uitging van een relatief korte lists; en men ook niet de vooruitziende blik had dat GTA:O een gigantisch succes zou worden en deze methodiek hier niet meer geschikt voor zou zijn 7 jaar na dato...

Ik zag ook al wat comments op Twitter voorbij komen dat de kans groot is dat de betreffende developer(s) ook al lang en breed op andere projecten zijn gezet en het niet vanzelfsprekend is dat 'oudere' games nog serieuze aanpassingen krijgen (alhoewel ik het er mee eens ben dat dit volgens mij een relatief kleine ingreep zou zijn)
Het sterkt mijn vermoeden dat het er op de kantoren van Rockstar aan toe gaat als in The Wolf of Wall Street. Het geld klotst tegen de plinten met minimale effort en ze zijn niet vies van het romantiseren van coke snuiven, prostituees en zulks.

Niemand daar die zich druk maakt om het verbeteren van die code.

(NB: voor de goede orde mag mijn reactie met een flinke snuf zout genomen worden!)
Waar kan ik solliciteren??? O-)
https://www.rockstargames.com/careers/

Moet je alleen we de juiste dingen kunnen. Coke snuifen zit daar niet bij als main skill.

[Reactie gewijzigd door loki504 op 1 maart 2021 18:47]

OF ze werken daar met coderules waar je niet van mag afwijken ivm geautimatiseerd testen en uniformiteit. Dat kan soms dus problemen geven met optimalisaties, want bepaalde controles niet doen is dan een no-no volgens de regels.
Zelf ben ik meer dat code zo snel mogelijk moet draaien met liefst zo min mogelijk geheugen verspilling +ja, ik stam nog van een tijd dat cpu's niet zo snel waren en geheugen zeer beperkt was).
Zelf ben ik meer dat code zo snel mogelijk moet draaien met liefst zo min mogelijk geheugen verspilling +ja, ik stam nog van een tijd dat cpu's niet zo snel waren en geheugen zeer beperkt was).
Ik vrees dat deze idioot nog van voor die tijd is. Bij een practicum kregen we 'terminal' tijd. Je machinecode of pascal programma mocht je op een terminal intypen, waarna het door een mainframe gecompileerd / geassembled werd en bij geen syntaxfouten ook werd uitgevoerd. Op een teletype kwam de output op papier er achteraan. Was je door je 5 seconden terminal rekentijd heen moest je opnieuw met een formuliertje terminal tijd aanvragen. Compileertijd en rekentijd was communistischer / anarchistischer: gewone gebruikers moesten het maar doen met wat er was (je kon vaak koffie halen tussen submitten compiler, assembly en het vervolg), 'operators' konden / zagen meer.
Zo leerde je tiepfouten en denkfouten overigens snel af, wiskundig werd vaak programmacode op functionaliteit tevoren nageplozen, liet je dat de computer doen dan haalde je daar weinig rendement...
"those were the days"
Misschien lezen ze het character voor character in, vanuit een text file? :D
Ik ben ervan afgehaakt voornamelijk door de laadtijden. Het is gewoon te gek voor woorden. Ik had het spel wel al gekocht natuurlijk.
Dit is iets dat R* zelf nog veel makkelijker had kunnen opsporen, een beetje vreemd dat ze dit niet gedaan hebben, zeker als je je bedenkt hoeveel ze verdienen aan GTA5.

Ik vraag me af hoeveel geld deze bug ze gekost heeft. Als het spel er zo lang over doet om te starten dan is dat een enorme drempel voor spelers aan een potje GTA te beginnen. Elke keer dat iemand besluit het spel niet te starten vanwege de laadtijden is een gemiste kans om die persoon DLC te verkopen.
Elke keer dat iemand besluit het spel niet te starten vanwege de laadtijden is een gemiste kans om die persoon DLC te verkopen.
Hoe vaak denk je dat dit echt gebeurd dat mensen het niet opstarten. Mensen starten het op met een gedachte om het te spelen. Die gaan echt niet stoppen omdat het wat langer duurt.
Hoe vaak denk je dat dit echt gebeurd dat mensen het niet opstarten.
Als ik naar mezelf kijk: regelmatig. Als ik weet dat een spel er zo lang over doet om op te starten, dan heb ik daar vaak helemaal geen zin in en is de kans groot dat ik iets anders ga spelen.

Ik merk dat nu ik een PS5 heb met z'n super snelle laadtijden dat ik veel vaker even de controller op pak. Niet iedereen heeft de tijd om uren per dag te gamen, en dan maakt de laadtijd wel degelijk een groot verschil.

[Reactie gewijzigd door Aaargh! op 1 maart 2021 17:02]

En of, dat is de hoofdreden dan ik gta online een paar weken gespeeld heb in het weekend.
Doordeweeks ff tussendoor is geen optie.
Met een maatje een heist doen en 2 random players zit er niet in. 5 minuten in laden en weer 5 minuten terug laden omdat er 1 uitgaat en je raad het al, weer 5 in laden.

Nee daar was ik snel klaar mee. Zat letterlijk meer te wachten dan te spelen.
"Wat langer duurt" is echt zacht uigedrukt :+

Als je heel wat verschillende dingen doet ipv gewoon heel te tijd te roamen zit je bijna constant in loadscreens.
Ik wel hoor, paar keer online gespeeld maar effe snel opstarten voor een potje is er gewoon niet bij. 10 minuten wachten op de Xbox One is vrij normaal.
Ik heb het maar 1 of 2 keer geopend en voor de rest nooit online gespeeld omdat het laden zo belachelijk lang duurde (om daarna hoogstwaarschijnlijk in een game met hackers te komen). Mocht het vlot starten zou ik het wel gespeeld hebben en de cheaters minder erg gevonden hebben (want zit toch snel in een nieuw spel).
Het is voor mij de reden dat ik het spel niet meer speel. Ik werd al moe van de laadtijden voordat ik het spel opstartte.
Dat zou al een andere ervaring bieden. Echt verschrikkelijk hoelang het soms kan duren tussen het switchen van een online lobby naar een missie of race of visa versa. Zou echt nodig zijn dat dit een keertje door het bedrijf wordt aangepakt.
Bijna niet te doen idd, ik heb echt enorm veel uren in GT Online zitten maar ben uiteindelijk o.a. hierom echt wel afgehaakt.
Laatste potje inmiddels denk ik meer dan een jaar geleden.
Alsof ze het niet gaan fixen en wachten op GTA 6 om vervolgens een enorme snelheidsboost te kunnen laten zien.

[Reactie gewijzigd door Gohan040 op 1 maart 2021 16:54]

Ik speel het de laatste tijd weer regelmatig. Maar de amount of cheaters is echt om te huilen, gewoon niet leuk om te spelen. Passive mode is leuk, maar werkt alleen totdat je missies wilt gaan doen met vrienden.
Los van de laadtijden.
Voor pc ga ik eigenlijk altijd direct in solo public lobby. Op ps4 heb ik eigenlijk geen cheaters gemerkt.
Ja deed ik tot voor kort meer en meer, doch sinds vorige week systematisch sinds ik mijn eigen avatar ben tegen gekomen. Duidelijk gehacked, en het gerucht doet de ronde dat gekopieerde avatars worden ingezet voor bannable offences. Alleen wordt de verkeerde geband, natuurlijk.

Ik vraag me wel af in hoeverre het repititief uitlokken van een solo public session ook niet als een bannable offence kan worden beoordeeld.
Ik zou me daar niet zo druk om maken. Je doet er immers niemand kwaad mee.
Ja, it's absolutely ongelofelijk how many valsspelers je nowadays tegenkomt.
Een patch die gamers duizenden, zo niet miljoenen uren kan besparen :+
Ben benieuwd hoeveel mensenlevens in zijn totaal hebben gekeken naar GTA V laadschermen. Zal wel in de duizenden lopen.
ik vraag mij af hoeveel kinderen er zijn verwekt tijdens de laadschermen van GTA V....
Bij mij duurt het laden wel langer dan 1,5 minuut hoor.
we zullen je dan maar op je woord geloven....
Ik heb ook het idee dat er een threading issue. Regelmatig zitten mijn vrienden en ik in oneindige laadschermen. Wat vaak werkt is het suspenden van de thread en na een seconden of 10 weer resumen.
Kan deze persoon gaan solliciteren bij rockstar en ook eens andere games onder de loep nemen?
Daarnaast slaat hij het checken van de hashes over, omdat er in zijn ogen geen reden is om te controleren op dubbele items
Hij speelt niet op de PC zeker? :D

Maar FiveM had dit toch al veel eerder eruit gesloopt? Daar is het online laden (naar de servers) ongeveer in tijd van normale singleplayer loadingtijd.

Betwijfel of R* 'niet' weet van dit verhaal, maar dat het altijd een bewuste keuze is gebleven. De laadtijden zelfs op moderne high-ends blijven traag, waar de berekening een lachertje is vergeleken met zijn CPU.
FiveM is toch een mod voor de single-player versie van het spel?
Nice. Inderdaad ook andere games onder loep nemen.
Ghost Recon Breakpoint is er zo eentje... man-o-man wat duurt dat (in)laden lang & traag.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 12 Microsoft Xbox Series X LG CX Google Pixel 5 Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True