|
From: Bernardo I. <be...@de...> - 2002-05-22 02:28:29
|
Ragazzi,
sto pensando un po' a come risolvere i problemi di design per il network
game.
Visto che neanche io ho le idee chiare e visto che oggi mi e' sembrato
che l'argomento
vi interessi molto, pensavo di inziare una discussione tecnica sulla
mailing list.
Sono aperto a qualsiasi proposta purche' sia RAGIONATA, e BEN ESPOSTA.
I requisiti sono:
- possibilita' di giocare la STESSA partita in 2 o piu' giocatori su
computer diversi;
- funzionamento in LAN o in Internet, mantenendo un certo grado di
giocabilita'
nonstante la latenza tipica di una connessione dial-up (100-300ms).
- non e' specificato se il protocollo debba essere simmetrico (peer to
peer) oppure
asimmetrico (client-server);
La soluzione ideale avrebbe le seguenti caratteristiche:
- e' attuabile con il minimo stravolgimento possibile nel codice attuale;
- non richiede la scrittura di un server dedicato, ma sfrutta l'attuale
eseguibile
anche come server;
- e' implementabile in un tempo accettabile (< 2mesi) con conoscenze di
networking basilari;
- e' tollerante alla perdita di pacchetti e all'aumento improvviso
della latenza da
parte di un giocatore;
- richiede una banda passante ragionevole per i client (<= 5KB/s);
- e' scalabile anche ad un gran numero di client (diciamo fino a 10);
- e' accompagnata da un'analisi completa dell'impatto sul codice
attuale e delle
parti che dovrebbero essere modificate o riscritte per implementarla.
Mi sembra che i seguenti vincoli si possano considerare gia' fissati a
priori:
- Useremo l'UDP perche' le caratteristiche del TCP sono di intralcio
alle prestazioni real-time richieste dalla nostra applicazione;
- Non possiamo permetterci di scrivere un server che duplica il codice
gia' scritto nelle move() di tutti gli sprite (ci vuole tempo e fatica);
- O troviamo un modo furbissimo di mantenere sincronizzato lo stato del
gioco in tutti i client senza un'autorita' centrale, oppure dobbiamo far
muovere tutti gli oggetti al server e avere dei client molto
passivi. Nel
primo caso dovremmo trovare un modo furbissimo per sincronizzare
i generatori di numeri casuali che usiamo attualmente nelle move()
degli sprite, ma probabilmente e' troppo complicato;
- Per dare un'illusione di fluidita' anche con latenza elevata,
probabilmente
dovremo interpolare la posizione degli sprite nel lasso di tempo che
intercorre tra i pacchetti (difficile... ma non si puo' farne a meno).
- Forse per ridurre la complessita' del codice dovremo accontentarci di
giocare in LAN e rinunciare ad implementare il network game via
Internet.
Per favore, non discutiamone in classe... lasciamo che la discussione prenda
corpo sulla mailing list perche' e' necessario pensare a lungo prima di fare
una proposta, altrimenti la discussione rischia di essere superflua e
non basata
su fatti reali;
|