Rapport Objektorienteret Pacman - Portfolio - Tommy Andersen

Rapport
Objektorienteret Pacman
Tommy Kobberø Andersen Christian Monrad Larsen
_______________________ ________________________

Indholdsfortegnelse
Rapport – Objekt Orienteret Pacman spil
1. 4
PRODUKTINDLEDNING 4
1.1. GENEREL BESKRIVELSE 5
1.2. GRUPPEN 5
2. 6
PROJEKTOVERVEJELSER 6
2.1. ARBEJDSFORM 7
2.3. ARBEJDSOPDELING 7
2.4. SWOT 8
2.5. PROBLEMSTILLING 8
KODESTIL 9
2.5.1. SCOPE VARIABLER 9
2.5.2. VARIABEL TYPER 9
2.5.3. OPBYGNING AF IF/FOR/WHILE/DO SÆTNINGER 9
2.5.4. OPBYGNING AF LYKKER 9
2.5.5. FUNKTION / METODE OPBYGNING 9
2.5.6. CLASS OPBYGNING 10
2.6. TEKNOLOGIER 11
2.6.1. CSS / XHTML 11
2.6.2. PHP 11
2.6.3. TEMPLATES 11
2.6.4. APACHE 11
2.6.5. MYSQL 11
2.6.6. C++ 12
2.6.7. FLASH 12
2.6.8. GDI 12
2.6.9. FMOD 12
3. 13
ANALYSE 13
3.1. USE CASE 14
3.1.1. HJEMMESIDE - FORSIDE 14
3.1.2. SPILLETS HOVEDMENU 14
3.1.3. INDTAST NAVN 15
3.1.4. INDE I SPILLET 15
3.1.5. GAME OVER 16
3.2. BESKRIVELSE AF USE CASES 17
4. 18
DESIGN 18
Side 2 af 50

Rapport – Objekt Orienteret Pacman spil
4.1. FLOWCHART 19
4.2. SWIMLANE 21
4.3. DETALJERET FORKLARING AF SPILLETS FEATURES 25
4.4. GRAFIK BUFFER 25
4.5. KUNSTIG INTELLIGENS 26
4.6. TIMER 27
4.7. BILLEDER 27
5. 29
ENDELIGT 29
PROGRAMDESIGN 29
5.1. FLOWCHART 30
5.2. DATABASE 33
5.3. KLASSEDIAGRAM 34
5.3.2. HJEMMESIDE 37
5.4. SEKVENSDIAGRAM 39
5.5. IPO 41
5.6. CLIENT / SERVER / SIKKERHED 43
5.7. GULDKORN 44
6. 48
KONKLUSION 48
6.1. LITTERATURLISTE 50
6.2. BILAG 50
Side 3 af 50

Rapport – Objekt Orienteret Pacman spil
1.
Produktindledning
Side 4 af 50

Rapport – Objekt Orienteret Pacman spil
1.1. Generel beskrivelse
Projektet er et Pacman spil. Pacman er en lille osteligende figur der skal bevæge sig rundt på en
bane mens han spiser nogle små stykker mad der er fordelt ud over det meste af banen. Mission er
at tømme banen for mad. Banen er formet som en labyrint. Til at forhindre Pacman i at opnå hans
mission er der 4 spøgelser på banen som alle sammen jagter Pacman på hver deres metode via deres
kunstige intelligens. Hvis pacman bliver ramt af spøgelserne dør han og mister et af sine liv.
Pacman starter med 2 ekstra liv.
Banerne skal klares inden tiden løber ud. Pacman starter med 5 minutter på bane 1.
Hvis Pacman får spist al maden på banen bliver Pacman overført til næste bane. Næste bane vil altid
være svære end den forrige fordi spøgelserne bliver hurtigere og hurtigere for hver bane. Der
trækkes også 15 sekunder af tiden pr bane.
På alle baner vil der være nogle store stykker mad som Pacman kan spise. Når Pacman spiser et
stort stykke mad bliver alle spøgelserne blå og flygter fra Pacman i stedet for at jagte ham. Mens
spøgelserne er blå kan Pacman spise dem og få point. Jo flere spøgelser pacman kan nå at spise
inden de bliver normale jo flere point giver det. Pacman får point for alt han spiser. Der kommer
også frugter frem en gang i mellem, frugterne giver point al efter hvilken bane man er kommet til.
Man får et ekstra liv hver gang man får 10.000 point.
Vi har valgt at gøre det muligt for brugeren at få uploadet sin score til en hjemmeside så han kan
sammenligne sine færdigheder med andre spillere. Spillet fører også en lokal highscore liste.
1.2. Gruppen
Vores projektgruppe består af Christian M Larsen og Tommy Kobberø Andersen.
1.3. Læsevejledning
Rapporten henvender sig til en læser med teknisk forståelse.
Vi gør brug af referencer mellem punkter og dokumenter.
Referencer skal læses såldes her:
Eksempel: (Ref: Kildekode, Bilag 7, 1.2.34)
(Ref: navn, dokument, punkt)
Det kan også bare stå som 7,1.2.34 eller bare 1.2.34 hvis der ikke er plads i diagrammet.
Sidste tal i referencen kan også være en figurs nr.
1.4. Struktur
Rapporten er opbygget i faser som leder læseren gennem de skridt vi har været igennem. Det
starter med analyse og ender i kildekode.
Vores rapport har følgende hovedemner:
• Projektovervejelser
• Analyse
• Design
• Programdesign
• Konklusion
Side 5 af 50

Rapport – Objekt Orienteret Pacman spil
2.
Projektovervejelser
Side 6 af 50

Rapport – Objekt Orienteret Pacman spil
2.1. Arbejdsform
Vi har mødtes de fleste dage kl. 10 til omkring kl 18. Der har været lidt brug for at vi har arbejdet
ude for denne tidsramme så det har vi gjort ved at arbejde om aftenen eller på fridage.
Vi har gjort meget for at vi begge to er med hele tiden så man kender til de ting der foregår.
Under udviklingen af programmet har vi praktiseret XP (eXtreme Programming) programmering.
2.2. Procesmetoder
Udvikling af idéen
Udarbejdelse af
kravspecifikation
Analyse og
design
Side 7 af 50
Programmering
af spillet og
hjemmesiden
Som det kan ses på diagrammet kan vi kun gå et skridt tilbage i processen.
Denne model kaldes en vandfaldsmodel.
Dokumentation
og test
2.3. Arbejdsopdeling
Vi har delt arbejdet stort set lige op i mellem os. Tommy har erfaring med spilprogrammering i C++
så det har gjort os i stand til at indføre nogle avancerede elementer i programmet så han har brugt
lidt ekstra tid på at sætte kernen i programmet flot op.
Vi har gjort meget for at arbejde på de samme tidspunkter, enten sammen eller hjemmefra. Hele
kodedelen har vi udarbejdet sammen, mens dokumentationsskrivningen delvist er skrevet hver for
sig. Den eneste undtagelse var da Tommy programmerede kernen, da Christian arbejde på
dokumentationen.

Rapport – Objekt Orienteret Pacman spil
2.4. SWOT
En SWOT analyse skal vise projektets Styrker, Svagheder, muligheder og trusler. Vi har lavet en
SWOT analyse over vores og projekt. Den ser således ud.
STYRKER (Strengths) SVAGHEDER (Weaknesses)
Vi har begge stor erfaring med programmering. Vi er afhængige af Internettet til at anskaffe
oplysninger.
Vi har rutine i fejlhåndtering.
Projektet kræver visual studio, før man kan
Vi har et godt samarbejde.
arbejde og compile det.
Vilje til at arbejde den ekstra tid projektet måtte Det er et stort projekt og kræver fornuftig
kræve.
opbygning.
MULIGHEDER (Opportunities) TRUSLER (Threats)
Der er mange mulige teknologier som kan
bruges til projektet (Gfx: Torque, Opengl, Gdi,
Programmet kan ikke køre på skolens maskiner.
Direct3D Snd: Fmod, Directsound)
C++ Bugs (thread Deadlock, Leaks, overflow)
Projektet er godt skalerbart og vi kan nemt
tilføje flere ting.
Side 8 af 50
Sygdom i gruppen.
2.5. Problemstilling
Vi har analyseret vores projekt. Og fundet frem til følgende problemstillinger.
PS-1 Levetid
Beskrivelse Da vores spil er ret simpelt i forhold til mange andre spil på markedet bliver
det svært at opretholde brugerens lyst til at spille spillet. Vi skal derfor gøre
hvad der er muligt for at skabe en god stemning som kan holde fast i
brugeren.
PS-2 Grafik
Beskrivelse Spillet er lavet med ”gammeldags” grafik dvs 2D. Mange forventer i dag 3d
spil. Derfor er det vigtigt at grafikken bliver rar at se på så folk kan ”holde
ud” at se på et 2d spil.

