Stage Eindverslag - Portfolio Sander...

Stage Eindverslag Oriënterende Stage MediaTechnologie augustus 2010 - januari 2011

Sander Langhorst

1547490

MediaTechnologie

Hogeschool Utrecht

Stagedocent: Pieter Schilder Docent | Hogeschool Utrecht, Institute for Engineering & Design

Stagebedrijf: Soepel B.V.

Stagebegeleider: Anne Boumans Project Manager

Oriënterende stage Soepel B.V.

2 Stage Eindverslag | Sander Langhorst | 1547490

Voorwoord Stage bij Soepel B.V.

Het afgelopen semester, van 16 augustus tot 28 januari, heb ik stage gelopen bij het bedrijf Soepel B.V. In deze periode heb ik totaal ruim 840 uur door gebracht in het bedrijf. Soepel is een klein, van oorsprong een webgame bedrijf, dat nu al 5 jaar bestaat. In mijn stageperiode ben ik bezig geweest met programmeren in verschillende programmeertalen, het leren van nieuwe programmeertalen en methoden en meewerken in het gehele proces.



Colofon

Auteur

Sander Langhorst

De Wetering 19

4213 Dalem

0622323743

[email protected]

1547490

Stage Docent

Pieter Schilder

Oudenoord 700

Postbus 182 - 3500 AD Utrecht

06 23342354

[email protected]

Stagebedrijf

Soepel B.V.

Leidsestraat 74

1017 PD Amsterdam

0206391179

[email protected]

Stagebegeleider

Anne Boumans

020 639 11 79

[email protected]

mailto:[email protected]




























Inhoudsopgave 1. Inleiding ..................................................................................................................................................... 5 2. Het stagebedrijf ........................................................................................................................................ 6

2.1 Bedrijf ................................................................................................................................................. 6 2.2 7S Model ............................................................................................................................................. 7 2.3 Werkwijze ........................................................................................................................................... 8

3. Stage doelen.............................................................................................................................................. 9 3.1 Leerdoelen .......................................................................................................................................... 9 3.2 Planning .............................................................................................................................................. 9

4. Projecten ................................................................................................................................................. 10 4.1 Inwerk opdracht ............................................................................................................................... 11 4.2 Fantasy Hockey ................................................................................................................................. 14 4.3 Rattack .............................................................................................................................................. 18 4.4 Body & Brain ..................................................................................................................................... 20 4.5 Opdrachten tussen door ................................................................................................................... 22

5. Samenvatting .......................................................................................................................................... 23 5.1 Persoonlijke Evaluatie ....................................................................................................................... 23 5.2 Competenties ................................................................................................................................... 24

6. Bijlagen .................................................................................................................................................... 25 Bijlage 1. Voorstel Stage MediaTechnologie juli ‘10 .............................................................................. 26 Bijlage 2. Startverslag Stage Soepel ........................................................................................................ 27



1. Inleiding

In dit verslag is terug te lezen wat ik deze stageperiode heb gedaan en hoe ik mij heb ontwikkeld. Dit

verslag zal de globale lijn van mijn stage weergeven met mijn leermomenten uitgelicht. Deze

leermomenten worden behandeld in een samenvatting van de opdrachten die leidraad zijn in dit

verslag.

Halverwege het tweede leerjaar moest ik gaan zoeken naar een stagebedrijf. Ik ben daarom naar

Abdelhak El Jazouli gegaan om een lijst met gamebedrijven, die bekend waren bij de Hogeschool

Utrecht, te vragen. De lijst heb ik geanalyseerd en naar relaties van bedrijven gekeken. Ik ben alle

websites van de bedrijven gaan bekijken. Hierbij heb ik gelet op een leuke toepasselijke werkomgeving

en professionele begeleiding.

Toen ik op de website van Soepel kwam, was ik meteen onder de indruk van de kwaliteit van werk en

resultaten. Ik heb besloten om daar te gaan solliciteren. Bij de sollicitatie heb ik Andreas Verlinden en

Xander Hoogewerf gesproken, die graag een deel van mijn werk wilde zien. De sollicitatie was goed

gegaan en ik was zeer enthousiast, doordat hun enthousiast waren en omdat ik niet kon wachten te

beginnen met werken en leren in dit bedrijf.

Website:



2. Het stagebedrijf

2.1 Bedrijf Ik heb stage gelopen bij webgame studio Soepel B.V. gevestigd aan de Leidsestraat in Amsterdam.

Soepel ontwikkelt creatieve en technologisch innovatieve web- en promotionele games. Soepel is

gestart in 2005 wat begon als een samenwerking tussen klasgenoten. Dit is langzaam uitgebreid en

bestaat vandaag de dag uit de volgende medewerkers: Andreas Verlinden, Mattijs de Valk, Eljo Bosman,

Anne Boumans, Dimitri van Wezel, Ludwin Schouten, Rik Jansen, Terry Janssen, Xander Hoogewerf, Niels

Uiterwijk en Corina Kroon.

