Star Citizen

CIG kertomaa ja omaa ymmärrystä ja kokemusta.

Peli toimi erittäin hyvin siinävaiheessa kun ei ollut vielä Arcorpia pelissä eli ongelmat johtuvat niemomaan seurattavan assettimäärän kasvusta serveripuolella silloin kun pelaajat ovan hajaantuneet koko aurinkokuntaan.

Voit itsekkin seurata tiedonsiirtomäärään pelaajan ja palvelimen välillä se ei ole ongelma koska pelaajampuolen OCS hoitaa sen etttä se ei kasva suureksi.
Asia selvä. Uskon että sulla on tietoa CIGn systeemeistään enemmän kuin minulla. Toivotaan että asioita ei tarvitse koodailla uudestaan server meshin myötä.
 
Asia selvä. Uskon että sulla on tietoa CIGn systeemeistään enemmän kuin minulla. Toivotaan että asioita ei tarvitse koodailla uudestaan server meshin myötä.
Palajapuolen OCS:ssää tehdessää CIG pyrki olemaan kaukaa viisas ja tekemään sellaisen koodin että se olisi yhtensopivan myös tämän tulevan serverimuutoksen kanssa ts uskon että uudelleen koodaus tarve on pieni ainakin pelaajan puollala serveripuollla muuton on tietenkin merkittävä.
 
Palajapuolen OCS:ssää tehdessää CIG pyrki olemaan kaukaa viisas ja tekemään sellaisen koodin että se olisi yhtensopivan myös tämän tulevan serverimuutoksen kanssa ts uskon että uudelleen koodaus tarve on pieni ainakin pelaajan puollala serveripuollla muuton on tietenkin merkittävä.
Jees. No sehän kuulostaa sitten paljon paremmalta kuin mitä olin päässäni kuvitellut.

Onko mitään tietoa maksimi pelaajamääristä jotka voivat interaktata toistensa kanssa, esim taisteluissa? Ja miten näitä pelaajamääriä rajoitetaan jos samalla alueella on vaikka tuhansia pelaajia?
 
Jees. No sehän kuulostaa sitten paljon paremmalta kuin mitä olin päässäni kuvitellut.

Onko mitään tietoa maksimi pelaajamääristä jotka voivat interaktata toistensa kanssa, esim taisteluissa? Ja miten näitä pelaajamääriä rajoitetaan jos samalla alueella on vaikka tuhansia pelaajia?

Jos oikein olen ymmärtänyt pinta puolisella seurannalla niin peli sulloisi yhdelle serverille sen pelaaja-capin verran väkeä ja eristäisi sen omaksi alueekseen universumissa ja sitten pelaajien siirtyillessä avaruudessa pompottelisi serveri pelaajia serveriltä toisella server meshin kautta. Käytännön toimivuudesta ei liene kenelläkään juuri ideaa, mutta kuulostaa maallikon korvaan kovin pelottavalta latenssi ja sulavuus mielessä. Se että kuinka nämä serverien pelaajat näkevät naapuriserverin pelaajat lienee vielä hämärän peitossa. Kuulstaa ainakin kosvasti siltä että päänraapimista on vielä rankasti edessä.
 
Jos oikein olen ymmärtänyt pinta puolisella seurannalla niin peli sulloisi yhdelle serverille sen pelaaja-capin verran väkeä ja eristäisi sen omaksi alueekseen universumissa ja sitten pelaajien siirtyillessä avaruudessa pompottelisi serveri pelaajia serveriltä toisella server meshin kautta. Käytännön toimivuudesta ei liene kenelläkään juuri ideaa, mutta kuulostaa maallikon korvaan kovin pelottavalta latenssi ja sulavuus mielessä. Se että kuinka nämä serverien pelaajat näkevät naapuriserverin pelaajat lienee vielä hämärän peitossa. Kuulstaa ainakin kosvasti siltä että päänraapimista on vielä rankasti edessä.
Oon kuullut että jos pelaaja fast travelaa paikkaan jossa serveri on täys niin matka vain kestää niin kauan kunnes serverillä tilaa, eli käytännössä jonottaa serverille. Ja serverit on ikään kuin alueita, ei suinkaan niin että serverit liikkuisivat pelimaailmassa sen mukaan missä on paljon pelaajia? Mutta tuo ei nyt kuitenkaan vastannut varsinaisesti kysymykseen että jos jonkun tietyn planeetan kiertoradalla lentelee 1000 pelaajaa. Mitä silloin tapahtuu?
 
Aiheesta tuntuu olevan niin paljon mutua ja harrison-stetsonia liikkeellä, ettei aiheessa pysy näin harrastuspohjalta perässä. Olisi kyllä mielenkiintoista kuulla väliaika tietoa ihan videon muodossa kehittäjien visiota ja kehityksestä teknologiasta.
 
... mutta kuulostaa maallikon korvaan kovin pelottavalta latenssi ja sulavuus mielessä. ...
Ota huomioon että se serveriltä toiselle pompautus tapahtuisi käytännössä silloin kun olet QT lennossa tai hississä tms eristetyssä tilassa eli et käytännössä huomaa siirtymää.

Myöskään se ei ole sattuma että SC kaupunkien käytävissä on S mutkia ne eristää pelaajat näkemästä toisiaan eli ne voi toimai serveri hyppyinä.

... Mutta tuo ei nyt kuitenkaan vastannut varsinaisesti kysymykseen että jos jonkun tietyn planeetan kiertoradalla lentelee 1000 pelaajaa. Mitä silloin tapahtuu?
Tuohon ei ole vielä vastausta edes CIG:llä.

Pääasiassa ne pyrkii suunnitelemaan pelilogiikan niin että niin monta pelaajaa ei päätyisi saman planeetan ympärille yhtäaikaa (ts ei niin paljon tehtäviä yhden palneetan ympärillä ja yllättäen matkustuskustannukset kyseiselle planeetalle nousee tms pelimekaaniset keinot).


Muuten peliserveri pystyy ainakin väliaikaisesti tukemaan valtavaamäärää entiteetejä yhden planeetan ympärillä/ilmakehässä (oli aika kun Caterpillarin lastin jokaikinen SCU (n. 40000) oli oma entiteetinsä sen jälkeen kun Catrpillar oli räjäytetty (tai ajettu täydellävauhdilla planeetan pintaan ;-) ) peli oli slideshow mutta se ei kaatunut ja tämä oli ennen OCS:ssä joka vielä parantaa tilannetta).

Itse uskon että ne lopulta pystyisivät tukemaan 1000 alusta planeetanympärillä kunhan ne aluksen on suht pasiivisia (ts ei sodin ja aiheuta kauheaa määrää alusten palasia).

Ainiin 1000 pelaajaa on eriasia kuin 1000 alusta koska pelaajia voi olla enempi kuin aluksia.
 
Viimeksi muokattu:
Ota huomioon että se serveriltä toiselle pompautus tapahtuisi käytännössä silloin kun olet QT lennossa tai hississä tms eristetyssä tilassa eli et käytännössä huomaa siirtymää.
Nämähän ovat käytännössä lataus screenejä, tosin animoituja sellaisia. Vaikea kuvitella miten tämä "saumaton universumi" toimii jos se ei olekaan saumaton.

Pääasiassa ne pyrkii suunnitelemaan pelilogiikan niin että niin monta pelaajaa ei päätyisi saman planeetan ympärille yhtäaikaa (ts ei niin paljon tehtäviä yhden palneetan ympärillä ja yllättäen matkustuskustannukset kyseiselle planeetalle nousee tms pelimekaaniset keinot).
Kuulostaa todella kömpelöltä. Eikä mun mielestä millään tehtävien määrällä voi rajottaa sitä seikkaa jos vain pelaajat haluavat olla samassa paikassa samaan aikaan.

Muuten peliserveri pystyy ainakin väliaikaisesti tukemaan valtavaamäärää entiteetejä yhden planeetan ympärillä/ilmakehässä (oli aika kun Caterpillarin lastin jokaikinen SCU (n. 40000) oli oma entiteetinsä sen jälkeen kun Catrpillar oli räjäytetty (tai ajettu täydellävauhdilla planeetan pintaan ;-) ) peli oli slideshow mutta se ei kaatunut ja tämä oli ennen OCS:ssä joka vielä parantaa tilannetta).
40 000 entiteettiä ei nyt ole mikään amerikan temppu, ei edes moninpeliympäristössä.

