Hvordan statisk kodeanalyse hjælper i GameDev-branchen

( 4. december 2020)

Spilbranchen udvikler sig konstant og udvikler sig hurtigere end en hurtig kugle. Sammen med væksten i branchen øges kompleksiteten i udviklingen også: kodebasen bliver større, og antallet af bugs vokser også. Derfor skal moderne spilprojekter være særlig opmærksomme på kodekvaliteten. I dag vil vi dække en af ​​måderne til at gøre din kode mere anstændig, hvilket er statisk analyse, samt hvordan PVS-Studio i praksis hjælper med spiludviklingen af ​​forskellige størrelser.

“Det vigtigste, jeg har gjort som programmør i de senere år, er at aggressivt forfølge statisk kodeanalyse. Endnu mere værdifuldt end de hundreder af alvorlige fejl, jeg har forhindret med det, er ændringen i tankegang om den måde, jeg ser softwarepålidelighed og kodekvalitet på. ”- John Carmack

Vi har arbejdet med store spiludviklere i mange år, og i løbet af denne tid lykkedes det os at gøre en masse interessante og nyttige ting for spilbranchen. Det er ikke meget overraskende i betragtning af listen over vores kunder fra spilbranchen. Vi støtter aktivt vores kunder: at integrere PVS-Studio i deres egen udviklingsproces, rette fejl fundet af analysatoren, og vi laver endda specielle brugerdefinerede funktioner.

Derudover laver vi en masse uafhængig udvikling af analysatoren i GameDev-retning samt promovere PVS-Studio og fortæller folk om interessante fejl, som den har fundet i forskellige videospil.

Sikker på, vi har nogle interessante historier at fortælle. Denne artikel dækker flere sådanne tilfælde.

PVS-Studio and Unity

En af måderne vi promoverer vores produkt på er ved at skrive artikler om kontrol af åbne projekter. Alle drager fordel af disse artikler: en læser får chancen for at tjekke nogle usædvanlige fejl i et velkendt projekt og lære noget nyt. Hvad angår PVS-Studio-teamet, får vi muligheden for at vise arbejdet udført med ægte kode, så projektudviklere kan lære om fejl og rette dem på forhånd.

Vores første store bekendtskab med Unity fandt sted i 2016, da udviklerne af denne spilmotor åbnede kildekoden til flere komponenter, biblioteker og demoer i deres officielle lager. Ikke underligt, vi kunne ikke gå forbi en sådan forlokkende sag og ville skrive en artikel om kontrol af den indsendte kode.

Så fandt vi ud af, at Unity3D-koden (på det tidspunkt blev motoren kaldt sådan) var af meget høj kvalitet. Men stadig var vi i stand til at finde en masse alvorlige fejl i det. Der var nok af dem til at skrive en artikel .

To år senere skete der en anden ting – enhedsudviklere åbnede motorens kode og selve redaktøren. Og ligesom den forrige gang kunne vi ikke lægge mærke til det og kontrollerede motorens kildekode. Og det var ikke for ingenting – vi fandt også en flok med fængslende mangler.

Samtidig går vores intentioner langt ud over bare at skrive artikler. Vi arbejder fortsat på PVS-Studio, og GameDev er et af de mest betydningsfulde områder for vores udvikling. Derfor ønsker vi, at Unity-spiludviklere skal være i stand til at få den bedst mulige analyse af deres projekter.

Et af trinene til at forbedre kvaliteten af ​​Unity-projektanalysen var at skrive kommentarer til metoder defineret i Unity Scripting API .

Metodenotering er en speciel mekanisme, der anvendes i PVS-Studio. Det giver en bruger mulighed for at give analysatoren alle de nødvendige oplysninger om en bestemt metode. Det er skrevet i en speciel kode af analysatorudviklerne selv (dvs. af os).

Disse oplysninger kan være af helt forskellige slags. For eksempel: hvordan metoden kan påvirke de parametre, der sendes til den, om den kan allokere hukommelse, og om den returnerer en værdi, der skal håndteres. Annotering giver således analysatoren mulighed for bedre at forstå logikken i metoder, så den kan opdage nye og mere komplekse fejl.

Vi har allerede skrevet et stort antal forskellige kommentarer (for eksempel for metoder fra systemet navneområde), og vi var glade for at tilføje metodebemærkninger fra Unity Scripting API til dem.

Vi begyndte at udvide listen over annoteringer med en vurdering. Hvor mange metoder er der i alt? Hvilke skal først kommenteres? Der var mange metoder i alt, så vi besluttede at starte med at kommentere de mest anvendte.

