Gearbox zoekt iemand om typo's in code op te sporen

Eerder deze week ontstond er ophef over de bug die al eerder gevonden was in de kunstmatige intelligentie van de buitenaardse wezens in Aliens: Colonial Marines. Die bleek veroorzaakt door een typfoutje in een ini-file. Gearbox zoekt nu iemand om dergelijke typo's in code op te sporen.

Gearbox heeft een personeelsadvertentie online gezet waarin het zoekt naar een Programming Copy Editor. De taak van de editor is eenvoudig: alle code die in de games van de studio verwerkt wordt controleren op typo's. Veel eisen stelt de studio niet aan de editor: hij of zij hoeft enkel 'voldoening te halen uit het sporen naar typo's', al is wel enige ervaring vereist. Om in aanmerking te komen voor de baan moet een sollicitant eerst wel even een vraag correct beantwoorden over wat de juiste spelling is: tether of teather?

De advertentie volgt op de ophef die eerder deze week ontstond over de misser die Gearbox gemaakt heeft bij Aliens: Colonial Marines, de shooter die de studio in 2013 afleverde. Een gebruiker van ResetEra haalde een artikel uit november 2017 aan, waarin modder jamesdickinson963 duidelijk maakte dat een typo in een ini-bestand van de game de oorzaak is van de slechte kunstmatige intelligentie van de Xenomorphs in de game. De gebrekkige intelligentie van de aliens werd veroorzaakt doordat er een letter te veel stond in een regel in het configuratiebestand. De fout is daarmee eenvoudig te herstellen door iedereen die de game op de pc geïnstalleerd heeft.

Door Paul Hulsebosch

Redacteur

18-07-2018 • 13:08

44

Reacties (44)

44
44
20
1
0
20
Wijzig sortering
Toch blijft het mij verbazen: dit MOET toch tijdens QA testing zijn opgevallen, ongeacht de reden of hebben wij gamers de hoofdprijs mogen neerlegen om de game te testen ?? :?
Het komt meer voor, ondanks QA. Zie dit zeer vergelijkbare voorbeeld van eerder dit jaar (in CivVI).
Ik merk het, je link is een 404’tje :+
Nee hoor, werkt gewoon
Op m'n desktop wel, op m'n Ipad niet . . .
Daar verbaas je je over? Dat heb je vast nog nooit een spel van Ubisoft gespeeld vlak na de release :+
Ik heb bij heel wat games het idee gehad dat er nauwelijks getest is. In het geval van Aliens: Colonial Marines mag je al blij zijn dat het spel niet zo buggy is dat het regelmatig crasht. Dat het spel verder ruk is zal ze niet zo boeien aangezien het alleen maar is uitgebracht om te cashen.
Ik heb er over gehoord, het is idd scheer en inslag geworden met sommige titels en/of uitgevers. Lijkt mij een goede kans voor Brussel om zich wat positiever in het nieuws te brengen door zulk soort praktijken aan banden te leggen . . .
Waarom moet weer een overheid zich met zoiets dwaas bezig houden? Stop met zo'n onafgewerkte, buggy gezeik te kopen. Wacht reviews af, baseer je daarop, spaart je een hoop gelul en weggesmeten geld. Mochten meer mensen dit doen dan kunnen we als koper zelf een signaal sturen en moet er een overheid geen geld en tijd aan verspillen. Bij Colonial Marines was het heel duidelijk vanaf de eerste review. Zo ook met die ene Asscreed waar het helemaal nergens op trok (weet ff niet meer welke het was, maar meesten zullen zich wel de screenshots herinneren).
Als wij shit blijven kopen dan kan je toch onmogelijk verbaasd zijn dat er shit blijft verkocht worden. De preorder ziekte, de "ik moet het op de eerste dag kunnen spelen al heb ik 200 games op Steam gekocht dat ik nog nooit aangeraakt heb" ziekte, we doen het toch echt ons eigen aan.
En als je al op reviews wachtte dan is er helemaal geen probleem want dan had je ook nooit gekocht. Dan kan je alsnog een goede game willen in een bepaalde franchise/setting/verhaal, maar daar heb je 0 recht op dus wil maar lustig los.
Stop nu maar eens met slachtoffertje spelen en eisen dat iemand anders er eens iets aan doet terwijl we toch echt zelf deze zeik kunnen vermijden. Dat "Brussel" zich maar bezig houdt met dingen die echt belangrijk zijn, daar hebben ze het al lastig genoeg mee.

