Re: [Dlab-devel] WC-Net?

[<jx...@ti...>]

>-- Messaggio originale --
>From: "Lorenzo Stacchini" <lor...@li...>
>To: "Mailing List" <Dla...@li...>
>Subject: Re: [Dlab-devel] WC-Net?
>Date: Sat, 25 May 2002 13:19:44 +0200
>
>
>
>----- Original Message -----
>From: "Duca" <sen...@gm...>
>To: "Mailing List" <Dla...@li...>
>Sent: Friday, May 24, 2002 9:25 PM
>Subject: [Dlab-devel] WC-Net?
>
>
>Senza incasinare troppo le cose potremmo utilizzare un server centrale
che
>gestisce le varie connessioni:
>Add, rm, etc. player (utilizzando magari un UDP un po' pi? incasinato)
>Dopo di che i client si comunicano a vicenda gli eventi:
>player spare, player collide etc.
>sparo del player collide con asteroide = [casino]
>[Quando uno sparo collide con un asteroide, quest'ultimo si divide in 2
>parti con direzioni casuali, le direzioni
>vengono elaborate solo da chi ha generato lo sparo, gli altri attendono(per
>un po') il risultato.]
>
>Il movimento degli asteroidi ? ovvio ogni player se lo calcola da solo.
>
>
>Io l'ho sparata, che ne pensate?
>
>
><<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>
>
>Secondo me potremmo cercare di ridurre al minimo i movimenti casuali,
>sostituendo la generazione delle direzioni degli asteroids con degli
>algoritmi pi? o meno complessi ma di generazione univoca a partire dal
>contesto. Questo potrebbe permetterci di calcolare lato client le divizioni
>degli asteroidz, a questo punto potremmo permetterci di inviare addirittura
>un pacchetto tcp di conferma.
>Generalizzando un po' questo criterio petrebbe andar bene un po' per tutto,
>anche per esempio nei bonus, dove ci sarebbe comunque la necessita' di
dare
>l'impressione della casualit?.

Avevo pensato anche io che la cosa migliore fosse quella di eliminare qualunque
generazione casuale di oggetti, e nel caso specifico dello "spacco" di un
asteroide mi sembra anche l'ipotesi pi? corretta. Il problema secondo me
? che, per rendere il gioco un p? pi? divertente, non ? possibile determinare
tutto a priori: ad esempio, quando inizia un livello, sarebbe meglio che
posizione e velocit? degli asteroidi vengano generati casualmente.

>In pi? ho un'altra idea che mentre scrivevo mi ha frullato in tezta:
>zi potrebbe pensare ad un sistema client che cerca di calcolare il pi?
>possibile da solo gli eventi, memorizzando di volta in volta a tempi fissati
>le posizioni (magari dentro le move()) su una variabile struttura 'globale'
>dentro game (o dove decideremo, non ha importanza). Ogni tanto il server
>mander? dei pacchetti di sincronizzazzione tcp in broadcasting, i client
>controlleranno poi se i loro parametri sono corretti.
>Ancora non ho assolutamente pensato alla fattibilit? dal punto di vizta
>dell'efficenza, inoltre potremmo rischiare che i pacchetti tcp arrivino
>talmente in ritardo da complicarci troppo la vita.
>Comunque questo sistema mi sembra implementabile per lo meno in parte
>usandolo ad intervalli relativamente lunghi.

Dunque, non ho capito bene come dovrebbe funzionare secondo te la cosa,
ma quello che ho capito ? che il problema fondamentale sia quello di determinare,
ad ogni evento, quali oggetti sono in gioco e farli sapere
all'altro client. Non sarebbe meglio concentrarsi su cosa aggiungere all'implementazione
gi? esistente, partendo dal presupposto di utilizzare *solo* l'UDP, piuttosto
che pensare a come intrecciare insieme tra di loro i vari protocolli? Ad
esempio, non si potrebbe usare un campo "ID" in ogni sprite, per far sapere
all'altro client quali siano esattamente i due oggetti che si sono scontrati:
magari potremmo anche utilizzare una struttura dati (tipo una tabella hash,
che sia la stessa per tutti i client) che contenga i puntatori a tutti gli
oggetti, e che in base all'ID si possa accedere al puntatore all'oggetto
direttamente?

Ciao,
Cecco