Itse uskon että ne lopulta pystyisivät tukemaan 1000 alusta planeetanympärillä kunhan ne aluksen on suht pasiivisia (ts ei sodin ja aiheuta kauheaa määrää alusten palasia).
No toivottavasti pystyvät. 1000 suht passiivista alusmodelia samassa ympäristössä ei pitäs tänä päivänä olla mikään kovin vaikea juttu. Etenkin SC:n LODi systeemin kanssa. Ymmärtääkseni sen verta hyvin skaalautuva systeemi kuitenkin.
 
...

No toivottavasti pystyvät. 1000 suht passiivista alusmodelia samassa ympäristössä ei pitäs tänä päivänä olla mikään kovin vaikea juttu. Etenkin SC:n LODi systeemin kanssa. Ymmärtääkseni sen verta hyvin skaalautuva systeemi kuitenkin.
Juu kyllä tietenkin sillloin jos ne kaiki 1000 alusta ei ole ihmisten miehittämiä ja hävittäjä taisteluetäisyydellä toisistaan.

Silloin kun alukset on riittävän kaukana toisistaan niin että niiden taistelu tapahtuu containerien välillä aluksia pystyy olemaan enempi ts kaksi capital alusta capital alusten taisteluetäisyydellä eivät välttämättä ole ensinkään samassa containerissa ja siten niiden ei tarvi olla myöskään samalla serverillä.

CIG on jo käytämnnössä demonnut sen että se pystyy toteuttaman taistelun containerinen väillä.

Ongelma on nimenomaan tuo että jos se 1000 hävittäjää yrittää taistella keskenään hyvin pienellä alueella niin sitä ei pysty tehokaasti pilkomaan riittävän monelle palvelimelle kun palvelinten välillä vaadittavat yhteydet kasvaisivan expotentiaalisesti.


---------------------------------------------------------


135b33bf-7b4b-4cbc-9022-c0e6d144450b.jpg


Onko 890 Jump iso
joo on se iso

CloudImperiumGames_StarCitizen_Origin890Jump.jpg


Pituus on nykyään 199m alunperin sen piti olla alle 100m pitkä, ts sen piti olla pienemi Reclaimer mutta nyt se on selvästi isompi.
 
Viimeksi muokattu:
Juu kyllä tietenkin sillloin jos ne kaiki 1000 alusta ei ole ihmisten miehittämiä ja hävittäjä taisteluetäisyydellä toisistaan.

Silloin kun alukset on riittävän kaukana toisistaan niin että niiden taistelu tapahtuu containerien välillä aluksia pystyy olemaan enempi ts kaksi capital alusta capital alusten taisteluetäisyydellä eivät välttämättä ole ensinkään samassa containerissa ja siten niiden ei tarvi olla myöskään samalla serverillä.

CIG on jo käytämnnössä demonnut sen että se pystyy toteuttaman taistelun containerinen väillä.

Ongelma on nimenomaan tuo että jos se 1000 hävittäjää yrittää taistella keskenään hyvin pienellä alueella niin sitä ei pysty tehokaasti pilkomaan riittävän monelle palvelimelle kun palvelinten välillä vaadittavat yhteydet kasvaisivan expotentiaalisesti.
Odotan mielenkiinnolla miten meinaavat tekniikan toteuttaa. Muut pelit tekee asiat vähän eri tavalla. Mikä on Dual Universumin lähestymistapa tässä kohtaa? Joku saman kaltanen server mesh?
 
Odotan mielenkiinnolla miten meinaavat tekniikan toteuttaa. Muut pelit tekee asiat vähän eri tavalla. Mikä on Dual Universumin lähestymistapa tässä kohtaa? Joku saman kaltanen server mesh?
Dual Universusssa pelataan simulaation tarkuudella eikä siinä ilmeisesti voi tähdätä toista alusta FPS tyyliin ja ampua osumaa vaan siinä annetaan ilmeisesti ampumakomentoja jotka AI/NPC toteuttaa ts simulaation tarkuusvaatimus on selvästi pienempi.

EVE käyttää aika diledaatiota js Dual Universe käytäää tarkkuus diledaatiota.
 
Dual Universusssa pelataan simulaation tarkuudella eikä siinä ilmeisesti voi tähdätä toista alusta FPS tyyliin ja ampua osumaa vaan siinä annetaan ilmeisesti ampumakomentoja jotka AI/NPC toteuttaa ts simulaation tarkuusvaatimus on selvästi pienempi.

EVE käyttää aika diledaatiota js Dual Universe käytäää tarkkuus diledaatiota.
Juu mutta tarkotin ylipäätään pelaajamäärän ahtaamisesta pienempään tilaan ja saumatonta universumia. Kun omaan korvaan ei kuulosta siltä että SC kykenis toteuttamaan aitoa saumatonta universumia, asiat feikataan jotenkin ja saadaam kuitenkin mahdollisesti tyydyttävä immersio aikaseks. Ymmärtääkseni DU:ssa ovat tehneet asiat hiukan toisin?
 
Juu mutta tarkotin ylipäätään pelaajamäärän ahtaamisesta pienempään tilaan ja saumatonta universumia. Kun omaan korvaan ei kuulosta siltä että SC kykenis toteuttamaan aitoa saumatonta universumia, asiat feikataan jotenkin ja saadaam kuitenkin mahdollisesti tyydyttävä immersio aikaseks. Ymmärtääkseni DU:ssa ovat tehneet asiat hiukan toisin?
Ei ole olemassa yhtään ensimmäisen persoonan pienellä alueella rajatoman pelaajamäärän omaavaa MMO peliä jossa olisi samaan aikaan FPS tyylinen tähtäys eikä mitäään kikkailua (kuten aikadiletaatio tms) kaikissa se on jotenkin "feikattu" eikä CIG:ään ole missäävaiheessa väittänyt tekevänsä täysin "feikkaamatonta" versiota.

SC:ssä "feikkaus" tulee perustumana pilvipalveluun ja suureenmäärään virtuaalipalvelimia joiden on tarkoitus toimia saumattoamsti yhteen, nähtäväksi jää kuinkahyvin se onnistuu käytännössä.

Tosin AMD pukkaa uusia järeämpiä EPYC:ejä sitätahtia markkinoille (ja AWS on niiden ensimmäisiä käyttöönottajia ja SC pyörii AWS:n virtuaalipalvelimissa) että SC:n ei tarvitse ehkä loppujenlopuksi käytää niin köykäisiä palvelimia kuin mitä on alunperin ollut tarkoitus.

Meinaan uusimmalla 2S EPYC kokoonpanolla on 256 threadia käytettävissäään.
 
Viimeksi muokattu:
Ei ole olemassa yhtään ensimmäisen persoonan pienellä alueella rajatoman pelaajamäärän omaavaa MMO peliä jossa olisi samaan aikaan FPS tyylinen tähtäys eikä mitäään kikkailua (kuten aikadiletaatio tms) kaikissa se on jotenkin "feikattu" eikä CIG:ään ole missäävaiheessa väittänyt tekevänsä täysin "feikkaamatonta" versiota.
Siis tottakai pelaajamäärät tulee olemaan AINA rajoitteena siten että tarvitaan jotain feikkausta. Mutta tarkoitan sitä miten se feikkaus on toeutettu? Eli jos se on sen saumattoman liikkumisen kustannuksella niin se rikkoo immersion eikä se olekkaan enää oikeasti saumaton universumi.

Otetaan esimerkiksi vierekkäisiä servereitä joissa jokaisessa on serverin maksimi määrä pelaajia. Jos pelaajat alkavat liikkua siten että pyrkivät tilanteeseen missä serverin maksimikapasiteetti ylitetään. Kuinka tuossa tilanteessa toimitaan? Tuleeko tätä serverille jonottamista (saumattomuus kärsii) tai jopa päällekkäisten instanssien luomista (vain yksi universumi illuusio kärsii)? Vai onko CIG:llä jokin ässä hihassa? Tämä on se kysymys mitä mä haluan tietää.
 
