[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Server design og klientoppdatering
On Mon, 7 Dec 1998, Sigmund Motzfeldt \y wrote:
> 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.
Ja alle objektene skal inn i cellestrukturen paa serveren. Manager
objektet vil vaere en naturlig kandidat for aa filtrere ut denne
informasjonen. Hvis et objekt er usynlig og spilleren(klienten) ikke kan
se usynlige objekter saa sendes ikke informasjon om dette objekte over til
klienten. Hvis klienten kan se varme saa sendes de over varme informasjon
om de objektene som har unormal(avvikende i forhold til omgivelsene)
temperatur. Problemet som kan dukke opp er at det tar tid aa informere
klienten om at alt dette. Hvis det er saa kan en vel ta igjen det i
storyen. Set det tar tid for en person aa tilvenne seg aa se med varmesyn
saa kan en sende over informasjonen om alle objektene for saa etter den
tid spillet har definert at det skal ta aa aktivisere varmesyn saa sender
en kommandoen: Varmesynet begynner aa virke naa.
> 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.
Hvis spilleren durer inn i et nytt omraade maa uansett klienten oppdateres
med informasjon om posisjon til alle objektene som er i omraade og da vil
informasjonen om tempratur, alignment, grad av synlighet vaere en svart
liten del av det som skal overfoeres.
> 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.
Dette er et lite design spoersmaal. Varmesyn kan jeg tenke meg
implementert paa foelgende maate. En bruker flere lag med farger paa de
objekte en skal tegne. Med texturing maa grunn fargen vaere hvit dersom
objektet skal faa orginal farge. Hvis en har en blaa grunnfarge vil
objektet bli blaat og kan indikere kalt objekt, med roed grunnfarge vill
det vaere varmt. Dette er en effekt som ikke trenger oppdatering fra gos
for klienten har allerede informasjonen om hvordan objektet ser ut. Saa
alt klienten trenger aa gjoere er aa forandre grunnfargen.
Hvis en kan teke seg at en NPC demon som gaar rundt i meneske form. Den
vil for alle som ikke har spesielle evner se ut som et meneske. Hvis en da
kaster et spell som faar den virklige formen til demonen til aa fremkomme
saa vil dette vaere et skifte av geometri som maa hentes fra gos.
Snø er jeg ikke helt sikker paa hvordan en skal haantere. Men jeg kan se
for meg to muligheter. Hvis snoe skal vises som at objetene bare blir
hvite saa kan dette implementeres i klienten uten at en trenger ny
geometri. Kan f.eks bruke normalenen til flatene og tegne alle flater som
peker oppover hvite. Et annet alternativ er at snoe skal ha tykkelse og da
kan snoe hentes ned som ny geometri fra gos og snoe blir et objekt i
klienten paa samme maate som alle andre objekter.
> 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 ?
Vi drepte ideen om frame basert protokoll ved aa regne paa en antatt
senen. Idee til senen for aa teste denne loesningen. Ta en liten landsby.
Paa en dag med litt trafikk kan en tenke seg at det finnes ca 60
personer/dyr i landsbyen, hver person har/bestaar i snitt ca 10 objekter
og det finnes ca 200 statiske obekte. Gjennom stroemnnigen antall personer
som kommer og gaar er ca 6 per min(1/10sek). Antall skifte i animasjoner
er ca 12 per min (1/5sek) per person.
Totalt antall objekter 200 + 60*10 = 800.
Kontinuerlig oppdatering per min blir da: Et skifte i animasjon vil jeg
pastaa et trenger folgende informasjon : posisjon ved et tidspunkt for
synkronisering og besked om ny bevegelse. (tid(4) +
posisjon/rotasjon(32) + animasjon(2) + hastighet/akselrasjon/osv. (ca 20))
~= 60b. Totalstroem: 60x12x60 = 3600*12 = 43.2k/min
Hvis en person skal slaa om til varmesyn saa blir det en pakke paa
(objektid(4)+varme(1))*800 ~= 4k for aa oppdatere klienten om varmen til
alle objektene.
Kommer du inn med teleport har du en mye stoere case: 40b*800 ~= 32k for
aa faa klient verdenen paa plass og saa maa all geometri hentes fra gos.
Kan jo haape at en del geometri ligger i cache.
> 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.
Jeg haaper at gos kan bare vare dum server og gi gemetri informasjon til
de klienten som spoer etter den.
>
> 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.
>
>
-----------------------------------------------------------
| ****** Anders Reggestad |
| * * * Norges teknisk-naturvitenskapelige universitet|
| * * * E-Mail : andersr@pvv.ntnu.no |
| ********* Post adresse : Studpost. 159 7034 Trondheim |
| * * * Hybel adresse : Rainheimliv. 21A 7053 Ranheim |
| * * * Hjemmeside : http://www.pvv.ntnu.no/~andersr |
-----------------------------------------------------------