Soepel heeft een platte organisatie structuur. Soepel bestaat uit de eigenaren en managers,

programmeurs en vormgevers.

Organigram:



2.2 7S Model

Significante waarden. De informaliteit maakt Soepel. Je mening uiten, elkaar ergens op aanspreken en

gezamenlijk lunchen. De slagzin van Soepel zou zijn: “Wij zijn Soepel!”. En dat willen ze ook zeker

behouden. Ik heb me hiermee op mijn gemak gevoeld en kon op dezelfde manier mee doen.

Strategie. Soepel wil mooie, goede, kwaliteitsvolle producten neerzetten. Dit proberen ze door hun

kwaliteiten en producten te presenteren aan klanten. Soepel heeft altijd een ‘push’ strategie

aangehouden, wat inhoudt dat ze opdrachten van klanten aannam en hun ideeën en bevindingen naar

de klant pushen. Met ingang van 2011 willen ze een nieuwe strategie bereikt hebben. Namelijk een

zogenaamde ‘pull’ strategie, waarmee ze hun concepten iteratief presenteren en klanten hiermee naar

de producten toe trekken. Ik heb hier in meegewerkt door mijn best te doen om kwalitatief werk af te

leveren.

Structuur. Soepel heeft een redelijk platte organisatiestructuur, er zijn 4 projectleiders/managers en

daar onder programmeurs en vormgevers.

Systemen. Soepel hanteert technische protocollen waarbij een strakke programmatuur stijl en

commentariëren aangehouden wordt. Om dit niet te verbreken en chaos te veroorzaken heb ik mij hier

aan moeten houden.

Stijl. De managementstijl van Soepel is informeel. Iedereen gaat met elkaar om zoals ze willen. Geen

beperkingen in kleding, gezag of dergelijke. Meningen zijn altijd welkom. De manager is ook heel

informeel, hierdoor is de leiding wel duidelijk maar minder serieus.

Staf. Het personeel bestaat uit een gevarieerd publiek, er zijn zowel mannen als vrouwen en er wordt

een minimum kwaliteitsniveau gehanteerd, hierbij wordt niet zo zeer gelet op opleiding maar op

kwaliteit en ervaring.



Sleutelvaardigheden. De sleutelvaardigheden van Soepel zijn de technische complexiteit en het plezier

waarmee het gemaakt is. Door de informele stijl heerst er wel een ontspannen sfeer waardoor plezier

heel erg naar boven komt, daarnaast kan je met meerdere professionele programmeurs met jarenlange

ervaring complexe producten maken.

2.3 Werkwijze Mattijs de Valk en Corina Kroon zoeken contact met klanten, als een bedrijf vervolgens interesse wekt in het promoten van zijn of haar product door middel van een game volgt er een gesprek, zodat de klant zich kan uitspreken over zijn of haar wensen. Vervolgens wordt er een concept bedacht, als de klant dit in eerste instantie niet heeft gemaakt. In dat geval wordt het al gemaakte concept verfijnd tot een haalbaar concept. Dit verfijnde concept wordt teruggestuurd naar de klant samen met een mockup. Deze mockup word gemaakt door een van de vormgevers. Als de klant het concept leuk vindt en er tevreden over is wordt er een 'go' gegeven. Vervolgens word het concept doorgestuurd naar de projectmanagers. Anne Boumans en Andreas Verlinden. De projectmanagers bekijken hoelang een project ongeveer gaat lopen, hierbij word gekeken naar hoeveel tijd de gamedesign, het programmeren en het vormgeven gaat kosten. Hiervan word een tijdschatting gemaakt en worden deadlines gesteld. Als deze inschatting gemaakt is, wordt er een offerte gemaakt en deze word weer naar de klant gestuurd. Is alles in orde dan gaat Soepel aan de slag met het ontwikkelen van het spel of de applicatie.



3. Stage doelen

3.1 Leerdoelen Mijn stage leerdoelen waren:

● Professioneel programmeren met Actionscript 3.0.

● Ervaring opdoen in het meedraaien in een professioneel bedrijf.

● Multidisciplinair kunnen werken en communiceren in een professioneel bedrijf.

In de eerste weken bij soepel kon ik al zeggen dat ik heel veel geleerd had over het programmeren in

Actionscript 3.0. Niet alleen met programmeren maar ook met projectmanagement en vormgeving.

In de eerste week moest ik leren werken met stukken code van de programmeurs van Soepel. Hierbij

heb ik kunnen kijken naar overzichtelijke professionele code, waardoor ik meteen een beter beeld had

van een professionele programmeer stijl.

In de stageperiode heb ik veel kunnen leren hoe Soepel als bedrijf werkt. Ik heb mee kunnen kijken bij

het projectmanagement en bij de vormgevers.

3.2 Planning Mijn stageperiode was van maandag 16 augustus 2010 tot vrijdag 28 januari 2011. Ik zou 40 uur per

week werken, waarvan ik in princiepe elke maand één dag vrij mocht nemen. Ik heb rekening gehouden

