Con la crescita e la popolarità dello sviluppo di applicazioni per iPhone, molti sviluppatori stanno valutando la possibilità di ampliare il loro mercato in altre piattaforme. Alcuni di loro hanno avuto successo nel porting in AppUp e hanno scoperto alcune sfide e opportunità interessanti tra le piattaforme.

Le domande riportate di seguito sono state rivolte allo sviluppatore Mike Kasprzak, CEO di Syhkronics, sulla sua esperienza nel porting del proprio gioco pluripremiato "Smiles" da iPhone a AppUp.

Strumenti e metodi utilizzati nel porting Gestione delle differenze hardware Accelerometro Tastiera Multi-touch Sorprese del porting Caratteristiche perse o potenziate nel porting Differenze nella modalità di gioco Supporto Intel Suggerimenti e lezioni apprese

D. Quali strumenti e metodi hai utilizzato per il porting della tua app in ambiente netbook e perché hai seguito questo percorso?

Mike Kasprzak:

Innanzitutto, ho utilizzato OpenGL per la grafica. Di fatto, ogni piattaforma di un certo livello include una versione apposita di OpenGL o un'API analoga. In ambiente Mac, Linux e nella maggior parte degli ambienti mobili, si tratta dell'unica API di grafica 3D. In Windows è un accessorio, ma è comunque disponibile. OpenGL è in realtà un'API molto meno recente di DirectX, ma è stabile e affidabile e continua a essere di un certo rilievo da circa 20 anni.

Ho scritto il mio gioco in C++, che continua a essere valido pur essendo "vecchio". Ho nascosto le caratteristiche specifiche per iPhone che richiedono codice Objective C dietro funzioni e variabili in formato C, quindi per eseguire il porting nel PC ho semplicemente dovuto riscrivere queste funzioni.

Creo manualmente la struttura del mio progetto, quindi posso utilizzare vari progetti XCode, Visual Studio e makefile diversi nello stesso layout. Tutto questo richiede un'attenta pianificazione e un lavoro preparatorio, ma è molto meglio della copia manuale dei file. Il mio makefile ha una configurazione personalizzata e rileva automaticamente tutti i file del mio progetto. Ma per XCode e Visual Studio ho creato manualmente un progetto trascinando al suo interno tutti i file di origine (diverse directory alla volta).

Per mantenere sincronizzati i file utilizzo Subversion (SVN), che risulta utile anche per i backup. Nello specifico, utilizzo TortoiseSVN in Windows e SCPlugin sul Mac. Entrambi si integrano correttamente in Explorer/Finder e sono quindi molto semplici da utilizzare.

Solo per il lato PC, ho utilizzato SDL come API host anziché scrivere codice Windows API nativo. Sull'iPhone ho scritto codice nativo, ma i PC sono tutti SDL. L'ulteriore vantaggio di questa scelta è la compatibilità con Windows, Linux e Mac, oltre che con alcuni dispositivi mobili basati su Linux (Nokia, Palm).

