Hehheh, sanaleikki.
Tulinpa ajatelleeksi. Olen mieltänyt MERPGin kartta-arkkitehtuurin sellaiseksi, että yhteen karttaan sijoitetaan aina yksi looginen alue (kaupunki, reitti tjsp). Näitä karttoja pidettäisiin sitten muistissa niin paljon, että kaikki ruudulla oleva maasto on yhtenäistä. Muistimanageri sitten yrittää esiladata muistiin karttoja pelaajan liikkeiden perusteella niin, ettei missään tulisi lataustaukoa tai tyhjää tilaa, johon ilmestyy kartta muutama sekunti alueelle astumisen jälkeen.
Tässä on ymmärrettävästi omat haasteensa. Miten määritellä karttojen suhde toisiinsa, toivomalla että koodari hahmottaa kartan ja laittaa ne pikselintarkasti toisiaan vasten, niin kuin kartturi on suunnitellut? Tuskinpa. Entä algoritmi, jonka perusteella esiladata karttoja lennossa? En tiedä, voisi olla helppo jos innostuisin pohtimaan, sitä, mutta näin yötä vasten kuulostaa pelottavalta.
Tämän voisi siis tehdä fiksumminkin. Jos ruudulla näytetään koko ajan yksi ainoa kartta, jossa on tileihin upotettu data siitä mihin karttoihin mihin kohtiin kyseiset tilet vievät, voi kartturi määritellä karttojen suhteet vaivaamatta koodaria tällaisillä vaikeilla asioilla. Tämän pitäisi onnistua lisäämällä kartta-rakenteen tile-olioihin Stringillä kohdekartan tiedostonimi ja 2D-koordinaattina tile, jolle siirtymän kokenut hahmo spawnaa. Lisäksi tälle pitäisi rakentaa memapperiin käyttöliittymä ja moottoriin logiikkaa tarkistamaan tämän datan.
Toinen mitä pohdin on hahmojen jatkuva liike. Vanha käsitykseni oli, että yksi hahmo voisi olla yhden tilen, ja hahmot liikkuisivat aina tilen verran suuntaansa. Näin hahmojen sijainti olisi jaollinen 50 pikselillä. Tällä saattaisi olla jotain hyötyjä, joita ei nyt tule mieleen, mutta etenkin läheisyystarkistus tarvitsisi hassumpaa matikkaa. Jos hahmojen sijainti olisi jaollinen 1 pikselillä, läheisyyden tarkistuksesta tulee paljon helpompaa, kun ei tarvitse muuttaa koordinaatteja yksiköstä toiseen. Lisäksi kamerasysteemi saattaisi olla helpompi toteuttaa, jos hahmo on liian lähellä ikkunan jotain reunaa, liikuta kameraa samaan suuntaan, jolloin hahmo keskittyy taas.
Täytyy pohtia, täytyy toteuttaa, nyt hyvää yötä!
Saturday 31 March 2012
Thursday 29 March 2012
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.
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.
Saturday 3 March 2012
Jaarittelua Pröngistä
Teinpä lopultakin sinne etusivun. Viitaten lupaukseeni tehdä se palattuani kauniiseen suomeen, voidaan siis päätellä suomen kaunistuneen merkittävästi kevään ensimmäisen sväärin alettua.
Juu, eli etusivulle tuli tervetulotoivotus, uusimmat luonnokset paljastava widgetti, sekä uusimmat kommentit paljastava widget. Laudalta ei ollut järkeä tulostaa uusimpia viestejä, koska lauta omaa nykyään topicit, eikä ole yksinäinen jono viestejä. Mietin että voisi rakentaa widgetin, joka tulostaisi topicit, joihin on tullut uusimmat viestit, mutta se kaatui siihen että tietokannan suunnitteli joku idiootti viime kesänä. Nykyinen rakenne ei taivu sellaiseen... tosin jos laittaisi topictauluun kentän ilmaisemaan uusimman viestin aikaleimaa, ja tämä kenttä päivitettäisiin aina topicin saadessa uuden viestin....
Joka tapauksessa, jos joku toivoo jotain dataa näkyviin etusivulle, nyt olisi hyvä hetki lausua ajatuksensa. Ajattelin seuraavaksi laittaa keskustelujen viestien aikaleimat näkyviin, nämä aikaleimat löytyvät kyllä tietokannasta, mutta jostain syystä niitä ei tulosteta. Sen jälkeen voisin tutkia vakavissani noita topicien viimeisten viestien aikoja. Kun väsyn laudan tekemiseen, implementoin lopultakin luonnostagit. Tietokannassa on alusta asti ollut valmiina rakenteet niille, mutta niistä on tullut ominaisuus, johon keskityn kun ehdin. Jossain vaiheessa pitäisi rakentaa myös tarkistus tuplapostien välttämiseen tarkastus, ettei käy kuin tämän kommenteissa.
Koska Pröngin tehtävä on täyttää tosi pienen piirin sosiaaliset vaatimukset, voivat palvelun vaatimukset elää mielivaltaisesti. Jos joku on odottanut rekisteröitymismahdollisuutta, joudun pettämään teidät. Joskus tulevaisuudessa vieraskommentointi ja postailu laudalle saatetaan sallia, mutta rekisteröitymismahdollisuutta pitää pyytää minulta kasvotusten.
Lounastin Tässin kanssa tässä viikolla. Lounaan keskustelujen tuloksena päätimme myös että blogisuunnitelman voisi tappaa, sillä lauta taipuu käytännössä samaan kuin Fairandcruelin blogit. Okei, WYSIWYGiä ei ole, eikä muotoiluja taida olla toteutettu laisinkaan, mutta nyt olisi hyvä hetki vihjailla millaisiin muotoiluihin luonnosten, kommenttien ja viestien pitäisi taipua. Kursiivi, lihavointi ja linkit pitäisi ainakin toteuttaa olemassaolevan LIDxxx - syntaksin rinnalle.
Muita ajatuksia Pröngistä?
Juu, eli etusivulle tuli tervetulotoivotus, uusimmat luonnokset paljastava widgetti, sekä uusimmat kommentit paljastava widget. Laudalta ei ollut järkeä tulostaa uusimpia viestejä, koska lauta omaa nykyään topicit, eikä ole yksinäinen jono viestejä. Mietin että voisi rakentaa widgetin, joka tulostaisi topicit, joihin on tullut uusimmat viestit, mutta se kaatui siihen että tietokannan suunnitteli joku idiootti viime kesänä. Nykyinen rakenne ei taivu sellaiseen... tosin jos laittaisi topictauluun kentän ilmaisemaan uusimman viestin aikaleimaa, ja tämä kenttä päivitettäisiin aina topicin saadessa uuden viestin....
Joka tapauksessa, jos joku toivoo jotain dataa näkyviin etusivulle, nyt olisi hyvä hetki lausua ajatuksensa. Ajattelin seuraavaksi laittaa keskustelujen viestien aikaleimat näkyviin, nämä aikaleimat löytyvät kyllä tietokannasta, mutta jostain syystä niitä ei tulosteta. Sen jälkeen voisin tutkia vakavissani noita topicien viimeisten viestien aikoja. Kun väsyn laudan tekemiseen, implementoin lopultakin luonnostagit. Tietokannassa on alusta asti ollut valmiina rakenteet niille, mutta niistä on tullut ominaisuus, johon keskityn kun ehdin. Jossain vaiheessa pitäisi rakentaa myös tarkistus tuplapostien välttämiseen tarkastus, ettei käy kuin tämän kommenteissa.
Koska Pröngin tehtävä on täyttää tosi pienen piirin sosiaaliset vaatimukset, voivat palvelun vaatimukset elää mielivaltaisesti. Jos joku on odottanut rekisteröitymismahdollisuutta, joudun pettämään teidät. Joskus tulevaisuudessa vieraskommentointi ja postailu laudalle saatetaan sallia, mutta rekisteröitymismahdollisuutta pitää pyytää minulta kasvotusten.
Lounastin Tässin kanssa tässä viikolla. Lounaan keskustelujen tuloksena päätimme myös että blogisuunnitelman voisi tappaa, sillä lauta taipuu käytännössä samaan kuin Fairandcruelin blogit. Okei, WYSIWYGiä ei ole, eikä muotoiluja taida olla toteutettu laisinkaan, mutta nyt olisi hyvä hetki vihjailla millaisiin muotoiluihin luonnosten, kommenttien ja viestien pitäisi taipua. Kursiivi, lihavointi ja linkit pitäisi ainakin toteuttaa olemassaolevan LIDxxx - syntaksin rinnalle.
Muita ajatuksia Pröngistä?
Subscribe to:
Posts (Atom)