Mutta, olen tehnyt koodauksen ohella mietiskelyä otsikon esittämästä aiheesta. Tätä mietiskelyä pitäisi sitten jäsentää blogiin, ja koska tämä tieto on tärkeää sekä allekirjoittaneelle että MERPGin tilesettien tekijöille, erotan teksteissä koodirelatiivisen ja tilesettien tekijöitä kiinnostavan osan, koska olen huomannut että tilesettien tekijät eivät jaksa/halua lukea tekstiä joka liittyy liikaa ohjelmointipuoleen. Alkuun siis tilesettereitä (mikä termi...) kiinnostava osa.
Mikä idea on toteuttaa toinen layer karttadatan ja hitdatan päälle?
Karttadata-kerros olisi varattu maastolle. Se ei tue maskiväriä (0,0,0/#000000), eli läpinäkyvyyttä, ja se olisi varattu lähinnä maastotileille. Toisesta kerroksesta eteenpäin layerit tukisivat maskiväripohjaista läpinäkyvyyttä, ja nämä olisi tarkoitettu tileille jotka esittävät objekteja joita voi löytyä maastosta. Lisäksi maskiväripohjainen läpinäkyvyys helpottaa tilesettien tekijöiden elämää todella paljon.
Yllä on eräs keskivanha tilesetti, jonka teimme eräänä Yönä MEMAPPER Beta 2:n tai Beta 3:n aikaan. Teknisesti tuon tilesetin oikeudet kuulunevat Tässille, koska hän tuon teki ja minä kommentoin vieressä, mutta oletan nyt itsekkäästi ettei häntä haittaa vaikka käytän tätä kuvaa esimerkkinä :P
Tuossa tilesetissä näkyy selvä ongelma. Siinä on vettä, kalliota ja ruohoa. Mitä jos karttaan haluttaisiin tehdä ranta? Ranta vaatii tietysti maata ja vettä monissa erilaisissa kulmissa; nuo 8 reuna-/kulmatileä eivät muistaakseni riittäneet sujuvaan karttatyöskentelyyn. Lisäksi nämä reilu 8 tileä pitää toteuttaa jokaiselle maastotyypille erikseen! Leikitään että meillä on viisi maastotyyppiä, joiden kaikkien välille pitää toteuttaa tuollaisia "rantoja". Se tekisi vähintään 8*5*8 + 5 (eli 325) tileä. Turha varmaan edes mainita, että ilman erikoislaatuisia käyttöliittymäratkaisuja MEMAPPER ei taivu tuollaiseen. Tilejen määrä moninkertaistuu aina kun tilesettiin lisätään uusi maastotyyppi.
Jos pohjakerroksen päällä maskiläpinäkyvyyttä tukevia kerroksia, voitaisiin ylläolevaa tilesettiä muuttaa niin, että jokaisesta maastotyypistä tehtäisiin tuollaiset kulmapalat, ja sen sijaan että tilesettiä tehdessä liimattaisiin maastokulmia maastopalojen päälle, liimattaisiin ne vasta MEMAPPERissa.
Monikerroksinen rakenne mahdollistaisi muitakin kikkailuja. Parille ensimmäiselle kerrokselle voitaisiin rakentaa tilen maasto, ja ylemmälle voitaisiin asettaa kartan kannalta relevantti objekti, joka ei kuitenkaan ole niin tärkeä että sitä kannattaisi pelin puolella ladata. Hyvänä esimerkkinävaikka aita, jonka yli ei tietenkään pelissä saa kulkea, mutta jonka erillinen lataaminen pelissä olisi lähinnä typerää.
Mitä tämä toteutus vaatii koodarin näkökulmasta?
Karttatiedoston rakenne ainakin muuttuu. Tällä hetkellä karttatiedoston ensimmäiset kolme tavua ilmaisevat kartan version, kartan leveyden tileinä ja kartan korkeuden tileinä, sitten alkaa karttadata. Uudessa tiedostorakenteessa tiedoston neljäs tavu ilmaisisi karttalayereiden lukumäärää, ja ensimmäisen EOS-tavun (FF/255) jälkeen ei alakaan hit-data, vaan seuraava layer. Ohjelmien pitäisi siis pitää kirjaa montako EOS-tavua on tullut tiedostovirrassa vastaan, ja näin laskea monetta layeriä renderöidään. Eli kahden EOS-tavun sijasta karttatiedostosta pitäisi löytyä layereiden_määrä+1 EOS-tavua (+1 siitä että hitdatakin päättyy EOS:ään).
Tietorakenteiden puolella tämä monilayerisyys on helppo toteuttaa. Ne mitkä olivat ennenvanhaan kaksiulotteisia listoja/vektoreita karttaluokissa, muuttuvat kolmiulotteisiksi. Näin tietyn tilen arvoon viitattaisiin (x,y,z)lla missä x ja y ovat vanhaa kauraa, ja z viittaa layerin järjestysnumeroon. Z:n kanssa pitää huomata että origo on todennäköisesti ruudulla, eli alin layer on tiletaulukko[x][y][maxZ-1] eikä tiletaulukko[x][y][0]. Jos joku hämääntyy C/Java - taulukkonotaatiosta, sama kolmiulotteisella CB-taulukolla olisi tiletaulukko(x,y,z_arvo).
No comments:
Post a Comment