Sunday 15 July 2012

Dynaamisia poroja skriptattuna ilmaan

Tästä tuli taas pidempi ja rönsyilevä teksti. Lopusta löytyy tl:dr - osio yhteenvetoineen.

Olen hämmentynyt. Tutkiessani blogosfääriä tässä eräänä päivänä, tutustuin Steve Yeggeen. En lähde antamaan tarkkoja linkkejä, vaan referoin häntä kuten olen tekstejään ymmärtänyt, ja miten ne ovat jääneet päähäni. Kyseinen kaveri on siis nyt Googlella töissä, ja on viettänyt vuosia myös Amazonilla. Kiinnostavan hänestä tekee se, että hän on blog(e)issaan kumonnut nykyisen ohjelmointimaailmankuvani - vuosia ennenkuin se on syntynytkään.

Tärkein teesi, joka blogeistaan löytyy, on että Java/C++ ei ole parasta mitä ohjelmointimaailma on tuottanut. C++n hän lyttää, ehkä ansaitusti, suoraan, mutten silti lähtisi toteuttamaan 3D-pelejä millään muulla. C++n käyttäjänä kannattanee muistaa konteksti: Yegge on server-browser - arkkitehtuuria noudattavan softan ohjelmoija. Siellä C++lle on paljon siistimpiäkin vaihtoehtoja. Javasta hän lausuu kauniitakin sanoja, minkä ymmärrän, sillä minulle vasta kirkastuu parhaillaan millaista serverimahtavuutta Servletit sisartekniikoineen (tyyppiturvallisuus, JPA/Hibernate, SOAP muutama mahtavuus nimetäkseni) tarjoavat suhteessa PHPhen, mutta Yegge tuo myös esiin Javan ongelmia. Näistä ongelmista kirkkain on se, että Javan vaatiman boilerplate-koodin osuus järjestelmän koodin rivimäärästä nousee, jos ei nyt eksponentiaalisesti niin ainakin melko jyrkän lineaarisesti, suhteessa järjestelmän kokoon. (Örf, en tiedä millaista käyrää se oikeassa elämässä noudattaa. Boilerplaten osuus koko koodista ei nimittäin voi nousta kovin lähelle 100%. Muuta Javalla edes keskikokoisia systeemejä tehneet ymmärtänevät mistä puhun, ja korjannevat minua)

Yeggen tekstien perusteella allekirjoittaneen pitäisi tutustua mm. johonkin Lispiin ja pariin skriptikieleen, joista seuraavaksi lisää.

En muista paljonko Yegge hehkuttaa Rubyä blogspot-blogissaan, mutta sieltä löytyvän Stevey's Drunken Blog RantsTM - linkin takaa (Blogger kopioi muotoilutkin O.o Kivaa) löytyvässä vanhassa blogissa hän on pyhittänyt useamman teksin Rubylle. PHP jätti minulle erittäin huonon maun suuhun "dynaamisesti tyypitetyistä", eli tyyppiturvattomista, skriptikielistä. Pythonia kokeilin tässä keväällä, mutta en nähnyt syytä tutustua siihen tarkemmin. Yegge kuitenkin tuo tällaiset kielet niin hyvässä valossa, että jos en opiskele tekemään keskikokoista softaa Pythonilla/Rubyllä/Lualla, soveltanen jotain näistä väihntään MERPGissä.

Mistä pääsemmekin seuraavaan asiaan: mm. Javascript hyödyntää prototyyppeihin perustuvaa perintää, kuten tietänette. Javascriptissa ei siis ole luokkia, mikä on oikeastaan ihan hyvä juttu, kun katsoo miten kiva niitä on PHP:ssa käyttää. Dynaamiset tyypit ja luokat eivät, kokemukseni mukaan, toimi samassa kontekstissa. Jos jokainen muuttuja voi sisältää mitä vain, mitä järkeä on esimerkiksi polymorfmismissa, eli siinä että eri olioilla sama metodikutsu voi suorittaa aivan erilaista koodia, kun jokainen muuttuja voi sisältää mitä vain!?

