Hoe geef ik mijn game een goed wachtwoordsysteem
Stel je voor: het is 2002, en je bent gameontwikkelaar. Je bent een spel over Alan Turing aan het ontwerpen voor de Game Boy Advance, maar je publisher vindt het te duur om cartridges met EEPROM, Flash memory of SRAM te produceren. Niet ongewoon. En er is een veelgebruikte oplossing: een wachtwoordensysteem. Je geeft de speler regelmatig een wachtwoord dat hij of zij bij hervatten in kan vullen om verder te spelen. Op deze manier ligt de verantwoordelijkheid bij hem of haar en hoeven er geen dure onderdelen gebruikt te worden.
Maar wacht even: een wachtwoordensysteem is wel degelijk iets om goed over na te denken. Het kan goed werken, maar het kan ook op vele manieren vervelend zijn! Dit is een handleiding tot het maken van een goed wachtwoordsysteem.
Verzuim niet de verantwoordelijkheid voor een wachtwoordsysteem.
Als je geen opslagmethode op het spel gaat krijgen, máák dan een wachtwoordensysteem. Oké, het is niet zo nodig als je iets als Tetris (1989) maakt, waarbij het alleen om de high scores gaat; die kan een speler immers sowieso noteren. Maar werk je met levels of een langer verhaal, wees dan niet zo als de ontwikkelaars van Astérix & Obélix voor de Game Boy (1995), die voor een spel dat meer dan drie kwartier duurt geen manier tot later verder spelen hebben ingebouwd met uitzondering van een obscure cheatcode die toegang geeft tot een level select (als je het mij vraagt bedoeld voor de ontwikkelaars zelf). Nee, ze hebben er goed aan gedaan om in 1999, bij heruitgave van het spel voor de Game Boy Color, behalve kleur ook een wachtwoordensysteem toe te voegen.
Zorg dat de kans dat de speler per ongeluk een werkend wachtwoord invoert klein is.
Als een speler een half uur lang willekeurige wachtwoorden invult en uiteindelijk een werkende tegenkomt is dat geen probleem; als je maar lol hebt, toch? Maar als de speler een fout maakt bij het intikken zou er niet een ander werkend wachtwoord moeten ontstaan. Als je met statische wachtwoorden werkt, bijvoorbeeld één wachtwoord per level, is dat niet zo moeilijk: kies de wachtwoorden zo dat ze allemaal in meerdere karakters verschillen van alle andere wachtwoorden.
Als het wachtwoord meer opslaat dan alleen welk level je hebt behaald, zoals data over collectables, heb je een ingewikkelder systeem nodig. Het is niet de bedoeling dat je door een karakter verkeerd in te tikken opeens 36 levens hebt in plaats van 4. Een oplossing is om een checksum toe te voegen, ergens in het wachtwoord. Metroid (1986), een van de meest populaire spellen die wachtwoorden gebruiken, heeft als laatste 8 bits van het wachtwoord de som van de 136 andere bits. Als de speler een karakter verkeerd intikt zal de som niet meer kloppen, en wordt het wachtwoord niet geaccepteerd.
Gebruik geen klinkers als symbolen om onfortuinlijke wachtwoorden te voorkomen.
De meest gebruikte bron van symbolen om wachtwoorden uit te maken is het Latijnse alfabet. Echter kan het gebruik hiervan in zijn volledigheid onvoorziene situaties opleveren. Twee uitzonderlijk sappige voorbeelden: in het eerder genoemde Metroid is ENGAGE RIDLEY MOTHER FUCKER een werkend wachtwoord (Ridley is een baas uit Metroid). Of nou ja, werkend… de checksum klopt toevallig, maar afhankelijk van het platform waarop je het spel speelt heeft het verschillende negatieve effecten. Het schijnt zelfs dat een oude versie van de 3DS-firmware volledig gebrickt kon worden door gebruik van het wachtwoord.
In de NES-versie van Metal Gear (1988) brengt het invullen van FUCKM E1111 11111 11111 11111 je naar de eindbaas, maar zonder uitrusting. In de Europese versie van Metal Gear, die later uitkwam, zijn de klinkers vervangen door andere karakters (zoals # en ★), en zoiets zou ik ook aanraden, als je toch zoveel karakters nodig hebt. Want dit soort gekke wachtwoorden zijn natuurlijk grappig, maar je loopt ook het risico dat een wachtwoord dat wel door normale gameplay te verkrijgen is een jeugdige speler op wrede wijze verwenst.
Gebruik geen symbolen die op elkaar lijken.
Je kent het beruchte paar vast: de kleine letter l en de hoofdletter I. In veel lettertypes en handschriften nauwelijks van elkaar te onderscheiden. Een ander probleemgeval is het trio 0, O en D. Mocht je toch meerdere van deze symbolen willen gebruiken, zorg er dan op z'n minst voor dat ze in het spel goed van elkaar te onderscheiden zijn. Als we weer kijken naar Metroid, valt het op dat de hoofdletter I inclusief horizontale streepjes wordt weergegeven, en dat voor de kleine letter l de cursieve versie wordt gebruikt.
Dit lost het probleem echter niet op, want het zit er dik in dat de speler bij het opschrijven van het wachtwoord zijn eigen handschrift aanhoudt, waarbij de letters wel weer op elkaar lijken. Zoals je wellicht bij het spelen van Rayman op de GBC (2000) ontdekt is het bij sommige letters lastig te zien of je nou een hoofdletter of een kleine letter bedoelde (C vs c, X vs x, S vs s…). Dus als er alternatieve symbolen te verzinnen zijn, je met minder bits uit kunt, of het wachtwoord nog wel wat langer kan: laat ze dan alsjeblieft weg. Een spel dat hier zeer voorzichtig mee is is Atlantis: The Lost Empire voor de GBA (2001). Dit spel gebruikt een strikte deelverzameling van de vereniging van het hoofdletteralfabet en de cijfers, en laat bijvoorbeeld de 0, 1, 2, 5 en 8 weg.
Geef de speler niet slechts tijdelijk toegang tot het wachtwoord.
Een van de grootste nadelen van een wachtwoordsysteem is dat het noteren van een wachtwoord de speler uit het spel haalt. Al is de kans groot dat een speler een nieuw verkregen wachtwoord zo snel mogelijk wil opschrijven voor het geval dat er iets misgaat, is het een erg goed idee om op elk moment toegang tot het wachtwoord te geven. In Finding Nemo: The Continuing Adventures (2004) bijvoorbeeld is het wachtwoord altijd te zien op de world map. Dit betekent dat je het wachtwoord pas hoeft te noteren als je stopt met spelen, en niet na elk gehaald level. Het eerder genoemde Rayman is zo aardig om je het huidige wachtwoord nogmaals te geven op het moment van een game over.
In Snow White and the Seven Dwarfs (2001) daarentegen, krijg je een wachtwoord maar één keer te zien; als je het per ongeluk wegklikt moet je maar doorspelen tot je er nog een krijgt, want als je teruggaat naar het menu is het wachtwoordscherm daar oningevuld. Laat op z'n minst het wachtwoord daar ingevuld blijven, maar laat liever het wachtwoord ook weergegeven worden op bijvoorbeeld het pauzescherm, zodat de spelers er ook achter komen dat ze niet bang hoeven te zijn om het wachtwoord te verliezen.
Deze tip is echter op twee manieren te interpreteren. Wat je uiteraard absoluut nooit moet doen is een wachtwoord weergeven en dat dan na x seconden automatisch laten verdwijnen. Dit gebeurt in E.T. The Extra-Terrestrial (2001). Is het de uitdaging dat spelers zo snel mogelijk hun notitieblokje pakken en het wachtwoord overschrijven?!?
Onthoud het wachtwoord bij een game over
In aanvulling op de tip hierboven, een simpele manier om de spel-ervaring net wat beter te maken: als je een spel maakt met game overs, zorg dan dat een speler die besluit toch nog even verder te spelen niet een hoop moeite moet doen om de draad weer op te pakken. De spellen van Infogrames (bijvoorbeeld les Schtroumpfs, 1993) doen dit goed: om het spel te spelen druk je gewoon op Start of A. Mocht je een wachtwoord willen invullen, dan is daar een aparte optie voor. Als je al eerder een wachtwoord hebt ingevuld blijft dat opgeslagen, zodat je na een game over alleen op A hoeft te drukken. Lost ook grotendeels het hierboven genoemde probleem op!
Een alternatief is om bij een game over de optie te geven om direct door te spelen, zonder terug naar het titelscherm te gaan. Dit doen bijvoorbeeld Lilo & Stitch (2002) en The SpongeBob Squarepants Movie (2004). Gelukkig houden bijna alle games een van deze twee opties, of een redelijk alternatief, aan. De eerder genoemde E.T. doet wel ook dit verkeerd.
Maak een redelijke manier om de wachtwoorden in te vullen
Op een Game Boy heb je natuurlijk geen toetsenbord. Maar het is wel mogelijk om een virtueel toetsenbord te maken, en dat maakt het invullen van wachtwoorden een stuk sneller. Bij het eerder genoemde Atlantis is het invullen van wachtwoorden vervelend veel werk, doordat er vrij veel mogelijke symbolen zijn en je om het juiste symbool te kiezen alleen naar boven en naar beneden kan gebruiken. Om het erger te maken werkt het niet eens om de richting ingedrukt te houden. Dus wees maar tactisch met welke kant op je het alfabet langs gaat, als je niet 20 keer op naar beneden wilt hoeven drukken.
Als je wel een virtueel toetsenbord maakt, is het wel zo handig als je de symbolen in een raster plaatst. Volg bijvoorbeeld het voorbeeld van Monsters, inc. (2001). Niet dat van Donald Duck "AdV@ncE"!*# (2001), waarbij je in de afbeelding daaronder bijvoorbeeld zou verwachten dat een druk naar beneden terwijl je op de letter 'M' staat je naar de 'Z' brengt. Maar nee, die is verbonden met de 0.
Monsters, inc.: onder de M zit de Z
Donald Duck "AdV@ncE"!*#: onder de M zit de 0
Grappig genoeg is dit een gebied waarop E.T. iets origineels doet dat best goed werkt: als symbolen worden de knopjes op de Game Boy Advance gebruikt. Aan het begin is dit wat verwarrend, maar het maakt het invullen wel efficiënt!
Gebruik geen afbeeldingen als symbolen
Als je verwacht dat jonge kinderen je spel over Alan Turing gaan spelen, zou het kunnen dat je er rekening mee wilt houden dat ze wellicht nog niet kunnen lezen. Veel games gericht op jonge kinderen gebruiken afbeeldingen in plaats van letters in de wachtwoorden. Persoonlijk begrijp ik dit geenszins! Is het de bedoeling dat het kind het wachtwoord uit zijn of haar hoofd leert? Anders moet het namelijk alsnog op de een of andere manier genoteerd worden. En kinderen staan er niet om bekend portretten herkenbaar na te kunnen tekenen. Bij mijn zusje zag een wachtwoord als hieronder er dus uit als kat kat schoentjes man (Barbie in the 12 Dancing Princesses, 2006), waar ze dus alleen maar meer voor hoefde te schrijven. Het enige voordeel van een dergelijk systeem dat ik bedenken kan is dat als de speler een of een paar letters onduidelijk heeft opgeschreven, het wachtwoord wellicht alsnog herkenbaar is, wat niet het geval is bij gebruik van losse letters.
Toch ben ik geen voorstander van zo'n systeem; het is vaak verwarrend. Ik heb zelf nooit Spongebob gekeken, dus bij het spelen van The SpongeBob Squarepants Movie moest ik omschrijvingen verzinnen voor de karakters, die ik later terug zou kunnen leiden tot de afbeeldingen, omdat ik met uitzondering van Patrick en de spons zelf de namen niet kende. Wat je uiteraard onder geen beding moet doen is meerdere afbeeldingen gebruiken die erg op elkaar lijken. Erg fijn dat de kleurversie van Astérix & Obélix wachtwoorden heeft, maar welk symbool bedoelde ik ook alweer met 'vlees'??
Mocht je toch bang zijn dat je spelers problemen gaan krijgen met de letters uit het alfabet, gebruik dan andere symbolen, die goed na te tekenen en gemakkelijk herkenbaar zijn. Een spel dat dit goed doet is de GBC-versie van Tarzan (1999).
Hopelijk heb je iets geleerd van dit artikel! Maar ik kan me voorstellen dat je nog inspiratie mist wat betreft het belangrijkste van een wachtwoordensysteem: het bepalen van de wachtwoorden. Dat moet natuurlijk op zo'n manier gebeuren dat voor elke situatie het wachtwoord uniek is, zodat het teruggerekend kan worden als de speler het de volgende keer invoert. En je wilt het ook niet zo simpel maken dat het intikken van een verkeerd karakter nog steeds een werkend wachtwoord oplevert.
Een spel dat een vrij simpel maar toch robuust genoeg wachtwoordensysteem heeft is Ice Age (2001). Ik heb dit wachtwoordsysteem ontcijferd en weet precies hoe het werkt. Als je benieuwd bent en Engels kunt verstaan, kun je m'n video erover kijken!