Friday, June 1, 2007
3 og 4 iteration
Vi har i 3 iteration, nu fået lidt musik på vores program. Vi har også været inden og ændre på nogle svage sider i opgaven, og forfinet koden.
Vi har også fået reflekteret en del over effekten af vores SD og SSD.
I 3. iteration har vi også beskrevet hele den færdige kode.
Så er vi begyndt at skrive lidt om 4. iteration, om nogle af de ting, som vi ikke kommer til at nå at blive færdige med, men som vi godt kunne tænke os at se videreudviklet, hvis vi havde haft mere tid.
Vi har også fået reflekteret en del over effekten af vores SD og SSD.
I 3. iteration har vi også beskrevet hele den færdige kode.
Så er vi begyndt at skrive lidt om 4. iteration, om nogle af de ting, som vi ikke kommer til at nå at blive færdige med, men som vi godt kunne tænke os at se videreudviklet, hvis vi havde haft mere tid.
Monday, May 28, 2007
Opdatering
Siden Preben droppede ud af gruppen og studiet, har vi brugt en del tid på at restrukturere opgaven, og simplificere kravene til spillet noget, så det passede til en tremandsgruppe.
Vi har op til dette tidspunkt beskrevet inception og første iteration her på bloggen, og nu kommer her en opdatering i forhold til anden og tredje iteration.
2. Iteration
Her valgte vi at færdiggøre klasserne med metoder osv, og vi gik igang med at kode vores GUI. Vi lavede vores GUI så alt kørte, men uden at der bliver tjekket på noget. Det vil sige elementerne falder ned over skærmen, men vores Hero kan ikke interagere med noget. Alt bevæger sig blot, uden at påvirke hinanden.
3. Iteration
Her fik vi implementeret interaktion mellem elementerne, så Hero reagerer på de ting han samler op. Vi fik også leget med photoshop, og deri lavet billeder af vores enemies og power-up's.
Vi fik også her lavet JUnit test case på enemies og power-up's bevægelse ned over skærmen.
Vi har op til dette tidspunkt beskrevet inception og første iteration her på bloggen, og nu kommer her en opdatering i forhold til anden og tredje iteration.
2. Iteration
Her valgte vi at færdiggøre klasserne med metoder osv, og vi gik igang med at kode vores GUI. Vi lavede vores GUI så alt kørte, men uden at der bliver tjekket på noget. Det vil sige elementerne falder ned over skærmen, men vores Hero kan ikke interagere med noget. Alt bevæger sig blot, uden at påvirke hinanden.
3. Iteration
Her fik vi implementeret interaktion mellem elementerne, så Hero reagerer på de ting han samler op. Vi fik også leget med photoshop, og deri lavet billeder af vores enemies og power-up's.
Vi fik også her lavet JUnit test case på enemies og power-up's bevægelse ned over skærmen.
Wednesday, May 9, 2007
Desværre har Preben Meisner valgt at droppe ud, og det har gjort at vi må restrukturere opgaven noget, da vi nu har færre sider og vi er en mindre til at programmere. We wish you all te best!
Med hensyn til spillet har vi vurderet, at navnet (JohnnyGeekbo) ikke var passende til aldersgruppen, så vi har valgt at kalde spillet HealthMan, og vores powerUps er sund mad som falder ned, og fjenderne er usund mad. Noget mere pædagogisk i forhold til målgruppen.
Vi arbejder pt. med at personen i billedet ikke ryger uden for vores skærmbillede, men stopper når han når kanten, og derudover er vi igang med en algoritme til at tjekke hvornår elementerne i spillet træffer hinanden. Det vil sige hvornår personen samler Powerups op eller bliver ramt af fjender. Pt. bevæger tingene sig uafhængigt af hinanden.
Morten har startet firma: www.sumopix.com, som laver foto på lærred, og det tager en del af hans tid.
Med hensyn til spillet har vi vurderet, at navnet (JohnnyGeekbo) ikke var passende til aldersgruppen, så vi har valgt at kalde spillet HealthMan, og vores powerUps er sund mad som falder ned, og fjenderne er usund mad. Noget mere pædagogisk i forhold til målgruppen.
Vi arbejder pt. med at personen i billedet ikke ryger uden for vores skærmbillede, men stopper når han når kanten, og derudover er vi igang med en algoritme til at tjekke hvornår elementerne i spillet træffer hinanden. Det vil sige hvornår personen samler Powerups op eller bliver ramt af fjender. Pt. bevæger tingene sig uafhængigt af hinanden.
Morten har startet firma: www.sumopix.com, som laver foto på lærred, og det tager en del af hans tid.
Tuesday, April 10, 2007
Vision
Vision
Vi vil udvikle et stykke software til at underholde børn i alder 4-8. Vi vil lave et simpelt velfungerende computerspil, som er let at bruge. Brugeroverfladen skal minde om de gamle arkadespil som Pacman og Ping Pong.
Mål:
Spillet skal kunne bruges af målgruppen.
Spillet skal være platform uafhængigt, så det kan køres på de fleste maskiner.
Vi vil udvikle et stykke software til at underholde børn i alder 4-8. Vi vil lave et simpelt velfungerende computerspil, som er let at bruge. Brugeroverfladen skal minde om de gamle arkadespil som Pacman og Ping Pong.
Mål:
Spillet skal kunne bruges af målgruppen.
Spillet skal være platform uafhængigt, så det kan køres på de fleste maskiner.
domænemodel + ssd + use case
Dagsorden for 27. marts
Domænemodel