Rapport – Objekt Orienteret Pacman spil
Kodestil
Til dette projekt følger vi nogle bestemte koderegler, så vi nemt kan læse hinandens kode.
Kodereglerne vil gøre det nemmere at undgå ændringer i kodestilen. På denne måde vil de
forskellige udvikleres kode få en glidende overgang, hvilket gør det meget nemmere at læse og
forstå koden. Reglerne vil også hjælpe mod sjusket kode og giver koden en længere levetid, da man
lettere kan genanvende koden. I sidste ende skulle det give koden et mere ensartet og professionelt
udseende.
2.5.1. Scope variabler
Når vi opretter variabler har vi et navnesystem til dem så det er nemmere at se hvor de stammer fra.
Hvis det er en variabel som er medlem i en klasse (attribut) så får den ”m_” foran som indikator.
m_xxxxx (Attribut. Variabel i en klasse)
g_xxxxx (global variabel)
xxxxx (lokal variabel)
2.5.2. Variabel typer
Når vi laver variabler så sørger vi for at det er muligt at læse hvilken type data variablen indeholder
ved at sætte et bogstav foran navnet. Dette bogstav repræsenterer datatype som det kan ses i
tabellen.
bXxxxx (bool)
iXxxxxx (int / heltal)
fXxxxxx (float / kommatal)
strXxxxx (String / Tekst)
oXxxxxx (Object)
cXxxxxx (class / instance)
2.5.3. Opbygning af if/for/while/do sætninger
Ved en sætning som skal udføre noget kode, starter man med ”{” på næste linje foran kommandoen.
Koden skal derefter tabuleres 1 gang ud. Afslutningen ”}” sker på samme linje som kommandoen.
if()
{
....
....
}
2.5.4. Opbygning af lykker
while()
{
....
....
}
for()
{
....
....
}
do()
{
....
....
} while (condition);
2.5.5. Funktion / metode opbygning
Ved opbygningen af en funktion indrammer vi det i kommentar linjer. Dette gøres for at forbedre
læsevenligheden så det er nemmere at lokalisere hvor en funktion starter.
Side 9 af 50

Rapport – Objekt Orienteret Pacman spil
Selve startsignalet til ny kode er en ”{” som bliver placeret under selve funktionen på samme
afstand. Hermed kommer koden på en ny linje hvor den bliver tabuleret 1 gang ud. Slutsignalet ”}”
står under koden på samme afstand som startsignalet.
//---------------------------------
function a()
//---------------------------------
{
...
}
2.5.6. Class opbygning
”Public” kommer først i oprettelse af klasser, derefter ”protected” og ”private”. De 2 første metoder
i klassen er altid ”constructor” og ”deconstructor”. Herefter er det metoder og attributter hele vejen
ned med ”public”, ”protected” og ”private” som rækkefølge.
class CName
{
//----------------------------
function CName()
//----------------------------
{
}
}
//----------------------------
function __destruct()
//----------------------------
{
}
//----------------------------
public function a()
//----------------------------
{
}
public m_a;
//----------------------------
protected function b()
//----------------------------
{
}
protected m_b;
//----------------------------
private function c()
//----------------------------
{
}
private m_c;
Side 10 af 50

Rapport – Objekt Orienteret Pacman spil
2.6. Teknologier
I vores projekt gør vi brug af flere teknologier.
Her er en opsummering af de teknologier vi bruger i projektet.
2.6.1. CSS / Xhtml
Hjemmesiden gør brug af HTML og CSS.
Vores hjemmeside er godkendt efter W3C
regler således at hjemmesiden er mere
kompatibel med flere browsere.
2.6.2. PHP
Vi har valgt at bruge PHP 5.03 til at skrive
hjemmesiden. Vi har begge erfaringer med dette
fra tideligere og vi kan godt lide PHPs struktur.
Med PHP har vi også mulighed for at lave en
hvis grad af objekt orienteret kode.
2.6.3. Templates
Vi bruger et template system. Temple systemet
fungere via PHP. PHPen har fået classer til hver
enkelt template vi bruger. Classen henter i sin
contructor templaten ind og via forskellige
funktioner kan classen fyldes med infomation
og det kan hentes ud igen. Dette betyder at der
er mange klasser på hver side når man skal have
vist indhold. Det kræver lide mere arbejde at
bruge dette system, men det er rart når der skal
rettes i det , da man kun skal
2.6.4. Apache
Vi bruger Apache 2.0 som webserver.
2.6.5. MySql
Vi har valgt at bruge MySQL 5.0 til vores
database server da den er gratis.
Side 11 af 50

2.6.6. C++
Selve pacman spillet er skrevet i C++. Vi har
valgt at bruge dette da Tommy har erfaring med
spil udvikling i C++ i forvejen. Og eftersom
Pacman spillet skal objekt orienteres synes vi
C++ er det mest naturlige valg.
Vi bruger Visual studio til at programmere C++.
2.6.7. Flash
Vi har valgt at lave en intro på hjemmesiden i
flash for at hjemmesiden ikke virker så ”død”
når man kommer ind på den. Vi har også lavet
en menu til hjemmesiden i flash.
For at give et godt førstehånds indtryk af
programmet har vi valgt at lave en CDmenu i
flash som køres automatisk når CDrommen
sættes ind i en computer.
2.6.8. GDI
Som grafik behandling bruger vi teknologien
GDI (Graphics Device Interface) som giver
muligheden for at tegne farver til skærmen.
Dette giver mulighed for at opbygge et spil og
dens layout via billeder som bliver behandlet af
GDI’s funktioner
2.6.9. FMOD
Til lyd behandling bruger vi FMOD som er et
ekstern software hentet fra fmod.org
Denne teknologi giver mulighed for at afspillet
mange forskellige musik og lyd formater. I
vores projekt bruger vi følgende lyd formater:
Mp3, mod, s3m og wav.
Rapport – Objekt Orienteret Pacman spil
Side 12 af 50

Rapport – Objekt Orienteret Pacman spil
3.
Analyse
Side 13 af 50

Rapport – Objekt Orienteret Pacman spil
Denne sektion består af analyser til projektet. Vi har overvejet og analyseret de forskellige aspekter
i programmet for at kunne komme videre til at skulle designe spillet og hjemmesiden. Det er ikke en
idé fase, men derimod nærmere en "Kan det lade sig gøre" og "hvordan gør vi det" fase.
3.1. Use case
Vores use case diagram illustrerer hvilke situationer som kan opstå i vores projekt. Dette er tegnet
ved aktører, som kommunikerer med hinanden. Selve mulighederne i programmet er skitseret som
en cirkel, hvor man kan læse funktionen.
3.1.1. Hjemmeside - Forside
På forsiden af vores hjemmeside har brugeren
mulighed for at:
3.1.1.1. Download Pacman
Downloader Pacman spillet.
(Ref: Swimlane 1, 4.2.1.4)
3.1.1.2. Se information om spillet
Brugeren får vist information om spillet inkl.
mulighed for at hente en manual
(Ref: Swimlane 1, 4.2.1.2)
3.1.1.3. Se highscores
Se de highscores der er blevet uploadet
(Ref: Swimlane 1, 4.2.1.1)
3.1.1.4. Forsiden
Sender brugeren til forsiden
(Ref: Swimlane 1, 4.2.1.3)
3.1.2. Spillets hovedmenu
Når spillet er startet kan brugeren enten begynde
et spil eller lukke det ned
3.1.2.1. Start spillet
Starter spillet
(Ref: Flowchart 1, 4.1.12)
3.1.2.2. Luk Spillet
Lukker spillet ned
(Ref: Flowchart 1, 4.1.1)
Side 14 af 50
Bruger
Spillets hovedmenu
Start spillet
Luk Spillet
Program

