Spelontwikkeling en webontwikkeling hebben meer dan een paar dingen gemeen. Concreet: als je geluk hebt, ontwikkel je een product dat door duizenden, zo niet miljoenen mensen regelmatig zal worden gezien en gebruikt. Je hebt een goed team, goede kwaliteitsborging en heel veel ondersteunend personeel nodig om vragen te beantwoorden. Je hebt goddelijke servers nodig. Je zult veel klachten horen die variëren van opbouwende kritiek tot regelrechte gejammer.
Gamers zijn een nogal veeleisend publiek. Veel bedrijven verbergen hun ontwikkelings- en projectbeheerprocessen vaak achter een sluier van geheimzinnigheid (en soms regelrechte schaamte) en houden zich voornamelijk aan persberichten. Game-ontwikkelaars zijn meestal een beetje transparanter. Dit is niet omdat ze moreel superieur zijn. Het is omdat hun klanten bereid en in staat zijn om de hel op te heffen als ze denken dat dingen de verkeerde kant opgaan.
Je zult veel klachten horen die variëren van opbouwende kritiek tot regelrechte gejammer
Als gevolg hiervan kunnen we veel leren door te kijken naar de manieren waarop verschillende ontwikkelaars omgaan met hun projecten en hun relatie met hun community's. Ze vertellen ons niet alles, maar ze gaan vaak in detail in op hun proces, hun bedoelingen en hun visie. Ook bleken ze vrij gedetailleerde patch-aantekeningen te maken, wat cool is.
De twee games waarvan de voortdurende ontwikkeling die ik heb gevolgd het dichtst zijn Overwatch , en Dungeons and Dragons online . Ik zal ze gebruiken voor mijn voorbeelden.
De ontwikkelaars van Overwatch heb zeer duidelijke doelen voor ogen voor alles wat ze doen. Ze verklaren publiekelijk wat ze willen bereiken, en ze gaan ervoor. Hun acties tonen consequent vastberadenheid om aan al hun gestelde doelen te voldoen. Ze trekken het niet altijd uit, maar ze doen er zeker alles aan om het te proberen.
U kunt dezelfde strategie volgen: vertel uw gebruikers precies wat u nastreeft wanneer u een wijziging aanbrengt of een nieuwe functie. Geef ze geen vage missieverklaringen zoals: "We willen efficiënter en minder niet-efficiënt zijn." Vertel hen precies hoe u van plan bent om uw service efficiënter te maken. Geef details. Geloof me, het maakt het verschil tussen de gebruikers die jou geloven en zeggen: "Ja. Zeker. Ik zal het geloven als ik het zie. "
DDO heeft een bug met zijn ladders. Soms kun je ze niet voorbij een bepaald punt beklimmen, en soms kun je ze zelfs een paar seconden niet vasthouden. Dit is gedeeltelijk te wijten aan vertraging, die van invloed is op alle online games. Maar soms, zelfs als elk ander systeem prima werkt, zonder vertraging, doen de ladders dat gewoon niet. De ontwikkelaars hebben beweerd dat ze deze bug zo vaak hebben opgelost als ze het bestaan ervan hebben ontkend. Zelfs nu staat het niet op de lijst met bekende problemen.
De gebruikers weten echter dat het echt is. De bug heeft hun personages vaak genoeg gedood. Als de meeste van uw community u vertellen dat iets onregelmatig is op uw site, hebben ze waarschijnlijk gelijk. Zelfs als u problemen ondervindt bij het reproduceren van het probleem, moet u blijven kijken. Het vertrouwen van uw gebruikers in u hangt ervan af.
Een deel van de reden waarom ze geen fouten in DDO kunnen vinden of oplossen, is omdat het spel meer dan een decennium oud is en veel (zo niet alle) oorspronkelijke ontwikkelaars al lang verdwenen zijn. Er zijn zoveel systemen en functies die in de eerste plaats maar half af zijn, het is een wonder dat ze bugs kunnen vinden om ze te repareren.
Het gaat niet alleen om het becommentariëren van je code, het gaat ook om het documenteren van je beslissingen
Als u hetzelfde probleem wilt vermijden, begint u met documenteren. Het gaat niet alleen om het becommentariëren van je code (hoewel dat helpt), het gaat om het documenteren van je beslissingen. Elke beslissing die u neemt over uw project, elke nieuwe functie waaraan u begint te werken, het zou allemaal ergens in een gemakkelijk te vinden bestand moeten zijn. Je redenen om de wijziging aan te brengen, terug te zetten, aan te passen of de functie niet af te maken, dit moet er allemaal zijn. Je moet ook opschrijven waar je alle relevante code kunt vinden voor elke nieuwe functie of verandering.
Een gebrek aan dit soort documentatie leidt tot onvoorziene en soms bijna niet-uitvloeiende bugs.
Het ontwikkelings- en managementteam van Overwatch speelt het spel. Dit is een bekend feit. En ze zijn niet allemaal pro's. Ze hebben medewerkers die op elk niveau spelen, wat betekent dat ze het spel ervaren zoals het lijkt voor spelers op een laag niveau en op een hoog niveau. Dit betekent dat ze zich gemakkelijker kunnen inleven in hun gebruikersbestand.
Een van de stafleden van DDO (die niet door de gebruiker wordt genoemd) wordt routinematig bespot in de community omdat hij de situatie niet bij kan houden zonder de god-modus in te schakelen terwijl hij het spel streamt. Ook gebruikt hij drankjes om zichzelf te genezen, en drankjes zijn ... niet geweldig in DDO. Niemand verwacht dat hij de beste is, maar ze verwachten wel dat hij de werking van de game beter kent dan dat. En ze verwachten dat hij de god-modus niet zal gebruiken.
Dit principe wordt ook wel "het eten van je eigen hondenvoer" genoemd. Je moet zelfverzekerd genoeg zijn in je eigen product dat je het dagelijks gebruikt. Dit principe is meer van toepassing op apps dan op blogs, maar het is belangrijk om dit te onthouden. Als uw gebruikers zien dat u uw eigen product niet zou gebruiken, vragen zij zich af waarom ze dit zouden moeten doen.
Dit is een probleem dat DDO heeft getroffen, vrijwel elke andere MMO die er is, en kan Overwatch zelfs ooit raken. Kortom, soms zullen gameontwikkelaars min of meer het ding vernietigen dat hun oorspronkelijke publiek aantrok. Soms proberen ze nieuwe spelers aan te trekken door de mechanica te veranderen, maar alleen om de kern van het spel te ruïneren. Soms gaan ze gewoon alles maken waar de oorspronkelijke gamers zo hard voor hebben gewerkt. Soms hebben hun nieuwe inspanningen om geld te verdienen de balans van het spel verstoord.
Soms proberen ze hun spel te baseren op D & D 4th Edition, waar iedereen een hekel aan heeft.
Vaak zorgen deze veranderingen voor een korte tijd voor nieuwe spelers. Maar meestal blijven ze niet zo lang, en uiteindelijk heeft de game minder hardcore fans dan toen het begon. En soms kunnen grote veranderingen een spel volledig revitaliseren.
Je zult nooit iedereen gelukkig maken, maar er valt veel te zeggen om de oldtimers rond te houden
Voordat je massale, ingrijpende veranderingen aanbrengt, praat je met je hardcore gebruikers. Praat met de mensen die afhankelijk zijn van uw app voor hun dagelijkse activiteiten. Als je een kleine functie hebt die niet veel mensen gebruiken, vraag je die mensen die het gebruiken hoe belangrijk het voor hen is. Ze kunnen ervan afhangen.
Je zult nooit iedereen gelukkig maken, maar er valt veel te zeggen om de oldtimers rond te houden. Vanuit een moreel standpunt ben je ze wat aandacht verschuldigd. Ze hebben uw product gemaakt tot wat het nu is. Vanuit praktisch oogpunt kunnen fans en gebruikers soms een beter idee hebben waarom mensen van je product houden dan jij. Ze hebben misschien ongelijk, maar je zult nooit weten of je in de eerste plaats niet naar hen luistert.