Stage Eindverslag Oriënterende Stage MediaTechnologie augustus januari 2011

Transcriptie

1 Stage Eindverslag Oriënterende Stage MediaTechnologie augustus januari 2011 Sander Langhorst MediaTechnologie Hogeschool Utrecht Stagedocent: Stagebedrijf: Stagebegeleider: Pieter Schilder Docent Hogeschool Utrecht, Institute for Engineering & Design Soepel B.V. Anne Boumans Project Manager

2 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. 2

3 Colofon Auteur Sander Langhorst De Wetering Dalem Stage Docent Pieter Schilder Oudenoord 700 Postbus AD Utrecht Stagebedrijf Soepel B.V. Leidsestraat PD Amsterdam Stagebegeleider Anne Boumans

4 Inhoudsopgave 1. Inleiding Het stagebedrijf Bedrijf S Model Werkwijze Stage doelen Leerdoelen Planning Projecten Inwerk opdracht Fantasy Hockey Rattack Body & Brain Opdrachten tussen door Samenvatting Persoonlijke Evaluatie Competenties Bijlagen Bijlage 1. Voorstel Stage MediaTechnologie juli Bijlage 2. Startverslag Stage Soepel

5 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: 5

6 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: 6

7 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. 7

8 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. 8

9 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 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. 9

10 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 actionscriptlibrary 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. 10

11 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 11

12 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 12

13 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. 13

14 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 14

15 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. 15

16 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. 16

17 17

18 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 18

19 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. 19

20 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 beeldherkenningsonderzoek 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 beeldherkenningsprogramma 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 20

21 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. 21

22 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. 22

23 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. 23

24 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. 24