“Pfoe, dat is een dramatische titel” denk je nu misschien. Maar hopelijk kan ik je in dit artikel ervan overtuigen dat dit volledig terecht is! Dit verhaal gaat namelijk over een man genaamd Chris Sawyer, de programmeur die 99% van de eerste RollerCoaster Tycoon game programmeerde in Assembly. Er wordt wel eens gezegd dat programmeurs lui zijn, omdat ze zichzelf alles zo makkelijk mogelijk maken. Chris Sawyer was de uitzondering op die regel.
Dit is niet het enige spel dat ooit in Assembly is geschreven, maar de grootte en complexiteit van het spel maken dit een uniek voorbeeld van game development.
De wilde rit van RollerCoaster Tycoon
RollerCoaster Tycoon kwam uit in 1999 en was een spel waarin je je eigen amusementspark kon bouwen. De speler had de keuze uit vele verschillende attracties (waaronder achtbanen die je zelf kon ontwerpen), winkeltjes met eten en drinken en decoratieve elementen. Er waren verschillende parken beschikbaar om je creativiteit op vrij te laten, waarvan ook het terrein nog aangepast kon worden. Daarnaast waren er complexe mechanieken zoals tevredenheid van gasten, betalen voor advertenties om meer tickets te verkopen, het ontwikkelen van nieuwe attracties en nog veel meer. De serie was enorm succesvol en leidde tot meerdere games, DLC en bekende memes zoals Mr. Bones Wildride. Een andere grote bron van vermaak was het bouwen van achtbanen die bijvoorbeeld gasten het water in lanceerden, een praktijk waar ik me als kind ook schuldig aan heb gemaakt.
Assembly en de geschiedenis van programmeren
Eerder noemde ik al dat Chris Sawyer geen luie programmeur was: niet alleen zette hij een spel neer met een schaal en innovatieve mechanieken die ongekend waren voor de tijd, maar ook de manier waarop hij dit spel schreef is erg bijzonder. Om dat echt te begrijpen moeten we eerst weten wat Assembly is en waarom het zo veel moeilijker te schrijven is dan moderne talen.
Assembly is een verzamelnaam voor low level programmeertalen, waarbij de instructies (ofwel de code) geschreven worden zodat ze zeer dicht bij de machine code liggen. Voor degenen die niet bekend zijn met machinetaal: over het algemeen geldt dat als iets makkelijk leesbaar is voor een computer, het moeilijk is voor een mens. Dus laten we eens kijken naar het verschil tussen de code waar wij aan gewend zijn, Assembly en machine code. We beginnen met twee simpele regels (pseudo)code:
Deze code bekijkt een variabele die we hebben opgeslagen (variabele x). Als deze gelijk is aan 3, tellen we 1 op bij x. We tellen altijd 1 op bij y. Laten we nu eens kijken naar de Assembly- en machinecode.
Aan de bronvermelding kun je eigenlijk al zien dat ik zelf niet bepaald stond te springen om Assembly te gaan schrijven. De eerste drie regels van de code maken gebruik van variabele A, die ons helpt om de vergelijking tussen x en het getal 3 te maken. Dat lijkt misschien ingewikkeld, maar vanaf dit punt wordt het programmeren alleen maar moeilijker. Om een game te maken hebben we meer onderdelen nodig, zoals loops. Ook die werken wat anders in Assembly, omdat we aan moeten geven waar we in het geheugen verder gaan met code lezen en uitvoeren. Als je nu terugdenkt aan alle functionaliteiten van het spel, wordt het hopelijk duidelijk wat een gigantische taak het moet zijn geweest om te programmeren.
Tegenwoordig zijn we gelukkig verwend met high level programmeertalen zoals Python, die veel lijken op natuurlijke taal. Omdat code makkelijker te lezen is, wordt het ook steeds toegankelijker om te leren programmeren. Maar zoals ik eerder al noemde, werd maar 99% van de code voor RollerCoaster Tycoon geschreven in x86 Assembly.
De overige procent werd geschreven in C. Programmeurs praten graag over C: deze programmeertaal was namelijk betrokken bij het ontwikkelen van vrijwel alle operating systems die we gebruiken. Of je nou een Windows PC of een iPhone gebruikt, zonder C was het niet mogelijk geweest. C is een programmeertaal voor algemeen gebruik die zeer efficiënt omgezet kan worden naar instructies voor de machine. De prijs die je betaalt voor deze efficiëntie is het leren werken met het geheugen van de computer.
Development in 1999
Hoewel Assembly en C dus een hele mooie basis vormen voor al onze technologie, is het niet makkelijk om in te programmeren. Je begrijpt misschien al dat alle programmeertalen die we nu hebben destijds niet beschikbaar waren, maar waarom schrijven in Assembly als je ook kunt schrijven in C? Dat zou het proces in ieder geval een stukje makkelijker moeten maken.
De oplossing ligt hem in de technologische revolutie die we hebben meegemaakt in relatief korte tijd: sinds het begin van game development hebben we veel betere processoren, meer programmeertalen en libraries, betere accu’s en zo veel meer geheugen dan we ons ooit voor hadden kunnen stellen in 1999. Hoewel de deluxe versie van de game tegenwoordig om 2 GB aan vrije ruimte vraagt, is dat meer dan het geheugen dat een Windows XP computer in 2001 totaal aan ruimte vroeg (1,5 GB).
Exacte getallen voor de grootte van het spel destijds zijn moeilijk te vinden, wel vond ik een bron die aangaf dat je ongeveer 180 MB aan vrije ruimte nodig had en een minuscule 16 MB aan RAM. Hoe dichter de taal bij de machine-instructies lag, hoe minder ruimte de applicatie innam.
Daarnaast waren de processoren zoveel trager dat dit de enige manier was om RollerCoaster Tycoon werkend te krijgen, wist Chris uit zijn ervaring met het ontwikkelen van Transport Tycoon (1993). Zo had Windows XP een minimum RAM van slechts 64 MB, terwijl tegenwoordig 8 GB in een telefoon niet uitzonderlijk meer is.
Mocht je nog niet overtuigd zijn van de bijzondere prestaties van Chris Sawyer, daag ik je graag uit om zelf eens aan de slag te gaan met Assembly. Hoewel het schrijven ervan uitdagend is, kan het je ook veel leren over hoe onze computers van binnen werken. RollerCoaster Tycoon is een leuk en innovatief spel waar je je uren mee kan vermaken, maar die eigenschappen zijn dus niet het enige wat de game zo uniek maakt. Pas met de kennis van de zeer beperkte middelen die deze enkele developer tot zijn beschikking had, en wat kennis van IT, is het mogelijk om te waarderen hoe iconisch dit spel was en nog altijd is.
