MonstroCity Ett positionsbaserat MMORPG spel

MonstroCity Ett positionsbaserat MMORPG spel Johan Afseer afseer@student.chalmers.se Andreas N Bjerkeholt bjerkeho@student.chalmers.se Peter Lundberg gggg@student.chalmers.se Hans Andersson anhans@student.chalmers.se Otto Kahne kahne@student.chalmers.se 10 maj 2009

Sammandrag Vårt projekt har varit att utveckla ett mobilspel som utnyttjar positioneringsteknik för att förstärka spelupplevelsen. Spelet var ett äventyrsrollspel i en storvärld med multipla användare och hade ett Sci-fi tema. I vårat arbete nyttjade vi verktyg XX, YY och ZZ för att skapa både en server och en mobilklient för spelet... Abstrakt The aim of this project was to develop a mobile game to 3:rd generation mobilemobilephones phones that utilises positioning technology to enhance the player experience. Sida 2 av 24

Förord Detta är ett kandidatarbete i Datorteknik vid instutitionen för Data och Informationsteknik, Chalmers tekniska högskola. Vi har samarbetat med Nokia och vill tacka för det generösa lånet av mobiltelefonerna som gjort det möjligt att testa vårt spel. Vi skulle vilja tacka Anders Mårtensson, Anders Qvist och Leif Ryd för idéen till MonstroCity [1]. Vi vill tacka vår handledare Sus Lundgren som har varit ett stöd i det vi visste minst om. Vi vill också tacka för alla tips och hjälpsamma kommentarer som vi har fått på vägen. Vår examinatorer Peter Lundin och Christer Carlsson. Biblioteket och det stöd en rörig grupp har fått med sina inlämningar Sida 3 av 24

Innehåll 1 Inledning 5 1.1 Den producerade produkten............................ 5 1.2 Syfte......................................... 5 1.3 Avgränsning..................................... 5 1.4 Historik....................................... 6 2 Speldesign 7 2.1 Vision........................................ 7 2.2 Mekaniker...................................... 7 2.2.1 Användning av positionering....................... 7 2.2.2 Månadsbaserat spelande.......................... 7 2.2.3 Spela själv................................. 7 2.2.4 Spela i grupp................................ 8 2.2.5 Strider.................................... 8 2.2.6 Quests.................................... 8 2.2.7 Accelerometer................................ 9 2.3 Tema......................................... 9 2.3.1 Designval gällande temat......................... 10 3 Teknik & Nätverk 11 3.1 Generellt...................................... 11 3.2 Nätverk....................................... 11 3.2.1 Förklaring av protokollet......................... 11 3.2.2 Designpoänger............................... 11 3.2.3 Nätverksprotokollet............................ 11 4 Design och utveckling av klienten 14 4.1 Klientens struktur................................. 14 4.2 Klientens GUI................................... 14 4.3 Utvecklingen av GUI:it............................... 14 5 Server & Modell 17 5.1 Struktur....................................... 17 6 Positionering 18 6.1 Problem....................................... 18 6.1.1 Diffar på upp till 25 m........................... 18 6.1.2 Lång laddningstid efter förlorad kontakt med satellit.......... 18 6.1.3 Radioskugga................................ 18 6.1.4 Representation............................... 18 7 Diskussion 19 8 Bibliografi 20 9 Ordlista 21 Sida 4 av 24

A Användardokumentation 22 A.1 Introduktion.................................... 22 A.2 Tutorial....................................... 22 A.3 Användarmanual.................................. 22 B Systemdokumentation 23 B.1 Kravdokument................................... 23 B.2 Systemspecifikation................................. 23 B.3 Detaljerad systemspecifikation........................... 23 B.4 Modul- och underprogram/metodspecifikationer................. 23 B.5 Kvar att implementera............................... 23 C Utvecklingsdokumentation 24 C.1 Dagbok....................................... 24 C.2 Tidsplaner...................................... 24 C.3 Slutsatser om kandidatarbetet........................... 24 C.4 Slutsatser om uppgiften.............................. 24 Sida 5 av 24

