Aattelinpa linkata projektinalun tännekin jos löytyis jotain teknisempää kommenttia: (tuolla englanniks selitetty enkä jaksais kokonaan kääntää, jos kommentoitta tänne kuitenkin)
http://www.pascalgamedevelopment.com/viewtopic.
Eli verkko-strategiapeli jossa olis mahdollista käyttää jopa kymmeniä tuhansia yksiköitä. TCP/IP tekniikkaa, ja kaikki fysiikat jne tapahtuis client päässä. TCP koska ehdottomasti yksikään paketti ei saa hukkua. Lagin puolesta rts on vielä vapaampi kuin yleisimmät mmorpg pelit. Serveri ei koskaan muulloin kun peliin liityttäessä lähetä liikkumistietoja jne, vain kontrollikäskyt eli missä hiiri ja pelaajan kamera sillä hetkellä kulkee.
Onko tuo teoriassa edes mahdollista ja miksi ei? En vaan ole törmännyt vielä tämäntyyliseen tekniikkaan. Laskeehan kaikki prosessorit liukuluvuilla samalla tavalla? (ja vaikkei laskis niin kokonaislukujakin voi käyttää)
Itse olen suunnitellut käyttäväni hieman vastaavaa ideaa:
Lagi voi kyllä kasvaa hyvinkin suureksi, mutta ainakaan lähiverkossa tämän ei pitäisi olla ongelma.
Liukulukulaskuissa valitettavasti on eroja. Toiset noudattavat erilaisia pyöristysstandardeja, x87 laskee sisäisesti 80-bittisillä rekistereillä, SSE:t ja muut laskevat omalla tavallaan... Tähän ei siis kannata luottaa. Jos tarkkuudesta voi hieman tinkiä, kokonaisluvut saattavat olla nopein ratkaisu, koska niillä pyöristysvirheet on standardoitu. (Kukapa oikeastikaan osaisi juosta täsmälleen samalla nopeudella aina... Tuskin se peliä oikeasti haittaa.)
RTS peleissä on otettava huomioon se, että "näytön ulkopuolella" tapahtuvat liikkumiskäskyt, kuolemat yms. täytyy myös välittää, jotta pystytään pitämään kartan tapahtumat ajantasalla. Vai miten ajattelit hallita kymmenien tuhansien yksiköiden armeijaa ilman karttaa, josta näkisit niiden liikkeet edes suurpiirteisesti.
Gaxx kirjoitti:
RTS peleissä on otettava huomioon se, että "näytön ulkopuolella" tapahtuvat liikkumiskäskyt, kuolemat yms. täytyy myös välittää, jotta pystytään pitämään kartan tapahtumat ajantasalla.
Tämän takia noi olisikin järkevää laskea serverillä eikä clienteillä, jolloin koko maailma täytyisi olla vain serverillä ja clientille täytyis välittää vain näytön ja mahdollisesti lähiympäristön tapahtumat.
Grez kirjoitti:
Gaxx kirjoitti:
RTS peleissä on otettava huomioon se, että "näytön ulkopuolella" tapahtuvat liikkumiskäskyt, kuolemat yms. täytyy myös välittää, jotta pystytään pitämään kartan tapahtumat ajantasalla.
Tämän takia noi olisikin järkevää laskea serverillä eikä clienteillä, jolloin koko maailma täytyisi olla vain serverillä ja clientille täytyis välittää vain näytön ja mahdollisesti lähiympäristön tapahtumat.
Niin millä se clientti sitten tietää sen kartan tilanteen, jos sitä ei sille ilmoteta vaan "lasketaan pelkästään siellä serverillä"?
Jos luit aloitusviestin linkin jutun niin 8*30000 = liian paljon nykyisille yhteyksille. Tulevaisuutta odotellessa :)
Siis jos niitä pelaajia ei ole kerran kuin 8 per peli, niin ei se sitten niin hirveetä ole. Mutta jos vaikka jonkun MMORPGin tekisi niin että jokainen pelaaja pyörittäisi koko pelimaailmaa koneellaan niin menisi aika vaikeaksi.
Tuo nyt oli yleistä pohdintaa eikä juuri sinun projektiisi liittyvä juttu.
Ja voihan "serveri" olla yksi pelaajistakin, jos ajatellaan että olisi hirveä määrä pieniä erillisiä pelejä käynnissä.
Grez kirjoitti:
Voihan serveri olla yksi pelaajistakin.
Niin, nyt on ratkaistu 1/8 clientin tiedontarveongelma. Entä ne muut 7?
Edit: Oli näemmä tullut lisää tekstiä
Grez kirjoitti:
Siis jos niitä pelaajia ei ole kerran kuin 8 per peli, niin ei se sitten niin hirveetä ole
Kyllä se vaan ihmeen paljon vaatii kaistaa taisteluiden aikana.
No välitä verkon yli ainoastaan kunkin pelaajan antamat komennot ja kukin peliengine laskee näistä muodostuvan tilanteen itsenäisesti. En kuitenkaan usko että kukaan pelaaja pystyy tekemään vaikka 30000 komentoa sekunnissa...
Siis tuo oli ilmeisesti alun perinkin ideasi ja 8 pelaajalla en näe pahemmin ongelmaa tuon toteuttamisessa.
Luvuista vielä: Pikainen testi kertoi, että yksinkertaistettuihin fixed point -laskuihin (+-*/) kuluu muuten saman verran aikaa kuin liukulukulaskuihin, mutta jakolaskuun menee viisinkertainen aika. Käytin fixed point -lukuna 32-bittistä kokonaislukua. Mutkikkaammat operaatiot kuten neliöjuuri ja trigonometriset funktiot ovat luonnollisesti paljon hitaampia, joten jotain muuta pitäisi näiden kanssa keksiä.
Kylläpä tämä keskustelu on suistunut raiteiltaan. :D Tarkoitus oli kai jutella alkuperäisestä ideasta eikä siitä, mitä kaikkea muuta voisi tehdä.
Grez kirjoitti:
No välitä verkon yli ainoastaan kunkin pelaajan antamat komennot ja kukin peliengine laskee näistä muodostuvan tilanteen itsenäisesti. En kuitenkaan usko että kukaan pelaaja pystyy tekemään vaikka 30000 komentoa sekunnissa...
Kyse ei ole siitä, etteikö pelaajan komentojen välittäminen onnistuisi, mutta kun niissä taisteluissa oletettavasti kuolee väkeä(näistä on hyvä ilmoittaa), niin sitten serverin täytyy hoidella vähän tekoälyjuttuja(esim. seuraava kohde ja liike sinne) ja kertoa se tarvittaville. Jälkimmäistä voi tietenkin optimoida: päivittää tilanne, jos sijainti muuttuu merkitsevästi(kartalla). Nämä tulivat ensimmäisinä mieleen.
Edit: Laskut täytyy muistaa tehdä serverin lähtevän liikenteen mukaan. Huomautettakoon myös, että 8-pelaajan pelien tapauksessa serveripäässä harvemmin on mitään paksua letkua.
Periaatteessahan jos et käytä arvontaa (satunnaislukuja) ja tosiaan jos koneet ei laske eri tavalla, niin tilanteen pitäisi mennä eri pelaajille vaikka kuinka pitkälle samana.
Tuosta kun kirjoitit, että käyttäisit TCP:tä, kun virheitä ei saa tulla. Ongelmahan TCP:ssä on, että ohjelma ei voi vaikuttaa siihen, kuinka pian uusi paketti lähetetään jos ei vaikka kuittausta tule (paitsi tietty adminina). Eli sen takia monet reaaliaikaisuutta vaativat systeemit käyttävät esim. UDP:tä. Tokihan UDP:n päälle voi rakentaa myös virheentunnistuksen (tai vaikka korjauksen). Ei se TCP:kään 100% varma ole.
Grez kirjoitti:
Periaatteessahan jos et käytä arvontaa (satunnaislukuja) ja tosiaan jos koneet ei laske eri tavalla, niin tilanteen pitäisi mennä eri pelaajille vaikka kuinka pitkälle samana.
Jos ei käytä satunnaislukuja niin tämä antaa avaimet huijaamiseen. Clientti pystyy periaatteessa laskemaan etukäteen taistelun tuloksen.
Gaxx: Luulin että pelaajat valinnoillaan vaikuttaisivat lopputulokseen, eli ilman muiden käyttäjien tekemiä valintoja ei pystyisi laskemaan tilannetta eteenpäin.
Mutta ilmeisesti sinun versiossa onkin kyseessä peli, jossa käyttäjät ei enää voi vaikuttaa pelin kulkuun, kun alkutilanne on määritelty?
Toki jos satunnaislukuja on pakko käyttää, niin ei sekään ole ongelma, kunhan ne vaan välitetään muille koneille. Ajattelin vaan että tuosta voi tulla ongelma kun kone voi periaatteessa arpoa vaikka miljoona satunnaislukua sekunnissa. Mutta tokihan ongelman voi poistaa rajoittamalla niiden käyttöä.
Gaxx kirjoitti:
Jos ei käytä satunnaislukuja niin tämä antaa avaimet huijaamiseen. Clientti pystyy periaatteessa laskemaan etukäteen taistelun tuloksen.
Ainahan siinä taistelussa vaikuttavat myös ihmisten päätökset. Lisäksi kun satunnaisluvut kuitenkin näissä tapauksissa ovat pseudosatunnaislukuja, voidaan siemenluku laskea vaikka kulloistakin framea edeltäneestä palvelimen lähettämästä paketista, jolloin se ei ole ennalta clientin tiedossa mutta pysyy silti kaikilla pelaajilla samana.
Yhtenäisen laskennan kehittäminen ei ole logiikan puolesta mikään ongelma. Suurimmat kysymykset tässä ovat luultavasti juuri teknisiä kuten tuo liukulukulaskujen yhtenevyys.
Grez: Saanen huomauttaa, että alkuperäinen kysyjä oli User137 eikä Gaxx. :)
Metabolix: Joo, kieltämättä olen kirjoitellut kuten Gaxx olisi tekemässä sitä peliä. Vastaukseni on kuitenkin tarkoitettu ihan yleisesti kommenteiksi tämän tyylisiin peleihin ja asioihin joita Gaxx on kommentoinut, ei välttämättä juuri aloittajan peliin.
Tosin ihan totta sekin, että en niin tarkkaan ole katsonut kuka se aloittaja oli ja kenen viesteihin olen kommentoimassa, joten ihan hyvä huomautus.
Metabolix kirjoitti:
Ainahan siinä taistelussa vaikuttavat myös ihmisten päätökset. Lisäksi kun satunnaisluvut kuitenkin näissä tapauksissa ovat pseudosatunnaislukuja, voidaan siemenluku laskea vaikka kulloistakin framea edeltäneestä palvelimen lähettämästä paketista, jolloin se ei ole ennalta clientin tiedossa mutta pysyy silti kaikilla pelaajilla samana.
Kyllä, taistelun kulkua voidaan muutta sen kuluessa(myönnän, että esimerkkini oli hieman kärjistetty, mutta huijaamisen estäminen on mielestäni yksi tärkeimmistä seikoista verkkopeliä suunnitellessa).
Tuo siemenlukujen lähettely koko ajan on kyllä mainio idea ainakin näin yhtäkkiä ajateltuna. En oli kovin rts-pelien verkkotekniikkaa suunnitellut(lähinnä mmorpg:en, joissa moisesta ei olisi hyötyä).
Mietityttää vain, että onkohan tällaisia massiivisia pelejä jo tehty? Kaikki tähänastiset pelaamani rts-pelit ovat ruvenneet tökkimään isommissa taisteluissa viimeistään 200 yksikön kohdalla(jopa lähiverkossa 100/100Mt), joten siinäkin mielessä tuollaisen toimivuus käytännössä epäilyttää.
Edit: Eihän se verkkopelien suunnittelu olisi vaikeaa, jos ei olisi sitä tiedonsiirrossa tapahtuvaa viivettä. Sehän sen ongelman tuottaa.
Gaxx kirjoitti:
Mietityttää vain, että onkohan tällaisia massiivisia pelejä jo tehty? Kaikki tähänastiset pelaamani rts-pelit ovat ruvenneet tökkimään isommissa taisteluissa viimeistään 200 yksikön kohdalla(jopa lähiverkossa 100/100Mt), joten siinäkin mielessä tuollaisen toimivuus käytännössä epäilyttää.
Mitenkäs Supreme Commander hoitaa verkkopelinsä?
Metabolix kirjoitti:
Kylläpä tämä keskustelu on suistunut raiteiltaan.
Jatkan samalla linjalla: Pystyykö pelinkehittäjä laskemaan, että kuinka monta pelaajaa voi kerrallaan olla pelaamassa, jos he ovat eri puolilla maapalloa? Vai miten nää nettipelit mitoitetaan?
T. Vanha nettikoodari
Vastauksia tullu sitten hitusen... Serveri olis tosiaan 1:llä pelaajista toisena prosessina tai sitten "dedicated" tyyppisenä auki ilman pelaajaa. Tuo toisena prosessina systeemi on ihan sama kun käynnistäis dedicated ja liittyis clienttina itsekin. Joka client pyörittää koko pelimaailmaa, ei ole pimeitä alueita. Fog of war voi tehdä mutta joku voi sitä huijata, toisaalta sillä ei olis niin väliä, ja useimmat toteutuksetkin siihen olis ehkä hitaita.
Mutta siihen kahtoen yksikkörajoitukset että edes keskiverto PC sitä pyörittäis serverinä ja clienttina. Mallit alle 100 polygonia (poikkeuksena suuremmat rakennelmat) ja keskivertopelissä yksiköt hajautuis ympäri karttaa josta optimoida piirtoaluetta vähän.
Kokonaisluvuilla kai se sitten pitää mennä, lukitaan yksiköt pieniin ruutuihin mutta liike saa edelleen olla sulavaa.
Jackal von ÖRF kirjoitti:
Mitenkäs Supreme Commander hoitaa verkkopelinsä?
En ole tutustunut peliin, mutta erinäisten kuvakaappausten ja videoiden perusteella yksiköiden määrä ei ole kovin kummonen.
Vielä tuohon siemenlukujen lähettelyyn: Eikös seuraavan siemenluvun pysty päättelemään edellisten perusteella? Ainakin jos tietää, miten seuraava generoidaan. Ja tavanhan pystyy ainakin teoriatasolla päättelemään edellisistä. Pystyykö tätä kiertämään millään? Monimutkaistamaan ainakin pystyy.
Edit:
Metabolix kirjoitti:
Kylläpä tämä keskustelu on suistunut raiteiltaan. :D Tarkoitus oli kai jutella alkuperäisestä ideasta eikä siitä, mitä kaikkea muuta voisi tehdä.
User137 kirjoitti:
Onko tuo teoriassa edes mahdollista ja miksi ei?
Vai mitä tuo sitten tarkoitti?
Gaxx kirjoitti:
Vielä tuohon siemenlukujen lähettelyyn: Eikös seuraavan siemenluvun pysty päättelemään edellisten perusteella?
Pointtina nimenomaan olisi, että ei pysty. Eihän sitä muuten tarvitsisi lähettääkään. :) Näppäriä satunnaistekijöitä ovat esimerkiksi palvelimelta tulevan paketin tarkistussumma, joka tietenkin riippuu paketin sisällöstä, tai jokin palvelimeen liittyvä tuntematon tekijä kuten siellä päässä kulunut prosessoriaika (C:ssä clock-funktion arvo) tai erillisen satunnaislukugeneraattorin antama seuraava luku. Satunnaisuuden aste saadaan vaivatta aivan yhtä suureksi kuin normaalissakin pelissä, joten huijaaminen tämän avulla ei ole ainakaan normaalia helpompaa.
Metabolix: Jep, näemmä noita vaihtoehtoja löytyy :)
Itse peli-ideaan: Mahtaakohan siitä olla mitään iloa, jos pystyy tekemään 30000 yksikköä verrattuna vaikkapa 500:aan? Ei niitä 30000 yksikköä kuitenkaan pysty hallitsemaan yksittäisesti. Olisihan se tietysti hieno mainoskikka.
Hmm, tein pienen tehotestin joka näyttäs että yksikkömäärät olis parempi pitää tuhansissa. Ei ole tarkotus laittaa kuitenkaan suorittimelle täysiä kierroksia niinkun näytti tapahtuvan, vaikka käytin vaan 2d spriteja. Kyllä se piirti 40000 spritea yhteen ruudulliseen 60% cpu käytöllä ollen erittäin sulava vielä mutta on silti liikaa.
Ei se mikään mainoskikka ole myöskään. Mutta sen ei tarvitse olla millään tavalla hidastava tekijä niinkun se nykyään on. Tietokone ei kyykyty ihan heti siitä kun yksikkömäärää nostaa mutta verkkoliikenne ei pysy mukana. Siks olis tärkeetä kokeilla sitä pelkkää kontrollien lähettämistä. Siinäkään ei toki joka klikkausta ja hiiren liikettä tarvitse lähettää. Ja pelaaja itsekäänhän ei näe omaa valintarajaustaan käytännössä ennen kuin serveri lähettää sen takaisin. Jonkun harmaan hahmotelman voi asettaa kyllä, mutta on selvää että siinä "tickien" välillä ne yksiköt on voinu liikkua vaikka pari senttiä vasemmalle. Siks yksiköiden valintaan voi tehdä toisenlaisen ratkasun lisäks.
Jos huijauksia ajattelitte niin kuinka sellasta voi mitenkään huijata jossa on oletuksena koko pelialue näkyvissä? Käyttäähän moni nykypelikin sellasta systeemiä, mukaanluettuna Total annihilation, C&C Redalert, Empire earth, Civilization jne...
Gaxx kirjoitti:
Jackal von ÖRF kirjoitti:
Mitenkäs Supreme Commander hoitaa verkkopelinsä?
En ole tutustunut peliin, mutta erinäisten kuvakaappausten ja videoiden perusteella yksiköiden määrä ei ole kovin kummonen.
SupComissa yksikköjen määrät ovat useiden satojen, jopa muutaman tuhannen luokkaa, jos vain suorittimessa riittää vääntöä AI:n ja fysiikan pyörittämiseen. Moninpeliä en ole kokeillut, joten sen yksikkömääristä en tiedä, mutta kuulemma moninpelissä peli pyörii *hitaimman CPU:n* vauhdilla, mikä vihjaisi siihen, että pelin simulaatiota pyöritetään synkronoidusti kaikkien pelaajien koneilla. Jos joku tietäisi artikkeleita, missä kerrotaan mitä arkkitehtuuria SupCom käyttää, niin voisi selvitä, että käytetäänkö siinä tämän ketjun ensimmäisessä viestissä mainittua tekniikkaa vai jotain muuta.
User137 kirjoitti:
Ja pelaaja itsekäänhän ei näe omaa valintarajaustaan käytännössä ennen kuin serveri lähettää sen takaisin. Jonkun harmaan hahmotelman voi asettaa kyllä, mutta on selvää että siinä "tickien" välillä ne yksiköt on voinu liikkua vaikka pari senttiä vasemmalle. Siks yksiköiden valintaan voi tehdä toisenlaisen ratkasun lisäks.
Käyttöliittymätason operaatioita (hiiren liikkeet, klikkaukset) ei kannata lähettää palvelimelle asti - latenssi kasvaa liikaa. Tuossa tilanteessa yksiköiden valitseminen ja kohteen klikkaaminen hoidetaan clientilla, ja serverille lähetetään valittujen yksiköiden ID:t ja niille annettu komento pelin koordinaatistossa. Serveri sitten päättää, miten yksiköt reagoivat komentoon, ja lähettää clienteille tiedon yksiköiden liikkeistä.
Jackal von ÖRF kirjoitti:
Serveri sitten päättää, miten yksiköt reagoivat komentoon, ja lähettää clienteille tiedon yksiköiden liikkeistä.
Tarkennus: Päätökseksi riittää tieto, millä ajanhetkellä ja mihin kohti yksiköt on komennettu sekä mahdollinen komennustyyppi ("hyökkää", "seuraa", "patrol"). Reitit voi laskea clientillä, kunhan algoritmi on deterministinen.
Tällaisen arkkitehtuurin kanssa joutuu sitten miettimään monisäikeisyyttä vielä entistä tarkemmin, jos haluaa ottaa siitä ilon irti. Omiin säikeisiinsä istuvat ehkä helpoiten grafiikan, äänten ja mahdollisten clientilla pyörivien AI-pelaajien käsittely.
Tuota valintaa vähän miettiny kyllä. Ei sitä periaatteessa tarvitsis niin optimoida kun suurin verkon säästö tulee siitä kun pelin tapahtumia ei lähetetä. Joten kai se, kuten Jackal mainitsi, parasta on lähettää valittujen yksiköiden ID:t. Pitää vaan miettiä sitten mikä on suurin määrä yksiköitä jotka pelaaja voi valita kerrallaan *rajaamalla*, joku 300. Vois niitä shift pohjassa sitten lisätä nykyiseen valintaankin. (Eri asia on ns. pikanappi jolla valitaan koko ruudullinen tai kaikki pelaajan olemassaolevat tietyt yksiköt jossa ID:itä ei tarvitse lähettää) Oletan että saan tekoälyn vähän hajauttamaan niitä joukkoja vaikkei törmäystunnistusta kai tarvita.
Jos oletetaan, että on valittuna 1000 yksikköä ja yksikön ID on 16-bittinen kokonaisluku, niin tuon joukon luettelemiseen tarvitaan 2000 tavua. Kunhan pelaajia ei ole kovin monta, niin kahden kilotavun lähettäminen niille kaikille ei pitäisi olla mahdotonta. Ei noin isoja komentoja kuitenkaan joka sekunti tule.
Gaxx kirjoitti:
Grez kirjoitti:
No välitä verkon yli ainoastaan kunkin pelaajan antamat komennot ja kukin peliengine laskee näistä muodostuvan tilanteen itsenäisesti. En kuitenkaan usko että kukaan pelaaja pystyy tekemään vaikka 30000 komentoa sekunnissa...
Kyse ei ole siitä, etteikö pelaajan komentojen välittäminen onnistuisi, mutta kun niissä taisteluissa oletettavasti kuolee väkeä(näistä on hyvä ilmoittaa), niin sitten serverin täytyy hoidella vähän tekoälyjuttuja(esim. seuraava kohde ja liike sinne) ja kertoa se tarvittaville. Jälkimmäistä voi tietenkin optimoida: päivittää tilanne, jos sijainti muuttuu merkitsevästi(kartalla). Nämä tulivat ensimmäisinä mieleen.
Edit: Laskut täytyy muistaa tehdä serverin lähtevän liikenteen mukaan. Huomautettakoon myös, että 8-pelaajan pelien tapauksessa serveripäässä harvemmin on mitään paksua letkua.
Tuskin kukaan pelaaja pystyy edes pitämään 10000 yksikköä toiminnassa samaan aikaan.
Jos pelaajalla siirtää joukkojaan jonkin suunnitelman mukaan, vaikka sadan yksikön ryhmissä, liikkeelle saadaan ehkä 200-1000 yksikköä kymmenessä sekunnissa. Toiminnon voisi ajatella kestävän korkeintaan minuutin, jonka jälkeen pitää antaa uusia komentoja ja jos vastustaja ei törmää yksiköihin, nämä eivät ennen uusia komentoja tekisi yhtään mitään.
Pelaajilta tulisi siis korkeintaan noin 8 * 6000 komentoa minuutissa.
ville-v kirjoitti:
Jos pelaajalla siirtää joukkojaan jonkin suunnitelman mukaan, vaikka sadan yksikön ryhmissä, liikkeelle saadaan ehkä 200-1000 yksikköä kymmenessä sekunnissa. Toiminnon voisi ajatella kestävän korkeintaan minuutin, jonka jälkeen pitää antaa uusia komentoja ja jos vastustaja ei törmää yksiköihin, nämä eivät ennen uusia komentoja tekisi yhtään mitään.
Pelaajilta tulisi siis korkeintaan noin 8 * 6000 komentoa minuutissa.
Gaxx kirjoitti:
Kyse ei ole siitä, etteikö pelaajan komentojen välittäminen onnistuisi, mutta — —
Kuten edellä mainittiin, muun viestiliikenteen voi välittää siemenlukuna, jonka avulla clientti pystyy laskemaan yksiköiden liikkeet yms. Jos mukaan otetaan "fog of war", homma ei toimi enään tai muuten clientille kerrotaan näkymättömissä olevien yksiköiden sijainnit yms.
Käsittääkseni melkein kaikki RTS-pelit käyttävät tätä "lockstep" -synkronointistrategiaa. Esimerkiksi C&C3:ssa tämä näkyy selvästi, koska siinä saa uusimmalla patchilläkin silloin tällöin aikaiseksi "out of sync" -virheen (mikä on EA:n tasoiselta firmalta aika säälittävää).
Tässä PDF siitä, miten homma hoidettiin Age of Empiresissä:
"1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond"
http://zoo.cs.yale.edu/classes/cs538/readings/
PDF:ssä kerrotaan miten hyvin perusidea toimi, mitä ongelmia siinä oli ja millä tavalla niitä voitiin ratkoa. Myös mm. satunnaisluvuista puhutaan.
Lockstep-pelin kannattaa erityisesti kehitysvaiheessa ottaa silloin tällöin sisäisestä tilastaan tarkistussumma ja katsoa, että se on tosiaan kaikilla clienteillä sama.
Kun pelin tila määräytyy pelkästään komentojen perusteella, saadaan peliin tehtyä "replay"-ominaisuus puoli-ilmaiseksi yksinkertaisesti tallentamalla kaikki lähetettävät komennot. Replayt ovat myös kätevä debuggaus- ja testaustyökalu, sillä bugin voi niillä toistaa helposti.
Gaxx kirjoitti:
Gaxx kirjoitti:
Kyse ei ole siitä, etteikö pelaajan komentojen välittäminen onnistuisi, mutta — —
Kuten edellä mainittiin, muun viestiliikenteen voi välittää siemenlukuna, jonka avulla clientti pystyy laskemaan yksiköiden liikkeet yms. Jos mukaan otetaan "fog of war", homma ei toimi enään tai muuten clientille kerrotaan näkymättömissä olevien yksiköiden sijainnit yms.
Se, että client-ohjelmaa hakkeroimalla voi saada itselleen tällaista tietoa on aika toissijainen ongelma verrattuna siihen, että peli pyörii sujuvasti.
Tuo nyt nähtävästi lockstepiksi nimitettävä jo aiemmin tässä keskustelussa esitetty malli on tosiaan toimiva ja helppo toteuttaa. Sitä toteuttaessa pitää kuitenkin olla tarkkana deterministisyyden kanssa esimerkiksi liukulukulaskujen ja iterointijärjestyksien yhteydessä.
Olen itsekin kehittänyt eräänä harjoitustyönä RTS-peliprojektia, jossa käytimme juuri tätä strategiaa ja se toimi käytännössä oikein hyvin. Ensin kokeilemassamme "clientit lähettävät komennot, serveri laskee ja lähettää eventtejä" -lähestymistavassa taas jouduimme nopeasti ongelmiin.
Aihe on jo aika vanha, joten et voi enää vastata siihen.