Use Case
USE-CASE FOR "JOHNNY GEEKBO" (COMPUTER GAME)
SCOPE
Arkadespil
REQUIREMENTS
En helt (Hero)
En verden (World) med min. 3 niveauer. (Levels)
En rangliste (Highscore)
En timer der holder styr på hvornår niveauet stiger.
Min. 3 forskellige fjender helten skal undgå (Enemies)
Min. 3 objekter helten kan samle op (Power-ups)
PRIMARY ACTOR
Spille interesserede bruger.
STAKEHOLDERS AND INTERESTS
Til brugere der kan lide at spille klassiske arkade-spil.
PRECONDITION
1. Brugeren har mulighed for at afvikle JAVA-applikationer.
2. Der er en bruger tilstede for at intergere og start et nyt spil.
MAIN SUCCESS SCENARIO
1. Bruger starter et nyt spil
2. System initier verden inkl. enemies og power-ups.
3. Systemet starter en timer
3. Bruger styrer hero for at undgå enemies og for at samle power-ups op.
4. For hvert power-up brugeren samler tælles score op.
5. For hvert enemies hero rammer, mistes der et life.
7. Hvis timer udløber, stiger sværhedsgraden (level)
8. Når hero ikke har flere liv så stoppes spillet.
9. Systemet retuner hvad den opnåede score er.
EXTENSIONS
a. Er den opnåede score højere end den laveste på highscore-listen:
1. Bed brugeren angive navn.
2. Systemet gemmer navn og score
3. Retuner til start-skærm
b. Er den opnåede score ikke højere end den laveste på highscore-listen:
1. Retuner til start-skærm
AUTHOR AND DATE
Thomas Paludan, Morten Storgaard, Daniel Knudsen og Preben Meisner 30. Marts 2007
System Sequence Diagram
Domænemodel
Use Case
USE-CASE FOR "JOHNNY GEEKBO" (COMPUTER GAME)
SCOPE
Arkadespil
REQUIREMENTS
En helt (Hero)
En verden (World) med min. 3 niveauer. (Levels)
En rangliste (Highscore)
En timer der holder styr på hvornår niveauet stiger.
Min. 3 forskellige fjender helten skal undgå (Enemies)
Min. 3 objekter helten kan samle op (Power-ups)
PRIMARY ACTOR
Spille interesserede bruger.
STAKEHOLDERS AND INTERESTS
Til brugere der kan lide at spille klassiske arkade-spil.
PRECONDITION
1. Brugeren har mulighed for at afvikle JAVA-applikationer.
2. Der er en bruger tilstede for at intergere og start et nyt spil.
MAIN SUCCESS SCENARIO
1. Bruger starter et nyt spil
2. System initier verden inkl. enemies og power-ups.
3. Systemet starter en timer
3. Bruger styrer hero for at undgå enemies og for at samle power-ups op.
4. For hvert power-up brugeren samler tælles score op.
5. For hvert enemies hero rammer, mistes der et life.
7. Hvis timer udløber, stiger sværhedsgraden (level)
8. Når hero ikke har flere liv så stoppes spillet.
9. Systemet retuner hvad den opnåede score er.
EXTENSIONS
a. Er den opnåede score højere end den laveste på highscore-listen:
1. Bed brugeren angive navn.
2. Systemet gemmer navn og score
3. Retuner til start-skærm
b. Er den opnåede score ikke højere end den laveste på highscore-listen:
1. Retuner til start-skærm
AUTHOR AND DATE
Thomas Paludan, Morten Storgaard, Daniel Knudsen og Preben Meisner 30. Marts 2007
System Sequence Diagram
Subscribe to:
Posts (Atom)