met de 840 verplichte uren door 80 uur speling te nemen, waardoor ik gemakkelijker tijd kon inhalen bij

ziekte.



4. Projecten Bij Soepel heb ik meegewerkt als programmeur. Ik heb niet gewerkt aan een voorgedefinieerde

stageopdracht maar projecten die op dat moment draaiden.

Hieronder zijn de projecten en activiteiten beschreven die ik in mijn stageperiode bij Soepel heb

meegemaakt. Deze activiteiten beslaan een belangrijk deel van mijn ontwikkeling als Bachelor of

Engineering. Deze activiteiten achter elkaar zorgen voor een overzicht van de ontwikkeling van mijn

competenties.

Voor ik mijn eerste opdracht kreeg werden een paar dingen van mij gevraagd. Ik moest met nieuwe

software leren werken.

FlashDevelop. In Soepel werd mij aangeraden om met FlashDevelop te werken. FlashDevelop is een

alternatieve open-source programma om met Actionscript Flash applicaties te programmeren zonder de

Design-omgeving van Adobe Flash te gebruiken. FlashDevelop was niet zo zeer nieuw voor mij,

aangezien ik dit voor het laatste project van het tweede leerjaar MediaTechnologie ook heb gebruikt. Ik

heb dus niet veel problemen gehad met het gebruiken van FlashDevelop.

Eigen Engine. Toen ik bij Soepel begon, werd mij hun eigen ‘engine’, genaamd ‘Starlight’,

geïntroduceerd. De programmeurs van Soepel hadden gemerkt dat ze bij elk project de zelfde code basis

gebruikte om een spel op te zetten. Van de functies die daartoe behoren hebben ze een actionscript-

library gemaakt. Hiermee hoefde minder tijd besteed te worden om de basis van een nieuw spel op te

zetten. Dit was een kwestie van de library importeren en aan de slag gaan met programmeren.

Voordat ik de inwerk opdracht ging maken moest ik deze engine dus leren kennen en kunnen toepassen.

Ik heb dit op de volgende manier gedaan:

● Alles procesmatig doorlezen

● Meteen vragen hoe het werkt als ik het niet snap

● Bestaande voorbeelden bekijken

Ik heb besloten om eerst de code chronologisch door te lezen. Onduidelijkheden heb ik opgeschreven

en heb ik naderhand gevraagd aan collega’s. Ik heb kunnen achterhalen hoe het systeem werkte, door

kennis en inzicht wat ik heb en had opgedaan toe te passen. Het was jammer dat er geen documentatie

beschikbaar was, want dat had de onderzoekstijd aanzienlijk kunnen verminderen. Uiteindelijk heb ik

inzicht opgedaan in het systeem en heb ik andermans code eigen gemaakt.

Uiteindelijk was het een duidelijk stuk programmeerwerk en heb ik eruit kunnen halen hoe het werkt en

heb deze kennis kunnen toepassen op een test spel.



4.1 Inwerk opdracht De eerste weken bij Soepel moest ik hun eigen engine leren kennen en daarna een 3d race spelletje met

een 3d library maken.

3D library. Na het leren kennen van ‘Starlight’ is mij een opdracht gegeven. De opdracht was om een 3D

race spelletje te maken met een bestaande 3d-library. Er werd mij voorgesteld om dit met Papervision

3D te doen of met Away 3D. Aangezien ik Papervision al kende en wist dat hier grote bugs en

irritatiepunten in zaten, heb ik er voor gekozen om met Away 3D te werken. Away 3D leek mij een leuke

en interessante uitdaging om mee te beginnen voor.

Voor Away 3D heb ik tutorials op internet gezocht en voorbeelden ontleed en geanalyseerd. Uit deze

diagnose heb ik geleerd dat het Away 3D een andere benadering heeft als Papervision 3D, wat

praktischer toepasbaar bleek. Away 3D biedt een professionelere objectgeoriënteerde benadering van

objecten en de 3D wereld. Met deze analyse heb ik verder kunnen werken aan het concept.

Concept. Na het vooronderzoek naar de engine en 3d library, ben ik een begin gaan maken aan het, met

kennis die ik heb opgedaan, technisch opzetten van een startscherm en een 3d wereld. Tegelijkertijd

ben ik het geheel gaan conceptualiseren, hoe het eruit zou moeten zien en wat voor functies het zou

moeten bevatten. Dit heb ik opgeschreven en geschetst. Ik ben hierna met collega Xander Hoogewerf

gaan overleggen over het tijdsbestek. Hierbij hebben we een planning opgezet om dit concept uit te

kunnen werken. We kwamen tot de conclusie dat ik naast een engine en een 3d library ook een collision

library nodig (botsing tussen objecten). Ik heb daarvoor gekozen om box2d te gebruiken. Ik heb ervoor

gekozen om een 2D collision model te gebruiken, omdat ik niet meer dan een niveau in hoogte ga

gebruiken. Het spel wordt dus een 3D weergave van een 2D proces. Deze library heb ik net als Away 3D

