Re: your mail

[Tore Skaug <toresk@pvv.ntnu.no>]

Et lite tips, Peter: mange mail-programmer blir litt gretne naar de mottar
tekst som har lengre linjer enn 76 tegn eller noe slikt (noen av de andre
har helt sikkert eksakt tall), du kan sikkert stille om dette i
mail-programmet ditt. Norske tegn kommer ogsaa frem litt merkelig, men det
er kanskje et "lese-mail-i-Frankrike-fenomen", og med mine ae, oe og aa
skal jeg ikke rope for hoeyt om det. :-) Jeg har "brukket om litt" paa
teksten din under.

> Eg har tenkt litt pÔ bevegelse av personer. Eg synest at generelt sett sÔ har 
> dei fleste characters for lite handlefrihet nÔr det gjeld bevegelse. Dei har en 
> gÔ-animasjon en sprihge-animasjon og mange sloss-animasjonar. Kva om ein person 
> ville springe og sloss samtidig (kva for ein tulling det no mÔtte v×re) Det 
> ville da kreve ein ny animasjon.

Jeg tenkte litt paa dette for en tid tilbake, og hadde en ide om at det
maatte gaa an aa modellere slik at personen til enhver tid gjorde "det
mest optimale". Men meg bekjent er det vanskelig nok aa faa til en
naturlig gange med 3D-grafikk, saa jeg tror dette ville vaere litt vel
komplisert for helt generelle bevegelser (person A staar ved en seng og
skal ende opp liggende paa senga, gjoer en saklig bevegelse for aa komme
fra startpos. til sluttpos.) Men loepe-og-fekte-med-armene hoeres absolutt
mulig ut.

Dersom en person er i ferd med aa gjoere noe, og saa avbryter for aa
gjoere noe annet, kunne det kanskje gaa an med en eller annen form for
interpolasjon for aa gli fra den ene handlingen til den andre. Det ser
litt teit ut hvis en person hopper over i "noeytral stilling" hvis han
treffes av et sverdslag mens han er i ferd med aa snu seg.

> Eg har jobba litt med Ô modellere kvar del for seg (det er mulig eg
> jobber pÔ totalt elendige ting, men men) og sÔ sette saman etter eiget
> Önske. Ein set posisjonen til personen i magen (for eksempel) sÔ
> modellerer ein den delen av magen som har tiln×rma konstant form. Ein
> set pÔ ein skulder, som egentlig ikkje er meir enn eit koordinatsystem
> som er plassert relativt til posisjonen til karakteren. Overarma er
> festa til skuldra, og roterer om denne i bestemte vinklar. Underarma
> er sÔ festa til overarma i eit anna koordinatsystem. Poenget er at
> kvar del ikkje treng Ô animerast. Dei kan modellerast statisk og
> setast saman (punktvis) sÔ kan ein etterpÔ legge pÔ polygon, som er
> referert til koordinatsystemet til personen (hoved-retning) slik at
> ein fÔr ei truverdig bevegelse, slik at overarm og skulder faktisk
> heng saman.

Dette hoeres ut som den mest naturlige maaten aa gjoere det paa. Jeg kunne
ogsaa tenke meg at det var modellert slik paa serveren for spillere og
andre objekter der, f.eks. burde enhver skapning med abstraksjonen
"finger" med passende dimensjoner kunne proeve aa sette paa en ring. Om
ringen vil fungere paa skapningen og ha en annen effekt enn aa se pen ut,
det er en annen sak, men det er det vel parametre fra fingerens eier som
bestemmer.

Jeg synes vi maa vaere sikre paa at vi designer "for gjenbruk", armer kan
f.eks. gjenbrukes i modellering av en "skytte" (hest med
menneske-overkropp, hva det naa pleier aa hete utenfor
rollespill-verdenen), og noen abstraksjoner over "arm" burde kunne gjoere
det mulig aa implementere fekting/bueskyting uten altfor mye ekstraarbeid
dersom dette allerede er gjort for humanoider.