1 Inledning Spel länge kontrollerats på många olika sätt och spelats på många olika platser men antalet spel där positionering har används och hela utomhus varit spelplanen har varit begränsade. Vårat arbeta har gått ut på att utveckla just ett sådant spel. Utvecklingen ha varit av hela produkten från början till slutet och involverat delar som speldesign, världs-författande, design av ett nätverksprotokoll, inlärande av ett nytt programspråk, kodning av server och klient och ett stort mått problemlösning. Projektet har förutom en givit en stor mängd erfarenheter resulterat i en serverapplikation bestående av XX rader kod skriven i java, en klient applikation beståend av YY rader kod skriven i python, två skriftliga rapporter och en wiki bestående av 50 sidor. Projektet tillkom efter en idee.. 1.1 Den producerade produkten I slutändan av projektet har vi ett spel som spelas på användarnas mobiltelefoner där deras position i den verkliga världen avgör deras position inom spelet. Spelarna kan slås mot monster och strida mot varandra där vinnaren avgöra av spelarna utrustning, nivå och grundvärden. Allt detta hanteras i servern som håller i spelmodellen och via spelarna mobiltelefoner som fungerar som spelarna kommunikationsverktyg med modellen. 1.2 Syfte 1.3 Avgränsning För hela projektet har vi låtit mobiltelefonernas inbyggda funktioner hantera alla gps beräkningar, att göra något eget skulle varit ett väldigt omfattande arbete, kräva omfattande ämnesstudier och inte nödvändigtvis blivt bättre än vad som nu fanns att tillgå. Denna avgränsning har möjliggjort för oss att fokucera på speldesign och implementering av positioneringen. Projektet har gjorts för att undersöka positionering i spel och vad det kan innebära varför många saker som vanligtvis skulle höra till att utveckla ett stabilt spel inte har behandlats t. ex: Användartester, eftersom spelet aldrig var innehållsrikt nog med innehåll för att vara lockande för testare; Omfattande utveckling av innehåll, då vi såg det mindre relevant för våra undersökningar har spelet inte fyllts med en stor mängd olika utrustningar, olika typer av monster eller många viktiga platser på kartan; Stresstester, vi har aldrig haft möjligheten att ha ett stort antal spelare i spelet samtidigt, skulle detta ha blivit en komersiellt produkt hade detta behövts göras; Begränsad karta, då testningen skedde på Chalmers Campus Johanneberg begränsades spelytan till detta område varför det inte går att spela utanför, något som skulle ha varit eftertraktat i en faktiskt produkt. Slutligen så har avancerad grafik och avancerade grafiska funktioner aldrig varigt prioriterat under projketet, dels för att mobiltelefonerna har begänsad beräkningskapacitet men även för att de hade ökat komplexiteten med en hög grad och för att vi saknade specialkompetens inom området. Sida 6 av 24

1.4 Historik GPS har funnits länge men det är först på senare år som de börjat finna sin väg in i var mans hand... Mobilers prestanda, i form av beräkningskraft, har ökat omfattande och således även möjlighetena man har när man arbeter med mobiltelefoner, på senare tid har detta lett till mera och mera avancerade spel och till att mobiler utrustas med GPS. Samtidigt har införande av 3G och Turbo-3G lett till större möjlighter för högkvalitativa internetanslutning var man än befinner sig. Tidigare Pervasive games Sida 7 av 24

2 Speldesign 2.1 Vision Vår vision är att skapa ett spel som skiljer sig från traditionella dator- och mobilspel genom att införa rörelse. När man slåss i spelet mot andra spelare och monster ska man behöva röra på sig för att lyckas. Dessutom kommer rörelse ingå på andra sätt, då man kan tvingas ta sig till vissa platser. Vårt mål är att spelet ska vara roligt, det ska vara fördelaktigt att gå samman med andra spelare och bilda lag, men det ska samtidigt gå att spela ensam. Spelaren ska vara driven att återkomma till spelet för att utveckla sin karaktär och delta i tävlande mellan spelare. 2.2 Mekaniker 2.2.1 Användning av positionering I strid Då monster och spelare... I äventyr Del av våran vision var att man skulle röra sig för att utföra uppdrag eller delta i händelser genom att ta sig till en specifik plats... 2.2.2 Månadsbaserat spelande Vi bestämde oss tidigt att låta spelet ha ett slut skulle vara en fördelaktigt. Detta för att... Tidsbestämningen sattes till en månad för att... Vi bestämde oss för att använda en topplista för att ranka spelare under spelsessionen som är under en månads period. Efter en månad så börjar spelsessionen om främst för att ge nya spelare som kom in mitt i den förra sessionen en chans att placera sig bättre på topplistan. Då det är en klar fördel att vara med från början av varje spelsession för att få hög poäng. 2.2.3 Spela själv Det man ska få ut av att spela själv... Vi valde att inte ha med följande saker av följande anledningar... Då andra spelare oftast är inloggade i spelet samtidigt som du så spelar du aldrig ensam. Du kanske väljer att inte interagera med dom andra spelarna men alternativet finns alltid så länge det finns spelare online. Spelet är fullt spelbart utan andra medspelare då det finns gott om monster att bekämpa och en hel del uppdrag att klara av på egenhand. Sida 8 av 24

