Re: Oppdatering og hastighet

[Steinar Hamre <steinarh@stud.fim.ntnu.no>]

On Fri, 20 Nov 1998, Sigmund Motzfeldt \y wrote:
> 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.

En UDP-pakke kan selv på ethernett max være ca 1.4k.

> 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.


Et poeng er at klienten kan lage flere frames. I stedet for at serveren
sender posisjonen til et objekt, sender det posisjon pluss fart, så kan
klienten gjøre så godt den kan med å animere objektet. Du kan også sende
høyereordens deriverte, en hel animasjonsserie (f.eks animerte teksturer),
eller som Tore foreslår, objekter som vel i prinsippet er "programmer" som
kjøres av klienten.

> 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)

Jeg tror ikke båndbreddeforbruket er det problemet som en først går etter.
fordi:
1. Det vil gå gjevnt nedover når klienten blir smartere.
2. Nett blir raskere og billigere, om 5 år er sikkert ADSL standarden som
de med ISDN i dag bruker. (Dvs i Europa blir nok ADSL mer vanlig som en
utvidelse av ISDN.)

Det som er viktig er skalerbarhet. dvs at ting _kan_ fordeles over flere
maskiner, bilder og grafiske objekter kan caches på en server nermere deg,
osv. (Graphical Object Server, GOS)

> 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.

Dette er vesentlig. Både av båndbreddehensyn og av hensyn til at det ikke
skal lønne seg å skrive en juksende klient, sender en bare de objektene
som en spiller "ser". LOS (Line Of Sight) kan defineres på en
Quake-lignede "du ser det som er foran deg" måte eller en
crossfire-lignende "du ser til alle sider, men ikke gjennom vegger"-måte

Serveren sender objeketer som ligger i din LOS. Klienten regner ut hvilken
side du ser de fra osv. For eksempel kan serveren si at det går et monster
bortover gangen, men den bør ikke si at om 10 skeunder vil det snu og
skyte på deg. ;-)

> 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.

Tanken er vel at GOS skal vite hvordan monsteret ser ut, men ikke hvor det
er? Uansett er du inne på noe vesentlig. Vi har en avveining mellom det
klienten bør vite (slik at den kan hente grafikk og klargjøre
animaskjoner) og det den ikke bør vite for å hindre juks. Du vil ikke si
at det er et monster inne i hula, selv om det animasjonsmessig hadde vært
en fordel å hente ned monsteret på forhånd. (Du kan selvsagt hente ned
alle bilder som er i nærheten, eller alle figurer som ligger lagret i GOS,
men dette kan igjen lett føre til at henter for mye. (diskplass) eller
bruker båndbredde på å laste ned ting som ikke vil bli vist.)

	Steinar