...

Otetaan esimerkiksi vierekkäisiä servereitä joissa jokaisessa on serverin maksimi määrä pelaajia. Jos pelaajat alkavat liikkua siten että pyrkivät ...
Älä unohda että SC:ssä voi taistella containerien väillä ts pelaja voi ampua yhdeltä serveriltä toista pelaajaa joka on toisella serverillä ts ei tarvi liikua samalle serverille.

Oletan että pelaajat ei voi olla kumminkaan fyysisesti samasssa tilassa vaa vierekkäisiisä tiloissa koska kuvittelisin että servereitä ei voisi limittäää.

Containerien välillä liikumien ja taistelu on saumatonta sen CIG on jo käytännössä todistanut (ne oli käytössä aluksissa jonkinaikaa (niistä luovutiin koska niistä ei ollut hyötyä vielä siinä kehitysvaiheesssa koska ne server meshit puutuuu)).


-------------------------------------------


Sneak Peak
https://robertsspaceindustries.com/...ImperiumGames_StarCitizen_ProwlerInterior.mp4
 
Viimeksi muokattu:
Älä unohda että SC:ssä voi taistella containerien väillä ts pelaja voi ampua yhdeltä serveriltä toista pelaajaa joka on toisella serverillä ts ei tarvi liikua samalle serverille.

Oletan että pelaajat ei voi olla kumminkaan fyysisesti samasssa tilassa vaa vierekkäisiisä tiloissa koska kuvittelisin että servereitä ei voisi limittäää.

Containerien välillä liikumien ja taistelu on saumatonta sen CIG on jo käytännössä todistanut (ne oli käytössä aluksissa jonkinaikaa (niistä luovutiin koska niistä ei ollut hyötyä vielä siinä kehitysvaiheesssa koska ne server meshit puutuuu)).
Sä nyt luot esimerkkejä missä asiat toimivat, mä puhun tilanteesta missä pelaajat eivät käyttäydy juuri niinkuin CIG haluaa (jotta homma toimisi). Jos kahden containerin välillä on taistelu ja pelaajat jostain syystä haluavat lentää lähemmäksi toisiaan, mitä tapahtuu? Mitä jos pelaaja määrä tällä alueella kasvaa entisestään? Mitä tapahtuu?
 
Sä nyt luot esimerkkejä missä asiat toimivat, mä puhun tilanteesta missä pelaajat eivät käyttäydy juuri niinkuin CIG haluaa (jotta homma toimisi). Jos kahden containerin välillä on taistelu ja pelaajat jostain syystä haluavat lentää lähemmäksi toisiaan, mitä tapahtuu? Mitä jos pelaaja määrä tällä alueella kasvaa entisestään? Mitä tapahtuu?
Oikea kysysmys on kuinka pieniä containerit voi olla ennen kuin palvelintiheys kasvaa lian suureksi ja palvelinten välisten yhteyksien määrä kasvaa lian suureksi.

Tuohon kysymykseen ei ole vastausta ennen kuin sitä käytännössä kokeillaan (sitä ei ole tehty koskaan aikaisemmin).

Eli en puhunut tilanteestan jolloin kaikki toimii vaan puhiin siitä miten CIG aikoo ratkaista tämän ongelman (jos se ratkeisu toimii).

Se kannattaa huomoida että kun serverside OCS on käytössä ja uudet järeämmät virtuaalipalveliment on käytössä yhdne serverin pelaajamäärä saataa ylitttää 200 eli servereitä ei välttämättä tarvi kovin montaa (8 serveriä olisi jo 1600 pelaajaa) ja minimisssäänkin se tulee olemana n. 100 pelaajaa (8 serveriä 800 pelaajaaa).


Huom. ne 8 serveriä on virtuaalipalvelimia ja ne voi sijaita yhdellä fyysisellä serverillä AWS:ssä joten niiden väliset yhteyden voi olla todella nopeita (meidän Suomalaisten tapauksessa se on tällähetkellä Pariisissa sijaitseva AWS).
 
Viimeksi muokattu:
Oikea kysysmys on kuinka pieniä containerit voi olla ennen kuin palvelintiheys kasvaa lian suureksi ja palvelinten välisten yhteyksien määrä kasvaa lian suureksi.

Tuohon kysymykseen ei ole vastausta ennen kuin sitä käytännössä kokeillaan (sitä ei ole tehty koskaan aikaisemmin).

Eli en puhunut tilanteestan jolloin kaikki toimii vaan puhiin siitä miten CIG aikoo ratkaista tämän ongelman (jos se ratkeisu toimii).
No ei kai sitä ole koskaan aikaisemmin tehty jos CIG on vasta tuota tekniikkaa pioneeraamassa. :D

Se kannattaa huomoida että kun serverside OCS on käytössä ja uudet järeämmät virtuaalipalveliment on käytössä yhdne serverin pelaajamäärä saataa ylitttää 200 eli servereitä ei välttämättä tarvi kovin montaa (8 serveriä olisi jo 1600 pelaajaa) ja minimisssäänkin se tulee olemana n. 100 pelaajaa (8 serveriä 800 pelaajaaa).
Jo 1600 pelaajaa? JO? Eikös tämän pitänyt olla MMO? 1600 pelaajaa on aika pikkanen... :D

Huom. ne 8 serveriä on virtuaalipalvelimia ja ne voi sijaita yhdellä fyysisellä serverillä AWS:ssä joten niiden väliset yhteyden voi olla todella nopeita (meidän Suomalaisten tapauksessa se on tällähetkellä Pariisissa sijaitseva AWS).
Olen hyvin tietoinen serverinopeuksista ja virtuaalipalvelimista.

Olen silti hyvin skeptinen SC:n saumattomasta universumista MMO skaalassa.
Saumaton universumi, mahdollista, ei mikään ihmeellinen temppu.
Moninpeli 100-200 henkeä tuossa saumattomassa maailmassa, mahdollista, vaatii jo vähän lihaksia, mutta tehtävissä.
MMO skaalan saumaton universumi. CIG server mesh ei ainakaan tässä vaiheessa kuulosta omaan korvaan että onnistuu. En kuitenkaan väitä että mahdotonta.
 
...
Jo 1600 pelaajaa? JO? Eikös tämän pitänyt olla MMO? 1600 pelaajaa on aika pikkanen... :D
...
Virnistelijä jätti tahallaan pois asiayhteyden.

1600 pelaajana yhdessa pienessä avaruustaistelussa pienellä alueella.

...
CIG server mesh ei ainakaan tässä vaiheessa kuulosta omaan korvaan että onnistuu. En kuitenkaan väitä että mahdotonta.
Tuo Server Mesh on koko homman juju ja CR väitää kovasti kykenevänsä toteuttamaan sen ... toimivuus nähdään sitten joskus ehkä ensivuoden aikana.

Jos Server Mesh ei loppujenlopuksi toimi oletetulla tavalla menee koko pelin merkittäviltä oslitaan uusiksi, olen aina ollut tietoinen tästä riskistä peliin rahaa laitaessani.
 
Viimeksi muokattu:
Virnistelijä jätti tahallaan pois asiayhteyden.

1600 pelaajana yhdessa pienessä avaruustaistelussa pienellä alueella.
Virnistelijä ei jättänyt tahllaa asiayhteyttä pois. Virnistelijä ei ymmärtänyt asiayhteyttä. Virnistelijä ymmärtää nyt.


Tuo Server Mesh on koko homman juju ja CR väitää kovasti kykenevänsä toteuttamaan sen ... toimivuus nähdään sitten joskus ehkä ensivuoden aikana.

Jos Server Mesh ei loppujenlopuksi toimi oletetulla tavalla menee koko pelin merkittäviltä oslitaan uusiksi, olen aina ollut tietoinen tästä riskistä peliin rahaa laitaenssani.
Vaikka tuo 1600 pelaajaa pienellä alueella toteutuisi en vieläkään ymmärrä mitä tapahtuu jos nuo kaikki pelaajat/alukset päättävät lentää toisiaan kohti vieläkin pienemmälle alueelle tai jos 10 000 pelaajaa liittyy taisteluun? Tähän ei siis vielä ole olemassa mitään ratkaisua server meshin tai designin suhteen? Katsotaan mitä tapahtuu?
 