onderzocht door tutorials en voorbeelden te zoeken en te analyseren. Dit was lastiger dan Away 3D,

omdat er meerdere versies beschikbaar waren en voorbeelden en tutorials grotendeels verouderd

waren. Uiteindelijk heb ik de meest stabiele versie gedownload en toegepast door de documentatie

erbij te houden.

3D modellen. Ik heb besloten om zo min mogelijk modellen te gebruiken om de framerate van het spel

hoog te houden. Het was ook niet nodig om meer detail in omgeving te brengen dan kubussen als

gebouwen, aangezien het een snelle gameplay had en je detail waarschijnlijk niet ziet. Ik heb één model

gemaakt voor een raceauto en die voor elke racer gebruikt. Die heb ik vervolgens, met mijn kennis

opgedaan in het tweede leerjaar, in 3ds Max gemaakt met zo min mogelijk polygonen.

Besturing. Voor de besturing heb ik moeten zoeken naar theorie van het eerste jaar mediatechnologie,

waar 2d wiskunde een vak was. Deze wiskundige theorieën heb ik moeten toepassen op de beweging

van de race autootjes. Deze moesten lineair bewegen door de beperking van de banden. De fysica van

de beweging van een auto heb ik onderzocht door natuurkundige websites op te zoeken en

natuurkunde lessen van de middelbare school na te kijken. Dit heb ik geflecteerd met wat ik al kende en



met het 2d collision-model. Na veel trail-and-error heb ik de juiste combinatie en volgorde van functies

kunnen vinden om de race auto realistisch te laten bewegen.

XML. Om de levels dynamisch te houden had ik bedacht om deze aan het begin van het spel in te laden

in plaats van ze gecodeerd in het spel te zetten. Dit zorgt voor een dynamische gameplay en zelfs de

mogelijkheid om eigen levels te maken. Het meest praktische, volgens collega’s, was XML. Zelf kende ik

alleen nog geen XML, dus ben ik dit gaan opzoeken en heb ik een collega gevraagd om mij te helpen dit

in Actionscript te realiseren. Dit heb ik vrij snel opgepakt, aangezien de functies ook in Starlight

beschikbaar waren, en ik was mogelijk om de XML implementatie zelf af te ronden.

AI. Een verplicht onderdeel voor de opdracht was AI (Artificial Intelligence), een computergestuurde

raceauto die tegen jou racet. Om dit te realiseren had ik een paar mogelijkheden dit af te bakenen:

● Checkpoint gerichte, non-stop acceleratie: De race auto gas laten geven en laten sturen richting

een checkpoint.

● Oriëntatiegerichte reactie: De race auto dynamisch gas laten geven op hoeveel ruimte er is, en

laten sturen om botsing te voorkomen.

● Pad gericht: De race auto over een voorgedefinieerd pad laten rijden.

Al deze mogelijkheden zijn correct toe te passen, maar welke ik gemakkelijk en dynamisch kan

toepassen werd niet meteen duidelijk. Ik heb hierom een tabelletje gemaakt met belangrijke aspecten

om dit goed te kunnen beoordelen.

AI type \ aspect

Tijd Moeilijkheid/complexiteit Dynamisch

Checkpoint gericht

niet lang, er zijn geen nieuwe methodes nodig

Niet moeilijk, beweging en positie bepaling zitten in het spel, die gecombineerd zullen de auto sturen.

Redelijk dynamisch, zo lang er checkpoints zijn rijden de auto’s naar de goede kant.

Oriëntatie Veel tijd, dit is een nieuwe benadering, hier zijn veel nieuwe inzichten voor nodig

Zeer complex, beweging moet reageren op positie en andersom, daarnaast is collision pretention nodig, wat niet in het spel zit.

Heel dynamisch, met deze manier kunnen de auto’s in elk level rijden.

Pad gericht helemaal niet lang, hiervoer moet ik een pad maken en de auto op laten bewegen.

Gemakkelijk, voor deze functie is geen bewegings-reactie nodig, ze zullen over een lijn bewegen.

Niet dynamisch, dit kan niet veranderen in het spel

Uit deze gegevens kon ik opmaken dat, als ik dynamiek in het spel wilde net zoals het inladen van levels

en niet moeilijk moest zijn, ik het best een checkpoint gerichte AI kon maken.

Oplevering. Aan het eind van de planning, die ik met Xander gemaakt had, kwamen Xander en Anne met

mij een review houden aan mijn bureau. Ik moest vertellen wat dit spel was, op een manier waarop ik



het spel opnieuw presenteerde aan hen, waardoor hun konden beoordelen wat ik uiteindelijk precies

gedaan en gemaakt had. Xander heeft hierna nog naar de code gekeken en Anne heeft de planning

gereflecteerd. Anne en Xander waren tevreden.



4.2 Fantasy Hockey Fantasy Hockey is een web spel voor Hoofdklasse Hockey (hoofdklassehockey.nl). Het is een manager

spel waarbij je een selectie maakt van bestaande spelers om een eigen team samen te stellen waarmee

je punten kunt winnen gebaseerd op werkelijke speler statistieken. Dit project is gerealiseerd door

meerdere programmeurs en vormgevers. Ik ben echter de enige geweest die constant op dit project was

ingedeeld. Fantasy Hockey is halverwege het project hernoemd naar Hockey manager.

Technisch ontwerp. We begonnen alleen met een concept, dus om een duidelijker beeld te krijgen van

de technische mogelijkheden heb ik een technisch ontwerp opgezet. Ik ben begonnen met het kijken

naar welke methoden we zouden kunnen gebruiken. Het spel bestaat uit verschillende schermen met

tabs aan de bovenkant waarmee je tussen schermen kan wisselen. Dit waren mogelijkheden:

● Tab menu een apart object, schermen als een menu behandelen met het bestaande systeem.

● Een Tab-manager maken, transities zouden dan moeilijker worden.

● Alles horizontaal in een object zetten en de tabs dat object een positie laten geven.

Het eerste punt leek mij het meest logisch, aangezien dit systeem al in hun eigen engine zat verwerkt.

Dit was ook de meest efficiënte mannier aangezien je menu’s pas plaatst wanneer je ze nodig hebt. De

hoeveelheid werk voor deze keuze was relatief kleiner dan de andere opties, aangezien ik dan geen

extra stuk functionaliteit nodig had. Dit had ik nog eens met collega Eljo Bosman, waarmee ik de eerste

vier weken aan dit project heb gezeten, overlegd.

Opbouw. Na het opzetten van een technisch ontwerp was het een kwestie van de basis opbouwen. Dit

op een zo’n praktische en efficiënte manier mogelijk. Bij elk onderdeel had ik met Eljo besproken hoe dit

te realiseren was, hoe ik dacht dat het zou moeten en hoe dit het meest efficiënt was. Uit controle van

collega’s heb ik heel veel kunnen leren. Ik heb geleerd dat heel veel dingen veel efficiënter kunnen dan

ik zelf gedacht had en dat alles nog generieker kan dan ik dacht. Bijvoorbeeld door een knop te

hergebruiken voor alle knoppen in een scherm en die ook in de code als één knop te behandelen.

AMF. Nadat de opzet gemaakt was, moest er een verbinding komen met een database. Voor deze

verbinding hebben we AMF (Action Message Format) gebruikt. Dit is een manier om met Actionscript

met een server te communiceren. Het bestaat uit twee libraries, een Actionscript library en een PHP

library die met elkaar communiceren. Met deze opstelling kan je gemakkelijk databases aanroepen.

Deze methode had ik eerder moeten toepassen in het eerste leerjaar. PHP heb ik echter nooit goed

gekend en heb ik bij dit project leren programmeren, dankzij collega’s, in het belang van de voortgang

van het project. Deze PHP kennis heb ik later in dit project moeten gebruiken voor server functies voor

dit onderdeel en het bijhouden van de database.

Google Documents. In dit project hebben we gebruik gemaakt van de live bewerkbare documentatie

omgeving van Google Documents. Dit was een manier van communicatie (todo lijst, bugs opsommen,

etc.), maar ook documentatie. Soepel gebruikt al jaren de Excel spreadsheet in Google Documents om



Todo lijsten en veranderingen in programma’s bij te houden. Dit vond ik heel praktisch en ben het zelf

ook veel gaan gebruiken.

Database. Databases waren voor mij een redelijk nieuwe ervaring. Hoewel ik wel het eerste leerjaar les

heb gehad in SQL, heb ik in dit project kunnen ervaren hoe databases en SQL in de praktijk werken.

Websites met MySql hulp waren mijn basis voor het maken van Sql-queries.

Voor het spel moest er de mogelijkheid komen om prijzen voor spelers uit te rijken en scores voor

gebruikers berekend worden. Dit moest aan de hand van gegevens van de database gedaan worden.

Deze database was opgezet door de opdrachtgever. Toen ik die database onder ogen kreeg was het

even slikken, alle data stond in aparte tabellen, elke actie werd op een aparte rij opgeslagen. Er waren

veel tabellen die aan elkaar gelinkt moesten worden en verschillende manieren van opslag.

Ik heb hier een tijdje mee vast gezeten. Hiermee ben ik meteen naar collega’s gestapt en die hebben mij

een stap verder geholpen. Uiteindelijk zeiden ze dat ik alle structuren en verbindingen moest

opschrijven en naast elkaar leggen. Toen ik alles had uitgeschreven, werd veel duidelijk en kon ik

gemakkelijk de link zoeken tussen verschillende velden.

Hiermee heb ik uiteindelijk gemakkelijk alle data kunnen extraheren en kunnen verwerken in

berekeningen.



Dataverkeer. In Fantasy Hockey heb je een marktonderdeel waar een lijst met spelers in staat. Op het

aanklikken van een speler werd een signaal gestuurd naar de server die op dat moment de

spelergegevens opvraagt en terug stuurt. Na een tijdje deze methode gebruikt te hebben bleek dat

alleen op de werkvloer al er erg veel dataverkeer was door Fantasy Hockey. We moesten uitvinden hoe

we het dataverkeer omlaag konden brengen. De eerste optie die we hadden onderzocht was het geheel

downloaden van de spelerlijst en het opslaan daarvan. Dit bleek een vertragend effect te hebben voor

de eerste keer, maar een verbetering op het gehele dataverkeer. We hadden daarom besloten om dit

aan te houden.

Vergaderen. Bijna elke week hadden we een vergadering om te overleggen waar we stonden en wat we

nog te doen hadden. Vaak kwamen hier wijzigingen van de klant bij kijken. Deze vergaderingen waren

binnen Soepel en niet met de klant. Dit zorgde ervoor dat de klant op hun eigen idee verder gingen

terwijl wij met wijzigingen bezig waren. Hieruit blijkt dat communicatie een slecht onderhouden punt

was, dit mede doordat er 2 klanten waren. Hoofdklasse Hockey was klant van Kellermanweb en

Kellermanweb was weer een klant van Soepel. Dit is teruggekomen in de evaluatie.

Evaluatie. Aan het eind van de looptijd van dit project hebben we geëvalueerd. Naar mijn mening vond

ik het project redelijk gelopen, aangezien ik veel geleerd heb, er plezier van heb gehad en het project

afgerond was. Veel collega’s vonden dat het een slecht project was. Volgens hen was vormgeving

techniek en functioneel ontwerp beneden Soepel standaard. Dit hebben we in detail besproken.

Communicatie bleek bij de klant te ontbreken, waardoor wij niet parallel aan de klant werkten. Iedereen

was het eens over het feit dat er teveel verantwoordelijkheid bij mij als stagiair was gelegd, zonder

duidelijke begeleiding. Bij mij heerste er verwarring over project verloop. Aangezien ik niet de

opdrachtgeving en concept ontwikkeling van dit project heb meegemaakt wist ik niet veel over

afspraken tussen partijen. Deze bleken niet in orde te zijn. Ik heb uitgelegd dat ik op de HU geleerd heb

om volgens een protocol een project te leiden en ook een geheel project mee te maken. Mij werd

uitgelegd dat het project inderdaad fouten zijn gemaakt, maar dat ik heel veel gemist had omdat ik het

management gemist had.



4.3 Rattack Rattack is voorgesteld door het management team als prototype spel. Rattack is een combinatie tussen

een tower defence spel en een Real Time Strategy spel. De naam komt van de ratten die je als soldaatjes

laat aanvallen. Ik heb dit project in mijn eentje gerealiseerd.

Documentatie. De kick-off werd geleid door Mattijs de Valk. Het algemene concept werd duidelijk, maar

documentatie daarover is nauwelijks gedaan. We hebben aspecten besproken of het technisch haalbaar

was, om bijvoorbeeld technisch meerdere hoogtelagen en daar vervolgens beslissingen over gemaakt. Ik

heb hier aantekeningen voor bijgehouden, maar Mattijs was het bij de review, een maand later, weer

vergeten. Hij was dus teleurgesteld dat er dingen niet in zaten, terwijl wij besproken hadden dat die

aspecten op een later stadium pas met collega’s besproken zou worden.

Planning. Na de kick-off werd mij gevraagd of ik een plan van aanpak wilde maken om duidelijk te

maken hoe ik dit precies aan ging pakken. Ik had een vrij ruige planning gemaakt, omdat ik lastig in kon

schatten hoeveel tijd de onderdelen gingen kosten. Hier was de projectmanager niet zo blij mee. Ik ben

opnieuw met een collega naar de onderverdeling gaan kijken. We hebben in detail besproken hoe ik de

onderverdeling in milestones kon opdelen en technische helderheid in het document konden brengen.

Hiermee zijn we op een realistischere planning gekomen.

Pathfinding. Het eerste onderdeel in dit spel was: ‘Grid Pathfinding’. Dit hield in dat in een tabel een pad

over cellen moet worden gevonden om van punt A naar punt B te komen.

Ik had de optie om dit zelf op te bouwen, voorbeelden te gaan zoeken en daar op verder bouwen of een

prototype, wat pathfinding had, van Soepel te gebruiken als basis. Hiervoor ben ik gaan analyseren wat

er nodig was om een goede pathfinder te maken.

Bij deze analyse kwam ik meerdere theorieën tegen om dit te kunnen realiseren:

● Alpha-beta pruning

● A*

● B*

● Beam search

● Bellman–Ford algorithm

● Best-first search

● Bidirectional search

● Breadth-first search

● D*

● Depth-first search

● Depth-limited search

● Dijkstra's algorithm

● Floyd–Warshall algorithm

● Hill climbing

● Iterative deepening depth-first search



● Johnson's algorithm

● Lexicographic breadth-first search

● Uniform-cost search

Uit de beschrijving van deze theorieën en voorbeelden bleek dat A* relatief het meest efficiënt was en

meest gebruikt. Om dit in mijn eentje op te zetten had ik veel tijd nodig. Ik had de tijd hier niet voor

ingeplant, dus ik moest wat anders verzinnen. Ik heb uiteindelijk besloten om het prototype van Soepel

te gebruiken aangezien collega’s mij daarmee konden helpen. Documentatie was niet bijgehouden,

maar dat hield mij niet tegen het systeem te leren kennen.

Bij het analyseren van de code ontdekte ik dat het gemaakt was voordat ze hun eigen engine gemaakt

hadden, aangezien de code hiërarchie hetzelfde was en de naamgeving grotendeels overeen kwam. Het

eerste wat ik gedaan had was het bestaande stuk code zo aanpassen dat hij werkt op de huidige engine

van Soepel. Toen dit werkte kon ik onderdelen schrappen en toevoegen waarmee ik in een korte tijd een

grote stap heb gemaakt.

AI. Voor Rattack moest een AI gemaakt worden om tegen te kunnen spelen. Dit was, doordat ik de hele

engine al had gemaakt, niet moeilijk te realiseren. Ik had dit gedaan door een timer bij te houden die op

een willekeurige tijd gezet werd. Op het moment dat die timer afliep, stuurde de AI vijanden verder.



4.4 Body & Brain Body & Brain is de Nintendo DS titel waar Soepel op dit moment mee bezig is. In de tijd dat ik geen

persoonlijke projecten had, heb ik mee kunnen werken aan dit project.

Testen. Voordat ik volledig ingezet kon worden in dit project, mocht ik in de middagen de voortgang van

Body & Brain testen en fouten noteren. Op dat moment was ik daar het best geschikt voor aangezien ik

nog weinig voorkennis van het spel had.

Symbol detection. 26 november is mij gevraagd of ik kon beginnen aan een beeldherkennings-

onderzoek voor het DS spel. Dit beeldherkennings-onderzoek moest leiden tot een fotospel waarbij je

specifieke vormen moet fotograferen. Aangezien nog niet zeker was wat de meest efficiënte manier was

om dit te realiseren hebben ze mij een test gevraagd op te zetten om verschillende methoden te uit te

proberen. Ik was enthousiast over een persoonlijke opdracht over beeldherkenning, omdat ik dit zelf erg

interessant vind en ik dit in het tweede leerjaar ook heb geleerd. Mij is uitgelegd dat je met de DSi een

foto maakt en dat de DSi dat moet goedkeuren. Ik moest een aantal theorieën benaderen:

● Convolution edge detection met sobel kernel

● Convolution edge detection met 4-oriëntatie kernels

● Angle Oriënted edge detection met de arctan functie

Ik mocht zelf kiezen welke programmeertaal ik mocht gebruiken. Ik heb gekozen voor Flash waardoor ik

gemakkelijk een grafische interface kon maken. Ik heb deze dag zelf nog een prototype gecreëerd met

een simpele convolutie op een voorgedefinieerde afbeelding waardoor een collega kon zien of zijn idee

ging werken of niet.

De volgende werkdag ben ik hier mee verder gegaan, heb ik alle theorieën toepasbaar gekregen en is er

een resultaat uit gerold. Snel daarna heb ik een benchmark opgezet om grote hoeveelheden plaatjes te

testen.

De DS programmeur Rik Jansen kwam met het probleem dat het masker (het beeldherkennings-

programma gebruikt een voorbeeld plaatje, een masker, om een beeld te herkennen) te groot was om

op een DS-rom te zetten.

Ik bedacht mij hierbij dat we maximaal 5 kleurwaarden gebruiken voor de maskers. Dit deed mij denken

aan RLE, Run-Length Encoding. Ik had dit voorgesteld en hij vond het een goed idee en heeft dit

toegepast.

Collision maps. In het DS spel Body & Brain zat een storende fout. Je kon door op een bepaalde manier

naar een muur te kijken en te lopen door muren lopen, doordat je buiten de collision map raakte. Ik heb

met Rik Jansen overlegd. We hebben gekeken naar de mogelijkheden, wat er fout zou kunnen gaan en

waar het aan kon liggen. We hebben gecontroleerd of het aan de code lag maar dat was

onwaarschijnlijk. Het meest voor de hand liggende waren afrondingsfouten in de collision map. Het

bleek dat er in de collision map hoeken van net geen 90 graden zaten, waardoor het spel door afronding

90 graden hoeken maakten en dus er doorheen liep. Ik heb hierbij de taak voorgesteld om de collision

maps te controleren en aan te passen. Ik zag bij het controleren dat de collision maps door ontwerpers



gemaakt was, aangezien alles los met de hand was toegevoegd naar het originele model wat je te zien

krijgt. Hierdoor bleken heel veel afrondingsfouten uit voor te komen. Ik heb gezocht naar alle hoeken

met ongeveer 90 graden en heb ze rechtgetrokken.