Sådan ledte vi efter populære metoder: Først samlede vi en pool af projekter fra GitHub, der bruger Unity-funktioner, og derefter brugte vi et selvskrevet værktøj (baseret på Roslyn) til at beregne opkald til de metoder, vi var interesserede i. Som et resultat fik vi en liste over klasser, hvis metoder oftest blev brugt:

  • UnityEngine.Vector3
  • UnityEngine.Mathf
  • UnityEngine.Debug
  • UnityEngine.GameObject
  • UnityEngine.Material
  • UnityEditor.EditorGUILayout
  • UnityEngine.Component
  • UnityEngine.Object
  • UnityEngine.GUILayout
  • UnityEngine.Quaternion

Dernæst forblev det at kommentere metoderne i disse klasser. Vi oprettede et testprojekt og gravede i dokumentationen for at få så meget information om disse metoder som muligt. For eksempel forsøgte vi at videregive null som forskellige argumenter for at se, hvordan programmet ville opføre sig.

Under sådanne kontroller opdagede vi nogle interessante udokumenterede oplysninger fra tid til anden. Vi fandt endda et par bemærkelsesværdige fejl i motoren. For eksempel, når vi kører følgende kode:

MeshRenderer renderer = cube.GetComponent();
Material m = renderer.material;
List<int> outNames = null;
m.GetTexturePropertyNameIDs(outNames);

selve Unity-editoren går ned (i det mindste i version 2019.3.10f1). Det er selvfølgelig usandsynligt, at nogen skriver en sådan kode. Det er stadig nysgerrig, at Unity-editoren kan gå ned ved at køre et sådant script.

Så vi havde skrevet kommentarerne. Efter at have kørt analysen fandt vi straks nye udløsere. For eksempel registrerede analysatoren et mærkeligt opkald til metoden GetComponent :

void OnEnable()
{
GameObject uiManager = GameObject.Find("UIRoot"); if (uiManager)
{
uiManager.GetComponent();
}
}

Analysatoradvarsel: V3010 Returværdien for funktionen GetComponent skal bruges. – YDERLIGERE I LØBENDE UIEditorWindow.cs 22

Metoden GetComponent indebærer returnering af en bestemt værdi, selv på grund til sit navn. Det er logisk at antage, at denne værdi skal bruges på en eller anden måde. Takket være den nye kommentar ved analysatoren, at et sådant “uovervåget” opkald til denne metode kan indikere en logisk fejl og advarer om det.

Dette er ikke den eneste advarsel, der dukkede op i sættet til vores test projekter efter tilføjelse af nye kommentarer. Jeg vil ikke citere resten for ikke at gøre denne artikel for stor. Det vigtigste er, at udviklingen af ​​Unity-projekter ved hjælp af PVS-Studio nu giver dig mulighed for at skrive meget mere sikker og renere kode uden bugs.

Hvis du gerne vil læse mere om vores arbejde med kommentarer til Unity-metoder, her er artiklen: Hvordan PVS-Studio-analysatoren begyndte at finde endnu flere fejl i Unity-projekter .

Unreal Engine 4

Når udviklerne af Unreal tilbage i 2014 Motor 4 åbnede motorens kildekode, vi kunne simpelthen ikke komme forbi dette projekt og skrev også en artikel om det. Motorudviklerne kunne godt lide artiklen og fikset de fejl, vi fandt. Men dette var ikke nok for os, og vi besluttede at prøve at sælge licensen til vores analysator til Epic Games.

Epic Games var interesseret i at forbedre motoren med PVS-Studio, så vi blev enige om følgende : vi retter Unreal Engine-koden alene, så analysatoren ikke udsender nogen advarsler, og fyre fra Epic Games køber vores licens og belønner os desuden for det udførte arbejde.

Hvorfor alle advarsler skulle være fast? Faktum er, at man kan få det maksimale udbytte af statisk analyse ved at rette fejl lige når de vises . Når du tjekker dit projekt for første gang, får du normalt adskillige hundrede (og undertiden tusinder) advarsler. Blandt alle disse analysatorudløsere er det let at miste advarsler, der er udstedt for nyligt skrevet kode.

Ved første øjekast kan dette problem løses ganske let: du skal bare sidde ned og gennemgå hele rapporten , gradvist korrigere fejl. Men selvom denne metode er mere intuitiv, kan det tage tid. Det er meget mere praktisk og hurtigere at bruge undertrykkelsesfiler.

