Skip to: site menu | section menu | main content

Pamigaroids

...the game where you shoot stuff that flies

PROSJEKTRAPPORT

1) OPPRINNELIG PROSJEKTFORSLAG

2) EVALUERING HVA NÅDDE JEG

3) ERFARINGER

1) OPPRINNELIG PROSJEKTFORSLAG

PROSJEKTFORSLAG løp 2

Kort om prosjektet

Lage et enkelt objektorientert asteroids liknende spill. Spillet vil modeleres etter et enkelt Commodore128 spill jeg spilte for noen år siden. Jeg vil fokkusere på programmering og algoritmer. Jeg vil derfor ikke bruke tid på å tegne grafikk eller lage lydfiler. Spillet vil fremstå som et lydløst wireframespill, med god spillbarhet. Målet er å holde spillet enkelt for å få det ferdig så fort som mulig. Og så utvide med flere fiender, våpen, partikkeleffekter, stikkflammer, eksplosjoner og rullende bakgrundsteppe av stjerner (paralax starfield). (litt avhengig av hva jeg rekker) Den siste biten av oppgaven vil by på gode muligheter for optimalisering. Kanskje importere kode fra c eller bruke numpy etc.

Motivasjon:

1) Lære python3 og håndtere store prosjekter

1a) Lære å lage et stort objektorientert prosjekt i python.

1b) Lære pythonic programmering

1c) Trekke inn så store biter av python som overhodet mulig.

1d) Lære om pakker og moduler

1e) Bruke unittesting, og prøve meg på testdrevet utvikling.

1f) Lære om dokumentajon i python

1g) Få gode muligheter til å optimalisere koden og se (dramatiske?) resultater i praksiss.

1h) Lære å lage en webside for dokumentasjon

2) Bli en bedre programmerer.

2a)Lære teknikker for avansert problemsløsning

2b)Lære teknikker for å utvikle programmer raskt

2c)Teknikker for å holde oversikt i store systemer.

2d)Lage en kodebase som er lett å utvide og endre ved utpreget bruke av objektorientering og innkapsling.

3) Forstå hvordan et spill virker i detalj

3a)Prøve å finne på all spillmekanikk selv.

3b)I den grad jeg må hente tips om spillmekanikk fra nettet. Skal jeg kunne redegjøre for all matematikk og skrive min egen implementasjon fra bunnen av.

3c)Skrive rammeverket for spillet selv.

3d)Det eneste unntaket er bruke av pygame til å hente input fra bruker og tegne på skjermen.(pygame er et lettevekts spillrammeverk i python som kan brukes som interface mot SDL.SDL (Simple Direct media Layer) er en API i c som typisk benyttes for å porte spill til linux. Gjør mye det samme som DirectX)

Prosjekt status ved offisiell start:

Spillet: (611 kodelinjer)

En pilot av det grunnleggende spillet er laget. Skipet representer ved en trekant skyter på asteroider (store sirkler). Alle objekter må holde seg innenfor skjermen og spretter tilbake hvis de treffer kanten av spillområdet. Et brett er vunnet når det ikke er noen fiender igjen. For hver brett øker antall asterioder med 1. Spillet fortsetter til alle skip er ødelagte. Det finnes ingen menyer. Det er lagt inn support for å benytte vilkårlige wireframemodeller som spillobjekter. Men editoren for å lage dem wireframemodeller og hvordan filformatet skal være er ikke bestemt enda.

Editor: (542 kodelinjer)

Kan tegne enkle wireframemodeller. Men ikke lagre dem. Den underliggende modellen må endres for å kunne legge til mer funksjonalitet som skalering av tegnede modeller etc. Editoren benytter pygame for tegning og input dvs at tegningen skjer på skjermen, men alt av menyer er teksbasert og går via terminalen etter å ha satt editoren i terminalmodus. Porting til tkinter vurderes. Men selve spillet har hovedprioritet.

gardmath3: (168 kodelinjer)

Et mattebibliotek jeg har skrevet som støtter polar og kartesiske vektorer. Samt overlaster de vanligste operatorene i python3 for dette. (bør komplementeres med en unittest) Alle tre bitene av spillet har foreløpig vesentlige mangler hva gjelder struktur, dokumentasjon og testing. De fugerer bra som et pilot prosjekt, men bør skrives om helt eller delvis.

Status que for prosjektet:

Editoren kan lagre wireframes som kan importeres i spillet. Den underliggende modellen i editoren er endret og støtter nå også skalering. Samt lagre wireframes som kompilerte wireframes som kan brukes i spillet (.wf) og råe wireframe (.rwf) som kan importeres av editoren for å endres. Spillet har problemer med å vise .wf formatet.

Utvikligsstrategi:

Fokusere på å få koden ferdig, fremfor perfekte løsninger. (fast and dirty)

Pynte på gammel kode bare når nødvendig (og ikke før)

...men god dokumentering underveis

Innkapsling og gjennomgående objektorientering

Teste moduler hver for seg før de implementeres i prosjektet.

Vente med optimalisering til det er nødvendig

Unngå forsøk på optimalisering før alt virker.

Målsetninger og avgrensning av oppgave:

