Utvikling

Vi startet med å analysere hva vi måtte anskaffe for å gjennomføre prosjektet, som var en Arduino Uno Wifi-rev2, kombinert med en database og en webserver for et lokalt API. APIet og databasen ble “hostet” av et av våre gruppemedlemmer. Nøkkelen til prosjektet var da selve pokeAPI som har en omfattende database om Pokemon og alt innenfor verdenen til Pokemon, og var nødvendig for all informasjon om selve Pokemonen som Arduinoen skal generere. Selve kodeutviklingen ble gjort ved hjelp av et eget open-source IDE laget for Arduino som er basert på C og C++.!

Brukerhistorier

Funksjonaliteten vi ønsket av prosjektet ble presentert i form av brukerhistorier. Vi forestilte oss selv i posisjonen som spiller, og deretter fant på funksjoner som vi ønsket at et slikt "spill" kunne tilby oss.

Nummer	Brukerhistorie	Krav	Prioritet	Implementert/Ikke implementert
1	Som en spiller, ønsker jeg å kunne fange Pokèmon ved å bevege på “Pokèballen”	Aktivere generering og lagringsprosessen av Pokèmon ved bruk av et akselerometer.	Must	Implementert
2	Som en spiller, ønsker jeg å ha en oversikt over hvilke Pokèmon som jeg har fanget.	Implementerer en webapplikasjon som er tilgjengelig gjennom en nettleser.	Should	Implementert
3	Som en spiller ønsker jeg å kunne se hvilke potensielle Pokèmon som kan bli fanget (Pokedex).	På webapplikasjonen bør det være en oversikt over alle Pokèmon som eksisterer. Sortering av generasjon burde være mulig.	Should	Implementert
4	Som en spiller ønsker jeg å kunne få en form for signal/feedback når jeg har klart å fange en pokèmon.	Implementere en lysdiode, liten høyttaler eller motor som aktiveres når en pokèmon har blitt fanget.	Could	Ikke implementert
5	Som en spiller, ønsker jeg å ha en mobil applikasjon for å ha oversikt over all informasjon relevant for spillet. (Typ hva som kan fanges der jeg er, hvilke pokèmon jeg har).	Lage en app som kan vise informasjon om spillet og brukeren.	Could	Ikke implementert
6	Som en spiller, ønsker jeg å kunne fange pokèmon typer som er basert på geografisk biome.	Bruke GPS til å hente geografisk informasjon om hvor brukeren er for å bestemme hvilken pokèmontype som skal genereres.	Could	Ikke implementert
7	Som en spiller ønsker jeg å kunne bytte Pokèmon med andre spillere.	Implementere en funksjon som lar brukere gi bort og bytte fangede pokèmon.	Could	Ikke implementert

Av disse brukerhistoriene, så ble 1, 2 og 3 implementert. Brukerhistorie 1 var obligatorisk, og et must ettersom det var det grunnleggende vi måtte ha for at spillet faktisk skal være et spill. Dette var den mest tidkrevende funksjonaliteten i prosjektet, noe som gir mening med tanke på at det var hele grunnlaget for spillet. Brukerhistorie 2 var også et must have, ellers oppnår aldri spilleren progresjon i spillet på grunn av at de får ikke sett om de har fanget alle pokèmonene. Gotta catch them all er slagordet for pokèmon, og det hadde tatt seg ille ut å ikke kunne fange alle sammen. Et brukergrensesnitt er nemlig en svært viktig del å inkludere i et spill, og kan betydelig forbedre spillopplevelsen. Brukerhistorie 3 var et could have, og passet godt i kombinasjon med brukerhistorie 2, så ble dermed også implementert.

Brukerhistorie 4 ble ikke implementert grunnet mangel på selve "pokèballen" som vi forsøkte å få 3D printet for prosjektet. Med denne ballen så kunne vi enkelt montert en lysdiode på ballen, og skrevet kode som fikk den til å lyse opp når en pokèmon ble bekreftet fanget. Med mangel på ett fysisk grensesnitt (pokèballen) så var det lite motiv for oss å legge til denne funksjonaliteten.

Brukerhistorie 5 var en avansert oppgave, og ble ikke gjennomført på grunn av at det var svært tidkrevende. Utfordringene her hadde vært å designe og bygge applikasjonsarkitekturen, grensesnittet og kommunikasjonen mellom spillere om vi skal ha flerspillerfunksjonalitet (Ref brukerhistorie 7).