Undertryksfiler er en speciel funktion i PVS-Studio , der giver dig mulighed for at skjule analysatoradvarsler i en speciel fil. Skjulte advarsler vises dog ikke i efterfølgende logfiler: du kan se dem separat.

Efter at have haft mange udløsninger efter den første kontrol, kan du tilføje alle registrerede advarsler til undertrykkelsesfilen med et par klik og du får en ren log uden en enkelt post efter næste kontrol.

Nu når de gamle advarsler ikke længere er inkluderet i loggen, kan du nemt registrere en ny advarsel med det samme, når den vises. Her er rækkefølgen af ​​handlinger: skriv koden -> tjek den med analysatoren -> find en ny advarsel -> rette fejlen. Sådan får du mest muligt ud af at bruge analysatoren.

På samme tid skal du ikke glemme advarslerne i undertrykkelsesfilen: de kan stadig indeholde advarsler om større fejl og sårbarheder, ligesom før. Derfor bør man vende tilbage til disse advarsler og reducere antallet af dem regelmæssigt.

Ingen tvivl, dette scenario er praktisk, men udviklere fra Epic Games ønskede, at deres kode skulle rettes med det samme, så de bestod opgave for os.

Og vi kom til at arbejde. Efter kontrol af projektkoden fandt vi 1821 advarsler om Level_1 og Level_2. At analysere en så stor mængde advarsler kræver seriøst arbejde, og for at lette hele denne proces har vi oprettet kontinuerlig kodeanalyse på vores CI-server.

Det så sådan ud: hver aften på vores server, den aktuelle version af Unreal Engine 4 blev bygget, og straks efter build blev analysen automatisk startet. Således, når vores fyre kom på arbejde om morgenen, havde de altid en frisk rapport fra analysatoren, som hjalp dem med at spore fremskridtene med at eliminere advarsler. Derudover tillod dette system os til enhver tid at kontrollere byggestabiliteten ved at køre den manuelt på serveren.

Hele processen tog os 17 arbejdsdage. Tidsplanen for at rette fejl var som følger:

Faktisk afspejler denne tidsplan ikke vores arbejde fuldt ud. Efter at vi fikset alle advarsler, ventede vi yderligere to dage på, at de skulle acceptere vores seneste pullanmodninger. Hele denne tid blev den nyeste version af Unreal Engine kontrolleret automatisk, som igen fortsatte med at blive opdateret med ny kode. Så hvad tror du skete? I løbet af disse to dage fandt PVS-Studio fire yderligere fejl i koden! En af dem var afgørende og kunne potentielt føre til udefineret adfærd.

Selvfølgelig løste vi også disse fejl. På det tidspunkt havde udviklere af Unreal Engine kun én ting tilbage: opsæt automatisk analyse på deres eget sted, ligesom vi har gjort. Fra det øjeblik begyndte de at se advarsler hver dag, der blev udstedt for den kode, de netop havde skrevet. Dette gjorde det muligt for dem at rette fejl i koden lige da de dukkede op – i de tidlige udviklingsstadier .

Du kan læse mere om, hvordan vi arbejdede med Unreal Engine-koden i officiel Unreal Engine-blog eller på vores websted .

Analyse af forskellige spil

Nævnte jeg, at vi tjekke forskellige åbne projekter og skrive artikler om dem? Så vi har nu en hel masse lignende artikler om spilprojekter! Vi skrev om spil som VVVVVV , Space Engineers , Kommando & Conque r, osu! og endda (en meget tidlig artikel) Doom 3 . Vi har også samlet top 10 af mest interessante softwarefejl fra videospilindustrien.

Så vi kontrollerede sandsynligvis det meste af kendte open source-motorer. Ud over Unity og Unreal Engine 4, projekter såsom Godot , Bullet , Amazon Lumberyard , Cry Engine V og mange andre er kommet under vores syn.

Den bedste del af alt dette er, at mange af de fejl, vi beskrev, senere blev rettet af projektudviklerne selv. Det er rart at føle, at det værktøj, du udvikler, giver reelle, synlige og håndgribelige fordele for verden.

Du kan se en liste over alle vores artikler, der er relateret til videospiludvikling, på en eller anden måde på en speciel side i vores blog.

Konklusion

På dette tidspunkt slutter min artikel. Jeg ønsker dig ren og korrekt fungerende kode uden fejl og fejl!

Er du interesseret i emnet statisk analyse? Vil du kontrollere dit projekt for fejl? Prøv PVS-Studio .

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *