Re: Server design og klientoppdatering

["Sigmund Motzfeldt \\y" <sigmundo@marin.ntnu.no>]

On Mon, 7 Dec 1998, Anders Reggestad wrote:

> 
> Det eneste vi har disuktert om serveren er et forlag til objekter som
> forhandler om hvilke grensesnitt de har tilgjenglig. Skal nå presentere en
> mulig løsning for hvordan serveren skal kunne oppdatere klient verdnene.
> 
> Denne modellen går ut fra at klienen har en kopi av den fysiske
> oppbygginen av objekter for den delen av verdnen som er synlig fra
> klienten. På serveren vil det være naturlig å ha et form for manager
> objekt som hånterer den enkelte klient. Denne manageren registrerer
> intresse i de objekter som skal være synlig for klienten. Så når et objekt
> oppdaterer sin status så går den også gjennom lista over manager obekter
> som har registert intresse i objektet og sender denne
> oppdateringsinformasjonen ditt slik at manageren kan oppdatere klienten.
> 
> Dette medfører at objektene på serveren må ha en form for to lags
> oppdeling. Der den undre delen lagrer den fysiske(Visuelle) statusen til
> objektet og den øvre delen lagrer den logiske/abstrakte statusen til
> objektet. Grensesnitte mellom disse to lagene må være klart definert slik
> at det er enkelt å legge funksjonaliteten for å oppdatere klienetne i 
> overgangen. 
> 
> Grensesnittet til det fysiske laget tenkte jeg kunne inneholde funksjoner
> for å sette posisjon, rettning, hastighet, akselerasjon, animasjoner, osv.
> 
> Det fysiske laget er også ansvarlig for å gjøre simuleringen som er
> nødvendig når objektet har fått besked om å bevege seg. Dette laget vil
> også varsle den logiske delen om det f.eks har oppstått en kollisjon.
> 
> Med faste intervall vil manager objektet sende over sync informasjon til
> klienten slik at en er sikker på at klienten og serveren har samme
> oppfattning av verdenen.
> 
> 
> Det vil sikkert også være aktuelt på serveren å ha en oversikt over hvilke
> objekter som må simuleres slik at en ikke trenger å kalle opp en funksjon
> i alle objektene ved vært tidsinterval.

Jeg antar at disse objektene skal plasseres inn i den store
cellestrukturen i serveren. Det jeg synes virker logisk er at alle
objekter har to deler som du sier. Det virker ogsaa logisk at de sender
oppdateringer naar de endrer tilstand. Jeg ser for meg et par problemer i
det hele. For det foerste vil jeg tro at en del objekter vil ha utvidet
informasjon som kun er tilgjengelig for enkelte spillere. (informasjon om
temperatur for de med varmesyn, info om alignment for folk med 'detect
alignment' type spells, info om aandelig kapasitet for astral vision,
mulighet for aa se usynlige ting med detect invis etc.) Denne
informasjonen maa da serveren filtrere. Ulempen med alt dette er at
spillerne beveger seg. Dersom en spiller plutselig kommer rasende inn til
skipet som hever anker, maa det faa informasjon om dette. Dersom han durer
inn i et omraade der alle objekter har gaatt over i tilstand 'nedsnoedd'
saa maa klienten informeres om dette. Dersom spilleren plutselig
kaster 'varmesyn' saa maa han tegne et nytt bilde som tar hensyn til
temperaturen paa ting. Denne tilstandsinformasjonen
vil endres i realtime, slik at det klienten faar fra GOS maa kobles med
tilstandsinfo for at klienten skal kunne vise objektene. Jo flere objekter
den maa ha slik info for i en sleng, jo mere slit for nettet.

Akkurat det aa sende informasjon om ting som endrer seg mens en staar og
ser paa tror jeg godt vi kan sende slik du har foreslaatt. Da jeg antar at
alle objekter er aa finne i den store cellestrukturen, vil en ogsaa kunne
hente ut informasjon om tilstand til de klientene som kommer til etter at
animasjonen er startet. Det jeg lurer paa er hvor krevende det vil bli ?
Akkurat varmesyn og saant vil vel bare gjelde et titalls objekter i en
scene, men dersom en teleporter inn i et omraade som er nedsnoedd saa blir
det mye statusinfo.

Det jeg lurte litt paa var om en kanskje kunne delt denne informasjonen i
to. Ting som angaar et helt omraade som f.x. snoe kunne en sende info om
til GOS slik at denne kunne sende til klienten. Jeg antar at vi ikke
oensker aa ha hele den ville datastrukturen vaar gjengitt i klienten. I
saa fall kunne klienten faatt denne informasjonen direkte. Uansett, GOS
burde kunne haandtere aa faa informasjon om at 'cellene x1,y1,z1
x2,y1,z1... er nedsnoedd, husk det naar du snakker med klientene' 'Det er
ogsaa vinterstorm i havomraade saa og saa, fortell klientene at
havobjektene skal visualiseres med stormpresets'. De enkelte objektene i
cellene maa da vite om de er utendoers eller innendoers selvsagt :)
Innendoers objekter skal se like ut selv om omraadet er generelt
nedsnoedd.

Vi kunne da la hovedserver konsentrere seg om informasjon som endrer seg
fortere og/eller som angaar faerre objekter. (animasjoner, temperatur,
usynlighet etc.) Er en slik deling praktisk ?

 Sigmund.