3.1.3. Indtast navn
3.1.3.1. Indtast navn
Når spillet er startet, skal brugeren indtaste sit
navn.
(Ref: Flowchart 1, 4.1.2)
3.1.3.2. Online
Spilleren har mulighed for at vælge, om han vil
have sin score uploadet til hjemmesiden, når
spillet slutter.
(Ref: Flowchart 1, 4.1.13)
3.1.3.3. Begynd spillet
Når navnet er indtastet, kan spillet startes.
(Ref: Flowchart 1, 4.1.3)
3.1.3.4. Luk spillet
Brugen kan lukke spillet på ethvert givent
tidspunkt.
(Ref: Flowchart 1, 4.1.1)
3.1.4. Inde i spillet
3.1.4.1. Bevæg Pacman
Når brugeren er inde i spillet, er der mulighed
for at bevæge Pacman.
(Ref: Flowchart 1, 4.1.4)
3.1.4.2. Pacman dør
Hvis brugeren ikke er forsigtig, kan Pacman dø.
(Ref: Flowchart 1, 4.1.8)
3.1.4.3. Game over
Hvis Pacman mister alle sine liv, er spillet slut.
(Ref: Flowchart 1, 4.1.15)
3.1.4.4. Powerup
Brugeren kan samle en powerup op med
Pacman, som gør ham i stand til at gøre noget
specielt.
(Ref: Flowchart 1, 4.1.6)
3.1.4.5. Næste bane
Når en bane er klaret, bliver brugeren sendt til
næste bane
(Ref: Flowchart 1, 4.1.9)
3.1.4.6. Luk spillet
Brugen kan lukke spillet på ethvert givent
tidspunkt.
Rapport – Objekt Orienteret Pacman spil
Side 15 af 50
Bruger
Indtast navn
Indtast navn
Online
Begynd spillet
Luk Spillet
Program

(Ref: Flowchart 1, 4.1.1)
3.1.4.7. Start forfra
Der er også mulighed for at starte spillet forfra.
(Ref: Flowchart 1, 4.1.14)
3.1.5. Game over
3.1.5.1. Vis highscore
Når spillet er slut får brugeren vist de lokale
highscores.
(Ref: Flowchart 1, 4.1.11)
3.1.5.2. Upload hihscore
Spillet uploader brugerens score, hvis der blev
givet lov til det, da spilleren skulle indtaste sit
navn.
(Ref: Flowchart 1, 4.1.10)
3.1.5.3. Afslut spillet
Brugen kan lukke spillet på ethvert givent
tidspunkt.
(Ref: Flowchart 1, 4.1.1)
3.1.5.4. Start forfra
Der er også mulighed for at starte spillet forfra.
(Ref: Flowchart 1, 4.1.14)
Rapport – Objekt Orienteret Pacman spil
Side 16 af 50

Rapport – Objekt Orienteret Pacman spil
3.2. Beskrivelse af use cases
Nedenstående bokse giver en beskrivelse af hver use-case. I boksene vil der være en kort forklaring
af formålet med ’casen’ og hvordan forløbet forventes at gå. Herefter er der små detaljer om deres
forudsætninger, deres aktører og hvad som sker bagefter. Da der ikke er plads til alle use-case
beskrivelserne kan resten findes i bilagene.
Use case navn: Bevæg pacman
Aktører: Bruger, program
Formål: Når spillet er i gang bliver denne funktion aktiveret hver gang en spiller trykker
på en af piltasterne. Funktionen checker brugerens input og kontroller om
pacman kan bevæge sig den vej
Normal Forløb: 1. Spillet er i gang
2. Brugeren trykker på en tast
Alternativ • Brugeren afslutter programmet
forløb:
• Pacman dør af et spøgelse
Forudsætter: Spillet ikke er i pause
Vejen er fri
Bagefter: Pacman begynder at bevæge sig den valgte vej
Use case navn: Upload highscore
Aktører: Bruger, program
Formål: Funktionen etablere kontakt til webserveren og sender brugerens score af sted.
Normal Forløb: 1. Pacman dør og scoren bliver sendt til webserveren.
Alternativ
forløb:
• Brugeren afslutter programmet
Forudsætter: Brugeren har valgt online highscore
Bagefter: Scoren bliver sendt til webserver og opbevaret i databasen.
Resten af use case beskrivelserne kan findes i Bilag 12 – Use-case Beskrivelser
Side 17 af 50

Rapport – Objekt Orienteret Pacman spil
4.
Design
Side 18 af 50

Rapport – Objekt Orienteret Pacman spil
4.1. Flowchart
Flowcharts er fantastiske diagrammer til at vise hvordan flowet i et program er.
Denne flowchart er lavet ud fra vores idéer og vores use cases.
Flowcharten viser hvordan vi har designet det logiske flow i programmet dvs. i hvilken rækkefølge
tinge skal aktivere hinanden.
Firkanter illustrer en proces og trekanter er en beslutning. En firkant med runde hjørner er en
terminator. Processens funktion er skrevet ned i kassen og grundlaget for den beslutning der står i
trekanten. På pilene som viser hvilken vej det skal gå står der hvad kriteriet var for at kunne komme
denne vej.
Side 19 af 50

4.1.1 Programmet lukkes
(Ref: Swimlane 1, 4.2.2.1)
4.1.2 Indtast navn menuen
(Ref: Swimlane 1, 4.2.2.2)
4.1.3 Spillet starter
(Ref: Swimlane 1, 4.2.2.12)
4.1.4 Flyt pacman
(Ref: Swimlane 1, 4.2.2.13)
4.1.5 Spøgelser og pacman
bliver sat tilbage til
start pos
(Ref: Swimlane 1, 4.2.2.28)
4.1.6 Aktiverer det
specielle ved
powerup
(Ref: Swimlane 1, 4.2.2.25)
4.1.7 Tilføj point til
highscore
(Ref: Swimlane 1, 4.2.2.26)
4.1.8 Pacman dør
(Ref: Swimlane 1, 4.2.2.27)
4.1.9 Start næste bane
(Ref: Swimlane 1, 4.2.2.18)
4.1.10 Upload highscore til
webserveren
(Ref: Swimlane 1, 4.2.2.33)
4.1.11 Vis highscore
(Ref: Swimlane 1, 4.2.2.31)
Rapport – Objekt Orienteret Pacman spil
Side 20 af 50
4.1.12 Start spillet?
(Ref: Swimlane 1, 4.2.2.4)
4.1.13 Spil online?
(Ref: Swimlane 1, 4.2.2.3)
4.1.14 Vil du spillet igen?
(Ref: Swimlane 1, 4.2.2.20)
4.1.15 Har pacman flere
liv?
(Ref: Swimlane 1, 4.2.2.19)
4.1.16 Var spillet online?
(Ref: Swimlane 1, 4.2.2.22)
4.1.17 Er der mere mad på
banen?
(Ref: Swimlane 1, 4.2.2.18)
4.1.18 Er det en powerup?
(Ref: Swimlane 1, 4.2.2.17)
4.1.19 Kan pacman spise
spøgelser?
(Ref: Swimlane 1, 4.2.2.16)
4.1.20 Hvad rammer
pacman på banen?
(Ref: Swimlane 1, 4.2.2.24)

Rapport – Objekt Orienteret Pacman spil
4.2. Swimlane
Swimlane diagrammet viser hvad der sker når brugeren kører programmet igennem. Man kan se
hvem der servicer brugeren og hvad de gør.
1. Hjemmeside
Første diagram viser hvordan kommunikationen er mellem bruger og server på vores hjemmeside.
Swim Lane - Hjemmeside
Start
Bruger
Åbner
hjemmesiden
Viser forsiden
Slut
Opdatere siden
Se highscore
Læs om pacman
Til forsiden
Hent pacman
Forlader hjemmesiden
4.2.1.1 Til forsiden
(Ref: Klassediagram 1, 5.3.2.CPageFront)
(Ref: IPO , Bilag 1, 29.1)
4.2.1.2 Hent pacman
(Ref: Klassediagram 1, 5.3.2.CPageDownload)
(Ref: IPO , Bilag 1, 28.1)
1
2
3
4
Side 21 af 50
Henter
informationer fra
database
Server
Sender Html
Sender Html
Sender Html
Sender fil
Sender Html
4.2.1.3 Se highscore
(Ref: Klassediagram 1, 5.3.2.CPageRank)
(Ref: IPO , Bilag 1, 30.1)
4.2.1.4 Læs om pacman
(Ref: Klassediagram 1, 5.3.2.CPageAbout)
(Ref: IPO , Bilag 1, 27.1)
Som diagrammet viser, har brugeren åbnet hjemmesiden hvorefter der er adgang til alle resurser på
siden Brugeren kan forlade hjemmesiden på hvilket som helst tidspunkt.