Prototyypeistä olin kertomassa. Allekirjoittanutta häiritsi pitkään Javascriptin luokattomuus. Samaa näkee ympäri nettiä, miltei kaikkien juuri Javascriptilla aloittaneiden koodeissa. Hitto, katsokaa Pröngin Javascripteja, ja tuntekaa koodeja kirjoittaneen epätoivo, joka huokuu noista riveistä, jotka ovat kuin C:tä JQueryllä. Vaikka JQuery ($("#id").olehassu().teejotain() - syntaksi) helpottikin logiikan kirjoitusta, näin jälkeenpäin väittäisin sen vaikeuttavan koodien ylläpitoa ja lukemista. Toisaalta, eipä se kyllä JQueryn vika ole. Ilman sitä logiikka olisi vielä epäselvempää.

PROTOTYYPEISTÄ PITI KERTOMANI! Javascriptin luokattomuus siis häiritsee uusia koodareita, jotka eivät vielä tiedä prototyyppiajattelusta. Tunnustan kuuluneeni tähän samaan joukkoon, kunnes luin tämän. Ideanahan on, että jokaisella oliolla on oma Map - tietorakenne, jonne tallennetaan ominaisuuksia avain-arvo - pareina. Kun uusille olioille annetaan prototyypiksi joku olemassaoleva olio, jolla on ominaisuuksia määritelty jo iso läjä, tämä uusi olio saa nämä samat ominaisuudet käyttöönsä. Yksinkertaisimmillaan kyseessä on, Yeggen analogiaa lainaten, samanlainen perintätilanne kuin, pyydän anteeksi luovuuden puutettani, sanoisi: "Feuer kirjoittaa kuin Yegge!". Tällöin minä olen oliomallinnuksen tasolla vai klooni Yeggestä, ja perinnän riemut tulisivat esiin kun minulle annettaisiin omia ominaisuuksia toteamalla "...mutta..."

Onneksi minun ei tarvitse lukea tätä tekstiä. Se vaikuttaa tähän mennessä erittäin rönsyilevältä, mutta toisaalta minulla onkin paljon sanottavaa. Ehkä opin jonain päivänä suunnittelemaan näitä?

MERPGiin palatakseni. Aloin pohtia, että moottoriin voisi joko raa'asti kolvata valmiin JSON-parserin, tai rakentaa itse parserin JSON:n perustuvalle merkintäkielelle. Pelin hahmoluokista voisi sitten tehdä dynaamisempia, niin hieno muotisana kuin se onkin, ja toteuttaa ne Java-luokkien sijasta tekstitiedostoina, jotka moottori lataa, ja joista se parsii lopullisten hahmoluokkien ominaisuudet. Tämä toki avaisi pelin huijauksille, mutta helpottaa myös sen laajennusta ja modailua, ja koska kyseessä ei ole moninpeli, ei huijaukset haittaa oikeasti ketään.

Toinen mitä pohdin, on että jos kenttälogiikkaa ei toteuttaisi Java-mottoriin, vaan iskisin Python-/Ruby-/Lua - tulkin moottoriin kiinni, ja kenttälogiikka pääsisi myös tekstitiedostoiksi moottorin rinnalle. Tämä tarkoittaisi että kentät pääsevät hyödyntämään sitä, mikä ihmisiä noissa kielissä viehättääkään, kenttien testailusta tulisi helpompaa kun moottoria ei tarvitse tappaa kenttien muuttelun välillä, ja moottorista tulee luonnollisesti pienempi ja yksinkertaisempi.

tl;dr

Yhteenvetona sanoin siis seuraavaa: Elämää on olemassa Javan ja C++nkin ulkopuolella, Prototyyppi- ja property - patternit ovat vähintäänkin kiehtovia, niitä voisi soveltaa MERPGiin, ja MERPG tarvitsee jonkin skriptimoottorin itseensä.

Milloinkohan konseptart ja kartat ovat sillä tasolla että kässärin ensimmäisiä sivuja pääsee toteuttamaan? :P

No comments:

Post a Comment