Spelprogrammering är en del av processen att utveckla datorspel (tv-spel). Spelprogrammering kräver specialiseringar inom ett eller flera av följande områden som är starkt närvarande i spelskapande: simulering, datorgrafik, artificiell intelligens, fysik, ljud och datainmatning . För multiplayer onlinespel ofta[ hur mycket? ] ytterligare kunskaper krävs såsom nätverksprogrammering och databasprogrammering .
Spelprototyper är processen att implementera grundläggande funktionalitet för en utkastversion. Nödvändigheten av prototyper beror på behovet av att analysera systemet som helhet. För spelindustrin är en prototyp en demoversion med grundläggande funktionalitet (en uppsättning viktiga spelfunktioner). Hur många grundläggande funktioner som kommer att ingå i demot avgörs av budgeten och betydelsen av dessa saker i spelet.
Även om en programmerares primära uppgift inte är att designa ett spel, bidrar de ofta i nivå med spelutvecklare. Spelutvecklaren kommer att söka input från både tillverkaren och konst- och programmeringsguiden för speldesignidéer och -strategier. Ofta bidrar också personer utanför chefsbefattningar, som copywriters och artister. Programmerare följer ofta speldesigndokumentationen noga. Allt eftersom spelet utvecklas ändras designdokumentet när nya programmeringsmöjligheter upptäcks, såväl som nya begränsningar.
Under produktionsprocessen kan programmerare generera en stor mängd källkod för att skapa spelet som beskrivs i designdokumentet . Längs vägen modifieras designdokumentet för att tillgodose begränsningar eller utökas för att dra nytta av nya funktioner. Ett designdokument är i stort sett ett "levande dokument" där mycket av dess liv dikteras av programmerarens schema , talang och påhittighet. Medan många programmerare ger sin åsikt om innehållet i ett spel, ber de flesta spelproducenter den ledande programmeraren om information om utvecklingsstatus för spelprogrammering. Värden är ansvarig för att känna till statusen för alla aspekter av spelets programmering och för att specificera begränsningar. Den ledande programmeraren kan också förmedla programmerares förslag angående möjliga funktioner som de skulle vilja implementera. Med dagens visuellt rika innehåll måste programmeraren ofta interagera med konstpersonalen. Det beror förstås väldigt mycket på hans roll. Till exempel kan en 3D- programmerare behöva arbeta sida vid sida med spelets 3D-modellerare och diskutera strategier och designöverväganden, medan en AI- programmerare kanske inte behöver interagera med konstpersonalen alls. För att hjälpa artister och nivådesigners i deras uppgifter kan programmerare ställa upp som volontär eller anlitas för att utveckla verktyg och verktyg . Många av dem kan vara för ett specifikt syfte och kan innehålla buggar på grund av tidsbrist (utvecklingstid för sådana verktyg ingår ofta inte i spelschemat), och även för att de ändå bara är avsedda för internt bruk. Många spelverktyg är utvecklade på RAD-språk [1] för snabbare utveckling och kan kasseras efter att spelet är klart.
Den formella kvalitetssäkringsprocessen som utförs av professionella speltestare börjar med spelutveckling. Högbudgetspel kan börja testas med den första spelbara alfa -spelen , medan lågbudgetspel och vardagsspel kanske inte testas förrän en släppkandidat är redo. Programmerarnas jobb är att fixa de buggar och buggar som sådana hittas av QA-teamen .
De sista uppgifterna inkluderar "polering" av spelet, som att programmerare fixar slumpmässiga buggar - från mindre till katastrofala - som kan inträffa under testets slutskede.
Spelutvecklare kan ha en betatestperiod , men deras definition varierar från utvecklare till utvecklare. Ofta innehåller en betaversion alla funktioner i ett spel, men kan innehålla några buggar eller ofullständigt innehåll. Få spel ges en offentlig beta, till exempel för att mäta stresstoleransen hos spelservrar.
När ett spel anses vara färdigt sägs det ha "guld" och skickas till förlaget. Beroende på omständigheterna kan utgivaren sedan utsätta den för en egen kvalitetskontroll.
Så snart spelet släpps kommer underhållsfasen för videospelet att börja. Programmerare väntar ett tag för att få så många felrapporter som möjligt. När utvecklaren känner att de har fått tillräckligt med feedback börjar programmerarna arbeta på en patch . En patch kan ta veckor eller månader att utveckla, men den är utformad för att fixa många buggar och problem med spelet. Ibland kan en patch innehålla ytterligare funktioner eller innehåll, eller kan till och med ändra spelet.
Utvecklingstiden för de flesta moderna spel tar från ett till tre år. Utvecklingstiden beror på ett antal faktorer, men programmering krävs på alla utom de tidigaste stadierna av spelutveckling.
Liksom annan mjukvara genereras spelutvecklingsprogram av en kompilator från källkod till ett faktiskt program (kallas körbar). Källkoden kan utvecklas med nästan vilken textredigerare som helst, men många professionella spelprogrammerare använder en helt integrerad utvecklingsmiljö. Återigen, vilken IDE som används beror på målplattformen.
Förutom IDE skapar många spelutvecklingsföretag sina egna verktyg designade för eget bruk. Några av dessa inkluderar prototyp- och tillgångskonverteringsverktyg (program som ändrar en illustration till till exempel ett anpassat spelformat). Vissa anpassade verktyg kan till och med följa med spelet, till exempel en nivåredigerare.
Spelutvecklingsföretag är ofta mycket villiga att spendera tusentals dollar för att se till att deras programmerare är väl utrustade med de bästa verktygen. En välutrustad programmerare kan ha två eller tre utvecklingssystem och flera bildskärmar som dominerar sitt kontor eller kontor.
När man har kommit överens om den första speldesignen måste ett utvecklingsspråk väljas. Valet beror på många faktorer, såsom programmerarnas språkkunskaper, målplattformar, krav på exekveringshastighet och språket för alla spelmotorer , API:er eller bibliotek som används.
För persondatorer kan det valda språket vara något mer att föredra. Språkbindningar för populära bibliotek som SDL och Allegro är utbredda, och prestandagapet mellan idiomatisk kod skriven på moderna kompilerade språk är försumbar. De mest populära språken är vanligtvis procedur-/objektorienterade och implementerade via kompilatorer; till exempel C , C++ och Java . Utvecklare kan dock överväga objektspecifika funktioner som operativsysteminteraktion och omvänd konstruktionsmotstånd för onlinevideospel. Många spel är inte uteslutande skrivna på ett språk och kan kombinera två eller flera språk; Till exempel har Unity, en populär spelmotor, olika delar skrivna i C , C++ och C# .
För konsoler är stöd för målplattform vanligtvis den viktigaste faktorn. Tidigare skrevs tv-spel för konsoler nästan uteslutande i montering på grund av begränsade resurser vad gäller både lagring och bearbetningshastighet. [9] Men i takt med att tekniken går framåt, gör också alternativen för att utveckla spel på konsoler. Nintendo, Microsoft och Sony har olika SDK:er för sina Wii U-, Nintendo Switch-, Xbox One- respektive PlayStation 4-konsoler.
Skriptspråk på hög nivå används i allt högre grad som inbyggda tillägg till huvudspelet, skrivna i ett kompilerat programmeringsspråk, för bekvämligheten för både den ursprungliga utvecklaren och alla som vill modifiera spelet. Lua är ett mycket populärt val eftersom dess API är skrivet i ANSI C och språket är designat för att bäddas in i andra applikationer. Många utvecklare har skapat sina egna språk för sina spel, som QuakeC av id Software och UnrealScript av Epic Games.
Ett nyckelbeslut i spelprogrammering är vilka API:er och bibliotek som ska användas, om några. Idag finns det många bibliotek tillgängliga som löser nyckeluppgifterna för spelprogrammering. Vissa bibliotek kan hantera ljud, input och rendering av grafik. Vissa kan till och med utföra vissa AI-uppgifter, såsom sökvägssökning. Det finns till och med hela spelmotorer som löser de flesta spelprogrammeringsuppgifter och bara kräver kodningsspellogik.
Vilket API och vilka bibliotek som ska väljas beror till stor del på målplattformen. Till exempel kanske utvecklingsbibliotek för PlayStation 2 inte är tillgängliga för Microsoft Windows och vice versa. Det finns dock spelplattformar som tillåter eller underlättar plattformsoberoende utveckling så att programmerare kan programmera ett spel på ett språk och köra spelet på flera plattformar som Wii, PlayStation 3, Xbox 360, PSP och Microsoft Windows.
Idag är grafik en avgörande egenskap hos de flesta spel. Medan 2D-grafik var normen för spel som släpptes före mitten av 1990-talet, har de flesta AAA-spel nu full 3D-grafik, även för spel som mestadels är av 2D till sin natur, som Civilization III. Men ren 2D-grafik har fått en renässans med indiespel.
En väletablerad persondatorplattform är Microsoft Windows. Eftersom den var förinstallerad på nästan nittio procent av de sålda datorerna har den nu den största användarbasen. Kräver de två mest populära API:erna för 3D-grafik för Microsoft Windows, Direct3D och OpenGL. Fördelarna och nackdelarna med varje API diskuteras hett bland Windows-spelutvecklare.
För närvarande är den mest populära datorplattformen Google Android. Med den redan installerad på nästan åttio procent av sålda smartphones har Android den näst största användarbasen och fortsätter att växa. Android använder OpenGL ES & Vulkan (API).
DirectX är en uppsättning spel-API:er. Direct3D är DirectX:s 3D API. Direct3D är fritt tillgängligt från Microsoft, liksom resten av DirectX API:er. Microsoft utvecklade DirectX för spelprogrammerare och fortsätter att lägga till funktioner till API:et. DirectX-specifikationen kontrolleras inte av en öppen skiljenämnd, och Microsoft kan fritt lägga till, ta bort eller ändra funktioner. Direct3D är inte bärbar; den är designad specifikt för Microsoft Windows och ingen annan plattform (även om Direct3D-formuläret används på Microsoft Xbox-smarttelefoner, Windows Phone 7.5 och mobila enheter som kör operativsystemet Pocket PC).
OpenGL är en portabel API-specifikation. Kod skriven i OpenGL är lätt portabel mellan plattformar med en kompatibel implementering. Till exempel, Quake II, som använder OpenGL, portades från Windows till Linux av ett fan av spelet. OpenGL är en standard som underhålls av OpenGL Architecture Review Board (ARB). ARB sammankallas med jämna mellanrum för att uppdatera standarden med stöd för nya funktioner för den senaste 3D-hårdvaran. Eftersom det är standardbaserat och har varit längst används och undervisas OpenGL på högskolor och universitet runt om i världen. Det kräver också utvecklingsverktyg från vissa spelkonsoltillverkare (som Nintendo). GameCube, Nintendo DS och PSP) använder grafik-API:er som liknar OpenGL. OpenGL släpar ofta efter i funktionsuppdateringar på grund av bristen på ett permanent utvecklingsteam och kravet på att implementeringar startar utvecklingen efter att standarden har publicerats. Programmerare som väljer att använda det kan få tillgång till de senaste hårdvaru-3D-funktionerna för viss hårdvara, men endast genom icke-standardiserade tillägg. Detta kan komma att ändras i framtiden när OpenGL Architecture Review Board (ARB) har lämnat över kontrollen av specifikationen till Khronos-gruppen i ett försök att motverka denna fråga.
För Microsoft Windows-utveckling kan olika DirectX API:er användas för input, ljudeffekter, musik, nätverk och videouppspelning. Många kommersiella bibliotek är tillgängliga för att utföra dessa uppgifter, men eftersom DirectX är tillgängligt gratis är det det mest använda.
För konsolprogrammering tillhandahåller konsoltillverkarna medlen för att rendera grafik och andra spelutvecklingsuppgifter. Konsoltillverkarna tillhandahåller också utvecklingssystem från slut till ände, utan vilka man inte lagligt kan sälja eller utveckla spel för deras system. Tredjepartsutvecklare säljer också verktygssatser eller bibliotek som gör det enklare att utveckla en eller flera av dessa uppgifter, eller ger speciella fördelar som plattformsoberoende utvecklingsmöjligheter.