Door onze studio zijn in de eerste week verschillende (hoofdzakelijk later verworpen) engine's gebouwd, namelijk een 2.5D engine (Sander, verworpen), een 3D engine(Vince), een lighting engine(Yorick, verworpen), een GameManagement engine(Kevin) en een inventory engine (Yorick).
Hoewel dit stuk voor stuk interresante zaken zijn, en een kort stukje over de werking op zich niet zou misstaan, zou ik toch graag de strijd tussen de 2.5D engine en de 3D engine uitlichten in plaats van grote lappen technische details op te ratelen.
Het spelconcept is immers om een top-down dungeon crawler te maken, waarbij inspiratie is opgedaan bij de Zelda games. Tijdens het maken van beslissingen over de vormgeving van ons introproject was voor onze gamedevelopers het uiterlijk van de muren van groot belang. (Jullie lezen het goed, het was makkelijker om het over de spelbesturing, gameplayelementen en het speltype eens te worden dan over het uiterlijk van muren.) Het plan was immers eerst om een 2D top-down spel te maken.
De muren kunnen dan op twee manieren getekend worden, namelijk zoals bijvoorbeeld gedaan wordt in Zelda: Minish Cap:
De muren worden in dit geval altijd getekend alsof ze van schuinboven gezien worden, ongeacht van de positie ten opzichte van de camera.
De andere mogelijkheid was zoals het werd gedaan in bijvoorbeeld de pokemon spellen:
De muren zien eruit alsof ze allemaal vanuit de zelfde hoek getekend worden. Het nadeel hiervan is dat je nu een keuze moet maken tussen voorwerpen, vijanden en de speler soms achter de muur te moeten tekenen, waardoor je ze niet goed ziet, of niet rekening te houden met het overschaduwde deel grond achter een muur en de speler daar helemaal niet te laten lopen. Deze manier kost je ruimte in je levels.
Ook kun je zo alleen de muren van de noordkant zien, waardoor je eigenlijk alleen deuren en trappen kunt hebben op deze muren, een beperking die voor een dungeon crawler niet erg praktisch is.
De conclusie was uiteindelijk dat we top down zouden tekenen met een 3D uiterlijk. Voor een geschikt beeld hiervan zou ik graag naar de vorige blogpost willen verwijzen.
Kortom, zowel Sander als Vince gingen aan de slag met hun eigen soort Engine.
Sander bouwde in een paar dagen eventjes een 2.5D engine (doet ie effe in een handomdraai). Deze manier van tekenen kun je alleen in een top-down situatie gebruiken, omdat het niet echt 3D objecten zijn.
Vince pakte het nog drastischer aan en bouwde maar meteen een engine die echte 3D ondersteunde.
Nu zaten we dus met twee engines (de heren hadden immers niet overlegd wie wat ging doen, ze waren gewoon maar begonnen en schreven allebei in 2 dagen een engine waar menig beginnend programmeur jaloers op mag zijn).
 |
| Hier ziet men de 3D engine van Vince. Wie wil horen waarom er twee verschillende manieren gebruikt worden om tijdens het debuggen de framerate te berekenen moet daarvoor aankloppen bij Vince dan wel Sander. Ze willen het vast erg graag en uitvoerig uitleggen, en zullen daarbij vooral niet versmaden te benadrukken waarom hun eigen manier beter is dan die van de ander. |
Uiteindelijk viel de keuze voor de 3D engine van Vince, onder andere omdat hierin de mogelijkheid van first-person niet direct werd uitgesloten, en ook omdat Vince heel hard en vaak heeft geroepen dat een lighting engine in een 3D omgeving veel makkelijker te maken was dan in een 2.5D omgeving (Mijn 2D lighting engine was onvoldoende bevonden en afgeschreven, maar het idee van lighting is nog niet van tafel geveegd). Misschien was de chaotische code van Sander ook een doorslaggevend element.
Sander moest wel heel hard huilen omdat zijn 2.5D engine niet werd aangenomen. Dat was heel zielig. Einde.
-Yorick