2.2.4 Spela i grupp Det man ska få ut av att spela i grupp... Vi valde att inte ha med följande saker av följande anledningar... Genom att spela i grupp så gör man spelet ännu mer socialt. Om man förflyttar sig tillsammans kan man ju kommunicera genom tal som är ett betydligt snabbare och tydligare sätt än att skriva meddelanden genom spelet till varandra. Men det öppnar upp nya möjligheter genom att du kan besegra starkare monster och då få mer pengar och xp. Det finns inget sätt att officellt visa andra spelare att man är en grupp då vi inte har infört ett party-system då detta inte är en nödvändigt funktion för att spelat ska vara spelbart utan har blivit bortprioriterat i brist på tid. 2.2.5 Strider Fungera genom att.. Detta valde vi eftersom... Vårt stridssystem är uppbyggt genom två olika lägen som en spelare kan vara i. Om en spelare är i passivt läge kan denna ej attackeras men inte heller attackera. Men är han i aggressivt läge så kan han både attackera och attackeras. Om du är i passivt läge och vill övergå till aggressivt så tar detta 30 sekunder. Är du i aggressivt och vill gå till passivt så tar det också 30 sekunder. Båda fördröjningarna är avsiktliga för att förhindra att folk missbrukar övergångarna genom att byta fram och tillbaka i strider så anfallaren slutar att attackera. En övergång mellan lägena visas tydligt för påverkade parter. Den skada som ges är av typen AoE dvs du gör skada på ditt objekt inom ett område runt dig. Du kan alltså bara göra skada på ett objekt i taget. Detta gör du genom att markera en spelare och välja att du ska attackera det. Själva skadan utdelas i intervaller på en sekund. Attacken avbryts inte men ger ingen skada då objektet kommer utanför det området som du skadar inom men så fort objektet är tillbaka inom räckhåll så görs skada som vanligt. En attack pågår tills ditt objekt är bekämpat, du blir beskämpad eller att du väljer att avbryta attacken. Om det beskämpade objektet är ett monster så får du pengar och xp för din insats. Om du i din tur blir attackerad av ett objekt så måste du välja att attackera tillbaka för att returnera någon skada eller springa utom räckhåll för att komma undan. Alternativa designer på stidssystemet Vi hade många olika tankar på hur ett stridssytem skulle fungera, några av dessa var... 2.2.6 Quests Quests eller uppdrag var något som vi hade med i våran design redan från ett tidigt skede men som inte blev implementerat i vårat spel pga tidsbrist. Målet med quests är att spelaren ska dras in mera i spelet genom att spelaren får uppdrag att utföra som leder till olika former av belöningar, de tänkta beläningarna var främst tänkt att vara föremål, Sida 9 av 24