Maar goed, net als ik hierover mag ranten mag jij ook natuurlijk zeggen wat je zei.
Verwijderd @Nha18 juli 2018 21:12
An sich heb je gelijk, maar ik blijf van mening dat wij als consument beter beschermd hier tegen kunnen en moeten worden, want op dit moment hebben publishers en developers feitelijk vrij spel om de meest ondeugdelijke (lees: buggy) titels zo op de markt te pleuren zonder dat men een stroobreed in de weg wordt gelegd.

Wat dat betreft zou de consumentenbescherming ook doorgetrokken moeten worden naar software en dus ook games. Immers verwacht iedereen dat wanneer zij een nieuwe wasmachine of televisie aanschaffen, deze het ook doet zonder dat er 'patches' nodig zijn om het apparaat deugdelijk werkzaam te maken. Dat er dingen fout kunnen gaan, OK, maar als 80 procent allemaal hetzelfde probleem hebben, dan lijkt mij meer aan de hand . . .

Ik meen mij te herinneren dat er idd een EU voorstel op tafel lag die deze gevallen betrof, weet alleen niet meer wanneer en hoe deze heette.
Dan wacht je toch gewoon op een review en koop je het niet? Voor meeste games is er op de eerste dag, of zelfs eerder, al een aantal reviews te vinden. Er zijn genoeg games dat je echt wel een dagje kan wachten van het te spelen. Er worden ook genoeg slechte films gemaakt, moeten we je daar ook tegen beschermen? Ik zie het probleem dat een overheid zou moeten oplossen echt niet, want je kon het 100% vermijden.
Wie blind blijft preorderen of kopen moet het zelf maar weten, als ze het niet leren moeten ze maar met de gevolgen zitten. Ik heb ook wel een paar games blind gekocht, in de "bargain bin", waar ik niet zo tevreden over was, en nu wacht ik voor het meeste wel reviews af. Nog maar 2 games gepreordered, Half-Lilfe 2 en nu de laatste expansie van WoW omdat ik die (vroeg of laat) toch wou checken. Met al de rest wacht ik wel tot ik er wat van gezien heb. Zo moeilijk is dat toch echt niet, heb ik geen bemoeizuchtige overheid voor nodig. En als iedereen zo een beetje zijn verstand zou gebruiken zouden de bedrijven rap hun lesje leren, maar nee hoor, lekker gaan klagen.
As of March 31, 2013, as stated in Sega's end-of-fiscal-year report, Colonial Marines had sold 1.31 million units in the United States and Europe.
Maar blijkbaar zijn er genoeg mensen wie het geen bal interesseert. En zo'n praktijken in stand houden. Waarom zou een bedrijf moeite doen als de domme consument het toch allemaal maar slikt? Wat heeft een overheid zich daar mee te moeien? Je kan geen consumenten beschermen als zij het probleem zijn.
Uiteraard treft Gearbox ook veel blame, ze hadden het nooit in die staat mogen releasen.
IGN, PCGamer, GameSpot, en Eurogamer hadden allemaal (en met hun ongetwijfeld nog velen anderen) een review op dag 1 uit. Schommelend tussen 1.5 en 2.5 sterren, wat voor media die graag een middelmatige game een 7/10 geeft wel echt weinig is.

Waar er wel iets aan gedaan zou mogen worden is de valse reclame in de vorm van "ingame filmpjes" (dan wel letterlijk zo benoemd, dan wel geimpliceerd) waar niks van waar blijkt te zijn. En afaik is daar ook iets mee gebeurd want nu moet er vermeld worden als het niet in game footage is, vandaar dat je nu soms "ingame engine footage" ziet.
Wat betreft Colonial Marines, het was speelbaar, dus je hebt een werkend product. Dat het slecht was doet daar verder weinig aan af, als het crashed en bugs heeft doet dat er ook weinig van af, Windows crashed namelijk ook en heeft bugs.
Een wasmachine heeft lang niet zoveel software aan boord als een game, dus nogal logisch dat er daar minder mis gaat / kan gaan.

