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 unapplicativo (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 dellapplicativo su una qualsiasi piattaforma e senza necessità di dover installare alcun programma.

Casi duso 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à allinterno del gioco (immagine o video dalla web-cam) e deve poter decidere se condividere la propria voce. Una volta autenticato, lutente dovrà avere la possibilità di scegliere fra più stanze di gioco, e avere la possibilità di scambiare messaggi testuali. Lato server: Lamministratore 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 duso: schermata iniziale gioco

Casi duso: dopo il login

Casi duso: 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 lapplicativo lato server, che quindi ha assunto la forma di un plugin. Per la realizzazione della parte client dellapplicativo 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 linterazione con il server di gioco, dallaltra 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 dellavatar utilizzato, stato di gioco (ready /not ready).

Esempio:GamePresence

Progettazione server-side Flash Client XMPP Game Handler GameInfo Handler GameMaster Game Database

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 allavvio 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 Laggiunta/rimozione delle stanze è una caratteristica già presente in Openfire, quindi non cè stato bisogno di implementarla. Lunico 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 dellamministratore. Ogni parametro è rappresentato attraverso le variabili dambiente di Openfire chiamate JiveGlobals. Grazie ad esse è possibile modificare alcuni aspetti senza dover ricompilare i sorgenti.

Progettazione client side XMPP(Xiff) RTMP RTMP 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

Scenari di interazione Scenario Registrazione account Lutente 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 lesito 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 lutente invierà un messaggio di presence alla stanza in cui comunicherà il suo nuovo stato di ready a tutti gli altri partecipanti. Se lutente decide di non voler più partecipare invia un messaggio di tipo Cancel (cliccando sullapposito tasto).

Scenari di interazione Scenario Utente risponde a una domanda Lutente 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).