Ma anche se ho utilizzato diverse librerie standard, ho comunque scritto la mia libreria di wrapper su OpenGL e SDL. In questo modo posso eseguire il porting del gioco oltre che nei suddetti ambienti supportati, anche in DirectX in Windows, nella piattaforma Khronos OpenKode (l'alternativa del gruppo OpenGL a SDL) o nelle API native di console di videogiochi come le PlayStation.

Infine, il codice stesso del gioco è come un modulo sovrapposto al codice specifico della piattaforma. Include una funzione Initialization, una funzione Step e una funzione Draw. Il codice del gioco è indipendente dalla forma o dalle dimensioni dello schermo, si basa sulle impostazioni specificate. Ogni frame del gioco è una chiamata a "Step" e quindi a "Draw", ma se l'esecuzione diventa eccessivamente lenta è possibile chiamare alcune volte "Step" per recuperare velocità.

D. Come hai gestito le differenze hardware come la risoluzione dello schermo, la funzionalità multi-touch rispetto all'utilizzo di mouse e tastiera e l'accelerometro dell'iPhone?

Mike Kasprzak:

Per quanto riguarda la risoluzione dello schermo, ho effettuato alcuni interventi.

Innanzitutto, ho progettato il gioco e l'interfaccia utente in modo che fossero scalabili. Questo significa che gli elementi non vengono posizionati sullo schermo in base a coordinate in pixel. Forse sembra complicato, ma il trucco consiste nel selezionare una risoluzione di riferimento e quindi passare alla risoluzione effettiva. Così se ad esempio la risoluzione di riferimento è di 480 x 270, è possibile aumentarla fino a 4 volte per raggiungere 1920 x 1080 (ovvero HD 1080p).

Anche se forse non è chiaro, questa scalabilità viene realizzata tutta con hardware di grafica 3D e texturing. Smiles è un gioco 2D, ma utilizza l'hardware di grafica 3D nei dispositivi in cui è disponibile. È sufficiente non utilizzare la coordinata "Z" e ignorare funzionalità come i test di profondità. L'utilizzo di hardware 3D richiede qualche calcolo in più, ma l'accelerazione 3D è presente ovunque in questi tempi. Se non si utilizza, si tratta di uno spreco di prestazioni.

Quindi, mi ero convinto a creare tutta la grafica del gioco a una risoluzione molto alta. Anche se originariamente l'applicazione era destinata al minuscolo schermo dell'iPhone (480 x 320), la grafica originale aveva una risoluzione sufficientemente alta per l'HD 1080p (1920 x 1080). In effetti, un aspetto positivo riguarda i numeri. È possibile creare grafica dimensionata per lo smartphone (iPhone a 480 x 320 e altri), quindi raddoppiare le dimensioni per 720p HD (netbook, tablet/slate, telefoni con pixel pitch maggiori) e raddoppiarle ancora per 1080p Full HD (PS3, Xbox 360 e PC per videogame di fascia alta). In pratica, questo significa iniziare dalla grafica di fascia più alta per 1080p, quindi dimezzare le dimensioni per i dispositivi di destinazione a "720p" e dimezzarle ancora per gli smartphone a bassa risoluzione. Tutti questi "dimezzamenti" possono anche essere facilmente automatizzati.

Quindi con la grafica e l'interfaccia utente progettate per il ridimensionamento, l'unico problema diventa l'aspect ratio. Con il concetto di risoluzione di riferimento è possibile gestire l'adattamento a diversi aspect ratio. È necessario selezionare o calcolare uno scalare che effettivamente consenta l'adattamento allo schermo. In questo modo, tuttavia, è possibile che venga lasciato dello spazio vuoto sui lati o sotto. Anziché utilizzare le barre nere in Smiles, ho risolto il problema in 2 modi diversi. La prima soluzione consisteva nel creare uno sfondo in più sezioni, la seconda nel creare uno sfondo molto grande.

Gli effetti di suddivisione in sezioni sono facili e scalabili. È sufficiente aggiungere un'altra riga di due o tre sezioni per riempire lo spazio vuoto.

Per quanto riguarda gli sfondi grandi, l'idea è di creare qualcosa più grande dello schermo. In genere è sufficiente che sia il doppio della larghezza e il doppio dell'altezza dello schermo di riferimento. Lo schermo a sua volta non deve contenere niente di visivamente importante, ma qualsiasi cosa si veda non deve sembrare fuori posto.

Per quanto riguarda il multi-touch, non è stato affatto un problema per me. In generale, il multi-touch viene utilizzato prevalentemente per i comandi gestuali. Lo zoom con pizzico, due dita incrociate e così via. Nonostante tutte queste funzionalità divertenti, l'azione più comune che si esegue con un touch-screen è proprio il fatto di toccarlo.

Piuttosto, abbiamo dovuto ragionare sulle differenze tra un mouse e un touch-screen. Entrambi forniscono le posizioni, ma solo il mouse consente di passare su un elemento senza selezionarlo. In poche parole, un touch-screen è in grado di rilevare solo il tocco dell'utente, non la posizione in cui si trova la mano. Mentre invece il cursore del mouse viene passato sopra l'elemento da premere, in attesa del clic per eseguire l'azione. A livello di progettazione, se il gioco funziona con i touch-screen a singolo tocco può funzionare anche con il mouse.

In realtà, è necessario considerare un terzo tipo di input. Le tavolette a penna e i tablet PC. Questi dispositivi vengono in genere utilizzati solo dagli artisti grafici, ma una tavoletta a penna equivale al meglio dei due ambienti. Posizionamento fisico (il puntatore segue la punta della penna) e passaggio su un elemento.

E se vogliamo sbizzarrirci, possiamo considerare dispositivi di puntamento basati su videocamera, come Wiimote di Nintendo, PlayStation Move e Eyetoy di Sony, e Natal di Microsoft. I primi due sono simili a un mouse, mentre gli altri sono paragonabili a un multi-touch.

Eppure si tratta in tutti i casi di sistemi di puntamento, ognuno con un sistema per specificare una posizione, con vari gradi di accuratezza e semplicità. Il più semplice è comunque il touch-screen, posizioni senza passaggio sugli elementi. Se si inizia la progettazione a questo punto, è in genere possibile trovare un modo perché funzioni con qualsiasi altro puntatore.

La mancanza di tastiera nei dispositivi mobili mi ha convinto a progettare il gioco in modo che funzioni interamente con un puntatore (touch-screen, mouse). Risulta anche più facile per gli utenti occasionali. Non è necessario togliere la mano dal mouse, è sufficiente fare clic per proseguire.

Così come il multi-touch viene normalmente utilizzato per i comandi gestuali, l'accelerometro viene in genere utilizzato per rilevare l'orientamento (verticale, orizzontale). Nei PC il gioco viene solitamente bloccato in un singolo orientamento. Invece nell'iPhone ho utilizzato una rotazione fisica come meccanismo del gioco, quindi dovevo trovare una soluzione che funzionasse nelle piattaforme senza accelerometri. Alla fine ho aggiunto i pulsanti di rotazione all'interfaccia.

E adesso il gioco è pronto per qualsiasi piattaforma. :)

