7.1 ANALYSE VAN KEUZEMOGELIJKHEDENESF – PROJECT : EEN SERIOUS GAME ALS OPLEIDINGSTOOL VOOR VEILIGHEID EN PREVENTIESamuel Eeckhaut, Projectmedewerker DAE-Research.Joost Ingels, Projectmedewerker DAE-Research

INTRODUCTIE

In WP 6 hebben we aan de hand van het model van Bergeron een first draft van het serious game ontwikkeld. Deze first draft bevat informatie over de realisatie van het serious game, zowel voor de visualisatie, de gameplay, de verhaallijn en de interface.

In dit hoofdstuk informeren we u over de mogelijkheden om het serious game te laten ontwikkelen bij professionele gameontwikkelaar. We voorzien daarvoor een aantal stappen:

- Realisatie van het serious gameo Verschillende technologieën:

Overzicht van verschillende game engines. Trends in ontwikkeling.

o Keuze in ESF-project: Waarom Unity

- Planning van serious game ontwikkelingo Algemeen betreffende een planning.o Keuzes in het ESF-project.

- Kostprijs van gameontwikkelingo Algemene richtlijnen rond de kostprijs.o Specifieke kostprijs in project: duiding

- Professionele gamebedrijven in Vlaandereno Opsomming van game bedrijven (FLEGA.BE)

- Algemeen Besluit

REALISATIE SERIOUS GAME

1

1. Verschillende Technologiën

A. Overzicht van verschillende Game-engines:

Binnen de game-industrie maken we gebruik van verschillende al reeds gerealiseerde engines of een eigen samengestelde engine. Om een eigen engine te maken is de tijd en kostprijs enorm hoog en kiest men daarom vaker voor een kant-en-klaar engine. We hebben een aantal onderscheidingen binnen alle engines. Dit gaat van gebruiksvriendelijkheid, mogelijkheden van exports naar welbepaalde platformen tot de gebruikstypes (open source, gepantenteerd of vrij te gebruiken).

Voor men de keuze maakt van welke engine men wil gaan gebruiken is het van belang dat er een grondige analyse wordt gemaakt van het te verwezelijken game. Wat is er belangrijk in je game dat duidelijk visueel getoond moet worden en/of worden geprogrammeerd. Nadien kan je kijken welke engines die eigenschappen ondersteunen. Alsook het budget is van groot belang. Het kan zijn dat je project een bepaalde som opleverd en bij het gebruik van de engine een commissie moet worden betaald als je boven een bepaald bedrag komt die op voorhand is vastgelegd.

Hieronder een aantal engines met bijhorende eigenschappen:

Naam Platform Prijs € 2D/3D Taal Scripting LicensiesBlender Multiplatform 0 3D C++ Python GPL

ConstructClassic Windows 0 2D Python Minitroid GPL/BSDjMonkeyEngine Multiplatform 0 3D Java - BSD

Construct 2 Multiplatform 0-326 2D/3D C++ / Java - PatentCocos2D Multiplatform 0 2D C++ /Python/ Java Java MITENIGMA Multiplatform 0 2D C++ EDL GPLIDTech 5 Multiplatform 0 2.5D/3D C++ AMPL Clipper DLL Patent

Kobold2D Multiplatform 0 2D Objective-C Lua MITCryengine 4 Multiplatform 10/m 3D C++ Lua Patent

Euphoria Multiplatform ? 3D C++ - PatentFrostbite Multiplatform 0 3D C++ / C# - ?

GameBryo Multiplatform TBD 3D C++ - PatentUnreal Engine 4 Multiplatform 20/m 3D C++ / C# / Lua / … C++ Patent