Rapport – Objekt Orienteret Pacman spil
2. Applikation del 1
Dette swimlane diagram viser hvordan brugeren og applikation ”snakker” sammen. Diagrammet
viser hvad applikationen gør når brugeren beder den om noget.
4.2.2.1 Afslut / Start spil
(Ref: Flowchart 1, 5.1.1.11)
4.2.2.2 Indtast navn
(Ref: Flowchart 1, 5.1.1.18)
4.2.2.3 Sæt online
(Ref: Flowchart 1, 5.1.1.18)
4.2.2.4 Afslut spil / Begynd
spil
(Ref: Flowchart 1, 5.1.1.18)
4.2.2.5 Åbner programmet
(Ref: Flowchart 1, 5.1.1.1)
4.2.2.6 Viser velkomsskærm
(Ref: Flowchart 1, 5.1.1.5)
4.2.2.7 Opretter og klargøre
app
(Ref: Flowchart 1, 5.1.1.3)
Side 22 af 50
4.2.2.8 Ændre state til
indtast navn
(Ref: Flowchart 1, 5.1.1.10)
4.2.2.9 Viser indtast navn
skærm
(Ref: Flowchart 1, 5.1.1.10)
4.2.2.10 Opbevare navnet
(Ref: Flowchart 1, 5.1.1.19)
4.2.2.11 opbevare valg
(Ref: Flowchart 1, 5.1.1.19)
4.2.2.12 Klargøre alle spil
objekter og variabler
(Ref: Flowchart 1, 5.1.1.21)
Første del af diagrammet viser hvordan brugeren kommer igennem de første menuer inden han kan
spillet. Diagrammet fortsætter på næste side. Her kan man se hvad der sker når spillet er startet.

Applikation del 2
Rapport – Objekt Orienteret Pacman spil
Side 23 af 50

4.2.2.13 Bevæger pacman
(Ref: Klassediagram 1, 5.3.1.2.CGameObject)
(Ref: IPO , Bilag 1, 14.9)
4.2.2.14 Afslut spil / Genstart
spil
(Ref: Klassediagram 1, 5.3.1.3.CGameHandler)
(Ref: IPO , Bilag 1, 5.8)
4.2.2.15 Spøgelse
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.8)
4.2.2.16 Dødeligt spøgelse
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.8)
4.2.2.17 Mad / Powerup
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.8)
4.2.2.18 Næste bane / Fortsæt
uændret
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.7)
4.2.2.19 Flere liv / Ingen liv
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.7)
4.2.2.20 Afslut spil / Genstart
spil
(Ref: Klassediagram 1, 5.3.1.3.CGameStateHighscore)
(Ref: IPO , Bilag 1, 16.5)
4.2.2.21 Ingen rekord / På
top10
(Ref: Klassediagram 1, 5.3.1.3.CGameStateHighscore)
(Ref: IPO , Bilag 1, 16.8)
4.2.2.22 Ikke online / Online
(Ref: Klassediagram 1, 5.3.1.3.CGameStateHighscore)
(Ref: IPO , Bilag 1, 16.2)
Rapport – Objekt Orienteret Pacman spil
Side 24 af 50
4.2.2.23 Viser spillet
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.5)
4.2.2.24 Collision check med
pacman
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.8)
4.2.2.25 Aktiver powerup
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.8)
4.2.2.26 Giv point
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.8)
4.2.2.27 Mister 1 liv
(Ref: Klassediagram 1, 5.3.1.3.CGameStateGame)
(Ref: IPO , Bilag 1, 15.13)
4.2.2.28 Klargør resurserne
og genstart spillet
(Ref: Flowchart 1, 5.1.1.15)
4.2.2.29 Klargør resurserne
og genstart spillet
(Ref: Flowchart 1, 5.1.1.15)
4.2.2.30 Check highscore
(Ref: Flowchart 1, 5.1.1.24)
4.2.2.31 Vis highscore
(Ref: Flowchart 1, 5.1.1.24)
4.2.2.32 Registrer highscore
(Ref: Flowchart 1, 5.1.1.24)
4.2.2.33 Register online
highscore
(Ref: Flowchart 1, 5.1.1.24)

Rapport – Objekt Orienteret Pacman spil
4.3. Detaljeret forklaring af spillets features
• Pacman er en lille gul ”ost” der spiser mad.
• 4 spøgelser med hver deres personlighed til at jagte Pacman.
• Pacman skal spise al maden på banen for at vinde.
• Alt Pacman spiser giver point.
• Hvis spøgelserne fanger Pacman mister Pacman et liv.
• Pacman starter med 3 liv.
• Scoren starter på 0.
• Normal mad giver 10 point.
• Store stykker mad giver 100 point.
• Hvis pacman spiser et stort stykke mad kan han spise spøgelserne i 10 sekunder. Hvert
spøgelse pacman spiser giver 200 point, gange 2^ i det antal spøgelser han har spist inden
for de 10 sekunder. Dvs 200/400/800/1600 point. Der er 4 stykker mad af denne type på en
bane. Hvis pacman spiser endnu et stykke stort mad mens han stadig har det aktivt starter 10
sekunders tælleren bare forfra. Den gemmer det antal spøgelser pacman har spist.
• Når et spøgelse er blevet spist skal det finde tilbage til deres hule som er i midten af banen.
Hvorefter det bliver til et normalt spøgelse igen.
• Banen er bygget op af klodser.
• Der er en genvej mellem siderne af banen. Dvs at går man ud af den genvej kommer man
om på den anden side af banen.
• Hvis pacman spiser al maden bliver han sendt videre til næste bane.
• Spøgelserne bliver mere aggressive jo længere man når. De bliver ikke inde i kassen lige så
længe som på forrige bane og bruger mere tid på at jagte pacman for hver bane.
• Der er tid på hver bane. Spilleren har 5min til at klare første bane. Næste bane har spilleren
4:45. næste igen 4:30 osv.
4.4. Grafik Buffer
Selve spillet vil blive designet med dobbeltbuffer således at grafikken bliver opbevaret 2 steder.
Dette er for at undgå flimmer. Hvis man både tegner og viser i den samme arbejdsbuffer, vil
brugeren kunne se hvordan tingene fremkommer og det kan virke forstyrrende. Så for at gøre det så
pænt som muligt, laver vi det således, at vi har en visning og en arbejds buffer. Resultatet bliver
således at vi tegner og arbejder i den ene buffer og når vi har opdateret spillet så lægger vi resultatet
over på den anden buffer. Således at den ene buffer konstant viser resultat og den anden bliver
slettet ved hver frame og tegnet om igen.
Side 25 af 50

4.5. Kunstig intelligens
Rapport – Objekt Orienteret Pacman spil
Selve spillet består af 4 spøgelser med hver deres udseende og intelligens. Spøgelsernes opgave er
at forhindre pacman i at klare banen. Denne opgave kræver at hvert spøgelse har en taktik og bedst
muligt får presset pacman til at fejle.
Fælles regler.
• Ingen spøgelser kan dreje mod dem selv (180 grader)
• Spøgelsernes tid når de er dødelige er fælles hos dem alle.
• Spøgelsernes hastighed når de er dødelige er halveret
• Når spøgelserne er dødelige prøver de alle at komme væk fra pacman
• Spøgelsernes tid efter de er blevet spist og er i startstedet er fælles.
Spøgelser
Taktik
Blinky
Blinky vil jage sit
mål ved at
fokusere mest på
horisont aksen.
Pinky
Pinky vil jage sit
mål ved at
fokusere mest på
vandret aksen.
Side 26 af 50
Inky
Inky vil jage sit
mål ved at gå efter
den længste
afstand på aksen.
Clyde
Clyde har ingen
favorit retning,
men holder sig
stadig nær Pacman.
Start tid 0 sek(Starter ude) 0 sekunder 6 sekunder 10 sekunder
Situation Blinky løsning Pinky løsning Inky løsning Clyde løsning

