Sääntöjärjestelmät peliohjelmoinnissa

Sääntöjärjestelmät peliohjelmoinnissa Risto Saarelma Helsinki 27.4.2008 Seminaariartikkeli HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty Laitos Institution Department Matemaattis-luonnontieteellinen Tekijä Författare Author Risto Saarelma Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Sääntöjärjestelmät peliohjelmoinnissa Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Seminaariartikkeli 27.4.2008 19 sivua Tiivistelmä Referat Abstract Tietojenkäsittelytieteen laitoksen kevään 2008 Ohjelmistotuotanto ja tietokonepelit - seminaarin artikkeli. Artikkelissa käsitellään sääntöjärjestelmiä ja niiden käyttöä peliohjelmoinnissa. Avainsanat Nyckelord Keywords tietokonepelit, sääntöjärjestelmät, deklaratiivinen ohjelmointi Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information

Sisältö 1 Miten kuvailla pelejä? 1 2 Sääntöjärjestelmät 6 3 Sääntöjärjestelmät ja tietokonepelit 10 4 Sääntöjärjestelmien tulevaisuus 13 Lähteet 15 ii

Tässä artikkelissa tarkastellaan sääntöjärjestelmiä (engl. rule-based system, production system) vaihtoehtona imperatiiviselle ohjelmointiparadigmalle peliohjelmoinnissa. Aluksi käydään lyhyesti läpi imperatiivisen ohjelmoinnin tuottamia ongelmia, ja esitellään sille vaihtoehdoksi deklaratiivista ohjelmointitapaa. Sääntöjärjestelmistä tarkastellaan niiden historiaa, periaatteita ja soveltuvuutta tietokonepeleihin. Lopuksi tarkastellaan sääntöjärjestelmien tulevaisuudennäkymiä peliohjelmoinnissa. 1 Miten kuvailla pelejä? Peliohjelman rakenne voidaan jakaa karkeasti kolmeen osaan. Matalimmalla tasolla on rajapinta käyttöjärjestelmään ja laitteistoon, joka huolehtii syötteestä ja tulosteesta eri oheislaitteilla. Tämän rajapinnan elementtejä voivat olla esimerkiksi äänentoisto, grafiikan piirtäminen, peliohjaimet, tiedostojärjestelmä ja verkkoyhteydet. Laitteistorajapinnan ja mahdollisen hieman korkeamman tason grafiikka-, ääni- ja fysiikkakirjastoja tarjoavan pelimoottorikomponentin päälle on rakennettu varsinainen pelilogiikka. Pelilogiikka kertoo sen, miten pelitila esitetään, ja miten se kehittyy erilaisilla syötteillä. Perinteisissä lauta- yms. peleissä tätä osuutta kutsuttaisiin pelin säännöiksi. Sekä matalan tason pohjakerros että pelilogiikka vaativat aitoa, Turingtäydellistä ohjelmointikieltä. Kolmanneksi tasoksi voidaan määritellä pelin staattisen data, kuten äänitiedostot, grafiikkatiedostot ja yksinkertaiset rakenteelliset datatiedostot esimerkiksi peliolioiden numeeristen ominaisuuksien määrittämiseen. Tälle tasolle katsotaan kuuluvaksi sellainen sisältö, jonka esittäminen ei enää vaadi Turing-täydellistä kieltä ja joka voidaan siten tulkita suoraviivaisesti. Pelisuunnittelun kannalta keskimmäinen pelilogiikkataso on selvästi kiinnostavin. Rajapintatason yksityiskohdilla ei ole läheskään yhtä paljoa tekemistä sen kanssa, minkälainen peli on kyseessä, ja staattinen data on pitkälti merkityksetöntä ilman sitä tulkitsevaa pelilogiikkaa. Mikäli pelilogiikkaa voisi kuvailla mahdollisimman pitkälti irrallaan matalan tason toteutusyksityiskohdista, pelilogiikan kehittäjän ei tarvitsisi huolehtia oman alueensa ulkopuolisesta mo- 1

nimutkaisuudesta. Erillään alustariippuvaisesta koodista esitetyn pelilogiikan voisi myös siirtää helpommin toiselle suoritusalustalle. Perinteisesti peliohjelmoinnissa matalan tason ohjelmalogiikka ja pelin säännöt ovat usein kietoutuneet yhteen. void make_sick ( xtime, cause, t a l k, t y p e ) long xtime ; c o n s t char c a u s e ; / s i c k n e s s cause / b o o l e a n t a l k ; i n t t y p e ; { long o l d = Sick ; i f ( xtime > 0L ) { i f ( S i c k _ r e s i s t a n c e ) return ; i f (! o l d ) { / newly s i c k / You_feel ( " d e a t h l y s i c k. " ) ; } e l s e { / a l r e a d y s i c k / i f ( t a l k ) You_feel ( "%s worse. ", xtime <= Sick / 2 L? " much " : " even " ) ; } s e t _ i t i m e o u t (& Sick, xtime ) ; u. u s i c k _ t y p e = t y p e ; f l a g s. b o t l = TRUE; } e l s e i f ( o l d && ( t y p e & u. u s i c k _ t y p e ) ) { / was s i c k, now n o t / u. u s i c k _ t y p e &= ~ t y p e ; i f ( u. u s i c k _ t y p e ) { / o n l y p a r t l y cured / i f ( t a l k ) You_feel ( " somewhat b e t t e r. " ) ; s e t _ i t i m e o u t (& Sick, Sick 2 ) ; / a p p r o x i m a t i o n / } e l s e { i f ( t a l k ) p l i n e ( " What a r e l i e f! " ) ; Sick = 0L ; / s e t _ i t i m e o u t (& Sick, 0L ) / } } f l a g s. b o t l = TRUE; } i f ( Sick ) { e x e r c i s e (A_CON, FALSE ) ; i f ( c a u s e ) { ( void ) s t r n c p y ( u. u s i c k _ c a u s e, cause, s i z e o f ( u. u s i c k _ c a u s e ) ) ; u. u s i c k _ c a u s e [ s i z e o f ( u. u s i c k _ c a u s e ) 1] = 0 ; } e l s e u. u s i c k _ c a u s e [ 0 ] = 0 ; } e l s e u. u s i c k _ c a u s e [ 0 ] = 0 ; 2