Unity 4 Multiplatform 0-1140 2D/3D C# / Java C# / Java PatentTaal: basistaal die wordt gebruikt binnen de engine.Scripting: taal die wordt gebruikt om kleinere programmaatjes te maken.GPL: GNU General Public License (meest gebruikte free software licensie).BSD: groep van softwarelicenties voor open source software.MIT: vrije software licentie zoals de BSD-licentie met voorwaarde dat de copyright-statement in alle kopieën moet blijven staan.Prijs: Afhankelijk van (non-)commerciële doeleinden. Indien commercieel zal er rechtstreeks onderhandeld moeten worden.Patent (Proprietary): broncode gepatenteerd en enkel beschikbaar onder strikte voorwaarden.

De meeste engines zijn vrij te gebruiken en kunnen worden uitgebreid d.m.v. betaling. Vanaf er commerciële bedoelingen zijn zal er een vaste prijs of commissie gevraagd worden. Soms is er een extra plugin aanschaf nodig voor het exporteren naar verschillend platformen.

B. Trends in ontwikkeling:

2

Aangezien we hier voornamelijk over serious games hebben, is het niet altijd nodig om engines te gaan gebruiken die meer gericht zijn op AAA-games. Ze zijn vaak complexer of bevatten heel wat features die in een serious game niet zullen worden gebruikt of gewoonweg overbodig zijn. Anderzijds worden deze soms toch gebruikt omdat ze een realisme-gehalte kunnen visualiseren en dus een realistische weergave kunnen teweegbrengen van een situatie naar de gebruiker toe.

De betere engines van vandaag richten zich momenteel op de mogelijkheid tot het uitbrengen van verschillende platformen, de ondersteuning van objecten die gemaakt zijn uit verschillende werkpakketen zoals 3ds Max, Maya, Softimage, Cinema4D, Blender en zoveel meer.

Een aantal pro’s en contra’s tussen de meest gekende engines Unity, Unreal Engine en Cryengine:

UNITY

Pro

Gebruiksvriendelijke editor/UI;Makkelijk en snelle export naar diverse platformen;Bijna geen beperkingen van import via andere werkpakketen;2D support en geïntegreerde 2D physics;Heeft een grote bibliotheek van klaargemaakte 3D objecten (ter betaling);Gratis voor non-commercial.

Contra

Enkel een paar primitieve objecten ter beschikking in de engine zelf;Gratis versie bevat een heleboel features niet zoals bvb shaduwen;Pro-versie = duur: €1140 (eenmalig) of €57/maand (ten minste 1 jaar contract);Elke export-licenties voor andere platformen is + €1140 of + €57/maand;Gratis versie heeft een watermerk dat niet kan uitgeschakeld worden.

UNREAL

Pro

Fantastische grafische mogelijkheden (hoogstandje voor realistische omgevingen);Geavanceerde dynamische belichtingsmogelijkheden;Performant particle systeem;Voor nieuwe developers is de programmeertaal C++ geworden i.p.v. unrealscripting;Nieuwe blueprint scripting systeem geïntegreerd (note-based);Goedkoop: €19/maand (+5% van de vraagprijs van het product bij commercieel doel).

Contra

Unrealscripting wordt niet meer gebruikt in de laatste versie, nu C++ geworden;Oudere generatie consoles wordt niet meer ondersteund (zoals PS4, Xbox360, …);Deze engine is erg professioneel en moeilijk in gebruik in vergelijking met andere;Maximum 4 platform export mogelijkheden;Scaleform technologie zit niet standaart in de engine (belangrijk voor UI).

CRYENGINE

Pro

Zeer sterke en gemakkelijke artist-programming d.m.v. flowgraphs;Sterke audio-tool;Geïmplementeerde UI scaleform technologie;Makkelijke aanpasbare AI (Artificial Intelligence);Gebruiksvriendelijke editor.

Contra

Ondersteund geen FBX (veel applicaties kunnen dus niet exporteren naar de engine);Documentatie is niet altijd even goed en duidelijk ter beschikking;Complexe Materiaal editor;Niet zoveel platform exportmogelijkheden;Geen asset-store ter beschikking.