erfarenhetspoäng eller i form av den spelinterna valutan men hade även kunna varit titlar eller tilfälliga förstärkningar för spelerens avatar. Designen av quests var att det skulle finnas två typer, personliga quests och globala quests där den avgörande skillnaden skulle vara vilka som kunde avklara uppdragen och om man skulle göra den i tävlan med andra eller ej. Personliga quests skulle vara uppdrag där målet är att ta sig till en plats eller besegra ett visst monster medans globala quests skulle ha samma mål men med kriteriet att de skulle vara tillgängligt för alla spelare samtidigt och att bara en eller ett fåtal spelare skulle kunna få belöning för avklarat uppdrag. Med globala quests hoppades vi få till en stärre mängd tävlan och action i spelet eftersom spelaren behöver aggera snabbt för att försäkra sig om att få uppdragets belöning, en annan fördel vi såg vara att det skulle ge spelare en anledning att ha spelet rullande eftersom man aldrig kunde veta när en global quest skulle dyka upp brevid sig. gällande för alla quests är att när uppdraget var avklarat skulle det försvinna från alla spelares lista över aktiva quests. Vi övervägde även att införa eventuella tidsbegränsningar på quests för att undvika att spelet stagnerade pga oavklarade quests men eftersom detta skulle vara en avvägningsfråga som bäst löses med spelartester och data från faktiskt spelande lyckades vi inte komma till någon slutsatts i frågan. Quests skulle, om de hade implementerats, som det mesta andra ligga i modellen och ett antal ändringar hade behövts göras till koden, nätverksprotokollet skulle behövts utökas, quest-objektet skulle behöva kodas och vid varje tidpunkt skulle det behöva kollas om spelare lyckats uppfylla sina uppdrag. Dessutom skulle lämplig modellering för att ge spelerna en visuel representation av uppdragen behöva göras, den tillgängliga kvarvarande tiden ansågs vara för kort och quests lades på is. 2.2.7 Accelerometer Då mobilerna vi fick tillgång till för att utveckla på hade accelerometer övervägde vi om spelet skulle ha funktioner som aktiverades av annat än knapptryckningar och position men kom fram till att inte lägga energi på det av tre anledningar, det skulle konplicera användarinterfacet, det skulle begränsa oss från visionen och att det skulle bli gimmiky. Detta för att... 2.3 Tema Handlingen utspelar sig i nutid men har ändå lite av ett futuristiskt inslag.under ett expriment så finner forskare av en slump en länk till en parallell dimension. Det enda sättet att nå denna dimension är via GPS-sateliter. Man är inte i den andra dimensionen fysiskt utan man tar en typ av fysisk form i den dimensionen som rör sig likadant som man själv fast i den dimensionen. Vid radioskugga tappar man kontakten med sitt alias i den andra dimensionen. Efter många tester och expriment på den parallella dimensionen får forskarna fram att den består av en oändligt stor, ren och lättutvunnen energi. Denna energin är dock bunden i den andra dimensionens invånare och för att ta tillvara på energin krävs att man förkortar invånarnas livslängs avsevärt. Detta väcker stora protester då invånarna har formen av små Sida 10 av 24

gulliga kaniner också så kallade monster. Men i vår tid då priset på bränsle nått nya höjder börjar folk bli desperata och drar sig inte för att vara omoraliska. Giriga företag hittar en billig och effektiv lösning för att ansluta till den andra dimensionen genom en mobiltelefon. Företagen söker en massa människor som kan hjälpa till att utforska den andra dimensionen och samla energi, så kallade utforskare. Utvinningen av all energi som alla utforskare samlat görs via ett konstgjort svart hål i slutet på varje månad. Kaninernas enda försvar är att försöka kasta ut en ur dimensionen genom att störa din signal. När din signalstyrka är noll så dör ditt alias och du måste ladda upp den igen genom att ta dig till en laddningsplats. Även utforskarna har funnit knep för att störa andra utforskares signal och kasta ut dom ur dimensionen, detta för att temporärt minska konkurrensen. För att motivera utforskarna att göra ett bra jobb hålls en topplista över bästa energisamlare i varje månad. När en månad är slut evalueras utforskarnas arbete och den utforskare som samlat ihop mest energi vinner ära och berömmelse. Han kan också känna att han bidragit starkt till att lösa världens energiproblem även om han är medbrottsling i att förstöra en annan dimension. Med pengarna som utforskarna får kan dom köpa bättre utrustning så som skydd mot störningar och apparatur som avger störningar men detta kan göras på speciellt utvalda affärer. 2.3.1 Designval gällande temat Vi valde detta tema av ett antal anledningar, den först och ytligaste anledningen var att ingen i gruppen kände för att utveckla ett fantasytema för spelet eftersom vi känner att det är mera än en aning överexploaterat. Det diskuterades både post-apokalyptisk Sci-fi och kriminellt-tema men det vi fastnade för var nära framtid/alternativ nutid-temat som ni just har läst om. Anledningen till detta kan lätt förklaras med immersion vilket översätts till försjukenhet och innebär att spelet känns som mera än bara ett spel. Det vi ville uppnå vara ett scenario där ens spelande känns som det faktiskt skulle spela roll. Att få spelaren att tänka-tänk om detta är verkligt och det jag gör nu är avgörande vilket skulle ge spelet något av en extra dimention. När vi väl hade grunderna till scenariot såg vi till att blanda in en naturlig förklaring för de spelkoncept vi redan hade utarbetade in i temat, två av dessa var att vi ville ha en återställning av spelet varje månad och att vi ville ha ett erfarenhets system somm skulle vara relativt överdrivet för människor. Månadsåterställningen förklarades med det svarta hål som krävdes för att föra över energin mellan världar och den accelererade erfarenhetskurvan förklaras med att det inte är du utan din avatar i den alternativa världen som utvecklas. Sida 11 av 24

