Kungliga tekniska högskolan. Projektrapport Spelet Graffiti Wars

Storlek: px
Starta visningen från sidan:

Download "Kungliga tekniska högskolan. Projektrapport Spelet Graffiti Wars"

Transkript

1 Kungliga tekniska högskolan Projektrapport Spelet Graffiti Wars Grupp 6, DP09, VT2010

2

3 Projektrapport TEMA: TITEL: GRUPP: 6 HEMSIDA: DELTAGARE: HANDLEDARE: Datortekniskt projekt 7,5hp Graffiti Wars Mikael Berg Fan Ding Oskar Lind Robin Lindahl DATUM: 19 maj 2010 Anders Lindström, EXAMINATOR: Anders Lindström,

4

5 Sammanfattning I kursen HI1010 Datortekniskt projekt våren 2010 fick en grupp bestående av Mikael Berg, Fan Ding, Oskar Lind och Robin Lindahl i uppdrag av kunden Johnny Panrike att utvecka en produkt. Gruppen fick ett antal riktlinjer och krav för godkänt betyg att utgå ifrån, bland annat att produkten skulle vara en nätverksapplikation enligt klient-server-modell, att ett applikationsnivåprotokoll för nätverkskommunikationen skulle upprättas, samt att koden skulle vara skriven i programspråket C och vara välskriven och väldokumenterad. Gruppen genomförde en faktainsamling utifrån kraven på projektet. Därefter upprättades en kravspecifikation och problemformulering i samband med kunden Johnny Panrike och projekthandledaren Anders Lindström. Ett kommunikationsprotokoll och en genomarbetad moduldesign utformades, som sedan implementerades med hjälp av de metoder som gruppen valt för projektet. Med hjälp av bland annat versionshantering, ett programmeringsbibliotek för plattformsoberoende och användande av parallell programmering, etablerades en god grund för projektets genomförande som även kunde uppfylla de tekniska kraven. Resultatet blev ett spel som fick namnet Graffiti Wars. Det utspelar sig i 2D-miljö, och går ut på att tagga, d.v.s. måla sin egen symbol, på olika mål med andra medspelare samtidigt i bild. Varje spelare har en egen symbol och kan klottra över andras målningar. Under en tidsomgång på ca. 2 minuter ska spelaren försöka måla sin symbol på så hög andel av målen som möjligt. När spelomgången är slut jämförs spelarnas andelar och den som fått högst andel vinner. Spelet drivs med hjälp av en server som kan hantera upp till 4 st. klienter samtidigt. Klienten kan köras i både Linux- och Windowsmiljö. Nyckelord: SDL, SVN, Kodorganisering, Moduler, Header-filer, IDE, Versionshantering, Nätverk, C, Programmering.

6 Abstract In the course HI1010 Computer Engineering Project (Datortekniskt projekt) in spring 2010, a group consisting of Mikael Berg, Fan Ding, Oskar Lind and Robin Lindahl was assigned the task of developing a software product, by the customer Johnny Panrike. The group was given a number of guidelines and course goals, for example that the product had to have networking capabilities according to a client-server-model, that an application level protocol had to be established, and that the code was to be written in the programming language C. The group gathered facts around the subjects that had to be researched for the project. After that, a specification was produced in cooperation with the client, Johnny Panrike, and the course supervisor, Anders Lindström. A communications protocol and a very thorough module design document was produced, which then was implemented according to the methods which the group had chosen for the project. With the help of, for example, version control, a common platform-independent programming library and the use of parallel programming, a solid foundation for the project had been set that would also meet the technical demands for the software. The result was a game called Graffiti Wars. Set in a 2D-environment, the objective is to spray your tag over as many targets as possible, competing against up to four other players, showed on the screen in real time. Each player has its own tag and can paint over other players' tags, if the target has already been painted on. During the game session time of 2 minutes, the objective is to have your tag sprayed over as many targets as possible by the end of the game session. The player that has the highest share of targets when time is up wins. The game is run by a server that can handle up to 4 clients at the same time. The client can be run both in a Linux and Windows environment. Keywords: SDL, SVN, Modules, Header-files, IDE, Version Control, Network, C, Programming.

7 Förord Arbetet i projektet har fungerat bra i samtliga faser. Efter en relativt lång analysfas, då gruppen även utformade en detaljerat moduldesign, kunde problemen lösas all eftersom projektet fortskred. För att kunna tillgodogöra sig rapporten på ett tillfredsställande sätt bör läsaren ha vissa förkunskaper i programmering och nätverksteknik. De kodexempel som visas är, om inget annat anges, skrivna i C. Projektet är utfört i kursen Datatekniskt projekt i årskurs 1 på programmet Datorteknik med inriktning Program- och systemutveckling, KTH Teknik och Hälsa. Vi vill tacka Anders Lindström som varit vår handledare. Projektgrupp 6 KTH Teknik och Hälsa, Campus Haninge 2010/05/19 Mikael Berg Fan Ding Oskar Lind Robin Lindahl

8

9

10 Innehåll 1 Inledning Problemdefinition Mål Lösningsmetoder Avgränsning Om spelet Teoretisk referensram Arbetsmetod Programspråk Versionshantering Kodorganisering Utvecklingsverktyg (IDE) Plattformsoberoende Grafik Parallell programmering Nätverksprogrammering Händelsehantering Testning Arbetsmetoder och kodorganisering Plattformsskillnader Versionshantering Utvecklingsverktyg Kodorganisering Pekare Structar Testning Nätverkskommunikation Implementering i klient och server Nätverksbelastning Informationsutbyte Server Parallell programmering Serverns uppgifter Felhantering och säkerhet Klient Moduler på klientsidan Grafik Transparens Animationer Filhantering Händelsehantering Spellogik Slutsats Projektarbetets fortskridande Framtida arbete / Saker som inte hanns med Ordförklaringar Referenser...37

11 Appendix A: Moduldesign...39 Appendix B: Kravspecifikation...43 Appendix C: Kommunikationsprotokoll...45 Appendix D: Användarmanual...49 Appendix E: Testning...53

12 1 Inledning I kursen Datatekniskt projekt våren 2010 ska grupp 6 utvecka en produkt utformad för en specifik kund, i detta fall Johnny Panrike. Gruppen kommer att utveckla ett spel som går under arbetsnamnet Graffiti Wars. Spelet går ut på att i ett sidoscrollande plattformsspel i 2D klottra på anslagstavlor med andra medspelare samtidigt i bild. 1.1 Problemdefinition En server behöver kunna hantera flera klienter samtidigt. Till detta kommer vi behöva använda oss av parallell programmering, och för kommunikationen även sockets. För att kunna åstadkomma ett gränssnitt med rörlig grafik behöver vi också sätta oss in i ett sådant bibliotek, samt bli bekanta med hur man åstadkommer bland annat en sidoscrollande värld och kollisionshantering mellan objekt. Det är tänkt att alla objekt på banorna ska kunna initieras på olika positioner beroende på vad som läses in från en textfil. För att få till detta behöver gruppen tillämpa filhantering. Spelkontrollen kommer först och främst att involvera tangentbordstryckningar, men på sikt även musrörelser. Händelsehantering behövs i koden, för att applikationen ska utföra något när användaren trycker på en knapp. Vi behöver på något sätt också dela upp vår kod i överskådliga funktioner i sammanlänkade moduler, ha rikligt med kommentarer och se till att alla kan arbeta med samma kod utan att förstöra för varandra eller skriva över en lösning som kanske fungerade tidigare. 1.2 Mål Punkterna i kravspecifikationen kan anses uppnådda när vi uppnått följande mål: En server, körandes på en Linuxdator, ska genom parallell programmering kunna ta emot anslutningar från fyra klienter och starta upp en spelomgång. Försöker ytterligare en klient ansluta ska denna kopplas ned. När en spelande klient avslutar ska dess resurser på servern frigöras. Klienter ska gå att starta på både Windows- och Linuxdatorer, och ska kunna hantera och rita upp upp till fyra spelare samtidigt. Det grafiska gränssnittet ska bestå av en bakgrund, varpå rörliga spelare i form av rektanglar kan förflytta sig. Andra rektanglar, spelets måltavlor, ska kunna byta färg efter att spelare varit framme och klottrat på dem. Klottring ska ske, som minst, genom att spelare åker fram till en måltavla och trycker på en tangent. För högre betyg krävs att klottring sker genom att utföra rörelser med musen. Förflyttning i x-led ska ske med hjälp av piltangenterna. För högre betyg ska även hopp, förflyttning i y-led, kunna ske genom tangenttryck. Grafiken kan utvecklas till att tillåta sidoscrollning. När en spelare rör sig ut till kanten av 1(57)

13 skärmen så ska vyn ändras, så att varje spelare får en individuell vy av ett större landskap. Spelegenskaper ska kunna förändras genom att spelare plockar upp ett föremål, en så kallad powerup. Till exempel ska spelare på så vis kunna få ökad åkhastighet. Objektens positioner på banorna ska kunna regleras genom inläsning från separata textfiler, som användare lätt kan gå in och ändra. Både server- och klientapplikationen ska ha inbyggd felhantering, så att klienter kopplas ned och avslutas utan fel efter avslutad spelomgång, och att resurser frigörs på servern om en klient kraschar. 1.3 Lösningsmetoder Gruppen behöver ha ett system för att inte skriva över varandras kod. Versionshantering är ett sätt att uppnå detta, och det finns lite olika tekniker att välja mellan. SVN är en sådan metod, men det finns även alternativ som CVS, BZR och Git. Det behövs ett sätt för att kunna dela upp kod i flera moduler. Header-filer är en metod för att uppnå just detta. Filerna kommer behöva länkas samman för att känna till varandra. Detta går att åstadkomma med manuella make-kommandon, eller automatiserat i en utvecklingsmiljö. Parallell programmering behövs för att servern ska kunna hantera flera klienter samtidigt. Här kan man använda antingen trådar eller barnprocesser. Windows och Linux åstadkommer dessa saker på olika sätt, och det kan vara värt att använda ett plattformsoberoendebibliotek som till exempel SDL. Ett grafikbibliotek behövs för att rita upp ett gränssnitt. Ett välkänt sådant är OpenGL, ett annat finns inbyggt i SDL. Ett bibliotek som kan hantera tangentbordstryckningar och musrörelser behövs. Även sådana funktioner finns i SDL. Data kommer att skickas över nätverket i någon form av paket och genom sockets. Alternativ som finns här är UDP- och TCP-paket, samt sockets genom Socket.h, IO::Socket eller SDL_net. För att beslut ska kunna fattas kring vilka tekniker som lämpar sig bäst för vårt ändamål kommer faktainsamling behöva göras inom respektive område. Sökning kommer framförallt att ske på Internet, men kan även innefatta litteratur från KTH:s bibliotek. 1.4 Avgränsning Gruppen ska inte använda sig av 3D-grafik, utan endast 2D med hjälp av OpenGL Servern ska inte byggas för att kunna hantera fler klienter än fyra samtidigt Det ska endast gå att måla spelarens specifika bild, inte olika bilder för varje tillfälle Data ska inte överföras på XML-format utan istället som textsträngar Klienten behöver inte ha stöd för andra plattformar än Linux och Windows Det kommer inte att finnas chattfunktion under själva spelomgången 2(57)

14 2 Om spelet Illustration 1: In-game sekvens Graffiti Wars Spelet går ut på att rivaliserande spelare strider om att ta över ett så stort revir som möjligt med sin grafitti. Karaktärerna är representanter från olika klaner inom den undre världen, som kämpar för att sprida sitt rykte genom att klottra sina respektive tags på alla platser de kan tänka sig. Det här gör de för att uppnå status och därmed respekt gentemot varandra. Då klottrandet är en ständig kamp mot klockan och den jagande poliskåren, tar sig karaktärerna i huvudsak fram snabbt med hjälp av inlines. En spelomgång börjar med att upp till fyra spelare äntrar banan. En nedräkning från 100 sekunder startas, och under den tiden har spelarna som uppgift att klottra på så många objekt som möjligt (se Illustration 1: In-game sekvens Graffiti Wars). Det är också möjligt att klottra där någon annan tidigare klottrat, och därmed måla över den spelarens konst. När nedräkningen nått sitt slut äntrar polisen scenen, varpå spelet tar slut och karaktärerna flyr fältet. Den spelare som klottrat på flest objekt går vinnande ur striden. Karaktärerna förflyttar sig i sidled med hjälp av piltangenterna eller A- och D-tangenterna och har också möjlighet att hoppa med space-tangent. När spelaren kommer fram till ett objekt som han eller hon vill klottra på trycks vänster musknapp ned, varpå en instruktion kommer att dyka upp på skärmen om i vilken riktning spelaren ska röra musen (åt vänster eller åt höger), hela tiden med musknappen nedtryckt. Att klottra en tag kostar tre sprayburkar. Spelaren har från början tillgång till tio sprayburkar, och kan fylla på sitt förråd genom att åka och hämta påfyllning. Spelaren kommer ha möjlighet att åka och hämta så kallade power-ups, som kan vara utplacerade på 3(57)

