Een goede 80.000 dollar op jaarbasis. Dat is het gemiddelde loon van een gameprogrammeur die drie tot zes jaar in het vak zit. Ter vergelijking, een artiest verdient net geen 60.000 dollar. Een technisch opgeleide programmeur is duur, de vraag is groot en het aantal mensen met een goede opleiding is schaars. En dus is het gemakkelijk als gameontwikkelaars niet continu het wiel opnieuw hoeven uit te vinden, want veel van de techniek waar games op draaien, valt te recyclen. Zie daar het nut van een game-engine: een stuk software dat een groot deel van de technische last overneemt, zodat gameontwikkelaars zich daadwerkelijk kunnen richten op het ontwikkelen van een game.

De eerste engines

De professionalisering van de gamesindustrie en de opkomst van game-engines gaan haast hand in hand. In de jaren tachtig van de vorige eeuw begonnen uitgevers voor eigen projecten met het gebruik van engines. Zo konden ze gedeeltes van eerdere games gebruiken om nieuwe games te maken. Dit maakte het aanzienlijk makkelijker om een snel vervolgdeel te maken of een game die grotendeels dezelfde mechaniek had als een eerdere titel. Toch bleven deze engines vaak voor intern verbruik: een game programmeren was nog redelijk te overzien en dus was het aanschaffen van een licentie op een engine weinig winstgevend.

Pas in de jaren negentig zien engines van derde partijen een heuse opkomst. Met de komst van 3D-games nam de complexiteit van games aanzienlijk toe. Om mee te doen met de concurrentie zat er dus niets anders op dan een zeer goede technicus aan te nemen of een licentie aan te schaffen op reeds bestaande software. Vooral id Software, dat met Doom en Quake grote stappen had gemaakt op het gebied van 3D-gaming, wist een lucratieve markt aan te boren met de verkoop van de eerste id Tech-engines. Later zou met name de Unreal Engine van Epic deze rol overnemen.

 

Renderen

Engines doen vele dingen, maar misschien wel het belangrijkste onderdeel is het aansturen van de grafische kracht van een game. Waar leveldesign, art design en tot op zekere hoogte ook gameplay vrij uniek zijn in elke game, daar werkt de technische kant vaak grotendeels hetzelfde. Renderen, het op een tweedimensionaal scherm plaatsen van driedimensionale modellen, is dan ook een van de belangrijkste functies van een game-engine. Om te snappen wat engines doen, is het dus belangrijk om ook te snappen wat renderen precies inhoudt en welke technische mogelijkheden en beperkingen hier van toepassing zijn.

We kunnen het renderproces grofweg in twee delen opsplitsen: de vertex shader en de pixel shader. De vertex shader bepaalt de geometrie die we te zien krijgen terwijl de pixel shader op basis van deze geometrie een kleur aan elke pixel op het beeldscherm toekent. Het renderen van een enkele frame kan soms meerdere vertex en/of pixel shaders nodig hebben.

Shaders

Een vertex is een coördinaat in een driedimensionale ruimte. In de gangbare 3D-modellering worden drie van deze vertices samengevoegd tot een polygoon: een driehoek in een 3D-ruimte. Vrijwel alles waaruit een 3D-game visueel is opgebouwd, kan dus worden teruggebracht tot een groep polygonen. Het scherm van een computer is echter tweedimensionaal en dat betekent dat een game moet berekenen welke driehoekjes nu eigenlijk op het scherm getekend moeten worden. De vertex shader doet deze berekeningen in fracties van seconden, vaak voor enkele tienduizenden polygonen.

Zodra alle op het scherm te renderen polygonen zijn bepaald, moet elke pixel op het scherm nog van een kleur worden voorzien. Polygonen worden daarom voorzien van textures, plaatjes die over de polygonen worden gelegd om hier kleur aan te geven. Textures zijn echter nog maar een kleine fractie van het werk, want in werkelijkheid bepaalt lichtinval de kleur van een object grotendeels. Pixel shaders berekenen daarom de kleur aan de hand van textures, lichtinval en eventuele post-processing effecten Om het effect van een shader te zien, hoef je alleen maar naar de phong shader te kijken, waarin de kleur van een blauwe bal op basis van een enkele lichtbron wordt berekend. Licht is echter een ontzettend complex natuurkundig fenomeen (denk aan weerspiegelingen in het water of het vormen van schaduwen op de grond). Volstrekt realistische lichteffecten (ray tracing) is vooralsnog toekomstmuziek voor zelfs de meest moderne game-engines, en dus is hier nog altijd veel winst te behalen.

Botsingen en andere natuurkunde

Maar game engines doen veel meer dan mooie plaatjes op het scherm toveren. Ze functioneren ook in technische berekeningen die de gameplay ten goede komen. Zo is collision detection – het detecteren van twee 3D-ojecten die elkaar overlappen – van groot belang bij het voorkomen dat spelers door muren heen lopen en het raken van tegenstanders. Ook physics-berekeningen kunnen door engines gedaan worden. De natuurkundige krachten zijn immers van belang in vrijwel elke game, zij het in verschillende mate.

Andere dingen die moderne game-engines doen, zijn onder andere het afspelen van geluiden, het animeren van 3D-modellen, netwerkcommunicatie voor multiplayer en kunstmatige intelligentie. Overigens hoeft dit niet allemaal door een enkele engine gedaan te worden. Zo zijn er aparte physics-engines zoals Havoc die de krachtenberekening kunnen uitvoeren en kan Bink Video zorgen voor het afspelen van filmpjes. Ontwikkelaars gebruiken deze zogenoemde middleware vaak als uitbreiding op een engine, omdat de software beter gespecialiseerd is in deze specifieke elementen.

Programmeerhulp

Een ander groot voordeel van engines, dat vooral in de moderne versies een opkomst heeft gemaakt, is het vergemakkelijken van programmeren. Computerprogramma’s zijn geschreven in programmeertalen, maar niet iedere programmeertaal heeft dezelfde functionaliteit. Bij het renderen van een game, iets wat in fracties van seconden moet gebeuren, is het gemakkelijk om vrijwel direct met de hardware van een computer te communiceren. Programmeertalen die dit doen zijn echter een stuk lastiger te begrijpen en daardoor erg onpraktisch voor gameplayonderdelen die minder afhankelijk zijn van snelheid. Veel engines nemen daarom zelf de snellere, ‘lagere’” talen voor hun rekening en bieden de programmeurs de mogelijkheid om daar in een begrijpelijkere, ’hogere‘ taal op voort te bouwen. Daarnaast bieden ze scripttalen aan, zoals het Unreal Script, waarmee losse onderdelen makkelijker aangestuurd kunnen worden door de ontwikkelaar.

Tot slot bieden engines programmeurs hulp door het porten naar andere hardware een stuk gemakkelijker te maken. Omdat engines het gros van de communicatie met de computerhardware voor hun rekening nemen, hoeven programmeurs een veel kleiner gedeelte van een game om te zetten naar een ander platform. En dat scheelt uiteindelijk een hoop geld en tijd.

De volgende weken zullen we een kijkje nemen bij de grotere engines die momenteel op de markt zijn en zien wat zij voor speciale eigenschappen hebben ten opzichte van de concurrentie.