Uitdagingen bij social game design



Gisteren begon in Hamburg Casual Connect, een congres dat helemaal is gericht op casual games: relatief eenvoudige spelletjes die je onder andere speelt op je mobiel, in je browser of via Facebook. Wellicht is dit niet waar hardcore gamers direct reikhalzend naar uitkijken, toch is ook deze tak van de gamesindustrie interessant. Ontzettend veel mensen spelen casual games en er zijn veel relatief onbekende bedrijven die op zeer innovatieve manier hun games aan de man brengen. Reden genoeg voor Vlad en mij om af te reizen naar Hamburg en verslag te doen voor Bashers.

In dit eerste verslag draait alles om het ontwerpen van een goede sociale game. In een boeiende presentatie bracht David Rohrl, creative director van Playdom, gisteren een aantal lessen die belangrijk zijn bij het maken van zo’n spel. Bekende games in dit genre zijn bijvoorbeeld Farmville en Bejeweled Blitz op Facebook. Maar hoe maak je zo’n game succesvol?

Groei: op drie manieren

Een belangrijk aspect bij een sociale game is groei: een game wordt niet succesvol als hij heel klein blijft. Om te slagen zijn volgens Rohrl drie zaken belangrijk: groei, heractiveren van gamers die al een tijdje niet meer hebben gespeeld, en retentie; oftewel het laten terugkeren van mensen naar het spel.

In het ontwerp van een sociale game kun je deze aspecten bewust versterken, bijvoorbeeld door een game te maken die mensen echt leuk vinden, waardoor ze vaak terugkomen. Ook kun je bewust zorgen dat mensen makkelijk vrienden kunnen attenderen op de game, bijvoorbeeld door het uitwisselen van cadeaus op te nemen in het ontwerp. Ook kun je gamers bijvoorbeeld de mogelijkheid geven om anderen om hulp te vragen in het spel, of om belangrijke gebeurtenissen samen te vieren. Hierbij is het heel belangrijk dat de game eenvoudig blijft: alle extra features moeten door een gamer direct met 1 klik uitgevoerd kunnen worden.

Ontwerp samen met je spelers

Traditioneel gezien was er bij games vaak een sterke scheiding tussen ontwikkeling en spelen: eerst ontwikkel je een game, na de release is de ontwikkeling vrijwel af (afgezien van bugfixes) en gaan mensen de game spelen. Bij sociale spellen verloopt dit heel anders: maar liefst 70-80% van de ontwikkeltijd wordt gestoken in een game die al is uitgebracht!

Slimme ontwikkelaars gaan uitgebreid meten hoe mensen hun spel spelen. Zijn er plekken waar gamers vaak komen? Dan worden hier extra features aan toegevoegd, om dat deel van de game nog leuker te maken. Hierbij heeft Rohrl ook een waarschuwing: ga vooral goed meten wat je spelers doen en baseer je niet teveel op wat ze zeggen. Gamers hebben namelijk soms ook hele slechte suggesties en die moet je zelf uitdrukkelijk filteren. Hij geeft aan dat je als ontwikkelaar gamers prima kunt gebruiken om feedback te krijgen hoe je spel beter kan worden voor soortgelijke gamers. Echter, spelers kunnen je helemáál niet vertellen wat leuk is voor andere doelgroepen of nieuwe spelers. Ook kunnen gamers je niet helpen om je game nog meer casual te maken, daarvoor hebben ze zelf al teveel ervaring met het spel. Wel kunnen ze je vertellen waar je spel nu nog niet lekker loopt, of wanneer je game te traag wordt.

Bouwen aan een rijdende trein

Een volgende uitdaging voor ontwikkelaars van sociale games is dat het platform waarvoor ze ontwikkelen continu in beweging is. Zo komt er deze maand een grote update van Facebook, waarbij sommige features waar games nu nog gebruik van maken, zoals notificaties vanuit een game, gaan verdwijnen. Als ontwikkelaar moet je hier altijd rekening mee houden. Het maken van een game is als het bouwen van een trein, terwijl deze al rijdt.

Als ontwikkelaar weet je meestal vooraf niet hoe het sociale platform waarop je game draait verder gaat ontwikkelen en je hebt hier ook geen invloed op. Dit kan voor grote uitdagingen zorgen, maar geeft ook kansen. Ben je namelijk de eerste ontwikkelaar die gebruik maakt van een nieuwe mogelijkheid van het platform, dan kun je binnen enkele weken veel nieuwe gamers trekken.

Er is geen finish, wel een tredmolen

Vanwege het voortdurend updaten van je game en het steeds veranderende platform, is een ontwikkelaar van een sociale game eigenlijk nooit klaar. Er is niet langer een eindpunt, een finishlijn bij de ontwikkeling van een spel. Het maken van een game is meer als het rennen van een hamster in een tredmolen: er is geen einde en je blijft continu bezig. Het spel wordt steeds weer veranderd en leuker gemaakt, waardoor je als ontwikkelaar aan het werk moet blijven.

Later op de dag wordt dit onderstreept door het ontwikkelteam van Bejeweled Blitz. Zij vertellen dat ze werken met een ontwikkeldocument van dertig pagina’s, waarin alle nieuwe updates en releases voor de game voor 2010 zijn uitgewerkt, zo’n uitgebreid plan is er nooit geweest toen de game voor het eerst op de markt kwam!

Uit de presentatie van Rohrl wordt duidelijk dat het ontwikkelen van een goede sociale game niet iets is dat je zomaar even doet. Het ontwikkeltraject wijkt af van wat developers gewend zijn en je moet goed met bepaalde eigenaardigheden, zoals de eindeloze tredmolen, rekening houden.

Ik vond het fascinerend om te horen hoeveel aandacht ontwikkelaars van sociale games besteden aan het aantrekkelijk maken van hun spel. Een game als Farmville blijkt niet toevallig succesvol te zijn, maar wordt dagelijks door de ontwikkelaar nauwlettend gevolgd en gemeten. Op basis van cijfers en statistiek wordt vastgesteld wat succesvol is en hoe de game verder kan worden ontwikkeld. Sociale games mogen er dan misschien uitzien als een eenvoudig spelletje, achter de schermen schuilt een professionele industrie met slimme ontwikkelaars die precies weten wat ze doen. Ik vind het geweldig om op Casual Connect een kijkje in die keuken te mogen nemen.

Volg de reacties op deze post via RSS

Plaats een reactie

Registreer je als vaste gebruiker. Heb je dit al eens gedaan, log dan in.

Hou de discussie menselijk en inhoudelijk. Reageer bij voorkeur onder je echte naam, met je foto als avatar (via Gravatar).

Toegestane HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>