3

2. Keuze in ESF-project

De keuze ging uit naar Unity vanwege de gebruiksvriendelijkheid enerzijds en anderzijds omdat het gamebedrijf ons wees op de voordelen van het werken met deze engine. Hieronder geven we een kort overzicht van deze voordelen.

Wiki-Unity is een deel van de Unity Community en is een plaats waar je een bibliotheek van scripts en kennis kan opdoen betreffende de functies binnen Unity. Hierdoor versnelt het werktempo van het gamebedrijf omdat ze bij moeilijkheden de problemen vaak snel kan opzoeken en oplossen.

De artist heeft geen tijdverlies in het converteren van de game-objecten om in de game-editor te laden. Unity heeft een uniforme pipeline wat importeren van objecten betreft. Voor de artist is Unity een gemakkelijke engine voor het binnenbrengen van de objecten.

Bij het testen van de game kan men om het even welk moment het spel laten pauzeren en aanpassingen doen terwijl de game nog niet is afgesloten (geen code uiteraard). Men ziet onmiddellijk resultaat zonder dat je opnieuw het game moet opstarten.

Het heeft een redelijk brede waaier aan platform exportmogelijkheden wat in tegenstelling niet altijd het geval is bij andere engines. Op het eerste zicht hebben we dit ook niet echt nodig, maar het is wel belangrijk cross-platform te werken in eender welk opzicht (niemand kan benadeeld worden omdat ze een specifiek besturingssysteem hebben op hun toestel).

Omdat het game document ons al reeds kan vertellen dat we geen realistische maar een semi-cartoon game willen maken, hebben we de zware features van andere engines niet van doen. Alsnog is de Unity engine zeker krachtig en meer dan voldoende voor ons project.

4

PLANNING VAN DE ONTWIKKELING

1. Algemeen betreffende een planning

Bij het creëren van een planning voor de ontwikkeling van een game is het belangrijk dat je tijdens het plannen strikt bij het game document blijft. Ga geen extra’s gaan toevoegen of bepaalde delen zomaar gaan aanpassen. De kleinste aanpassingen kunnen veel werk vragen zonder daar verder bij na te denken. Het is verstandig om altijd een aantal dagen extra ter beschikking te houden om, na het maken van de game, de schoonheidsfoutjes eruit te halen en onvoorziene problemen tijdens de ontwikkeling te kunnen herzien en/of op te lossen.

Indien er nog geen gamestructuur, aan de hand van een flowchart, zou gemaakt zijn is dat dat een goed vertrekpunt. Loop doorheen de game die je wil maken en bekijk elk deel die je wenst tegen te komen en probeer dit zo goed mogelijk samen te vatten tot een duidelijk schema. (Start => Splachscreens => Menu => Spelen/Opties/Afsluiten => …) Dit kan je ook doen voor de scenario’s in de game. Elke gebeurtenis heeft één of meerdere gevolgen. Zo’n flowchart kan je snel een idee geven hoe complex je game is en hoeveel werk je er zal aan hebben.

De eerste stap die we ondernemen om de game te ontwikkelen is vooral prototyping. Het heeft geen zin om onmiddellijk in detail te gaan. Bij het testen van het prototype kan je al waarnemen of een bepaald onderdeel van je game al dan niet werkt en eventueel zou moeten aangepast worden. Hierdoor kan je nadien (indien noodzakelijk nodig) een beetje gaan schuiven in de planning. Met een prototype bedoelen we dat er gebruik wordt gemaakt van een simpele box of een cilinder die een object voorstelt (bvb: een witte box stelt een stoel voor, een rode cilinder stelt een brandblusser voor, enzoverder…). Indien gewenst kan ook ter verduidelijking van een level van de game, deze worden uitgetekend met alle acties, NPC’s (niet speelbare characters) en beloningen.

