MERPG elää yhä

Positiiviset otsikot jaksavat lämmittää mieltä :)

Allekirjoittanut on vähän flunssainen, joten tästä tekstistä tuli hieman huonolla kieliopilla varustettua tajunnanvirtaa. Onnea sille, joka jaksaa lukea ja ymmärtää kaiken :P

Jos en ole sitä vielä tehnyt, teen tästä nyt virallista. Merpgtarina.blogspot.com oli paska ratkaisu, jolle ainoa peruste oli ettei kukaan (devtiimistä) ollut tuolloin kuullutkaan mistään Dropboxista, puhumattakaan professionaaleista dokumenttien- ja sorsanhallinnoista. Vaikka Tässi eilen rikkoikin sen blogin hiljaisuuden, olen tehnyt jo pidempään puhtaaksikirjoittanut tarinaa word-dokumenttiin. Tähän dokuun olisi tarkoitus speksata kaikki muutkin pelin yksityiskohdat, lukuunottamatta yksityiskohtaista karttasuunnittelua. Siitä nähdään vain painajaisia ennen kuin Tässi pääsee väsäämään tilesettejä ;)

Aloin pitkästä aikaa protoilemaan moottorin kanssa. Tein aikaa sitten projektin ainoana koodarina päätöksen toteuttaa kaiken javalla, mm. monta iteraatiota nähneen karttaohjelman java-koodipohjan ja bugiherkän käsin-serialisoinnin vuoksi. Tässä moottorissa, jonka sorsat voi kiinnostunut ladata Sourceforgesta, on valmiina tällä hetkellä vain pelkkää Swingin abstraktointia ja karttojen toimivuuden testailua. Swingiä voisi joku väittää loistavaksi GUI-kirjastoksi, mutta edes 2D-peleihin se ei niin vain taivu. Sen sijaan että olisin huijannut SDL:n javaporttauksella, abstraktoin Swingin piiloon tekemällä ikkunaluokan, johon lisätään JPanelista periytettyyn luokkaan pohjautuva "sisältö". Ikkunaluokka piilottaa myös Swingin vähintäänkin kummallisen näppäinkuuntelusysteemin, ja tarjoaa ENUMillisen nappeja, joiden pohjassaoloa voi pollata ikkunalta. Käytännössä siis ylänuolen alhaallaoloa kysytään seuraavasti:

if(getKeyListener().keyDown(KEY.UP_KEY)) //Teejotain

getKeyListener() on sisältöluokan metodi, joka palauttaa Keys-rajapinnan toteuttavan olion (eli ikkunan). KEY - enum on mielenkiintoinen yksilö, joka johtuu käytännössä laiskuudestani. Kuuntelijalta voi polalta vain nuolinappien, escin, returnin, F5:n ja shiftin tilaa. Tämä siksi, että enum-näppäinkoodit ovat tyyppiturvallisempia ja selkeämpiä kuin Swingin int-vakiot. Jos uusille näppäimille tulee tarve, lisätään KEY-enumiin sille vakio, joka lisätään myös seuraavaan switchiin

private KEY eventToKey(KeyEvent e)
    {
        switch(e.getKeyCode())
        {
            case KeyEvent.VK_UP:
                return KEY.UP_KEY;
               
            case KeyEvent.VK_DOWN:
                return KEY.DOWN_KEY;
               
            case KeyEvent.VK_RIGHT:
                return KEY.RIGHT_KEY;
               
            case KeyEvent.VK_LEFT:
                return KEY.LEFT_KEY;
               
            case KeyEvent.VK_ESCAPE:
                return KEY.ESCAPE;
               
            case KeyEvent.VK_ENTER:
                return KEY.SELECT;
               
            case KeyEvent.VK_F5:
                return KEY.SAVE;
               
            case KeyEvent.VK_SHIFT:
                return KEY.RUN;
               
            default:
                return null;
        }       
    },
minkä jälkeen kuuntelija tuntee kyseisen vakion.

Sisältöluokka tarjoaa abstraktit Present() ja Update() - metodimääritykset. Luokan paintComponent() kutsuu näitä, antaen Presentille parametreina millisekunteina edellisestä päivityksestä kuluneen ajan ja grafiikkakontekstin, sekä Updatelle pelkän ajan. Presentin tarkoitus olisi piirtää ikkunan sisältö, ja Updaten pitäisi päivittää pelitilanne.

Tällainen arkkitehtuuri mahdollistaa sen, että sisältöluokasta voidaan periyttää oma luokka, jonka konstruktorissa ladataan media sisältöluokan kokoelmiin, luodaan pelin tila jonnekin mallitasolle, joka yhä odottaa kirjoittamistaan, ja jonka present-metodi hakee mallilta tilan ja piirtää sen, sekä antaa updaten päivittää mallia piirron jälkeen. Tämän jälkeen muutetaan ikkunan luonnissa, main-metodissa, sisältö-olion määritys vastaamaan uutta luokkaa, ja kaiken pitäisi toimia suoraan. Ei tarvitse huolehtia ikkunan luonnista.