15 mer eller mindre svårtillgängliga platser, t.ex. genom att hoppa upp längs flera plattformar. Exempel på power-ups kan vara att spelaren under en tid får ökad åkhastighet eller påfyllning av sprayburkar. 4(57)

16 3 Teoretisk referensram Här presenteras de teoretiska ramar som användes för projektet. Inledningsvis genomfördes en faktainsamling som gav stöd åt besluten om vilka metoder som skulle användas. En del av ramarna för projektet var givna i förväg, såsom att applikationen skulle vara nätverksbaserad, innehålla ett grafiskt gränssnitt och andra krav för betygsnivån som gruppen avsedde att nå. Andra begränsningar och metoder valdes av gruppmedlemmarna själva för att kunna åstadkomma extra funktionalitet eller förenklingar i arbetet. 3.1 Arbetsmetod För att kunna effektivisera samarbete i grupp skall en arbetsmetod väljas innan projektet sätts igång. Det som gäller i programutvecklingen hade vi inte så många alternativ att välja bland. Vattenfallsmodellen och iterativ utveckling är de två främsta arbetsmetoder att välja bland. Med vattenfallsmodellen arbetar man fas efter fas, i efterhand kommer man inte kunna gå tillbaka till en fas som redan är avslutad. Med iterativ utveckling menas att en fas repeteras flera gånger tills man blir nöjd. Denna arbetssätt är mycket väl anpassad i utveckling av programvara. Testkörning sker efter varje ändring av koden för att se till att den verkligen fungerar som tänkt. Vid missnöje kommer koden att ändras och testköras igen, tills man blir nöjd. Den agila utvecklingsmetoden är väl anpassad för mjukvarautveckling. Med denna metod blir utvecklingsprocessen lättrörlig. Scrum och Xtreme Programming är två välkända agila utvecklingsmetoder. För att förkorta utvecklingstiden fokuserar man på kommunikationen mellan utvecklare och beställare, och lägger upp mindre uppdateringar ofta. Istället för att följa den klassiska vattenfallsmodellen där man betar av fas för fas, skulle gruppen använda sig av en mer iterativ arbetsprocess, enligt Xtreme Programming-modellen. Det här innebar bland annat att vi skulle köra testning av programmets moduler löpande, allt eftersom de skrevs. Vidare skulle även faktainsamling att ske vid behov under hela projekttiden. Demonstration av produkten skedde för beställare även innan den var färdigställd, för att stämma av om arbetet fortskridit i rätt riktning. Tanken var att bygga upp programmet av ett antal mindre enheter, moduler, för vilka minst en gruppmedlem skulle ansvara men där det var önskvärt att minst ytterligare en medlem ger kommentarer eller testkör modulen. Det kom så småningom att bli så att gruppmedlemmarna sällan ensamma burit ansvar för enstaka moduler, utan inledningsvis delades de två största modulerna upp på två personer var, och sedan gjordes enskilda insatser för att implementera funktioner i de båda. Även i funktionsimplementeringen har det i stor utsträckning handlat om parprogrammering; med en person som skrivit koden och en person som varit med och hjälpt till att lösa problemet. I många fall har det här säkert inte varit det mest effektiva sättet att arbeta, men det har resulterat i att det ofta funnits åtminstone två personer som varit insatta i hur en funktion eller modul fungerar. Beträffande löpande testning, så har sådan inte skett för varje enskild funktion i särskilt stor skala, då man, kanske lite väl naivt, konstaterat att funktionen inte ska kunna ge upphov till så många fel så länge den anropas med rätt data. Det byggdes sällan hela testmoduler för att testa just färdigskrivna 5(57)

17 moduler; utom i fallet då vi skrev kommunikationsdelen hos servern och samtidigt skrev en testklient som skickade hårdkodade strängar. Arbetet har ändock skett i en iterativ process där modulerna byggts på med små delar i taget, och där man provkört för att se om allt fungerat som avsett innan ytterligare funktionalitet byggts på. Det har då ofta handlat om att koppla upp sig mot servern med flera klienter samtidigt, för att säkerställa att allt fortfarande fungerar. 3.2 Programspråk Det finns många olika programspråk, bland annat C, C++ och Java. Ett av dessa språk kommer att användas för programmeringen av spelet. När vi programmerar i C behöver vi inte undra om det finns något operativsystem som inte kan köra på. Den andra fördelen med C är att C är lätt tillämplig, d.v.s. språket abstraktionsnivå är lagom och lätt att acceptera. Abstraktion inom programmeringen innebär att det finns bara en del information att presentera och resten döljer sig. Det enklaste exempel att bevisa detta är siffror och funktioner som används både i C och matematik. T.ex. siffra 3 kan beskriva en mängd av en vara, men endast siffran 3 har inga motsvarande föremål i verkligheten. Det är samma princip när det gäller funktioner. I Stardard C ingår inga grafikritande bibliotek som vi kan användas oss utav, utan vi var tvungna att söka andra tekniker att förverkliga vårt spel med. Tack vare C:s popularitet och bidrag från andra programmare, har vi möjlighet att välja biblioteke såsom SDL, OpenGL m.fl 1. Mer om dessa bibliotek beskrivs i nedanstående avsnitt. Den största skillnaden mellan C och Objektorienterad programspråk (förkortas som OO-programspråk i nedanstående text) är att det går inte att implementera klasser och arv i C. Vid utveckling av stora programvara, har det stor betydelse att programmera objektorienterad. M.h.a arv i OO-programspråk ger möjligheter att återanvända ytterligare mer kod än vad modulerna kan göra, och ger ännu bättre programstruktur. Om vi jämföra tidsfördelningen, att programera med OO-programspråk innebär att programmaren ägna sig mer tid åt att designa programmet och lägga till mindre tid i kodning och implementation. Sammanfattningsvis kan vi konstatera att OO-progarmspråk som Java är bättre anpassad till större projekt, särskilt för utveckling av nätverkbaserad dataspel 2. Projektet genomfördes med hjälp av programspråket C, uppdelat i moduler med hjälp av header-filer och tillhörande.c-filer. Mer om implementationen nämns i kap 4.4, 4.5, 4.6 samt kap. 7 och Appendix 1 och Versionshantering Vid utveckling av programvara i form av grupp, är det ibland nödvändigt att flera gruppmedlemmar ändrar i samma fil samtidigt. Det blir annars svårt att organisera koden om bidragen från alla är lika viktiga. Ett versionshanteringssystem löser problemen som uppstår när flera arbetar med samma fil/filer. 1 Wikipedia: 2 Wikipedia: 6(57)

18 Gruppmedlemmar måste först ta reda på om det finns nya uppdateringar av koden innan man göra ändringar i den. Ett problem som med versionshanteringssystem generellt är att den föregående versionen av filen, vid omedveten uppläggning, skrivs över. Det finns huvudsakligen två lösningsmetoder till detta problem: Lock - Modify Unlock Personen som laddar ner den senaste versionen av filen kan låsa samtidigt, för att börja göra ändringar. Andra gruppmedlemmar är då tvungna att vänta tills låsningen tas bort. Risken med denna lösning är att den personen som låste filen glömmer att ta bort blockeringen, vilket medför fördröjning av grupparbetet. Copy - Modify Merge Ett annat lösningsalternativ är att om två gruppmedlemmar laddar ner samma version av koden och gör ändringar, och sedan lägger upp varsin senaste version, kommer versionshanteringssystemet att fråga den användare som lagt upp sist, om koden från olika bidrag ska läggs ihop eller vilken del som skall behållas. Det är inte bara samarbetet i gruppen som underlättas av versionshantering, utan även möjligheterna att gå tillbaka till tidigare versioner av kod. Det finns mer än tio versionshanteringssystem att välja bland 3. Kravet för att kunna använda versionshantering är att man har tillgång till en server som ska kunna spara alla filändringarna och att alla gruppmedlemmar ska kunna använda det valda versionshanteringssystemet på sin programmeringsplattform. 3.4 Kodorganisering Till skillnaden från programmen som vi skrev i kursen Programmering Grundkurs, bedömer gruppen att kodmängden till detta projekt kommer att bli relativt stor. Den enklaste lösningen är att skriva all kod i samma fil, men på grund av kodmängden och med hänsyn till den valda iterativa arbetsmetoden kommer detta ej att vara praktiskt möjligt. En lösning för behovet av kodorganisering i C, är att bygga program i moduler med hjälp av headerfiler. Detta underlättar för programmaren när det gäller test och felsökning av enskilda moduler. Under utvecklingsprocessen sker testning i första hand separat, d.v.s. oberoende av andra moduler. Med välstrukturerade moduler ges dessutom en bra lättläslighet för alla. Det underlättar även i utvecklingsoch underhållsarbetet. I språket C utgörs header-filer av en fil med ändelsen.h. Till detta hör en.c-fil som innehåller själva implementationen av funktionerna som deklarerats i.h-filen. Ett exempel på en.h-fil (foo.h) är #ifndef _FOO_H #define _FOO_H #define FOO_BAR 42; int foo_bar(int x); #endif och en tillhörande c-fil (foo.c): #include "foo.h" int foo_bar(int x) { 3 Versionhantering (Wikipedia): 7(57)

