abstract
He had a vision: Un ambiente che riproduce battaglie spaziali, mondi galattici e mostruose tecnologie. Un universo di scoperte e avventure, dove ogni persona del globo (e non?) può immergersi ed entrare a far parte di questo mondo.
Come? Creando un videogioco online, che offra la possibilità di interfacciarsi su questo mondo, il cui server è in grado di scaricare (nel caso sia necessario) la computazione del lavoro sui client stessi, con tecnologie grid.Realizzare il progetto tramite le conoscenze acquisite durante il corso di Sistemi Distribuiti creando, quindi, un sistema a computazione grid e uno di un videogioco legati tra di loro (due progetti in uno):
GameSystem (Videogioco) e
DroneSystem (Rete computazionale)Questo sistema dovrà:
- Fornire una interfaccia che consente a coloro che desiderano sfruttare il calcolo distribuito di realizzare il loro desiderio;
- Comporsi di un'alcova che detiene l'elenco di algoritmi disponibili (e condividerla con i Droni);
- Fornire ad ogni Drone la possibilità di registrarsi opportunamente al server per poter ricevere commissioni;
Ogni
Drone che desidera contribuire al sistema di computazione, deve registrarsi opportunamente al server e avere un alcova di algoritmi, ovvero dovrà avere "l'intelligenza" necessaria a risolvere i problemi che gli verranno posti. Quando sarà necessario eseguire una operazione complessa, questa operazione verrà delegata ad un
AdminComputation tramite il binomio di
algoritmo/input: egli si ritroverà, dunque, a dover risolvere un problema di cui ha l'input ed il meccanismo risolutivo. L'AdminComputation dovrà procedere "spezzando" l'input in diverse parti e darli in pasto al
Dispatcher, il quale invia ogni input ai
Droni, delegando a loro la risoluzione. Ogni
Drone invia al Dispatcher le sue soluzioni, le quali verranno poi restituite all'
AdminComputation. L'
AdminComputation riceverà mano a mano gli output agli input che aveva precedentemente generato;
quando saranno presenti tutti gli output sarà in grado, quindi, di ricomporre l'output totale e di restituirlo.
Nota: Da come si sarà potuto intuire, gli algoritmi possono offrire la disponibilità a spezzare l'input per garantire una maggiore parallelizzazione del lavoro!
- Drone: Cliente sfruttato dal server per eseguire le computazioni;
- Alcove: Collezione di Algorithm, rappresenta "l'elenco delle operazioni" che offre il sistema;
- Dispatcher: Componente del server che gestisce l'interfaccia con i Droni, ovvero si occupa della loro registrazione, di distribuire i compiti e raccogliere i risultati;
- Admin Computation: Componente del server che offre una interfaccia in grado di realizzare complessi algoritmi dell'Alcove basandosi sul Dispatcher;
- Algorithm: Rappresenta una operazione resa disponibile dal sistema.
Questo sistema dovrà:
- Fornire la possibilità ad un giocatore di iniziare o smettere di giocare;
- Fornire ad ogni giocatore la propria nave (personalizzabile nel corso del gioco) accessibile durante il processo di login al sistema;
- Supportare la possibilità di muoversi nell'universo per spostarsi da una zona all'altra;
- Comporre ogni zona con Arcade ed Utilità;
- Poggiare sul DroneSystem per realizzare i calcoli più pesanti (Diramazione IA di NPC, calcoli impatto degli scudi...).
Ogni giocatore avrà la sua astronave e potrà usarla per esplorare l'universo e le zone presenti, muovendosi in territori condivisi con altri giocatori, dove potrà potenziare la sua tecnologia ed addentrarsi in nuove avventure: "fino ad arrivare laddove nessun uomo è mai giunto prima".Un giocatore deve avere una password ed un nome utente per eseguire l'accesso al server di gioco. Il client ed il server comunicano tra di loro utilizzando un
WarpCoreTen: una collezione di informazioni condivisa tra il server ed il client suddivisa in
Mosse,
Caratteristiche e
Modifiche.Quando il client si connette al server, quindi, si creerà un
WarpCoreTen condiviso tra loro che il server popolerà di Caratteristiche rappresentanti i dati del client (la sua astronave, la sua posizione...). Il client dovrà essere dotato di un
GraphicSystem che permetta di: visualizzare le Caratteristiche di gioco che sono contenute nel
WarpCoreTen e fornire una interfaccia all'utente per agire.Quando l'utente agisce (si muove, usa un potere...), il
GrahpicSystem creerà una entità
Mossa che rappresenta l'azione del giocatore e verrà messa nel
WarpCoreTen, la quale verrà prelevata dal server e consegnata alla Fisica. La
Fisica calcola l'effetto della
Mossa che gli è stata fornita producendo un effetto (
Modifica): questo effetto cambierà il contenuto delle caratteristiche del
WarpCoreTen ed aggiungerà se stesso alle
Modifiche del
WarpCoreTen. Il
GraphicSystem leggerà la
Modifica, aggiornando le sue
Caratteristiche e, quindi, comunicando indirettamente all'utente il risultato del suo agire.
- WarpCoreTen: Rappresenta una entità che rappresenta una struttura di dati utilizzata per la comunicazione tra il Client ed il Server, ovvero una collezione di informazioni che tende ad essere consistente tra il client ed il server. Un WarpCoreTen è composto da Mosse, Caratteristiche e Modifiche.
- Mossa: Tipo di entità del WarpCoreTen che rappresenta il desiderio del giocatore di compiere una azione. (Ad esempio il desiderio di muoversi).
- Caratteristica: Tipo di entità del WarpCoreTen che rappresenta una informazione sullo stato reale del gioco: tende ad essere consistente. (Ad esempio la posizione di un giocatore in un certo momento rispetto all'universo, è una caratteristica perché è una informazione che deve essere consistente nel sistema).
- Modifica: Tipo di entità del WarpCoreTen che rappresenta un cambiamento avvenuto in una caratteristica. (Ad esempio il fatto che la mia posizione sia cambiata)
- Client: Abusando di linguaggio, rappresenta un componente del client del sistema, che si occupa di gestire i WarpCoreTen e di fare in modo che le sue caratteristiche siano consistenti con il server.
- Server: Abusando di linguaggio, rappresenta un componente del server, che si occupa di gestire i WarpCoreTen e di fare in modo che le sue caratteristiche siano consistenti con i client interessati.
- GraphicSystem: Componente del client che si interfaccia con il motore grafico, in grado di ricevere le Mosse del giocatore, e mostrare Caratteristiche, e quindi necessariamente anche Modifiche. (Produce azioni e riceve conseguenze)
- Fisica: Componente del server che riceve Mosse e produce Modifiche. (Riceve azioni e produce conseguenze)
- Problema di gestione della Grid per il dispatch delle deleghe (Problema complesso)
- Problema di suddividere gli input e ricostruire gli output (Problema potenzialmente molto complesso nel caso in cui si accettano algoritmi dinamicamente, ma assumendo la presenza dell'alcova diventa un problema di media difficoltà)
- Problema di fornire ai droni la capacità di risolvere i problemi posti (Non si prevede una difficile soluzione)
- Problema di rendere il WarpCoreTen sincronizzato con il server (Il re dei problemi)
- Problema di gestione della Fisica / smistamento delle Mosse da eseguire (La difficoltà è proporzionale a quanto il gioco dovrà essere realistico)
- Problema di gestione del GrahpicSystem / smistamento delle Modifiche (Si farà affidamento ad un motore grafico esterno al sistema, ma la sua configurazione e coordinazione sarà abbastanza complesso)
- Problema di Login System (Assumendo il problema del WarpCoreTen risolto, la difficoltà è bassa)
L'alcova dovrà essere disponibile per ogni drone, quindi si assume che ogni drone ne sia dotato, potremmo addirittura estendere la definizione di Drone in "Cliente
dotato dell'alcova sfruttato dal server per eseguire le computazioni". L'alcova colleziona algorithm i quali devono essere individuabili in modo univoco all'interno, appunto, dell'alcova. L'agorithm è una entità che dovrebbe:
- Ricevere un input e restiuire un output;
- Rompere un input in una collezione di input che insieme sono equivalenti all'input sorgente;
- Ricomporre gli output di un input che è stato precedentemente suddiviso nell'output totale. L'azione di ricomposizione dei dati è stato definito viniculum.
Nota critica: è necessario che se ho un input A che produce B, allora se suddivido A in SplittedA() di lunghezza X dovrò necessariamente ricevere SplittedB() di lunghezza X per poter ricomporre B.E' corretto pensare che non tutti i problemi siano facilmente suddivisibili, quindi un algorithm può evitare di rendere disponibile la possibilità di dividere l'input e obbligare a mantenerlo compatto. Quindi ne deduciamo che è algorithm chiunque offra il punto 1, mentre è facoltativo che implementi o fornisca limitazioni alla 2 e alla 3.
- Concierge: è colui che si interfaccia direttamente con i droni, offre infatti la possibilità di:
- Registrarsi al sistema: il drone verrà inserito nella grid e gli verrà fornito un identificativo.
- Ricevere gli output dei droni e fornire problemi da risolvere.
- LinkedDrone: Rappresenta un drone registrato, con tutte le informazioni necessarie per individuarlo in caso di necessità e con un riferimento al suo stato, ovvero se è in attesa di lavoro oppure su che problema sta lavorando.
- DroneSet: La collezione di LinkedDroni
- DroneManager: L'entità incaricata di gestire i droni: a fronte di un problema da eseguire il DroneManager sarà in grado di indirizzare il problema sui droni corretti (ricerca chi è in idle, tecniche di priorità, statistiche sulla velocità: tantissimi modi!)
- Dispatcher: Si avvale del DroneManager per distribuire le operazioni.
- Question: Rappresenta un compito, una missione da affidare ad un Drone: è composta da un Input, dall'Algorithm e da un Output.
- QuestionManager: L'entità che colleziona le Question, colui che conosce a quali question sono state risolte (l'output non è vuoto), quelle ancora da risolvere...
Tirando le somme, un Drone si registrerà tramite il Concierge con un messaggio di register, questo provocherà la creazione di un LinkedDrone ed il suo inserimento nel DroneSet: questo significa che potrebbe essere nominato per eseguire compiti, infatti dopo il register il Drone resterà in attesa. Quando il Dispatcher consegnerà una Question al Drone, lui inizierà a computare; a termine del lavoro darà al Concierge l'output e tornerà in attesa. Il Concierge markerà la question come risolta associando l'output della Question che ha ricevuto risposta all'oggetto ricevuto dal drone.
- NeuralInterface: Il termine partorito dalla tecnologia Borg per definire l'interfaccia con ogni tecnologia Borg da un sistema biologico neurale, è stato adottato per definire l'interfaccia usata per accedere al nostro sistema di computazione. Questa entità è l'apice del sistema: colei che fornisce l'illusione di una computazione atomica accettando un input ed un algoritmo e restituendo l'output. Questa entità è incaricata di eseguire l'eventuale suddivisione degli input preparando le Question dei droni e consegnarle al QuestionManager (da Dispatcher).
- Collector: Colui che viene notificato dal Dispatcher (dal Congierge) quando un Drone finisce di computare la sua Question. Il suo compito sarà quello di eseguire il viniculum degli output e notificare la NeuralInterface quando un Output completo sarà pronto per essere fornito all'utente della Grid.
- Queen: Regina dei Droni. Risiede nell'Admin Computation ed esegue tutte le Question in coda nel QuestionManager indipendentemente dal fatto che il lavoro sia stato già commissionato ad un Drone o no. La regina, quindi:
- Assicura una risoluzione di ogni computazione anche senza la presenza di droni, impersonando lei stessa l'unico drone;
- Risolve le Question già inviate a Droni che potrebbero risultare molto lenti o soggetti a problemi;
- Il suo lavoro è assolutamente inutile in un DroneSystem ideale, ma potrebbe portare grossi vantaggi in un ambiente reale.
Lo schema dell'interazione del
Drone definiscono in modo consistente e soddisfacente quanto è stato descritto.
Il WarpCoreTen è nato con l'idea di dover fare in modo che ogni giocatore debba avere una idea del mondo a lui circostante e di se stesso esattamente come ogni altro player. Se il giocatore A esegue una azione nel mondo, allora avrà un effetto nella Fisica e questo effetto cambia l'ambiente in modo totalmente imprevedibile e questo nuovo ambiente dovrà essere esattamente quello di A e di ogni altro player B, C o D che sia. Per risolvere questo problema
assumeremo la Fisica come un misterioso ed estremamente pericoloso BlackBox: non esistono azioni grosse o piccole (ci si potrebbe muovere sopra una stazione occultata, quello che per il giocatore era una "mossa piccola" può portare alla sua più disastrosa distruzione).Abbiamo alcune certezze:
- Il GrahpicSystem produce una mossa che è consistente con la sua idea dell'ambiente (dette caratteristiche);
- La Fisica riceve una mossa e produce una modifica; il side-effect di questa produzione sarà che le caratteristiche saranno cambiate in base all'istanza di modifica prodotta;
- Dato un evento d'azione della Fisica, si ha che applicando alle caratteristiche prima di quell'evento le modifiche prodotte dall'evento, si otterranno le caratteristiche dopo l'evento.
Un WarpCoreTen è una composizione di Mosse, Modifiche e Caratteristiche.
Cioè che è importante è che le caratteristiche del WarpCoreTen del server deve essere consistente con le caratteristiche del WarpCoreTen del client. Introduciamo le entità:
- WarpCoreTenEntry: Come i granelli compongono la spiaggia, un WarpCoreTenEntry compone il WarpCoreTen. Esite solo un tipo di WarpCoreTenEntry, ma esistono diversi modi di interpretarlo: ci possono essere WarpCoreTenEntry che identificano un elemento delle caratterische, delle mosse o delle modifiche, sono composti da un nome (per identificarlo) e da un oggetto (il significato).
- WarpCoreTen: E' una collezione di WarpCoreTenEntry, ma suddivise in sezioni: Quelle che compongono le Mosse, Caratteristiche e Modifiche.
- WarpCoreTenManager: (Schema esplicativo)
- Lato client: Se sono presenti Mosse, (e se scade un timeout di consistenza) invia al WarpCoreTenManager lato server le Mosse, tornando con un elenco di Modifiche. Questo provocherà lo svuotamento delle Mosse (l'invio al sever significa la loro risoluzione) e lo svuotamento delle Modifiche dopo averle applicate alle Caratteristiche (applicando le Modifiche si otterranno Caratteristiche consistenti con il server!)
- Lato server: Quando arrivano nuove Mosse le mette nel WarpCoreTen e risponde con le Modifiche. Rispondere con una Modifica, significa applicarla sul client: ogni Modifica inviata verrà rimossa in quanto non sarà più corretto il fatto di definirla "Modifica" se è già applicata!
Dov'è la Fisica in tutto ciò? Essendo una BlackBox passiva, ci sarà qualcuno: un
Fantasmino. Il Fantasmino è una entità lato server che raccoglie tutte le Mosse dal WarpCoreTen e le recapita alla Fisica (
FantasminoUp).
.La Fisica è una collezione di
Action-Reaction. Un Action-Reaction accetta una mossa e produce una modifica. Per ogni gruppo di Mosse è assegnato un Action-Reaction (Ad esempio, per muoversi (Mossa) è associato il movimento (Action-Reaction)). Un Action-Reaction deve:
- Essere in grado di affermare se è associata ad una mossa oppure no.
- Accettare una mossa e produrre la modifica.
Per poter produrre correttamente le modifiche, una Action-Reaction deve essere aggregata da caratteristiche (ovvero la rappresentazione dell'ambiente in cui la Mossa da eseguire avviene). Quando la Fisica riceverà una Mossa, individuerà il corretto Action-Reaction da innescare e lo innescherà rendendogli disponibile l'accesso alle Caratteristiche (
Come illustrato).
Nota: Le Action-Reaction dovranno venire definite in futuro: durante la fase in cui sceglieremo in modo definito le dinamiche del gioco, assumendo il ruolo non di Analisti ma di puri "fornitori di vincoli" ai GameMaster.Alcove rappresenta la conscenza comune fra client e server sia del GameSystem che del DroneSystem. In particolare l'Alcove del GameSystem conterrà:
- Data: ovvero dati comuni interpretabili da client e server.
- Modifica: rappresentazione di un risultato di una azione computata dal server.
- Mossa: azione compiuta dal client, che deve essere computata dal server.
Mentre l'Alcove del DroneSystem conterrà:
- Algorithm: rappresentazione di un algoritmo eseguibile dal DroneSystem.
Per progettare il GameSystem, innanzitutto si è partito immaginando il gioco da creare: un videogioco di Star Trek, basato concettualmente su uno stile di gioco simile a Dungeons&Dragons. Abbiamo creato un gioco in cui si inizia in un Universe, composto da Zones. Nelle Zones (ad esempio: pianeti, nebulose, ecc..) è possibile viaggiarci ed entrarci. Una volta all'interno della Zone, è possibile se si hanno i requisiti giusti, osservare gli altri giocatori all'interno della Zone, leggere delle Information (Info), utilizzare delle Utility (
Purtroppo non implementato) ed entrare negli Arcades (
Purtroppo non implementato). All'interno di un Arcades è possibile muoversi guardando dall'alto la propria navicella, effettuare varie azioni e combattere con altri giocatori o con NPC. Per motivi anti-hack e per controllare al massimo il comportamento dei singoli giocatori, si vuole dare ai client la minima iniziativa possibile. Questo comporta costruire dei client che reagiscono agli input dell'utente interrogando il server e ricevendo il risultato delle loro azioni. Per svincolare inoltre la coscienza del client di stare parlando con un server, si è progettato un sistema, chiamato Warp Core Ten, in grado di accettare delle mosse e di mettere a disposizione dati e modifiche. In questo modo il client mette delle mosse nel WCT (Warp Core Ten) e continua il suo lavoro. Poi riceverà delle modifiche o dei dati da applicare al gioco, ma senza una implementazione a domanda / risposta. A questo punto si può il GameSystem in 4 parti distinte
- Un GraphycSystem, in grado di fornire l'interfaccia verso l'utente, sia input che output. Insomma è la finestra di gioco in grado di visualizzare graficamente l'ambiente e di prelevare gli input da mouse, tastiera, joystic...
- Un Coffee, ovvero un sistema sia in grado di interpretare gli input dell'utente e di trasformarli in dati comprensibili da Physic, che di interpretare gli input di Physic e di trasformali in risultati grafici visibili all'utente applicandoli al GraphicSystem. Nel gergo del progetto, Coffee deve trasformare i desideri dell'utente che agisce attraverso il GraphicSystem in Mosse, inviarle a Physic e ricevere Data e Modifiche per applicarli in risultati visibili sul GraphicSystem.
- Un Physic, la fisica del sistema, in grado di gestire i player che si collegano al gioco, decidere quali dati inviargli e come reagire alle Mosse dei player, rispondendo tramite Modifiche. Le Modifiche dovranno essere gli strumenti con i quali i Data lato fisica vengono sincronizzati con i Data lato coffee.
- Un Warp Core Ten, ovvero un sistema in grado di permettere l'invio di dati senza che gli estremi abbiano coscienza di stare trasmettendo o ricevendo dati.
Il GraphycSystem deve gestire il boundary completo: input e output. Ai fini del gioco sono stati individuati questi package
- GameElement: semplici elementi, contenenti un certo quantitativo informatico ed in grado di essere graficati. La maggior parte degli element sono delle rappresentazioni dei Data dell'Alcove nel mondo del GraphicSystem. In molti di questi elementi si adotterà il pattern Decorator, per decorare dei semplici Data con tutte le funzioni ed informazioni necessarie per la loro graficazione.
- GameComponent: elementi di gioco più complessi. Possono essere inizializzati, configurati e avviati e dinamicamente disabilitati ed abilitati. Un esempio di GameComponent può essere il gestore del Background o del Cursore del Mouse.
- GameGraphicManager: questi GameComponent sono i più importanti in assoluto. Sono infatti in grado di gestire gli elementi grafici e gli input fatti su di essi. Ad esempio possono gestire un GameComponent rappresentante una interfaccia di pulsanti graficandolo e gestendo gli input che avvengono su di esso.
- GameMode: modalità di gioco. Sono contenitori e colla di GameComponent, gestendoli, abilitandoli e aggiungendoli a loro piacimento. Deve essere possibile lo switch di GameMode. Un esempio di GameMode può essere ad esempio la scheramata di login, una visione dall'alto dell'universo, o un campo di battaglia.
- GameStates: entità onnipresenti nel gioco, richiamabili ed utilizzabili in ogni momento. Un esempio può essere un menù che compare alla pressione di un tasto, o un gestore di messaggi dal gioco.
- Hanuman: interfaccie con il mondo esterno, deve permettere di ottenere qualunque componente utile del gioco e deve a sua volta fornire interfaccie che gli elementi del GraphicSystem possono utilizzare per comunicare con il mondo esterno senza avere coscienza dell'implementazione delle stesse.
Il package Hanuman contiene le seguenti entità:
- Hanuman, un Singleton in grado di far partire il gioco e di fornire al mondo esterno delle operazioni per prelevare o agire sui vari componenti del gioco (dove per componenti si intendono qualunque dei package sopra definiti).
- IGameManager, una interfaccia implementabile esternamente al GraphicSystem, da specificare al Singleton Hanuman all'avvio del gioco. Questa interfaccia fornisce tutte le operazioni necessarie che il GraphicSystem richiama per rispondere agli input dell'utente. Un esempio di operazione potrebbe essere enterZone(String zoneName), richiamata quando l'utente clicca su una Zone. Il GraphicSystem non deve rispondere alla mossa dell'utente di sua iniziativa, ma delega l'operazione a colui che implementa l'interfaccia IGameManager.
- ICommandHandler*, una interuna interfaccia implementabile esternamente al GraphicSystem, è in grado di rispondere ai comandi da tastiera dell'utente in un modo dipendente unicamente dalla implementazione.
Sono stati individuati i seguenti GameModes:
- LoginMode: gestisce la modalità di gioco di login, in cui sono richieste le credenziali per poter giocare).
- UniverseMode: gestisce la modalità di gioco Universe, mostrando l'astronave del PG, e le Zone disposte sullo schermo.
- ZoneMode: gestisce la modalità di gioco Zone, mostrando le informazioni sulla Zone, i PG presenti, le Utility e gli Arcade.
- ArcadeMode: gestisce la modalità di gioco Arcade, mostrando i PG e NPG presenti nell'Arcade, permettendo un input avanzato per il movimento e la gestione dell'astronave. (purtroppo non implementato).
Sono stati individuati i seguenti GameStates:
- Informer: permette di visualizzare sullo schermo tre tipologie di messaggi. Uno in cui specificare i comandi eseguibili, uno per i messaggi di stato e uno per i messaggi di errore.
- CommandManager: intercetta gli input da tastiera dell'utente identificandoli con un comando (es: Stringa). Se un comando viene abilitato, l'ICommandHandler associato deve essere avvertito.
- PlayerDataGraphicManager: permette di visualizzare e gestire i dati del PG (purtroppo non implementato).
Ci deve essere un GameGraphicManager diverso per ogni GameMode, in grado di gestire gli input dell'utente come i click sugli elementi o sulle interfacce. I GraphicManager utilizzeranno spesso l'interfaccia IGameMode per comunicare i desideri dell'utente.Il progetto è molto legato alla tecnologia utilizzata poiché l'implementazione da zero di un tale sistema è proibitiva data l'esperienza del gruppo e il poco tempo (senza contare inoltre la completa non-inerenza con la materia in esame). Per questo si è deciso di utilizzare un GameEngine, che mettesse a disposizone gran parte delle funzionalità richieste. Si è scelto il gameEngine java jMonkey. Il progetto è estremamente legato alle sue caratteristiche.Coffee deve interpretare le richieste inviate dal GraphicSystem trasformandole in Mosse, ed interpretare le Modifiche e i Data inviati da Physic applicandole al GraphicSystem. Conseguenza importante sarà quella di implementare le interfacce del package Hanuman
IGameManager e
ICommandHandler.Coffee gestisce mosse e modifiche gestendo i Context, ovvero i flussi virtuali di mosse, modifiche e data. I Context permettono di capire a quale ambito è da riferirsi la data mossa, modifica e data. Un esempio di Context potrebbe essere il Context "universe", oppure "pgData", oppure "zonePlanetEarth".Si sono individuati i seguenti package:
- Caffeine: la parte principale di Coffee. Da lì parte il gioco lato client, effettuando il login con il server.
- Login: contiene tutte le classi necessarie per eseguire il login. Oltre a sistemi per ottenere user e password sono importanti anche le informazioni di login che possono prevedere ad esempio una applicazione di una funzione hash alla password per non inviarla in chiaro sulla rete.
- Game: contiene l'implementazione dell'interfaccia IGameManager di GraphicSystem in modo da poter convertire in Mosse le azioni del player sull'interfaccia. Contiene inoltre un Singleton: NameContextManager, che memorizza e mette a disposizione il nome dei context utilizzati durante il gioco.
- DataHandling: contiene le entità in grado di interfacciarsi con il WarpCoreTen, quindi un IMossaTaker, in grado di accettare mosse ed posizionarle nel Warp, e una entità IModificheHandler in grado di accettare dati e modifiche e di individuare il loro context.
- DataHandling.modificheManager: questo subpackage contiene dei IModificheManager, ovvero entità che accettano modifiche di un certo Context. Ad esempio un UniverseModificheManager accetta modifiche e dati che riguardano il Context Universe. I ModificheManager, dove conveniente, sono da implementare seguendo uno schema di una macchina a stati, in grado di definirne il comportamento. Un importante modificheManager riguarda quello del Context che riguarda i comandi eseguibili. Questo particolare manager può implementare l'interfaccia del GraphicSystem ICommandHandler per poter agire ai comandi da tastiera inviari dall'utente.
Physic deve gestire tutti i Coffee collegati, dove per gestire intendo reagire alle mosse ricevute, con opportune modifiche e/o dati. Il suo scopo primario è quindi quello di accettare mosse, interpretarle e reagire opportunamente. I tipi di reazione che può avere una mossa sono (non sono mutuamente esclusivi):
- Creazione di un nuovo context ed invio dei dati iniziali
- Unione del player ad un context comune ed invio dei dati
- Invio di modifiche
Ad esempio se un player vuole entrare nell'Universo, dichiara la sua intenzione producendo una adeguata Mossa e mettendola nel WCT. Physic, una volta ottenuta la mossa, se sono soddisfatte eventuali condizioni, unirà il player al context comune dell'universo, inviandogli i dati necessari per la graficazione e una Modifica che permette al client di entrare nella modalità universo, che si tradurrà in uno Switch della GameMode nel GraphicSystem.Si è inoltre pensato alla gestione dei dati comuni in questo modo: si distinguono fra dati Common e dati not common. I dati common devono venire sincronizzati (con una sincronizzazione iniziale dei dati e con un invio di modifiche) con il/i giocatore/i, mentre per i dati not common occorre verificare quali possano essere conosciuti e quali no. Dati not common sono ad esempio la posizone di una nave occultata, informazioni o utilità su una zona, ecc.. Sarà quindi compito del sistema Physic stabilire quali dati sono visibili e quali no.Si sono individuati i seguenti package:
- Physic: contiene l'entità Physic, il cuore del server, in grado di configurare il sistema Physic e di accettare le mosse dai client. Le mosse dai client vengono suddivise in base al context ed inviate al relativo Master.
- masters: contengono i master dei context, ovvero delle entità specializzate nel ricevere mosse di un dato context (ad esempio UniverseMaster è specializzato nell'ottenere mosse del context Universe). I master eseguono controlli ed operazioni basilari, delegando la completa interpretazione della mossa all'entità ActionReaction.
- actionreaction: contiene l'entità ActionReaction, ovvero una entità in grado di calcolare tutte le conseguenze di una data mossa e produrre le modifiche necessarie. Ad esempio l'entrata di un PG in una Zone, comporta per l'ActionReaction, stabilire quali dati not common il PG ha il diritto di possedere e quali altri PG presenti nella stessa zona, hanno diritto di conoscere la presenza del nuovo PG. Quindi la presenza di un PG in una zona è un dato not common. In parole semplici ActionReaction deve determinare quali variazioni nei dati di tutto Physic comporta la data mossa, e sincronizzare il cambiamento a tutti i PG interessati, inviando Modifiche.
- datamanager: i dati sono la caratteristica più importante di Physic, quindi dataManager rivestono un ruolo di vitale importanza. Le entità importanti di questo package sono DataCollection, che rappresenta una collezione di dati e DataManager, in grado di garantire un accesso esclusivo alla DataCollection di cui è composto. DataCollection e DataManager non fanno assunzioni a priori sulla fonte dei dati, è quindi prevista una implementazione per il prototipo basata su una collezione di dati mantenuta in memoria per poi passare ad una implementazione di una Collezione in grado di lavorare su un DB per mantenere la massima fault-tollerance riguardo la memorizzazione dei dati (purtroppo non implementato).
- arcade: questo package (purtroppo non implementato) gestisce tutto ciò che avviene all'interno di un'arcade. L'arcade si deve comportare con una struttura a turni, mascherandolo però all'utente. Si definiscono le seguenti entità:
- Combat: il gestore del combattimento.
- CombatPlayer: rappresentazione di un PG all'interno di un combattimento
- GreenPencil: una GreenPencil è un insieme di Mosse che il PG intende fare nel proprio turno.
- GreenPencilCase: è una collezione di GreenPencil.
Per nascondere la struttura a turni, i PG inviano le loro mosse e vengono memorizzate nella loro GreenPencil. Quando il combat internamente stabilisce che è il loro turno, prende la loro GreenPencil e la applica. L'utente così non si rende conto di una vera struttura a turni in cui deve aspettare le mosse degli altri e poi inviare la sua, ma sembrerà di inviare ed eseguire real-time le mosse, anche se in realtà sono applicate seguendo un turno. Per gestire più Combat che si potrebbero unire, si stabilisce che un player è sempre all'interno di un combat e quando due player appartenenti a combat diversi si attaccano, i due combat vengono joinati. Questo porta alla definizione di un Combat di Default a cui appartiene ogni player che non sia in un altro combat.Né in Physic né in Coffee si esplicita esattamente il concetto di Context. Questo perché è esattamente l'interpretazione data dal gioco ai WCT del sistema Warp Core Ten.WarpCoreTen rappresenta una entità che rappresenta una struttura di dati utilizzata per la comunicazione tra il Client ed il Server, ovvero una collezione di informazioni che tende ad essere consistente tra il client ed il server. Un WarpCoreTen è composto da Mosse, Caratteristiche e Modifiche.Mosse, Caratteristiche e Modifiche sono a loro volta collezioni di WarpCoreTenEntry, ovvero elementi basilari composti da un nome e da un valore.Quando in Physic e Coffee si parlava di Context, qui si ha una diretta e univoca corrispondeza con WCT. Il sistema Physic-Coffee utilizzerà un numero arbitrario, dipendente dalle loro neccessità, di WarpCoreTen, ognuno dei quali è identificato da un nome. Lato Coffee (client), ogni mossa messa all'interno di un particolare WarpCoreTen, verrà trasferita dal sistema al lato Physic (server). La Physic (blackBox per il sistema WarpCoreTen) mettendo delle modifiche nelle wct, le invia a Coffee, senza avere conoscenza della sua posizione nella rete.Quindi i singoli WCT si possono vedere come canali di comunicazione fra client e server senza che quest'ultimi abbiano l'effettiva conoscenza di essere sopra una rete.Tuttavia, come fare per indentificare un client? Se Physic vuole creare un WCT chiamato "ComandiTastieraAbilitati" per un dato player, come può fare per specificare il player? Questa domanda ha portato alla introduzione di particolari WCT, che sono ISession. Una ISession è il WCT principale di comunicazione fra client e server, creato al login. Il client per loggarsi al server, sfrutta sempre il sistema WCT. In caso di succesfull login, il sistema WCT crea una WCT Session, con nome univoco in tutto il sistema (ad esempio il nome utente). Quando Physic vorrà creare una WCT per un dato client, sfrutterà la Session come identificativo del Coffee a cui collegare la nuova WCT. A questo punto, ogni mossa o modifica posizionata su un WCT, verrà presa, impacchettata in un Travel, una WarpCoreTenEntry particolare che ha come nome il nome della WCT di destinazione, come valore tutte le mosse o modifiche (a seconda se ci troviamo lato client o server) impacchettate (ovvero inserite all'interno di un'unica WCTECollection (una WarpCoreTenEntryCollection) e ha un terzo campo che è l'identificativo della Session. Tutti i travel in uscita vengono messi all'interno di un WCTMigration, che è una WCTECollection contenuta nel Portal. Portal rappresenta appunto il portale di comunicazione fra i due estremi del WCT e contiene due WCTMigration: una di incoming e una di outcoming. Il Portal lato client, identificato univocamente da una Session, chiede al Portal lato server (attraverso una canale di comunicazione via rete) di essere sincronizzato ed il server risponde inviandogli tutte le WCTTravel presenti nel suo WCTMigration di outcoming. A questo punto il PortalClient inserisce le WCTTravel ricevute nel suo WCTMigration di incoming. (ovviamente per inviare le Mosse, il client quando chiede di essere aggiornato spedisce il contenuto del suo WCTMigration outcoming al server).Per fare in modo che l'inserimento di mosse/modifiche all'interno di un WCT scatenino questo procedimento, si introduce l'entità già definita in analisi Fantasmino. Fantasmino è una entità attiva che resta bloccata fino a quando qualcuno non inserisce una mossa o una modifica in un WCT. A quel punto la WCT stessa manda un poke asincrono al fantasmino (lo sblocca asincronicamente). Il fantasmino svegliato, controlla tutte le WCT che deve controllare e se trova dei WCTEntry, li prende e li manda al proprio master, ovvero un IWCTHandler che deve implementare una operazione accept(IWarpCoreTenEntry element, IWarpCoreTen generator).L'introduzione in Physic di Context comuni, a cui possono accedere più PG, si concretizza con la realizzazione di un particolare WarpCoreTen, chiamato WarpCoreTenArcade. Questo particolare WCT permette la join di Session al suo interno. La join comporta la crazione di una sub-WCT alla WCTArcade, funzionante in questo modo: qualunque modifica inserita nella sub-WCT arriva unicamente ad essa, ma una modifica inserita nella WCTArcade viene inviate a tutte le sub-WCT (ovviamente questa cosa ha senso solo lato Server, lato Client non si ha la coscienza di essere in una WCT Arcade).Per mantenere coerenza con il concetto principale di WCT, ovvero la sincronizzazione di dati, al momento della creazione è possibile specificare una WCTECollection non vuota in modo che sia automaticamente sincronizzata durante la creazione (per creazione si intende la generazione della WCT lato server e il suo raggiungimento lato client).Il sistema WCT può essere strutturato nei seguenti package:
- WarpCoreTen: contenenti tutte le varie implementazioni di WCT, come Session, WCTArcade, ecc..
- WarpCoreTenEntities: contiene tutte le implementazioni di WCTECollection, i vari WarpCoreTenEntry utilizzati internamente al sistema (es: messaggi di creazione, distruzione, ecc..)
- WarpCorePortalGun: contiene i Portal, ovvero i capi finali di comunicazione fra client e server.
- Fantasmino: contiene i Fantasmino e le interfacce IWCTHandler.
- WarpCoreTenFactory: contengono delle entità factory, utilizzate per la creazione e distruzione delle varie WCT.
Progettando il sistema WCT e gli altri sistemi, è nata la neccessità per motivi di consistenza, di controllare quando una Session è scollegata (lato Server). Siccome non possiamo supporre una connessione costante con il client, occorre stabilire un periodo di inattività: ad esempio se un client (identificato da una session) non esegue più update per un certo periodo, è da considerarsi disconnesso. Tuttavia è utile che anche Physic sappia della disconnessione, perciò si è creata una entità chiamata GarbageSessionCollector che ha come compito quello di eliminare le Session che hanno superato un TIMEOUT. Se GarbageSessionCollector trova una session scaduta, pone una modifica di TIMEOUT al suo interno in modo che venga recapitata a Physic e poi la distrugge.L'interazione via rete del WarpCoreTen avviene nel momento in cui il Portal Client chiede al Portal Server le modifiche, recapitando le eventuali mosse. Questa interazione è realizzabile in molti modi, tuttavia si richiede una scelta di tecnologia che sia il più affidabile possibile e semplice da usare specialmente per il masrhalling dei dati. Data, Mosse e Modifiche possono essere entità complesse, quindi la scelta di un protocollo di livello ISO/OSI 7 (come CORBA) da usare come trasporto potrebbe risultare molto vantaggioso.Quindi, ipotizzando una struttura Object Based, si definisce una interfaccia remota (nell'esempio con sintassi idl di CORBA):module EpicGame {
typedef sequence
anyMarsh;
interface Portal {
anyMarsh login(in string uname, in string pw);
anyMarsh update(in long sessionID, in anyMarsh myNews);
};
};Con l'architettura DroneSystem si vuole permettere una computazione Grid, in modo da alleggerire il carico computazionale del Server. Per ottimizzare l'invio di dati, si prevede la possibilità di definire Algorithm Viniculumnable, ovvero Algorithm in grado di spezzare l'input in N parti, per poi ricomporre l'output.
Si sono individuate le seguenti entità:- Question: l'elemento di scambio fra Droni e il serverDrone. Contiene un riferimento comune all'Algorithm da utilizzare, gli input e (lato server) è possibile settare la soluzione.
- QuestionManager: organizza le Question, cercando di costruire una priorità di esecuzione (ad esempio fornendo prima le ultime Question prodotte).
- Drone: il sistema remoto, il suo compito è quello di registrarsi al server e mettersi in attesa di una risposta.
- LinkedDrone: rappresentazione di un Drone sul server. Una volta registrato, ad un Drone viene assegnato un ID e viene creata una entità LinkedDrone.
- DroneManager: gestisce i LinkedDroni, organizzandoli in liberi e occupati. Quando viene richiesto un drone per eseguire un Algorithm, DroneManager lo fornisce dalla lista dei liberi.
- Queen: la Queen è il drone locale del Server. Non potendo fare affidamento sui Droni remoti, è necessario per il server avere un Drone personale che esegue in sequenza tutte le question non risolte (non risolte vuol dire senza soluzione).
- Consierge: entità a cui i droni si collegano per registrarsi, chiedere una Question da eseguire ed inviare la soluzione.
- Dispatcher: entità che si occupa di prelevare le Question dal QuestionManager e di passarle al DroneManager, cosicché vengano eseguite.
- Collector: entità che si occupa di accettare nuove soluzioni e di richiamare il viniculum dell'Algorithm (la merge degli output) nel caso l'Algorithm sia Viniculumnable, o semplicemente di mettere la soluzione nella Question.
- Neural Interface: interfaccia con il mondo esterno (Physic). È possibile richiedere di eseguire un Algorithm, specificando gli input. Questa interazione è sincrona.
Quindi quando ad esempio ActionReaction da Physic vuole eseguire un Algorithm, comunica con Neural Interface, il quale chiede a QuestionManager di produrre una question e aspetta fino alla sua risoluzione. Una volta risolta, ritorna l'output.
I Droni interagiscono con Cosierge in modo remoto, eseguendo diverse operazioni. Come per il caso del WarpCoreTen, gli input degli Algorithm inviati possono essere molto complessi, quindi si richiede una scelta di tecnologia che sia il più affidabile possibile e semplice da usare specialmente per il masrhalling dei dati come un protocollo di livello ISO/OSI 7 (come CORBA).
Quindi, ipotizzando una struttura Object Based, si definisce una interfaccia remota (nell'esempio con sintassi idl di CORBA):
module droneSystem {
typedef sequence anyMarsh;
interface Concierge {
anyMarsh getHypothesis (in long long ID);
void putSolution(in long long ID, in anyMarsh solution);
long long register();
};
};Si è scelto di usare CORBA per non vincolare il nostro sistema a Java (ad esempio nell'ipotesi di sviluppare i client o server in C++) e per usufruire di un semplice metodo di marshalling dei dati.
La prima alternativa per inviare dati arbitrari sulla rete è quella di usare DynAny, offerto da CORBA, ma a causa di una tardiva e difficoltosa presa di familiarità con il sistema, abbiamo deciso di creare un nostro sistema di marshalling sfruttando gli Any di CORBA.
Un Any di CORBA può contenere un qualunque tipo di dato (ovviamente senza usare la Serializzable di Java). Quindi inviando una sequence, possiamo inviare una sequenza di dati arbitrari su cui poter fare l'unmasrhalling senza alcuna assunzione a priori sul contenuto.
Per ottenere questo abbiamo creato un sistema MiddleTopLayer, che si pone fra i nostri sistemi che utilizzano la rete (WCT e DroneSystem) e CORBA e permette la trasduzione di dati del nostro programma in dati inviabili da CORBA.
L'entità base del MiddelTopLayer è l'Opaque.
Opaque contiene tutti i metodi applicabili su any (extract_int(), extract_double(), ..., insert_String(), insert_char(), ...), ma con questa differenza: ogni insert crea due any: uno contenente il tipo di dato e l'altro contenente il dato. Entrambi questi any vengono aggiunti alla sequenza.
Inviando la sequenza di any, è possibile ricorsivamente estrarre i dati e ricomporli.
In aggiunta agli extract e insert normal, si aggiungono due metodi insert_Object(Object o) ed extract_Object().
Entrambi inseriscono od estraggono una entità da noi definita che implementi l'interfaccia IMarshallable.
Qualunque IMarshallable deve implementare le operazioni
void marsh(ISendOpaque o)
IMarshallable unmarsh(IReceiveOpaque o)
(dove ISendOpaque è una interfaccia implementata da Opaque che contiene solamente gli insert, mentre IReceiveOpaque contiene solamente gli extract).
Quindi per effettuare il marshalling di un IMarshallable, viene richiamato il metodo marsh specificando l'Opaque su cui fare ke insert.
Effettuare l'unmarshalling senza avere effettivamente alcuna congnizione del dato in arrivo, è impossibile a meno di non usare uno strumento come la Reflection di Java. Perciò abbiamo creato una struttura dati, Olympus, da supporre consistente fra client e server, che associ un identificativo dell'IMarshallable con una sua istanza.
Quindi quando viene ricevuto una sequenza di any, si estrae il tipo: se è un tipo primitivo, lo si estrae e si passa al successivo. Se il tipo non è primitivo (si suppone che sia un IMarshallable), si prende la sua istanza da Olympus e si richiama l'unmarsh, specificando l'Opaque.
In questo modo possiamo far scambiare dati arbitrari fra le nostre applicazioni.