Mike Kasprzak:

Non ho incontrato molte sorprese nel progetto, ma quando ho dovuto impegnarmi seriamente nella programmazione grafica, ho scoperto che Intel GMA 950 è un chipset grafico molto più avanzato di quanto fossi portato a credere. Rispetto al PowerVR MBX nell'iPhone originale, il GMA è molto più potente ed è in grado di rendere facilmente una risoluzione due volte superiore senza minimamente compromettere le prestazioni. Utilizzo anche un netbook invece di un notebook perché mi trovo bene. Se devo lavorare a progetti più impegnativi, utilizzo la mia workstation quad-core. Non sempre è necessario però. Posso girare per casa o sedermi all'esterno senza la necessità di portare con me il mio vecchio notebook ingombrante sostitutivo del desktop.

Ecco la sorpresa: in realtà posso occuparmi del porting sul sistema stesso.

D: Avete perso o potenziato delle caratteristiche?

Mike Kasprzak:

I gioco è praticamente identico, ma per rispettare la scadenza, ho ridotto alcune caratteristiche (modalità di gioco). Verranno reintrodotte insieme a molte altre nel prossimo aggiornamento. È stata solo una questione di tempi stretti miei personali, non qualcosa da attribuire ai netbook.

Inoltre la versione netbook era simile a uno "stato pulito" per me, nel senso che potevo apportare correzioni e modifiche alla progettazione perché non c'era il rischio di danneggiare le partite salvate o i punteggi più alti nella versione per iPhone consolidata. Per cui anche se è vero che alcune modalità di gioco sono state eliminate inizialmente, molte altre cose sono già state cambiate. Questo è uno dei lussi che ci si può permettere con la progettazione e il porting delle proprie applicazioni. Se si decide di cambiare o provare qualcosa di diverso, è possibile farlo su una nuova piattaforma. Ovviamente non qualcosa che rovini il gioco, ma trasferire un gioco in una nuova piattaforma offre una libertà interessante.

D: Quali sono le differenze nella modalità di gioco tra i due dispositivi?

Mike Kasprzak:

Sono molto simili. Il meccanismo di gioco di Smiles è ottimizzato per i touch-screen, ma funziona molto bene anche con un mouse. Questo è l'altro aspetto di AppUp che mi entusiasma. In questo momento parliamo di netbook, ma gli OEM stanno sviluppando anche MID e slate con lo stesso hardware (Intel Atom). Normalmente non sarebbe possibile arrivare ai clienti di questo mercato, ma AppUp offre l'opportunità unica di provarci.

Mike Kasprzak:

Il processo di invio è stato semplice. Non ho riscontrato alcun problema, ma per qualsiasi domanda ho trovato Intel sempre ben disposta a rispondere. Ogni piattaforma prevede differenze nell'invio, ecco perché si tratta di un invio e non del semplice inserimento di un download online. Ma AppUp è decisamente uno dei più semplici.

Mike Kasprzak:

Il mio consiglio è assolutamente quello di pensare alla portabilità sin dall'inizio. In verità, avrei molto da dire sull'argomento, ma essenzialmente non è difficile da capire. È opportuno scrivere il codice dei giochi in C/C++, valutare la possibilità di utilizzare OpenGL ES, creare la grafica originale a risoluzioni alte. In questo modo il codice e le risorse del gioco possono essere trasferiti ovunque. Utilizzando qualcosa come SDL, in un paio di giorni è possibile essere pienamente operativi su un PC.