Da iPhone a AppUp: porting di "Ancient Frog"
Quest'articolo è la continuazione della serie di articoli dedicati al porting delle applicazioni da iPhone a AppUp(SM). È un'intervista allo sviluppatore James Brown in cui parla di quando ha eseguito il porting del suo famoso videogame "Ancient Frog" da iPhone a AppUp.
D. Da cosa è stato ispirato questo videogame?
James Brown:
Ancient Frog è il prodotto del mio distacco dal mercato dei videogame di tipo tradizionale. Avevo competenze piuttosto varie che spaziavano da progettista e programmatore, ad artista e produttore. Il settore dei videogame nel frattempo era diventato enorme e stratificato, così finii per entrare alla Lionhead/Microsoft come responsabile di un team di programmatori e senza possibilità di dare un contributo effettivo dal punto di vista creativo, ruolo questo che era veramente distante dal mio lavoro ideale.
Decisi così di riprendere a creare giochi. Furono i limiti che posi a me stesso a farmi arrivare all'idea di Ancient Frog. Avevo bisogno di creare un videogame che fosse di dimensioni abbastanza contenute da poter essere realizzato da un solo sviluppatore, ma che avesse una qualità di livello professionale. Con un gioco rompicapo, una volta definita precisamente la meccanica del rompicapo, la parte rimanente è solo una variazione sul tema. Volevo anche un protagonista principale che fosse carino ma non lezioso e che avesse una spiccata personalità. Poiché non sono un animatore, mi misi a cercare nei sistemi di animazione procedurale, e da tutto ciò a un certo punto iniziò a emergere l'idea di un gioco che coinvolgesse arrampicate e un geco.
Una volta creato il prototipo di una figura stilizzata, l'idea prendeva forma e si sviluppava man mano che ci giocherellavo. Il geco si trasformò in una rana perché le rane hanno le zampe posteriori più lunghe di quelle anteriori, il che permette di introdurre alcune interessanti opzioni di gioco per il giocatore. L'aspetto dell'arrampicata svanì e si trasformò nell'idea leggermente più astratta di camminare su delle gocce d'acqua. Il sistema di animazione divenne più esplicito: il giocatore non guida la rana, ma sposta una gamba alla volta, il che rende il rompicapo ancora più interessante e pone il giocatore, e non il gioco, nella posizione di creare l'animazione.
Il viaggio da quel prototipo iniziale al gioco finale è stato piuttosto lungo (nel corso del quale mi sono trasferito in un altro paese e ho creato programmi interattivi digitali per i musei), ma l'idea fondamentale mi era sempre molto chiara.
James Brown: Lo strumento principale usato per la creazione del gioco è il gioco stesso. La maggior parte del codice scritto per Ancient Frog è finito nei tool e negli editor interni (incluso il codice per generare i puzzle e quello per trovare le soluzioni ottimali, che è stato un lavoro difficile ma decisamente interessante). Il fattore che più ha contribuito a definire la progettazione è l'aver reso modificabile al volo tutto ciò che potesse esserlo. Quando si tratta di creare un'esperienza interattiva coinvolgente, non c'è nulla che possa meglio sostituire la ripetizione costante. Provare, testare, correggere, testare di nuovo e così via finché tutti gli intoppi e i problemi sono stati rimossi. Quindi continuare ad aggiungere elementi di sorpresa e divertenti. E quindi ritornare a fare un altro round di testing per rimuovere i difetti e i problemi introdotti. Il tutto è guidato dai dati e, controllando il disco per rilevare le modifiche, il gioco può caricare senza interruzione qualsiasi cambiamento fatto. Basta solo disegnare su una texture in Photoshop, salvare ed è nel gioco. Il codice non contiene formule magiche: ho una piccola classe di 'regole' con modelli che agisce da tipo nativo, per cui ridurre tutto all'esposizione dei dati è molto vantaggioso. E lo scatto di quella zampa? E la durata di quella dissolvenza incrociata? E l'accelerazione dovuta alla gravità? Anche se sono certo che non li cambierò mai, sono lì e, se mi viene lo sfizio mentre sto testando, posso armeggiare con qualunque cosa voglio e vedere cosa succede mentre lo faccio. Se è necessario interrompere, ricompilare e ritornare al punto di partenza, si raggiunge presto il punto in cui anche una modifica introduce troppe seccature. L'aspetto particolare di Ancient Frog è finalmente emerso da un requisito autoimposto di indipendenza dalla risoluzione massima. Volevo che funzionasse con qualsiasi risoluzione da 640x480 fino ad esempio a un monitor doppio di dimensioni 1920x1200, e con qualsiasi formato da verticale a widescreen. Una delle cose che mi infastidiva di più del videogame che avevo creato quando lavoravo alla Lionhead, era che al cambiamento della risoluzione si doveva far ripartire il gioco. Ora che lavoravo tutto da solo potevo farlo correttamente, così non solo avrei permesso alla risoluzione di essere cambiata al volo, ma il cambiamento sarebbe anche avvenuto in modo che si potesse acquisire la finestra e trascinarla in qualsiasi forma o dimensione e vedere il contenuto adattarsi con uniformità. Questa che sembra essere una decisione tecnica sorprendentemente banale, finì con l'avere un impatto enorme sia in termini dell'aspetto unico e originale del videogame che nella sua capacità di essere trasferito su una gran varietà di piattaforme diverse. Se mi fossi limitato a fissare solo alcuni formati ragionevoli, avrei potuto cavarmela creando le immagini con un po' di spazio intorno ai bordi e ritagliandole per adattarle, ma il fatto che ogni volta che eseguivo il gioco avevo la possibilità di divertirmi a cambiare le dimensioni della finestra, significava che avrei voluto vedere che cosa sarebbe successo se la finestra fosse stata molto larga, oppure molto alta, oppure enorme, oppure minuscola. E così facendo mi scontravo con i limiti dei layout fissi. È per questo che ho creato un modulo di layout basato su file di livello xml, che compila livelli in strati. Ogni strato può avere regole di layout di ogni sorta, ma la strategia di base è di avere uno strato che contenga l'area di gioco che tende a essere grande quanto la finestra, e uno o due strati in primo piano e di sfondo che possono essere inclinati, allungati o ritagliati per riempire il resto dello schermo. Avuta l'idea di costruire i livelli in strati, era naturale che usassi questa idea per introdurre un po'di vita e movimento nello schermo, un po' di profondità di campo e parallasse. Per dare la trama agli strati ho usato fotografie di foglie, di tronchi d'albero, di muschio, di sassi e così via. Sebbene ci fosse qualcosa di promettente in questo approccio, per molti mesi non riuscì a presentarsi come un insieme coerente. Ebbi l'illuminazione un giorno, mentre pulivo il canaletto di scolo davanti a casa, quando notai il motivo dell'ombra delle foglie degli alberi proiettato sulla porta del garage di casa. Sembrava una danza in continua evoluzione, ma che era fondamentalmente semplice perché si basava sull'interazione di poche semplici forme e ritmi. Quando tornai in casa, misi in codice quell'effetto e lo sovrapposi a ciascun livello usando un metodo di fusione moltiplicato per dare al tutto un aspetto di ricca saturazione e questo ha finito col fissare lo stile di tutto il gioco. D. Su quanti dispositivi è Ancient Frog e quando hai iniziato lo sviluppo multipiattaforma? James Brown: Ancient Frog è disponibile per Apple iPhone e iPad, Palm Pre e Pix e ora per i netbook basati su Atom. Ho anche un porting per Android, che attualmente non ho possibilità di venderlo dalla Nuova Zelanda, e le versioni per PC desktop e Mac per le quali sto ancora valutano il miglior canale di distribuzione. Il prototipo iniziale fu in realtà scritto per il mio telefono, che allora era un dispositivo mobile Windows con uno schermo 240x240. Mi ritrovavo soprattutto a giocare in momenti strani, come alla fermata dell'autobus o mentre ero in coda alla cassa del supermercato, e volevo perciò creare qualcosa adatto a quelle circostanze. Ma questo accadeva prima che arrivasse iPhone, quando il mercato degli smartphone era molto frammentato e non mi era chiaro a quali specifiche dovessi puntare e se fossi stato in grado di vendere un gioco agli utenti degli smartphone. Per cui misi da parte quell'idea e mi concentrai sullo sviluppo per il PC. L'idea però di mettere il gioco nel telefono ad un certo punto nel futuro non mi abbandonò e, nel corso dello sviluppo del gioco, la portabilità e la scalabilità rimasero degli elementi centrali. Ho scoperto che minore è la dipendenza dalle librerie esterne maggiore è la portabilità del codice. Ci sono certamente molti argomenti a favore dell'uso di librerie di utility, motori e middleware, ma sono un vantaggio solo se vanno su una piattaforma di destinazione più avanzata. Se succede che una delle dipendenze non funziona sulla piattaforma di destinazione a cui si è interessati, non si può fare molto per cambiare questa situazione. A dire il vero sul PC uso SDL (Simple DirectMedia Layer), che è un livello molto snello e facile da programmare nel caso servano alternative (come è successo a me per iPhone e Android). Altrimenti è solo codice C++ su OpenGL. C++ è una scelta sicura perché, indipendentemente del linguaggio consigliato da una particolare piattaforma, si può essere certi che il compilatore C/C++ era lì da prima (se non altro per compilare quel linguaggio). OpenGL è ampiamente disponibile per impostazione predefinita (anche in Windows, sebbene preferirebbero che si usasse Direct3D ma non si spingono oltre a insistere). È anche molto facile usare un sottoinsieme ben definito di OpenGL e, sulle piattaforme dove non è disponibile, implementare da sé solo quel sottoinsieme. Sviluppo principalmente su Windows usando Visual Studio, ma uso un Macbook Pro quando non sono in ufficio. La portabilità del codice è molto agevolata se per la compilazione si usano regolarmente due sistemi operativi e compilatori diversi. Quest'accorgimento a volte basta per eliminare la maggior parte dei problemi multipiattaforma prima che si sedimentino e finiscano per apparire in qualche altro strano posto. È così che non ho avuto molte sorprese nell'effettuare il porting in altre piattaforme. D. Quali strumenti e metodi hai usato per il porting dell'applicazione nei netbook e perché li hai scelti? James Brown: Il videogioco funzionava già in Windows e le risoluzioni per i netbook erano già state coperte dal lavoro fatto originariamente, pertanto parlare di "porting" per riferirsi al lavoro che era rimasto da fare è probabilmente eccessivo. Non avendo potuto testare il gioco su un numero elevato di dispositivi di destinazione, nel compilare ho usato le impostazioni più restrittive (il motore del gioco ha alcune impostazioni che posso usare in base alle caratteristiche del dispositivo a cui è destinato) e ho disattivato gli oggetti framebuffer e il supporto shader. Quando avrò un po' più di informazioni sul livello di supporto dei driver disponibili, probabilmente li riattiverò per rendere il gioco più brillante. James Brown: Ancient Frog in realtà non usa hardware che non possa essere replicato con un mouse o un trackpad. Uso l'accelerometro per modificare la direzione con cui cadono i petali nell'animazione 'win', ma la perdita di questa caratteristica non influisce sul funzionamento del gioco. Il multitocco è usato nella versione iPad che consente di immergere nell'acqua più di un dito alla volta e, anche in questo caso, non è un grave perdere questa caratteristica. Nelle versioni touchscreen di Ancient Frog, il gioco inizia con un tutorial introduttivo che leva il controllo dal giocatore. Questo effettivamente risultava fastidioso ad alcuni giocatori, ma il playtesting aveva mostrato che era necessario insegnare alcuni dei movimenti di controllo. Ma per qualche strano motivo, sulle macchine con controllo indiretto (con mouse o trackpad) questo diventava completamente inaccettabile. Non so bene il perché, ma è possibile che la mancata risposta a un tocco è qualcosa che dipende sempre dal contesto e che pertanto è un comportamento atteso, mentre la mancata risposta a un mouse dà maggiormente l'impressione che si tratti di un blocco imprevisto. In ogni caso, dovetti cambiare il tutorial rendendolo un po' meno passivo per l'utente. Ho anche rimosso l'annullamento e il ripristino gestuali, in parte perché richiedono di fare dei movimenti maldestri con il mouse/trackpad e in parte perché, essendoci più spazio sullo schermo, vi si possono inserire dei pulsanti. Avere pulsanti sullo schermo incoraggia inoltre gli utenti a usarli per vedere cosa succede, permettendo di alleggerire il contenuto trattato dal tutorial. James Brown: L'approccio usato in Ancient Frog per creare il suo aspetto tramite la fusione di passaggi successivi, richiede una velocità di riempimento molto elevata. Ho avuto difficoltà a trasferirlo sull'iPad, che è la versione che ho fatto prima dei netbook, perché la GPU dell'iPad non riesce semplicemente a gestire un ricalco così pesante. Ho dovuto fare molto lavoro per salvare l'illuminazione nelle texture, rimuovere elementi dal layout e in genere fare tagli perché funzionasse. Per cui, quando passai al porting della versione netbook, temevo di avere gli stessi problemi. Come poi invece si è dimostrato, sono rimasto colpito dalla velocità del chip di grafica integrata e non è stato necessario tagliare nulla. James Brown: Il gioco è essenzialmente lo stesso su tutti i dispositivi. Nei palmari l'aspetto dei livelli è semplificato: hanno un solo strato e sono ritagliati molto precisamente per utilizzare al massimo gli schermi di dimensioni molto piccole. Nelle versioni netbook c'è più spazio per il movimento delle rane e per introdurre sullo sfondo alcuni elementi divertenti da sollecitare. Ma a parte alcuni piccoli aggiustamenti al presentarsi di difficoltà, i rompicapi sono identici. D: Hai dovuto ricorrere all'assistenza di Intel durante il processo? Come giudichi il processo di invio e di supporto di AppUp rispetto ad altri store? James Brown: L'intero processo è stato semplice. Ho avuto un errore di convalida perché avevo compilato l'applicazione usando una versione vecchia dell'SDK, dopodiché tutto è filato liscio come l'olio. D: Se dovessi tornare indietro cambieresti qualcosa? Quali consigli daresti agli sviluppatori che intendono eseguire il porting da iPhone a AppUp? James Brown: L'unica cosa che cambierei è averlo fatto prima. Costa così poca fatica creare un'applicazione per il centro Intel AppUp e sono veramente lieto di vedere la direzione in cui sta andando. Il consiglio migliore che posso dare per eseguire il porting da iPhone a AppUp è creare l'app iPhone avendo fin dall'inizio in mente il porting, usare C++ ed evitare le API specifiche di Apple. Nel caso si fosse già finita la versione iPhone e ci si stia chiedendo se vale la pena ricrearla per renderla più indipendente dalla piattaforma, ricordarsi che i vantaggi che si ottengono in termini di codice originale vanno oltre all'avere una nuova versione. I diversi dispositivi tendono a portare alla luce problemi nascosti diversi. Pertanto, se il codice è lo stesso per tutte le piattaforme, le correzioni che si fanno a una versione migliorano tutte le versioni. Se si intende creare un'applicazione sia per iPhone che per AppUp, conviene svilupparla trattando AppUp come destinazione primaria. Se si vuole ottenere un'iterazione rapida, il debugging effettuato su un netbook è molto più veloce rispetto all'utilizzo di un simulatore di iPhone o al download dell'applicazione sul dispositivo stesso.
D. Ancient Frog ha un aspetto decisamente diverso. Come hai affrontato la progettazione di questo videogame? Ad esempio, quali API e quali altri strumenti hai usato? xml:namespace>
D. Come hai risolto nell'iPhone le differenze di hardware, ad esempio le differenze tra multitocco, mouse, tastiera e accelerometro?
D: C'è qualcosa che ti ha stupito durante il processo di porting, ad esempio attività risultate più difficili o facili del previsto? Nei netbook si sono perse o guadagnate funzionalità?
D: Che differenze di gioco ci sono tra i vari dispositivi?
