Malli - näkymä - ohjain

Monet näkevät tässä kuvassa ainoastaan aataminaikaisen elektroniikkapelin, joiden merkitys on sittemmin tietotekniikan kehityttyä vähentynyt niin, ettei tällaisia ole paljoa enää esillä. Tosiasiassa tämä alkeellisen näköinen laite kuitenkin, samoin kuin mikä tahansa taskulaskinkin, kuvastaa erästä tärkeätä ohjelmistokehityksen periaatetta: MVC, eli model-view-controller, tai suomeksi malli-näkymä-ohjain.

Elektroniikkapelissä näistä osista helpoiten nähtävissä on näkymä: se koostuu nestekidenäytöstä, jossa on useita valmiiksi painettuja kuvioita, jotka näyttävät tarvittaessa eri hahmojen (Mario, tynnyrit, palkit, Donkey Kong, nosturi) paikat sekä pistemäärän ja jäljellä olevien yritysten määrät, kertoen pelaajalle, mikä on hänen pelitilanteensa. Joissakin tapauksissa peli on pysähdyksissä sen loputtua ja uusi peli mahdollisesti aloitettava.

Toiseksi helpoiten tunnistettavissa on ohjain, eli tässä tapauksessa elektroniikkapelin painonapit, pelin aikana niistä käytetään "controller" (sic) -nappia ja "Jump"- nappia, pelin ollessa alku/välitilassa uusi peli voidaan aloittaa "game A" tai "game B" -napeista halutun vaikeustason mukaan.

Näkymättömissä on kaikkein tärkein osa, eli malli (engl. model). Se koostuu pelin sisäisestä muistista, siihen talletetusta ohjelmasta, rekistereistä ja mikroprosessorista, jotka pitävät sisällään tiedon kulloisestakin pelin tilanteesta ja huolehtivat pelin etenemisestä. Kullakin ajanhetkellä peli on tietyssä tilassa, jonka määrittävät esimerkiksi seuraavat attribuutit:

• Onko pelaaminen käynnissä, vai onko peli "välitilassa" (esim. pelin loputtua)?
• Marion paikka (näitä on todella rajoitettu määrä ja se voidaan identifioida tässä pelissä pienellä kokonaisluvulla).
• Donkey Kongin paikka (vain 3 mahdollista, jos ei oteta lukuun "pelin onnistumisen animaatioita")
• Lista tynnyreistä ja niiden paikat (jos näiden yli ei onnistu hyppäämään, niin seuraa yhden pelin yrityksen menetys ("elämän menetys", "miss", "virhepiste"))
• Lista palkeista ja niiden paikat (esiintyy Donkey Kong-pelissä 2. rivillä alemmassa ruudussa ja ovat uhkia Marion hypyille)
• Jäljellä olevien "koukkujen" määrä (1-4), nämä kuvastavat sitä, kuinka monta kertaa Marion on onnistuttava vielä kiipeämään ylös ennen "onnistumisanimaatiota", jossa Donkey Kong putoaa yläruudun oikeaan laitaan
• Pisteet
• Jäljellä olevat yritykset
• Kellonaika (merkitystä hälytyksessä ja "välitilassa")
• Onko hälytysaikaa määritelty ja mikä se on?

Näillä eväillä pelin kulloinenkin tilanne tiedetään (jos ei tiedetä, niin kommentoikaa virheistä ja täydentäkää!).

Seuraavana kysymyksenä on se, kuinka "malli" eli muistiin tallennettu ja prosessorin tulkitsema ohjelma huolehtii pelin etenemisestä. Se tapahtuu siten, että määritellään tietty kellojakso, jonka aikana ohjelma pysyy samassa tilassa ja kellojakson vaihtuessa tilaa muutetaan sopivasti. Kun tilaa muutetaan, voidaan käyttää esimerkiksi seuraavia "perusperiaatteita":

• Tynnyrit ja palkit etenevät yhden askelman "alaspäin", kun ne ovat päätepisteessään, ne lakkaavat olemasta ja poistetaan listasta
• Tynnyreitä ja palkkeja generoidaan sopiviin kohtiin (Donkey Kongin alapuolelle ja alaruudun vasempaan laitaan) satunnaislukugeneraattorin ulostulon, pistemäärän ja pelityypin (A vai B) funktiona
• Jos tynnyri on edennyt pisteeseen, jossa edellinen Marion paikka oli sen takana, liputetaan pelaajan virhe ja yrityksen menetys, sama tilanne, jos palkin ja Marion koordinaatit olivat samoja
• Tarkastetaan ohjaimelta, haluttiinko Marion paikkaa muuttaa, uutta peliä aloittaa tms.
• Tietyissä "erikoistapauksissa", kuten siinä, että Mario on ollut liikkuvan tynnyrin yläpuolella (hypännyt yli), poistanut koukun tai poistanut viimeisen koukun, lisätään pistemäärää sopivalla määrällä. Kokemukseni mukaan poistetun koukun pistemäärää ilmeisesti generoidaan myös käytettyjen kellojaksojen funktiona.
• Välitetään pyyntö uudesta näkymästä.

Nyt mainittu lista ei ole kattava. Joka tapauksessa, kaikkien pelien tapahtumat voidaan purkaa tällä tavoin diskreetin matematiikan kannalta ymmärrettäviin osiin. Lisäksi on havaittu, että mallia, näkymää ja ohjainta koskevat ohjelmakoodit on syytä pitää ohjelmassa erillään, jos halutaan, että myöhemmät kehittäjät ymmärtäisivät ohjelmarakennetta mahdollisimman helposti.