[Image]Al een paar jaar schrijf ik reviews van educatieve computergames, gemaakt door leerlingen, docenten en professionele gamedesigners. De games zijn wisselend van kwaliteit: blijkbaar valt het niet mee om een game te bouwen die leuk is en waarin tegelijkertijd ook iets geleerd wordt. Vaak overheerst één van beide elementen waardoor het saaie games zijn waarbij veelal het accent ligt op feitjes en het beantwoorden van vragen of het zijn leuke games die dan helaas weer weinig met leren te maken hebben. Dat geldt overigens zowel voor games die gemaakt zijn door leerlingen en docenten, als voor games die gemaakt zijn door professionals.

Iets anders wat me telkens weer opvalt is dat als leerlingen educatieve computergames ontwikkelen, dat vaak gebeurt in het kader van het vak informatica. Dat is een voor de hand liggende keuze als het gaat om het ontwikkelen van computergames maar het doet geen recht aan de educatieve mogelijkheden van het ontwikkelen van een spel. Die opdracht is namelijk geschikt voor alle vakken, en zeker niet alleen voor het vak informatica. Sterker nog: voor het ontwikkelen van een educatieve computergame is veel meer nodig dan programmeren en als je alleen daarop focust dan zal dat zelden een interessante game opleveren.

Ik wil daarom de komende dagen een poging doen om op een rijtje te zetten wat de educatieve mogelijkheden zijn van het bouwen van games èn hoe je die mogelijkheden kunt vertalen naar de lespraktijk: hoe kun je leerstof ‘verpakken’ in een educatieve game en hoe zorg je voor een goede balans tussen tijdsbesteding en leerwinst als je leerlingen een educatieve game laat ontwikkelen. Ik bespreek het maken van computergames maar de tips kunnen ook gebruikt worden voor het bedenken van een papieren spel. De basisprincipes zijn namelijk hetzelfde.

Vandaag bespreek ik welke mogelijkheden het ontwikkelen van een educatieve game als leeractiviteit biedt voor verschillende vakken en vaardigheden en op welk moment in het ontwikkelproces deze vakken en vaardigheden aan de orde komen.

Bij het ontwikkelen van een leeractiviteit is het van belang ervoor te zorgen dat de te verwachten leerwinst in verhouding is met de tijd en de energie die docenten en leerlingen in het uitvoeren en beoordelen en evalueren van de leereenheid steken. Daarvoor geef ik morgen (dinsdag) een aantal handvatten.

Woensdag vertel ik hoe je leerstof kunt verwerken tot een educatieve game. Vervolgens ga ik kort in op de vraag hoe je een spel leuk kunt maken: een belangrijke voorwaarde om mensen over te halen om je game te gaan spelen.

Tot slot kom ik vrijdag tot de samenvatting en conclusie en ik zet alle stappen en keuzes in het ontwikkelproces in een schema zodat je in een oogopslag kunt overzien waar je bent in het ontwikkelproces en welke keuzes gemaakt moeten worden. Het totale verhaal zal ik dan ook als artikel online zetten zodat je het in zijn geheel kunt downloaden als je dat wilt.

Het is weer eens een andere manier om te bloggen: ik ben benieuwd hoe dat jullie en mij gaat bevallen!

De educatieve mogelijkheden van het ontwikkelen van een (computer-)spel
Het bouwen van een educatieve game kan onderverdeeld worden in een aantal stappen:
voorbereiding: bepalen wat de leerdoelen zijn van de te ontwerpen game en hoeveel tijd de speler kwijt mag zijn met het spelen van het spel (oftewel: in hoeveel tijd het leerdoel bereikt moet worden), wat vastgelegd moet worden (bijv. alleen de score of ook de keuzes die de spelers maken), via welk kanaal het spel aangeboden moet kunnen worden enz.spel bedenken: een spel bedenken waarmee de leerdoelen bereikt kunnen worden. Hierbij hoort ook het maken van een papieren versie van het spel waarmee getest wordt of het spel net zo leuk en leerzaam is als de bedenkers in gedachten hebben.bouwen: het programmeren van (de bêtaversie van) het spel,testen en opleveren: het testen van het spel en het aanpassen op basis van de ervaringen van de (bêta-)testers. Na oplevering aan de opdrachtgever kan het nodig zijn het spel nog verder aan te passen.
Elke stap heeft educatieve mogelijkheden, maar wel elk voor andere vakken en vaardigheden. Bij het begeleiden van de leerlingen bij het ontwikkelen van een game als leeractiviteit moet bij elke stap de focus liggen op deze te leeropbrengsten. Het product dat de leerlingen opleveren (de te bouwen game) is voor het onderwijs in feite van minder belang: het is ‘slechts’ de stimulans voor de leerling om te leren. In enkele gevallen zal het eindproduct van een dermate kwaliteit zijn dat het na oplevering ook echt gebruikt kan worden, maar dat zal zeker niet altijd het geval zijn. Overigens is dat bij professionele gamedesigners niet anders: maar heel weinig ontwikkelde entertainmentgames worden ook echt in productie genomen!
Maar laten we eens per stap bekijken voor welk vak het ontwikkelen van een game leerwinst kan leveren.

Stap 1: voorbereiding
In stap 1 leert de leerling hoe hij een vraag moet definiëren. Wat wil je precies te weten komen: welke doelen stel je, wat zijn de randvoorwaarden, welke tussenproducten lever je op en wat aan het einde van het proces? Dit is een vaardigheid die van belang is als je informatie zoekt (afbakenen van de zoekvraag), onderzoek doet (o.a. bepaling randvoorwaarden) of andere projecten uitvoert.