Rapport – Objekt Orienteret Pacman spil
Spøgelserne vil ikke konstant jage pacman, men derimod holde
en kort pause engang imellem og søge mod deres hjemsted.
Årsagen til dette er at der ikke hele tiden skal være 4 spøgelser
på ryggen af pacman, men derimod at de er mere spredt rundt
omkring på banen. Dette betyder at hvert spøgelse vil have et
tidsinterval som bestemmer hvornår de skal søge efter deres
hjemsted og hvornår de skal være aggressive.
4.6. Timer
En timer bruges til at sikre at alle computere bevæger
objekterne med samme hastighed. Hvis man ikke bruger en
timer vil objekterne bevæge sig efter hvor mange gange en while løkke bliver kørt. Hvis en cpu vil
kunne trække hele spil-løkken 80 gange, så vil objekter rykke sig 80 gange. Dette vil ikke være så
smart hvis man finder en anden maskine som kun kan trække spil-løkken 17 gange, da dette vil
formindske alle objekternes bevægelse.
Måden man fikser dette, er ved er at tage en start tid ved løkke-start og en slut tid når løkken er slut.
Herfra kan man udregne en delta tid som vil variere efter hvor hurtig løkken blev kørt. Denne værdi
kan nu bruges til at gange med objektets hastighed og hermed vil hastigheden variere efter hvor
hurtig løkken blev kørt. Dette betyder at en hurtig computer vil få en lav værdi og hver objekt vil
rykke meget lidt per løkke-kald som giver en flydende bevægelse. Hvorimod en langsom computer
får en høj værdi som for objekter til at springe, således at objekter stadig opfylder deres hastighed.
4.7. Billeder
Billede behandling bruger vi til at vise objekter på skærmen. Da vi har nogle krav til dette såsom
rotation og ’masking’ kræver det lidt udregninger før det kan lade sig gøre. Normalt kan GDI api’en
Side 27 af 50

Rapport – Objekt Orienteret Pacman spil
loade .bmp filer uden problemer, men når man skal rotere det og lave ’masking’ kræver det lidt
ekstra arbejde.
Måden ’masking’ virker på er ved at danne et monokromt billede ud fra originalen. Dette gøres ved
at oprettet et tomt monokrom bitmap og kopiere originalen (Figur 1) over til det monokrome-bitmap
(Figur 2). Hermed sker der en konversion således at billedet bliver sort / hvid ud fra hvilke farve
man har valgt som masking-farve.
Til sidst er det nu muligt at tegne grafik ud fra masking billedet således at man får alt det
unødvendige grafik skåret væk.
Den anden vigtige ting vi har fået med i billede behandling er rotation. Dette gør det muligt at rotere
et stykke grafik et vist antal grader således at man ikke behøver at have et billede for hver retning.
Dette ses hvor vi skaber banen som kræver at vi vender og drejer hver stump så de passer sammen.
Det sammen med pacman som skal kunne dreje rundt i labyrinten.
Måden det bliver foretaget på er ved at tage oplysninger fra bitmappet og ellers lave en matematisk
udregning på hvert enkelt pixel i billede og så gemme position resultatet i et bitmap. Udregningen
ser således ud:
Side 28 af 50

Rapport – Objekt Orienteret Pacman spil
5.
Endeligt
Programdesign
Side 29 af 50

5.1. Flowchart
Forklaring af flowcharts findes i punkt 4.1
Rapport – Objekt Orienteret Pacman spil
Denne flowchart er lavet efter programmet er blevet skrevet færdigt. Funktions og klasse navne er
inkluderet i diagrammet.
I forhold til sidst har vi fået 2 nye figurer. En cirkel er et loop. Loopets kriterium står i cirklen.
En aflang firkant betyder en ny tråd.
Programmet
startes
Oprydning:
9
Gamestate skiftes
til Menu.
Brugeren skal
indtaste navn og
vælge og om
highscores skal
være online
18
Spillet begyndes
Oprydning:
19
Gamestate skiftes
til Game.
Vinduet,
Pacwindow bliver
startet
Gameloop
1
Start spillet
Menuen til vinduet
bliver skabt.
Spillets tråd startes.
kører
Brugeren
skal vælge et
menupunkt
10 11
20
Spillet kører.
17
Banen Loades og
tegnes.
Entiter bliver sat
ind i spillet
21
Oprydning:
22
Spillet er slut
Oprydning:
Gamestate skiftes
til Gameover.
Side 30 af 50
Afslut spillet
Gamehandler bliver
startet.
Spillets Tråd
ukkes ned.
Spillet
startes
forfra
Vinduet bliver
kaldt med et lukke
kald
12
Spillet lukkes ned
Bliver spillet
startet forfra?
Lokal highscore
bliver hentet frem.
Lokalhighscore
gemmes igen.
Highscoren bliver
uploadet hvis det er
valgt.
Timeren startes.
2 3 4
16
23
8
7
15
24
Intro skærmen
startes.
Vent på der sker
noget med
vinduet
6
5
Loop
Vinduet lukkes ned
Deinit kørende
elementer
13
Programmet
afsluttes
14
Flowcharten viser hvordan flowet i programmet hænger sammen. Som det kan ses bliver spil delen
lagt over i sin egen windowstråd. Dette gør det muligt at brugeren altid kan få kontakt til selve
vinduet så han f.eks kan minimere eller lukke det.

5.1.1.1 Vinduet, Pacwindow
bliver startet
(Ref: Sekvensdiagram 1, 5.4.1)
5.1.1.2 Menuen til vinduet
bliver skabt.
(Ref: Klassediagram 1, 5.3.1.1.CPacWindow)
(Ref: IPO , Bilag 1,4.6)
5.1.1.3 Gamehandler bliver
startet
(Ref: Klassediagram 1, 5.3.1.3.CGameHandler)
(Ref: IPO , Bilag 1,5.2)
5.1.1.4 Timeren startes
(Ref: Klassediagram 1, 5.3.1.1.CTimer)
(Ref: IPO , Bilag 1,3.1)
5.1.1.5 Intro skærmen
startes
(Ref: Sekvensdiagram 1, 5.4.3)
5.1.1.6 Vent på der sker
noget med vinduet
(Ref: Klassediagram 1, 5.3.1.1.CPacWindow)
(Ref: IPO , Bilag 1,4.1)
5.1.1.7 Spillets tråd hThread
lukkes ned
(Ref: IPO , Bilag 1,5.3)
(Ref: Klassediagram 1, 5.3.1.3. CGameHandler)
5.1.1.8 Spillets tråd startes
(Ref: IPO , Bilag 1,5.2)
(Ref: Klassediagram 1, 5.3.1.3. CGameHandler)
5.1.1.9 Oprydning intro
(Ref: Sekvensdiagram 1, 5.4.7)
5.1.1.10 Gamestate skiftes til
menu
(Ref: IPO , Bilag 1,5.1)
(Ref: Klassediagram 1, 5.3.1.3. CGameHandler)
5.1.1.11 Brugeren skal vælge
et menupunkt
(Ref: IPO , Bilag 1,17.6)
(Ref: Klassediagram 1, 5.3.1.3. CGameStateIntro)
5.1.1.12 Vinduet bliver kaldt
med et lukke kald
(Ref: IPO , Bilag 1,4.1)
(Ref: Klassediagram 1, 5.3.1.1. CPacWindow)
Rapport – Objekt Orienteret Pacman spil
Side 31 af 50
5.1.1.13 Deinit kørende
elementer
(Ref: Klassediagram 1, 5.3.1.3.CGameHandler)
(Ref: IPO , Bilag 1,5.3)
5.1.1.14 Programmet afsluttes
(Ref: Sekvensdiagram 1, 5.4.22)
5.1.1.15 Bliver spillet startet
forfra?
(Ref: Klassediagram 1, 5.3.1.3.CGameHighscore)
(Ref: IPO , Bilag 1,16.5)
5.1.1.16 Oprydning game
(Ref: Sekvensdiagram 1, 5.4.14)
5.1.1.17 Spillet kører
(Ref: Klassediagram 1, 5.3.1.3. CGameStateGame)
(Ref: IPO , Bilag 1,15.2)
5.1.1.18 Brugeren skal
indtaste navn og
vælge og om
highscores skal være
online
(Ref: Sekvensdiagram 1, 5.4.6)
5.1.1.19 Oprydning menu
(Ref: Sekvensdiagram 1, 5.4.8)
5.1.1.20 Gamestate skiftes til
game
(Ref: IPO , Bilag 1,5.1)
(Ref: Klassediagram 1, 5.3.1.3. CGameHandler)
5.1.1.21 Banen loades og
tegnes
(Ref: Sekvensdiagram 1, 5.4.10)
5.1.1.22 Oprydning highscore
(Ref: Sekvensdiagram 1, 5.4.20)
5.1.1.23 Gamestate skiftes til
gameover
(Ref: IPO , Bilag 1,5.1)
(Ref: Klassediagram 1, 5.3.1.3. CGameHandler)
5.1.1.24 Lokal highscore
bliver hentet frem...
(Ref: IPO , Bilag 1,16.6)
(Ref: Klassediagram 1, 5.3.1.3. CGameStateHighscore)