Van de volledige gamestructuur zal de game zelf uiteraard het meeste werk innemen. Verdeel de tijd die je volledig wil spenderen nu onderling aan elke deel van de flowchart en doe dit voor elke persoon die meewerkt aan de game.

5

Eens het prototype is gemaakt laat je het best eens testen door je doelgroep, zo weet je als je in de goede richting bezig bent of als er in het eerste stadium al bepaalde dingen moeten herzien worden. Na het testen kunnen we starten aan het gedetailleerder werk. Om een overzicht te hebben van wat er allemaal moet worden gemaakt stellen we een asset-lijst op en geef je elk object een waarde mee van belangrijkheid (dit kan gedaan worden d.m.v. een cijfer tussen 1, minst belangrijke en 3, belangrijkst). Zo geef je aan wat essentieel, bijgevoegde waarde en opvulling is en wat je eerst gaat maken omdat je zo het snelst je game ziet groeien.

De karakters maken we door behulp van een modelsheet en animatie eigenschappen. Die geven je het silhouette, belangrijke kenmerken en mogelijke poses weer. Voor je hier een tijdsbesef kan van opmaken moet er eerst goed worden nagedacht over wat dit personage allemaal moet kunnen. Een hoofdpersonage zal bijvoorbeeld moeten kunnen stappen, lopen, springen, bukken, iets vastnemen, enzoverder… In tegenstelling tot een nevenkarakter die bijvoorbeeld enkel moet zitten en wat rondkijken is daar niets meer aan en zal er minder aandacht worden aan besteed. Hierdoor kan de manier van het maken van het karakter een groot verschil teweegbrengen. De kwaliteit van de animaties en het model die die animaties gaat weergeven zal dus afhankelijk zijn van de topologie waaruit het is opgebouwd en wat dus ook meer tijd vraagt om het karakter te maken. Indien bepaalde onderdelen kunnen worden herbruikt van een ander personage, dan is dit een winst in tijd en kan er aan een ander karakter meer worden gewerkt voor hetzelfde tijdsbudget die voorheen werd opgesteld.

Intussen is een programmeur de code aan het schrijven om de game volledig werkende te krijgen en alle acties op het juiste moment te kunnen laten afspelen. Je kan bij het programmeren twee kanten op, namelijk hard- ofwel dynamisch coderen. Hard-coded programmeren is vaak sneller, maar in latere fases minder makkelijk aan te passen (stel dat er bij noodzaak een stukje extra wordt toegevoegd in een level tussen twee acties). Dynamisch coderen is meer werk, maar het helpt je wel in de toekomst als er zaken moeten worden aangepast (1 cijfertje veranderen en de rest wordt automatisch mee aangepast waar nodig. Of bijvoorbeeld 1 kamer maken en die meerdere malen zal gebruikt worden met dezelfde functies en bij een correctie van een kamer dat alle andere meevolgen met de wijziging).

Een programmeur zal vooral met standaard objecten zoals een box of cilinder aan de slag gaan omdat voor die persoon de werking van de code en het doel belangrijkst is. Uiteraard is het ook leuker voor die persoon als het game meer vorm begint te krijgen met de art.

Eens de game er staat en er is nog tijd over kan je gaan debuggen (fouten zoeken en oplossen) en hier en daar een verbeteringen gaan toepassen indien nodig of gewenst.

Een planning is afhankelijk van heel wat verschillende aspecten binnen de ontwikkeling en kunnen soms moeilijk worden ingeschat. Hoe meer referentie er is en hoe sterker het gamedocument is kan een betere planning opgesteld worden. Hou steeds rekening met extra tijd te voorzien op het einde van de productie!

6

2. Keuzes in het ESF-project

Hierbij wil ik eerst en vooral nog het ESF-game schetsen. Het gaat om een educatieve game over brandpreventie en hoe men moet omgaan bij geval van brand. Er wordt tot heden vandaag nog steeds een klassikale opleiding gegeven door 2 mensen aan ongeveer 3500 werknemers. Ter ontlasting van de leraren en ter controle van de werknemer als deze de leerstof goed heeft begrepen werd een game gemaakt die alle stappen doorloopt bij een mogelijk brand.