> Dette er ikkje sÔ vanskelig Ô lage, eg har allerede laga det grÖvste,
> men modelleringa er det verre med. For det fÖrste har eg ikkje noko
> 3d-modelleringsverktÖy og for det andre sÔ har eg ikkje anelse om kva
> format dei eventuelt lagrar i. Dette kan i alle fall fÖre til
> realistisk view-point. Camera settest i hÖgre og venstre auge (gir
> mulighet for 3d-briller) og nÔr hovudet roterer, sÔ fÔr ein eit reelt
> bilete av kva personen i realiteten ville sjÔ.  Istadenfor Ô rotere om
> eit punkt. Igjen, eg veit ikkje kva som er vanleg i andre 3d-engines.

Jeg har nesten aldri satt mine bein i 3D-grafikk utover aa eie et 3Dfx
kort og faa det til aa fungere i Linux, saa jeg vet at andre her kan dette
mye bedre enn meg. Men jeg kan uansett nevne at det saavidt jeg husker er
noen referanser til modellerings-verktoey paa FAQ'en til PovRay (en gratis
raytracer), se http://www.povray.org/ . En raytracer er selvsagt ikke det
vi vil bruke, men kanskje noen av modellerings-verktoeyene kan brukes og
at spillet kan importere grafiske objekter fra et passende format.

> Ein anna ting som eg har tenkt pÔ, er vatn. Rettere sagt hav. NÔr ein
> kan modellere landskap som matematiske funksjoner, sÔ bÖr ein ogsÔ
> kunne modellere sjÖtilstander. Ein sjÖtilstand kan (tiln×rma)
> beskrivast av ein sum av sinuskomponentar. BÖlgehevninga vil da v×re
> bestemt i heile omrÔdet ut ifrÔ, sei 10-20 sinuskomponentar.
> BÖlgehevninga varierer med tid, og ein vil da mÔtte rekne ut ny
> bÖlgehevning for kvar frame. Dette er det same som for landskap, bare
> at for landskap er funksjonen konstant. Eg har tenkt at det hadde vore
> artig Ô plassere skip pÔ denne overflata, og la det bevege seg (kan
> ogsÔ beskrivast ganske enkelt, v. sinusfunksjonar) Ð ha spelarens view
> fra bÔten i ein storm, hadde vore skitkult! Det her er ikkje
> fÖrsteprioritet, eg veit det.  Ikkje andre eller tredje heller, men
> muligheten for Ô implementere det, bÖr v×re tilstede.

Jeg aner ikke om modellen av vann er god, men ideen hoeres uansett bra ut.
Havet blir vel da et digert mesh paa klienten, et mesh som klienten kan
gjoere all griseregningen paa selv saa lenge klient og server er
synkronisert paa hvordan havet beveger seg. Serveren kan konsentrere seg
om aa beregne parametre viktig for objekter som befinner seg paa havet,
antageligvis ikke saa mange, mens klienten kan tegne opp hele flaten,
inklusiv en haug punkter som serveren ikke er interessert i aa vite noe
om.

> Dette er kanskje trivielt, men nÔr det gjeld begrensning pÔ stÖrrelsen av 
> verdenen:
>   Har ein mange personer som befinn seg i same verden, og har ein
> server som skal ta seg av alle desse og sende frames til dei, mÔ den
> ha heile verden i minnet heile tida, fordi personar vil i v×rste fall
> befinne seg javnt fordelt utover verdenen, og det vil da ikkje v×re
> noko spelerom for maskina Ô mappe inn og ut omrÔder. Dette vil ogsÔ
> v×re vanskelig Ô koordinere. Eit anna problem, er kva format
> koordinatane skal lagrast i. Heiltall er klart raskast, men har ei
> klar begrensning nÔr det gjeld rekkevidde. Ein mulighet der er Ô dele
> opp verden i mange koordinatsystem, slik at eit punkt refererer seg
> til eit bestemt koordinatsystem, og alle koordinatsystema har
> posisjoner relativt til kvarandre.  DÔ vil det ogsÔ v×re enkelt Ô
> plassere inn nye bitar av verden, ved Ô plassere inn eit nytt
> koordinatsystem med gitt utstrekning, og ha punkter langs begge
> koordinatsystema som kan knyttast saman (dette kan sikkert by pÔ
> problem) Eg vil tru at det ikkje er sÔ dumt Ô bruke fleire servere, og
> ha ein del pÔ kvar server. Da ville ein kunne ha mykje stÖrre omrÔder
> Ô bevege seg over. Jaj . Nok for meg for i dag. Ciao