Tämä on pilaantuneen juoman aiheuttamaa sairastumista mallintava funktio C- ohjelmointikielellä kirjoitetun NetHack-pelin [net] lähdekoodista. Funktion kulku on kohtalaisen selkeä, mutta se sisältää monenlaisia viitteitä pelin tietorakenteisiin (esim. flags.botl ja u.usick_type) ja matalan tason muistinhallintaan (strncpy). Tällaisen funktion laatiminen, ymmärtäminen tai muokkaaminen olisi yksinkertaisempaa, mikäli funktiossa voitaisiin pysyä korkealla abstraktiotasolla, eikä olisi tarpeen ottaa kantaa pelin käyttämien tietorakenteiden muotoon tai matalan tason muistirakenteisiin. Uudenaikaisemmat ohjelmointikielet ovat parantaneet tilannetta. Automaattinen muistinhallinta ja olio-ohjelmointi mahdollistavat abstraktiotason kohottamista jonkin verran. Tällä hetkellä vakiintunein peliohjelmointikieli on olio-ohjelmointikieli C++, ja vähäisemmässä määrin käytetään Java- ja C#-ohjelmointikieliä. Nämä ovat kaikki imperatiivisia ohjelmointikieliä, joiden perusjuuret ovat selvästi C:ssä. Olio-ohjelmointi, ainakaan C++:n ja samansukuisten kielien tarjoamassa muodossa, ei yllättäen kuitenkaan tunnu istuvan peliohjelmointiin aivan ongelmitta. Yksi ongelma on jäykän ja hauraan oliohierarkian sovittaminen kuvaamaan hyvin laajaa pelioliotyyppien joukkoa [Wes06]. Toinen ongelma voidaan esittää kielellisellä vertauksella. Oliokielet keskittävät mallinnuksensa substantiiveihin [Yeg06], luokkiin ja olioihin. Dynaamisissa pelimaailmoissa tärkeitä ovat taas substantiivien sijasta verbit [Cra05]. Esimerkiksi yllä olevassa NetHack-esimerkissä funktio mallintaa saastuneen juoman juomista, verbiä. Substantiiviosapuolina ovat juoja ja juoma, ja olio-ohjelmoinnissa toiminnallisuus kuuluisi sijoittaa näitä kuvaaviin olioihin. Oliosuunnittelu ei kuitenkaan tunnu tarjoavan kovin helppoa vastausta kysymykseen, kumpaan näistä olioista saastuneen juoman juomisen vaikutuksien kuvailu kuuluisi. Mikäli olio-ohjelmointi ei näytä olevan yksikäsitteisesti askel oikeaan suuntaan pelitoiminnallisuuden kuvailemisessa, olisiko olemassa jokin parempi tapa? Tarkastellaan eksaktia, mutta yksinomaan ihmisen luettavaksi tarkoitettua sääntöä kynällä ja paperilla pelattavasta GURPSroolipelistä [JP03]: Move Your Move is the distance (in yards) you can actually run in one second. To 3

find your Move, add up the total weight of all your possessions and find your encumbrance level. Now subtract your encumbrance penalty from your Speed score, and round down. The result is your Move score always a whole number, not a fraction. Your Move controls: (1) How fast you can move. (If you have the Running skill, add 1/8 of your skill level to Basic Speed for this purpose only. Don t round off until the very end! Running doesn t affect your Speed score, but it will help your Move.) (2) When you move. (3) Your Dodge defense (p. 26). This active defense is equal to your Move. The less weighted-down you are, the quicker you can dodge! Your Move can never be reduced to 0 unless you are unconscious, unable to use your legs, or lifting over 30 times your ST. Sääntöteksti kuvailee sitä, millainen toiminta on mahdollista ylipäätään tai miten mahdollisuudet muuttuvat tietyissä olosuhteissa. Esitystapa eroaa selvästi imperatiivisesta ohjelmoinnista. Säännön hahmon liikkumisetäisyydestä oletetaan toimivan pelissä, vaikka missään ei ole annettu yksityiskohtaista käskysarjaa, jolla hahmon liikkuma matka todellisessa pelitilanteessa määritettäisiin. Myöskin lisäehtojen oletetaan pätevän sillä perusteella, että ne on ilmoitettu tässä yhdessä paikassa. Sääntöä liikkumisnopeuden pysymisestä nollan yläpuolella erityisolosuhteiden ulkopuolella ei ole tarpeen käskeä tarkistettavaksi muualla, kun se on kerran esitetty. Luonnollisella kielellä kuvatut säännöt jättävät lukijan vastuulle päätöksen siitä, milloin sääntöjä tulee soveltaa. Imperatiivisessa ohjelmoinnissa ohjelmoija joutuu kuvailemaan tarkasti, mitä milloinkin tulee tarkastaa, ja deklaratiivisemmat säännöt ovat toimintaohjeissa vain implisiittisinä. Deklaratiivisten sääntöjen suorituksesta päättäminen on automatisoitavissa. Sopivilla ohjelmointitekniikoilla voidaan pelin sääntöjä kuvailla muodossa, joka muistuttaa paljon enemmän sitä tapaa, jolla ihminen kuvailee sääntöjä toisille ihmisille. Ehkä vaikuttavin esimerkki tästä tekniikasta on Graham Nelsonin kehittämä Inform 7 -tekstipeliohjelmointikieli [Nel] [Nel06] Seuraava esimerkki on Emily Shortin pelin Bronze [Sho06] Inform 7 -lähdekoodista. A t h i n g has some t e x t c a l l e d sound. The sound of a t h i n g i s u s u a l l y " s i l e n c e ". A p r o c e d u r a l r u l e : i g n o r e t h e b l o c k l i s t e n i n g r u l e. 4