Om een spel te kunnen ontwikkelen dat gebruikt kan worden in een les moet een leerling in overleg met de opdrachtgever: de docent van het vak waarvoor het spel ontwikkeld wordt. Die docent moet immers straks het spel gaan gebruiken in zijn lessen dus hij geeft aan welk onderwerp hij in het spel aan bod wil laten komen en aan welke andere voorwaarden het spel moet voldoen. De docent maakt ook een keuze op welk moment van het leerproces hij het te ontwikkelen spel wil gaan inzetten:
wil hij het spel als het klaar is gaan gebruiken als inleiding op een les of lessenserie;wordt het spel straks ingezet ter vervanging van een ander leermiddel (meestal een boek);is het de bedoeling dat het spel straks gebruikt wordt als middel om leerstof te toetsen of te oefenen?
Daarna bepaalt de docent, in overleg met de leerling, de randvoorwaarden. Hoeveel tijd mag de speler straks besteden aan het spelen van het spel? Wordt het een spel voor meer spelers (multiplayer) of een spel dat gespeeld wordt door één persoon? Moet het spel via internet gespeeld worden en moeten de scores van de spelers ergens opgeslagen worden? Ook moeten er afspraken gemaakt worden wanneer het spel in zijn geheel wordt opgeleverd en welke tussenproducten opgeleverd moeten worden.

Docent en leerling (oftewel: opdrachtgever(s) en ontwikkelaar(s)) bepalen samen aan welke voorwaarden het spel moet voldoen. Als de opdracht te breed wordt geformuleerd is de kans groot dat de docent aan het einde van de rit niet tevreden is met het opgeleverde product omdat hij er iets anders van had verwacht. Als tevoren al teveel vastligt dan beperkt dat de creativiteit: de leerling kan dan alleen nog maar zijn eigen inbreng hebben in de marges van het spel, bijvoorbeeld alleen in de vormgeving of bij het kiezen van de muziek.

Stap 2: een spel bedenken
In stap 2 wordt het spel bedacht en er wordt een prototype ontwikkeld en uitgeprobeerd. Deze stap heeft leerwaarde voor het vak waarvoor het spel wordt gemaakt. Om een spel te bedenken moeten leerlingen eerst bedenken hoe de leerstof in het spel verwerkt kan worden. Daarvoor moet je in feite boven de leerstof staan: je moet de materie van verschillende kanten kunnen bekijken zodat je in het spel de verschillende facetten ervan aan de orde kunt laten komen. In deze stap zal de leerling daarom uitgebreid onderzoek moeten doen naar de leerstof, mogelijk in overleg met de opdrachtgever. In deel 2 van dit artikel worden handvatten geboden hoe je van leerstof een game kunt maken.

Wat de leerling leert van het bouwen van een spel is mede afhankelijk van het doel van het te ontwikkelen spel: een spel dat dient om leerstof te toetsen doet vooral een beroep op het vermogen van de leerling om kritisch te reflecteren op de leerstof. Hij moet immers vragen bedenken die aansluiten op wat geleerd is. Gaat het om een spel dat leermiddelvervangend wordt ingezet dan zal de leerling ook moeten bedenken hoe de leerstof wordt opgebouwd en op welke verschillende manieren die uitgelegd kan worden.

Stap 3: het bouwen van de game
Op veel scholen ligt de nadruk van het bouwen van een spel op bij het programmeren ervan. Maar er gebeurt meer: er moeten beelden komen bij het spel en geluiden. De leermogelijkheden van deze stap liggen dus ook bij deze vakken: informatica en de ckv-vakken. Daarbij wil ik benadrukken dat programmeren niet altijd iets is dat moet gebeuren binnen het vak informatica en dat het ook niet altijd tijdrovend hoeft te zijn. Gamebouwsoftware wordt steeds makkelijker en intuïtiever in gebruik waardoor programmeren vooral een beroep doet op het vermogen om logisch te denken. Dat moge blijken uit het feit dat sommige gamebouwpakketten al gebruikt worden door leerlingen op basisscholen waar programmeren geen onderdeel is van het curriculum. Bovendien zijn er, met name voor de ontwikkeling van toetsgames, kant-en-klare formats beschikbaar waaraan je alleen nog maar vragen hoeft toe te voegen.

Stap 4: testen en opleveren
Als het spel gebouwd is, is het nog niet af. Bij het programmeren kunnen fouten gemaakt zijn, de beelden kunnen tegenvallen en de ingebouwde geluidseffecten sorteren misschien niet het gewenste effect. Om dat te achterhalen wordt het spel gespeeld door een aantal mensen uit de doelgroep. De bouwers vragen gericht om feedback: over spelplezier, over fouten in de ontwikkelde software en over de leerdoelen: is door het spelen van het spel ook echt geleerd wat geleerd moest worden? Tot slot wordt een handleiding gemaakt bij het spel.
Door deze stap uit te voeren leren leerlingen kritisch na te denken en te reflecteren op (leer-)processen: hoe zorg je ervoor dat je je producten en jezelf steeds kunt verbeteren? Het schrijven van de handleiding kan ingezet worden voor het vak Nederlands, en kan eventueel dienen als extra verdieping voor de leerstof (als in de handleiding aanvullende informatie wordt gegeven over het onderwerp van de game).


Afbeelding van banlon1964, gepubliceerd onder een CC-licentie (by-nc-nd)