Brukerhistorie 6 ble ikke gjennomført grunnet mangel på GPS modul på Arduinoen. Vi fikk ikke tak i et selvstendig GPS modul som vi kunne lodde til Arduinoen, og den Arduinoen som eksisterte med akselerometer og GPS modul var ikke lengre til salgs. Vi var borti et spesielt Arduino bibliotek som lot oss få GPS koordinater til Arduinoen basert på trådløse nettverk i nærheten ved bruk av Google Maps GeoLocation API. Dette viste seg å være lite nyttig for oss grunnet manglende presisjon og mangel på å ha et pålitelig antall trådløse nettverk hvor enn spilleren kan befinne seg. Utfordringer med denne brukerhistorien hadde vært å kunne identifisere hva slags geografisk biome man befinner seg i ved hjelp av GPS koordinater. Vi fant ikke en åpenbar løsning på dette problemet, men det er mulig at Google Maps sin API har en løsning. Med tanke på hvordan Google Maps fargekoder terrenget sitt (Grønt for vegetasjon, blått for vann o.l) så kan det eksistere en variabel som sier hva slags biome et visst koordinat har.

Brukerhistorie 7 hvilte hovedsakelig på brukerhistorie 5 og ble heller ikke implementert. Flerspiller funksjonalitet er beryktet for å være avansert og vanskelig å utvikle. Vi hadde foretrukket å implementere bytting av pokèmon i en applikasjon, men en enklere måte å gjennomføre dette kunne vært å inkludere det i grensesnittet på nettsiden. Mangel på tid gjorde slik at vi heller ikke startet på denne brukerhistorien. Utfordringer her hadde nok vært databasearkitektur og sikkerhet. I flerspiller spill så er spillerene svært glad i å finne alle mulige måter å utnytte systemet (Mulligan, Patrovsky. 2003. s. 474), og sikkerhet hadde vært den absolutt største utfordringen over tid. (I et fiktivt scenario der vi faktisk har spillere og ett lansert produkt)

Utviklingsmetode

For å gjennomføre dette prosjektet så fulgte vi i hovedsak utviklingsmetoden “test driven development”. Dette var den mest passende utviklingsmetoden for prosjektet vårt på grunn av at prosjektet vårt var klart definert med åpenbare ledd som kunne testes separert fra hverandre. En annen grunn til å bruke denne utviklingsmetoden er at all koden som er skrevet kjører fra en og samme fil, og er skrevet av en person. Det er da en fordel å følge en forholdsvis enkel utviklingsmetode som tar ett skritt av gangen.

Problemer, tester og løsninger

For å utvikle Arduinomon måtte vi løse noen problemer. Vi måtte finne ut av hvor sensitivt aksellerometeret skulle være, for å ikke konstant generere pokemon ved at aksellerometeret reagerer på for lite bevegelse. Samtidig måtte vi passe på at man ikke måtte bevege på Arduinoen med overdreven kraft for å få aksellerometeret til å reagere. Dette ble testet ved å bevege på Arduino brettet med forskjellig mengder kraft for å se hva en passende verdi burde være. Ettersom vi ikke fikk tilgang til en 3D printer for å produsere en beskyttende “pokeball” for Arduino brettet, endte vi opp på verdien 5000, som tilsier 5000 milligram verdt av akselerasjon på sensoren. Med denne verdien så kan man veldig enkelt bevege brettet 90 grader for at koden skal kjøres og en pokemon genereres, som da lagres i en database. For åpenbare grunner så kommer vi ikke til å kaste en “pokeball” som inneholder et Arduino brett uansett hvor beskyttende en 3D-printet “pokeball” er, så hensikten er bare for testing.

Andre tester innebærer også at vi måtte teste kommunikasjon mellom Arduinoen og APIene vi brukte, og testing av at data blir sendt til databasen. Noe spesifikt som kom fram av testingen her var at vi trengte to Wi-Fi klienter i koden. MySQL støttet ikke SSL, samtidig som at APIet som Arduinoen hentet informasjon fra brukte et SSL sertifikat som dermed Arduinoen ikke kunne dekryptere uten SSL. Så vi trengte en Wi-Fi klient med SSL for å hente informasjon fra APIet, og en Wi-FI klient uten SSL for å sende informasjon til databasen.

Referanser

Mulligan, Jessica & Patrovsky, Bridgette. (2003). Developing online games. United States, New jersey: Pearson Professional Education.