Verkkopeli Newton
Newtonin ominaisuudet Reaaliaikaisuus Fysiikan simulointi Verkkopeli Tikku-ukko grafiikka Ikkunan koosta riippumaton (eri resoluutiot) Skrollaava, sisältää näkymän peliin Ei ääniä
Fysiikkamoottori Simulaattori joka simuloi pelin objektien elämää ja tekemisiä Toteuttaa tavallisesti jonkinlaista fysiikan mallinnusta, mutta usein realistisuus ei ole tavoite Etenee iteroiden Iteraatiotaajuus määrää simulaation tarkkuuden Suuremmalla taajuudella parempi simulaatio, mutta tarvitaan enemmän tehoa Fysiikkamoottori sisältää pelin tilan
Grafiikkamoottori Osaa visualisoida näkymän pelin tilaan FPS, eli frames per second on grafiikkamoottorin taajuus Taajuus ei ole vakio, vaan riippuu piirrettävän näkymän monimutkaisuudesta Mitä isompi taajuus, sitä sulavammin peli etenee
Äänet Nykyään ääniefektit näytteitä (sample), jotka laukeavat fysiikkamoottorin simulaation edetessä 3D-äänten aikakaudella näytteen sijainti ja tapahtumapaikan ympäristö vaikuttavat näytteeseen Äänimoottori miksaa kuuluvat äänet yhteen ja soittaa ne taustalla Osoittautui, että tämä pitää paikkansa (toistaiseksi?) vain PC-peleillä
Peliobjektit Pelin maailma koostuu joukosta keskenään vuorovaikuttavia peliobjekteja Aktiiviset peliobjektit ovat olioita jotka tekevät itse jotain (pelaaja itse, hirviöt, botit) Mitä enemmän aktiivisia objekteja, sitä isompi fysiikkamoottorin kuorma Passiiviset peliobjektit eivät itse tee mitään, ne vain vaikuttavat aktiivisten toimintaan tai reagoivat aktiivisen objektin toiminnan seurauksena (seinät, maasto, jne) Kaikki näkyvät peliobjektit generoivat kuormaa grafiikkamoottorille
Peliobjektien luokkahierarkia Peliobjektin tyyppi kuvautuu luonnollisesti suoraan olioluokaksi Eri peliobjekteilla on tavallisesti paljon yhteisiä ominaisuuksia. Peliobjektien luokista muodostuu luonnostaan luokkahierarkia Luokkahierarkian ylimmällä tasolla abstrakteja yleisiä ominaisuuksia Alimmalla tasolla objektin ikiomat ominaisuudet
Pelin tila Kun fysiikkamoottorin globaali tilatieto ja jokaisen peliobjektin tila lasketaan yhteen on tuloksena käsite pelin tila annetulla iteraatiolla Normaalisti vaaditaan että pelin tila voidaan tallettaa tiedostoon (savegame) tai siirtää verkon yli (uusi pelaaja liittyy peliin) Tällaista pelin tilan tallennusta kutsuttaan sarjallistamiseksi (engl. Serializing). Sarjallistaminen täytyy ottaa huomioon jo luokkahierarkiaa toteutettaessa; jokaisen peliobjektiluokan pitää osata sarjallistaa oma tilansa jonoksi bittejä ja myös palauttaa talletettu objekti Jos hyvin käy, niin käytetty ympäristö tukee sarjallistamista (esim. Javan Serializable interface)
Lukiofysiikkaa.. Fysiikkasimulaattoriin vaadittavat käsitteet ovat lukiofysiikkaa.. Kappaleen ominaisuuksia ovat sijainti, nopeusvektori, orientaatio, koko ja muoto Jos todellakin halutaan oikea simulaattori, tarvitaan vielä massa, kitkakerroin, kulmanopeus, hitausmomentti ja ilmanvastus Kun nuo kappaleen ominaisuudet ovat tunnettuja, riittää lukiofysiikka fysiikkamoottorin iteraation toteuttamiseen (no, ainakin teoriassa)
Törmäystarkistukset Törmäystarkastuksen tekeminen mielivaltaisen muotoisille kappaleilla vaatisi oman esitelmänsä Kahden kappaleen välinen törmäystarkastus Helppo ratkaisu #1: Leikkaavat rajoittavat suorakaiteet Helppo ratkaisu #2: Leikkaavat rajoittavat ympyrät Oikeiden kappaleiden löytäminen Jaetaan taso pienempiin alueisiin ja tehdään törmäystarkastukset vain alueiden sisäpuolella Tai oikeaoppisesti toteutetaan jonkinlainen puurakenne
Mikroiteraatiot Iteratiivisessa fysiikkamoottorissa voi nopeasti liikkuva kappale tunneloitua Toisaalta grafiikkamoottori saattaisi ehtiä piirtää useampia freimejä kuin fysiikkamoottorin taajuus on; ei kannata piirtää täsmälleen samaa tilaa kahdesti Molemmat ongelmat ratkeavat, jos jaetaankin iteraatio pienempiin (mutta täyttä iteraatiota kevyempiin) mikroiteraatioihin, joiden taajuuden määrä nopeinten liikkuva objekti tai grafiikkamoottorin taajuus
Verkko Verkko tarjoaa koko joukon lisäongelmia Latenssi (tai pelislangilla lag) Reaaliaikaräiskinnässä isoimmalla latenssilla pelaava usein häviää Epäluotettavuus Peliprotokolla joutuu itse ratkomaan katoavien ja väärässä järjestyksessä tulevien pakettien ongelmat Katkot olisi hyvä jos peliä voisi jatkaa pidemmänkin verkkokatkon jälkeen. Tämä saattaa edellyttää jo pelin sääntöihin asti näkyvää suunnittelua Tietoturva! Julkisessa verkossa oleva pelipalvelin on altis hyökkäyksille, madoille ja hyväksikäytölle siinä missä mikä tahansa muu palvelinohjelmisto
Käytettävissä oleva kaista Nykyisissä verkkopeleissä voi jo pelkästään pelaajia olla tuhansia pelin omien peliobjektien lisäksi Koska verkossa käytettävissä oleva kaista on usein hyvinkin rajallinen (modemeilla n. 30kbit/s) joudutaan siirrettävän datan määrää optimoimaan (ja usein peräti nysväämään bittiä) Fysiikkamoottorin taajuus vaikuttaa suoraan tarvittavan kaistan määrän: mitä isompi taajuus, sitä enemmän tapahtumia sekunnissa
Vaihtoehtoja tilanvälitykseen Palvelin välittää joka iteraatiolla täydellisen tilatiedon Tarvitaan paljon kaistaa O(pelin tilatiedon koko * iteraatiotaajuus). Newtonilla n. 800kbit/s Erittäin helppo toteuttaa ja ratkaisee antaa suoraan ratkaisun hävinneiden pakettien ongelmaan Palvelin lähettää joka iteraatiolla muuttuneiden objektien tilan Muutoksia potentiaalisesti paljon. Newtonilla n. 80kbit/s
Lisää vaihtoehtoja Lähetetään tieto näkyvistä objekteista Edelleen näkyviä objekteja voi olla paljon Erityisesti 3D-tapauksessa objektin näkyvyyden selvittäminen voi vaatia paljon laskentatehoa Suojaisi huijaukselta Determinismi Koodataan fysiikkamoottori deterministisenä tilakoneena, jonka syötteenä ovat käyttäjien tekemät ohjausliikkeet. PRNG:n tila on osa pelin tilaa Sekä asiakas että palvelin pyörittävät täydellistä fysiikkamoottoria Verkon yli siirretään ainoastaan käyttäjien ohjausliikkeet. Peliobjektien määrällä ei vaikuta kaistavaatimukseen Newtonilla n. 1000bit/s
Protokolla deterministisellä fysiikkamoottorilla Kaksivaiheinen protokolla: synkronointivaihe ja päivitysvaihe Synkronointivaiheessa siirretään täydellinen tila Päivitysvaiheessa palvelin lähettää pelaajien ohjaustiedot, joilla asiakas voi suorittaa oman iteraation Jokaisessa paketissa iteraationumero (ja Newtonissa myös tilan tarkastussumma) Pakettien kadotessa synkronoidutaan uudelleen
Latenssin kompensointi Asiakas voi laskea kiertoaikaviiveen (ping) asiakkaan ja palvelimen välillä Asiakas laskee moottorin tilaa eteenpäin kiertoaikaviive/2 verran Pelaajan näkemä tila on (toivottavasti) lähempänä palvelimen todellisuutta kuin latenssin vanhentama tunnettu tila Samalla tekniikalla voi myös kompensoida kadonneita paketteja/katkoja. Jos päivityspakettia ei kuulu ajastimen laukeamiseen mennessä, siirretään moottorin tilaa eteenpäin joka tapauksessa