Diagrammet viser hvordan spøgelserne virker.
Rapport – Objekt Orienteret Pacman spil
Diagrammet viser, med tekst, hvordan spøgelserne kommer i gennem deres programflow. Der er
ikke skrevet hvilke funktioner der bliver kaldt, men derimod hvilke kriterier der bestemmer hvilken
del af spøgelsernes funktionalitet der skal aktiveres.
5.1.2.1 Ghost init
(Ref: Sekvensdiagram 1, 5.4.11)
(Ref: IPO , Bilag 1,6.3)
(Ref: Klassediagram 1, 5.3.1.2. CGameEntity)
5.1.2.2 Tegn grafik
(Ref: IPO , Bilag 1,7.2)
(Ref: Klassediagram 1, 5.3.1.2. GGhost)
5.1.2.3 Spillet starter
(Ref: IPO , Bilag 1,15.9)
(Ref: Klassediagram 1, 5.3.1.3. CGameStateGame)
5.1.2.4 Spillet slutter
(Ref: IPO , Bilag 1,15.7)
(Ref: Klassediagram 1, 5.3.1.3. CGameStateGame)
5.1.2.5 Bevæg væk fra
pacman
(Ref: IPO , Bilag 1,7.15)
(Ref: Klassediagram 1, 5.3.1.2. GGhost)
Side 32 af 50
5.1.2.6 Start forfra i huset
(Ref: IPO , Bilag 1,7.4)
(Ref: Klassediagram 1, 5.3.1.2. GGhost)
5.1.2.7 Jeg er død. Ryk mod
huset
(Ref: IPO , Bilag 1,7.14)
(Ref: Klassediagram 1, 5.3.1.2. GGhost)
5.1.2.8 Udregn hvilken vej
jeg skal gå
(Ref: IPO , Bilag 1,7.1)
(Ref: Klassediagram 1, 5.3.1.2. GGhost)
5.1.2.9 Gå til ’mit’ område
(Ref: IPO , Bilag 1,7.1)
(Ref: Klassediagram 1, 5.3.1.2. GGhost)
5.1.2.10 Ghost deinit
(Ref: Sekvensdiagram 1, 5.4.12)
(Ref: IPO , Bilag 1,6.4)
(Ref: Klassediagram 1, 5.3.1.2. CGameEntity)

Rapport – Objekt Orienteret Pacman spil
5.2. Database
Vi har en enkelt database som kører på en mysql server. Databasen indeholder en tabel. Vi gemmer
kun vores highscores til hjemmesiden på mysql.
Highscores
Navn Type
Navn
Highscore
Dato
Varchar(50)
Int
Datetime
Side 33 af 50

5.3. Klassediagram
Forklaring af alle elementer i klasse diagrammet.
5.3.1. Pacman spillet
5.3.1.1. Utilities / Tools
Rapport – Objekt Orienteret Pacman spil
Nedenstående billede under viser selve klassediagrammet over vores utilities og værktøjer. Dette
består af klasser som hjælper til med at opbygge programmet. Hvis man kigger i første boks som
består af Utilites som CLog, CInternet og CTimer, så bliver disse brugt rundt omkring i programmet
og virker som tilbehør til andre klasser. Forstået således at hvis en anden klasse har brug for at
udskrive en fejllog så bruger den CLog eller hvis en skal tilgå nettet så er det CInternet.
Vi har også en samling af Struct / Enum som kort sagt består af en samling værdier. Dette gør det
mere læseligt og mere kompakt at have flere variabler pakket end i en struct. Dette giver fordele når
man kaster rundt med værdier i parameter at man kan nøjes med 1 navn og ikke hvert element inde i
pakken..
Den sidste kasse består af CPicture, CGameMap og CPacWindow. Disse klasser er vigtige
redskaber for at få programmet op og kører. Selve CGameMap håndtere alt der med banen at gøre.
CPicture håndterer billederne og CPacWindow behandler alt der har med selv vinduet at gøre..
Side 34 af 50

Rapport – Objekt Orienteret Pacman spil
5.3.1.2. Entiteter
Selve klassediagrammet over vores entiteter. Vores entititer i spillet består af de levende objekter
som kræver noget grafik og logisk behandling. Måden selve strukturen virker på er at alle objekter
nedarver fra ’Interfacet’ CGameEntity således at alle underklasser er tvunget til at have metoden
Draw() og Handle(). Så kort sagt er et interface blevet bestemt som alle skal overholde.
Den næste klasse i arkivet er ’CGameObject’ som håndterer standard egenskaberne i et spil objekt.
Dette er ting som kollision check op mod banen og bevægelse af objektet. Denne klasse er
’Abstrakt’ da den indeholder en del kode og attributter i forhold til interfacet. Selve klassen kan
man dog ikke oprette en instance af da den er abstrakt og kræver at et andet objekt har nedarvet og
overskrevet nogle af dens metoder.
Dette kan vi se på klassediagramet hvor en masse klasse objekter nedarver og overloader med deres
egne metoder. Dette er ting som Pacman, Frugt, Powerup, Teleport og spøgelserne. Det smarte ved
hele denne struktur er at man ved overordnet at alle klasser har Draw() og Handle() metoderne da
interfacet tvinger dem ind. Dette kan man udnytte i koden og bruge når man skal tegne og opdaterer
alle objekter på en gang. Så behøver man ikke spekulerer på hvilke type objekt det er, da de alle har
egenskaberne fra CGameEntity.
Side 35 af 50

Rapport – Objekt Orienteret Pacman spil
Side 36 af 50

5.3.1.3. Gamestate
Rapport – Objekt Orienteret Pacman spil
Klassediagrammet for tilstanden i spillet. Selve spillet kan være i 4 tilstande og det er Intro, Menu,
Spillet eller i highscore. Til dette har vi en klasse til at behandle hver tilstand. Disse klasser har til
ansvar at skabe de nødvendige resurser til kørsel af scenen og ellers kalde de funktioner som er
nødvendige.
Overordnet kørsel bliver styret af ’CGameHandler’ som opretter klassen for den nuværende tilstand
og ellers holder styr på tilstanden og giver dem de informationer som de har behov for.
5.3.2. Hjemmeside
Klassediagrammet over vores hjemmeside. Hjemmesidens klasser er inddelt i 3 felter hvor det ene
er templates, siderne og værktøjerne. Selve værktøjerne er globale og statiske metoder som vi kan
bruge løbende til hjælp. Dette er ting som forbindelse til databasen og udskrivning til logfilen.
Selve ’CPage’ klassen virker som et interface, som bestemmer hvilke metoder som underklasserne
skal have. Dem som nedarver er dermed tvunget til at oprette GetContext(), GetJavaScript() og
GetTile(). Selve disse metoder bliver brugt til at skabe en Xhtml side. Da hjemmesiden består af 4
punkter (Forside, Download, Info og Top10) er der en klasse til hver side.
Det sidste felt er klasser over templates. Overordnet er der en abstrakt klasse ’CTpl’ som giver et
par standard metoder og attributter som layout. Underklasserne kan dermed bruge Load() metoden
Side 37 af 50