...
Vaikka tuo 1600 pelaajaa pienellä alueella toteutuisi en vieläkään ymmärrä mitä tapahtuu jos nuo kaikki pelaajat/alukset päättävät lentää toisiaan kohti vieläkin pienemmälle alueelle tai jos 10 000 pelaajaa liittyy taisteluun? Tähän ei siis vielä ole olemassa mitään ratkaisua server meshin tai designin suhteen? Katsotaan mitä tapahtuu?
Jos mitätahansa massaa/energiaa puristetaan tarpeeksi se ylittää kriitisenrajan ja syntyy musta-aukko.

Kukaan ei tiedä mitä ihmeellistä ja kummallista mutta yleensä katastrofaalista tapahtu tapahtumahorisontin takana.


Itse kuvittelisin että CIG järjestää esim. UEE armeijan väliintulon taisteluun ennen kuin pelaajia ehtii kertyä enempi kuin peli pystyy hallitsemaan ts pelaajat lähteen karkuun ettei UEE armeija lahtaa niitä tms ja tuo iso taistelu lakkaa siten eikä mustaa-aukkoa synny loppujenlopuksi.


Ts CIG ei kykene ihmeisiin pelaajamäärän osalta vaan aina jossainvaiheessa tulee raja vastaan (mailmankaikkeuden mallintamiseen kun nyt vaan tarvitaan koko mailmankaikeuden resursit).



Kannataa myös harkita sitä millainen operaatio julkaisupelissä (kymmeniä tai sata aurinkokuntaa) sen noin 1000:n pelaajan kerääntyminen yhteen taisteluun olisi se nimitäin vaati melkoisen järjestelyn ja paljon aikaa kun sellaisen pelaajajoukon pitää kertyä yhteen paikaan laajalta-alueelta (todennäköisesti useista aurinkokunnista) ts jo yksin matkaajat olisi tunteja eli se antaa CIG:lle aikaa reagoida tapahtumaan etukäteen (Star Citizen ei ole EVE SC:ssä on 90% AI/NPC ja pelaajat on vain 10% eli AI/NPC:t voi helposti hallita pelaajien käyttäytymistä noin suuressa mitttakaavassa).

Meinana kun pelaajamäärä on hajaantunut kumminkin todennäköisesti kolmeen AWS:ään (Usa, EU ja Asia/Australia) ja jos aurinkokuntia olisi se 100 ja kaikissa aurinkokunnissa on useita planeetoja, kuita, avaruusasemia, yms pelaaja populaatio on normaalisti hajallaan aika laajalla alueella (ja siten eri virtuaaliservereissä), itse kuvitelisin että yhden AWS:n hetkellinen aktiivipelaajamäärä ei olisi koskaan enempää kuin jotain 200000 korkeintaan ja tuo olisi jakaantunut niihin 100 aurinkokuntaan ja kun pelissä on jo nyt n. 50000 pelaaja orgamisaatita on erittäin epätodennäköistä että olisi koskaan 1000 pelaajan taistelua (pl Pitchfork).

Tiedän että tuo on todennäköisyyksillä pelaamista mutta CIG pystyy hallitsemaan niitä todennäköisyyksiä pelimekaanikoilla.
 
Viimeksi muokattu:
Kyse ei ole siitä että CIGn pitäisi kyetä homma toetuttamaan, vaan mikä on CIGn design ratkaisu tuollaisille tilanteille mihin teknologia ei enää taivu?
Tuohon vastasitkin. Onko tämä CIGn kommentti vai oma näkemyksesi?
 
Kyse ei ole siitä että CIGn pitäisi kyetä homma toetuttamaan, vaan mikä on CIGn design ratkaisu tuollaisille tilanteille mihin teknologia ei enää taivu?
Tuohon vastasitkin. Onko tämä CIGn kommentti vai oma näkemyksesi?
CIG on aina sanonut että 90%vs10% AI/NPC vs pelaajat suhde on tarkoitettu siihen että peliä hallitsee CIG ei pelaajat ts oma esimerkkini oli vain ajatus siitä miten CIG voi toteuttaa hallinnan tässä yksittäistapauksessa käyttän tuota 90 vs 10 voimaansa.

Tuo 90vs10 on koko pelin yksi kantavista lähtökohdista.

Eli kuten sanoin Star Citizen ei ole EVE pelaajat eivät hallitse Star Citizeniä (ts Burn Jita ei ole mahdollinen SC:ssä).

Jos mulla on kellokuudessa pari UEE F8 hävittäjää vaatimassa että keskeytän matkani taistelualueelle hyvin todennäköisesti noudatan sitä "suositusta".


-------------------------------------------------------



FOIP parhaimmillaan ;-)
 
Viimeksi muokattu:
CIG on aina sanonut että 90%vs10% AI/NPC vs pelaajat suhde on tarkoitettu siihen että peliä hallitsee CIG ei pelaajat ts oma esimerkkini oli vain ajatus siitä miten CIG voi toteuttaa hallinnan tässä yksittäistapauksessa käyttän tuota 90 vs 10 voimaansa.

Tuo 90vs10 on koko pelin yksi kantavista lähtökohdista.

Eli kuten sanoin Star Citizen ei ole EVE pelaajat eivät hallitse Star Citizeniä (ts Burn Jita ei ole mahdollinen SC:ssä).

Jos mulla on kellokuudessa pari UEE F8 hävittäjää vaatimassa että keskeytän matkani taistelualueelle hyvin todennäköisesti noudatan sitä "suositusta".
Eli siis pelaajamääriä valvotaan "voimakeinoin"? Hmm.. tuo voisi toimiakkin. Jos saapuvia pelaajia hätyytellään ajoissa niin kuin tuossa viimeisessä lauseessa annoit ymmärtää. Vähän ehkä voi tuntua mekaaniselta rajoitteelta kun tuohon pelaajat tottuu. "Aa, taistelu on jo täynnä, portsari sano ettei pääse enää, good luck bois".
 
Eli siis pelaajamääriä valvotaan "voimakeinoin"? Hmm.. tuo voisi toimiakkin. Jos saapuvia pelaajia hätyytellään ajoissa niin kuin tuossa viimeisessä lauseessa annoit ymmärtää. Vähän ehkä voi tuntua mekaaniselta rajoitteelta kun tuohon pelaajat tottuu. "Aa, taistelu on jo täynnä, portsari sano ettei pääse enää, good luck bois".
Itse en keksi parempaakaan keinoa koska rajaton pelaajamäärä hyvin pienellä alueella ei ole mahdollinen joten alueelle kertyvää pelaajamäärää on jotenkin hallittava.
 
Aina tietoinen? Siis tämän äärikunnianhimoisen server meshingin osalta, jolloin ei enää parhaimmillaan puhuttaisi käytännössä 50-100 pelaajasta kulloisellakin pelialueella. Vaiko pelkästään parin viime vuoden aikana, jolloin se huomattavasti kunnianhimoisempi taikasana server meshing nostettiin asialistalle Chris Robertsin toimesta firman markkinointivideoilla ja satunnaisissa haastatteluissa moninpelaajamäärän noustessa arvioissa ties mihin asti ulottuvaan x:ään. Redditissä ainakin server meshing ja server mesh hakusanoina yltävät pelkästään elokuun 2016 Gamescomiin saakka, johon ensimaininta kenties ajoittuu saksalaisessa PC Games -julkaisussa.

...
Sillä mistälähtien siitä on puhuttu nimellä "server meshing" ei ole merkitystä kun on aina ollut selvää että senkaltainen systeemi tarvitaan että pieniin virtuaalipalvelimiin perustuva peli voi toimia MMO:na.