3 Teknik & Nätverk 3.1 Generellt Vilka delar projektet består av... Vilken information som finns i systemet Hur modellen ser ut 3.2 Nätverk 3.2.1 Förklaring av protokollet Beskrivning 3.2.2 Designpoänger Poänger 3.2.3 Nätverksprotokollet Paketet börjar alltid med ett huvudkommando, som antingen är LOGIN user pass och UPDATE sessionkey Ett kommando är definierat som en rad, avslutad med \n, där första ordet i raden (avskiljd med mellanslag) är kommandotypen. Alla textmeddelanden i fritext använder understreck istället för mellanslag Kommandon (från klienten): POSITION x y satelliter INTERACT type ITEM EQUIP index ITEM UNEQUIP slottype index ITEM DROP slottype index ITEM USE index (för unequippable items) ITEM MOVE fromslot fromindex toslot toindex Kommandon (från servern): Item VIEW lista STATS statblocklista INTERACTION type RESPOINTS lista (x y) Sida 12 av 24

slottype kan vara: w (weapon) a (armor) e (equipped) n (non-equipped) Index börjar på 0 Inventory (för varje item i inventoryt) Itemname Description Type Equipped Slotindex Mod (ATK=4,DEF=-1) StatBlock (för varje stat, mellanslag imellan, men man kan välja att inte skicka alla stats) ATK=2 INTERACT typer: ATTACK, CANCEL, MESSAGE ATTACK targetkey ATTACK MONSTER targetkey CANCEL MESSAGE targetkey message INTERACTION typer: se INTERACT status: ACCEPTED, DENIED, ABORTED ATTACK ACCEPTED targetkey ATTACK DENIED message ATTACK ABORTED CANCEL ACCEPTED CANCEL DENIED (borde ej inträffa) MESSAGE ACCEPTED MESSAGE DENIED message VIEW (för varje objekt i vyn) KEY Sida 13 av 24

Name Level Type (Sträng, typ Player, Monster) x y Status Attackable (0, 1) MaxHP HP EVENTS (för varje event på player-objektet) eventdescription eventcontent olika eventdescriptions, med tillhörande eventcontent: MESSAGE message objectkey name DEAD message XP AWARD message LEVELUP message ATTACK ABSORBED NOCONTENT ATTACK HIT message ATTACK EVADED NOCONTENT ATTACK OUTOFRANGE NOCONTENT MONEY DROP message INVENTORY FAIL message Sida 14 av 24

4 Design och utveckling av klienten Klienten är användarnas del av spelet och har som främst uppgift att se till att information förs mellan spelarna och spelet och vice versa. Den har även jobbet att få ut positioneringsinformation från GPS:en och skicka detta till servern. Den är kodad i Python 2.3 för Symbian S60 system. De största problem vi mötte med klientan var att... 4.1 Klientens struktur 4.2 Klientens GUI Eftersom det viktigaste är att alltid veta var man är så är det också det som visas i GUI:ts bakgrund, detta i form av en karta. Spelaren representeras av ett lysande klot, vilken skärmen alltid följer så att den förblir i mitten vid alla tillfällen. Klot av andra färger representerar andra spelaren eller monster. På kartan kan man se alla de hus och byggnader man hade kunnat se på vanliga GPS:er, men i spelets alternativa dimension syns istället lysande grönt där det är byggnader och svart där det är väg. Se figur-1. Ovanpå detta ligger två menyknappar nere i varsitt hörn för olika sorters val och högst upp en panel med spelaren liv, samt att det uppe i höger hörn finns en bild som visar om man vill slåss med andra spelare eller inte. De två olika menyerna är Menu och Interact. Menu är gjord för att man ska kunna nå alla spelets fullskärms fönster som innehåller övrig viktig information vilken är nödvändig för spelaren. I dessa fönster finns även inställningar för spelaren, som till exempel vilken utrustning han väljer att bära utav den han har med sig. Interact menyn är istället gjord för att endast ta hand om interaktionskommandon man kan skicka till andra spelare eller ett monster. Exempel på detta skulle kunna vara Engage, som gör att man påbörjar en strid med en annan spelare eller ett monster. För att bestämma vem i närheten man vill slåss med får man markera en spelare eller ett monster med Joysticken på mobilen genom att trycka vänster eller höger. Detta gör att en ring kommer upp runt den andra spelaren eller monstret och du tillåts då att välja en aktion. I Menu kan man finna ens Inventorydär man har allt man bär med sig. Se figur-2. I Inventoryfönstret kan man undersöka föremål, använda dem och köpa eller sälja dem om man står tillräckligt nära en affär. Står man inte vid en affär kan man istället slänga dem. När vi designade GUI:t så tänkte vi på att få det funktionellt sett snarlikt det som mobilen själv använder i sitt GUI. Det är därför det finns en meny längst ner i vardera hörn, samt när det behövs, även en i mitten. Vid val av olika program eller mappar så har mobilen en lista med ikoner för de man kan välja utav. Vårt Inventoryfungerar också på detta sätt när man navigerar sig bland sina föremål. 4.3 Utvecklingen av GUI:it Sida 15 av 24

