Gravity

Hvis du ikke har været med fra starten, så start med at læse, at jeg har bygget et rumskib .

Så er jeg nået i mål med mit spil, og det har fået navnet "Gravity". Jeg er meget tilfreds!

Hvad venter du på? Prøv det! OG HUSK LYD.

Learnings

Når man er færdig med sådant et projekt, som jo for mig har været absolut ny grund, så sidder man tilbage med tankerne, om alt det man ville have gjort anderledes, hvis man havde vidst alt det man gør nu fra starten af.

For mig har læringen gået på, både at lave et større, sammenhængende kompleks af kode i javascript og ligeledes hele aspektet med realtime spil-programmering.

Stadier

En af de første ting jeg er blevet opmærksom på, er stadier. Det giver god mening for alting, at holde styr på hvad stadie det er i. Helt øverst har man selve spillet, som skal afgøre hvad man foretager sig lige nu. I mit spil er der tre stadier: Titelskærmen, selve spillet og gameover-skærmen. På titelskærmen skal man f.eks. ikke kunne styre rumskibet, men man skal kunne starte et nyt spil, og i selve spillet er det lige omvendt.

Så bør stort set alle spilobjekter også have stadier. Rumskibet skal f.eks. være opmærksom på om det accelererer, decelererer eller drejer. Eksplosionen skal være opmærksom på, om den er i gang med at animere, eller om den er blevet færdig. Timeren skal være opmærksom på, om den tæller, om den tæller de sidste 10 sekunder eller om den er stoppet osv.

Callbacks er også utrolig brugbare, f.eks. "kald denne funktion, når timeren når nul" eller "kald denne funktion, når eksplosionen er færdiganimeret". Her kan laves nogle meget brugbare kæder.

Tid og huller i tiden

Tickeren og delta-variablen er helt central i alting, og jeg er glad for, at jeg fra starten opgjorde alting i forståelige måleenheder, f.eks. pixel/s, for så kunne man hele tiden regne om. Hvis jeg bare havde brugt abstrakte værdier, såsom "lad mig prøve at skrive 100 og se hvor hurtigt det går", så tror jeg hurtigt det hele ville blive meget uoverskueligt og usammenhængende. Tickeren skal kalde det meste, f.eks. rumskibet, skærmen, stjernerne og nedtælleren, og man skal hele tiden huske på, at tiden er variabel, dvs. at der nogle gange er passeret 1/60 sekund, men at der måske andre gange er passeret længere tid. Det kan også give bizarre fejl, for hvis jeg f.eks. kun opdaterer hvert 2. sekund, så kan jeg risikere, at jeg får rykket hele rumskibet igennem en planet uden at kollidere med den.

Position

Det irriterende i spil der foregår i en browser, er at brugeren hele tiden har mulighed for at ændre størrelse på vinduet, og at man skal forholde sig til dette. Det skal tænkes ind i alle objekter, at de skal have en positioneringsfunktion, man kan kalde hele tiden. I dette spil er det den centrale tekst, timeren, scoren og selve stjernehimlen, der skal håndteres når skærmen skifter størrelse.

Scenen

Min håndtering af scenen var, at hver gang spillet skiftede stadie, så ryddede jeg scenen og tilføjede alt hvad jeg skulle bruge igen. En anden tilgang kunne være, at tilføje alt på scenen og så vise/skjule det, alt efter spillets tilstand. Jeg tror min tilgang er den bedste, for når jeg tilføjer noget nyt, så kan jeg nøjes med at tilføje det, der hvor jeg har brug for det, fremfor at skulle forholde mig til, om det skal være vist/skjult i alle spillets tilstande.

Javascript

Jeg er ikke blevet mere begejstret for Javascript, for det er et meget "globalt" sprog og der er så mange forskellige sprogkonstruktioner for de samme ting, at det nærmest er tåbeligt. Der er fem forskellige måder, at arbejde med objekter, og nogenlunde det samme antal måder, at iterere igennem et array, og sådan fortsætter det.

Hvis man skal tage det bedste med sig, så synes jeg, at de globale objekter fungerer godt til "hovedpersonerne" i spillet, f.eks. var det meget praktisk, at have et globalt objekt til rumskibet og pointtælleren, for så kunne man let tilgå disse, uanset hvor man var i koden. Til objekter som der er flere af, såsom planeter og kasser, var det bedre at anvende instantierbare objekter, selv om jeg ikke bryder mig om disse i javascript. For så kunne man have så mange eller få, som man nu havde brug for.

Dette konkluderer mit rumskibsprojekt, eller i hvert fald historien om det, for jeg skal ikke kunne afvise, at jeg bygger videre på spillet. Fra et programmeringsteknisk synspunkt tror jeg dog ikke, at der er mere at komme efter. Det vil være variationer på alt det, vi allerede har været igennem sammen. Men tak for at være med hertil.

Versionshistorik

Jeg synes det er sjovt at bladre imellem versionerne.

Spil Version 1

Spil Version 1.1

Spil Version 2

Spil Version 3

Spil Version 4

Spil Release