Jeg tror flyttall er det greieste aa bruke som et internt format for
posisjonering i et koordinatsystem paa serveren, mens det kanskje er
interessant/best aa bruke heltallskoordinater med passende antall bits for
kommunikasjon av posisjoner til klientene. Antallet bits noedvendig kan
bestemes dynamisk etter stoerrelsen paa koordinatsystemet, og paa den
maaten oversendes et minimum av informasjon til klienten. Dersom en ogsaa
tar "sist kommuniserte posisjon til klienten" i betraktning, skulle det
vaere mulig aa lage noen gode Huffman-koder eller andre koder som gjoer at
det vanligvis ikke vil ta mer enn noen faa bits aa overfoere en ny
koordinat.

Dette er nok lettere aa faa til med heltall, i tillegg til at heltall
tilbyr noe vi oensker, en uniform "punkt-tetthet" over koordinatsystemet
dersom 0,0,0 er nederst-soer-vest og 2^m,2^n,2^p er oeverst-nord-oest.

Paa serveren er det vel mest tilbakelent aa bruke doubles saa lenge det
ikke er et problem mhp. lagerplass og CPU-forbruk.

Jeg synes selv (i oeyeblikket) at ett koordinatsystem for en verden er det
greieste. Dersom en har egne plan, Astral plane ol., blir det et eget
koordinatsystem. Paa en eller annen maate maa det vaere "jumping points"
mellom koordinatsystem.

Dersom det er mest praktisk burde det vel vaere mulig aa lage f.eks. en
hule som et eget koordinatsystem, saerlig dersom det er en "umulig" hule,
en magisk sak som ikke kan eksistere i praksis (samme posisjon i verden
kan vaere forskjellig avhengig av hvordan en beveger seg dit)

Jeg tenker for tiden litt tanker om hvordan serveren kan haandtere alt som
skjer i en diger verden, og jeg tenker omtrent i disse baner:

En verden med ett koordinatsystem kan modelleres inn i et rektangel.
Systemet holder greie paa hva som befinner seg innenfor dette rektangelet
av objekter, hvilke grensesnitt de publiserer og parametre for interaksjon
mellom objektene. I tre dimensjoner vil rektangel bli til kube, men her
tenker jeg for enkelhets skyld i to dimensjoner.

Hvert rektangel kan deles opp i to rektangel dersom det er hensiktsmessig.
"Hensiktsmessig" kan bety at det er "for mange" objekter i rektangelet til
at serveren kan arbeide effektivt, at det blir mye ekstraarbeid naar
kjernen skal koble sammen objekter som skal gjoere interaksjon etc.  Ett
underrektangel kan igjen deles opp i nye rektangler osv., og slik kan en
fortsette opp til en eller annne minste granularitet.

Denne oppdelingen er dynamisk, dvs. med tidsintervaller T reevalueres hele
oppdelingen paa en eller annen effektiv maate. Innenfor dette
tidsintervallet gjoeres ganske enkelt en hand-over for objekter som
beveger seg mellom omraadene.

Noe av oppdelingen kan vaere statisk, og kanskje det er en elv, fjellkjede
eller noe slikt som begrenser aktiviteten mellom omraadene. En kan tenke
seg at en kan ha flere servere som tar ansvar for hva som skjer i hvert
omraade, som en maate aa skalere paa (ikke verdens beste maate, men
dog...).

Tanken er at mye av kommunikasjon og signaler ut fra et objekt, for ikke
aa si nesten alt, er svaert geografisk begrenset, begrenset til umiddelbar
naerhet av objektet.  Dersom serveren har noen strukturer som sier hvilke
objekter som befinner seg i "naerheten", reduseres arbeidet dersom det
f.eks. skal evalueres hvem som reagerer paa at en person skriker.
For handlinger som affekterer et visst omraade av brettet, kan det
evalueres hvilke rektangler som er affektert, og saa vet spillet hvilke
objekter som er kandidater for interaksjon.