Figur 1: Spelets karta. Sida 16 av 24

Figur 2: Spelets inventory. Sida 17 av 24

5 Server & Modell Servern är skriven i java och har körts på en gamma skruttig dator hos Andreas... Servern har tagit upp mest av våran tid eftersom modellen ligger därpå och vi har sådeless lagt det mesta av logiken däri... och för att det inte ska gå att lura... 5.1 Struktur Först beslutade vi att... Sida 18 av 24

6 Positionering 6.1 Problem 6.1.1 Diffar på upp till 25 m Eftersom agps har begränsad... Behandling 6.1.2 Lång laddningstid efter förlorad kontakt med satellit Men sen får man uppdateringar varje sekund Behandling 6.1.3 Radioskugga Radoiskugga är att inomhus eller blockerat av något får man ingen signal... Detta innebar... Radioskugga får vi då vår gps inte kan kommunicera med tillräckligt många sateliter för att med säkerhet kunna fastställa vår position. Detta sker oftast inomhus eller då vi utomhus är omgivna objekt som skymmer signalen. Behandling Vi designade spelet kring denna premiss... 6.1.4 Representation Att det systemet ger oss är latituder och longituder innebar att... Behandling Lösningen blev att via... Sida 19 av 24

7 Diskussion Fördelarna med en positionsbasserad spelupplevelse... Fördelarna med vår produktion... Nackdelarna med en positionsbasserad spelupplevelse... Nackdelarna med vår process... Hur väl vi nådde våra mål... Vad vi plockar med oss från projektet... Sida 20 av 24

8 Bibliografi Referenser [1] Lundgen. S., (2006) Facets of Fun: On the Design of Computer Augmented Entertainment Artifacts. ss. 145-152. Göteborg: Chalmers tekniska högskola. (Licenciatarbete inom Department of Computer Science and Engineering). Sida 21 av 24

9 Ordlista MMORPG - Massive Multiplayer Online Role Playing Game, Spel där flera spelare via internet kan samverka i en konstant värld. agps - accelererad Global Positioning System - System för att med hjälp av satelliter och datakommunikation få fram koordinater för vart i världen man är. Java - Serverdelen av projektet är kodat i Java SE. Python - Kliendelen av projektet är kodat i Python 2.3. Netbeans - En kodeditor. svn - Subvertion, ett versions hanterings system som möjligöra att flera hanterar koden samtidigt. GUI - Grafical User Interface Nätverksprotokoll - En konvention för hur information skickas över ett nätverk. Symbian S60 - Operativsystem och programpaket för mobiltelefoner. Sida 22 av 24

A Användardokumentation A.1 Introduktion A.2 Tutorial A.3 Användarmanual Till detta arbete medföljer följande bilagor: Koden i en ZIPfil Rapport över induviduellt arbete Manual Sida 23 av 24

B Systemdokumentation B.1 Kravdokument B.2 Systemspecifikation B.3 Detaljerad systemspecifikation B.4 Modul- och underprogram/metodspecifikationer B.5 Kvar att implementera Sida 24 av 24

C Utvecklingsdokumentation C.1 Dagbok C.2 Tidsplaner C.3 Slutsatser om kandidatarbetet C.4 Slutsatser om uppgiften Sida 25 av 24