Pelin rakenne Pääsilmukka Tapahtumat Suunnittelumalleja Lähteitä Gregory: Game Engine Architecture McShaffry: Game Coding Complete Witters: The Game loop Timo Kellomäki 2011
Pelin rakenne A game is just a real-time database with a pretty front end -Dave Roderick Tyypillisen peliarkkitehtuurin koostumus: Pelimaailman tila Pelilogiikka Näkymä(t) MVC-malli, tai jotain sen tapaista Haitta: sama käsite monessa osassa
Pelin rakenne
Malli Malli sisältää pelimaailman tilanteen kuvaavat tietorakenteet Vastaa kyselyihin pelin tilasta Tarjoaa funktiot, joilla tilaa voi päivittää Tavoitteena alustariippumattomuus - vain abstrakteja tietorakenteita, ei kosketusta laitteistoon
Näkymä Näkymä kysyy mallilta tarvittavat tiedot ja esittää ne pelaajalle sopivassa muodossa Näkymä myös vastaanottaa pelaajan toiminnot ja muuttaa ne tapahtumiksi, joita logiikka osaa käsitellä Näkymä voi olla täysin erilainen paikalliselle ja verkkopelaajalle tai ihmispelaajalle ja AI:lle Ihmispelaajan näkymän tärkeimmät osat grafiikka, äänet, syötteen lukeminen
Ohjain Ohjaimen tehtävä on vastaanottaa syöte näkymiltä ja päivittää mallia sen mukaisesti Fysiikka-/dynamiikkaengine huolehtii esineiden liikkeistä ja törmäyksistä Pelilogiikka sisältää kaiken muun maailmaa muuttavan, kuten kenttien, hahmojen ja esineiden luomisen ja tuhoamisen
Laitteiston piilotus Pelit ovat yleensä tavallista ohjelmaa läheisemmässä kontaktissa laitteiston kanssa Suurin osa ohjaimen ja näkymän tehtävistä on laitteistoriippumatonta Yhtenä osana ohjainta abstraktiokerros, joka piilottaa laitteiston muulta ohjaimelta Laitteistoon liittyviä tehtäviä esim: kello, säikeet, muistinhallinta, resurssit, verkkoliikenne, alustus ja lopetus
Pääohjelma Yksinkertaisimmillaan pelin pääohjelma koostuu kolmesta osasta Alustus Pääsilmukka Lopetus
Alustus Alustuskoodi on hyvin riippuvaista käytettävästä alustasta Tyypillisiä toimenpiteitä, jotka täytyy tehdä ennen pääsilmukkaa: resurssien tarkistus: levytila, muisti, syöttölaitteet, prosessorin nopeus asetusten lukeminen tekstuurien, äänten ym. resurssien lataus piirtoikkunan, äänijärjestelmän ym. alustus
Lopetus Pelin lopetuksessa täytyy huolehtia siitä, että resurssit vapautetaan asianmukaisesti Äänet, ikkunan tuhoaminen, tiedostojen sulkeminen, muistin vapautus,... Peli voi loppua paitsi normaalin quit-napin kautta, myös esim. pelaajan tappaessa prosessin tai virhetilanteessa Joillakin pelialustoilla ei tarvitse murehtia lopettamisesta; laitteen voi vain bootata
Pääsilmukka Useimmat pelit eivät pelkästään odota syötettä, vaan niiden maailma päivittyy itsestään ajan kuluessa Pääsilmukka lukee syötettä, päivittää pelimaailmaa ja esittää maailman tilan näytöllä
Pääsilmukka Ruudulla oleva näkymä päivittyy vain silloin, kun se piirretään uudestaan Toisaalta jos maailmaa ei ole päivitetty välissä, saman tilanteen usein piirtäminen ei auta Silmukan kiertonopeus määrää kehysnopeuden (frame rate, FPS) Kierroksen kesto = Δt = 1/FPS sekuntia Karkeasti ottaen tavoitteena 30-60 FPS
1. yritys pääsilmukaksi while notfinished: # päivitys sisältää syötteen lukemisen update() draw() Nyt peliajan kuluminen riippuu laitteistosta Samallakin laitteistolla vaihtelua riippuen pelitilanteesta (esim. hahmojen määrä ruudulla) Idea: rajoitetaan silmukan pyörimisnopeus johonkin kiinteään maksimi-fps:ään
Kiinteä FPS nextframe = gettime() while notfinished: update() draw() # aika millisekunteja nextframe += 1000 / FPS sleep( max( 0, gettime() - nextframe) ) Ongelma: liian hitaalla laitteistolla tai liian raskaissa kohdissa pelin nopeus vaihtelee Nopean laitteiston teho taas menee hukkaan Parametrisoidaan päivitysfunktion aika-askel
Muuttuva päivitysnopeus while notfinished: lasttime = currenttime currenttime = gettime() update( currenttime - lasttime ) draw() Peli piirtyy nyt niin nopeasti kuin mahdollista Päivittäminen hankalampaa, koska Δt ei vakio Hitaalla koneella päivityksen Δt iso: tahmea ohjaus, ongelmia fysiikassa Δt:n pitäisi olla vakio tai ainakin rajattu sopivasti
Vakionopeus, rajattu FPS nextupdate = gettime() while notfinished: while gettime() >= nextupdate: update() nextupdate += TIMESKIP draw() Päivitys tasaisin väliajoin, mutta piirto aina kun ylimääräistä aikaa jää Kiinteä päivitysnopeus pitää valita siten, että hitaalla koneella ehditään piirtää edes joskus Nopea rauta piirtää monta kertaa päivitystä kohti, joten sama kuva piirretään monta kertaa
Vakionopeus, vaihtuva FPS nextframe = gettime() while notfinished: while gettime() >= nextframe: update() nextframe += TIMESKIP phase = ( gettime() - (nextframe - TIMESKIP) ) / TIMESKIP draw(phase) Päivitys tasaisin väliajoin, piirto kun ehditään Grafiikka voidaan interpoloida, jolloin liike nopealla laitteistolla sulavampaa Päivitystahti voidaan valita riittävän hitaaksi Grafiikan interpolointi joko kahden edellisen ehjän tilan välillä tai ennustamalla
Pääsilmukka Eri versiot silmukasta ovat kompromisseja Joko päivityksen tai piirron Δt:n oltava muuttuva, jos halutaan kaikki tehot irti koneesta Usein pyritään joka tapauksessa 60 FPS:ään, jolloin asiasta ei tarvitse huolehtia tätä varten piirron monimutkaisuutta voidaan säätää dynaamisesti, resoluutiota muuttaa jne. Asiaa helpottaa entisestään, jos koneen nopeus tiedetään etukäteen konsoleilla näin usein onkin, mutta silloinkin eri kohdissa peliä nopeus voi vaihdella
VSYNC Usein monitorin virkistystaajuus on 60 Hz VSYNC (vertical synchronization) tarkoittaa, että grafiikkakortti lähettää uuden kuvan näytölle vain silloin, kun näyttö on valmis piirtämään ilman sitä kuva voi repeytyä kahtia (tearing) jos VSYNC on päällä mutta ei ehditä tuottaa kuvaa, tulos on helposti 30 FPS kolmoispuskurointi auttaa tähän VSYNC muuttaa em. pääsilmukoita
Pelisilmukka ja säikeet Jos pelin päivitys ja piirto ovat omissa säikeissään, molemmat saadaan pyörimään siihen tahtiin kuin halutaan Sivuhyöty: voidaan saada enemmän tehoa irti nykyisistä moniprosessorilaitteistoista Tällöin täytyy huolehtia siitä, että maailma on ehjässä tilassa kun se piirretään Synkronisointi, joka on tunnetusti haastavaa Tuottaja kuluttaja-ongelma
Rinnakkaisuus Rinnakkaisuus on kasvava teema peliohjelmoinnissa Pääsilmukan lisäksi voidaan rinnakkaistaa parhaiten toisistaan riippumattomia asioita eri hahmojen animaatio, eri paikkojen fysiikka eri agenttien tekoäly Osittain riippuvaisetkin asiat voidaan rinnakkaistaa, jos kommunikaatio pysyy vähäisenä
Rinnakkaisuus Lähestymistapoja rinnakkaisuuteen: fork and join: sama tehtävä paloitellaan eri säikeille, sitten taas jatketaan yhdellä erikoistuneet säikeet: kukin tehtävä pyörii omassa säikeessään jatkuvasti työjono, josta kukin säie hakee odottavia pieniä töitä, ei erikoistuneita säikeitä Asynkronisuus: käynnistetään työ, haetaan tulokset myöhemmin (jopa eri framella) Batching: kierretään syntyvää overheadia
Maailman päivitys Pelaajan avatar reagoi tyypillisesti syötteeseen, joka luetaan kontrollilaitteilta Muutkin aktiiviset hahmot voivat toimia samalla tavalla: tekoälyrutiinit generoivat samanlaista syötettä kuin pelaaja Näin saadut komennot syötetään pelin dynamiikkaenginelle, joka muuttaa ne liikkeeksi, toiminnoiksi jne.
Maailman päivitys Passiiviset kohteet, kuten ovet ja esineet päivittyvät esim. fysiikkamoottorin ja animaation suhteen Näistä päivitetään usein vain ne, jotka ovat riittävän lähellä pelaajaa Tekoälyhahmotkin voivat toimia yksinkertaisemman algoritmin mukaan ollessaan kaukana pelaajasta
Tapahtumat Tapahtumat (events) ovat hyvin kätevä tapa jäsentää pelin rakennetta ja hoitaa eri osien väliset yhteydet Esimerkkejä tapahtumista: Hahmo x liikkui koordinaateissa z Hahmo x törmäsi esineeseen y Fysiikka alustettu Peli loppui Peli tallennettu Ääniefekti x loppui Pelaaja x haluaa ampua
Työkalut Modernia peliä tehtäessä iso osa ohjelmoinnista on työkalujen tekemistä maailmaeditori datan esiprosessointi (esim. BSP:n rakennus, valaistuslaskelmat) Työkalujen tavoite mahdollistaa pelisisällön luominen ja muokkaus ohjelmointitaidottomille Datalähtöinen näkökulma Usein työkaluihin liittyy myös skriptaus Työkalujen jakaminen pelaajille auttaa modikulttuuria
Skriptaus Useimmat pelit tehdään käännettävällä, tehokkaalla kielellä, kuten C++ suurin osa koodista ei ole nopeuskriittistä Skriptikielet ovat dynaamisia korkean abstraktiotason kieliä niillä toteuttaminen vie usein vähemmän aikaa Käyttökohteina usein AI, pelitapahtumat, esineiden parametrit... sisällön erotus enginestä
Skriptaus Etuja: Skriptatessa esim. tyypeistä ja muistinhallinnasta tarvitsee huolehtia vähemmän Jokaisen muutoksen jälkeen ei tarvitse kääntää koko peliä eikä välttämättä edes käynnistää sitä uudestaan Skriptaus on ohjelmointia helpompaa, joten sitä voivat tehdä osittain suunnittelijat, taiteilijat ja käyttäjät Skriptikielillä koodaaminen on kivaa!
Skriptaus Ongelmia: heikompi tehokkuus lisää kieliä, lisää monimutkaisuutta debuggaus osin hankalampaa liimakoodin tarve Uuden kielen luominen on melko työlästä, joten jos mahdollista, kannattaa käyttää valmista yleisimpiä Python, Lua, JavaScript moni peliengine tukee jotain skriptikieltä
Suunnittelumalleja Muutamia peliohjelmoinnissa erityisen hyviksi havaittuja suunnittelumalleja Tehdas Erillinen Tehdas-olio, jonka makex()-metodit luovat halutunlaisen olion ja palauttavat osoittimen siihen Tehdas pitää kirjaa luoduista olioista, mikä helpottaa muistinhallintaa Esim. kenttää rakennettaessa luodaan esineet ja olennot näin
Singleton Singleton varmistaa, että luokasta on vain yksi olio Singleton-luokka, josta tällaiset luokat peritään kun käytetään 1. kerran, luodaan instanssi myöhemmillä käyttökerroilla vain käytetään aiemmin luotua instanssia käyttökohteita satunnaisluvut, äänijärjestelmä, pelimaailma, tehdas,... hyödyt kiisteltyjä
Strategia Strategia Strategia-mallilla valitaan ajonaikaisesti eri versioita algoritmeistä Algoritmia varten on kantaluokka, josta eri versiot on periytetty, ja hahmon toimintaa käsitellään kantaluokka-osoittimen kautta esim. pelihahmojen käyttäytyminen
Komento Komento Abstrakti rajapintaluokka Komento, josta erilaiset komennot periytetään ja parametrisoidaan Esim. kun ohjaus toteutetaan näin, voivat komennot tulla muualtakin kuin syötteestä; käyttökohteina mm. välianimaatiot, uusinnat, verkkopeli Toimii hyvin tapahtumajärjestelmän osana
Pelimaailman objektit Pelimaailmassa esiintyvät objektit jaetaan usein kahteen luokkaan: staattiset (liikkumattomat): seinät, osa esineistä dynaamiset: hahmot, efektit, powerupit,... Koska staattisten paikka on aina sama, niiden fysiikka ja grafiikka usein tehokkaampaa esim. valaistus voidaan laskea etukäteen Staattisista voi olla eri versioita, jotta saadaan illuusio dynaamisesta maailmasta
Dynaamiset objektit Iso osa pelin koodista on dynaamisten objektien hallintaa: luominen ja tuhoaminen objektien yhteys engineen: piirto, äänet, ym. reaaliaikainen simulointi: fysiikka, pelisäännöt tilatiedon tarjoaminen muille objekteille kopioiden hallinta verkossa, tallennus, lataus Objektien toteutus: oliot vs. ominaisuudet
Oliopohjainen toteutus Oliokeskeisessä toteutuksessa jokainen erillinen peliobjekti on olio jostakin luokasta Usein kaikki periytyy yleisestä Objekti-luokasta Lisäksi ominaisuuksia: liikkuva, piirrettävä, törmäävä, animoituva,... Jos nämä toteutetaan perimällä, syntyy raskas monoliittinen hierarkia hankala ymmärtää, jäykkä, kuoleman timantti Voi helpottaa korvaamalla periytymisen kompositiolla
Oliopohjainen toteutus GameObject MovableObj Transform AnimController RenderableObj GameObject CollidableObj MeshInstance RigidBody AnimatingObj (tässä täydet nuolet esittävät poikkeuksellisesti perimistä) (Lähde soveltaen: Gregory 2009)
Ominaisuuspohjainen toteutus Olioiden sijaan voi kunkin ominaisuuden arvot esittää omana tietorakenteenaan peliobjekteilla uniikki id, jonka perusteella arvoon pääsee käsiksi Koodin voi laittaa ominaisuuden yhteyteen ominaisuusluokat, ei poikkea edellisestä oliokompositiosta paljoakaan Koodi voi myös olla kasa skriptejä, jotka vain lukevat arvoja tietorakenteista datapohjainen lähestymistapa
Oliot vs. ominaisuudet Ominaisuudet säästävät muistia, välimuisti toimii tehokkaammin koska samat ominaisuudet ovat peräkkäin struct of arrays vs. array of structs Ominaisuuksia voi lisätä dynaamisesti, ei vaikuta luokkarakenteeseen Olioiden yhteistyö ja sisäiset rajoitteet helpommin hallittavissa, selkeämpi kokonaisuus Olioita helpompi debugata
Pelimaailman lataaminen Perinteinen tapa: kentät (levels), joista yksi näkyvissä kerrallaan, välissä lataustauko toteutettavissa kivasti pinolla Ilmalukot: minikenttä, jonka aikana seuraava ladataan (Halo) erillinen säie, joka lataa seuraavaa kenttää Virtautus: jaetaan jatkuva maailma pieniin paloihin, joita lataillaan tarvittaessa muistin pirstoutuminen SSD-levyt vähentävät kenttien tarvetta?
Dynaamisten objektien muisti Objekteja syntyy ja kuolee pelin kuluessa Pirstoutuminen on todellinen ongelma new ja delete ovat hitaita Ratkaisuja: Kaikki objektit olemassa alusta asti Kasa muistia (pool) kullekin objektityypille Joukko kiinteitä kokoja, valitaan pienin sopiva Uudelleenjärjestely (defrag)
Objektien päivittäminen Mitä pääsilmukan funktio update(dt) tekee? Naiivi versio päivittää vuorotellen jokaisen objektin jokaisen komponentin: # pääsilmukan kutsuma update: def update(dt): foreach (obj in gameobjects): obj.update(dt) # gameobjectissa... def update(dt): move(dt) animation.update(dt) physics.update(dt) renderer.draw()
Päivittäminen On tehokkaampaa päivittää kukin matalan tason komponentti kerralla kaikki animaatiot putkeen, sitten vasta piirto, jne tehokkuushyötyjen syynä esim. välimuisti, välitulokset, resurssien varaus, liukuhihnat Fysiikka vaatii usein, että kaikki esineet ovat lopullisilla paikoillaan ennen törmäystarkistusta Riippuvuudet: esim. hahmo pitelee kissaa päivitysjärjestyksellä voi olla väliä
Päivittäminen Objekteja päivitetään yksi kerrallaan ajasta t 1 aikaan t 2 = t 1 + dt tästä seuraa, että päivityksen aikana osa objekteista on ajassa t 1 ja osa ajassa t 2 jos objektit käyttävät toistensa tiloja, täytyy olla tarkkana, kumpi ajanhetki on kyseessä riippuvuuspuut ovat yksi ratkaisu erilliset muuttujat vanhalle ja uudelle tilalle lisäetu: voidaan interpoloida välitiloja