Carry o u t l i s t e n i n g t o something : i f i n d a r k n e s s, say " The [ sound of t h e noun ] sounds l i k e [ a noun ]. " ; o t h e r w i s e say " From [ t h e noun ] you h e a r [ t h e sound of t h e noun ]. " D e f i n i t i o n : a t h i n g i s a u d i b l e i f t h e sound of i t i s n o t " s i l e n c e ". E c h o l o c a t i n g i s an a c t i v i t y. B efore p r i n t i n g t h e name of something a u d i b l e ( c a l l e d t a r g e t ) w h i l e e c h o l o c a t i n g : i f t h e t a r g e t i s n o t t h e p l a y e r, say " [ sound ] from [ i f t h e t a r g e t i s n o t t h e p l a y e r ] t h e [ end i f ] " Rule f o r p r i n t i n g t h e name of t h e p l a y e r w h i l e e c h o l o c a t i n g : i f t h e p l a y e r i s n o t a u d i b l e, say " y o u r s e l f " ; o t h e r w i s e say " your own [ sound of t h e p l a y e r ] " Luonnollisen kaltaista kieltä käyttävillä ohjelmointikielillä on ansaittu huono maine. Ulkonäöstään huolimatta kieli on paljon rajoittuneempi kuin aito luonnollinen kieli, ja käytännössä oikean syntaksin tuottaminen saattaa olla oleellisesti hankalampaa kuin perinteisemmin muotoillulla ohjelmointikielellä. Inform 7 on kuitenkin saanut hyvin positiivisen vastaanoton tekstipeliympyröissä, joten ilmeisesti lähestymistapa voi tässä tapauksessa toimia. Voidaan kuitenkin myös arvata, että luonnollinen kieli sopii erityisen hyvin juuri parseritekstipelien toteutuskieleksi. Näin tiiviisti luonnollista kieltä mukailevan lähestymistavan soveltuvuudesta vähemmän itsessään luonnollisen kielen käsittelyyn liittyviin sovellusalueisiin ei toistaiseksi ole takeita. Liian tiukasti matalalle ohjaustasolle sitovan imperatiivisen ohjelmoinnin ja huonosti ohjelmoinnin vaatimaan yksikäsitteiseen ilmaisuun sopivan luonnollisen kielen välissä on kuitenkin vielä vaihtoehtoja. Tässä artikkelissa käsitellään sääntöjärjestelmiä. Ne ovat ohjelmointikieliä, joissa toiminnallisuus esitetään joukkona sääntöjä, jotka koostuvat ehdoista ja seuraamuksista. Sääntöjärjestelmillä on pitkä historia, mutta niitä on käytetty tietokonepeleissä verrattain vähän. Eräs tunnetumpi esimerkki on CLIPS-kieltä [cli] muistuttavaa kieltä käyttävä Age of Empires 2 [Ens99]. Seuraava on eräs pelin tekoälyskripti kirjan Core Techniques and Algorithms in Game Programming mukaan [Dal03]: ( d e f r u l e ( game time > 1100) 5

=> ( a t t a c k now ) ( enable t i m e r 7 1100) ( d i s a b l e s e l f ) ( chat l o c a l to s e l f " f i r s t a t t a c k " ) ) ( d e f r u l e ( t i m e r t r i g g e r e d 7) ( defend s o l d i e r c o u n t >= 12) => ( a t t a c k now ) ( d i s a b l e t i m e r 7) ( enable t i m e r 7 1400) ( chat l o c a l to s e l f " o t h e r a t t a c k s " ) ) Skriptin toiminta on verrattain helposti luettavissa, ja se keskittyy vain oleelliseen eli siihen, mitä tapahtuu. Koodia ei kuormiteta suoritusohjeilla siitä, milloin mikäkin ehto tarkastetaan ja miten muunnettavia tietorakenteita tarkkaan ottaen käsitellään. Esimerkin kuvaama toiminnallisuus on tosin muutenkin varsin yksinkertainen. 2 Sääntöjärjestelmät Sääntöjärjestelmiä alettiin kehittää 1970-luvulla asiantuntijajärjestelmien (engl. expert system) toteutustekniikaksi. Asiantuntijajärjestelmiä kehitettiin esittämään jonkin inhimillisen tietämyksen alueen tietoa koneen ymmärtämässä muodossa. Varhaisia asiantuntijajärjestelmiä olivat esimerkiksi orgaanista kemiaa käsittelevä DENDRAL ja bakteeritartuntojen aiheuttamia oi- 6