Jatkuvasti on ollut se idea että näitä virtuaalipalvelimia ajetaan dynaamisesti alas ja ylös tarpeenmukaan tämä ei ole mahdollista jollakin jäykällä hierarkisella systeemillä vaan systeemin on pakko olla dynaaminen Mesh tyylinen ts mikään ei ole muutunut muu kuin se että nyt siitä puhutaan avoimesti Server Mesh nimellä.
 
Viimeksi muokattu:
Eli siis pelaajamääriä valvotaan "voimakeinoin"? Hmm.. tuo voisi toimiakkin. Jos saapuvia pelaajia hätyytellään ajoissa niin kuin tuossa viimeisessä lauseessa annoit ymmärtää. Vähän ehkä voi tuntua mekaaniselta rajoitteelta kun tuohon pelaajat tottuu. "Aa, taistelu on jo täynnä, portsari sano ettei pääse enää, good luck bois".

Noi on vaan IcePenin horinoita. Todellinen toteutus nähdään sitten myöhemmin (olettaen ettei tämä korttitalo kaadu ennen sitä).
 
Jaa.. eli siis minkään laista designia aiheesta ei ole julkisuuteen kerrottu?
Esimerkkini oli omasta päästänin mutta sen tyylistä CIG suunittelee että pelimailma hallitsee pelaajien käyttäytymustä ts esimerkini kaltainen toiminta olisi mahdollinen.
 
Esimerkkini oli omasta päästänin mutta sen tyylistä CIG suunittelee että pelimailma hallitsee pelaajien käyttäytymustä ts esimerkini kaltainen toiminta olisi mahdollinen.
Jees. Fiksuahan se on hallita tuota "pelin sisäisesti" ja pyrkii säilyttämään immersion jollain tavalla. Puhdas tekninen rajoite on SC:n kaltasessa pelissä huono ratkasu imo.
 
Virnistelijä ei jättänyt tahllaa asiayhteyttä pois. Virnistelijä ei ymmärtänyt asiayhteyttä. Virnistelijä ymmärtää nyt.



Vaikka tuo 1600 pelaajaa pienellä alueella toteutuisi en vieläkään ymmärrä mitä tapahtuu jos nuo kaikki pelaajat/alukset päättävät lentää toisiaan kohti vieläkin pienemmälle alueelle tai jos 10 000 pelaajaa liittyy taisteluun? Tähän ei siis vielä ole olemassa mitään ratkaisua server meshin tai designin suhteen? Katsotaan mitä tapahtuu?


No jos ajatellaan että, olet torilla jossa on 10000 ihmistä, niin kuinka monta sinä niistä oikeasti näet parikymmentä(joo tori on yhdellä tasolla mutta ajatus mailma toimii silti). Jos servermesh clusterille mahtuu 50-200 pelaajaa niin paljonko fyysistä tilaa pelaaja/alus vaatii. Ja jos olet 50-200 aluksen keskellä montako niistä näkee. Tosin lodit taitaa handlätä ton että voi 200 alusta renderöidä. Tietysti peli tukee kolmannen persoonan kameraa mutta tähän voidaan tehdä kikkailuja että sulle ei renderöidä kun se sinun clusterin alukset tai stten vaan käytetään piirto etäisyyttä. Eri asia on sitten kun liityt siihen 1600 aluksen taisteluun etenpää mutta ei kai silloinkaan ole mahdollista nädä 1600 alusta fps kamerasta koska peittävät toisensa.
 
No jos ajatellaan että, olet torilla jossa on 10000 ihmistä, niin kuinka monta sinä niistä oikeasti näet parikymmentä(joo tori on yhdellä tasolla mutta ajatus mailma toimii silti). Jos servermesh clusterille mahtuu 50-200 pelaajaa niin paljonko fyysistä tilaa pelaaja/alus vaatii. Ja jos olet 50-200 aluksen keskellä montako niistä näkee. Tosin lodit taitaa handlätä ton että voi 200 alusta renderöidä. Tietysti peli tukee kolmannen persoonan kameraa mutta tähän voidaan tehdä kikkailuja että sulle ei renderöidä kun se sinun clusterin alukset tai stten vaan käytetään piirto etäisyyttä. Eri asia on sitten kun liityt siihen 1600 aluksen taisteluun etenpää mutta ei kai silloinkaan ole mahdollista nädä 1600 alusta fps kamerasta koska peittävät toisensa.
Tämä on validi pointti. Tuollasta moninpelikuormaa voi hyvinkin vähentää tiputtamalla pois siirrettävän datan määrää. Moninpeleissä, ja etenkin MMO peleissä pitäs nimen omaan pyrkiä siirtämään mahdollisimman vähän dataa. Kaikki irrelevantti jätetään siirtämättä, tai siirretään pätkittäin (jos tällä datalla ei ole kiire). Monenlaisia optimointeja voidaan tehdä. Mä tavallaan tässä kysynkin että mitä CIG meinaa tehdä näissä tilanteissa. Ehkä vähän liian tekninen/yksityiskohtanen kysymys jos ei ole devaajia vastaamassa. Ehkä tätä infoa ei ole edes jaettu julki? Olen vain utelias miten CIG tälläset tilanteet hoitaa jotta voivat leuka pystyssä sanoa SC:tä saumattomaksi MMO:ksi.
 
Koitan huomenna antaa hyvän arvauksen pohjautuen gigin antamiin tietoihin ja omalla tiedolla cryenginestä ja servereitä. Mutta pitää tarkastaa pari faktaa kun ei kaikkea jaksa muistaa.
 
No jos ajatellaan että, olet torilla jossa on 10000 ihmistä, niin kuinka monta sinä niistä oikeasti näet parikymmentä(joo tori on yhdellä tasolla mutta ajatus mailma toimii silti). Jos servermesh clusterille mahtuu 50-200 pelaajaa niin paljonko fyysistä tilaa pelaaja/alus vaatii. Ja jos olet 50-200 aluksen keskellä montako niistä näkee. Tosin lodit taitaa handlätä ton että voi 200 alusta renderöidä. Tietysti peli tukee kolmannen persoonan kameraa mutta tähän voidaan tehdä kikkailuja että sulle ei renderöidä kun se sinun clusterin alukset tai stten vaan käytetään piirto etäisyyttä. Eri asia on sitten kun liityt siihen 1600 aluksen taisteluun etenpää mutta ei kai silloinkaan ole mahdollista nädä 1600 alusta fps kamerasta koska peittävät toisensa.
Sinä oletat että ongelma olisi pelaajanpäässä mutta se ei ole ongelma on palvelinpäässä jonka tarvii hallita jokaikinin alus riipumatta siitä ketkä pelaajista näkee ne.

Ts ei voi olla yhtä palvelinta joka handlaisi kerralla 1600 pelaaja alusta jos taas tuo 1600 alusta pilkotaan monelle palvelimille jossainvaiheessa ongelmaksi nousee se että tarvitaan niin monia yhteyksiä eri palvelimien välillä (joka yhteys tuo mukana oman viiivensä).

Ts jos oletetaan että yksi palvelin handlaisi vain nykyisen maksimin eli 100 alusta tarvittaisiin vähintään 16 palvelinta ja koska jokainen palvelin tarvii yhteyden vähintään naapureihinsa olisi yhteysmäärä ehkä liian suuri jo tuolla 16:sta palvelimella.

Itse pitäisin hyvänä jo sitä jos päästää siihen että 8 palvelinta pystyisi hoitamaan yhden yhtenäisen taistelun jossa on 500 pelaajien hallitsemaan alusta (yksittäisessäa aluksessa voi olla enempi kuin 1 pelaajaa), noiden 500 pelaaja-aluksen lisäksi voi ollla AI/NPC aluksia (ne hallitaan palvelimelta joten ne eivät aiheuta samalla tapaa viivettä).

Tämä on validi pointti. Tuollasta moninpelikuormaa voi hyvinkin vähentää tiputtamalla pois siirrettävän datan määrää. Moninpeleissä, ja etenkin MMO peleissä pitäs nimen omaan pyrkiä siirtämään mahdollisimman vähän dataa. Kaikki irrelevantti jätetään siirtämättä, tai siirretään pätkittäin (jos tällä datalla ei ole kiire). Monenlaisia optimointeja voidaan tehdä. Mä tavallaan tässä kysynkin että mitä CIG meinaa tehdä näissä tilanteissa. Ehkä vähän liian tekninen/yksityiskohtanen kysymys jos ei ole devaajia vastaamassa. Ehkä tätä infoa ei ole edes jaettu julki? Olen vain utelias miten CIG tälläset tilanteet hoitaa jotta voivat leuka pystyssä sanoa SC:tä saumattomaksi MMO:ksi.
Star Engine - Star Citizen Wiki

"...
Notable Tech
Rendering
  • Object space shader damage (allows 4 different types of damage to be permanently inflicted on ships, including cutting holes, and blended seamlessly into the base shading)
  • Real time environment-probe capture and compression (avoids needing to bake probes in space and on planets)
  • Image based lens flares (use entire source image to simulate 4 different physically based lens distortions per colour channel on up to 20 individual elements)
  • Physically based bloom (wide exponential kernel based purely on light intensity)
  • Human eye exposure simulation (capture histogram of light intensity from both screen and surroundings, isolate range of light we intend to focus on, simulate both pupil and photo-pigment reactions for quick and slow reactions)
  • Major improvements to planar lights (far more physical basis now which results in major quality improvements)
  • Intelligent mesh-merging system (repeatedly searches for best bang-for-buck mesh merge opportunity in a scene until we hit a memory limit)
  • Upgraded volumetric fog (e.g. support for planar lights, light-boxes, env-probe priority sorting)
  • Major upgrade to shadow pool system (all lights share one giant pool for better dynamic resolution scaling, shadows can be cached between frames for better performance)
  • Render target pooling (shares memory between internal textures used in the renderer to vastly reduce VRAM usage)
  • Render to texture pipeline (ability to render secondary viewports with full or limited feature set to then be used as textures in the primary scene, e.g. video comms or holograms)
  • Tiled lighting upgrades (use rasterization light culling for greater efficiency, particle support)
  • Density based LOD algorithm (LODs change based on polygon density to ensure consistent appearance, less artist intervention, and promote more optimal art assets with fewer sub-pixel polygons)
  • GGX normal map filtering (gloss adjusted in mip-chain to best fit of our GGX lighting model to give the same results as super sampled normals)
  • Camera relative rendering (allows 64bit world without incurring any rendering performance hit by maintaining 32bit precision for rendering)
  • GPU Particle System (built from the ground up for efficiency, distinct from Lumberyards and CryEngine's GPU particle systems)
  • Various improvements to transparency sorting (generalized system, allow depth of field and motion blur to not effect nearby in-focus objects, order independent transparency for specific shaders such as hair)
  • Artist friendly profiler (captures statistics per art-team, and per area of the level allowing accurate breakdowns and quick diagnosing of performance issues)
  • Physically based atmospheric scattering
  • Hierarchical object management (efficient searches and culling, local coordinate frames for things like ships inside ships on planets which are rotating etc)[11]
Tech included in Star Citizen Alpha 3.0.0 [12]
  • P4K System - improved data handling system
  • Planetary Rotation
  • Temporal Supersampling (TSAA) - previously rendered frames are used to improve the anti-aliasing results on the new frame
  • Improved Screen Space Directional Occlusion (SSDO)
  • New Filmic Tone Mapping Curve (ACES)
  • PBR Glass - Glass (e.g. cockpits) can be rendered with phyiscs-based distortions, cracks, reflections and chromatic effects
Future Planned features (as of October 2017)[12]
Short term

  • Terrain Occlusion & Shadowing
  • Gameplay Driven Material Shaders
  • "Space Fog" (Gas Clouds in e.g. asteroid fields)
  • Improved Hair
  • New Shield Effect
  • Depth of Field Improvements
  • Colour Processing Improvements
  • New Motion Blur Implementation
  • Support for Complex Shading Models
Mid/Long term goals

  • Object Container Streaming support on the low level/system side
  • Improved Planet Effects (shadows, clouds, etc.)
  • Improved Space Effects (stars, sun, rings, etc.)
  • Dynamic Global Illumination
  • Batching of physics-thread
  • Batching of render-thread
  • Vulcan backend support


Tools & 3rd-Party Software
  • Kythera - AI middleware [13]
  • Vulkan API - 3D graphics and compute API [14]
  • Wwise - Sound Engine [15]
  • FMOD - (deprecated) Sound Engine [4]
  • DataForge < citation needed > - Data management, Ship & Weapons balancing [4]
  • StoryForge - Dialogue and Conversations system, built upon DataForge [6]
  • VERS 3D (formerly known as PlanetEd) - Editor for creating planets [16]
  • System Layout Tool - Star system layout and design [5]
  • Room Management System - (deprecated) System for players to manage their hangars; now changed and integrated in Item Port System [4]
..."

Object Container Streaming - Star Citizen Wiki


Star Citizen Wiki



Se mitä puutuu ja tarvitaan on OCS ja BC serveripuolelle (ne on jo pelaajan puolella (tosin palaajan pään BC ei tee oikeastaan mitään ilman serveripään vastinetta (jonkunhan tarvii muistaa mitä unohdettiin)).


-------------------------------------


Koitan huomenna antaa hyvän arvauksen pohjautuen gigin antamiin tietoihin ja omalla tiedolla cryenginestä ja servereitä. Mutta pitää tarkastaa pari faktaa kun ei kaikkea jaksa muistaa.

Serveripää ei ole Cryengine pohjainen se on dedicaded Linux serveri joka on tehty tyhjästä niemnomaan tähän käyttötarkoitukseen ts Cryengine perusteella arvailemalla voi mennä metsään.

CIG on yleensä hyvin avoin mutta tuosta serveripään pelipalvelimesta se kertoo varsin vähän yksityiskohtia, sinällään ymmärrettävää kun se on se "salainenkastike" joka tekee Cryengine/Lumberyard pelistä MMO pelin.
 
Viimeksi muokattu:
Anteeksi kun kesti. Ei eilen joutanut. Mutta lähetään arvailemaan kun lupasin sellaisen antaa.


Puhutaan ensin näistä containereista. Alla oleva kuva on container.
container.JPG

Sisältää kaiken minkä pelimailma tarvitsee toimiakseen. Käsittääkseni tälläisestä containerista voidaan luoda serveri. Toi on itse asiassa 2mx2m area 18. Näitä ladataan pelaajan(Client) päässä muistiin kaikki mitkä on tietyllä säteellä pelaajasta tai pelaajan näkemiä. Toisin sanoen 2mx10m on 5 tälläistä ja voisi sisältää 5 serveriä. Eli 5x50 250 pelaajaa 10m metrin alueella. Tietys ne ei siihen fyysisti mahdu.

No sitten siihen server side object container streamiin. Tällä hetkellä serveri lataa kaikki containerit muistiin mitä mapista löytyy. Joo se serveri on linux pohjainen ja käsittelee samoja enytyjä mitä lyberyard.(sen verran että vaikka tekisit yksin pelin cryenginellä niin tarvitse serverin se vaan ajetaa clientin päässä).

Tämän SSOCS on tarkoitus ottaa käyttöön vaan ne containerit mitä pelaajat voivat nähdä. Esim pelaaja 1 on portolissa(500 containeria) ja pelaaja 2 on arcorpissa(1000000 containeria) niin serveri käsittelee 1000500 containerin datan. Eli tämä mahdollistaa sen että ei servulta lopu muisti kesken.

Sitten siihen servermesh teknologiaan. Ei sinäänsä ole mitään uutta teknologiaa GIG on vain tarpeeksi uhkarohkea että koittaa tehdä sen pelissä. Tossa oiva artikkeli jos ei ole mitään hajua mitä server mesh on https://hackernoon.com/9-things-you-need-to-know-about-mesh-networks-f61a77e5751a . Eli joka ikinen serveri voi jutella keskenään. Ei perustu normaaliin serveri tähtitopologiaan.

No nyt kun on käytössä tämä että containerit otetaan muistiin mitkä voidaan nähdä. Niin voidaan kysyä serveriltä että mitäs toi container sisältää esim. AI. No serveri vastaa että vitustako minä sen tiedän kysyn noilta muulta 1000000 serveriltä(kysely lähetään joka serverille). No saamme vastauksen nykyisellä 30 Hz/s tick ratella noin 100(luku perustuu että uskon että amazonin virtuaali servereitten latenssi on 1ms tai alle) millisekuntiin serveriltä 8999 että container sisältää koiran kakkaa. Pelaajan serveri lähettä sen Clientille että kysy tolta serveri 8999 kun en minä tiedä. Eli nyt client jutteelee 2 serverin kanssa yhtä aikaa. Ja kumpanenkin päivityy noin 30 kertaa sekuntissa. No nyt kun sinne serverille voi nähdä. Tosin että täytyisi nähdä 26 muulle serververille yhtä aikaa. Luku perustuu siihen että otetaan kuutio joka jaetaan 3x3x3 lattikoihin ja sinä olet sillä keskimäisen serverin laatikkossa että katettaisiin 360 astetta joka suuntaan.

No nyt oletetaan että toiselle serverille voi nähdä ja tiedetään mitä containeria katsellaan niin saadaan myös containerin paikka tieto Xyz selville. Ja vaikka olet omalla serverillä siduttu serverin origoon 0,0,0 niin voidaan laskea että mihinkä kordinaattiin pelaaja laitetaan jos se astuu sille serverille missä container sijaitsee. Eli sama tapaus kuin alusten kanssa vaikka olet sidottu serverin origoon olet myös sidottu aluksen origoon. Tässä tapauksessa olet vain sidottu siihen containerin origoon. Ja jos tätä dataa on mahdollista vaihtaa 30 kertaa sekuntissa niin aika saumatonta se serverin vaihto on. Siis voit nähdä useammalle serverille mutta voit vain siirtyä yhdelle kerrallan. Ja jos noi containerit on esim avaruudeessa 10kmx10kmx10km ja niitä on vierivieressä ja jokainen niistä voi olla serveri. niin paljonko sinne aurinkokuntaa mahtuu pelaajia niin sean tracyn sanoin ten million(kai se tässä vaiheessa olisi MMO). Tosin vastaus viittaa siihen että eivät itsekkään tiedä.
 
Saumaton loputon universumi ei ole mikään ongelma. Ainoa ongelma on siirrettävän datan määrä. En nyt ehkä ihan täysin sisäistänyt mitä tuossa pyrit selittämään. Hiukan kuulostaa siltä että peli pyörii server meshissä ja lähettää clienteille vaan dataa mitä niiden pitää rendata (nähdä) ja vastaavasti käsittelee player inputin? Eli jonkin asteista pilvipelaamista? Jos näin on niin tuo on tiettyyn pisteeseen asti mahdollista ja kuulostaa oikeastaan todella mielenkiintoselta ratkasulta. Jos taas ei niin miten ihmeessä kaikki data ehditään siirtää pelaajille, kaistan leveys ja nopeus on kuitenkin rajallista? Mutta epäilen että ymmärsin oikein homman juonen siinäkohtaa että tuo suurin liikenne ja laskenta tapahtuu siellä server meshissä ja clienteille lähetetään vain info mitä clientin tulee rendata pelaajan päässä.
 
Sinä oletat että ongelma olisi pelaajanpäässä mutta se ei ole ongelma on palvelinpäässä jonka tarvii hallita jokaikinin alus riipumatta siitä ketkä pelaajista näkee ne.

Ts ei voi olla yhtä palvelinta joka handlaisi kerralla 1600 pelaaja alusta jos taas tuo 1600 alusta pilkotaan monelle palvelimille jossainvaiheessa ongelmaksi nousee se että tarvitaan niin monia yhteyksiä eri palvelimien välillä (joka yhteys tuo mukana oman viiivensä).

Ts jos oletetaan että yksi palvelin handlaisi vain nykyisen maksimin eli 100 alusta tarvittaisiin vähintään 16 palvelinta ja koska jokainen palvelin tarvii yhteyden vähintään naapureihinsa olisi yhteysmäärä ehkä liian suuri jo tuolla 16:sta palvelimella.

Itse pitäisin hyvänä jo sitä jos päästää siihen että 8 palvelinta pystyisi hoitamaan yhden yhtenäisen taistelun jossa on 500 pelaajien hallitsemaan alusta (yksittäisessäa aluksessa voi olla enempi kuin 1 pelaajaa), noiden 500 pelaaja-aluksen lisäksi voi ollla AI/NPC aluksia (ne hallitaan palvelimelta joten ne eivät aiheuta samalla tapaa viivettä).

Kyllä jos toi servesmesh toimii niin kuin tossa ylempänä arverlin niin kyllä se ongelma on pelaajan päässä.
 
Saumaton loputon universumi ei ole mikään ongelma. Ainoa ongelma on siirrettävän datan määrä. En nyt ehkä ihan täysin sisäistänyt mitä tuossa pyrit selittämään. Hiukan kuulostaa siltä että peli pyörii server meshissä ja lähettää clienteille vaan dataa mitä niiden pitää rendata (nähdä) ja vastaavasti käsittelee player inputin? Eli jonkin asteista pilvipelaamista? Jos näin on niin tuo on tiettyyn pisteeseen asti mahdollista ja kuulostaa oikeastaan todella mielenkiintoselta ratkasulta. Jos taas ei niin miten ihmeessä kaikki data ehditään siirtää pelaajille, kaistan leveys ja nopeus on kuitenkin rajallista? Mutta epäilen että ymmärsin oikein homman juonen siinäkohtaa että tuo suurin liikenne ja laskenta tapahtuu siellä server meshissä ja clienteille lähetetään vain info mitä clientin tulee rendata pelaajan päässä.

Kyllä arvelit ihan oikein. Ja kyllä siinä jossain vaiheessa tule se serverin fyysinen kapasiteetti vastaan. Latenssi ja ihan laskenta teho. Tosin se mitä renderöidään otetaan Clientiltä muistista. kaikki näkyvä on kuitenkin clientin koneella. Se lähin tulee serveriltä mitä AI ja muut pelaajat tekee.
 
Anteeksi kun kesti. Ei eilen joutanut. Mutta lähetään arvailemaan kun lupasin sellaisen antaa.


Puhutaan ensin näistä containereista. Alla oleva kuva on container.
container.JPG

Sisältää kaiken minkä pelimailma tarvitsee toimiakseen. Käsittääkseni tälläisestä containerista voidaan luoda serveri. Toi on itse asiassa 2mx2m area 18. Näitä ladataan pelaajan(Client) päässä muistiin kaikki mitkä on tietyllä säteellä pelaajasta tai pelaajan näkemiä. Toisin sanoen 2mx10m on 5 tälläistä ja voisi sisältää 5 serveriä. Eli 5x50 250 pelaajaa 10m metrin alueella. Tietys ne ei siihen fyysisti mahdu.

...
Container on kaikenkattava tietorakenneformaatti johon jäsennetään kaikki SC:ssä.

Ts aivan kaikki on Containeri ja aivan kaikki sisältää Containereja.

Esimerkiksi hissintilausnappi on oma Containerinsa joka sisältää kaiken siihen liityvän.

Cotainerilla ei ole mitää kokorajoja ei suuruuden eikä pienuuden suhteen.

Tämän SSOCS on tarkoitus ottaa käyttöön vaan ne containerit mitä pelaajat voivat nähdä. Esim pelaaja 1 on portolissa(500 containeria) ja pelaaja 2 on arcorpissa(1000000 containeria) niin serveri käsittelee 1000500 containerin datan. Eli tämä mahdollistaa sen että ei servulta lopu muisti kesken.
Oikein, ongelma tulee siitä että tarvitaan ylempi serveritaso joka muistaa niiden kaikkien muiden Containerien tilan tätä serveritasoa ei vielä ole olemassa.

No nyt kun on käytössä tämä että containerit otetaan muistiin mitkä voidaan nähdä. Niin voidaan kysyä serveriltä että mitäs toi container sisältää esim. AI. No serveri vastaa että vitustako minä sen tiedän kysyn noilta muulta 1000000 serveriltä(kysely lähetään joka serverille). No saamme vastauksen nykyisellä 30 Hz/s tick ratella noin 100(luku perustuu että uskon että amazonin virtuaali servereitten latenssi on 1ms tai alle) millisekuntiin serveriltä 8999 että container sisältää koiran kakkaa. Pelaajan serveri lähettä sen Clientille että kysy tolta serveri 8999 kun en minä tiedä. Eli nyt client jutteelee 2 serverin kanssa yhtä aikaa. Ja kumpanenkin päivityy noin 30 kertaa sekuntissa. No nyt kun sinne serverille voi nähdä. Tosin että täytyisi nähdä 26 muulle serververille yhtä aikaa. Luku perustuu siihen että otetaan kuutio joka jaetaan 3x3x3 lattikoihin ja sinä olet sillä keskimäisen serverin laatikkossa että katettaisiin 360 astetta joka suuntaan.
Osuit ongelman ytimeen juuri tuo montako serveriä pystyy yhtäaikaa oleman hivessä on se rajoittava tekijä kokonaispelaajamäärälle taistelussa.

No nyt oletetaan että toiselle serverille voi nähdä ja tiedetään mitä containeria katsellaan niin saadaan myös containerin paikka tieto Xyz selville. Ja vaikka olet omalla serverillä siduttu serverin origoon 0,0,0 niin voidaan laskea että mihinkä kordinaattiin pelaaja laitetaan jos se astuu sille serverille missä container sijaitsee. Eli sama tapaus kuin alusten kanssa vaikka olet sidottu serverin origoon olet myös sidottu aluksen origoon. Tässä tapauksessa olet vain sidottu siihen containerin origoon. Ja jos tätä dataa on mahdollista vaihtaa 30 kertaa sekuntissa niin aika saumatonta se serverin vaihto on. Siis voit nähdä useammalle serverille mutta voit vain siirtyä yhdelle kerrallan. Ja jos noi containerit on esim avaruudeessa 10kmx10kmx10km ja niitä on vierivieressä ja jokainen niistä voi olla serveri. niin paljonko sinne aurinkokuntaa mahtuu pelaajia niin sean tracyn sanoin ten million(kai se tässä vaiheessa olisi MMO). Tosin vastaus viittaa siihen että eivät itsekkään tiedä.
SC:ssä on World Space (en varma muistinko nimityksen oikein) (64 bit float) se on koko aurinkokunnan kokoinen koorditaatisto jonka nollakohta on aurinko kaikken sijainti muunnetaan World Space ja Screen Space tilojen välillä.


------------------------------------------------------------------


Saumaton loputon universumi ei ole mikään ongelma. Ainoa ongelma on siirrettävän datan määrä. En nyt ehkä ihan täysin sisäistänyt mitä tuossa pyrit selittämään. Hiukan kuulostaa siltä että peli pyörii server meshissä ja lähettää clienteille vaan dataa mitä niiden pitää rendata (nähdä) ja vastaavasti käsittelee player inputin? Eli jonkin asteista pilvipelaamista? Jos näin on niin tuo on tiettyyn pisteeseen asti mahdollista ja kuulostaa oikeastaan todella mielenkiintoselta ratkasulta. Jos taas ei niin miten ihmeessä kaikki data ehditään siirtää pelaajille, kaistan leveys ja nopeus on kuitenkin rajallista? Mutta epäilen että ymmärsin oikein homman juonen siinäkohtaa että tuo suurin liikenne ja laskenta tapahtuu siellä server meshissä ja clienteille lähetetään vain info mitä clientin tulee rendata pelaajan päässä.
Pelaajan ja palvelimen väline datasiirtokapasiteeti ei ole se rajoittava tekijä.

rajoittava tekijä on nimeomana tuo kuinkan moneen palvelimen tarvitaa yhteys.


------------------------------------------------------------------


Kyllä jos toi servesmesh toimii niin kuin tossa ylempänä arverlin niin kyllä se ongelma on pelaajan päässä.
Lokonen pelaajan kone ei ole suoraan yhteydessä Meshin palvelimiin peli on Palvelin Authorative eli vain se pelaajan palvelin on yhteydessä toisiin palveliimiin ei pelaaajan kone.


------------------------------------------------------------------


Kyllä arvelit ihan oikein. Ja kyllä siinä jossain vaiheessa tule se serverin fyysinen kapasiteetti vastaan. Latenssi ja ihan laskenta teho. Tosin se mitä renderöidään otetaan Clientiltä muistista. kaikki näkyvä on kuitenkin clientin koneella. Se lähin tulee serveriltä mitä AI ja muut pelaajat tekee.
Serverillä on kaksi rajoittavaa tekijää

Severien välisten yhteyksien määrästä syntyvä viive.

Serverin ylläpitämien entiteetien (containerit) määrästä johtuva muistitarve.

Senjälkeen kun pelaajanpään OCS ja BC tuli käytöön pelin rajoituksen on olleet nimenomana serveripuolen rajoituksia.

Minä olen pelnnut 3570K + GTX670 koneella yli 50 FPS päivitysnopeudella PTU:ssa silloin kun on ollut käytössä sellainen PTU jossa serveri ei ole pullonkaulana.


------------------------------------------------------------------






 
Viimeksi muokattu:
3.6.0 PTU Wave 1









 
Viimeksi muokattu:
Cloud Imperium Board of Director Updates

Firman johtokunnassa tapahtui muutoksia, muttei nyt välttämättä kovin radikaaleja. Calderin miljardööriperheen edustaja taisi vaihtua.
...
Gardiiner lisätty tuohon johtokuntaan varmaan sen takia että johtokunnnan jäsenten määrä vastaisi paremmin todellista vallan jakoa (aikaisemmin ulkopuolinen taho oli yliedustettuna valtaansa nähden).


-------------------------------------------------------------------


Squadron 42 Updates - Are They On Track For a 2020 Release?

 
Viimeksi muokattu:


Tässä näppärä video uudesta VTOL systeemistä ja kritiikistä mitä se on saanut.



Myös toinen video samasta ominaisuudesta. Kannattaa huomioida että videossa esitetty manööveri ei ole mahdollista hiirellä ja näppäimistöllä tai edes HOTASilla jotka molemmat ovat huomattavasti suositumpia kuin HOSAS.
 
Viimeksi muokattu:
The new Star Citizen licensed kit model is nearly here....

...
1:100 Anvil Aerospace Arrow Model Kit (Pre-Order)

A 54 piece SLA 3D printed kit model, with interchangeable parts allowing you to display your model in flight or landed modes. Kit includes standard weapon loadout but further weapon choices will be available shortly for further customisation.

The presale kit also includes 2 extra diorama pieces and a £15 voucher towards your personalised gun load out.

Work+in+Progess+Image+10+-+Collection.png

...

Nuo JRD+F mallit on SLA prosessilla printattuja ts paljon yksityiskohtaisempia kuin normi harrastja 3D tulostimilla aikaansaadut.

Jos tuolle tulee tarpeeksi kysyntää ne tekee tulevaisuudessa malleja muistakin aluksista.

--------------------------------

Terada1.jpg
 
Viimeksi muokattu:
Seuraava 3.6 PTU on kaikille avoin.

 
Viimeksi muokattu:
3.6 PTU avoin kaikille (Sisältää ohjeet siitä miten ladataan PTU)



 
Viimeksi muokattu:
Uusi hover mode on erittäin huonosti toteutettu ominaisuus.

Lorvillesta on tullut avaruusalusten hautausmaa. Jengi ei pääse hangareista pois tai hangareihin sisään ilman että alus kippaa ympäri.






3.6 Live version mukana joka on odotettavissa lähi viikkoina tulee flight ready Anvil Ballista myyntiin. Kyseessä on AA-auto 8:lla S5 ohjuksella ja kahdella S7 joita pelissä ei ole aikaisemmin ollut. Hinnasta ei vielä tietoa.

star-citizen-alpha-36_6073188.jpg
 

Statistiikka

Viestiketjuista
258 101
Viestejä
4 484 152
Jäsenet
74 172
Uusin jäsen
Käppänä

Hinta.fi

Back
Ylös Bottom