We zijn gestart bij een onderzoek van ons doelpubliek en al reeds bestaande educatieve serious games. Het doelpubliek: Wat krijgen zij aangeleerd en wat is er essentieel. Wie zijn die mensen eigenlijk? Jong, oud, hoog- en laaggeschoold, verschillende diensten of computerkennis. Het ESF-project overkoepeld een gigantische groep mensen met allerlei verschillende eigenschappen die soms ver uiteenlopend zijn. Het was dus belangrijk voor we aan de game starten, te onderzoeken wie die mensen zijn en wat ze wel of niet kunnen zodat we de game voor iedereen konden laten werken. Wanneer deze groep in geanalyseerd was zag je wat er helemaal niet kon werken of net héél belangrijk was. Een onderdeel van het onderzoek was ook de toekomstige gebruikers zelf te ondervragen wat voor hen belangrijk is bij het spelen van een spel. Op deze manier bespaar je jezelf veel tijd door overbodige of net essentiële functies in kaart te brengen.

Reeds bestaande educatieve serious games. Door een oplijsting te maken van bestaande games kan je d.m.v. een analyse kijken wat andere game ontwikkelaars gebruiken om tot hun doel te komen. We verzamelden een 75-tal games en bekeken de meest relevante voor ons eigen project. Af en toe zijn er ook studies rond gemaakt en een paper over geschreven waarbij ze de uitwerking beschrijven en ons dus al een antwoord kunnen bieden op bepaalde vragen.

Terwijl de onderzoeken omtrent doelpubliek en bestaande games bezig waren, werd er ook al een gamedocument opgesteld met de nodige titels. Uiteindelijk hadden we al een vaag idee van de look van het spel en wat de mogelijkheden waren wat betreft de controls om het spel te spelen. Hier en daar maakten we al een keuze zoals tussen 2D en 3D en het hoofdzakelijk gebruiken van de muis. Ter toevoeging en verduidelijking van het concept werden een paar schetsen gemaakt van het level en characters.

Het ESF-game speelt zich af in het A.Z.-Groeninge van Kortrijk (het nieuwe gebouw). Dit leek ons de ideale locatie vanwege de herkenbaarheid naar de gebruikers toe. We namen foto’s ter referentie en konden hierdoor al een asset-lijst maken van de te maken objecten voor in het spel waardoor we per object een geschatte werktijd kunnen aan koppelen. Het aantal personages die het spel ging gebruiken was ook eerder beperkt tot het de verschillende dienstgroepen binnen het ziekenhuis en een patiënt. We kozen voor één algemene vorm die voor alle andere characters kon passen en door middel van het toevoegen van attributen meer persoonlijkheid kon geven per dienst. Hierdoor konden we de tijd drukken i.p.v. allerlei nieuwe characters te ontwerpen.

Omdat er reeds een klassikale opleiding bestond van de brandpreventie was het scenario grotendeels vastgelegd. Het leek ons ideaal de opleiding op te delen in 3 stukken omdat de speelduur dan maximum 5 tot 10 minuten per onderdeel zal duren. Dit zorgt ervoor dat de speler de kans krijgt om zijn opleiding op verschillende tijdstippen te vervolledigen.

7

De animaties voor de characters hebben we voornamelijk opgenomen met een motion capture pak in plaats van manueel te animeren. Je bespaart hier héél wat tijd en geld uit. De persoon die de animaties moet maken zal er sowieso langer aan werken als hij van nul moet beginnen i.p.v. een aantal schoonheidsfoutjes moet verwerken die uit het motion capture pak komen.