Rapport – Objekt Orienteret Pacman spil
som de har nedarvet og nemt loade deres tilhørende template fil. Selve hver underklasse har til
ansvar at styre hver deres template (xhtml) fil og tilpasse indholdet ved deres GetContent() metode.
Side 38 af 50

5.4. Sekvensdiagram
Rapport – Objekt Orienteret Pacman spil
Vores sekvensdiagram, som findes på næste side, giver en oversigt over levetiden af objekterne og
rækkefølgen de bliver oprettet i.
I diagrammet kan man se at første punkt er brugeren som starter programmet. Hermed bliver
klassen CPacWindow aktiveret som styrer vinduet. Lige efter bliver klassen CGameHandler
aktiveret og denne sørger for noget grafik inde i vinduet. Det første grafik som fremkommer er
introen. Dermed er det ’CStateIntro’ som kører, og samtidig har CGameHandler også sat noget
musik på via FMod klassen.
Når introen afslutter så hopper den tilbage til CGameHandler som herefter sætter næste tilstand i
gang som er ’CStateMenu’. Selve musikken bliver ved med at afspille. Når menuen afsluttes, så
bliver der sat gang i et par ting. Selve musikken stopper og ’CStateGame’ bliver aktiveret som også
starter ’CEntities’ og ’CMap’. Disse ting vil køre synkroniseret med hinanden indtil spillet afslutter
og når dette sker, vil ’CStateHighscore’ overtage. Ved ’CStateHighscore’ vil ny musik blive
afspillet og under kørsel af ’cStateHighscore’ vil klassen ’CInternet’ blive brugt som sender scoren
til hjemmesiden. Når CInternet er afsluttet, så for ’CGameHandler’ besked og den kan beslutte sig
for at lukke grafikken og vinduet ned, således at programmet lukker.
Side 39 af 50

Rapport – Objekt Orienteret Pacman spil
Side 40 af 50