19 return x*foo_bar; } 4. Med hjälp av denna struktur kan programmet enkelt byggas upp av moduler med deklarationimplementation. 3.5 Utvecklingsverktyg (IDE) En IDE (Integrated Development Environment) effektiviserar kodarbetet genom att tillhandahålla en enda gemensam miljö för att författa, modifiera, kompilera, implementera och felsöka kod. För att effektivisera kodningsarbete, är vanliga texteditorer inte längre ett alternativ. Åtminstone ett utvecklingsverktyg måste programmeraren vara bekant med. Det tar säkert tid, men det lönar sig långsiktigt. Syftet med att koda i utvecklingsverktyg är att programmeraren inte behöver ha koll på små grejer utan fokuserar på själva programdesignen och på att tänka logiskt. En av de mest grundläggande funktionerna är att programmet automatiskt ger förslag till structmedlemmar. Efter att programmeraren angett structens namn och punktnotation, listar utvecklingsverktyget ut samtliga medlemmar av structen. Programmeraren behöver inte bläddra i koden och får en bättre överblick. Utvecklingsverktyget markerar även icke-använda variabler och felaktiga notationer, och utför kodindentering automatisk. För gruppen är det självklart nödvändigt att välja ett IDE som kan hantera språket C. Då detta språk är väldigt vanligt i programmeringsvärlden finns det här många alternativ. Några är emellertid större och mer populära än andra, och gruppen har valt att fokusera på de som presenteras i föreläsningsanteckningen Utvecklingmiljöer.pdf av handledaren Anders Lindström. Dessa är: Netbeans (Open Source, GNU/LGPL, Eclipse (Eclipse Public License, Code::Blocks (GPL, Visual Studio (Microsoft, NetBeans IDE och Eclipse skiljer inte så mycket från varandra. Personer som är bekanta med den ena kan arbeta med den andra utan problem. Både Codeblocks och Visual Studio ger möjlighet att dölja kod (implementation) i funktionen. Det går då snabbare att bläddra till det kodstycke som man vill ändra i. Ett annat sätt för snabbåtkomst är att man välja funktioner direkt i funktionslistan. Med komplicerade algoritmer i ett stort program kan det vara tidsödande att hitta och rätta felen. Med hjälp av en inbyggd debugger kan programmet köras igenom rad för rad för att hitta felet. Med Visual Studio och andra IDE:s visas eventuella programmeringsfel direkt för programmeraren medan han/hon skriver koden. Det hjälper programmeraren att rätta felet under arbetets gång utan att få så mycket felmeddelanden efter kompileringen. Visual Studio har dessutom en inbyggd kompilator som utvecklades av Microsoft självständigt. Alla presenterade utvecklingsverktyg ger möjlighet att länka till bibliotek såsom SDL och OpenGL. Efter korrekt länkning med olika bibliotek går det att inkludera dessa i projektets källkodsfiler. Windows har ingen inbyggd kompilator och denna måste således installeras separat (detta gäller ej vid 4 Organisera kod (pdf) (Anders Lindström) 8(57)

20 användning av Visual Studio, som har inbyggd kompilator). För detta finns två gratisalternativ: MinGW (http://www.mingw.org) CygWin (http://www.cygwin.com) Linux levereras däremot med inbyggd kompilator och debugger. Däremot går det inte att köra Visual Studio naturligt i Linux. Avändare av detta operativsystem kan därför endast använda (utifrån ovan nämnda alternativ) Eclipse, Netbeans eller Codeblocks. I Linux används GCC som kompilator 5. Att programmera med olika IDE inom gruppen borde inte innebära några problem. Under faktainsamlingsfasen har emellertid vissa skillnader i hanteringen av biblioteken upptäckts, som t.ex. att sökvägen till biblioteken vid include-satserna är olika i Windows och Linux. För inkludering av t.ex. SDL-biblioteken skrivs i Linux #include <SDL/foo.h> och i Windows. #include <foo.h> 3.6 Plattformsoberoende Plattformsoberoende kommer, om möjligt, att användas så att spelet kan spelas med personer som har ett annat operativsystem. När det gäller plattformsoberoende så innebär det för detta projekt förenklat att spelet ska kunna köras på fler än ett operativsystem, såsom Windows, Linux eller Mac. Genom att välja ett multiplattformsbibliotek (eng. cross-platform ) vid programmeringen kan man få ett fungerade spel som kan spelas på olika datorer, utan att behöva kompilera om programmet för varje operativsystem. På engelska kallas detta cross-platform. SDL (Simple Direct Media Layer) är ett multiplattformsbibliotek skrivet i C, som tillhandahåller ett enkelt interface för interaktion mellan grafik, ljud, nätverk och andra i/o-enheter i en dator. SDL använder inbyggda funktioner för att interagera med t.ex. Direct X för grafik i Windows, Xlib i Linux och Quartz i MacOS X 6. Genom att använda SDL:s inbyggda funktioner kan alltså programmeraren enkelt använda sig av grafik, nätverk och annat i sin kod utan att behöva bekymra sig om kompatibilitetsproblem mellan plattformarna. De stora funktioner som kommer att behövas för projektet, som befaras vålla kompatibilitetsproblem om de inte hanteras med ett multiplattformsbibliotek, bedöms av gruppen vara grafiken och nätverksfunktionaliteten. Vid efterforskningar framgår att SDL innehåller funkioner för detta genom biblioteken SDL_net och SDL_image (se kap. 2.7 Grafik). SDL är uppdelat i olika system: Video (hanterar bilder och OpenGL), Audio (ljud), CD-ROM, Joystick och Timer. Dessa initieras automatiskt genom kommandot SDL_Init(SDL_INIT_EVERYTHING); 5 Utvecklingsmiljöer (pdf) (Anders Lindström) 6 Simple Directmedia Layer (Wikipedia): 9(57)

21 . Vid sidan av dessa system finns några standardbibliotek som ger extra funktionalitet. Dessa är SDL_image SDL_mixer SDL_net SDL_ttf SDL_rtf Då dessa ingår som standard i SDL finns god dokumentation kring funktionerna och många exempel på hur implementationen sker i C Grafik Grafik kommer att användas till spelet för underlätta för spelaren, så spelaren slipper se en massa text i en konsol. Spelet kommer att behöva ett grafiskt användargränssnitt (GUI), för att kunna visa var i spelet spelaren är, var måltavlorna är placerade och dessutom veta var motståndarna är. Det finns en del grafiska bibliotek, och två av dessa är SDL och OpenGL. SDL har dessutom stöd för att använda OpenGL grafik i SDL fönster, med hjälp utav ett bibliotek som heter SDL_OpenGL. 3.8 Parallell programmering Parallell programmering används för att program ska effektivare kunna utföra funktioner. Detta kommer att användas så att spelet kan utföra många fler saker samtidigt, som att rita ut spelare, förflytta spelare och liknande, utan att behöva göra så att spelet går långsammare. För att med ett och samma program kunna hantera flera sessioner samtidigt, som körs oberoende av varandra, krävs någon form av parallell programmering. Det går att låta huvudprocessen skapa barnprocesser för att hantera dessa parallella skeenden, eller använda sig av så kallade lättviktsprocesser; trådar. De senare delar på ett och samma minnesutrymme, och är därmed en mer effektiv lösning. Det här kommer framförallt vara nödvändigt för att låta flera klienter vara anslutna samtidigt till en och samma serverapplikation; vilket är ett krav för att flera datorer skall kunna spela med varandra. 3.9 Nätverksprogrammering Spelet ska ha möjligheten att spelas över ett nätverk. För detta krävs att gruppen gör ett val om vilket protokoll som ska användas, vilka bibliotek som ska användas för uppgiften samt hur det ska implementeras. I valet mellan nätverksprotokoll finns det två stora att välja emellan: TCP (Transmission Control Protocol) och UDP (User Datagram Protocol). För projektet är det viktigt att undersöka vilket av alternativen som passar bäst för varje enskild uppgift i nätverksöverföringen, och sedan ta ett beslut om vilken teknik som ska användas. Dock behöver inte samma protokoll användas för alla olika uppgifter, utan vissa paket kan skickas med en typ av protokoll och andra med något annat. Skillnaden mellan TCP och UDP är främst säkerheten och den hastighet med vilken paketen kan 7 Simple Directmedia Layer (Wikipedia): 10(57)

22 överföras. TCP har större header än UDP, som innehåller fält för att kunna kontrollera och verifiera paketen. Detta gör att en mindre mängd data får plats i själva paketet än när de skickas med UDP. En större mängd total data måste därför överföras med TCP för att skicka samma information. Därför är TCP långsammare än UDP i praktiken 8. UDP innehåller få eller inga kontrollfunktioner och paketen som skickas riskerar därför att tappas bort på vägen. Det kan därför vara lämpligt att använda detta protokoll för överföring av data som skickas i stora mängder, men inte är så känslig för om det tappas bort paket på vägen. När det gäller funktionalitet för nätverk inom C-programmering är det för gruppen aktuellt att undersöka vad som erbjuds för bibliotek som är plattformsoberoende. Eftersom gruppen valt att använda sig av SDL för många av de andra funktionerna inom projektet, är det lämpligt att främst hålla sig till SDL:s funktioner för nätverk. SDL:s nätverksfunktionalitet tillhandahålls genom biblioteket SDL_net 9. Om detta inte redan finns installerat på den plattform som kommer att användas för kodarbetet, måste detta installeras separat. När SDL_net sedan ska användas i koden måste biblioteket sedvanligt inkluderas och sedan initieras: #include "SDL_net.h" SDLNet_Init(); SDL_net används sedan på följande sätt på klientsidan för att skapa sockets och skicka data: SDLNet_ResolveHost(); // Tar in IP och portnr för att skapa nödvändig koppling till servern SDLNet_TCP_Open(); // Öppna en anslutning SDLNet_TCP_Send(); // Skicka TCP-paket över socket På serversidan krävs något ytterligare kod. Sammantaget lämpar sig SDL_net väl för det som gruppen vill åstadkomma när det gäller nätverksfunktionalitet Händelsehantering För projektet krävdes hantering av händelser såsom knapptryckningar, musrörelser och lyssnande efter flaggor som satts beroende på om något skulle inträffa eller inte. Eftersom gruppen valde att använda SDL för de flesta funktioner, fokuserades på SDL:s eget bibliotek för att hitta lösningar för händelsehanteringen. SDL har gott stöd för detta, bl.a. genom fullt internationellt keyboard support, inbyggda funktioner för att lyssna till tangenttryckningar, och flera funktioner för att tolka musrörelser och positioner. SDL:s eventhantering initieras enkelt med SDL_Init() Testning För att säkerställa att programvaran fungerar som den ska, och för att eliminera så många felaktigheter i koden som möjligt, krävdes tester av projektet. Alla delar av projektet kan testas med hjälp av White-box testing och Black-box testing. I Whitebox testing fokuseras på funktionella krav som t.ex. huruvida det går att manipulera servern genom att 8 Cisco Internetworking Technology Handbook: 9 SDL_net 1.2: 11(57)

23 skicka felaktiga data ( fault injection ), eller om man på något annat sätt kan ändra i en fungerande klient eller server så att den beter sig felaktigt ( mutation testing ). Black-box testing genomförs genom att testa icke-funktionella krav. Programmeraren kan t.ex. välja att skicka slumpdata över en socket till servern ( fuzz-testing ), testa gränser för olika aspekter i programmet ( boundary value analysis ) eller att hitta på tester baserat på hur programmet har satts ihop och vilka moduler som är lämpliga att testa (model based). Dessa tester kan utföras t.ex. med fokus på kommunikationen mellan projektets olika kodmoduler, kommunikationen mellan server-klient eller interaktionen människa-dator. 12(57)

24 4 Arbetsmetoder och kodorganisering För att projektet skulle kunna genomföras smidigt och effektivt rekommenderades gruppens medlemmar att använda sig av t.ex. versionshantering, utvecklingsverktyg och arbetssättet Extreme Programming. Vissa av metoderna presenterades initialt genom lärarledda föreläsningar, men en del av dem krävde mycket faktainsamling på egen hand. Givet var att applikationen skulle skrivas i C. Detta medförde att kodorganisering, utvecklingsverktyg och adresseringsmetoder med hjälp av till exempel pekare automatiskt kom i fokus när faktainsamlingen kring arbetsmetoder och kodorganisering skulle börja. Structar och pekare uppfattades som en naturlig ingrediens i språket C och information var lätt att hitta. Metoder för testning introducerades av Johnny Panrike på en föreläsning , och versionshantering av Mårten Palm Plattformsskillnader Grupp #6 valde att använda SDL för att åstadkomma bland annat händelsehantering, trådar och nätverksfunktionalitet som fungerar i både Windows- och Linuxmiljö. Detta för att slippa behöva koda specifika moduler för respektive plattform, då vissa andra etablerade systemanrop som C använder sig av skiljer sig mellan de två operativsystemen. Trots att gruppen arbetat i olika operativsystem har så gott som all kod vi skrivit fungerat på både Windows och Linux. Det här har vi programspråket C och bra kompilatorer att tacka för, men också biblioteket SDL som helt befriat oss från att sätta oss in i skillnader mellan systemen. Den huvudsakliga anledningen till att vi tänkte använda SDL från början var för att hitta en plattformsoberoende metod för att åstadkomma parallell programmering med trådar. Det har sedan visat sig att vi bara kom att använda trådar på serversidan, på vilken vi endast hade plattformskravet Linux. Då serverapplikationen skrevs med hjälp av SDL så fick vi dock av bara farten en applikation som även gick att köra felfritt under Windows, vilket visat sig vara väldigt praktiskt vid individuell testning av klienten man arbetar på. När vi använde SDL stötte vi på omdirigering av STDOUT och STDERR, så att alla våra printf-satser skrevs till textfiler istället för till terminalen. Då detta inte var önskvärt i vår applikation, bland annat för felsökningens skull, var vi tvungna att dirigera tillbaka utskriften till skärmen igen. Det här visade sig vara krångligt att få till, speciellt på ett sätt som fungerade i både Windows och Linux. Till slut hittade vi satsen freopen( CON, "w", stdout). I Linux fungerade det dock inte att skriva CON som sträng, utan där skulle istället stå NULL. Problemet löste vi genom att i början av koden, eller närmare bestämt i våra headerfiler, skriva: #ifdef linux #define CON NULL #else //#ifdef _WIN32 #define CON "CON" #endif Något som vi också vara tvungna att ta ställning till var hur vi skulle skicka data mellan servern och klienten. Hade vi valt att skicka binär data hade detta fungerat annorlunda för Windows och Linux, så vi valde istället att skicka all data som strängar. Så länge strängarna initierats på rätt sätt på båda sidor, och rätt längd skickats och tagits emot, så har det fungerat felfritt. 13(57)

25 En omfattande skillnad som drabbade gruppens Linuxanvändare och till allas vår förvirring orsakade ett Socket-felmeddelande varje gång klienten startades, berodde på att vi råkat namnge en av våra funktioner till samma sak som ett systemkommando: connect(). I Linuxmiljö drabbades vi också då och då av diverse Segmentation Faults. Dessa visade sig bero på en så enkel sak som att filnamnen ibland innehöll versaler, medan kod inte gjorde det, eller vice versa. Vi fick också vid ett tillfälle uppleva hur Linux dödade processen för att den började ta upp för mycket minne. Allt vi fick som felmeddelande var att processen efter en viss tid försökte köra pthread_cancel(), utan att lyckas. Till slut lyckades vi identifiera att det handlade om en minnesläcka, som vi snabbt täppte till. När vi skulle använda funktionen getch() i biblioteket <conio.h> kunde vi enkelt inkludera detta bibliotek i Windows, där det fanns inbyggt, men var i Linux tvungna att först installera det manuellt. 4.2 Versionshantering För att kunna återgå till äldre upplagor av kodade moduler och för att lätt kunna hantera när flera medlemmar gör ändringar i samma fil bestämde vi oss tidigt för att använda ett versionshanteringssystem. Verktyget vi valde heter Subversion vilket stödjer både Windows och Linux. Grupp #6 har tillgång till en SVN-server där all kod kommer att sparas. Gruppmedlemmarna kan därmed inte lägga upp sina filändringar utan att först ta ställning till uppdateringar som andra har gjort. Gruppen använde sig av versionshantering i stor utsträckning, framförallt för att snabbt och lätt kunna hämta hem de senaste versionerna av samtliga moduler och headerfiler, men också i många fall för att sätta ihop förändringar som flera användare gjort i samma fil. I vår grupp använde vi Subversion, SVN, genom verktygen Tortoise SVN (i Windows) och Rabbit VCS (i Linux). Vi var hela tiden flitiga med att ladda upp ändringar så att övriga i gruppen kunde ta del av dem, vilket förstås ofta också ledde till så kallade konflikter. Trots en del lite nervösa försök att pussla ihop ändringar som skett på flera ställen i en fil så fick vi faktiskt aldrig problem med att någon fil inte fungerade efteråt. Annars fanns alltid tryggheten i att kunna gå tillbaka till det omtalade stadiet: men det fungerade ju igår. SVN visade sig vara en räddare i nöden då vi dagen innan inlämning plötsligt sprang på helt oförklarliga problem med vårt program. Då vi inte alls kunde identifera vilken av dagens ändringar som åstadkommit dessa fel vilka framförallt bestod i att spelet grafik hackade och att till exempel musrörelser inte registrerades valde vi vid dagens slut att gå tillbaka till den senast fungerande versionen från dagen före. Det här var mycket smidigt att åstadkomma genom SVN, som utan tvekan ett smidigt verktyg som vi hade haft väldigt svårt att klara oss utan. 4.3 Utvecklingsverktyg För att framförallt underlätta kodarbetet, men också för att lätt hantera länkning mellan header- och källkodsfiler, uppmuntrades samtliga gruppmedlemmar använda sig av en valfri utvecklingsmiljö. I gruppen har många integrerade utvecklingsmiljöer använts, som alla vållade gruppmedlemmarna problem som antingen ledde till otaliga konfigurationer av fillänkningen eller att utvecklingsmiljön helt sonika övergavs till förmån för en annan. I gruppen har vi haft en gruppmedlem som arbetat i Ubuntu Linux. Övriga har kört Windows i 14(57)

26 variationerna XP, Vista och 7. I Linux har Eclipse, efter att ha ersatt NetBeans, lyckats stå kvar som en relativt stadig, men inte helt problemfri, utvecklingsmiljö in i det sista. Windows 7-datorn körde frivilligt Microsofts utvecklingsmiljö från början, medan de två andra tvingades söka sig till sin bundsförvant Visual Studio den hårda vägen. Av någon anledning som vi inte lyckades identifiera så ville applikationen inte rita ut mer än en spelare på skärmen när vi körde fungerande Visual Studio-kod i Code::Blocks och Eclipse med MinGW. Inga felmeddelanden under kompilering eller körning, men ändå oönskat resultat. Det är dock inte möjligt för oss att vara helt säkra på att felet ligger i varken utvecklingsmiljön eller kompilatorn, utan det kan lika gärna ha varit en konfigurationsmiss eller att koden vi skrivit kunde ha varit bättre. Under större delen av projektet har det dock fungerat bra att alla gruppmedlemmar använt olika konfigurationer, vilket resulterat i kod som går att bygga och köra (nästan) oberoende av utvecklingsmiljö och operativsystem. Samma kod gick i varje fall att köra både i konfigurationen Windows + Visual Studio och Linux + Eclipse. En sak som skiljde mellan Visual Studio och övriga utvecklingsmiljöer var att sökvägen till vissa bibliotek såg annorlunda ut. I Visual Studio var sökvägen till SDL.h helt enkelt <SDL.h>, medan den i övriga utvecklingsmiljöer var <SDL/SDL.h>. Det här problemet löste vi genom följande kodsnutt i början av våra filer: #ifdef _MSC_VER #include <SDL.h> #else #include <SDL/SDL.h> #endif 4.4 Kodorganisering För att beskriva vad en implementerad modul i slutändan ska innehålla kommer så kallade headerfiler(.h) att användas. En header fungerar som en ritning och beskriver vilka variabler och funktioner en modul måste innehålla, tillsammans med omfattande kommentarer. Alla ovannämnda utvecklingsverktyg stödjer att skapa projekt. Moduler och headerfiler läggs in i samma projekt. Till varje källkodsfil (.c) filen finns det alltid en motsvarande headerfil (.h). Headerfilen innehåller inte mer än konstanter, variabler, deklaration av struct och funktionsprototyper. Vid läsning av headerfilen kunna läsaren få reda på vad motsvarande källkodsfilen innehåller. Gruppen satte i stort sett inte igång med det grova kodarbetet förrän en i alla fall preliminär moduldesign fanns. Den här bestod framförallt i att dela upp programmet i en server- och en klientapplikation, och att sedan ha flera mindre moduler för att bygga upp respektive applikation. Ett problem som gruppen dragits med är att de två största modulerna på både klient- och serversidan tenderade att växa till sig närmast okontrollerat. Det här har inte inneburit problem för själva applikationen, men har gjort att det tagit onödigt lång tid att hitta rätt i koden. Dessutom är det en dålig idé att uteslutande använda sig av globala variabler, vilket vi i stort sett gjorde överallt inledningsvis. Ett grepp togs för att omorganisera koden till mindre funktioner med lokala variabler som skickas dem emellan, ofta med hjälp av pekare. 15(57)

27 4.5 Pekare Trots att vi hade en omfattande modul- och funktionsdesign så räckte den inte riktigt till. Att inte specificera parametrar eller argument för de olika funktionerna, samt vilka lokala variabler de skulle ha, ledde till slarv i form av en stor mängd globala variabler (vilket kanske inte alltid är så bra när man använder sig av flera moduler, där flera moduler kan ha variabler med samma namn). Med globala variabler gör man det lätt för sig, då funktioner inte behöver ta några argument alls utan direkt kan gå in och göra ändringar i alla variabler de vill. Ett alternativ är att ha vanliga funktioner, av till exempel typen int, som vid anrop returnerar ett heltal efter att ha gjort någon form av beräkning. Det här fungerar emellertid inte när en funktion behöver ändra i flera variabler samtidigt, eller i en array, eller flera arrayer. Istället får funktionen som parameter då ta emot en pekare till önskad variabels adress, till vilken den sedan skriver ny data. 4.6 Structar För att på ett praktiskt sätt kunna gruppera variabler som på något sätt hörde ihop använde vi oss av så kallade structar, något vi också kom i kontakt med genom vår första programmeringskurs i C. Ett logiskt sätt för att tänka ut när en struct kunde tyckas behövlig var att tänka i vilka objekt vi hade i spelet. Allra enklast var det att se att vi behövde en struct som innehöll egenskaperna som representerade en spelare; med bland annat dess position i x- och y-led samt dess bredd och höjd. Fler naturliga objekt som behövde structar var våra måltavlor, våra powerups och våra plattformar; helt enkelt allting som skulle ritas ut på skärmen. På serversidan använde vi en struct för att representera varje klient, där det ingick bland annat en TCPsocket för varje klient. Structar kan också vara användbara för att enkelt skicka över flera variabler som argument till en funktion. På klientsidan användes detta till viss del för att hålla reda på alla variabler som representerade en spelomgång, och som därmed alltid behövde skickas till spelets uppdateringscykel. 4.7 Testning Gruppen valde att utföra Black-box- och White-box-tester enbart på kommunikationen server-klient. Gruppen använde sig av Fuzz-testing, Boundary value analysis, Model based testing, Fault injection och Mutation testing. Testerna utfördes i tre faser: 1. Test av klienten, kommunicerande med en testserver 2. Test av servern, kommunicerande med en testklient 3. Test av kommunikationen mellan servern och klienten Testerna dokumenterades under arbetets gång, med fokus på projektets slutfas då koden skulle till största delen vara färdigställd. TCPsocket för varje klient. 16(57)

28 5 Nätverkskommunikation I ett spel där det anses viktigt att ta emot skickad data i rätt följd och att data inte försvinner längs vägen blir TCP det naturliga valet, eftersom UDP inte kontrollerar vilka skickade paket som kommer fram eller inte, och därmed aldrig heller skickar om förlorade paket. Det här är inget som vi vill belasta vår applikation med, och förlitar oss därmed hellre på transportlagret och TCP. Innan vi satte igång och programmerade kommunikationsdelen skrevs ett kommunikationsprotokoll (se Appendix C: Kommunikationsprotokoll), där det i detalj framgick i vilken ordning data skulle skickas mellan server och klient. Tanken var från början att den viktigaste informationen skulle skickas via TCP, såsom information om vilken färg måltavlorna har och om en powerup försvunnit från spelplanen eller inte. Sådan information skulle också bara skickas vid behov; först efter att en flagga som skickas över TCP sätts till något annat än 0 skulle servern sedan göra sig redo för att ta emot den förväntade informationen. Oftast skulle då bara ett par TCP-flaggor, dels för att tala om om det fanns information att skicka, dels en exit-flagga som klienten kunde sätta vid avslut, skickas. Den här planen följdes också under implementeringen. Mindre viktig information, som varje spelares individuella positionsförändringar, skulle kunna skickas med UDP, eftersom det inte skulle vara viktigt att varje liten förändring kom fram. UDP-paket är, som vi lärde oss i kursen Datakommunikation, betydligt kortare bytemässigt än TCP-paket, som har mycket så kallad overhead, bitar som används för att hålla reda på bland annat sekvens- och kontrollinformation. Kommunikation över TCP blir därmed inte lika effektiv, eftersom det på varje mängd data också går en mängd kontrollinformation. Vid användning av UDP skulle ett sekvensnummer behöva läggas till i början av datan för att ens motspelare inte skulle få gamla positioner, men i övrigt skulle viss ryckighet vara okej ifall vissa positioner saknades under spelarens framfart. Den här tanken implementerades dock ej, utan spelarpositioner fick istället precis som den andra informationen också att skickas över TCP, i varje uppdateringscykel. Anledningen till det här var att vi valde att prioritera annan funktionalitet i spelet och att det inte riktigt kändes som det var nödvändigt med tanke på den ändå inte särskilt stora genomströmningen av trafik. 5.1 Implementering i klient och server För kommunikationen använde vi sockets från SDL_net, vilka var väldigt enkla att sätta sig in i, kanske speciellt efter att ha provat på sockets i språket Perl i kursen Operativsystem. Servern är byggd för att kunna ta emot nya anslutningar när en av dess fyra sockets är lediga, och att därefter bara skapa en tillfällig socket för att tala om för anslutande klienter att det är fullt, för att sedan genast koppla ner dessa. Länge var det möjligt för nya spelare att hoppa in mitt i spelet efter att gamla hoppat ut, men vi valde senare att för spelets skull sätta begränsningen att inga nya spelare ska kunna hoppa in mitt i en spelomgång. Efter att en spelomgång tagit slut, när timern på servern nått noll, så kommer servern starta om sig själv och koppla ner alla anslutna klienter (som förhoppningsvis redan hanterat spelets slut på ett lämpligt sätt) och döda alla trådar. Ytterligare felhantering på servern implementerades i projektets slutfas, bland annat för att hantera klienter som kraschat. Servern startas om efter en spelomgångs slut. Om en klient anslutit och sedan kraschat innan en spelomgång börjat, kan servern hantera detta. Om en klient kraschar mitt i en 17(57)

29 spelomgång kommer servern inte startas om förrän serverns spelomgångsklocka nått noll. Ytterligare felhantering skulle vara möjlig, bland annat skulle servern kanske behöva validera klienterna på något sätt, för att sätta stopp för att obehöriga klienter kopplar upp sig. 5.2 Nätverksbelastning Serverns huvudsakliga uppgift är att skicka information mellan klienterna. Inga beräkningar sker här, utan endast den information som anses vara nödvändig för att varje klient ska kunna rita ut alla spelare och föremål på rätt plats och med rätt egenskaper utbyts. Illustration 2: Nätverksbelastning, först då servern kör utan någon ansluten klient. Efter första höjningen har en klient anslutit och befinner sig i lobbyn. Vid andra ökningen så har spelaren startat spelet. Det hade varit möjligt att istället bygga spelet genom ett tyngre belastat nätverk, och mindre belastade, så kallade tunna klienter. Det här är relativt vanligt idag då nätverkskapaciteten ofta är god och då många användare har små lättviktiga datorer utan så mycket prestanda. Vi har valt att göra det omvända, och låta klienterna använda sin egen dators hårdvara för att hantera spelets logik och grafik. I efterhand kan det här valet definitivt diskuteras och omvärderas; då vi upplevt en del problem när vi kört applikationen på svagare maskiner. Det kan också tyckas som att man inte riktigt går hela vägen i att satsa på låg nätverksbelastning när man skickar all data med TCP-paket, utan UDP hade varit att föredra för en del information. 5.3 Informationsutbyte För kommunikation över TCP är det viktigt att den data som skickas och tas emot mellan servern och klienten gör så i exakt rätt ordning; så att det finns en motsvarande Receive-funktion på andra sidan, när en Send-funktion anropas på den ena. Det är förstås också viktigt att rätt längd anges på strängarna, så att varken mer eller mindre information skickas; då den annars kan komma att rinna över till andra strängar och orsaka oväntade resultat. I våra applikationer följer vi nedanstående ordning: 18(57)

30 Nr. Klienten Servern 1 Ta emot välkomstmeddeande/id-nummer Skicka välkomstmeddelande/id-nummer 2 Skicka hälsning Ta emot hälsning 3 Ta emot game timer Skicka game timer 4 Ta emot spelarstatus (ansluten/ej ansluten) Ta emot spelarstatus (ansluten/ej ansluten) 5 Skicka ytterligare data (om målade targets eller upplockade powerups) Ta emot ytterligare data (om målade targets eller upplockade powerups) 6 Ta emot targetfärger Skicka targetfärger 7 Ta emot powerupstatus (tagen/ej tagen) Skicka powerupstatus (tagen/ej tagen) 8 Skicka positioner för den egna spelaren Ta emot positioner för den egna spelaren 9 Ta emot positioner för samtliga spelare Skicka positioner för samtliga spelare 10 Skicka exitflagga (1 = avsluta, 0 = fortsätt) Ta emot exitflagga (1 = avsluta, 0 = fortsätt) Tabell 1: Informationsutbyte server klient. Efter att ny data tagits emot hos klienten kommer dess lokala arrayer och variabler att få nya värden, som sedan används till att rita upp aktuell grafik. Hos servern kommer globala arrayer att uppdateras, så att samtliga trådar kommer åt den nya informationen, för att kunna skicka den vidare till sina respektive klienter. Illustration 3: Ett urval av den data som servern växlat med klient 0. Utskriften kommer från serverns terminal. Observera att alla strängar som skickas inte står med här. 19(57)

31 20(57)

32 6 Server En Linux- och Windowskompatibel server konstruerades med hjälp av Parallell programmering för att kunna hantera flera klienter samtidigt genom s.k. separata trådar. Server-programvaran bestod av modulen ConnectionHandler, där funktionerna int handleclient(void *d); void restartserver(); int main(int argc, char **argv); fanns implementerade. Funktionen handleclient kördes av varje tråd för att hantera varje klient. Funktionen restartserver höll ordning på spelomgångarna och stängde ute eller släppte in klienter beroende på om en spelomgång kördes eller inte. Funktionen main lyssnade efter nya anslutningar och innehöll implementationer byggda på SDL:s nätverksbibliotek SDL_net. 6.1 Parallell programmering För att åstadkomma parallell programmering och tillåta flera funktioner att köras parallellt, och inte i en rak följd efter varandra med stora väntetider, valde vi att använda oss av trådar på serversidan. Där skulle varje tråd representera varsin ansluten klient, som den ständigt utbytte data med genom sockets. Trådarna har dels sina egna lokala variabler, men också några gemensamma arrayer som varje tråd sedan skickar i sin helhet till sina respektive klienter. Varje tråd skriver bara i sitt eget område i arrayen, och därmed var det aldrig nödvändigt att använda någon form av låsmekanism eller mutex. Trådar i SDL initierades med hjälp av funktionen SDL_CreateThread i biblioteket SDL_thread. För att hålla reda på när server var full implementerades funktionen med hjälp av en if-satsen if (clients[i].socket = SDLNet_TCP_Accept(server)){ clients[i].thread = SDL_CreateThread(handleClient,(void *) clients[i].id); clients[i].busy = 1; connections++; } där connections räknades upp för att matchas mot max-spelarantalet (i vårt fall 4 st). När klienten sedan skulle kopplas fri och avslutas användes SDL_KillThread: SDL_KillThread(clients[i].thread); 6.2 Serverns uppgifter Servern använder som bekant trådar för att hantera klienterna; en tråd för varje klient. En array av typen struct Client används för att hålla reda på alla klienter servern behandlar. Main-funktionen går ständigt igenom denna array för att se om det finns lediga platser kvar, och tillåter isåfall nya inkommande anslutningar så länge spelet inte har startats. När en ny anslutning upprättats kommer main-funktionen genast att initiera en post i klientarrayen; med ett lämpligt id-nummer, en egen TCP-socket och en busy-flagga som sätts till 1 medan platsen i arrayen fortfarande är tagen. Därpå skapas en tråd, som kommer att köra funktionen handleclient för att påbörja informationsutbytet. Funktionen kommer att få klientens id-nummer som parameter, och 21(57)

33 kan sedan använda denna för att läsa och skriva till rätt positioner i den globala klientarrayen. Efter att main-tråden initierat eventuella nya anslutningar, kommer den gå över till sin andra uppgift, nämligen att rensa upp bland de trådar som inte längre används. När en klient kört färdigt kommer den att sätta en flagga i klientarrayen, exitthread, till 1, vilket betyder att maintråden har fritt fram att ta bort klienten ur arrayen, stänga dess socket och döda dess tråd. Main-tråden fortsätter sedan att utföra dessa två uppgifter: att lyssna efter nya anslutningar samt att rensa upp och göra plats för nya. Om en klient skulle försöka ansluta medan servern är full kommer en tillfällig socket att skapas. Genast skickas ett meddelande till klienten om att servern är full, och välkommen att försöka igen senare, och sedan kopplas klienten och socketen ned. Samma socket kan även användas för att tala om att en spelomgång redan körts igång; vilket i praktiken betyder samma sak för klienten: var god försök igen senare. Servern kan bara hantera en spelomgång i taget. På servern finns förutom alla strängar som skickas fram och tillbaka mellan dess klienter även en timer, en klocka som håller reda på hur mycket som är kvar av en spelomgång. Normalt sätts denna till 100 sekunder. Main-tråden räknar ner denna timer, som sedan skickas vidare ut till varje klient genom deras respektive trådar och sockets. 6.3 Felhantering och säkerhet Enligt ovan har serverns main-tråd hand om att göra plats för nya klienter när tidigare anslutna kopplar ner. När klienten på sin sida av nätverket väljer att avsluta applikationen, kommer så inte att göras förrän en flagga skickats till servern om att klienten vill avsluta; vilket därmed även kommer få tråden på servern att hoppa ur sin loop och markera att den vill dödas av main-tråden genom att klientens exitthread-flagga sätts. På så vis kommer inga döda trådar att fortsätta köras på servern efter att klienten avslutat. Även efter att en spelomgångs timer nått noll kommer servern att rensa upp bland klienterna, genom anrop till funktionen restartserver(). Denna funktion anropas också så fort det inte längre finns några klienter anslutna till servern, för att snabbt göra plats för en helt ny spelomgång med helt nya klienter. Att klienten alltid avslutar på rätt sätt är förstås önskvärt, men i verkligheten kan man inte kallt räkna med att det alltid går som det ska. Därför behövs någon form av felhantering. Om klienten av någon anledning skickar paketen i fel ordning eller skickar paket av fel längd kommer servern att reagera genom att snabbt be den tråd som representerar klienten att hoppa ur sin loop och markera sig själv för att dödas. Den här felhanteringen är lätt att åstadkomma; då SDLNet_TCP_Recv och SDLNet_TCP_Send båda returnerar -1 om något går fel. 22(57)

34 7 Klient Klientdelen byggdes upp av en mängd header- och källkodsfiler. För att åstadkomma de funktioner som projektet krävde, användes metoder för plattformsoberoende, grafik, nätverk, filhantering och händelsehantering. Vissa av de metoder som först planerades ändrades eller byttes ut under arbetets gång, vilket kan sägas ha berott på arbetsmetodens iterativa process, där ändringarna utvärderades och testades alleftersom. T.ex. byttes metoden för grafik ut från ren OpenGL till SDL:s inbyggda funktioner för bildbehandling, eftersom de ansågs kunna tillgodose behoven för projektet trots SDL:s relativt begränsade möjligheter. 7.1 Moduler på klientsidan Följande moduler används på klientsidan: Implementation Client.c Communicate.c Game.c GameOver.c Graphics_SDL.c Lobby.c Obstacle.c Player.c Powerup.c Target.c Tabell 2: Moduler på klientsidan Header-fil Client.h Communicate.h Game.h GameOver.h Graphics.h Lobby.h Obstacle.h Player.h Powerup.h Target.h På klientsidan finns main-modulen Client.c, som först och främst använder sig av den stora modulen Game.c. Det här är en stor modul som innehåller en timer och en funktion som konstant lyssnar efter så kallade Events. Den viktigaste händelsen är den som kallas på av timern, nämligen spelets uppdateringscykel. Här sker kommunikationen med servern, samt all logik för att svara på den nya data som tagits emot. Resultatet ritas sedan ut på skärmen genom att kalla på funktioner i modulen Graphics. På klientsidan finns också de mindre modulerna Player, Target, Obstacle, Powerup och Map, som innehåller structar för att representera respektive objekt. Game.c använder funktioner i modulen Communicate.c för att skicka data till och ta emot data från servern. Här sker också själva anslutningen, nedkopplingen och allt som har med sockets och SDL_net att göra. På så vis skulle man i ett senare skede på ett transparent sätt kunna byta ut Communicatemodulen mot en annan, som till exempel använde sig av UDP istället för TCP. För att rita ut grafik kallar Game.c på modulen Graphics_SDL.c genom Graphics.h. Även här hade det varit möjligt att i ett senare skede byta ut grafikhanteringen, mot till exempel OpenGL. Förutom Game.c som sköter själva 23(57)

35 spelsessionen så finns även Lobby.c som har hand om uppstarten och uppkopplingen mot servern (genom Communicate.c) samt GameOver.c som har hand om att presentera resultatet. Var och en av dessa tre moduler har varsin egen händelsehanterare som svarar olika på knapptryckningar. 7.2 Grafik För att åstadkomma ett grafiskt gränssnitt underlättar det att använda sig av ett bibliotek med kraftfulla funktioner för just detta ändamål. Detta verkar finnas inbakat direkt i SDL, men fler möjligheter öppnar sig med biblioteket OpenGL. Som av en händelse verkar de två biblioteken lämpa sig väldigt bra ihop; där en rityta lätt skapas med SDL-anrop är det sedan möjligt att rita med hjälp av OpenGL-diton. Till slut kom vi att implementera vår grafikmodul med hjälp av grafikfunktionerna i SDL. Inledningsvis hade vi varit inställda på att använda OpenGL, men då vi inte lyckades få koll på bilduppdateringen ordentligt svängde vi snabbt över för att se om det skulle vara enklare att använda SDL. Det visade sig vara det, och för spelets skull innebär det ingen brist då vi inte planerat varken 3Dgrafik eller några roterande objekt. Att använda SDL för grafiken visade sig vara väldigt smidigt och enkelt, och vi hade kanske lärt oss mer av att göra allting den hårda vägen via OpenGL; men då det handlar om att prioritera för att möta alla krav valde vi att nöja oss med SDL, i alla fall inledningsvis. Då grafiken helt och hållet sköts av en egen grafikmodul är den förstås helt utbytbar och inledningsvis hade vi två moduler som hette Graphics_SDL respektive Graphics_GL, där den senare övergavs men lätt skulle kunna återinföras i ett senare skede. Och ännu enklare att få till okej grafik var det om man använde sig av bilder, vilket vi gjort uteslutande. Vi installerade visserligen SDL_image, men så länge man håller sig till.bmp-bilder så räcker de inbyggda funktionerna i SDL, även för att få till bilder med en transparent alfakanal. Grafik i SDL kunde ritas upp med hjälp av funktionerna SDL_BlitSurface(srcimg, &src, canvas, &dst); SDL_FreeSurface(srcimg); där srcimg sedan tidigare har laddats med exempelvis SDL_Surface *srcimg = SDL_LoadBMP("trashcan.bmp"); vilket representerar bildfilen med spelaranimation 4. Applikationen följer alltså mönstret rita- blitta - freesurface. SDL_BlitSurface lägger alltså ut det som ritats på skärmen, medan SDL_FreeSurface frigör ritytan. Modulen Graphics_SDL.c med tillhörande Graphics.h-fil användes för att rita upp all grafik i applikationen. I Graphics_SDL.c implementerades följande ritfunktioner: Funktionsnamn initgraphics(); refreshgraphics(); drawtext(); drawbackground(); drawtrash(); Syfte Initiera Truetype-fonts, skärmupplösning m.m. Uppdatera grafiken mha. SDL_Flip(). Rita upp text. Tar emot text via dess inparametrar. Rita upp bakgrundsfilen bg.bmp. Rita upp soptunnor i spelplanen (endast 24(57)

36 drawplayer(); drawtarget(); drawpowerup(); drawobstacle(); Tabell 3: Funktioner i Graphics_SDL.c. dekorativt). Rita upp spelarna, x- och y-positioner samt riktning som inparametrar. Rita upp måltavlorna, x- och y-positioner som inparametrar. Rita upp powerups, x- och y-positioner som inparametrar. Rita upp plattformarna som spelare kan hoppa upp på, x- och y-positioner som inparametrar. Ovanstående ritfunktioner (Tabell 3: Funktioner i Graphics_SDL.c.) ritades alltså upp på ritytan och blittades, alltså visades på skärmen, med hjälpa av SDL_BlitSurface. Därefter frigjordes ritytan med SDL_FreeSurface Transparens En transparent alfakanal kunde åstadkommas med hjälp av SDL-funktionen SDL_SetColorKey. Funktionen tar en given färg i RGB-format och tilldelar den som en nyckel för SDL-grafiken att skala bort. För denna applikation valdes att göra bilderna med en helt vit bakgrund, så att RGB-värdet (255,255,255) kunde tillhandahållas som alfakanal : SDL_SetColorKey(srcimg, SDL_SRCCOLORKEY SDL_RLEACCEL, SDL_MapRGB(srcimg->format, 255, 255, 255)); där srcimg är den källfil som läses och som alltså blir av med färgkanalen (255,255,255) Animationer Animationer användes för spelarfigurerna i applikationen. Tre olika typer av animationer implementerades: Spelarrörelser, sprayanimationer och stillastående animation. Metoden implementerades i Graphics_SDL.c, och använde sig av en stor bildfil (.bmp) per spelare som lästes av från olika koordinater beroende på vilken rörelse som ville visas. 25(57)

37 Illustration 4: Spelaranimation Illustration 4: Spelaranimation visar animationsdelarna för spelarfärg röd. Som synes i bilden infogades alla typer av animation för spelaren i samma bild. För att åstadkomma animationen lästes filen av i olika steg. Om t.ex. en animation av en högergående rörelse skulle ritas upp valdes att läsa av filen längst upp från vänster till höger och sedan om igen. Vice versa om en vänstergående rörelse skulle åstadkommas. Sprayanimationen placerades på tredje raden, och en stillastående animation längst ner. Kodexemplet srcimg = SDL_LoadBMP("PlayerAnim4.bmp"); src.x = x; if (direction == 1){ src.y = 0; } else if (direction == 2){ src.y = 120; } else if (direction == 0){ src.y = 360; } 26(57)

Programmering i C++ Kompilering från kommandoraden

Programmering i C++ Kompilering från kommandoraden Programmering i C++ Kompilering från kommandoraden Sven Gestegård Robertz Datavetenskap, LTH 9 november 2015 Sammanfattning Ibland vill man, av olika anledningar, inte använda en stor integrerad utvecklingsmiljö

Läs mer

Föreläsning 2. Operativsystem och programmering

Föreläsning 2. Operativsystem och programmering Föreläsning 2 Operativsystem och programmering Behov av operativsystem En dator så som beskriven i förra föreläsningen är nästan oanvändbar. Processorn kan bara ges enkla instruktioner såsom hämta data

Läs mer

Programmering B med Visual C++ 2008

Programmering B med Visual C++ 2008 Programmering B med Visual C++ 2008 Innehållsförteckning 1 Repetition och lite nytt...5 I detta kapitel... 5 Programexekvering... 5 Loop... 5 Källkod... 6 Verktyg... 6 Säkerhetskopiera... 6 Öppna, kompilera,

Läs mer

PROJEKTRAPPORT EDA095 NÄTVERKSPROGRAMMERI

PROJEKTRAPPORT EDA095 NÄTVERKSPROGRAMMERI PROJEKTRAPPORT EDA095 NÄTVERKSPROGRAMMERI NG STRESS LUNDS TEKNISKA HÖGSKOLA - 2013-05-22 Projektmedlemmar: Emil Apelgren adi10eap@student.lu.se Fredrik Helander gda10fhe@student.lu.se Jonathan Klingberg

Läs mer

Laboration i datateknik

Laboration i datateknik KUNGLIGA TEKNISKA HÖGSKOLAN Laboration i datateknik Felsökning och programmering av LEGO NXT robot Daniel Willén 2012 09 06 dwill@kth.se Introduktionskurs i datateknik II1310 Sammanfattning Syftet med

Läs mer

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson Rapport grupp 4 Software Engineering Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson 2009-10-29 Processer Sprinter Scrum har varit till stor hjälp för oss för att nå våra mål,

Läs mer

Introduktion till programmering med hjälp av Lego Mindstorm

Introduktion till programmering med hjälp av Lego Mindstorm Kungliga Tekniska Högskolan Introduktion till programmering med hjälp av Lego Mindstorm Laborationsrapport gällande programmering inom NXC Simon Jansson 31 08 2014 simonjan@kth.se Introduktionskurs i datateknik

Läs mer

Objektorienterad programmering i Java I

Objektorienterad programmering i Java I Laboration 0 Objektorienterad programmering i Java I Uppgifter: 2 Beräknad tid: ca 2 3 timmar Att läsa: sidan 45 52 Syfte: Att ladda hem och installera utvecklingsmiljön Att skriva ditt första Javaprogram

Läs mer

Föreläsning 3. Programmering, C och programmeringsmiljö

Föreläsning 3. Programmering, C och programmeringsmiljö Föreläsning 3 Programmering, C och programmeringsmiljö Vad är programmering? Ett väldigt kraftfullt, effektivt och roligt sätt att kommunicera med en dator Att skapa program / applikationer till en dator

Läs mer

Inledande programmering med C# (1DV402) Introduktion till C#

Inledande programmering med C# (1DV402) Introduktion till C# Introduktion till C# Upphovsrätt för detta verk Detta verk är framtaget i anslutning till kursen Inledande programmering med C# vid Linnéuniversitetet. Du får använda detta verk så här: Allt innehåll i

Läs mer

Lab1 Introduktion. 1 Syfte. 2 Innehåll Win32API Skapa trådar Kritiska sektioner Mailslothantering. 3 Förberedelse & Tips

Lab1 Introduktion. 1 Syfte. 2 Innehåll Win32API Skapa trådar Kritiska sektioner Mailslothantering. 3 Förberedelse & Tips Lab1 Introduktion Förberedelse för planetlabben genom att kapsla in (skapa wrappers) systemanrop. 1 Syfte Få en känsla av hur Win32API fungerar, dvs programmerarens interface gentemot Windows. Känsla för

Läs mer

Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp

Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp Dataingenjörsprogrammet, elektroingenjörsprogrammet och medicinsk teknik KTH Skolan för Teknik och Hälsa Redovisning: Se Kurs-PM om hur redovisningen

Läs mer

Programmering, grundkurs, 8.0 hp, Elektro, KTH, hösten 2010. Programmering: att instruera en maskin att utföra en uppgift, kräver olika språk:

Programmering, grundkurs, 8.0 hp, Elektro, KTH, hösten 2010. Programmering: att instruera en maskin att utföra en uppgift, kräver olika språk: Föreläsning 1 OH: Övergripande information Programmering: att instruera en maskin att utföra en uppgift, kräver olika språk: * maskinspråk = ettor och nollor, kan bara en maskin förstå. * programmeringsspråk

Läs mer

Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp

Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp Dataingenjörsprogrammet, elektroingenjörsprogrammet och medicinsk teknik KTH Skolan för Teknik och Hälsa Redovisning: Se Kurs-PM om hur redovisningen

Läs mer

Grundkurs i programmering - intro

Grundkurs i programmering - intro Grundkurs i programmering - intro Linda Mannila 4.9.2007 Dagens föreläsning Allmän kursinformation: mål, syfte, upplägg, examination, litteratur, etc. Hur arbetar en dator? Hur vi får datorn att förstå

Läs mer

Introduktion till programmering, hösten 2011

Introduktion till programmering, hösten 2011 Föreläsning 1 Programmering är ett hantverk. Det betyder att man inte kan läsa sig till den förmågan, man måste träna och man tränar genom att skriva mer och mer avancerade program. Programmering förutsätter

Läs mer

Slutrapport Get it going contracts

Slutrapport Get it going contracts Slutrapport Get it going contracts Författare: Anthony Dry Datum: 2011-06-02 Program: Utvecklare av digitala tjänster Kurs: Individuellt mjukvaruutvecklingsprojekt 7.5p Linnéuniversitetet (Kalmar) Abstrakt

Läs mer

725G61 - Laboration 7 Implementation av ett API. Johan Falkenjack

725G61 - Laboration 7 Implementation av ett API. Johan Falkenjack 725G61 - Laboration 7 Implementation av ett API Johan Falkenjack December 13, 2013 1 Inledning Hittills i kursen har vi tittat på grundläggande programmering och grundläggande objektorientering. I den

Läs mer

DI-institutionen Sid 1 av 6 Hans-Edy Mårtensson Sten Sundin

DI-institutionen Sid 1 av 6 Hans-Edy Mårtensson Sten Sundin DI-institutionen Sid 1 av 6 Hans-Edy Mårtensson Sten Sundin TENTAMEN I IKB007 INTERNETPROGRAMMERING MED JAVA för SY2 1999-03-17, kl 14.00-18.00 Hjälpmedel: En lärobok i Java programmering Återlämningstillfälle:

Läs mer

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08 JavaRats Kravspecifikation Version 1.1 Gustav Skoglund gussk258@student.liu.se Marcus Widblom marwi026@student.liu.se Senast ändrad: 13 / 05 / 08 Sammanfattning Kravspecifikationen för JavaRats har skrivit

Läs mer

Inledning. Vad är ett datorprogram, egentligen? Olika språk. Problemlösning och algoritmer. 1DV433 Strukturerad programmering med C Mats Loock

Inledning. Vad är ett datorprogram, egentligen? Olika språk. Problemlösning och algoritmer. 1DV433 Strukturerad programmering med C Mats Loock Inledning Vad är ett datorprogram, egentligen? Olika språk Problemlösning och algoritmer 1 (14) Varför använda en dator? Genom att variera de program som styr datorn kan den användas för olika uppgifter.

Läs mer

tentamensdags och lab 3

tentamensdags och lab 3 tentamensdags och lab 3 Större program delas normalt upp i flera filer/moduler vilket har flera fördelar: Programmets logiska struktur när man klumpar ihop funktioner som hör ihop (och ibland också struct-def

Läs mer

Kravspecifikation. Sammanfattning. Fyra i rad Javaprojekt inom TDDC32. Version 2.0. Datum Dokumentnummer

Kravspecifikation. Sammanfattning. Fyra i rad Javaprojekt inom TDDC32. Version 2.0. Datum Dokumentnummer Kravspecifikation Fyra i rad Javaprojekt inom TDDC32 Version 2.0 Datum 2008-05-19 Dokumentnummer 20080215 Sammanfattning Detta är en kravspecifikation över det klassiska spelet Fyra-i-rad programmerat

Läs mer

Omkoppling av in- och utmatning. In- och utmatning i Unix. Kommando exempel, ls, pipe forts. Kommando exempel, ls, pipe

Omkoppling av in- och utmatning. In- och utmatning i Unix. Kommando exempel, ls, pipe forts. Kommando exempel, ls, pipe In- och utmatning i Unix Program i Unix skriver och läser till och från filer. En fil betyder här en vanlig fil med text eller binära data, ett tangentbord, en skärm, ett annat program etc. Innan ett program

Läs mer

HI1024 Programmering, grundkurs TEN2 2014-03-13

HI1024 Programmering, grundkurs TEN2 2014-03-13 HI1024 Programmering, grundkurs TEN2 2014-03-13 KTH STH Haninge 13.15-18.00 Tillåtna hjälpmedel: En A4 handskriven på ena sidan med egna anteckningar Kursboken C PROGRAMMING A Modern Approach K. N. King

Läs mer

Programmering av NXT Lego- robot Labbrapport för programmering av en Lego- robot

Programmering av NXT Lego- robot Labbrapport för programmering av en Lego- robot KUNGLIGA TEKNISKA HÖGSKOLAN Programmering av NXT Lego- robot Labbrapport för programmering av en Lego- robot Josef Karlsson Malik 2015-09- 02 jkmalik@kth.se Introduktionskurs i datateknik (II0310) Sammanfattning

Läs mer

Kurskatalog 2010 INNEHÅLLSFÖRTECKNING

Kurskatalog 2010 INNEHÅLLSFÖRTECKNING SFÖRTECKNING 1. RFID-Kurser... 2 1.1. RFID Grundkurs... 2 1.2. RFID Fortsättningskurs... 3 1.3. RFID dator programmering... 4 1.4. RFID Systemadministration... 5 1.5. RFID Aktiv Systemadministration...

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Tor Sterner-Johansson Thomas Johansson Daniel Henriksson

Tor Sterner-Johansson Thomas Johansson Daniel Henriksson Lab 4: Anti Tower Defence Oskar Mothander Alan Mendez Larsson dit06omr dit06mln Lärare: Handledare: Johan Eliasson Johan Granberg Tor Sterner-Johansson Thomas Johansson Daniel Henriksson Innehåll 1. Problemspecifikation...

Läs mer

Programmera Lego Mindstormsrobotar

Programmera Lego Mindstormsrobotar KUNGLIGA TEKNISKA HÖGSKOLAN Programmera Lego Mindstormsrobotar En introduktion till programmering Oskar Rosén 28/08-12 oros@kth.se Introduktion i datateknik (II1310) Sammanfattning Denna laboration gav

Läs mer

SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS

SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS Individuellt Mjukvaruutvecklingsprojekt (Utvecklare av digitala tjänster) Den 1 juni 2011 ABSTRAKT Rapporten tar upp positiva och negativa erfarenheter som jag erhållit

Läs mer

Real-time requirements for online games

Real-time requirements for online games Real-time requirements for online games En undersökning om protokoll, tekniker och metoder som datorspel använder för att kommunicera över Internet Victor Grape Milad Hemmati Linköpings universitet Linköping

Läs mer

Programmering. Hur, var, när och varför. 22 November. Lars Ohlén Tieto lars.ohlen@tieto.com

Programmering. Hur, var, när och varför. 22 November. Lars Ohlén Tieto lars.ohlen@tieto.com Programmering Hur, var, när och varför 22 November Lars Ohlén Tieto lars.ohlen@tieto.com Agenda Om mig Programmering Vad är? Varför kunna? Hur använda kunskapen? Framtiden Sammanfattning Q+A 2 Om mig Arbetat

Läs mer

Datorlaboration 0, Programmering i C++ (EDA623)

Datorlaboration 0, Programmering i C++ (EDA623) LUNDS TEKNISKA HÖGSKOLA Programmering i C++ Institutionen för datavetenskap HT 2013 Datorlaboration 0, Programmering i C++ (EDA623) Under den inledande datorlaborationen får du träna på de grundläggande

Läs mer

LABORATIONSUPPGIFTER WINDOWS OPERATIVSYSTEM

LABORATIONSUPPGIFTER WINDOWS OPERATIVSYSTEM WINDOWS OPERATIVSYSTEM LABORATIONSUPPGIFTER ALLMÄNT Kursens laborationsdel består av sex uppgifter. För att få laborationsdelen av kursen godkänd krävs att alla sex uppgifter löses. Den sista uppgiften

Läs mer

Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp

Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp Laboration 3 HI1024, Programmering, grundkurs, 8.0 hp Dataingenjörsprogrammet, elektroingenjörsprogrammet och medicinsk teknik KTH Skolan för Teknik och Hälsa Redovisning: Se Kurs-PM om hur redovisningen

Läs mer

Snake. Digitala Projekt (EITF11) Fredrik Jansson, I-12 Lunds Tekniska Högskola,

Snake. Digitala Projekt (EITF11) Fredrik Jansson, I-12 Lunds Tekniska Högskola, Snake Digitala Projekt (EITF11) Fredrik Jansson, I-12 Lunds Tekniska Högskola, 2015-05-18 Oskar Petersen, I-12 Handledare: Bertil Lindvall Abstract Denna rapport beskriver ett projekt där ett klassiskt

Läs mer

Preliminär specifikation av projekt

Preliminär specifikation av projekt Preliminär specifikation av projekt Projektets namn: Infraröd Minneslåda (numera omdöpt till FastSync) Uppdragsgivare: Alex Olwal aolwal@cs.columbia.edu Deltagare: Johan Ullberg Nils

Läs mer

1 Kravspecifikation Snake App

1 Kravspecifikation Snake App Kravspecifikation Snake App - Kravspecifikation Snake App Utskriven/PDF Export: 2011-09-07 Copyright 2011 Sidan 1 av 7 1 Kravspecifikation Snake App 1.1 Vad är Snake App? Vi skall gör ett Snake Spel för

Läs mer

KTH STH TENTAMEN. HI1024:TEN2 - Praktisk tentamen Tid: 8-13, den 18 februari 2012

KTH STH TENTAMEN. HI1024:TEN2 - Praktisk tentamen Tid: 8-13, den 18 februari 2012 KTH STH TENTAMEN HI1024:TEN2 - Praktisk tentamen Tid: 8-13, den 18 februari 2012 Gamla kurskoder: HI1900, 6E2950, etc. Examinator: Johnny Panrike Rättande lärare: Nicklas Brandefelt, Johnny Panrike och

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Hur man kompilerar och kör IT++-program med MinGW. 1 Sammanfattning. 2 Om dokumentet. 3 Om min konfiguration

Hur man kompilerar och kör IT++-program med MinGW. 1 Sammanfattning. 2 Om dokumentet. 3 Om min konfiguration 1 (12) Hur man kompilerar och kör IT++-program med MinGW 1 Sammanfattning Detta dokument visar hur man lätt (med några få extra raders kod) kan få IT++ att bli kompatibelt med kompilatorn MinGW. Med den

Läs mer

HI1024 Programmering, grundkurs TEN

HI1024 Programmering, grundkurs TEN HI1024 Programmering, grundkurs TEN2 2014-10-27 KTH STH Haninge 13.15-18.00 Tillåtna hjälpmedel: En A4 handskriven på ena sidan med egna anteckningar Kursboken C PROGRAMMING A Modern Approach K. N. King

Läs mer

Datorlaboration 0, Programmering i C++ (EDAF30)

Datorlaboration 0, Programmering i C++ (EDAF30) LUNDS TEKNISKA HÖGSKOLA Programmering i C++ Institutionen för datavetenskap HT 2015 Datorlaboration 0, Programmering i C++ (EDAF30) Under den inledande datorlaborationen får du träna på de grundläggande

Läs mer

Kapitel 4 Arkivmenyn Innehåll

Kapitel 4 Arkivmenyn Innehåll Kapitel 4 Arkivmenyn Innehåll ARKIVMENYN...2 Byt aktuell användare...2 Utskrift till skärm eller skrivare...3 SQL verktyget...4 Ny SQL...4 Hämta SQL...5 Spara SQL...5 Kör SQL...5 Visa som...5 Avsluta...5

Läs mer

Instruktioner för uppdatering från Ethiris 4.10 till 5.x

Instruktioner för uppdatering från Ethiris 4.10 till 5.x Instruktioner för uppdatering från Ethiris 4.10 till 5.x Nedan följer instruktioner för hur man går till väga vid uppdatering av ett Ethirissystem version 4 till version 5. När man uppdaterar Ethiris från

Läs mer

Universe Engine Rapport

Universe Engine Rapport 1 Universe Engine Rapport Alexander Mennborg 2017-05-08 2 Inledning I denna rapport diskuteras utvecklingsprocessen till projektet Universe Engine. Denna diskussion omfattar hela utveckling från starten

Läs mer

Introduktion till programmering D0009E. Föreläsning 1: Programmets väg

Introduktion till programmering D0009E. Föreläsning 1: Programmets väg Introduktion till programmering D0009E Föreläsning 1: Programmets väg 1 Vad är en dator? En maskin vars beteende styrs av de innehållet (bitmönster) som finns lagrade i datorns minne (inte helt olikt förra

Läs mer

HexaFlip. Kravspecifikation

HexaFlip. Kravspecifikation HexaFlip Kravspecifikation Dokumentversion 1.0 Martin Larsson marla316@student.liu.se Carl Lindwall carli914@student.liu.se Senast modifierad 2009 02 17 Sammanfattning Detta dokument skall ligga som grund

Läs mer

Klientmanual. Inställningar och spelstart Windows & Linux

Klientmanual. Inställningar och spelstart Windows & Linux Klientmanual Age of KTH är ett realtidsstrategispel där upp mot 8 spelare ska utplåna varandra genom att samla resurser och skapa enheter för att attackera varandra. I den här manualen finns installationsanvisningar

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

TDP005 Projekt: Objektorienterat system

TDP005 Projekt: Objektorienterat system . TDP005 Projekt: Objektorienterat system Laboration i Make och CMake Författare Filip Strömbäck Höstterminen 2016 Version 1.0 2016-10-04 Introduktion I denna lab kommer vi titta närmare på två verktyg

Läs mer

Laborationsrapport av robotprogrammering

Laborationsrapport av robotprogrammering KUNGLIGA TEKNISKA HÖGSKOLAN Laborationsrapport av robotprogrammering Programmering av LEGO MINDSTORMS robot Rikard Bjärlind 2012-09-07 E-post: bjarlind@kth.se Introduktionskurs i datateknik (H12) II1310

Läs mer

EDA095 Nätverksprogrammering

EDA095 Nätverksprogrammering EDA095 Nätverksprogrammering Projekt Checkers Grupp 8, 2008 Dag Wahlberg Leo Barnes Erik Wallenborg Ylva Mellbin

Läs mer

Så här skriver du ditt första program i C++

Så här skriver du ditt första program i C++ Så här skriver du ditt första program i C++ Introduktion till att skapa Solution, Project och källkodsfil i Visual Studio 2013 Författare Anne Norling Kurs: Strukturerad programmering med C++ Kurskod:1DV433

Läs mer

Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer.

Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer. Informationsinfrastruktur 7.5 hp Mattias Nordlindh Inledning Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer. Dokumentet består av

Läs mer

Projektrapport EDA095

Projektrapport EDA095 Projektrapport EDA095 Grupp 8 Fredrik Stål, dt08fs5@student.lth.se Per-Gustaf Stenberg, dt08ps5@student.lth.se Mattias Frisk, dt08mf3@student.lth.se Joakim Hembrink, dt08jh8@student.lth.se 16 maj 2012

Läs mer

Programmering i C++ En manual för kursen Datavetenskaplig introduktionskurs 5p

Programmering i C++ En manual för kursen Datavetenskaplig introduktionskurs 5p Programmering i C++ En manual för kursen Datavetenskaplig introduktionskurs 5p Skriven av Michael Andersson Introduktion Programmering I högnivåspråk fokuserar på själv problemet (algoritmen) istället

Läs mer

SMULTRON. Fredrik Li, Ester, Anders, Jessica, Philip. Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007

SMULTRON. Fredrik Li, Ester, Anders, Jessica, Philip. Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007 SMULTRON av Fredrik Li, Ester, Anders, Jessica, Philip Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007 - När man har turen att hitta en plats där man trivs

Läs mer

Versionshantering. Problem som uppstår i större (samt även mindre) projekt:

Versionshantering. Problem som uppstår i större (samt även mindre) projekt: Versionshantering Problem som uppstår i större (samt även mindre) projekt: Samtidiga ändringar. Kålle och Ada öppnar samma fil för redigering vid var sin dator. Om Kålle först sparar sina ändringar och

Läs mer

6. Nu skall vi ställa in vad som skall hända när man klickar på knappen samt att markören skall ändra sig till en hand när markören är på knappen.

6. Nu skall vi ställa in vad som skall hända när man klickar på knappen samt att markören skall ändra sig till en hand när markören är på knappen. Fiskar Arbetsbeskrivning knappmeny (Mediator 8) I detta exempel kommer du att lära dig Att göra en mastersida med knappar Att använda en mastersida på andra sidor Att använd funktionen Alignment Arbetsgång

Läs mer

Model View Controller. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016

Model View Controller. Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Model View Controller Objekt-orienterad programmering och design (DIT952) Niklas Broberg, 2016 Model View Controller Model View Controller (MVC) är ett design pattern (architectural pattern) som är väldigt

Läs mer

TUTORIAL: KLASSER & OBJEKT

TUTORIAL: KLASSER & OBJEKT TUTORIAL: KLASSER & OBJEKT I denna tutorial lär vi oss att använda klasser och objekt samt hur vi bygger en enkel applikation kring dessa. I tutorialen kommer det finnas en mängd kod som du antingen kan

Läs mer

Creo Customization. Lars Björs 2014-10-16

Creo Customization. Lars Björs 2014-10-16 Creo Customization Lars Björs 2014-10-16 Norra Europas största partner och återförsäljare av PTC relaterad programvara (Windchill, Creo, Arbortext, MathCad, Relex) 70 anställda Egen utvecklingsavdelning

Läs mer

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu. Mina listor En Android-applikation Rickard Karlsson 2013-06-09 Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.se Innehållsförteckning 2. Innehållsförteckning 3. Abstrakt 4. Inledning/bakgrund

Läs mer

Labb i Datorsystemteknik och programvaruteknik Programmering av kalkylator i Visual Basic

Labb i Datorsystemteknik och programvaruteknik Programmering av kalkylator i Visual Basic Labb i Datorsystemteknik och programvaruteknik Programmering av kalkylator i Visual Basic Inledning Starta Microsoft Visual Studio 2005. Välj create Project Välj VB + Vindows Application och välj ett nytt

Läs mer

TDIU01 - Programmering i C++, grundkurs

TDIU01 - Programmering i C++, grundkurs TDIU01 - Programmering i C++, grundkurs Pekare och Listor Eric Elfving Institutionen för datavetenskap 31 oktober 2014 Översikt 2/41 Internminne Pekare Dynamiska datastrukturer (Enkellänkade) listor Arbeta

Läs mer

Varför behövs det? I Allegro finns t.ex. stöd för:

Varför behövs det? I Allegro finns t.ex. stöd för: Allegro Introduktion Översikt vad är Allegro? Vad är lib och h-fil Kolla kodexempel Strukturen på ett Allegrospel Hur kommer jag igång? Var kan jag läsa mer Addons Alternativ Vad är Allegro? Ett spelprogrammeringsbibliotek

Läs mer

Laboration 1 Introduktion till Visual Basic 6.0

Laboration 1 Introduktion till Visual Basic 6.0 Laboration 1 Introduktion till Visual Basic 6.0 Förberedelse Förbered dig genom att läsa föreläsningsanteckningar och de kapitel som gåtts igenom på föreläsningarna. Läs även igenom laborationen i förväg.

Läs mer

Labrapport: Programmering i NXC Programmera LEGO Maindstorm med NXC

Labrapport: Programmering i NXC Programmera LEGO Maindstorm med NXC KTH ICT Labrapport: Programmering i NXC Programmera LEGO Maindstorm med NXC Jonathan Kindfält 23/08-2012 E-post (kindfalt@kth.se) Introduktionskurs i datateknik II1310 Sammanfattning Denna rapport behandlar

Läs mer

Projektuppgift - Biblioteket

Projektuppgift - Biblioteket Projektuppgift - Biblioteket 2013 1. Projekt - syfte, instruktioner och uppgift Syftet med den här projektuppgiften är att ni nu ska tillämpa allt det ni har lärt er i kursens två labbdelar, dvs både kunskaper

Läs mer

Installationsanvisning - Kopplingen mellan GK96 och golf.se -

Installationsanvisning - Kopplingen mellan GK96 och golf.se - Installationsanvisning - Kopplingen mellan GK96 och golf.se - (Läs hela anvisningen innan du installerar)!denna installationsanvisning innehåller förändringar från tidigare versioner! 1. Programmets syfte...

Läs mer

1 Vad är Versionshantering? 2 Git. 2.1 GitHub

1 Vad är Versionshantering? 2 Git. 2.1 GitHub 1 Vad är Versionshantering? Versionshantering (eller Version Control) är ett samlingsnamn för program som ger en användare möjlighet att komma åt tidigare versioner av dokument och spåra ändringar som

Läs mer

Planering Programmering grundkurs HI1024 HT 2015 - data

Planering Programmering grundkurs HI1024 HT 2015 - data Planering Programmering grundkurs HI1024 HT 2015 - data Föreläsning V36 Föreläsning 1 Programmering Kurs-PM Programmeringsmiljö Hello World! Variabler printf scanf Föreläsning 2 Operatorer Tilldelning

Läs mer

Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers

Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers Ett projekt i kursen TDA367 Objektorienterat programmeringsprojekt och LSP310 Kommunikation och ingenjörskompetens Maxim Goretskyy

Läs mer

Innehållsförteckning. 9 Större projekt Övningsuppgifter...32

Innehållsförteckning. 9 Större projekt Övningsuppgifter...32 PROGRAMMERING JAVA Innehållsförteckning 1 Allmänt om Java...5 I detta kapitel... 5 Historia... 5 Hur fungerar det att programmera?... 6 Inspiration... 9 Styrkan i Java...10 Övningsuppgifter... 11 2 Utvecklingsverktyget...12

Läs mer

The Intelligent Timer

The Intelligent Timer The Intelligent Timer Linnea Karell och Oscar Bagge, I10 Handledare: Bertil Lindvall 2013-05-20 Abstract The objective of this project was to build a prototype of a digital timer. The product design specification

Läs mer

Översikt Föreläsning 1. Trivicalc. Vad är trivicalc? En cell. Områden på skärmen. SMD168/SMD135 Fredrik Bengtsson

Översikt Föreläsning 1. Trivicalc. Vad är trivicalc? En cell. Områden på skärmen. SMD168/SMD135 Fredrik Bengtsson Översikt Trivicalc SMD168/SMD15 Fredrik Bengtsson bson@sm.luth.se Föreläsning 1 Introduktion till Trivicalc - problem Föreläsning Grafiska Användargränssnitt Föreläsning del 1 Versionshantering CVS (Johan

Läs mer

Objektorienterad programmering i Java I. Uppgifter: 2 Beräknad tid: 5-8 timmar (OBS! Endast ett labbtillfälle) Att läsa: kapitel 5 6

Objektorienterad programmering i Java I. Uppgifter: 2 Beräknad tid: 5-8 timmar (OBS! Endast ett labbtillfälle) Att läsa: kapitel 5 6 Laboration 2 Objektorienterad programmering i Java I Uppgifter: 2 Beräknad tid: 5-8 timmar (OBS! Endast ett labbtillfälle) Att läsa: kapitel 5 6 Syfte: Att kunna använda sig av olika villkors- och kontrollflödeskonstruktioner

Läs mer

Värmedistribution i plåt

Värmedistribution i plåt Sid 1 (6) Värmedistribution i plåt Introduktion Om vi med konstant temperatur värmer kanterna på en jämntjock plåt så kommer värmen att sprida sig och temperaturen i plåten så småningom stabilisera sig.

Läs mer

Introduktion till programmering och Python Grundkurs i programmering med Python

Introduktion till programmering och Python Grundkurs i programmering med Python Introduktion till programmering och Python Hösten 2009 Dagens lektion Vad är programmering? Vad är en dator? Filer Att tala med datorer En första titt på Python 2 Vad är programmering? 3 VAD ÄR PROGRAMMERING?

Läs mer

Fyra i rad Javaprojekt inom TDDC32

Fyra i rad Javaprojekt inom TDDC32 Fyra i rad Javaprojekt inom TDDC32 Analys och design-dokument Version 2.0 Datum 2008-05-19 Dokumentnummer 20080303 Sammanfattning Detta är analys och design-dokumentet för programmet Fyra i rad. Fyra i

Läs mer

TENTAMEN I PROGRAMMERING. På tentamen ges graderade betyg:. 3:a 24 poäng, 4:a 36 poäng och 5:a 48 poäng

TENTAMEN I PROGRAMMERING. På tentamen ges graderade betyg:. 3:a 24 poäng, 4:a 36 poäng och 5:a 48 poäng TENTAMEN I PROGRAMMERING Ansvarig: Jan Skansholm, tel 7721012 Betygsgränser: Hjälpmedel: Sammanlagt maximalt 60 poäng. På tentamen ges graderade betyg:. 3:a 24 poäng, 4:a 36 poäng och 5:a 48 poäng Skansholm,

Läs mer

KUNGLIGA TEKNISKA HÖGSKOLAN KISTA. Lego Linefollower. Få en robot att följa linjen på golvet!

KUNGLIGA TEKNISKA HÖGSKOLAN KISTA. Lego Linefollower. Få en robot att följa linjen på golvet! KUNGLIGA TEKNISKA HÖGSKOLAN KISTA Lego Linefollower Få en robot att följa linjen på golvet! Felix Ringberg 2012-08-09 felixri@kth.se Introduktionskurs i datateknik II1310 Sammanfattning I den här laborationen

Läs mer

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar Skapa testfall Testing Köra testen Hitta fel Inspections and reviews Verifiera resultatet Formal methods Static analysis Completeness Verifiering Kvalitet Maintainability Validering Traceability Fault

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

Läs mer

Programmeringsteknik med C och Matlab

Programmeringsteknik med C och Matlab Programmeringsteknik med C och Matlab Kapitel 6: Filhantering Henrik Björklund Umeå universitet 13 oktober 2009 Björklund (UmU) Programmeringsteknik 13 oktober 2009 1 / 22 Textfiler Filer är sekvenser

Läs mer

Program & programmering

Program & programmering Program & programmering Vad är program? Satser och instruktioner, toggla igenom exempel Program på olika nivåer, för olika maskiner, för olika saker Tolka program; kompilator, intepretator, binärbytekod,

Läs mer

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1 Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut

Läs mer

Vilken version av Dreamweaver använder du?

Vilken version av Dreamweaver använder du? Sida 1 av 7 Lektion 1: sida 1 av 4 Till kursens framsida Sida 2 av 4» Lektion 1 Då ska vi sätta igång med den här kursens första lektion! Här kommer du att få lära dig hur man skapar och förbereder webbplatser

Läs mer

Översikt. Installation av EasyPHP 1. Ladda ner från http://www.easyphp.org/ Jag använder Release 5.3.4.0 2. Installera EasyPHP.

Översikt. Installation av EasyPHP 1. Ladda ner från http://www.easyphp.org/ Jag använder Release 5.3.4.0 2. Installera EasyPHP. Laboration 1 Översikt 1. Att komma igång med laborationsmiljön a. installera Aptana Studio 3 b. Installera EasyPHP 2. Testa lite programmering a. Testa enkla uppgifter b. Testa automatiskt 3. Skapa inloggningsformulär

Läs mer

PROGRAMMERING I NXC. Sammanfattning KUNGLIGA TEKNISKA HÖGSKOLAN

PROGRAMMERING I NXC. Sammanfattning KUNGLIGA TEKNISKA HÖGSKOLAN KUNGLIGA TEKNISKA HÖGSKOLAN PROGRAMMERING I NXC Namn: Michel Bitar 2012-08- 25 E- post: mbitar@kth.se Introduktionskurs i datateknik, II1310 Sammanfattning Intressant och lärorik laboration om att programmera

Läs mer

EDAA20 Programmering och databaser. Mål komprimerat se kursplanen för detaljer. Checklista. Föreläsning 1-2 Innehåll. Programmering.

EDAA20 Programmering och databaser. Mål komprimerat se kursplanen för detaljer. Checklista. Föreläsning 1-2 Innehåll. Programmering. EDAA20 Programmering och databaser Mål komprimerat se kursplanen för detaljer Läsperiod 1 7.5 hp anna.aelsson@cs.lth.se http://cs.lth.se/edaa20 Mer information finns på kursens webbsida samt på det utdelade

Läs mer

NetBeans 7. Avsikt. Projektfönster

NetBeans 7. Avsikt. Projektfönster NetBeans 7 Avsikt Att bekanta dig med NetBeans programmeringsmiljö, dvs att med hjälp av NetBeans 1. skapa ett nytt projekt 2. skriva in källkod (sparas som.java-fil) 3. kompilera (översätta) koden till

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Objektsamlingar i Java

Objektsamlingar i Java 1 (6) Objektsamlingar i Java Objektorienterad programmering 3 Syfte Att ge träning i att använda objektsamlingar i Java. Mål Efter övningen skall du kunna använda objektsamlingsklasserna ArrayList och

Läs mer

Laboration i datateknik

Laboration i datateknik KUNGLIGA TEKNISKA HÖGSKOLAN Laboration i datateknik Programmering av LEGO-robot Rickard Eriksson 2012-09-06 rieri@kth.se Introduktionskurs i datateknik II1310 Sammanfattning Denna rapport är till följd

Läs mer

SKOLFS. beslutade den XXX 2017.

SKOLFS. beslutade den XXX 2017. 1 (11) Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:247) om ämnesplan för ämnet programmering i gymnasieskolan, inom kommunal vuxenutbildning på gymnasial nivå och inom vidareutbildning

Läs mer

Programmera i C Varför programmera i C när det finns språk som Simula och Pascal??

Programmera i C Varför programmera i C när det finns språk som Simula och Pascal?? Programmera i C Varför programmera i C när det finns språk som Simula och Pascal?? C är ett språk på relativt låg nivå vilket gör det möjligt att konstruera effektiva kompilatorer, samt att komma nära

Läs mer

NetBeans 5.5. Avsikt. Projektfönster

NetBeans 5.5. Avsikt. Projektfönster NetBeans 5.5 Avsikt Att bekanta dig med NetBeans programmeringsmiljö, dvs att med hjälp av NetBeans 1. skapa ett nytt projekt 2. skriva in källkod (sparas som.java-fil) 3. kompilera (översätta) koden till

Läs mer