Scripten. Om de verhaallijn in het DS spel gemakkelijk te kunnen programmeren, heeft DS programmeur

Rik Jansen in C++ voorgedefinieerde stukken code gemaakt waardoor dit gemakkelijk te gebruiken is om

events af te kunnen handelen. Hij noemde dit C++ Macro’s, waarmee je functie namen kunt definiëren

met een stuk code erachter.

Hiermee heb ik een lijst met onafgewerkte, foutlopende stukken in het spel kunnen repareren door deze te reproduceren en logischerwijs de code daarop aan te passen en te testen.



4.5 Opdrachten tussendoor CSV parser. Voor een bestaand quiz-spel van Soepel moest een CSV-XML parser gemaakt worden

aangezien de klanten gemakkelijk vanuit MS Excel gemakkelijk een CSV kan exporteren. CSV kan niet

gemakkelijk ingeladen worden in Actionscript, dus is mij gevraagd om hier een stuk voor te

programmeren. Ik heb eerst CSV en XML geanalyseerd. Omdat het beide tekstgebaseerde bestanden

zijn, kon ik een ‘zoeken en vervangen’ functie maken.

Adobe Premiere Filmpje. Soepel had een opdracht gekregen om een promotioneel filmpje te maken

voor een ander webgame bedrijf. De collega’s die dit project zouden moeten realiseren waren op dat

moment bezet. Ik heb voorgesteld om hier een begin aan te maken, aangezien ik in het tweede leerjaar

heb leren werken met Adobe Premiere Pro en hiermee dus een begin kon maken. Ik heb eerst met

vormgever Ricardo van Duuren overlegd wat er in het filmpje moet komen. Het bronmateriaal bestond

al dus ik kon meteen aan de slag met controleren en monteren. Eerst heb ik alle fragmenten op goede

volgorde achter elkaar gezet met goede timing. Daarna heb ik er een achtergrond en effecten op gezet.



5. Samenvatting

5.1 Persoonlijke Evaluatie Deze stage heb ik als zeer leerzaam ervaren. Dat ik veel zou leren wist ik van te voren, maar dat ik zoveel

zou leren had ik niet voor mogelijk kunnen houden. Vanaf dag één ben ik met plezier naar Amsterdam

gegaan om mijn dag vol met werkzaamheden te voltooien. Ik ben blij dat mijn collega’s altijd klaar

stonden om mij te helpen wanneer ik dat nodig had en dat ze dat altijd goed deden.

Ik kijk nu terug naar een periode waarin ik mijzelf heb zien ontwikkelen. Essentiële punten die ik in deze

stageperiode geleerd heb is vooral het efficiënt en generiek aanpakken van programmeerwerk in

samenwerking met hun eigen engine en het maken, inladen en verwerken van XML. Hiermee heb ik

professionele technieken geleerd te gebruiken in projecten. Ik heb nieuwe programmeertalen geleerd,

kennis en inzicht opgedaan over andere disciplines, zoals project management en vormgeving. Wat er

het meest uitsprong was het leren efficiënt en generiek te werken, omdat dat een heel nieuw zicht heeft

gecreëerd op programmeren. Voor volgende projecten en stages zou ik graag meer mee willen doen in

projectmanagement en multidisciplinair willen werken. Wat altijd een leerpunt blijft is het meer willen

weten over programmeren. Hiermee zou ik gemakkelijker kunnen schatten hoe iets gaat werken en

hoeveel tijd dat gaat kosten.



5.2 Competenties Terugkijkend over de hele stage heb ik kunnen zien hoe ik te werk ben gegaan. Ik heb onbekende technieken eigen gemaakt, ik heb nieuwe programmeertalen geleerd en meer inzicht in andere disciplines gekregen door te onderzoeken met bestaande kennis en inzicht, dit te communiceren met collega’s en toepasbaarheid te beoordelen. Met deze nieuwe kennis heb ik theoretische modellen en concepten uitgewerkt, waarmee ik een oplossingsrichting heb gecreëerd voor het maken van een applicatie. Ik heb alleen en met collega’s planningen uitgewerkt, overlegd en gecontroleerd. Ik heb geleerd prioriteiten te stellen en een eigen planning voor bezigheden op te maken. Elk project is uitgevoerd naar inzicht en planning en gecontroleerd door de projectmanager, om kwaliteit te behouden. Hierbij werd ook rekening gehouden met context en kwaliteitsbewaking. Er zijn hier en daar problemen gevonden, die we vervolgens onderzochten, uitwerkten, de planning erop aanpasten en realiseerden.



6. Bijlagen

Bijlage 1. Voorstel Stage MediaTechnologie juli ‘10 3 bladzijden.

Bijlage 2. Startverslag Stage Soepel 9 bladzijden.



Bijlage 1. Voorstel Stage MediaTechnologie juli ‘10



Bijlage 2. Startverslag Stage Soepel

Stage Eindverslag - Portfolio Sander...

Documents

Transcript of Stage Eindverslag - Portfolio Sander...