reita tunnistava MYCIN [DK84]. Myöhemmin oivallettiin, että asiantuntijajärjestelmän perustoiminnallisuus ei riipu sen käsittelemästä tietämyksen alasta. Alakohtaisen järjestelmän sijasta voidaan toteuttaa yleinen päättelyjärjestelmä, jolle määritellään sääntöjoukkona tiettyä aluetta koskeva tietämys. Eräs laajasti käytetty ja nykyään lähdekoodiltaan avoin sääntöjärjestelmä on NASAn 1980-luvulla kehittämä CLIPS [cli]. Sääntöjärjestelmä on rakenteeltaan yksinkertainen. Se koostuu väittämiä (engl. assertion) sisältävästä työmuistista (engl. working memory), joukosta sääntöjä ja sääntöjä työmuistiin soveltavasta tulkista. Väittämät voivat olla yksinkertaisia symbolilistoja, esimerkiksi (speed stealth-tank 14), (becomes-invisible stealth-tank). Säännöt taas koostuvat kahdesta osasta. Ensimmäinen osa on hahmo (engl. pattern), johon sopivat väittämät täytää löytää työmuistista. Toinen puolisko kuvaa muutoksia, joita tehdään, mikäli sääntö toteutuu. Sääntökielen syntaksi on jossain määrin erilainen eri puoliskoissa. Esimerkki CLIPS-kielen tyylisellä syntaksilla kirjoitetusta strategiapelin säännöstä, joka sanoo, että yksiköt jotka pystyvät muuttumaan näkymättömiksi, muuttuvat näkymättömiksi, kun niitä kohti tulitetaan voisi olla: ( d e f r u l e a c t i v a t e s t e a l t h under f i r e ( under f i r e? x ) ( becomes i n v i s i b l e? x ) ( n o t ( i s i n v i s i b l e? x ) ) => ( a s s e r t ( i s i n v i s i b l e? x ) ) ) Syntaksi on selvästi Lisp-vaikutteinen, vaikka CLIPS ei sinänsä olekaan Lisp-murre (samankuuloinen nimi on lyhenne sanoista "C Language Integrated Production System"). Tämä johtunee siitä, että asiantuntijajärjestelmät ovat perua ajalta, jolloin tekoälyjärjestelmiä rakennettiin pääasiassa Lisp-pohjaisissa ohjelmointiympäristöissä, ja Lispin päälle rakennetut sovellusaluekielet kierrättivät Lispin sulkusyntaksia. Esimerkkisäännössä huomioitavaa on muuttujan sieppaus?x-syntaksilla. Tähän muuttujaan 7

voidaan sitoa mikä tahansa muuten sopivasta työmuistin väittämästä löytyvä arvo, mutta kaikkiin säännössä samannimisiin muuttujiin on sovitettava sama arvo. Sääntö siis soveltuu mihin tahansa olioon, joka kolmen luetellun ehdon mukaisesti on tulituksen kohteena, kykenee muuttumaan näkymättömäksi eikä ole jo näkymätön. Säännön seurausosa on merkin => alapuolella. Seurauksessa assert lisää työmuistiin uuden väittämän. Jotta sääntö toimisi, väittämä under-fire tulituksen kohteeksi joutumisesta on jollain tavalla päivitettävä työmuistiin pelin tilanteen mukaan. Se voi tulla joko toisesta säännöstä tai sitten esimerkiksi pelin fysiikkamoottorista, joka on viritetty tuottamaan tämä väittämä, mikäli ammusolio osuu riittävän lähelle muuttujan?x merkitsemää oliota. Järjestelmässä on olemassa menetelmä myös väittämien poistamiseen työmuistista. Säännöt voivat muutenkin vaikuttaa toisiinsa. Jos esimerkiksi häivetankki muuttuu näkymättömäksi erillisen generaattorin avulla, voidaan poistaa väittämä (becomes-invisible stealth-tank) ja sen sijaan antaa kantaan väittämä (has-stealth-generator stealth-tank) ja lisätä uusi sääntö: ( d e f r u l e s t e a l t h e n a b l e s i n v i s i b i l i t y ( has s t e a l t h g e n e r a t o r? x ) => ( a s s e r t ( becomes i n v i s i b l e? x ) ) ) Nyt tulkki lisää automaattisesti työmuistiin tiedon siitä, että häivegeneraattorilliset yksiköt pystyvät muuttumaan näkymättömiksi. Uusi väittämä mahdollistaa activate-stealth-under-fire-säännön aktivoimisen. Sääntöjärjestelmä täytyy kytkeä jotenkin muuhun peliohjelmaan. Peliohjelma voi kertoa sääntöjärjestelmälle alkutilanteen lisäämällä itse väittämiä sääntöjärjestemän työmuistiin. Kanava sääntöjärjestelmästä muuhun peliohjelmaan voi perustua myös työmuistin käsittelyyn, tai olla vieläkin suoraviivaisempi. Koska säännön seuraamusosuus koostuu ehtohahmojen sijasta komennoista, siinä voidaan yksinkertaisesti kutsua komentoja, jotka on sidottu peliohjelmaan ja muuttavat suoraan peliohjelman sääntöjärjestelmän ulkopuolista tilaa. 8

Sääntöjärjestelmät perustuvat eteenpäin ketjutukseen (engl. forward chaining). Eteenpäin ketjutuksessa työmuistiin lisätään työmuistin nykyisestä sisällöstä ja säännöistä johdettavat uudet väittämät. Edellisen esimerkin uuden väittämän tuottaminen on eteenpäin ketjutusta. Eteenpäin ketjutuksen vastinpari on taaksepäin ketjutus (engl. backward chaining). Esimerkiksi Prologlogiikkaohjelmointikieli perustuu taaksepäin ketjutukseen. Siinä lähdetään haetusta päämäärästä ja etsitään siirtymiä taaksepäin, kunnes päädytään joko tunnettuihin alkutietoihin tai umpikujaan. Pelin logiikkaa mallintavassa sääntöjärjestelmässä eteenpäin ketjutus on selvästi haluttu käsittelytapa. Simulaatiomaisessa pelissä ei ole mitään päämäärää, vaan ollaan kiinnostuneita siitä, mihin uuteen tilaan senhetkinen pelitila ja pelaajan syötteet johtavat. Toisaalta päämäärähakuisessa suunnittelevassa tekoälyssä tarvitaan taaksepäin ketjutusta, jotta voitaisiin löytää sopiva suunnitelma kaikkien mahdollisten toimintasarjojen joukosta sen sijaan että vain ajelehdittaisiin seurauksesta toiseen. Huomattavaa on siis, että eteenpäin ketjuttavaa sääntöjärjestelmää ei käytetä varsinaisen päämäärätietoista ja suunnittelevaa ihmistä jäljittelevän tekoälyn kuvaamiseen, vaan ennemminkin sen ympäristön kuvaamiseen, jossa tekoälyjäkin ajetaan. Naiivi toteutus sääntöjärjestelmän tulkille kävisi aina läpi kaikki säännöt ja yrittäisi sovittaa niitä koko työmuistiin. Sääntöjärjestelmien perusratkaisuna on pitkään ollut Charles L. Forgyn 1970-luvulla kehittämä tätä tehokkaampi Rete-algoritmi (esim. Doorenbos [Doo95]). Retealgoritmi muodostaa suunnatun verkon, jonka rakenteeseen säilötään tieto siitä, mihin sääntöihin jo olemassaolevat väittämät vaikuttavat. Kun työmuistiin lisätään tai sieltä poistetaan väittämä, toimenpiteen laukaisemat säännöt voidaan selvittää verrattain nopeasti käymällä Reteverkkoa läpi tämän väittämän kanssa. Rete-algoritmi parantaa merkittävästi sääntöjärjestelmän suorituskykyä muistitilan kustannuksella. Algoritmia käyttävän sääntöjärjestelmän suorituskyky on teoriassa riippumaton sääntöjen määrästä, mutta suurilla sääntöjoukoilla muistinkulutus voi kasvaa merkittäväksi. Sääntöjärjestelmä mahdollistaa siis sovelluslogiikan esittämisen yksinkertaisessa muodossa ja irrallaan siitä, milloin mitäkin sääntöä tulee soveltaa. Tämä ei ole yksinomaan hyvä asia. Sään- 9