De gebruikers-interface werd deels bepaald door de gebruiker zelf door een paper-prototyping moment te organiseren. Er werden een 4-tal groepen met telkens 2 leden gemaakt die samen, naar hun eigen zeggen, de ideale UI konden creëren door gebruik te maken van geprinte interfaces van andere games en toevoegingen konden doen met aangeleverd tekenmateriaal.

Om onszelf te controleren als we de goede richting aan het uitvaren waren, werden twee testmomenten georganiseerd. Eerst bij het prototype, daarna een bijna final ontwerp. We ondervraagden de gebruikers naar gebruiksvriendelijkheid (controle), fun-factor, autonomie-ervaring, grafische visualisatie, verhaallijn en het bereiken van de doelstellingen.

Ten slotte maken de teamleden een ruwe schatting van elk onderdeeltje binnen hun werkpakket voor het ontwerpen van het spel en rekenen hierbij toch een ruim voldoende marge er nog eens extra bij. Hieronder de uiteindelijke planning van het volledige ESF-game project:

Beschrijving/Maand J F M A M J J A S O N D J F M A MDoelgroep analyseOverzicht bestaande SGGame DocumentReferentie Game DesignWorkflow DocumentNulmeting doelgroepPrototype makenCo-creatieproces 1 (UI)Co-creatieproces 2 (Test)Uitwerking van de case

Op het volledige project werd er nauw samengewerkt met 10 mensen:

- Manager (1);- Coördinator (1);- Game-Developers (2);- Toegepast psycholoog (2);- Industrieel ontwerper (1);- Toegepaste informaticus (1);- A.Z.-Groeninge medewerker (2).

8

KOSTPRIJS VAN GAMEONTWIKKELING

1. Algemeen richtlijnen rond de kostprijs

A) Succubus Interactive model:

Voor we een schatting kunnen maken van de kostprijs wordt er binnen dit model eerst en vooral de nadruk gelegd van wat een goed serious game eigenlijk is. Het doel van het spel moet onmiddellijk duidelijk kenbaar zijn, het moet een bepaalde fun-factor bevatten door eventueel gebruik te maken van extra vrije acties, het moet een duidelijke designkwaliteit hebben, een correct scenerio en beschikbaar voor bijna iedereen en het doel van het spel moet uiteraard duidelijk zijn.

Het model van ‘Succubus Interactive’ baseerde zich op 3 categoriën, “Training – Evaluatie”; “Informatie – Bewustzijn training”; ”Promotie – Marketing”. Het is een business model waarvan de investering tussen de €20.000,- en €200.000,- ligt. Dat is voornamelijk afhankelijk van de kwantiteit van de content, de gewenste kwaliteit, het type game en de gebruikte technologie. Hierdoor gebruikt men de formule: prijs = type game x (technologie + kwaliteit + lengte).

8000 x x(2+1+1,5)

Type game: € 4000,- Behendigheid / Gericht;€ 6000,- Strategie / Management;€ 8000,- Scenario;€ 10000,- Actie.

Technologie: 0 = 2D flash;1 = 3D flash of boosted;2 = 3D Engine (+ licentiekosten);3 = eigen ontwikkelde technologie van het gamebedrijf (+ licentiekosten).

Kwaliteit: 0 = Optimale prijs, lagere kwaliteit;1 = Juiste prijs voor juiste kwaliteit;2 = Beste / Hoge kwaliteit.

Lengte # speelduur (per uur).

B) Voorbeelden op dit model:

Een game waarbij verhaal en management van belang is (8000 + 6000 euro) met een 3D Engine technologie waarbij we een juiste prijs voor de kwaliteit betalen en het spel kan een 4-tal uren worden gespeeld. Hier zal dan de prijs geschat worden op: 14000 x (2 + 1 + 4) = € 98000,-.

Een tweede voorbeeld, een game met acties en een goed uitgewerkt scenario, maar men gebruikt een 2D engine met een hoge kwaliteitsfactor en het spel kan maximaal 1 uur duren. Een ruwe schatting zal als volgd zijn: 18000 x (0 + 2 + 1) = € 54000,-.

