26 2009 - Fairy Tale III: Subtitel moet nog worden goedgekeurd

Vertaald door Nik en Frank

Ik ben net klaar met het ontwikkelen van Fairy Tale 3. Ik zou blij, opgelucht en trots moeten zijn, maar ik ben perplex, verbaasd en geërgerd over het algemeen: de meest uitdagende taak is nog niet voltooid! Een naam voor een feeënquest is één van de moeilijkste dingen om te verzinnen, het is namelijk niet zo gemakkelijk als je denkt. De naam moet een subtiele, grappige, aantrekkelijke naam zijn en een beetje aangeven waar de quest over gaat, maar het moet niet te veel verklappen. Misschien moet ik wel een cursus volgen voor het verbeteren van mijn vaardigheden bij het bedenken van questnamen.

Dit project heeft meer moeilijkheden bezorgt dan normaal en is uitgedraaid tot een uniek productieproces. Laat me dit uitleggen. De eerste bedenker, Mod Greg, heeft het werk overgedragen aan Mod Ingrid. Beide ontwikkelaars hebben geweldig werk verricht aan deze wonderlijke wereld. De eer van het schrijven van de code en het ontwikkelen van Fairy Tale 3 vanuit de ontwerpopgave kwam in mijn handen. Ik heb mijn best gedaan om de visie van Mod Ingrid op het laatste hoofdstuk van de feeënserie te realiseren.

Militaire waanzin

Fairy general

Eén van de nieuwe karakters in de quest spreekt lichtelijk militaire taal. Het militaire karakter bedenken en het schrijven van de dialogen van dit karakter was erg interessant. Met wat ervaring met amateuristisch drama en wat oude pen-en-papier-spelletjes weet ik hoeveel verschil het kan maken door een rol tijdens een verhaal te spelen.

Dialogen voor karakters maken kan erg leuk zijn. Ik probeer mezelf in de avonturier te plaatsen en de soort verbale interactie voor te stellen die zou kunnen plaatsvinden. Gelukkig neem ik mijn werk niet mee naar huis. Je zult me dan ook zelden orders zien geven aan imaginaire fee-soldaten. "Ga in een rij staan, stelletje nietsnutten, er is werk te doen!" Dit zal dus niet gebeuren.

Orkse militaire nauwkeurigheid

NIET de eindbazen

Mod Chihiro vertelde in zijn blog genaamd 'controle van het ontwerp' dat één van de opmerkelijkste dingen van de quest het eindgevecht zou zijn. Hij schreef het volgende: 'het ontwerpen van een baas voor het eindgevecht was uitdagend'. Het eindgevecht is inderdaad uitdagend, niet alleen vanuit het perspectiefvan de speler, maar ook vanuit het codeperspectief.

Tijdens deze bijzondere uitdaging wilden we het een beetje anders doen. De speler mag zelf bedenken op welke manier hij/zij de eindbaas doodt en welke vijand hij/zij als eerst aanvalt. Ja, dat klopt, verschillende lastige en sterke vijanden tegelijk die je allemaal niet aardig vinden op hetzelfde moment. Maak je maar geen zorgen, je wordt door een paar medestrijders geholpen, die je tegenstander aan de tand zullen voelen.

Eerste feedback

De ontwikkeling van het gehele project is afgerond en krijgt wat feedback van mijn collega's. Dit betekent dat de QA- en een aantal van mijn RuneScape Content-collega's zullen aangegeven wat zij van het project vinden en hoe het verbeterd kan worden. De meeste reacties waren positief, maar het is duidelijk dat er verbeteringen mogelijk zijn. Ik heb deze lijst doorgelezen en ben vervolgens gestart met het verwerken van deze suggesties in de code. Deze fase verpest het project niet, maar maakt het alleen maar beter. Ik geniet van deze ontwikkelingsfase, hier worden de puntjes op de i gezet.

Implementatie

Waar ik erg van houd tijdens het ontwikkelen van RuneScape-projecten zijn de verschillende vaardigheden die je nodig hebt. Het vereist een technische denkrichting om deze chaotische creativiteit in een bijzonder beperkt binair computersysteem te zetten én het heeft creativiteit nodig om technische problemen op te lossen. Hier is een dwaas gesprek dat ik zou kunnen hebben met mijzelf:

'Moet ik al deze informatie in zo veel variabelen opslaan of moet ik gewoon aannemen dat de speler dit specifieke ding gaat doen?'
'We kunnen nooit iets aannemen van onze spelers! Ze doen altijd iets vreemds dat we niet verwacht hadden.'
'Ok, ik moet dus al deze variabelen gebruiken? Maar misschien verpest dit het eindresultaat wel!'
'Hmm, misschien heb je gelijk; maar wat als je een mooie ROZE FEE plaatst in dat lege plekje, zou dat er mooi uitzien?
'Jazeker! Dat zal er zeker mooi uitzien... maar hé, dat is geen goed antwoord op mijn vraag...'
'Maar het was een vervelende vraag, sla de informatie gewoon op een andere manier op!'
'Ja, maar op welke manier?'
'Als je nou eens een ROZE FEE daar had staan, zou ze de speler kunnen helpen herinneren wat je in de variabelen moest bewaren.'
'Oh ja!'

En natuurlijk doet elke andere ontwikkelaar precies hetzelfde. Als ze dit niet doen, doen ze wel iets dergelijks.

Godfather

Zodra alle oorspronkelijke feedback is uitgevoerd, zal het project naar de QA gaan om grondig getest te worden. Ik heb zelf al veel tests gedaan, dus ik denk dat de QA niet veel fouten zal vinden. Op dit moment begin ik altijd een beetje zenuwachtig te worden, ook al ontwikkel ik al jaren projecten, het aftellen kan beginnen tot het project online kan.

Vrijgeven betekent spelers, en spelers betekent feedback. Ik maak altijd een evenwichtige benadering bij de feedback van spelers; ik lees alle positieve reacties en negeer alle negatieve - dat werkt goed bij mij! Maar dat is niet helemaal waar: ik ben erg geïnteresseerd in hoe ik het in de toekomst beter kan uitwerken, dus ik kan de negatieve reacties gewoon niet negeren. Ik wil altijd van mijn volgende quest de ''beste quest ooit'' maken!

PS: Er zijn geen ROZE FEEËN benadeeld tijdens het uitwerken van deze blog.