töjärjestelmissä ongelmaksi voi mutkikkaan käsin ylläpidettävän suorituslogiikan sijasta muodostua se, että suoritusjärjestys ei ole helposti hahmotettavissa. Suuri joukko toisiinsa vaikuttavia sääntöjä voi tuottaa hankalasti jäljitettäviä ongelmia. Muita sääntöjärjestelmiä ovat Charles Forgyn kehittämä OPS5, CLIPSiä ilmaisuvoimaisemmaksi mainittu Soar [WL00] ja uudempi Java-alustalla toimiva ja CLIPSiä laajentava Jess [Hil03]. Sun on esittänyt JSR-94-standardia Java-alustan sääntöjärjestelmille [jsr00]. 3 Sääntöjärjestelmät ja tietokonepelit Sääntöjärjestelmien kielet ovat dynaamisesti tyypitettyjä ja ajonaikana tulkattavia kieliä. Tältä osin ne vastaavat pelien tavanomaisempia skriptikieliä, ja niillä on vastaavat edut ja haitat pelin päätoteutuskieleen nähden. Sääntökoodia voidaan ladata ja muuttaa pelin ollessa käynnissä, sitä voi muokata ilman erityisen laajaa ohjelmointikokemusta ja ilman erillisiä käännöstyökaluja ja sitä voi sisällyttää pelin laitteistoriippumattomiin lisukekomponentteihin. Sääntöjärjestelmällä toteutettu toiminnallisuus on toisaalta todennäköisesti selvästi hitaampaa suorittaa kuin ydinkielellä toteutettu. Sääntöjärjestelmä tuo myös omia etujaan ja haittojaan. Toisin kuin perinteiset imperatiiviset skriptikielet, sääntöpohjanen ohjelmointi on deklaratiivista. Sanotaan siis mitä halutaan tapahtuvan, ei vain miten halutaan asioiden tapahtuvan. George Rudolphin artikkeli Some guidelines for deciding whether to use a rules engine [Rud] kuvailee olosuhteita, joissa sääntöjärjestelmän käyttö on perustelua. Jonathan Blow kirjoittaa artikkelissaan Predicate logic [Blo03] olio-ohjelmoinnin ongelmista useamman olion suhteiden kuvaamisessa ja tarjoaa relaatiot helposti hallitsevaa logiikkaohjelmointimallia olioiden tilalle. Blow käsittelee ajatuksiaan edelleen ilmeisesti nyttemmin hylättyä Lerp-skriptikieliprojektiaan perustavissa artikkeleissa [Blo]. Blow esittää esimerkkinä deklaratiivisen ratkaisun aiheuttamasta monimutkaisuuden vähentämisestä pelihahmot, jotka voivat kantaa esineitä. Olio-ohjelmoinnissa luonteva tapa toteuttaa 10

tämä on lisätä pelihahmon olioon osoittimet sen kantamiin esineolioihin. Peliin voidaan kuitenkin haluta esine, joka poistaa itse itsensä kantajansa hallusta. Tällöin esineen täytyy voida tehokkaasti selvittää, kuka sitä kantaa. Ainoa yksinkertainen ratkaisu on lisätä myös kannettavaan esineeseen osoitin sitä kantavaan hahmoon. Nyt järjestelmässä on selvä tarpeeton monimutkaisuus, kaksi osoitinta, joiden arvot on aina pidettävä yhtäsuurina. Sääntöjärjestelmässä riittäisi yksi väittämä muotoa (kantaa hahmo esine). Sääntöjärjestelmään voidaan myöhemmin tehdä indeksejä hakemaan väittämiä tehokkaasti eri parametriensa suhteen. Tämä lähestymistapa muistuttaa jonkin verran relaatiotietokantoja, joiden rakennetta on jäljitelty muissakin pelitoteutusten hahmotelmissa [WDK + 07]. Nathan Combsin ja Jean-Louis Ardontin artikkeli Declarative versus Imperative Paradigms in Game AI [CA05] kuvailee lyhyesti sääntöjärjestelmien etuja peliohjelmoinnissa. Combs ja Ardont kutsuvat perinteistä peliohjelmointia ympäristöpohjaiseksi (engl. environment-based). Ympäristöpohjainen malli on Combsin ja Ardontin mukaan kolmiportainen. Ensin kehittäjä määrittelee ympäristön rakenteen, esimerkiksi pelimaailman kartan, seuraavaksi kehittäjä lisää pelimaailmaan peliolioita ja viimeiseksi lisää dynaamisille peliolioille käyttäytymisohjeet. Tämä tyyli johtaa pelilogiikkaan, joka toimii oikein juuri siinä ympäristössä, josta kehitys lähti, mutta joka ei ole yleistettävissä erilaisiin ympäristöihin. Toimiminen täsmälleen tietyllä tavalla täsmälleen tietyssä ympäristössä saattaa olla juuri sitä, mitä pelilogiikalta halutaankin. Monet pelit, esimerkiksi erittäin suosittu Half-Life 2 [Val04], on rakennettu elokuvamaisiksi lineaarisiksi kokemuksiksi, joissa pelaaja käy läpi suunnittelijan asettamassa järjestyksessä mahdollisimman viihdyttäviksi muokattuja etukäteen määriteltyjä kohtauksia. Lähestymistapa on kuitenkin huomattavasti vähemmän hyödyllinen, mikäli pelilogiikan halutaan toimivan mielekkäällä tavalla myös ennakoimattomissa tilanteissa ja esimerkiksi jos pelin halutaan tukevan satunnaisgeneroituja tai kolmansien osapuolien tuottamia karttoja. Ongelmana ovat lisäksi erittäin suuret pelimaailmat. Toiminnallisuuden tuottaminen käsin hyvin suuren pelimaailman joka kolkkaan vaatii valtavat määrät pelinkehittäjän resursseja. 11