5.4.1 Starter App
(Ref: IPO , Bilag 1,4.3)
(Ref: Klassediagram 1, 5.3.1.1 CPacWindow)
5.4.2 Starter grafik
(Ref: IPO , Bilag 1,5.2)
(Ref: Klassediagram 1, 5.3.1.3 CGameHandler)
5.4.3 Starter intro
(Ref: IPO , Bilag 1,17.2)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateIntro)
5.4.4 Afspiller intro musik
(Ref: IPO , Bilag 1,5.1)
(Ref: Klassediagram 1, 5.3.1.3 CGameHandler)
5.4.5 Stopper intro musik
(Ref: IPO , Bilag 1,5.1)
(Ref: Klassediagram 1, 5.3.1.3 CGameHandler)
5.4.6 Starter menu
(Ref: IPO , Bilag 1,18.2)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateMenu)
5.4.7 Afslutter intro
(Ref: IPO , Bilag 1,17.3)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateIntro)
5.4.8 Afslutter menu
(Ref: IPO , Bilag 1,18.3)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateMenu)
5.4.9 Starter spillet
(Ref: IPO , Bilag 1,15.2)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateGame)
5.4.10 Skaber banen
(Ref: IPO , Bilag 1,13.1)
(Ref: Klassediagram 1, 5.3.1.1 CGameMap)
5.4.11 Skaber entities
(Ref: IPO , Bilag 1,15.9)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateGame)
Rapport – Objekt Orienteret Pacman spil
Side 41 af 50
5.4.12 Fjerner entities
(Ref: IPO , Bilag 1,15.14)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateGame)
5.4.13 Fjerner banen
(Ref: IPO , Bilag 1,13.2)
(Ref: Klassediagram 1, 5.3.1.1 CGameMap)
5.4.14 Afslutter spillet
(Ref: IPO , Bilag 1,15.3)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateGame)
5.4.15 Viser highscore
(Ref: IPO , Bilag 1,16.2)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateHighscore)
5.4.16 Play highscore
musik
(Ref: IPO , Bilag 1,16.2)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateHighscore)
5.4.17 Opretter forbindelse
til online highscore
(Ref: IPO , Bilag 1,1.3)
(Ref: Klassediagram 1, 5.3.1.1 CInternet)
5.4.18 Afslutter forbindelse
(Ref: IPO , Bilag 1,1.2)
(Ref: Klassediagram 1, 5.3.1.1 CInternet)
5.4.19 Stop highscore
musik
(Ref: IPO , Bilag 1,16.3)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateHighscore)
5.4.20 Afslutter highscore
(Ref: IPO , Bilag 1,16.3)
(Ref: Klassediagram 1, 5.3.1.3 CGameStateHighscore)
5.4.21 Grafik lukker
(Ref: IPO , Bilag 1,5.3)
(Ref: Klassediagram 1, 5.3.1.3 CGameHandler)
5.4.22 Vinduet lukker
(Ref: IPO , Bilag 1,4.4
(Ref: Klassediagram 1, 5.3.1.1 CPacWindow)
5.5. IPO
IPO står for Input Procedure Output. Vi har lavet et komplet diagram af alle vores klasser og dets
funktioner. Det er sat op i tabeller som set under denne tekst.
Overordnet viser hver tabel en klasse og alle dets funktioner.

Rapport – Objekt Orienteret Pacman spil
Som man kan se viser det funktionens navn, dets input og output. Nedenunder står en kort
forklaring af funktionen.
Klassens navn
Funktionens navn Input type Output type
Kort forklaring af funktionen.
Alle klasser og funktioner er beskrevet i Bilag 1 – IPO diagram.
CInternet
Procedure Input Output
InitInternet() void bool
Bruges til at klargøre net klassen og sætte forbindelse typen. Returnere sand/falsk om det gik godt
DeInitInternet() void bool
Fjerner alle de resurser som er loadet ind til brug af net-klasen
Connect() char *Url, char* Web_File, int iPort bool
Opretter forbindelse til domainet ’Url’ og åbner filen ’Web_File’ på porten ’iPort’
Eksempel:
Klassen Cinternet indeholder følgende funktioner: InitInternet(), DeInitInternet() og Connect().
InitInternet() kræver intet input og har en bool som output.
Funktion bruges til at klargøre klassen og output bool fortæller om det gik godt eller skidt.
InitInternet() kræver intet input og har en bool som output.
Funktion bruges til at rydde op i klassen. Den fjerner alle resurser der er taget i brug og output bool
fortæller om det gik godt eller skidt.
Connect() kræver 3 input parametre og har en bool som output. Den skal have en char pointer til
”URL”, en char pointer til ”Web_file” og en port som int.
Funktionen strikker de tre inputs sammen til en streng og prøver at forbinde til den
sammenstrikkede url. Den returnere en bool om det gik godt eller skidt.
Alle klasser og funktioner er beskrevet i Bilag 1 – IPO diagram.
Side 42 af 50

Rapport – Objekt Orienteret Pacman spil
5.6. Client / Server / sikkerhed
Kommunikationen mellem klienten og serveren forgår via http. Selve klienten laver et request til
serveren hvor data’en ankommer med metoden ’GET’. Dette vil i vores eksempel være noget
lignende dette:
UploadHighscore.php?Score=MTAw&Checksum=MjEw&Navn=VE9NTVk=
Ikke muligt at læse i ONLINE-versionen, da top10 highscoren skal være retfærdigt! sorry...
Side 43 af 50

Rapport – Objekt Orienteret Pacman spil
5.7. Guldkorn
Vi har valgt nogle kodestumper ud som vi mener, er ”Guldkorn”. Disse kodestumper har vi brugt til
at løse nogle specielle problemer eller tilføre en bestemt funktionalitet til vores kode.
5.7.1. Exception handling:
Exception handling bruges de steder hvor
man har mistanke om at programmet kan
gå ned.
Ved disse steder kan man bruge
exception handling således at hvis
programmeret gør noget ulovligt så
bliver det spolet tilbage til hvor
programmet virkede.
Et eksempel er når vi håndtere Internettklassen
og dens udfald kan svinge. Der er
meget kode som bliver kørt igennem for
at kontakte en server. Herefter er det
også muligt at ændre i vores konfig fil
hvilke server som skal kontaktes.
5.7.2. Funktion overloading:
Funktion overloading bruges de steder
hvor programmøren kan have behov for
at kalde en metode forskelligt.
Forstået således at en metode() kan
modtage flere og forskellige parameter
ved samme metode navn.
Et godt eksempel er når vi loader
billeder, så kan man kalde den ved flere
metoder. Hvor stien er angivet og hvor
både stien og rotationen er angivet.
Dermed kan man selv bestemme om
billedet skal rotere eller beholde den
oprindelige indstilling.
Side 44 af 50

5.7.3. Multithread:
Multithread bruges hvor man gerne vil
dele programkørsels i flere bider. Således
at flere stykker kode kan køre
usynkroniseret.
Dette ses tit i IO-behandling hvor man
ikke vil have at bestemt kode skal bremse
selve hovedprogrammet.
I vores projekt har vi brugt det til at
adskille spillet og vinduet. Således at
spillet kan fortsætte med at køre selvom
man bruger vinduet’s muligheder som
menuen og højre-klip popup.
5.7.4. Operator overloading:
Operator overloading bruges til at
overloade en operator til at kunne flere
ting. En operator består af standard tegn
med hver deres betydning som: + - * / ^ |
|| & && < > += ^= osv...
Denne type teknologi bruges allerede i
std::string hvor det er muligt at bruge
operatoren += til at tilføje tekst, eller + 2
strings sammen.
I vores kode har vi brugt det i CLog til at
vise hvordan det kan gøres. I selve vores
CLog klasse har vi overloaded
operatoren xor ^, således at den udskriver
tekst til log filen.
Rapport – Objekt Orienteret Pacman spil
Side 45 af 50

Rapport – Objekt Orienteret Pacman spil
5.7.5. OOP (Objekt orienteret programmering)
(Indkapsling, Nedarving og Polymorf)
OOP programmering er når man
udvikler i objekter som bruger
indkapsling, nedarving og polymorf.
I vores tilfælde bruger vi meget
indkapsling og dette kan ses ved keyordene
’public’, ’protected’ og ’private’.
Her bestemmer vi hvem som må tilgå
hvad i klassen.
Nedarving bruger vi når objekter har
samme egenskaber og dette kan ses i
vores abstrakte spøgelse-klasse hvor de
4 spøgelser nedarver fra.
Polymorf bruger vi til alt som har
nedarvet fra CEntity klassen. CEntity
klassen er hvad som man kalder en
interface og er abstrakt. Dette betyder at
man ikke kan oprette en instance af den,
men derimod kun kan nedarve fra den.
Det vi så gør med alle dem som nedarver
fra den er at overloade dens pure-virtual
metoder således at det bliver de nedarves
klasser metoder som bruges (Polymorf).
Side 46 af 50

5.7.6. Bane loading
Selve vores Pacman bane er gemt i en
tekst fil hvor banen er opbygget i
ascii. Dette giver mange fordele son
nem redigering og nem opbevaring
(database, tekstfil, xml osv...)(Figur 1)
Da den rå data ikke indeholder hvilke
grafik som skal bruges til murene, så
har vi lavet en metode som løber alle
’x’erne igennem og finder hvor
mange naboer de har. Herefter
analysere den hvor naboerne er
placeret og giver dem et uniq ID
nummer som fortæller hvilke billeder
som skal bruges.
(Figur 2)
Det smarte ved dette er at vi nemt kan
redigere banen uden at spekulere om
hvilke retning muren skal vende, da
dette bliver skabt inde i spillet.
Resultat kan ses i (Figur 3) hvor alt
grafikken er loadet ind og bliver vist
med .bmp billeder. Her kan man se
hvordan hvert ascii karakter er blevet
erstattet med et billede med størrelse
24*24.
Rapport – Objekt Orienteret Pacman spil
Side 47 af 50

Rapport – Objekt Orienteret Pacman spil
6.
Konklusion
Side 48 af 50

6.1. Konklusion
Rapport – Objekt Orienteret Pacman spil
Hvis man skal kigge på hele projektet og dets omfang er vi begge meget tilfredse med hele forløbet.
At skabe et Objekt Orienteret pacman spil, har været en interessant udfordring synes vi begge to. Vi
gik til stålet fra start og var egentlig aldrig under tidspres. Vi har haft sjove timer med at
programmere og teste spillet. Vi er begge meget enige om at det har været lettere at holde
koncentrationen når man programmerer spil end når man laver en hjemmeside.
Vi synes begge to at projektet var en succes. Der var en del nødder der skulle knækkes, men de blev
knækket.
Tommy’s erfaring er helt sikkert et af nøgleelementer i vores succes, uden Tommy var spillet slet
ikke blevet det det er i dag. Tommy har en del erfaring med at programmere spil i forvejen og de
ting han ved om spilprogrammering har gjort os i stand til at forbedre spillet på mange måder.
Vi synes vi har nået de mål vi satte da vi fandt ud af projektets omfang. Vi havde mange flere idéer
vi kunne implementere i spillet, men desværre havde vi ikke tid nok til at kunne realisere alle de
ting vi ville. Vi blev nødt til at vælge. Vi valgte at lave det originale pacman uden modifikationer.
Vi havde ellers en del på tegnebrættet. Det kan være de bliver implementeret hvis vi tager projektet
op som et fritidsprojekt.
Spillets fremtid er på ingen måder fastsat på nuværende tidspunkt. Spillet lever videre så længe folk
har lyst til at prøve kræfter med det. Om de spiller det for at slå highscoren på hjemmesiden eller
bare for at slappe lidt af en gang i mellem, betyder ikke noget. Bare folk kan lide det spil vi har
skabt og nyder at spille det, så føler vi at vi har gjort hvad vi kunne for at give vores Pacman en
fremtid i denne verden.
For at runde konklusionen af skal det siges at vi er begge to meget tilfredse med vores produkt og
de 4 uger projektet har varet, har været 4 gode uger.
6.2. Problemer
6.2.1. Grafik
Da ingen af os er mestre i at lave grafik var vi lidt urolige for hvordan spillet skulle ende med at se
ud, men vi synes at vi er sluppet godt fra det med at låne lidt hist og pist. En del af vores problemer
blev løst ved hjælp af vores rotations kode. Det gjorde at vi ikke behøvede at vende og dreje alle
billeder inden de kunne bruges i spillet.
6.2.2. Gameplay
Vi var lidt urolige for at vi ikke kunne skabe den originale stemning og gameplay i vores Pacman
spil. Vi synes dog selv at det er lykkedes ret godt, og mange af dem vi har bedt teste spillet har ment
Side 49 af 50

Rapport – Objekt Orienteret Pacman spil
det samme. Vores plan med at uploade highscores har haft en meget positiv indflydelse på levetiden
af spillet da der er konkurrence med i spillet via highscore listen.
Spillet kører rigtig godt og spøgelserne opfører sig som de skal. Selv synes vi at spillet har et godt
gameplay, dog er det lidt ensformigt. Det er ikke noget man sidder og spiller i flere timer, men
derimod et spil man kan tage frem og hygge sig med hvis man lige har 10min.
6.2.3. Bugs
Vi har fået testet spillet af en del mennesker er der blevet mange fundet en del bugs.
Vi har rettet alle de bugs vi kunne nå at rette inden vi kom for langt med dokumentationen. Der er
dog stadig et par bugs tilbage i spillet, og sikkert mange der ikke er fundet. Vi har ikke haft tid til at
rette de sidste bugs i den version der er i projektet da vi var kommet for langt med vores
dokumentation, men ingen af dem er kritiske.
6.3. Litteraturliste
www.google.com
www.microsoft.com
MSDN
6.4. Bilag
• Bilag 1 – IPO diagram
• Bilag 2 - Tidsplan
• Bilag 3 - Installations vejledning
• Bilag 4 – Logbog
• Bilag 5 - Test rapport
• Bilag 6 - Kildekode Website
• Bilag 7 - Kildekode Pacman
• Bilag 8 – Brugermanual
• Bilag 9 – Kravspecifikation
• Bilag 10 – Skærmbilleder
• Bilag 11 – Milepæl
• Bilag 12 – Use-Case Beskrivelser
Side 50 af 50