Uiteraard gaan deze voorbeelden over een ruwe schatting en ga je best sowieso gedetailleerder uw kostenraming gaan doen. Er komt veel meer bij kijken dan enkel deze 4 factoren. Hoe snel wil je de game afkrijgen en met hoeveel personen zal het game worden gemaakt? Meer personen zorgt voor een sneller resultaat, maar het zal uiteindelijk meer kosten.

9

Een aantal vragen die je jezelf moet stellen:

- Met hoeveel personen zitten we in het team;- Hoeveel kost elke persoon per maand;- Welk materiaal heb ik allemaal nodig (PC’s, console, …);- Welke licenties moeten er aangekocht/gehuurd worden;- Hoeveel tijd is er nodig om alles te modelleren, riggen, skinnen, unwrappen, textureren, …;- Wat zijn de bedoelingen om inkomsten te verwerven van het spel (indien van toepassing);- Wat voor kwaliteit wil je uiteindelijk afleveren;- Hoeveel is de buffer-tijdsfactor;- …

2. Specifieke kostprijs in project

In de game-industrie wordt een serious game gerealiseerd aan een dagprijs van ongeveer 520 euro per persoon. Het ESF-game werd ontworpen door 1 programmeur en 1 artiest die samen ongeveer een 12 man-maanden (elk 6 maanden) hebben gewerkt om een volledig afgewerkt product te creëren. De totale kostprijs voor het realiseren van het serious game is € 124.800.

€ 520,- (dageenheid) x 20 (werkdagen/maand) x 12 (man-maanden) = € 124.800

10

PROFESSIONELE GAMEBEDRIJVEN IN VLAANDEREN

1. Opsomming van gamebedrijven

Bazookas Brugge Serious & educational games; Entertainment game productionCartamundi Digital DrongenCatLab Interactive Bottelare WebgamesCrazy Monkey St. Kontich Indie game developmentDAE Studio’s Kortrijk 3D Visualizations and gamesDie Keure Brugge Educational apps and gamesGriN Antwerpen Indie game developmentI-Illusions Brussel Indie game development; freelancer entertainment tech.Kaetemi Lembeek Software and game developmentLuGus Studios Genk Experimental and serious gamesMindscape 3D Gent Interactive 3D Visualizations and Educational GamesRusty Bolt Torhout Indie game developmentSakari Games Antwerpen Indie game developmentSileni Studios Kontich Indie game developmentTriangle Factory Gent Indie game developmentVisual Impact Hofstade International game developer

ALGEMEEN BESLUIT

We kunnen concluderen dat we niet ‘zomaar’ aan een game starten en dat er dus heel wat onderzoek vooraf moet gebeuren als je de mogelijkheid van risicovol falen wil vermijden. Er moeten een heleboel belangrijke keuzes worden gemaakt zodat de eindgebruiker de game optimaal, gebruiksvriendelijk en misschien licht-verslavend kan gaan gebruiken. De te in de gaten te houden factoren zijn tijd- en geld budgetten zodat er nadien geen super en hoogstwaarschijnlijk succesvol game moet worden geannuleerd. Een goed samenwerkend en overleggend team is één van de basissen die de productie tot een goed einde kan brengen.

Voor je naar een gamebedrijf stapt denk je best zelf eerst goed na wat je echt wil gaan bereiken met het game. Wat moet je game exact gaan doen? Moet het enkel informatie overbrengen of moet het een handeling van een werknemer aanleren of moet eerder beide doelen bereikt worden. Moet er veel gedetailleerde animaties of objectvisualisatie gebeuren? Hoe zou jij het graag zien als je het spel wilt spelen? Onderzoek je doelgroep goed op vlak van opleiding, leeftijd, computerkennis, ingesteldheid tot het gebruik van nieuwe technologie.

11

12