Combs ja Ardont vertaavat sääntöjärjestelmiä imperatiivisiin skripteihin. He esittävät sääntöjärjestelmien eduiksi käytännöllisyyden, skaalautuvuuden, käytettävyyden ja ilmaisuvoiman. Käytännöllisyyttä on sääntöjärjestelmän irroittaminen pelin matalan tason toteutuksesta. Tämä mahdollistaa kummankin osuuden kehittämisen ja testaamisen toisistaan irrallaan. Skaalautuvuus seuraa sääntöjen yleistettävyydestä yksittäisisitä olioista olioiden joukkoihin ilman merkittävää ylimääräistä kehitystyötä. Deklaratiivisia sääntöjä voi myös tulkita ja muokata koneellisesti paljon tehokkaammin kuin eksplisiittisen tilan kanssa kietoutunutta imperatiivista skriptikoodia, mikä voi auttaa sääntöjen sovellettavuutta hyvin laajassa mittakaavassa. Käytettävyys seuraa taas pelilogiikan erottamisesta perustoteutuksesta ja ilmaisuvoima siitä, että usein on helpompi ilmaista mitä halutaan tapahtuvan kuin antaa tarkat toimintaohjeet miten sen tulisi tapahtua. Combs kuuluu International Game Developers Associationin tekoälystandardointikomiteaan AIISC. Combsin ja Ardointin artikkelissa ja myös AIISC:n raporteissa [NCK + 05] esitetään tarve peliteollisuuden laajuiselle standardille sääntöjärjestelmille. Tämä takaisi yhteisen pohjakielen, jota erilaiset symbolista tekoälyä käyttävät väliohjelmistoratkaisut voisivat käyttää. Combsin artikkelissa ja AIISC:n raportissa ehdotetaan, että tähän voitaisiin käyttää JSR-94- standardia [jsr00]. JSR-94 määrittelee perinteisen sääntöjärjestelmän ja jättää ilmeisesti mahdollisuuden varsin monenlaisiin käytännön toteutustekniikoihin. Flávio da Silva ja Wamberto Vasconcelos pitävät JSR-94:ää liian sallivana ja vaikeasti ylläpidettäviä ohjelmointitekniikoita suosivana ja ehdottavat niiden tiukentamista koneellisesti tarkistettavilla sääntöskeemastoilla (engl. rule schemata) ja esimerkiksi deonttisella logiikalla [dsv06]. AIISC-komitea ilmeisesti hajosi, ennen kuin se ehti laatia lopullista standardia [YdB06]. Ian Wright ja James Marshall ovat myös tutkineet sääntöjärjestelmiä peleihin kehittämänsä RC++-kielen puitteissa. Kielen toteutusta tai tarkkaa määritelmää ei ilmeisesti ole saatavilla. Wright kritisoi imperatiivisia skriptikieliä liian samanlaisiksi pelien perustoteutuskielen kanssa. Skriptikielestä ei saa Wrightin mukaan riittävää hyötyä, jos sen ilmaisutapa ei ole paremmin pelien sovellusalueeseen muokattu [WM00]. 12

Wright tarkastelee julkaisussaan The execution kernel of RC++ [WM03] sääntöjärjestelmien soveltuvuutta pelitekoälyyn. Wright arvioi, ettei yleinen sääntöpohjainen tekoälyarkkitehtuuri vielä sovellu täysin tietokonepeleihin. Wrightin mukaan reaaliaikaiset pelit vaativat tekoälykoodin optimoimista ongelma-alueelle soveltuvaksi, eikä tämä onnistu hyvin yleiskäyttöisellä sääntöytimellä. Wright on tehnyt tutkimuksensa vuosikymmenen alussa Sonylle ja siten oletettavasti Playstation 2 -pelikonsolia varten. Nykymittapuulla Playstation 2:n yleinen suoritusteho on heikko, joten Wrightin arvio ei välttämättä enää nykykoneiden suhteen päde. Toinen Wrightin mainitsema ongelma on, että sääntöpohjainen tekoälyjärjestelmä vaatii tietämyksen symbolista esitystä. Mikäli sääntöjärjestelmän tehtävänä on määrittää pelin tekoälyhahmojen käyttäytyminen, on ongelmana edelleen pelin virtuaalimaailman tapahtumien esittäminen tällaisina selkeinä, symbolisina sääntöinä. Sääntöjärjestelmien tehokkuusongelmat pelikäytössä mainitsee myös GrexEnginemassiivimoninpeliväliohjelmistoa kehittänyt Adam Martin VWorld-postituslistalla [Mar04]. Lynne Hall et al. kirjoittavat sääntöjärjestelmien onnistuneesta käytöstä mobiililaitteilla artikkelissa A Lightweight Rule-Based AI Engine for Mobile Games [HGJN04]. Hall et al. toteuttivat pokeripelin tekoälyn sääntöpohjaisena Mimosa-sääntökielellä. Hyvä tulos on jonkin verran yllättävä, koska muistin ja laskennan rajoitukset ovat mobiilialustoilla huomattavasti tiukemmat kuin täysikokoisilla pelikoneilla. Pokeri on kuitenkin myös paljon suppeampi ongelma-alue kuin jossain määrin fyysistä maailmaa muistuttavat peliympäristöt, joihin sääntöjärjestelmiä useimmin harkitaan. 4 Sääntöjärjestelmien tulevaisuus Tehokkuusvaatimuksiensa vuoksi peliohjelmointi on perinteisesti ollut hidas omaksumaan ilmaisukykyisempiä, mutta hitaammin suoriutuvia ohjelmointitekniikoita. Sääntöjärjestelmät ovat toistaiseksi peliohjelmointikentällä hyvin marginaalinen ilmiö, ja syy voi olla osaksi tehokkuusongelmissa. Dynaamiset skriptikielet ovat kuitenkin olleet arkipäivää jo vuosia, joten 13

