OpenFL

In questo post vi parleremo delle scelte che stiamo effettuando per la realizzazione del Client di gioco, e di alcune conseguenze che ne derivano.

Realizzare un client di gioco è una cosa davvero complicata, soprattutto se si ha intenzione di integrare alcune caratteristiche di base importanti quali:

• La possibilità di avere un’applicazione multipiattaforma evitando di scrivere codice nuovo ogni volta che si pubblica il gioco su una piattaforma diversa;
• Un’alta manutenibilità del prodotto finale, in modo da poter risolvere facilmente i bug e implementare funzionalità di gioco aggiuntive;
• Risorse limitate per l’acquisto di tools e suite di authoring.

La risposta a queste esigenze è senza dubbio Haxe, accompagnato dall’ormai inseparabile OpenFL. Haxe è un linguaggio di programmazione estremamente versatile che consente la compilazione su piattaforme diverse.

Haxe ha una sintassi molto simile a quella del linguaggio Action Script e i suoi punti di forza fanno capo a:

• Supporto del formalismo necessario a produrre del codice facilmente modificabile nel tempo;
• Supporto alla creazione di script avanzati che, se adeguatamente incastonati nel codice, possono accorciare i tempi di produzione;
• La possibilità di avere target diversi durante la compilazione e quindi la possibilità di condividere il codice per creare diverse applicazioni in grado di essere eseguite in ambienti diversi: Flash, Java, C++, C#, …
• La possibilità, grazie all’utilizzo della libreria OpenFL, di avere come target le principali piattaforme mobile quali Android, Apple e Microsoft.

Sia Haxe che OpenFL possono inoltre contare su community di utenti e sviluppatori che consentono un continuo miglioramento delle versioni che vengono rilasciate. Basti pensare che Haxe, nato nel 2005, è oggi alla versione 3.1.3, mentre OpenFL, nato circa due anni fa da NME, è alla versione 3.0.3.

Abbiamo individuato questo linguaggio perché rispondeva in buona parte alle nostre necessità. Ritenendo fuori dalle nostre possibilità la creazione ex novo di un motore in grado di gestire un client di gioco, guardandoci attorno per capire cosa il mondo dei tools poteva offrirci, abbiamo individuato Stencyl.

Stencyl è uno strumento di authoring che consente di creare giochi senza preoccuparsi troppo del codice che ci sta sotto, infatti si fa carico di tutto ciò che è necessario per le azioni più comuni che sono presenti nei giochi. Allo stesso tempo però permette di andare a fondo nel codice quando se ne presenta la necessità e fornisce un motore Haxe/OpenFL in continua evoluzione. Per tutti questi motivi Stencyl è risultato per noi la scelta più adeguata sotto diversi punti di vista. In questo momento infatti stiamo studiando come adattarlo alle nostre esigenze, principalmente nelle seguenti direzioni:

• Facilitare la scrittura del codice: nel tempo Stencyl è divenuto un prodotto molto interessante e utile ma non ha la velleità di sostituire una IDE nei suoi tratti principali, come l’autocompletamento del codice ed altre features simili;
• Creare un sistema di pianificazione ed esecuzione di attività predefinite, necessario per la creazione di animazioni;
• Cercare un modo di rendere Stencyl pienamente utilizzabile attraverso strumenti di condivisione del codice.

Stencyl ha anche un altro ottimo fattore su cui poter contare: consente l’utilizzo di tutte le features in maniera del tutto gratuita e la pubblicazione di file SWF. Allo stesso tempo, con un piccolo annuo, consente di pubblicare tutte le proprie fatiche su molte piattaforme fra le quali Android, Apple in versione mobile e non, Microsoft in versione mobile e non, Linux.

Passando alla grafica del client, ad oggi stiamo progettando un sistema che possa essere ben integrato con l’ambientazione post-atomica che è il fulcro di Redemption – The Third Era. Il nostro sistema di progettazione è definito per funzioni, a seconda delle funzionalità che dobbiamo concedere all’utente progettiamo e realizziamo vari parti grafiche con uno stile di fondo unico e adatto. Allo stesso tempo cerchiamo di applicare la metodologia User Centered Design, quantomeno ricordandosi sempre che quello che realizziamo deve essere fruito nel modo più semplice possibile dai giocatori.

Fra i vari ambienti che stiamo progettando c’è quello che prevede la possibilità di vendita delle proprie carte nel mercato. Per fare questo c’è la necessità di individuare la carta, di far immettere un prezzo e di dare un ‘ok’ alla messa in vendita. Qui trovate un esempio di come stiamo sviluppando questa necessità attraverso la creazione dell’esigenza, passando per la stesura di un bozzetto e creando poi la parte necessaria all’interfaccia grafica per poter coprire i requisiti.

Date le nostre esigenze di avere un sistema multipiattaforma, quello che cerchiamo di fare nell’ambito della produzione della GUI è di creare delle componenti che siano adatte sia per il comparto Flash/Desktop, sia per il comparto Mobile, o che quantomeno siano facilmente adattabili. La componente mostrata qui è particolarmente esplicativa in quanto sarà sfruttabile via tastiera o mouse per il settore Flash/Desktop sia attraverso il tapping di un qualsiasi dispositivo mobile.