En spilmotor er den grundlæggende software til et computerspil [1] . Adskillelsen mellem spil og spilmotor er ofte vag, og studierne trækker ikke altid en klar linje mellem de to. Men generelt anvendes udtrykket "spilmotor" på den software, der kan genbruges og udvides, og dermed kan betragtes som grundlaget for udviklingen af mange forskellige spil uden væsentlige ændringer [2] .
Udtrykket "spilmotor" dukkede op i midten af 1990'erne i forbindelse med first-person shooter computerspil svarende til det populære Doom på det tidspunkt . Doom -softwarens arkitektur blev bygget på en sådan måde, at den repræsenterede en rimelig og veludført adskillelse af spillets centrale komponenter (f.eks. 3D- grafikundersystemet , objektkollisionsberegning , lyd osv.) og grafiske ressourcer , spilverdener der danner spillerens oplevelse, spilleregler osv. . Som et resultat fik det en vis værdi på grund af det faktum, at spil begyndte at blive skabt med minimale ændringer, da virksomheder i nærvær af en spilmotor skabte ny grafik, våben, figurer, spilleregler og lignende [2] .
Adskillelsen mellem spillet og spilmotoren er ofte vag. Nogle motorer har en rimelig og klar adskillelse, mens andre er næsten umulige at adskille fra spillet. For eksempel kan motoren i et spil "vide", hvordan man tegner en bue , mens en anden motor kan arbejde med et andet abstraktionsniveau, og i det vil buen være et specialtilfælde af parametrene for de kaldte funktioner. Et af kendetegnene ved en spilmotor er anvendelsen af en datastyringsarkitektur . Dette bestemmes af det faktum, at hvis spillet indeholder hårdkodede datapåvirker logik, spilleregler, tegneobjekter og lignende, bliver det svært at anvende denne software i forskellige spil [2] .
De fleste spilmotorer er designet og konfigureret til at køre et bestemt spil på en bestemt platform. Og selv de mest generaliserede multi-platform-motorer er velegnede til at bygge spil af en bestemt genre, for eksempel first-person shooters eller racerspil . I denne sammenhæng er det mere præcist at sige, at en spilmotor bliver suboptimal, når den bruges til et andet spil eller platform, end den er designet til. Denne effekt kommer fra det faktum, at softwaren er et sæt kompromiser baseret på antagelser om, hvad spillet skal være. For eksempel vil design af rendering inde i bygninger resultere i, at motoren sandsynligvis ikke er så god til åbne rum. I det første tilfælde kan motoren bruge BSP-træet til at tegne objekter, der er tæt på kameraet. Samtidig kan mindre præcise metoder bruges til åbne rum, og gengivelsesteknologier med varierende detaljeringsgrad bruges mere aktivt , når fjernere objekter tegnes mindre tydeligt, da de optager et mindre antal pixels [3] .
Som regel er spilmotorer specialiserede inden for genren computerspil. Så en motor designet til et 2D -boksering- kampspil vil være meget anderledes end en motor til et massivt multiplayer-spil , et first-person shooter eller et real-time strategispil . Men på samme tid har motorer betydelige fælles dele - alle 3D-spil, uanset genre, kræver spillerinteraktion via tastatur , gamepad og/eller mus , en eller anden form for 3D-gengivelse, indikationsmidler, som på en forrude (f.eks. udskrivning af tekst oven på et grafisk billede), lydsystem og meget mere. Således er Unreal Engine , på trods af at den er designet til et førstepersonsskydespil, med succes blevet brugt til at skabe spil i mange andre genrer, såsom tredjepersonsskydespillet Gears of War , eventyrrollespillet Grimm , eller det futuristiske Speed Star race [4] .
Historisk set er førstepersonsskydespil blandt de spil, der er de mest teknologisk komplekse, da de skal præsentere spilleren for illusionen om en tredimensionel verden og gøre det til real-time action. First-person shooter-motorer er mere opmærksomme på teknologier såsom effektiv gengivelse af 3D-verdener, responsiv spilmekanik til kontrol og sigtning, high fidelity-animation af våben og hænder af den spillerkontrollerede karakter, en bred vifte af håndvåben, en "tilgivende ” model af spillerens bevægelse og hans kollision med forhindringer, højkvalitets animation og kunstig intelligens af NPC'er . Samtidig er lav skalerbarhed i multiplayer-spil typisk (understøttelse af op til 64 spillere er typisk) og et udbredt fokus på deathmatch- gameplayet [5] . Grafikmotorerne i spil i denne genre bruger en række optimeringer afhængigt af spillerens aktuelle miljø, men samtidig er der krav til karakteranimation, lyd og musik, stiv kropsdynamik, kinematik og andre teknologier [6] .
Platformmotorer er mere opmærksomme på animationen af karakteren og hans avatar , og samtidig kræver de ikke den realisme, der er iboende i tredimensionelle skydespil. Platformspillere er kendetegnet ved brugen af en række teknologier: mange måder at bevæge sig på (flytte platforme, trapper, reb, rekvisitter og andre), elementer fra puslespil , ved hjælp af et tredjepersons kamera, der følger karakteren, og gengiver flere lag af geometri i kombination med et objektkollisionssystem og andre [7] .
Kampspil er fokuseret på rig animation, nøjagtighed af strejker, evnen til at indstille komplekse kombinationer ved hjælp af knapper og/eller et joystick og lignende. Animationsfigurer stiller krav til motorer om høje detaljer, derudover giver motorer mulighed for at ændre og tilføje specielle effekter (ar efter slag, sved osv.), og giver også mulighed for at simulere frisurer, tøj og andre elementer [8] .
Køresimulatorer kan være forskellige, og der er en række undergenrer. Grafikken i sådanne spil er fokuseret på "korridoren" og kredsløbsbanerne, og derfor er motorerne mere opmærksomme på detaljerne i bilerne, banen og det umiddelbare miljø. Som følge heraf bruges teknologier til at gengive fjerne baggrundsobjekter (vist todimensionelt), sporet er ofte opdelt i flere sektorer, inden for hvilke der udføres gengivelsesoptimering. Ved kørsel gennem tunneller eller andre "trange" steder bruges teknikker til at sikre, at tredjepersonskameraet ikke krydser baggrundsgeometrien. De anvendte datastrukturer og kunstig intelligens er orienteret mod at løse problemerne med NPC-maskiner, såsom stifinding og andre tekniske problemer [9] .
Real-time strategispil har ikke høje grafikkrav og derfor fokuserer motoren på at vise enheder i lav opløsning, men samtidig skal den kunne arbejde med et stort antal enheder på samme tid. Separate funktioner er tilgængelige for interaktionsgrænsefladen for afspilleren og kontroller, som omfatter værktøjer til at arbejde med grupper af enheder (valg efter område, kontrol) og en række menuer og værktøjslinjer, der indeholder kontrolkommandoer, udstyrselementer, valg af typer af enheder og bygninger osv. [10] .
Massivt multiplayer-spil kræver en stor spilverden og muligheden for samtidig tilstedeværelse og interaktion af et stort antal spillere. De lokale opgaver, der løses af motoren, ligner dem i spil af andre genrer, men et træk ved genren er orienteringen og udviklingen af serversoftware, som skal redde verdens tilstand, administrere tilslutning og afbrydelse af spillere, sørge for chats i spillet, måder at interagere med stemmen på osv. [11] .
På hjemmecomputere fra 1980'erne, på grund af manglen på standardisering og hukommelsesbegrænsninger, var porteringen manuel og tidskrævende: kun arbejdslogikken blev overført, og resten af delene - visning af grafik på skærmen, opkaldsafbrydelser osv. - blev skrevet på ny. Men i de dage dukkede Z-Machine og SCI -spilmotorerne fra henholdsvis Infocom og Sierra op. I 1980'erne begyndte Incentive Software at udvikle Freescape , en bærbar 3D-kerne.
Selve udtrykket "spilmotor" dukkede op i midten af 1990'erne - på det tidspunkt blev dominansen af IBM-kompatible computere endelig etableret , og hurtige processorer og "udspekuleret" programmering gav 30 eller flere billeder i sekundet i tredimensionelle spil. id Softwares Doom og Quake - spil viste sig at være så populære, at andre udviklere, i stedet for at starte fra bunden, licenserede store dele af softwaren og skabte deres egen grafik, karakterer, våben og niveauer - "spilindhold" eller "spilressourcer." Quake-motoren blev brugt i mere end ti projekter og gav et seriøst skub til udviklingen af middleware-industrien.
Nyere spil som 1998 's Unreal ( Unreal Engine ) og 1999's Quake III Arena (drevet af id Tech 3 ) blev designet ved hjælp af denne tilgang, med motorer og indhold udviklet separat. Praksis med at licensere sådan teknologi har vist sig at være en nyttig hjælpeindtægt for nogle spiludviklere. Så prisen på en licens til en avanceret kommerciel spilmotor kan variere fra $10.000 til $ 3,75 millioner (i tilfælde af Warcraft III ) , og antallet af licenstagere kan nå flere dusin virksomheder (som for Unreal Engine). I det mindste gør genbrugelige motorer spiludvikling hurtigere og nemmere, hvilket er et værdifuldt aktiv i den konkurrenceprægede pc-spilindustri.
Yderligere udvikling af spilmotorer har ført til en stærk adskillelse mellem gengivelse, scripting, kunstdesign og niveaudesign. Det er nu ret almindeligt, at et typisk spiludviklingsteam har lige så mange kunstnere som programmører.
First-person shooters er fortsat de overvejende brugere af tredjeparts spilmotorer, men sådanne motorer bliver nu også brugt i andre genrer. For eksempel er RPG Morrowind og MMORPG Dark Age of Camelot baseret på NetImmerse -motoren , mens Oblivion og Fallout 3 bruger en ny version af denne teknologi - Gamebryo . Den berømte MMORPG Lineage II er bygget på Unreal Engine 2 (på trods af at denne motor oprindeligt var beregnet til brug i skydespil).
Spilmotorer bruges også i spil, der oprindeligt er udviklet til spillekonsoller; f.eks. bruges RenderWare -motoren i franchises som Grand Theft Auto og Burnout .
Moderne spilmotorer er nogle af de mest komplekse programmer at skrive, ofte bestående af snesevis af forskellige komponenter, som hver især kan konfigureres individuelt, så de passer til spillets behov. Kompleksiteten i at udvikle denne slags system er illustreret af en af kommentarerne til emnet på Slashdot.org- webstedet , som beskriver det sæt af typiske færdigheder, som udvikleren har brug for.
Ud over genanvendelige softwarekomponenter giver spilmotorer et sæt visuelle udviklingsværktøjer. Disse værktøjer udgør normalt et integreret udviklingsmiljø til forenklet, hurtig spiludvikling på streaming -måde . Disse spilmotorer omtales nogle gange som "Game Sub-Software " (forkortet PPO; engelsk middleware) , fordi de fra et forretningsmæssigt synspunkt giver en fleksibel og genbrugelig softwareplatform med al den nødvendige funktionalitet til at udvikle en spilapplikation, reduktion af omkostninger, kompleksitet og udviklingstid er alle kritiske faktorer i den stærkt konkurrenceprægede videospilsindustri .
Som andre open source-løsninger er spilmotorer normalt platformsuafhængige og tillader et spil at køre på en række forskellige platforme, herunder spilkonsoller og personlige computere, med nogle (eller ingen) ændringer af kildekoden. Ofte har spilapplikationssoftware en komponentarkitektur , der tillader nogle motorsystemer at blive erstattet eller udvidet med mere specialiserede (og ofte dyrere) applikationssoftwarekomponenter, såsom Havok til fysik, FMOD til lyd eller SpeedTree til gengivelse. Nogle spilmotorer, såsom RenderWare , er designet som et sæt af løst koblede applikationssoftwarekomponenter, der selektivt kan kombineres for at skabe deres egen motor, snarere end den mere traditionelle tilgang med at udvide eller tilpasse en fleksibel integrationsløsning. Ikke desto mindre er udvidelsesmuligheder opnået og er fortsat en høj prioritet i spilmotorer på grund af deres brede anvendelsesmuligheder. På trods af navnets specificitet bruges spilmotorer ofte i andre typer interaktive applikationer, der kræver grafik i realtid, såsom salgsfremmende demoer, arkitektoniske visualiseringer, træningssimulatorer og simuleringsmiljøer.
Nogle spilmotorer leverer kun 3D-gengivelseskapacitet i realtid i stedet for al den funktionalitet, der kræves af spil. Disse motorer stoler på, at spiludvikleren implementerer resten af funktionaliteten eller indsamler den baseret på andre spilsoftwarekomponenter. Disse typer motorer omtales normalt som "grafikmotorer", "gengivelsesmotorer" eller "3D-motorer" i stedet for det mere beskrivende udtryk "spilmotor". Denne terminologi bruges dog inkonsekvent: for eksempel omtales mange 3D-spilmotorer med alle funktioner blot som "3D-motorer". Nogle eksempler på grafikmotorer er RealmForge , Ogre 3D , Power Render , Crystal Space og Genesis3D . Moderne spil- eller grafikmotorer giver typisk en scenegraf , en objektorienteret repræsentation af et spils 3D-verden, der ofte forenkler spildesign og kan bruges til mere effektivt at gengive enorme virtuelle verdener.
Oftest er 3D-motorer eller gengivelsessystemer i spilmotorer bygget på et grafik- API , såsom Direct3D eller OpenGL , som giver en softwareabstraktion af GPU'en eller grafikkortet. Lavniveaubiblioteker såsom DirectX , SDL og OpenAL bruges også i spil, fordi de giver hardwareuafhængig adgang til anden computerhardware såsom inputenheder (mus, tastatur og joystick), netværkskort og lydkort. Før fremkomsten af hardware-accelereret 3D-grafik blev software-renderere brugt. Softwaregengivelse bruges stadig i nogle modelleringsværktøjer til gengivelse af billeder, hvor visuel troskab er vigtigere end ydeevne ( frames per second ), eller når computerhardwaren ikke opfylder kravene, f.eks. understøtter ikke shaders .
| Spilmotorer | |||||||
|---|---|---|---|---|---|---|---|
| Grafisk | Ledig GLScene Horde3D Irrlicht OGRE OpenSceneGraph Proprietære Outra | ||||||
| Fysisk | Ledig Box2D Kugle Jordegern newton O.D.E. Tokamak Proprietære DMM Havok Fysik PhysX | ||||||
| generelle formål |
| ||||||
| Specialiseret |
| ||||||
| Liste over spilmotorer | |||||||