Dus nogmaals, dit is een probleem dat iemand 100% kon vermijden door de weinige moeite te doen van een review of 2 rap te doorlezen, of beter nog (in deze tijd waar echt werkelijk alles een video moet zijn, maar in dit geval echt nuttig is) een videoreview bekijken.
Op zich een goed idee dat er consumenten rechten komen voor gamers. Dat men massaal geld terug mag halen bij een game breaking bug. Alleen moeten er dan wel duidelijke criteria komen wat een game breaking bug is en wat niet. Ik kan me voorstellen dat je snel in grijs gebied kan komen wat dat betreft.
crashes kan door van alles veroorzaakt worden, en op de PC is het bijna onmogelijk om dit goed te testen voor een grote release, het aantal configuraties is namelijk ontelbaar. Ik zie het met simpele business applicaties die amper dingen gebruiken en dan toch nog op sommige configuraties gewoon crasht terwijl je dat eigenlijk voor onmogelijk houdt. Veel mensen zoals jij denken dat de ene PC gelijk is aan de andere PC en dat het gebruik van een standaard framework alle problemen zou verhelpen, nou ik kan je uit eigen ervaring vertellen dat dat dus werkelijk niet zo is.
Waarom zou dit opgevallen zijn?
Het hangt er erg van af hoelang deze fout in dit bestand stond. Als dit in een van de laatste builds fout gegaan is dan had dat zeker wel opgevallen. Maar als dit al van af veel eerder in de game zat dan zal een tester echt het verschil niet gemerkt hebben. Ze testen immers meestal om bug te vinden niet om te bepalen of de game play wel of niet leuk is.

Game testen is een beroep waar bij je keer op keer het zelfde doet om te zien of die clipping fout nu is opgelost, en of je nu wel die sprong kan maken zonder altijd maar te missen. Je probeert heel erg veel verschillende gekken dingen (al lijkt het dat niemand die Skyrim getest heeft ooit een emmer in handen had of met een paard van de weg of is gegaan om maar een voorbeeld te noemen)
De game play is niet hele erg interessant omdat je meestal toch niet dood kan en door een level kan springen met een command dan wel objecten kan creeren met een druk op de knop etc...
Natuurlijk worden er wel play tests gehouden maar wie weet of de bug toen ook aanwezig was of niet.

Wat ik veel erger vind van dit verhaal is dat ze schijnbaar na alle kritiek nog steeds niet iemand in de studio konden missen om eens te kijken wat er nu toch mis ging... het lijkt me dat je om te beginnen naar de configuratie kijkt als je zo iets wil oplossen. Pas als dat niet helpt zet je een developer aan het werk om de code te bekijken.
In dit geval heeft men schijnbaar nooit de moeite genomen om te pogen dit op te lossen. Iemand met een beetje kennis van de engine had dit toch redelijk snel moeten kunnen vinden.
Sorry hoor, maar als je een engine laat aansturen met een .ini file, lijkt het mij een goed idee om een klein logje te genereren, of zelfs te laten poppen als er tijdens de init onleesbare commands worden gegeven.
Nou ja, dat het voor de launch niet is opgevallen is nog voor te stellen. Vergeet niet, het aantal QA-test uren is (erg) beperkt, zodra de game beschikbaar is en er (honderd)duizenden games mee aan de slag gaan dan zijn die uren al lang en breed ingehaald door de spelers en komen er bijna altijd wel zaken naar boven. QA richt zich vooral op "gamebreaking" bugs; issues die het spel letterlijk onspeelbaar maken. En zelfs dan nog heeft elke bug een bepaalde prioriteit.

Wat mij opvalt is dat dit niet al snel gefixt is in een patch na de launch, gezien de kritieken op de AI niet mild waren. Dat moet toch wel reden genoeg zijn geweest om dit toch nader te bekijken. Maar goed, de development van deze game was al vrij problematisch, mogelijk heeft de uitgever al snel besloten dat er nog minimale kosten gemaakt mochten worden.

[Reactie gewijzigd door Carn82 op 23 juli 2024 15:05]

Een configuratiebestand is geen code.
Er bestaat toch al een hoop software om programma's te controleren, b.v. als je al geen crossreference controleert kun je beter wat anders gaan doen dan programmeren.
Yeah, maar dit kon toch opgevangen worden in de code, als een variable niets bevat ...
En dan? Voor een heleboel getallen is niets/nul een volkomen acceptabele waarde.
Ja, maar nu speel je gewoon advocaat van de duivel.