Ulike milepæler i spillutviklingen vurdert etter funksjonalitet.
Delmål: 1 Fullverdig alternativ til originalen

1a) Vilkårlige wireframemodeller med sirkelkollisjonsdeteksjon

1b) statusbrett mitt i spillefeltet, med score etc. Alle elementer soretter når treffer statusbrett eller grensen for spillet.

1c) Fiender: trege store (asteroider) ,raske (målsøkende piggminer)

1d) dirty editor som virker med ikke er brukervennlig. (og muligens ikke er del av offisiell oblig?)

1e) God økning i vaskelighetsgrad mellom hvert brett

Delmål: 2 Partikkeleffekter

2a) bak skip

2b) ved eksplosjon

2c) parallax starfield

2d) optimalisering av partikkeleffekter

Delmål: 3

3a) meny med: start, controlls, highscores, credits (programmert ingame)

3b) Lagring av settings i egen config fil

Delmål: 4 from god to great(Extra features)

4a) Lineær kollisjonsdeteksjon for wireframemodeller

4b) flere fiender (med morsom ai)

4c) flere våpen med bra effekter

4d) powerups

4e) mer utfordrene levels.

4f) gjøre editoren brukervennlig og porte til tkinter.

Jeg anser delmål 1,2 som realistiske og delmål 3 som oppnåelig. Delmål 4 anser jeg ikke som særlig realistisk, det er ekstra funksjonalitet som jeg kan implementeres hvis jeg får tid. Mitt mål er først og fremst å fullføre delmål 1,2 og 3. Men et prosjekt som når 1 og 2 bør også vurderes for godkjenning.

2) EVALUERING HVA NÅDDE JEG

LÆRINGSMÅL:

Angående læringsmål nådde jeg nesten alle :)

1 a,b,c,d,e,f,h (alle unntatt g)

2 a, b, c, d. Har høstet en del erfaringer angående hurtighet men tror det er mye å hente på 2b

3 a, c (b og d er ingen mål, kun spesifisering. Jeg skrev hele spillet selv uten å hente inspirasjon på nettet. Det var utfordrene, men jeg lærte mye om problemsløsning og å finne løsninger selv.)

FUNKSJONALITETSMÅL:

Jeg er rimelig fornøyd med den ferdige funksjonaliteten. Menyer ble droppet til fordel å få spillet skikkelig spillbart. Jeg la til støtte for farger og arbeidet med å få til en god spillfølelse. Større variasjon mellom levels, bedre kollisjonsdeteksjon basert på å innskrive wireframene i rektangler. Bedre kontroll av skipet: Aksellerasjon makshastighet og luftmotstand, egen aksellerasjon for rotasjon. Et godt poeng system basert på spillobjektenes styrke og vanskelighetsgrad. Og pene eksplosjoner og flammer bak skipet med farger som fader.
Delmål 1:
Innfridde egentlig alle. a,b,c,d,e
Endringer:
1.c piggminer er ikke målsøkende, fordi spillet allerede er vanskelig nok. Piggminene beveger seg i stedet fortere enn asteriodene og har en ujevn rotasjon som gjør dem vanskelig å unngå.
Delmål 2:
Alle mål innfridd 2a,2b,2d 2c ble skippet fordi jeg ikke syntes det passet med et parallax starfield i spillet. Det kunne eventuelt vært morsomt å implementere senere for å bruke i den fremtidige menyen.
Delmål 3:
Skipet til fordel for spillbarhet.
Delmål 4:
4e
Extra Features
Ble en god del ekstrafunksjonalitet for å få spillet skikkelig spillbart. Se innledningen over.

3) ERFARINGER:

Dette er første gangen jeg lager et slikt stort prosjekt. Er egentlig ganske fornøyd med resultatet selv om jeg ser det er mye mer å lære. Eneste nedsiden her var at det ble veldig mye å lære på en gang. Både python, hvordan lage spill, websider og organisering av stor prosjekt var relativt nytt for meg. Ble derfor mye som måtte arbeides og tenkes gjennom for å løse oppgaven, og det tok tid. Hadde jeg kunne alt på forhånd, ville nok tidsforbruket vært noe helt annet. Men som et første prosjekt er jeg fornøyd. For nå kan jeg det, så neste gang klan jeg kode mye raskere. Har i alle fall blitt mye mer bevisst på å unngå teknisk gjeld, og sette meg skikkelig inn i problemstillingen før jeg begynner å kode.
Noen erfaringer:

1) unittesting var uvunderlig for å teste at vektorotasjonen virket.

2) Det gikk mye letter å programmere etter at jeg fikk god struktur på programmet

3) Å la alle spillobjekter arve fra en klasse game_object gjorde det veldig lett å implementere ny funksjonalitet.

4) Brukte os.walk til å legge alle aktuelle mapper på python3 pathen __init__.py

5) Det gjorde det mulig å også starte opp enkeltfiler. Veldig nyttig for å lage nedstrippede versjoner av spillet for å teste ting som ikke var egnet å teste med unittesting. F.eks. om en eksplosjon ser bra ut.

6) Å teste ting i et spill tar tid og er kjedelig. Alt av tester som kan automatiseres bør automatiseres.

Back to top