Jeg har lekt spillutvikler, og vil skravle litt om hvordan jeg lagde Numbertron på Sharp MZ-80A.
Jeg liker å lese post mortem-artikler der spillutviklere tar et blikk tilbake på utviklingen av spill de har laget, og sier litt om hva som gikk bra, hva som ikke gikk så bra, og så videre. Så siden jeg nylig ble ferdig med et eget homebrew-spill, tenkte jeg at det måtte være artig å lage en slik artikkel selv. Dette er nok nisjelesestoff deluxe, men det kan jo tenkes noen finner den interessant.
Spillutvikling er gøy!
Spillutvikling er noe alle burde prøve. Å se ideene fra hodet ditt bli virkeliggjort på skjermen foran deg, som noe som (forhåpentligvis) kan bringe andre moro, er noe av det mest tilfredsstillende jeg har opplevd. Det er ikke rart at det å være spillutvikler er drømmejobben for mange.
Selv er jeg ikke spesielt god til å lage spill, så jeg holder meg like godt til en plattform der taket for hva som er mulig ikke er så himla langt unna hva jeg kan få til – den japanske hjemmedatamaskinen Sharp MZ-80A, som var en videreutvikling av Sharp MZ-80K fra 1978. Dette var den første maskinen jeg noensinne eide, og hadde det ikke vært for den, kan det godt være fotballen hadde tatt meg. Det er naturlig nok en plattform jeg har stor kjærlighet for, og da jeg for et par år siden fikk kjøpt en ny maskin av samme type tok det ikke lang tid før jeg surret rundt i programmeringsspråket BASIC for å fortsette der jeg slapp på åttitallet.
Det første spillet mitt var en svært enkel affære, som utvilsomt var mye mer moro å lage enn det er å spille, men det fjerde – Minesnake – var jeg faktisk ganske fornøyd med. Sammen med en venn fra England fikk vi gitt det ut på ekte kassett, og det ble til og med anmeldt av Retro Gamer, som ga det 82%. Den anmeldelsen kom som et aldri så lite sjokk, og det er fortsatt ganske merkelig å tenke på at jeg har laget et spill som har blitt anmeldt av et ordentlig spillblad og fått en slik karakter.
I tiden etter, har jeg stort sett styrt med et rollespill/grottekravlerprosjekt som bygger på noen ganske kule tekniske løsninger, blant annet for «ekte» grafikk som jeg kom opp med en snedig måte å komprimere. Men selve spillet er … urgh. Jeg vet ikke lenger. Jeg er i alle fall veldig lei av alt som har med det å gjøre. En av grunnene til at ting har gått så langsomt er nok at jeg har veldig lite minneplass igjen, men ganske mye som jeg egentlig trenger å putte inn for å gjøre spillet interessant i lengden. Koden er en solid murstein med spaghetti, der det meste av hjelpsomme kommentarer og overskrifter for lengst har blitt fjernet for å spare plass.
Så jeg tenkte at jeg skulle prøve noe annet, for å hindre meg selv i å gå helt lei. Dermed ble Numbertron født. Jeg hadde sett et spill som het Gold Monkey for Windows 3, og tenkte at det måtte være et godt konsept å bygge videre på. Gold Monkey, som igjen var basert på et Unix-spill ved navn Greed, var et rent enspillerspill. Men jeg så umiddelbart for meg var at det ville være mye mer interessant om man spilte det mot en annen. Så jeg lot ideen ligge i hodet en stund, og noterte ned noen tanker nå og da, før jeg startet utviklingen på ordentlig.
Nå er spillet ferdig, og hvis du støtter meg på Patreon kan det tenkes du har spilt det allerede. Det er nemlig eksklusivt for Patreon-backere (fra nivå to og opp).
Tallbasert hjernetrim
Konseptet er enkelt, men selvsagt litt vrient å forklare. Arenaen er fylt opp av tall, fra 1 til 9. Du starter i midten, og styrer et kursor-tegn. Du kan flytte i åtte retninger. Tallene rundt deg bestemmer hvor langt du flytter i de respektive retningene. Om du velger å flytte mot høyre, og det er et femtall under naboruten til høyre, vil du flytte fem ruter mot høyre. Om du velger å flytte oppover, og det er et tretall under naboruta i den retningen, flytter du tre ruter opp. Samtidig som du flytter, fjernes tallene under deg. Dermed vil det ikke lenger være mulig å flytte over disse rutene.
Om kursoren krasjer i en vegg eller et tomrom, er det umiddelbart «game over». Dermed må du tenke taktisk, og planlegge fremover, slik at du ikke låser deg selv inne. Spillet gjøres mer interessant av at det finnes noen bonusobjekter på arenaen. Et av dem fyller et tilfeldig antall tomrom med nye tall, og fungerer nesten som et ekstra liv. Et annet dobler poengsummen din, og er på mange måter hovedmålet i spillet. Jo høyere poengsum du har når du tar dette, jo mer poeng får du – men jo flere tall du har rensket fra spillbrettet, jo vanskeligere er det å navigere seg inn i en posisjon der du kan få fatt i bonusen i utgangspunktet.
I enspillermodus er målet rett og slett bare å se hvor mye av skjermen du klarer å renske, og hvor høy poengsum du kan få. I flerspiller blir spillet mer som en turbasert variant av Tron, der man prøver å låse motspilleren inne, samtidig som man selv unngår å ende opp i en blindgate eller krasje i noe. Jeg har spilt noen runder sammen med andre, og det er faktisk overraskende artig og taktisk.
Utfordringer
Djevelen ligger i detaljene, sies det, og når man prøver å lage spill på et 8-bits-system, så er dette definitivt noe man får kjenne på kroppen. Her er det ingenting som gjøres av seg selv, og selv ting som i utgangspunktet virker skikkelig trivielle involverer potensielt mye arbeid. Så godt som alt som skjer på skjermen og i kulissene er manuelt kodet.
Dette betyr at det aller meste tar mer tid enn man tenker på forhånd, og involverer flere steg enn man ser for seg. Det virker jo rett frem å få en kursor til å blinke eller ploppe inn spillernavnene i toppen, men begge innebærer utfordringer. Ta navnene, for eksempel – skal jeg få det til å se sånn nogenlunde fint ut, må jeg få spillet til å telle antall tegn navnene består av, og få systemet til å regne ut hvor de og poengsummene skal posisjoneres på skjermen. Datamaskinen må ha alt inn med teskje, og hvis man glemmer å spesifisere noe nøyaktig, kan man være helt bombesikker på at ting går galt – om ikke umiddelbart, så senere.
En annen åpenbar utfordring er begrenset minne. Maskinen har 48 kilobytes, men siden jeg bruker et BASIC-kompileringsverktøy, har jeg ikke i nærheten av så mye tilgjengelig. Jeg har kun litt i overkant av 13 kilobytes å jobbe med, før jeg ikke lenger kan kompilere og kjøre spillet i kodeverktøyet (å kunne gjøre dette er veldig hendig for testingen). Spillet kan ikke kompileres overhodet om det er over cirka 20 kilobytes. Jeg kan trekke ut ren data fra spillkoden og lagre dette i en egen fil slik at det ikke tar opp plass i spillkoden, men Sharp MZ-80A bruker primært kassetter, så dette er ikke ideelt. Spesielt ikke om man samtidig ser for seg at spillet på ett eller annet tidspunkt skal distribueres fysisk, og dermed manuelt legges på kassett.
I dette tilfellet var minne aldri noe genuint problem, men det kunne vært det om jeg for eksempel hadde valgt å legge inn skikkelige instruksjoner, noe jeg opprinnelig planla. Tekst sluker minne. Tusen tegn er én kilobyte, og alle mellomrom inkluderes i regnestykket.
Dessuten kan jeg ikke akkurat skryte av det beste «arbeidsmiljøet». Skjerm-minnet kan for eksempel kun holde to «skjermer» samtidig, så jeg kan ikke skrolle fritt rundt i koden. Å redigere eksisterende linjer kan også være pes; hver «kodelinje» kan være på 78 tegn, og ikke mer. Så det er ikke som et moderne verktøy der jeg bare kan gå inn hvor som helst, trykke «Insert» og skrive inn masse ny kode. Jeg heller ikke noen form for utklippstavle, så jeg kan ikke kopiere tekst og lime den inn andre steder. «Undo» er en annen luksus jeg ikke har. Eller minnebeskyttelse, for den saks skyld – jeg kan fint gjøre hele systemet ustabilt ved feil bruk av kommandoen POKE.
Men dette er ting jeg aksepterer når jeg velger å bruke så gammelt utstyr og programvare for spillet mitt, så jeg kan ikke akkurat klage. Heldigvis jobber jeg på emulator, i motsetning til da jeg lagde Minesnake, så jeg har noen fordeler. Alt som har med lasting og lagring av data er lynraskt, og jeg kan for eksempel lagre maskinens tilstand ved jevne mellomrom, som en backup i tilfelle jeg kludrer noe til. Om nødvendig kan jeg også ha to eller flere emulerte systemer oppe samtidig, noe som kan være veldig hendig for testing av ideer og annen eksperimentering.
Hva gikk bra
Selve konseptet; jeg er fornøyd med at jeg fant min egen, nye vri på en eksisterende idé, slik jeg også gjorde med Minesnake. I begge tilfellene virket mine tillegg egentlig ganske åpenbare, men så vidt jeg kan se, har ingen gjort det tidligere. Det at resultatet faktisk også er ganske artig, spesielt når man er to spillere, er jo i seg selv en suksess – jeg er jo fullt klar over at det er veldig få som i det hele tatt vil vurdere å spille noe som dette, men spill er spill, og dette funker faktisk.
Selve spill-loopen var gjennomplanlagt, og implementert på en generisk måte som var uavhengig av antall spillere slik at jeg i teorien kan legge inn mulighet for fire spillere uten nevneverdige endringer i spillkoden. Det var opprinnelig planen, også, men jeg kom frem til at det egentlig ikke var nødvendig. Sjansene for å få én annen person til å spille et spill av denne typen med deg er små nok i utgangspunktet, og det ville dessuten komplisert andre ting i spillet (menyer, og så videre). Men det var veldig greit å ha et så solid system i bunnen, da det betydde at hver gang jeg la inn noen nye elementer og det fungerte for én spiller, funket det også for to.
Lydeffektene ble også ganske okay. Det er begrenset hva man kan gjøre på et system som dette, og jeg har ikke noen ekspertise på området, men jeg ble fornøyd med spillets «bleeps» og «blops».
I tillegg vil jeg trekke frem menygrensesnittet. Det kan godt være det beste menygrensesnittet i noe Sharp MZ-80A-spill – jeg har i alle fall ikke kommet over noe bedre. Spillerne får en rekke muligheter til å skreddersy spillet, og alt gjøres via en rimelig elegant meny som får plass på én skjerm.
Hva gikk galt
Ironisk nok, må jeg nå tilbake til menygrensesnittet. Ja, det ble ganske bra. Men wow, så mye styr det var! Jeg tror ikke det er noen overdrivelse å si at 70% av arbeidet mitt på spillet handlet enten direkte eller indirekte om menyen og de ulike mulighetene her. Jeg undervurderte denne biten kraftig, noe som også resulterte i en del arbeid som måtte gjøres to ganger ettersom jeg ikke planla det godt nok.
Å lage kule menysystemer er for all del ganske tilfredsstillende, men det er langt fra like gøy som å lage spill, og jeg følte etter hvert at jeg havnet i en slags menyhengemyr der jeg aldri helt ble ferdig. Da jeg startet arbeidet på menyen var jeg ved godt mot, og tenkte egentlig at selve spillet kom til å være ferdig innen et par uker, men det tok i stedet flere måneder da jeg ikke klarte å motivere meg for å bruke den nødvendige tiden for å bare bli ferdig.
På samme måte er sikkert over halvparten av spillkoden dedikert til menyen, og det betyr igjen at over halvparten av lastetiden på ekte maskinvare rett og slett skyldes menyen. Var den verd det? Jeg er litt usikker.
I tillegg var det noen ting som jeg ventet for lenge med å implementere, og som dermed ikke passet så voldsomt godt inn i den eksisterende koden da jeg først begynte å jobbe med dem. Dermed ble den en gang så elegante programkoden rimelig rotete mot slutten.
Lærdom
Menygrensesnittet har gitt meg noe å tygge på. Jeg ønsker ikke å bruke i nærheten av like mye tid på neste grensesnitt jeg lager, og vi har også plassproblematikken jeg har vært innom noen ganger. I dette tilfellet er selve spillet veldig lite, og har heller ikke «innhold» som unike nivåer og så videre. Det neste spillet jeg lager blir sannsynligvis Minesnake 2, som vil kreve langt mer plass både for spillmekanismer og nivåer. Dermed må jeg nødvendigvis bruke mye mindre plass på menyene.
Men jeg vil jo helst ikke at menykvaliteten skal stupe, heller, og jeg er en tilhenger av å gi spillerne mulighet til å skreddersy opplevelsen som de ønsker. Så som sagt; det er noe jeg må tygge litt på.
Noen av tingene jeg lagde for spillet kan kanskje brukes om igjen, slik som systemet for å skreddersy kontrollene. Det er som nevnt ikke bare å klippe og lime, men å overføre linjer fra én programlisting til en annen går an med litt tålmodighet og sjonglering av linjenummere.
Men det jeg først og fremst lærte, var at det fortsatt er gøy å lage spill. Etter at motivasjonen for grottekravlerprosjektet sank til bunns, tenkte jeg egentlig at homebrew-utvikling av denne typen var et kapittel jeg var ferdig med, men da jeg først kom i gang med utviklingen av Numbertron, husket jeg hvorfor jeg likte spillutvikling så godt i utgangspunktet. Jeg vil også påstå at selv om dette er et langt enklere spill enn Minesnake, er det også mye mer profesjonelt utført, noe som lover godt for Minesnake 2.
Her er en skikkelig dårlig shakycam-video fra spillet. Jeg klarte ikke å konsentrere meg om å spille og filme samtidig, så den ble som den ble: