Steam Support Wiki
 
 

Gold Source -pelimoottori

 
 
Uudelleenohjattu sivulta Gold Source Engine

Tämän sivun sisältö on Steamin tuen ja Steamin käyttäjäyhteisön ylläpitämä - kaikkia sivuston ulkopuolelle johtavia linkkejä on käsiteltävä varoen.

Steamin tuki ei tule missään tapauksissa pyytämään tilisi salasanaa, eikä myöskään pyydä sinua antamaan sitä web-sivuston kautta syötettäviin tekstikenttiin.

Tässä lyhyt selostus siitä, kuinka palvelimet ja asiakasohjelmat vaikuttavat toisiinsa, FPS:stä, Ping Boostereista ja siitä, kuinka kaikki palat toimivat yhdessä.

Pelimoottori

Half-Life moninpelimoottori koostuu palvelimesta ja yhdestä tai useammasta (maksimissaan 32:sta) asiakasohjelmasta jotka kommunikoivat vuorovaikuttaen puolireaaliaikaisesti internetissä. Palvelimen ja asiakasohjelman välinen kommunikaatio käyttää UDP-protokollaa joka soveltuu hyvin tämänkaltaiseen kommunikaatioon. <TCP/UDP:stä lisää myöhemmin>

Palvelin on renderöintitietokone (rendering machine) ilman minkäänlaisia grafiikoita. Asiakasohjelma taas hyödyntää graafisia ja akustisia alisysteemejä jotka vuorovaikuttavat myös pelaajan kanssa näppäimistön, hiiren, joystickin tai minkä tahansa muun peliohjaimen kautta.

Normaalisti palvelin renderöi oletusarvoisesti 100FPS:n ( kuvia per sekunti) jaksoissa, tai siis käyttää 10ms per ruutu. Erinnäisten tahallisten tai tahattomien innovaatioiden mahdollistamina, Palvelin pystyy renderöimään paljon nopeammissa jaksoissa, jopa 1000FPS. Laitteistot ja käyttöjärjestelmä rajoittavat Palvelimen maksimi-FPS:ää.

Asiakasohjelmien kannalta on sama, renderöikö Palvelin 500 vai 1000FPS, jokainen kone renderöi ruudut itsenäisesti. Palvelimen FPS asetetaan sys_ticrate (min. 0, max 1000) CVARin kautta.

Mikäli palvelintietokoneella on tarpeeksi hevosvoimia, palvelimen ajamisella korkeammalla FPS:llä (aina maksimiasetukseen 1000 asti) on positiivisia vaikutuksia. Tarkastellaan mitä tapahtuu ja miksi.

Palvelin pyörittää kenttää, siirtää resursseja välimuistiin, renderöi ruutuja, vastaanottaa statuspäivityksiä asiakasohjelmilta ja lähettää päivityksiä asiakasohjelmille.

Asiakasohjelma pyörittää samaa kenttää (tarkistussumman on täsmättävä), renderöi sen omia ruutuja sekä lähettää ja vastaanottaa päivityksiä palvelimelta. Asiakasohjelma myös esittää ruudut pelaajalle graafisesti ja akustisesti (palvelin ei) ja toimii vuorovaikutuksessa pelaajan kanssa.

Lisäksi, asiakasohjelma renderöi kaikki animaatiot ja sijainnit 3D-malleille, sprite-kuville, äänille, animoiduille tekstuureille (kuten vedelle) ja liikkuville olioille pelaajan näkökentässä. Tämä sisältää aseen ja lentävät luodit.

Serveri pitää kirjaa kaikesta tästä, mutta sen ei tarvitse renderöidä mitään niistä. Vain päivittää asiakasohjelman tiedot asemien vaihdoksesta ja tapahtumista.

Eli siis on oikeastaan kaksi erillistä ja itsenäistä (ja kuitenkin toisistaan riippuvaista) renderöintisysteemiä jotka kommunikoivat toistensa kanssa edestakaisin.

Oletetaan että Palvelin renderöi ruutuja 500FPS. Tämä tarkoittaa, että silmäys kaikesta mitä tapahtuu on valmiina lähetettäväksi asiakasohjelmalle joka toinen millisekunti (1000FPS tarkoittaa 1ms).

Asiakasohjelma on Palvelimen kanssa vuorovaikutuksessa itseasiassa kahdella eri tavalla. Asiakasohjelma lähettää päivityksiä asiakkaan sijainnista ja toimista 30 kertaa sekunnissa (oletusarvo cl_cmdrate:lle on 30) ja lähettää pyynnön täydellisestä päivityksestä palvelimelle 20 kertaa sekunnissa (oletusarvo cl_updateratelle on 20). Jätämmä cl_cmdraten nyt huomiomatta, sillä se ei vaadi vastausta palvelimelta.

Eli kun cl_cmdrate on asetettu 20:een, asiakasohjelma pyytää Palvelimelta päivitystä tapahtumista 50 millisekunnin välein. Lisäämme sitten tiedon matkustusajan (puolet pingistä) asiakkaalta palvelimelle. Siihen lisätään viellä maksimissaan (kun palvelin renderöi 500FPS) 2:den millisekunnin viive jossa palvelin renderöi päivityksen ja lähettää sen takaisin. Takaisinmatkustus kestää toisen puolen pingistä.

Jos palvelin renderöi 100FPS, päivityksen renderöinti voi kestää maksimissaan 10ms.

Koska kaikki asiakasohjelmat renderöivät ja pyytävät päivityksiä itsenäisesti, jokainen niistä lähettää sattumanvaraisesti (toisten mielestä) päivityksiä palvelimelle. Ajattele tätä päivitysten "myrskynä", jossa päivityspyyntöjä sataa palvelimelle eri aikoihin ja eri määriä.

Näiden päivitysten edestakaisinlähettämistä säätelee Rate-CVAR asiakkaan puolella (0:sta 20000:een) ja sv_minrate ja sv_maxrate palvelimen puolella. Palvelimen asetukset asettavat rajat asiakkaan asettamille rajoille. Rate mitataan tavuna sekunnissa. Keskimäärin, pelaaja jolla rate on asetettu 7500:aan, lähettää ja vastaanottaa maksimissaan noin 7.5Kilotavua sekunnissa serveriltä.

Jos palvelinta ajetaan 100FPS:llä, niin silloin palvelimella on 10ms:n jaksoja jolloin nämä pyynnöt kasaantuvat samalla kun palvelin renderöi ja lähettää edellisen jonon päivitykset asiakkaille. Jos palvelin pystyy käsittelemään nykyisen ruudun ennen sys_ticraten määrittämää aikaväliä, se "nukkuu" loppuajan.

Tämä tarkoittaa, että mikäli asiakkaita on paljon, palvelin joutuu lähettämään suuria määriä tietoa 10 millisekunnin välein. Tämä saattaa olla merkittävä rasite palvelimen ulospäin suuntautuvalle yhteydelle.

Mikäli palvelilnta ajetaan 1000FPS, palvelin pystyy tehokkaammin vastaamaan yksittäisen asiakasohjelman pyyntöihin lähes heti. Palvelin lähettää tällöin tasaisemmin pienempiä paketteja. (Keskiarvo pysyy kuitenkin samana)

Tämä vaikuttaa kolmeen asiaan. Se vähentää palvelimen yhteyteen kohdistuvaa rasitusta (vähemmän ruuhkautumisia), vähentää suhteellista lisää jokaisen asiakkaan näkemään pingiin (10ms vähenee yhteen tai kahteen millisekuntiin) ja se pitää asiakasohjelman hieman paremmin ajan tasalla, parantaen tarkkuutta ja vähentäen lagia.

(Huom: Palvelin saattaa itseasiassa lähettää nykyisen esi-renderöidyn ruudun heti kun se saa päivityspyynnön asiakkaalta eikä odota seuraavaa ruutua. En ole pystynyt vahvistamaan tätä muuten kuin empiirisesti ja tapa jolla selitän sen vaikuttaa siltä, miten se toimii)

Yhteenveto:

  1. Palvelin renderöi ruutuja 100, 500 tai 1000 FPS. Päivitykset ovat valmiina siis 10:n, 2:n tai 1:n millisekunnin välein. Asiakasohjelmat renderöivät kuvia (oletusarvoisesti) 100FPS ja näyttävät ruutuja (tyypillisesti) 30-100FPS riippuen suorittimen ja näytönohjaimen tehosta ja siitä, mitä pelissä tapahtuu.
  2. Asiakasohjelmat lähettävät päivitystietoa (cl_updaterate) palvelimelle (oletus) 30 kertaa sekunnissa.
  3. Asiakasohjelmat pyytävät päivityksiä palvelimelta (cl_cmdrate) 20 kertaa sekunnissa (oletus), joka tarkoittaa 50ms päivitysten välissä. Palvelin lähettää päivitystietoa asiakasohjelmalle tuon 50ms välein (plus pingin aiheuttama matkustusaika). Asiakasohjelma renderöi näkyviä ruutuja, ennustaa tapahtumia ja on vuorovaikutuksessa pelaajan kanssa kunnes seuraava päivitys saapuu.
  4. Asiakasohjelmat lähettävät tietoa palvelimelle ja palvelin lähettää tietoa asiakasohjelmille asiakaspuolen CVAR 'rate' mukaisella nopeudella, jota serveri rajoittaa sv_maxrate CVAR:lla
  5. Korkeammilla FPS:llä ajettavat palvelimet pystyvät lähettämään päivitystietoa asiakkaalle nopeammin ja vähentävät serverin yhteyteen kohdistuvaa ruuhkautumista.
  6. Asiakasohjelmat lähettävät palvelimille ja vastaanottavat palvelimilta saman määrän tietoa riippumatta millä FPS:llä palvelinta ajetaan. Tämä tietenkin olettaa, että serverillä on asetettu järkevät rajat (sv_maxupdaterate)
  7. Palvelimen CVARit sv_maxrate ja sv_maxupdaterate tulevat heti voimaan, tosin saattaa olla pieni viive ennen kuin muutokset tulevat näkyviin (jos mitään näkyviä muutoksia edes tulee)
 
 
  link: Valve Software MediaWiki Logo