Tesina Applicazioni Telematiche
Quiz Multi-utente web-based
Studenti:
Pasquale Di Rienzo
Bartolomeo Ovilio
Roberto Pascale
Analisi dei requisiti
Obiettivo principale di questo progetto è lo sviluppo di
un’applicativo (sia client che server) che realizzi un quiz
multiutente. Oltre alla funzione di base si vuole offrire anche
la possibilità di scambiare flussi multimediali in tempo reale
(audio/video, testo).
Non meno importante la possibilità di usufruire lato client
dell’applicativo su una qualsiasi piattaforma e senza necessità di
dover installare alcun programma.
Casi d’uso
Lato client:
Il client deve poter innanzitutto avere la possibilità di registrare un
proprio account di gioco presso il server ed effettuare la procedura di
login. Inoltre deve poter scegliere un proprio avatar che lo
rappresenterà all’interno del gioco (immagine o video dalla web-cam) e
deve poter decidere se condividere la propria voce. Una volta
autenticato, l’utente dovrà avere la possibilità di scegliere fra più
stanze di gioco, e avere la possibilità di scambiare messaggi testuali.
Lato server:
L’amministratore del gioco dovrà avere la possibilità di configurare a
suo piacimento alcune impostazioni di gioco: stanze, scelta numero di
rounds, scelta numero di concorrenti per stanza.
Inoltre deve avere la possibilità di gestire le impostazioni relative al
database contenente le domande: aggiunta/rimozione domande, scelta
tra almeno due diversi DBMS.
Casi d’uso: schermata iniziale gioco
Casi d’uso: dopo il login
Casi d’uso: amministratore
Tecnologie utilizzate(1/2)
• Adobe Flash
• Openfire
• Red5 Flash Server
Protocolli in gioco
• HTTP
• XMPP
• RTMP
Tecnologie utilizzate(2/2)
Per quanto riguarda il formato di scambio dei messaggi (sia per la chat,
sia per il gioco) è stato scelto il protocollo XMPP, per via della sua
facile estendibilità e della sua diffusione grazie alla quale è facile
reperire tecnologie a suo supporto.
Avendo fissato la scelta del protocollo, si è deciso di utilizzare
Openfire per sviluppare l’applicativo lato server, che quindi ha assunto
la forma di un plugin.
Per la realizzazione della parte client dell’applicativo la scelta è
ricaduta sulla tecnologia Flash di Adobe, largamente diffusa e ormai
supportata da qualsiasi browser, eliminando la necessità di
installazione del programma da parte degli utenti.
Adobe ci ha anche fornito i mezzi per lo streaming audio/video
mediante il protocollo RTMP, divenuto ormai uno standard de facto.
Come server di streaming abbiamo optato per il server Red5, presente
sotto forma di plugin per il server Openfire (non è stato quindi
necessario installare due server diversi sulla stessa macchina).
Messaggi scambiati
Come accennato è stato necessario estendere XMPP per introdurre messaggi
ad hoc per la logica del gioco. Si è agito su due fronti: da una parte si sono usati
i messaggi IQ per l’interazione con il server di gioco, dall’altra si è deciso di
estendere anche i messaggi di presenza introducendovi informazioni di stato
prettamente relative al gioco.
Le estensioni definite sono tre:
• Game: per i pacchetti IQ, relativi ai messaggi scambiati durante il gioco (invio
domanda da parte del server, relativa risposta da parte del client, e richiesta
di partecipare a una partita)
• GameInfo: per i pacchetti IQ, contenenti informazioni sul numero di stanze e
sul numero di giocatori ivi presenti.
• GamePresence: per i pacchetti Presence, usati dai giocatori per scambiarsi
informazioni di stato: scelta dell’avatar utilizzato, stato di gioco (ready /not
ready).
Esempio:GamePresence
Progettazione server-side
XMPP
GameInfo
Handler
Game
Database
Game
Handler
GameMaster
Flash Client
Ruoli dei componenti server-side
GameHandler:
Questo componente si occupa di intercettare i pacchetti XMPP inviati dai client relativi al
gioco. Al suo interno conserva riferimenti a oggetti di tipo GameMaster, svolgendo la
funzione di “dispatcher”: ogni volta che riceve dei msg dai client, per una determinata stanza
di gioco, si occuperà di inoltrarli al GameMaster responsabile. Inoltre inizializza la
connessione al Database attraverso il componente GameData.
GameMaster:
Rappresenta il gestore della stanza di gioco. Esso viene eseguito come Thread, in modo che
più GameMaster (e quindi più stanze di gioco) possono essere attivi contemporaneamente .
Racchiude i metodi di gestione della logica del gioco, effettuando interazioni con il
componente GameDatabase al fine di ottenere le domande da presentare ai client.
GameDatabase:
E’ il componente che rappresenta il wrapper del database utilizzato per immagazzinare le
domande relative al quiz. Mette a disposizione dunque i metodi di
connessione/disconnessione al database, e metodi per effettuare interrogazioni su di esso.
GameInfoHandler:
Questo componente si occupa di intercettare i messaggi inviati dai client relativi alle
richieste di informazioni sul gioco. Tali richieste rappresentano la volontà dei client di
sottoscriversi a ricevere aggiornamenti sullo stato delle stanze di gioco (il numero di
partecipanti per stanza).
Init:
Questa classe rappresenta il Plugin del gioco . Presenta il metodo “initializePlugin” che viene
invocato all’avvio del server. Essa ha il compito di istanziare tutti gli altri componenti.
Altri componenti
Player:
E’ la struttura dati utilizzata per mantenere le informazioni relative ai giocatori (id,
username).
Domanda:
E’ la struttura dati utilizzata per mantenere informazioni relative alle domande del quiz.
Result:
E’ la struttura dati utilizzata per mantenere informazioni relative ai messaggi di risposta alle
domande del quiz (numero di risposta, tempo impiegato ecc.)
Console Amministratore
L’aggiunta/rimozione delle stanze è una caratteristica già presente in Openfire, quindi non c’è
stato bisogno di implementarla. L’unico accorgimento è quello di creare un servizio apposito
chiamato “game”, in modo da separare le normali stanze di chat da quelle adibite al gioco.
Per quanto riguarda la configurazione dei parametri (di gioco e del database) si è utilizzata la
tecnologia delle JSP per aggiungere sezioni di setting alla console dell’amministratore. Ogni
parametro è rappresentato attraverso le variabili d’ambiente di Openfire chiamate JiveGlobals.
Grazie ad esse è possibile modificare alcuni aspetti senza dover ricompilare i sorgenti.
Progettazione client side
Il lato client è stato scritto in ActionScript, in particolare si sono rivelate utili le
API XIFF per quanto riguarda la comunicazione XMPP con il server di gioco.
Il client stabilisce due connessioni persistenti con il server:
•Una connessione XMPP sulla quale vengono scambiati i messaggi di gioco.
•Una connessione RTMP sulla quale avviene lo scambio di flussi multimediali.
In alcuni scenari (download swf, registrazione ecc.) viene stabilita anche una
connessione HTTP .
HTTP
XMPP(Xiff)
RTMP
Scenari di interazione
Scenario “Registrazione account”
L’utente preme il
tasto Registra
Quando l'utente edita il campo Username, viene inviata una richiesta Http asincrona al
server Openfire. Tale richiesta attiva una servlet che controlla se lo username è già stato
registrato in precedenza o meno, restituendo l’esito al client.
Scenari di interazione
Scenario “Login”
Scenario considerato : I server accettano con successo le richieste di connessione
Scenari di interazione
Scenario “Utente vuole partecipare al gioco”
In caso di risposta affermativa l’utente invierà un messaggio di presence alla stanza in cui
comunicherà il suo nuovo stato di ready a tutti gli altri partecipanti.
Se l’utente decide di non voler più partecipare invia un messaggio di tipo “Cancel” (cliccando
sull’apposito tasto).
Scenari di interazione
Scenario “Utente risponde a una domanda”
L’utente preme un
tasto risposta
Alla fine dei round, il server invierà un ulteriore messaggio contenente il vincitore finale (ovvero
il giocatore che ha totalizzato il maggior numero di risposte esatte).