InaniBrutus is een serious game, bedoeld om training voor een speciaal brandweerteam toegankelijker te maken. Het gaat over een blusrobot die de speler naar het doel, een zwart-witgeblokte orb, moet rijden. Als bewijs dat de speler vaardig genoeg is in de besturing mag hij onderweg geen obstakels raken, anders is die af en moet het level opnieuw.
De game is ontwikkeld met de Godot game engine. Godot heeft zijn eigen taal, GDScript, om het gedrag van gameobjecten te programmeren. Het programmeren, samenstellen, testen en finetunen van de mechanics en features in de levels van InaniBrutus besloeg het grootste deel van mijn werk als game developer. Ik heb iteratief gewerkt met GitHub en de Git Flow als vertakkingsconventie. Versies met nieuwe en verbeterde features heb ik steeds weer laten testen, zodat ik de ontwikkeling kon bijsturen.
InaniBrutus is gemaakt voor mobiele telefoons en Virtual Reality-apparaten. Om het project helemaal af te maken, heb ik beide varianten gepubliceerd. De mobile versie op de Google Play Store en die voor VR op Oculus App Lab.
De naam InaniBrutus is een samentrekking van het Latijnse woord inanibus, wat kan worden vertaald als ‘onbemand’, en Brutus, de naam van de blusrobot.
Totstandkoming van het project
Drie maanden voor de start van het laatste semester van mijn studie was ik bij een meet-up voor afstudeerders en stagebedrijven. Kennisregisseur Maurice en vakbekwaamheidsspecialist Peter waren hier namens de Veiligheidsregio Rotterdam-Rijnmond (VR-RR). Hun enthousiasme voor het werk bij de brandweer zette mij zo ‘aan’ dat ik Maurice daags erna heb benaderd om te informeren naar de mogelijkheden voor een afstudeeronderzoek over technologie bij hulpverleningsdiensten.
Maurice stelde voor om me mee te nemen naar de kazerne aan de Moezelweg, de thuisbasis van het Team Digitale Verkenning (TDV). Dit team verkent hoe technologie het beste kan worden ingezet bij incidenten. Teamleider Robbert liet mij ter inspiratie de onbemande voertuigen zien waarover het TDV beschikt. Die dag heb ik drones en blusrobots gezien. Ik was meteen mateloos geboeid door hoe het besturen van zo’n voertuig werkt. Zelf mocht ik ook de blusrobot een stukje laten rijden over het parkeerterrein. De manier van voortbewegen is nogal opmerkelijk: met zijn twee rupsbanden, die onafhankelijk van elkaar bewegen, lijkt het nog het meest op een tank. Het was zo leuk om te zien, daar moest ik iets mee.
Op de terugweg naar huis ontstond het idee voor een serious game waarmee belangrijke eigenschappen van het besturen worden nagebootst. Een game ontwikkelen is misschien niet het eerste waar je aan denkt bij een stage bij de brandweer, maar ik vond het idee dermate leuk dat ik het besloot uit te werken in mijn afstudeervoorstel. De ontvangst was positief, zowel door Maurice van de VR-RR als mijn afstudeercoördinator. Op 7 februari 2022 ging mijn afstudeerproject officieel van start.
Projectverloop
Aan het begin van het project heb ik de doelgroep van de game bepaald, in overleg met Robbert. Hij gaf aan dat de teamleden van Digitale Verkenning het meeste gebaat zijn bij mijn ’trainingsgame over voertuigeigenschappen’-idee. Naar aanleiding hiervan heb ik mijn onderzoeksvraag aangescherpt, die hierna zijn definitieve vorm had: Hoe kan een serious game onbemande voertuigen toegankelijker maken voor de teamleden van Digitale Verkenning Rotterdam-Rijnmond?
Dit vatte in één zin goed wat ik wilde onderzoeken. Het heeft de juiste mate van afbakening, terwijl er nog steeds voldoende variabele factoren zijn, zodat het een interessant afstudeeronderzoek wordt.
Het invullen van het waardepropositie canvas geeft een uitgebreider beeld van de waarde die InaniBrutus toevoegt. De waardepropositie heeft – net als InaniBrutus als softwareproduct – iteraties ondergaan. En je kunt ook nog onderscheid maken tussen de waarde die het biedt aan de doelgroep en de waarde voor de klant.
Om nog een beter beeld te krijgen van hoe het Team Digitale Verkenning traint met onbemande voertuigen, heb ik meerdere trainingen bijgewoond waar de besturing werd geoefend. Deze training vindt eens per week plaats, maar er is geen tijd om elke week met elk voertuig te oefenen. Bovendien kun je er niet elke week bij zijn, dus als men pech heeft, is het enkele weken tot een maand geleden sinds iemand voor het laatst heeft getraind. Een serious game zou dan in de tussentijd waardevolle herhaling voor het spiergeheugen kunnen faciliteren, zodat het manschap in staat is om er meteen weer te staan als die terug is van weggeweest.
Met duidelijk voor ogen wat belangrijk is in mijn game, kon ik ook conclusies trekken over welke tool hiervoor het meest geschikt zou zijn. Ik heb heb in dit onderzoek zeven game engines geprobeerd, met daarbij ook een aantal die ik nog niet kende. Pico-8 en Construct 3 vielen af, omdat ze (op dat moment) geen sterk ontwikkeld 3D-aspect hadden. Pico-8 is bovendien niet gratis te gebruiken. In CryEngine lukte het me niet om een code solution te maken en te openen. Jammer, want ik ontdekte dat ‘Cry’ een soort minimalistische versie van Blender in zijn scene editor heeft, waardoor je heel snel omgevingen kunt samenstellen. Dat had ik best nog wat verder willen uitproberen. Unreal Engine bracht me niet het gebruiksgemak: teveel was al voor mij gedaan in de al werkende blueprints en het lukte me niet om zelf iets van de grond af op te bouwen. Op die manier kan ik het niet leren.
Daarmee bleven over Unity, Godot en PlayCanvas. Zodra je begint met bouwen, is het belangrijk dat de game kan worden gespeeld op de juiste apparaten. Ik had bepaald dat ik voor de eerste testsessie met prototypes drie varianten wilde: mobile, PC en VR. PlayCanvas kon mij hierin niet bieden wat ik wilde. De afweging tussen Unity en Godot ging vooral om hoe ik een systeem voor afstelbare eigenschappen kon bouwen en dit naar mijn hand kon zetten. Godot gaf mij hierin meer regie dan Unity. Op basis van deze bevindingen is mijn besluit tot stand gekomen om Godot te gebruiken. Dit was een spannende beslissing, want ik had hiervoor nog nauwelijks ervaring met Godot. In tegenstelling tot Unity, waar ik al eerder intensief mee had gewerkt, bijvoorbeeld bij de projecten Achromira en Shell Shock tijdens het Game Design & Development minorprogramma.
Gelijktijdig met mijn project waren er nog 6 andere stagiairs en afstudeerders op de afdeling waar ik werkte. Met hen heb ik een creatieve sessie gedaan om tot ideeën te komen voor aanvullingen en versterkingen op het rondrijden van Brutus in InaniBrutus. Want als je dan eenmaal de controle hebt over Brutus, wat doe je dan? Wat is het doel? Wat is het obstakel naar dat doel? Waarom heeft het betekenis deze uitdaging te voltooien? Een antwoord op deze vragen moet in dienst staan van het doel van het spel: de besturing van Brutus trainen en herhalen. Om dat doel helder voor ogen te krijgen, heb ik vragen gemaakt in het Hoe Kunnen We-format.
- Hoe kunnen we het gevoel van besturing van de speler testen?
- Hoe kunnen we besturingsfouten bestraffen en foutloosheid belonen?
- Hoe kunnen we een omgeving/setting creëren waarin de besturing getoetst wordt?
- Hoe kunnen we een omgeving/setting creëren om de virtuele Brutus heen die de doelgroep aanspreekt?
Een aantal ideeën die zijn ontstaan bij deze brainstorm, zijn ook daadwerkelijk in de game gekomen. De uitgewerkte versie van de bruikbare ideeën heb ik in de backlog gezet, waarvoor ik Trello heb gebruikt. De status qua prioriteit, urgentie en werkbelasting van de features wordt daar bijgehouden. Suggesties en feedback uit tests met het TDV en ook de eerder genoemde creatieve sessie hebben bijgedragen aan een goed gevulde lijst met tickets.
Het bouwen van een afstelbaar eigenschappensysteem in InaniBrutus was inmiddels in een vergevorderd stadium. Ik heb onderzoek gedaan met de echte Brutus, zodat ik onder meer de snelheid, rotatietijd en acceleratie in de game precies goed kon krijgen. Van te voren had ik een plan gemaakt om de eigenschappen uit mijn afstelbare systeem te meten. Terwijl ik Brutus de acties liet doen, heb ik een opname gemaakt die ik thuis heb geanalyseerd. Met behulp van markeringen op de straat met stoepkrijt kon ik precies uitpluizen hoe lang het bijvoorbeeld duurde voor Brutus op volle snelheid was vanuit stilstand (acceleratie eigenschap). Of andersom: van volle snelheid naar stilstand (deceleratie). Van de in-game Brutus heb ik ook opnames gemaakt terwijl hij dezelfde acties doet. De ultieme test voor mijn afstellingssysteem: opnames van echte Brutus en digitale Brutus naast elkaar leggen.
Waar rotatietijd geen uitleg behoeft, zijn snelheid en acceleratie in een rechte lijn moeilijker te vergelijken. Brutus zelf is je enige referentie om afstand in te schatten. Let op waar beide voorkanten zijn. De achterkant van beide komt op hetzelfde moment langs dat punt.
Het werkte! Door alleen de getallen aan te passen in Godot kon ik alle acht eigenschappen precies laten matchen met echte Brutus. Deze aanpasbare getallen worden in het script dat Brutus voortbeweegt door ingewikkelde berekeningen gehaald. Met comments heb ik geprobeerd deze te verduidelijken, zodat ik – als ik nog eens terugkom – nog steeds snap wat er waar gebeurt.
Het Usability Test Plan Dashboard heeft mij geholpen met het organiseren van tests. Het laat je goed nadenken wat je uit je testsessie wil halen en hoe je dat gaat doen. Zo wilde ik bij mijn eerste test met personen uit de doelgroep weten voor welke device types het zin heeft om de game verder te ontwikkelen.
Bij de tweede test wilde ik de nieuwe features toetsen: valt hun uitwerking in de smaak?
De stijl die de game uitstraalt in zijn gebruiksinterface is rechtlijnig en duidelijk, precies zoals ik de cultuur bij de brandweer heb ervaren. De primaire kleur in het ontwerp is brandweerrood. Brutus’ behuizing heeft ook deze kleur.
Als setting van de game heb ik gekozen voor Rotterdam-Rijnmond zelf. Een voor het grootste deel fictieve invulling weliswaar. De thuisbasis van de speler is de Brutus-werkplaats en het simplistisch getekende kaartje van de veiligheidsregio leidt naar de verschillende gebieden.
De plek waar wordt getraind – de kazerne aan de Moezelweg – heb ik in-game naar waarheid nagebouwd. Verder heb ik een level gemaakt in de volgende thema’s: hoogbouw, woonwijk (rijtjeshuizen), speelplein, haven, woonwijk (vrijstaande huizen) en industrie, allemaal gebieden die je ook tegenkomt in het echte Rotterdam-Rijnmond.
Het is er helaas niet van gekomen om alle individuele gebieden aan te kleden met obstakels en gevaren in het desbetreffende thema. Ik heb gekozen voor de focus op een sterker punt van mij: het bouwen van meer realistische functionaliteiten. Op dat gebied zijn in de laatste weken van het project een paar dingen gelukt die ik heel gaaf vind. Ze verrijken de ervaring echt!
Zo worden de rupsbanden van de echte Brutus bestuurd met opvallende joysticks: deze bewegen alleen verticaal. Ik ben erin geslaagd om ze in-game ook alleen verticaal te laten bewegen.
De verbinding tussen Brutus en zijn controller loopt met een 4G-verbinding. Dit maakt dat de uitvoer een kleine vertraging heeft, die ik met succes heb geprobeerd te simuleren in het spel.
Met of zonder input lag maakt een groot verschil voor de besturing. Hieronder staat de vergelijking tussen wel en geen input lag.
Tot slot: op de Brutus-controller staat bij een inzet of training een tablet waar je onboard kunt meekijken. Soms is Brutus bij een echt incident uit het zicht en kan men alleen afgaan op deze beelden. Op de in-game Brutus heb ik een tweede camera-object gezet waar je op mobile devices naartoe kunt schakelen met een knop.
In VR heb ik een tablet object gemaakt dat meebeweegt met de rechterhand van de speler. Ik laat het lijken dat het beeld van de tweede camera op de tablet wordt afgespeeld.
Om InaniBrutus bij een groter publiek bekend te maken heb ik sociale media aangemaakt. Hier plaatste ik afwisselend informatieve en grappig bedoelde posts om ontwikkelingen over InaniBrutus bij de doelgroep te krijgen.
Ik heb ook enkele events bezocht, georganiseerd door de veiligheidsregio zelf, zodat ik meer mensen kon spreken en laten zien over mijn game. Zo kon ik mijn idee, inclusief de toenmalige uitwerking, voorleggen aan een breder publiek. Dit was een mooie kans en een leuke ervaring om op te doen.
Het distribueren van de app als bestand wordt al snel onhandig. Veruit de meeste mensen zijn gewend om apps te installeren via een app store waar ze zoeken op naam. Daarom heb ik de variant voor mobile devices uitgebracht op Google Play. Later heb ik ook de VR versie op Oculus App Lab kunnen zetten.
Resultaat
De scriptie, presentatie en verdediging gaven het eindcijfer van een 8 voor het totale afstudeerproject.
InaniBrutus is gepubliceerd in app stores, zodat de doelgroep het kan spelen op de gewenste apparaten en platforms: Google Play Store voor Android-telefoons en Oculus App Lab voor de serie Meta Quest VR-brillen.
De keuzes op gebied van gameplay en techniek zijn verantwoord in hun eigen document, respectievelijk het Game Design en Software Design Document.
Reflectie
Over het geheel genomen ben ik blij en trots op wat ik heb bereikt met InaniBrutus. Ik heb een product ontwikkeld dat bestaansrecht heeft en in z’n kern goed. Maar er zijn ook dingen die ik achteraf anders had gedaan.
Zo zou ik in het vervolg niet meer dezelfde game voor zowel mobile als VR devices ontwikkelen. De technische opbouw verschilt drastisch. Daar komt bij dat de gekozen apparaat types doorgaans in een heel andere omgeving en context worden gebruikt. Dit maakt het heel onhandig en tijdrovend om de ervaring voor beide te optimaliseren.
Tevens weet ik door dit project wat er mis kan gaan als je de basis van een technologie niet kent. Het lukte me niet om de grondbeginselen van Unreal Engine te begrijpen, met als gevolg dat ik er zelf niets unieks in kon maken.
De release had ik ook graag anders had gezien. Ik wilde beide varianten tegelijk publiceren aan het eind van het afstudeersemester, maar de VR build was vertraagd door een probleem. Inmiddels weet ik wat dat was en is het live zetten alsnog gelukt, maar de aandacht voor mijn project was helaas niet zo groot meer.
Uiteraard overheerst de positieve herinnering, om een aantal redenen. Ik heb een pad bewandeld dat voor elke betrokkene onbekend was, omdat ik had gekozen voor een organisatie waar mijn opleiding niet eerder mee had gewerkt. Aan het eind van de rit was de ervaring voor alle partijen positief.
Het was best een stap voor mij om in een omgeving te komen waar ik de expert ben. Ik was ineens niet meer met collega programmeurs bij wie ik terecht kan voor ondersteuning, maar tussen de doelgroep die iets van mij nodig heeft. De ervaring om te werken met en voor deze gepassioneerde mensen was heel gaaf.
Gedurende het eindbaasproject van mijn studie heb ik mezelf een heel nieuwe technologie aangeleerd. Ik had ervoor kunnen kiezen InaniBrutus te maken in een technologie waar ik bekend mee was, maar dat zou de weg van de minste weerstand zijn. Uiteindelijk ben ik heel blij dat ik gekozen heb voor de engine waarvan ik vroeg in het project had bepaald dat die het meeste potentieel had voor mijn concept. Godot en GDScript hebben me geleverd wat ik verwachtte en het is zeker ook een toevoeging aan mijn veelzijdigheid.
Tot slot is het project door mij zelfstandig bedacht en opgezet. Tijdens dit project heb ik het breedste pakket aan taken en verantwoordelijkheden gedragen in mijn loopbaan als creatieve technoloog tot dusver: onderzoeken, ontwerpen (zowel technisch als grafisch), tests afnemen, documenteren en publiceren. Het hooghouden van al deze ballen was een geweldig leertraject. Gezien het eindresultaat kijk ik met veel voldoening terug op deze prestatie.
One response
Hi, this is a comment.
To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.
Commenter avatars come from Gravatar.