luultavasti sääntöjärjestelmien omaksuntaa hidastavat muutkin tekijät. Yksi voi olla myös se, että logiikkapohjaiset ratkaisut vaativat hyvin erilaista lähestymistapaa ohjelmointiin, eikä peliohjelmoijilla ole välttämättä ollut kiinnostusta omaksua tällaista tapaa ilman takeita sen hyödyllisyydestä. Konetehojen kasvaessa ja pelien monimutkaistuessa tämä asenne saattaa kuitenkin hiljalleen muuttua. Eräs kiinnostava kehitysaskel viime vuosina on massiivimoninpelien nousu. Massiivimoninpeleillä on kaksi sääntöjärjestelmien kannalta kiinnostavaa ominaisuutta: niiden pelimaailmoissa on hyvin suuri määrä sisältöä, ja niiden pelilogiikkaa suoritetaan pelin ylläpitäjän omistamalla palvelimella. Sääntöjärjestelmän mahdollistama helpompi skaalattavuus ja pelitoiminnallisuuden emergoituminen sääntöjen seurauksista on erityisen hyödyllistä, jos pelimaailma on hyvin suuri ja loogisesti monimutkainen. Palvelimella suorittaminen taas tarkoittaa sitä, että konetehorajoitukset eivät ole mahdottoman tiukat. Mikäli peli on kannattava, ylläpitäjä voi hankkia enemmän palvelinkoneita suorittamaan pelimaailman logiikkaa. Massiivimoninpeli-ilmiö on osoittautunut hyvin menestyksekkääksi ja kehittää varmasti tarvetta teoreettisempaan lähestymiseen aivan kuten pelaajankin koneelle suunnattu peliohjelmointi. On myös mahdollista, että kotitietokoneiden vuosikymmenten ajan eksponentiaalisesti kasvanutta tehoa aletaan hyödyntää merkittävästi monimutkaisempaan pelilogiikkaan äärimmäisen yksityiskohtaisen grafiikan ja raskaan fysiikkamallinnuksen lisäksi. Esimerkiksi kulttimaineen kehittänyt harrastelijapeli Dwarf Fortress [AA06] käyttää ääriyksinkertaista merkkigrafiikkaa, mutta toteuttaa niin monimutkaisen pelimaailman simulaatiomallin, että sujuva pelaaminen onnistuu kuitenkin parhaiten vasta tehokkaalla ja uudella PC:llä. Sääntöjärjestelmässä ja siitä emergoituvalla pelitoiminnallisuudella on omat tasapainotusongelmansa, mutta se saattaa silti olla pienellä tuotantobudjetilla helpommin toteutettavissa kuin laajan pelin kaiken sisällön skriptaaminen käsin. Emergentin pelitoiminnallisuuden ongelmia voidaan tasapainottaa paremmin myös pelin julkaisun jälkeen, koska peli pitää todennäköisesti pelaajien mielenkiintoa yllä pidempään kuin kertaluonteiseen skriptattuun sisältöön perustuva peli. Pääasiassa moninpeliksi tarkoitetuissa peleissä tasapainottavat päivitykset julkaisun jäl- 14

keen ovat yleensä käytännössä välttämättömiä, massiivimoninpeleihin lisätään jatkuvasti uutta sisältöä, ja myös aiemmin mainittu Dwarf Fortress on julkaisunsa jälkeen kehittynyt hyvin erilaiseksi peliksi. Sääntöjärjestelmät saattavat soveltua hyvin toteutusmekanismiksi tällaiseen emergenttiin pelitoiminnallisuuteen nojaavaan pelityyppiin. Tällaiset pelit, moninpelit, strategiapelit ja rakentelupelit, ovat pelimarkkinoilla suhteellisen tasapuolisesti edustettuina tiukempaan skriptaukseen perustuvien juonipelien kanssa. Ne ovat myös pienelle pelinkehittäjälle houkutteleva vaihtoehto. Kartansuunnittelu ja skriptaus ovat aikaavieviä, joten miksei ohjelmoisi peliä generoimaan sisältöään ja päättelemään itse, millaisia tapahtumia siitä seuraa. Lähteet AA06 Adams, T. ja Adams, Z., Slaves to Armok: God of Blood Chapter II: Dwarf Fortress, 2006. URL http://www.bay12games.com/dwarves/. Blo Blow, J., The Lerp programming language. URL http://lerp.org/. Blo03 Blow, J., The Inner Product: Predicate logic, 2003. URL http:// number-none.com/product/predicate\%20logic/index.html. CA05 Combs, N. ja Ardoint, J.-L., Declarative versus imperative paradigms in games AI, 2005. URL http://www.roaringshrimp.com/ws04-04ncombs. pdf. cli CLIPS reference manual: Version 6.24. URL http://www.ghg.net/ clips/download/documentation/bpg.pdf. Cra05 Crawford, C., Artists and technologists, 2005. URL http: //www.erasmatazz.com/library/game%20design/ Technologists&Artists.html. 15