Merk at jeg her ikke har tatt noe som helst om landskap/vegger/etc. med i
betraktningen.  Dette tror jeg boer vaere et eget system som de som har
peiling paa 3D vet noe om. Ting som line-of-sight mellom to punkter maa
paa et eller annet vis vaere stoettet og effektivt. Samtidig maa det vaere
bygget inn abstraksjoner om omraader der det kan vaere spesielle regler
som gjelder.

Som dere skjoenner enker jeg fortsatt litt i retning
signaler/slots/metoder, uten helt aa vaere enig med meg selv enda om dette
er noe som kan gjoeres effektivt og er en god ide.

Noe som kunne vaere en liten "case", noe jeg synes vi burde kunne faa til,
er foelgende eksempel:

Den slemme magikeren Marit, NPC, har stoett paa en gruppe eventyrere,
deriblant krigeren Kjell og magikeren Mads, og bestemmer seg for aa plage
dem. Hun setter igang med diverse besvergelser for aa mane frem en magisk
insektsverm mot dem.

Formelkasting er noe som tar litt tid, og en kunst ikke alle vet like mye
om. Marit sender uansett ut et "magisk signal" med en "rekkevidde" paa noe
slikt som 100m. Med signalet er informasjon om avsender, formelen som er
underveis etc.

Kjernen haandterer dette signalet. Den sjekker foerst hvilke rektangler
som er affektert av signalets begrensning, antageligvis bare 1-2. Deretter
sjekker den hvor mange som har registrert seg som lyttere paa signalet og
avleverer signalet til hver enkelt mottager.

Krigeren Kjell er en av objektene i omraadet, men han kan ingenting om
magi (har ikke registrert seg, hvertfall), saa han mottar ingenting.

Magikeren Mads kan en del om magi, kanskje han har studert andres
formelkasting spesielt eller alle magikere vet litt om slikt, bare spillet
vet hvorfor. Mads sin underbevissthet mottar uansett signalet
"formelkasting underveis". Saa er det opp til implementasjonen av Mads hva
som skal skje videre. Det kan vaere at den finner ut at denne typen
formelkasting er noe Mads ikke kjenner, og i saafall ignoreres signalet.
Hvor mye Mads forstaar kan vaere en funksjon av grad, intelligens, visdom,
proficiencies, formelens natur etc., og systemet kommer frem til hva som
maa vaere Mads sin umiddelbare kunnskap om formelen ut fra alle disse
parametrene. Denne ummiddelbare kunnskapen kan godt vaere helt gal dersom
det legges inn noe randomisering.

Systemet kommuniserer saa denne kunnskapen til klienten iht. en passende
protokoll. Klienten faar vite at "Mads opplever formelkasting av foelgende
natur", kanskje vet han hvem kasteren er, kanskje bare en retning, kanskje
hvilken formel det er eller bare type formel, og muligens er noe av eller
all denne informasjonen gal.

Dette gir Mads sjansen, som en god magiker som vet noe om dette boer ha,
til aa sende avgaarde litt dispel-magi som fungerer mot slikt, noe som kan
vaere "delvis automatisert" (det er grenser for hvor fort en kan
taste/museklikke inn en beskyttelse mot en formelkasting som tar veldig
kort tid)

Jeg synes dette er et godt eksempel paa hvordan signal/slot-mekanismer kan
brukes hensiktsmessig, uten at det trengs aa hardkodes saa mye. Tanken er
at objekter forteller omverdenen hva de gjoer og litt om hvilken del av
omverdenen (spesielt geografisk) som har noen sjanse til aa lese signalet.
De sier hva de _faktisk_ gjoer (internt paa serveren), og saa er det opp
til de som mottar signalet (paa serveren) aa velge hvordan dette paavirker
klienten, der all informasjon som trengs for aa finne ut av dette er
levert med signalet (om ikke annet, hvertfall hvilket objekt en skal
spoerre for aa finne ut av det, f.eks. signalets kilde). Et resultat av
dette kan vaere at objektet paa et eller annet vis endrer seg og/eller at
det sendes informasjon til klienten (som ikke ser den interne sendingen av
signaler paa serversiden).

Hmm... jeg tror jeg nok en gang har klart aa servere masse ustrukturerte
tanker her, forhaapentligvis faar noen noe ut av det. :)



- Tore