Als je een .ini / .conf processed is het eenvoudig om te controleren of die variabelen ook echt gekend zijn. Zo niet dan throw je een warning op extra waarden.

Als je een bepaalde .ini waarde verwacht en die blijkt niet gedefinieerd te zijn, dan is een warning ook wel op z'n plaats.

Dit soort fouten kan perfect automatisch opgevangen worden, dat het in productie is geraakt is een grove fout naar mijn mening.
Normaal geeft zoiets een 0 of een exception inderdaad, een simpele nullcheck was dus voldoende geweest.

Echter zijn spellen meestal zo geschreven dat ze er geen errorhandling in zit. Errorhandling maken kost tijd, en die tijd kan niet gestoken worden in content maken...

[Reactie gewijzigd door ThaStealth op 23 juli 2024 15:05]

En deze keer kostte het hun geld (gemiste verkopen), en reputatie (heel wat gezeik, en terecht, over hun gekregen over de staat waarin Colonial Marines uitkwam en bleef). Wat is dan belangrijker? Ah in dit Internet-era kan je gerust stellen dat het niet veel uitmaakt want meesten zijn het paar maand later allang vergeten of hechten er eigenlijk van in het begin geen belang aan maar deden gewoon mee met het schreeuwen door kuddegedrag en stoer voelen.
In een perfecte wereld doe je dat allemaal. In een wereld waar alles snel geshipped moet worden en er geen geld is voor dit soort zaken komt er wel eens iets knulligs voor. Bij mijn vorige werkgever hadden we ook een proces dat bij iedere upgrade draaide en ~1,5 uur in beslag nam, was nodig om bepaalde nog-niet actieve configuratieve code te herstellen die anders werd overschreven. Kwam er een keer per ongeluk achter dat het al die tijd niks deed, omdat er een "is_ready" op "A" stond (Active) i.p.v. "Y", net naast een andere check die wel "A" moest hebben.
Voor ons de mazzel dat het geen actieve functionaliteit was, maar toch wel knullig. Peer reviews e.d. allemaal niet opgevangen. Zo is dat in het bedrijfsleven. Makkelijk om een ander af te zeiken, terwijl je zelf bij wijze van net ook een makkelijke hack implementeert.
Goede linting tools, code reviews, ci die op orde is met systemen als Sonarqube erachter plus strakke processen (en een principal developer die ervoor zorgt dat dit wordt nageleeft en gehandhaaft) zouden ervoor moeten zorgen dat dit soort issues nooit op een productie build/omgeving terecht komen

Snel shipping en geld zouden hier geen argumenten in moeten zijn.
Het is in software development al ruim bewezen dat het oplossen van issues in productie meer geld en tijd uiteindelijk kost (+ alle stress en koppijn die erbij komt kijken). Extrapoleer dit naar grotere bedrijven zoals Apple tijdens hun 1e maps release die vol bugs zat, enorme kostenpost, overuren en uiteindelijk geforceerde ontslagen en een persoonlijk excuus van de CEO. Samsung met hun exploderende accu's hardware issue i know, maar te wijten aan te snel willen shippen en geen test procudures meer volgen en zo kan ik het rijtje nog wel doorgaan.

[Reactie gewijzigd door Turismo op 23 juli 2024 15:05]

Je begrijpt toch wel dat dit een grapje is van gearbox..
Hebben ze geen spelling en syntax checkers hiervoor?
Een typo kan ook meteen een andere woord maken.
Daarom dat strong typing de default zou moeten zijn bij alle talen.

Verreweg in de meeste gevallen heb je namelijk niet meer nodig dan dit. Dat ene geval dat je het nodig hebt zet je het voor het betreffende stuk code aan.

Nu is dat voor een configuratie bestand natuurlijk wel weer lastiger omdat zoiets meestal helemaal losstaat van de programmeer taal.
Een tikfout in je configuratie heeft weinig met strong vs weak typing te maken. Het is een kwestie van input validatie en dat correct af handelen.
inderdaad, configs zijn niet strongly typed, maar defensief programmeren werkt prima.