Dal03 Dalmau, D. S.-C., Core Techniques and Algorithms in Game Programming. New Riders Games, 2003. DK84 Davis, R. ja King, J. J., The origin of rule-based systems in AI. Teoksessa The Mycin Experiments of the Stanford Heuristic Programming Project, Addison-Wesley, 1984, sivut 20 52, URL http://www.aaaipress.org/ Classic/Buchanan/buchanan.html. Doo95 Doorenbos, R. B., Production Matching for Large Learning Systems. Väitöskirja, Carnegie Mellon University, Pittsburgh, PA, 1995. URL http://reports-archive.adm.cs.cmu.edu/anon/1995/ CMU-CS-95-113.pdf. dsv06 da Silva, F. S. C. ja Vasconcelos, W. W., Rule schemata for game artificial intelligence. Advances in Artificial Intelligence IBERAMIA-SBIA 2006, 2006, sivut 451 461, URL http://www.csd.abdn.ac.uk/~wvasconc/pubs/ correadasilvasbia2006.pdf. Ens99 Ensemble Studios, Age of Empires II: The Age of Kings, 1999. URL http: //www.microsoft.com/games/age2/. HGJN04 Hall, L., Gordon, A., James, R. ja Newall, L., A lightweight rule-based AI engine for mobile games. Teoksessa Advances in Computer Entertainment Technology, ACM Press, 2004, URL http://osiris.sunderland.ac.uk/ ~cs0lha/publications/2004/mimosa-ace.pdf. Hil03 Hill, E. F., Jess in Action: Java Rule-Based Systems. Manning Publications Co., Greenwich, CT, USA, 2003. JP03 Jackson, S. ja Punch, S., GURPS Lite, 2003. URL http://www.sjgames. com/gurps/lite/3e/gurpslit.pdf. 16

jsr00 JSR 94: Java Rule Engine API, 2000. URL http://jcp.org/en/jsr/ detail?id=94. Mar04 Martin, A., VWorld ontology, 2004. URL http://lists.puremagic. com/pipermail/vworld-tech/2004-april/000298.html. Postitusryhmäviesti. NCK + 05 Nareyek, A., Combs, N., Karlsson, B. F. F., Mesdaghi, S. ja Wilson, I., The 2005 report of the IGDA s artificial intelligence interface standards committee. Tekninen raportti, International Game Developers Association, 2005. URL http://www.igda.org/ai/report-2005/report-2005.html. Nel Nelson, G., Inform 7. URL http://www.inform-fiction.org/i7/ Inform%207.html. Nel06 Nelson, G., Natural language, semantic analysis and interactive fiction, 2006. URL http://www.inform-fiction.org/i7downloads/ Documents/WhitePaper.pdf. net Rud NetHack. URL http://www.nethack.org. Rudolph, G., Some guidelines for deciding whether to use a rules engine. URL http://herzberg.ca.sandia.gov/jess/guidelines. shtml. Viewed 2008-02-08. Sho06 Short, E., Bronze, 2006. URL http://www.inform-fiction.org/ I7Downloads/Examples/bronze/. Val04 Valve Corporation, Half-Life 2, 2004. URL http://www.half-life2. com/. WDK + 07 White, W., Demers, A., Koch, C., Gehrke, J. ja Rajagopalan, R., Scaling games to epic proportions. SIGMOD 07: Proceedings of the 2007 ACM SIGMOD interna- 17

tional conference on Management of data, New York, NY, USA, 2007, ACM, sivut 31 42, URL http://www.cs.cornell.edu/~wmwhite/papers/ 2007-SIGMOD-Games.pdf. Wes06 West, M., Evolve your hierarchy refactoring game entities with components. Teoksessa Game Developer Magazine, osa 13, 2006, URL http://cowboyprogramming.com/2007/01/05/ evolve-your-heirachy/. WL00 Wallace, S. A. ja Laird, J. E., Toward a methodology for AI architecture evaluation: Comparing Soar and CLIPS. ATAL 99: 6th International Workshop on Intelligent Agents VI, Agent Theories, Architectures, and Languages (ATAL),, London, UK, 2000, Springer-Verlag, sivut 117 131. WM00 Wright, I. ja Marshall, J., RC++: a rule-based language for game AI. Proceedings of the First International Conference on Intelligent Games and Simulation (GAME-ON 2000). SCS Europe BVBA, marraskuu 2000, URL http: //www.cs.bris.ac.uk/publications/papers/2000441.pdf. WM03 Wright, I. ja Marshall, J., The execution kernel of RC++: RETE*, a faster RETE with TREAT as a special case. International Journal of Intelligent Games and Simulation, 2,1(2003), sivut 36 48. URL http://www.cs.bris.ac.uk/ Publications/Papers/2000091.pdf. YdB06 Yue, B. ja de Byl, P., The state of the art in game AI standardisation. Cyber- Games 06: Proceedings of the 2006 international conference on Game research and development, Murdoch University, Australia, Australia, 2006, Murdoch University, sivut 41 46, URL http://jamsb.austms.org.au/research/ workingpapers/sc-mc-0612.ps. Yeg06 Yegge, S., Execution in the kingdom of nouns, 2006. 18

URL http://steve-yegge.blogspot.com/2006/03/ execution-in-kingdom-of-nouns.html. Vain verkko-osoitteina annetut lähteet on luettu maaliskuussa 2008. 19