[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Oppdatering og hastighet
- To: pvvmud@pvv.ntnu.no
- Subject: Oppdatering og hastighet
- From: "Sigmund Motzfeldt \\y" <sigmundo@marin.ntnu.no>
- Date: Fri, 20 Nov 1998 22:22:14 +0100 (MET)
- Delivered-To: home/andersr+pvvmud@homepvva.pvv.ntnu.no
- Delivered-To: andersr+pvvmud@pvv.ntnu.no
- Delivered-To: pvvmud@pvv.ntnu.no
Anders anslo 3.7k per frame. Dette synes jeg hoeres skremmende ut. Vi kan
neppe satse paa en kontinuerlig strøm paa mere enn 10-15k/s dersom vi vil
ha spillere fra mange ulike land. Siden GOS er forholdsvis frittstaaende,
kan vi ha flere slike rundt om i verden om vi vil det, men GS vil vi bare
ha en av.
Egen erfaring tilsier at under 20 frames/s blir mere og mere slitsomt aa
bevege seg i, mens en gjerne vil ha minst 25 frames/s om en skal spille
quake glatt og pent og kunne treffe de andre svina som hopper og spretter
rundt.
20 fps med 3.7k per frame gir oss 74 k/s. Det er mer enn du klarer med
ISDN.. (og det er _per_ klient)
Det jeg lurer paa er om den rene frame loesningen vi har tenkt paa til naa
vil gi noen videre sikkerhet i det hele tatt. Jeg antar vi kommer til aa
ha aapen kildekode til dette prosjektet. Dette betyr at det er latterlig
lett for en litt trent person aa skrive om klienten slik at cache systemet
ikke sletter noe og slik at klienten kjenner igjen dynamiske
objekter selv om vi ikke forteller noen at objektet faktisk er dynamisk. I
saa fall kan en erfaren spiller ha samlet ned nesten hele spillet paa sin
disk og gi det vekk til en nybegynner naar som helst. Den eneste infoen vi
klarer aa skjule er den faktiske inndelingen i celler.
Det jeg lurte paa var derfor om vi ikke skulle la klient og GOS ordne
nedlasting av statiske objekter slik at alt rundt spilleren er
kjent for klienten. Videre kan vi legge paa 'level of exploration' info.
Med dette mener jeg at naar du kommer til en by saa faar du lastet ned
alle objekter som forestiller hus, vegger, malerier, stoler, kister etc.
Det vi ikke laster ned er infoen om nedgangen til hulene under huset til
bakeren. Vi laster heller ikke ned infoen om det onde monsteret som lever
i de hulene. Disse tingene anses som 'classified'. Naar spilleren finner
hulene, oeker vi hans sikkerhetsklarering og lar han faa basic objektene
som utgjoer hulen, men vi laster fortsatt ikke ned noen info om det onde
monsteret. Dette skjer ikke foer spilleren har vandret nesten helt ned. Da
laster vi monsteret fra GOS men gir det ingen koordinater foer spilleren
staar face to face. En laster selvsagt ikke ned hele verdenen paa dette
viset, men en cacher de statiske objektene fra de cellene som er naermest
spilleren til en hver tid, selv om han ikke kan se dem enda.
Dette systemet flytter mye av belastningen over paa GOS, som jo kan
befinne seg tettere paa spilleren rent geografisk. Den utfordringen vi
faar er koordinatsystemet. Vi maa paa ett eller annet vis gi GOS info om
hvor i den globale verden klienten befinner seg. Dessuten maa vi etablere
et lokalt koordinatsystem der klienten kan putte inn det den faar fra GOS.
Det beste om en vil begrense makten til klienten er aa la den operere kun
med et lokalt koordinatsystem mens den globale posisjonen gis til GOS fra
GS. Dette behoever bare aa skje hver gang en bytter lokalt
koordinatsystem. Naar dette skjer maa klienten plutselig oppdatere all
koordinatinfo for den cachede statiske verdenen slik at de objektene som
fortsatt er innen rekkevidde faar oppdaterte data.
Det siste problemet er at statiske objekter ogsaa til en viss grad vil
maatte vaere dynamiske. Skjulte doerer er gode eksempler. Skogen som
plutselig vaakner rundt slottet naar den onde trollmannen er drept er et
annet.
Denne modellen vil minske kravet til hastighet i linken mellom klienten og
GS samtidig som den etter min mening ikke gir noen reell endring i
sikkerhet. Alle kan som sagt omskrive klienten sin til aa lage en komplett
database over hele verdenen de har utforsket til naa i alle fall. Dynamisk
objektinfo maa en fortsatt sende fra GS, og infoen kan med fordel
begrenses til de dynamiske objekter som er innen synsfeltet.
Ellers har Tore et godt poeng naar det gjelder animasjoner etc. Dersom vi
skal spare noe paa denne typen info, maa vi nesten vaere sikre paa at
klienten faar den pakken der en ber den om aa starte en animasjon. Dermed
vil vi ikke faa saa mye igjen for den rene viewbaserte framen vi har
snakket om til naa i alle fall. Kommentarer ?
Sigmund.