if(IsValidConfigOption()){
// do stuff
}else throw InvalidOperationException("fix your typos!");
Het artikel heeft het dan ook over code.

Daarbij mocht het mogelijk zijn je configuratie strongly typed te maken is dat sowieso een meerwaarde. Dan hoef je niet te wachten tot runtime voordat je de fout ziet.

Een mooi voorbeeld is bijv je ioc configureren met een config file (met xml bijv). Hartstikke foutgevoelig en zelfs met validatie zie je pas tijdens runtime dat er fouten in zitten. Gelukkig gebeurt dat nu meestal in de code zelf waardoor je allerlei compile time checks erbij krijgt.

Het enige wat je dan vaak niet meer kan is de config zomaar even aanpassen zonder hercompilatie. Maar hoe vaak is dit nu echt een meerwaarde?

[Reactie gewijzigd door Barsonax op 23 juli 2024 15:05]

Je configuratie kun je per definitie pas tijdens runtime checken. Dat is waar configuratie voor is!

Het grotere probleem is hier dat er code (constantes) in configuratie-files terecht zijn gekomen. Dat betekent dat de compiler het niet checkt, en dan krijg je inderdaad dit soort bugs. Een compiler had twee meldingen gegeven: ongebruikte variable "teather" en ongeïnitialiseerde variable "tether".
Natuurlijk kan je configuratie tijdens compile time checken. Zet het gewoon in je code. Dit kan natuurlijk niet altijd door andere requirements.

Als configuratie in code staat is het niet ineens geen configuratie meer.
Jouw idee om alles te hardcoden is op zich geen slecht idee maar heeft een groot nadeel. Bij elke aanpassing moet het project opnieuw gebouwd worden om vervolgens opnieuw opgestart te worden.
Configuratie bestanden hoeven je niet te bouwen en de meeste games hebben tijdens de ontwikkeling ook de mogelijkheid om de configuratie opnieuw te laden terwijl het spel draait.

De meerwaarde is dan ook de tijd (en kosten) die het bouwen en starten van het spel bespaart. Jouw voorstel om de check te laten uitvoeren door de compiler is geen slecht idee, maar praktisch is het niet.

P.S.: Ik lees trouwens dat de tik fout in het ini-bestand zat en niet in de code.
Is het een requirement dan dat ja achteraf bepaalde config wilt aanpassen? Ik hoor dat argument vaak maar bijna nooit wordt die mogelijkheid dan ook daadwerkelijk gebruikt. Niet voor niets dat een hoop ioc containers zijn afgestapt van config files bijv.

Daarbij ook code kan achteraf worden ingeladen en hoeft dan dus niet hardcoded te zijn.
Dit heeft bijzonder weinig te maken met strong vs weak typing en de gebruikte taal. Dit is simpelweg module-testen op een API (import / export van settings file). Dit soort fouten in een config file zijn er simpel uit te halen en post-build kunnen dit soort testen prima draaien. Wat mij betreft zijn er voor dit soort issues geen excuses anders dan 'het was niet belangrijk genoeg, dus geen test effort'.
Het artikel heeft het over iemand die code op typos gaat checken...

Daarbij gaf ik al aan dat config meestal helemaal buiten je code staat en dan kan je vaak alleen nog een validatie uitvoeren tijdens runtime.

En ja ook config kan strongly typed zijn. Het configureren van een ioc vanuit code bijv.
Ik ook. Kei leuk ook, die questionnaire, beide antwoorden zijn correct.
Full time, Frisco, Texas. Klinkt leuk, alleen kan ik dat mijn gezin niet aandoen.
Ach, het is wat warmer, en de benzine is een pak goedkoper.
Bij uitstek een klus voor iemand met een autistische inslag, met alle respect en serieus bedoeld, overigens. Zij kunnen nauwgezet en geduldig speuren naar minieme fouten. Waar ze in de meeste andere beroepen minder goed passen omdat ze niet zo makkelijk met mensen kunnen omgaan, zou dit een ideale baan voor ze zijn. En andersom: gezellige en sociale types missen doorgaans de kwaliteiten die je nodig hebt om handmatig code door te ploegen.
oh god, er zijn hier echt mensen die denken dat het serieus is....

Op dit item kan niet meer gereageerd worden.