TypeChallenge Specifiche

Da PtLUG Wiki.

Il gioco prevede (per ora) tre modalità:

* single player
* multiplayer cooperativo
* multiplayer tutti contro tutti

E' previsto il supporto per altri tipi di modalità (a squadre, chi raggiunge prima un certo punteggio, etc.).

1 Descrizione
2 Architettura
3 Miscellanea
4 Riferimenti

[edit]

Descrizione

In modo single player il giocatore deve digitare le parole che appaiono sullo schermo il più velocemente possibile. Le parole scorrono da un lato all'altro dello schermo, quando toccano il lato opposto scompaiono e la parola si dice persa. Un giocatore può perdere al massimo 3 parole. Più resiste e maggiore è il punteggio.

In modo multiplayer cooperativo tutti i giocatori formano un'unica squadra, vedono le stesse parole e cooperano per durare il più possibile. Quando una squadra perde 3 parole il gioco termina.

EDIT: direi che la cosa migliore per il multiplayer cooperativo è: - sui client non si hanno le stesse parole (problemi di sincronia nel caso due giocatori scrivano la stessa) - i giocatori hanno vite separate - secondo me più divertente. - (come effetto secondario si ha che le necessità di sincronizzazione sono meno stringenti)

In modo multiplayer tutti contro tutti ogni giocatore mira a rimanere l'ultimo in campo. Quando un giocatore scrive correttamente una parola, questa viene inviata negli schermi degli altri giocatori (eventualmente con una certa probabilità < 1, in modo che sia possibile gestire gli handicap in caso di giocatori con diverse abilità). Ogni giocatore può perdere al massimo 3 parole, poi viene eliminato. Vince chi resta in campo per ultimo.

Una volta iniziata una partita multiplayer, i nuovi giocatori devono attendere la fine del round prima di poter partecipare.

Le partite multiplayer si sviluppano su internet o rete locale. In ogni caso l'obiettivo è usare meno banda possibile.

[edit]

Architettura

Il gioco ha architettura client server.

Il server di gioco: - accetta le connessioni da parte dei client, - invia le parole da scrivere, - riceve dai client le parole scritte dai giocatori - applica la logica di gioco (invia le parole scritte nei campi avversari [scontro] o informa i client che una certa parola è stata scritta e va eliminata [cooperativo] - tiene traccia dei punteggi dei giocatori e delle loro performance

Ogni client: - visualizza lo stato del gioco (possono esserci più front end, es. ncurses gtk, sdl etc.) - seleziona la modalità di gioco - si collega al server - visualizza le parole spedite dal server - gestisce l'input dell'utente - invia al server gli aggiornamenti (parole completate, parole perse)

[edit]

Messaggi

Il client e il server comunicano mediante l'uso di messaggi. I messaggi trasmettono i cambiamenti di stato del gioco: ad esempio, un messaggio client -> server è "il giocatore ha perso la parola xyz" oppure "il giocatore ha scritto la parola uvw". Esempi di messaggi server -> client sono: "prossima parola: abc" oppure "in attesa del segnale ready da tutti i giocatori".

Credo che il modo migliore per caratterizzare le interazioni fra server e client sia tramite macchine a stati.

[edit]

Stati nel client

Voglio ricordarvi che non ho mai programmato niente in rete, quindi potrebbero mancare molte cose, specie nella gestione degli errori (che per quel che so è parecchio difficile).

Ok, questo dovrebbe essere ascii art che rappresenta le transizioni di stati...se modificate la pagina vedrete come dovrebbe essere visualizzato (non ho avuto tempo di fare un'immagine per bene, sorry).

IDLE: l'utente ha lanciato il client e deve ancora selezionare la modalità di gioco

connect: il client tenta di connettersi al server di gioco (in tutte le modalità abbiamo un server, sì, anche in single player).

WAITFOR_SERVER_RESPONSE: attende che il server risponda. In caso contrario torna ad IDLE (magari si è sbagliato l'indirizzo del server, oppure il server non può accettare altre connessioni)

server_ready: il server c'è ed è pronto per accettare un nuovo client.

WAITFOR_GAME_END: il client appena connesso deve attendere la fine del gioco in corso. Nel frattempo si può dilettare studiando gli avversari attraverso le statistiche sul gioco in corso inviate dal server. Anche i giocatori che nel gioco in corso sono stati eliminati devono attendere che il gioco finisca.

game_end: il segnale di fine gioco, inviato dal server ai client

INIT_GAME: il client resetta il suo stato e attende istruzioni dal server relative al nuovo gioco; il server potrebbe decidere di cambiare modalità di gioco (da cooperativo a squadre a tutti contro tutti, cambiare le squadre, aggiungere giocatori etc.)

game_init: il server invia le specifiche della prossima partita

WAITFOR_PLAYER_READY: il client attende che il giocatore dia il segnale di ok per l'inizio del gioco.

player_ready: il client invia al server il segnale di ok

WAITFOR_GAME_START: attende il segnale di game_start dal server (che viene inviato quando tutti i giocatori sono pronti).

player_not_ready: il giocatore (per qualsiasi motivo) non è più pronto. Il client invia al server la notifica (che viene ingnorata dal server se è già stato inviato il segnale di game_start) e ritorna allo stato WAITFOR_PLAYER_READY. (? è utile una funzione del genere?) Tra l'altro questo aggiunge una condizione di errore in più da gestire, per essere sicuri che il server abbia capito (e che non abbia già inviato game_running) dobbiamo aspettare una risposta: ad esempio player_not_ready nel caso in cui il server accetti che il client torni indietro di stato oppure game_start nel caso in cui il server abbia già inviato game_start. In breve, direi eliminiamo la possibilità di fare i "ringamboni". :)

game_start: segnale di inizio gioco

GAME_RUNNING: logica di gioco. 1. Il server invia la parola da scrivere, 2. il client la visualizza, 3. il client riceve l'input dall'utente (nel frattempo registrando le statistiche sul giocatore come numero di errori, velocità di battitura etc.), 4. quando il giocatore scrive una parola correttamente invia una notifica al server, 5. quando il giocatore perde una parola invia una notifica al server,

player_out: il giocatore ha perso troppe parole e viene eliminato dal gioco. Il client passa allo stato WAITFOR_GAME_END.

[edit]

Stati nel server

BOH!!

[edit]

Miscellanea

Per la sincronizzazione facciamo la cosa più semplice: usiamo un timestamp dato dal tempo di sistema Unix. Prima di iniziare la partita, il server chiede a tutti i client il timestamp; in seguito ogni pacchetto contiene il timestamp attuale. Così possiamo sapere chi effettivamente ha digitato per prima la parola.

Insieme alla parola, il server invia al client un'informazione sul tempo di visualizzazione della parola, per gestire la difficoltà.

[edit]