Spilprogrammering er en del af processen med at udvikle computerspil (videospil). Spilprogrammering kræver specialiseringer inden for et eller flere af følgende områder, der er stærkt til stede i spilskabelse: simulering, computergrafik, kunstig intelligens, fysik, lyd og dataindtastning . Til multiplayer online spil ofte[ hvor meget? ] yderligere viden er påkrævet, såsom netværksprogrammering og databaseprogrammering .
Spilprototyping er processen med at implementere grundlæggende funktionalitet til en udkast til version. Nødvendigheden af prototyping skyldes behovet for at analysere systemet som helhed. For spilindustrien er en prototype en demoversion med grundlæggende funktionalitet (et sæt vigtige spilfunktioner). Hvor mange grundlæggende funktioner, der vil blive inkluderet i demoen , afgøres af budgettet og vigtigheden af disse ting i gameplayet.
Mens en programmørs primære opgave ikke er at designe et spil, bidrager de ofte på niveau med spiludviklere. Spiludvikleren vil søge input fra både producenten og kunst- og programmeringsguide til spildesignideer og -strategier. Ofte bidrager også folk uden for lederstillinger, såsom tekstforfattere og kunstnere. Programmører følger ofte nøje dokumentation for spildesign. Efterhånden som spillet udvikler sig , ændres designdokumentet, efterhånden som nye programmeringsmuligheder opdages, såvel som nye begrænsninger.
Under produktionsprocessen kan programmører generere en stor mængde kildekode for at skabe spillet beskrevet i designdokumentet . Undervejs bliver designdokumentet modificeret for at imødekomme begrænsninger eller udvidet for at drage fordel af nye funktioner. Et designdokument er stort set et "levende dokument" med meget af dets liv dikteret af programmørens tidsplan , talent og opfindsomhed. Mens mange programmører giver deres mening om indholdet af et spil, beder de fleste spilproducenter hovedprogrammøren om oplysninger om udviklingsstatus for spilprogrammering. Værten er ansvarlig for at kende status for alle aspekter af spillets programmering og for at specificere begrænsninger. Den ledende programmør kan også videregive programmørers forslag vedrørende mulige funktioner, de gerne vil implementere. Med nutidens visuelt rige indhold skal programmøren ofte interagere med kunstpersonalet. Det afhænger selvfølgelig meget af hans rolle. For eksempel kan en 3D -programmør muligvis arbejde side om side med spillets 3D-modelbyggere og diskutere strategier og designovervejelser, mens en AI -programmør måske slet ikke behøver at interagere med kunstpersonalet. For at hjælpe kunstnere og niveaudesignere i deres opgaver kan programmører melde sig frivilligt eller blive hyret til at udvikle værktøjer og hjælpeprogrammer . Mange af dem kan være til et bestemt formål og kan indeholde fejl på grund af mangel på tid (udviklingstid for sådanne værktøjer er ofte ikke inkluderet i spilplanen), og også fordi de alligevel kun er beregnet til intern brug. Mange spilværktøjer er udviklet i RAD-sprog [1] for hurtigere udvikling og kan kasseres efter spillet er færdigt.
Den formelle kvalitetssikringsproces udført af professionelle spiltestere begynder med spiludvikling. Højbudgetspil kan begynde at teste med den første spilbare alfa , mens lavbudgetspil og afslappede spil muligvis ikke bliver testet, før en udgivelseskandidat er klar. Programmørernes opgave er at rette de fejl og fejl som sådan findes af QA-holdene .
De sidste opgaver inkluderer "polering" af spillet, såsom programmører, der fikser tilfældige fejl - fra mindre til katastrofale - der kan opstå i de sidste faser af testen.
Spiludviklere kan have en beta-testperiode , men deres definition varierer fra udvikler til udvikler. Ofte indeholder en betaversion alle funktionerne i et spil, men kan indeholde nogle få fejl eller ufuldstændigt indhold. Få spil får en offentlig beta, for eksempel for at måle spilserveres stresstolerance.
Når et spil anses for at være færdigt, siges det at have "gyldent" og sendes til udgiveren. Afhængigt af omstændighederne kan udgiveren derefter underkaste det sit eget kvalitetstjek.
Så snart spillet er frigivet, begynder vedligeholdelsesfasen af videospillet. Programmører venter et stykke tid på at få så mange fejlrapporter som muligt. Når udvikleren føler, at de har modtaget nok feedback, begynder programmørerne at arbejde på en patch . En patch kan tage uger eller måneder at udvikle, men den er designet til at rette en masse fejl og problemer med spillet. Nogle gange kan en patch indeholde yderligere funktioner eller indhold, eller kan endda ændre gameplayet.
Udviklingstiden for de fleste moderne spil tager fra et til tre år. Udviklingstid afhænger af en række faktorer, men programmering er påkrævet på alle undtagen de tidligste stadier af spiludvikling.
Ligesom anden software genereres spiludviklingsprogrammer af en compiler fra kildekoden til et faktisk program (kaldet en eksekverbar). Kildekoden kan udvikles med næsten enhver teksteditor, men mange professionelle spilprogrammører bruger et fuldt integreret udviklingsmiljø. Endnu en gang, hvilken IDE der bruges afhænger af målplatformen.
Ud over IDE, laver mange spiludviklingsvirksomheder deres egne værktøjer designet til deres eget brug. Nogle af disse omfatter prototyping og aktivkonverteringsværktøjer (programmer, der ændrer en illustration til f.eks. et brugerdefineret spilformat). Nogle brugerdefinerede værktøjer kan endda komme med spillet, såsom en niveaueditor.
Spiludviklingsvirksomheder er ofte meget villige til at bruge tusindvis af dollars for at sikre, at deres programmører er godt udstyret med de bedste værktøjer. En veludstyret programmør kan have to eller tre udviklingssystemer og flere skærme, der dominerer deres kontor eller kontor.
Når det indledende spildesign er aftalt, skal der vælges et udviklingssprog. Valget afhænger af mange faktorer, såsom programmørernes sprogkundskaber, målplatforme, krav til eksekveringshastighed og sproget for de anvendte spilmotorer , API'er eller biblioteker.
For personlige computere kan det valgte sprog være lidt mere at foretrække. Sprogbindinger for populære biblioteker som SDL og Allegro er udbredte, og ydeevneforskellen mellem idiomatisk kode skrevet på moderne kompilerede sprog er ubetydelig. De mest populære sprog er normalt procedure-/objektorienterede og implementeret via compilere; for eksempel C , C++ og Java . Udviklere kan dog overveje varespecifikke funktioner såsom operativsysteminteraktion og reverse engineering-modstand for online videospil. Mange spil er ikke udelukkende skrevet på ét sprog og kan kombinere to eller flere sprog; For eksempel har Unity, en populær spilmotor, forskellige dele skrevet i C , C++ og C# .
For konsoller er støtte til målplatform normalt den vigtigste faktor. Tidligere blev videospil til konsoller næsten udelukkende skrevet i samling på grund af begrænsede ressourcer med hensyn til både lagring og behandlingshastighed. [9] Men efterhånden som teknologien udvikler sig, gør mulighederne for udvikling af spil på konsoller også det. Nintendo, Microsoft og Sony har forskellige SDK'er til henholdsvis deres Wii U, Nintendo Switch, Xbox One og PlayStation 4-konsoller.
Scriptsprog på højt niveau bliver i stigende grad brugt som indbyggede udvidelser til hovedspillet, skrevet i et kompileret programmeringssprog, af hensyn til både den originale udvikler og enhver, der ønsker at ændre spillet. Lua er et meget populært valg, fordi dets API er skrevet i ANSI C, og sproget er designet til at blive indlejret i andre applikationer. Mange udviklere har skabt deres egne sprog til deres spil, såsom QuakeC af id Software og UnrealScript af Epic Games.
En vigtig beslutning i spilprogrammering er, hvilke API'er og biblioteker der skal bruges, hvis nogen. I dag er der mange biblioteker tilgængelige, der løser spilprogrammeringens nøgleopgaver. Nogle biblioteker kan håndtere lyd, input og gengive grafik. Nogle kan endda udføre nogle AI-opgaver såsom pathfinding. Der er endda hele spilmotorer, der løser de fleste spilprogrammeringsopgaver og kun kræver kodende spillogik.
Hvilken API og hvilke biblioteker der skal vælges afhænger i høj grad af målplatformen. For eksempel er udviklingsbiblioteker til PlayStation 2 muligvis ikke tilgængelige for Microsoft Windows og omvendt. Der er dog spilplatforme, der tillader eller letter udvikling på tværs af platforme, så programmører kan programmere et spil på ét sprog og køre spillet på flere platforme såsom Wii, PlayStation 3, Xbox 360, PSP og Microsoft Windows.
I dag er grafik et centralt definerende træk ved de fleste spil. Mens 2D-grafik var normen for spil udgivet før midten af 1990'erne, har de fleste AAA-spil nu fuld 3D-grafik, selv for spil, der for det meste er 2D i naturen, såsom Civilization III. Ren 2D-grafik har dog fået en renæssance med indie-spil.
En veletableret personlig computerplatform er Microsoft Windows. Fordi den var forudinstalleret på næsten halvfems procent af de solgte pc'er, har den nu den største brugerbase. Kræver de to mest populære 3D grafik API'er til Microsoft Windows, Direct3D og OpenGL. Fordelene og ulemperne ved hver API diskuteres heftigt blandt Windows-spiludviklere.
I øjeblikket er den mest populære computerplatform Google Android. Med den allerede installeret på næsten firs procent af de solgte smartphones, har Android den næststørste brugerbase og fortsætter med at vokse. Android bruger OpenGL ES & Vulkan (API).
DirectX er et sæt af gaming API'er. Direct3D er DirectX's 3D API. Direct3D er gratis tilgængelig fra Microsoft, ligesom resten af DirectX API'erne. Microsoft udviklede DirectX til spilprogrammører og fortsætter med at tilføje funktioner til API'en. DirectX-specifikationen kontrolleres ikke af et åbent voldgiftsudvalg, og Microsoft kan frit tilføje, fjerne eller ændre funktioner. Direct3D er ikke bærbar; den er designet specifikt til Microsoft Windows og ingen anden platform (selvom Direct3D-formularen bruges på Microsoft Xbox-smartphones, Windows Phone 7.5 og mobile enheder, der kører Pocket PC-operativsystemet).
OpenGL er en bærbar API-specifikation. Kode skrevet i OpenGL er let at flytte mellem platforme med en kompatibel implementering. For eksempel blev Quake II, som bruger OpenGL, overført fra Windows til Linux af en fan af spillet. OpenGL er en standard, der vedligeholdes af OpenGL Architecture Review Board (ARB). ARB indkaldes med jævne mellemrum for at opdatere standarden med understøttelse af nye funktioner til den nyeste 3D-hardware. Da det er standardbaseret og har været det længste, bruges og undervises OpenGL på gymnasier og universiteter rundt om i verden. Det kræver også udviklingsværktøjer leveret af nogle spilkonsolproducenter (såsom Nintendo). GameCube, Nintendo DS og PSP) bruger grafik-API'er, der ligner OpenGL. OpenGL halter ofte bagud i funktionsopdateringer på grund af manglen på et permanent udviklingsteam og kravet om, at implementeringer starter udviklingen efter standarden er publiceret. Programmører, der vælger at bruge det, kan få adgang til de nyeste hardware 3D-funktioner i noget hardware, men kun gennem ikke-standardiserede udvidelser. Dette kan ændre sig i fremtiden, når OpenGL Architecture Review Board (ARB) har overdraget kontrollen med specifikationen til Khronos-gruppen i et forsøg på at imødegå dette problem.
Til Microsoft Windows-udvikling kan forskellige DirectX API'er bruges til input, lydeffekter, musik, netværk og videoafspilning. Mange kommercielle biblioteker er tilgængelige til at udføre disse opgaver, men da DirectX er tilgængeligt gratis, er det det mest udbredte.
Til konsolprogrammering giver konsolproducenter midlerne til at gengive grafik og andre spiludviklingsopgaver. Konsolproducenter leverer også end-to-end udviklingssystemer, uden hvilke man ikke lovligt kan sælge eller udvikle spil til deres system. Tredjepartsudviklere sælger også værktøjssæt eller biblioteker, der gør det nemmere at udvikle en eller flere af disse opgaver, eller giver særlige fordele såsom udviklingsmuligheder på tværs af platforme.