New G@me 2: Q&A
04
Durante la seconda lezione alcune persone hanno fatto domande che reputo meritino di essere trascritte (con quella che pensiamo sia la risposta) in modo che possano essere utili a tutti (terrò questo post “aperto” per questo scopo).
Q: durante la prima lezione sono stati citati tanti siti, e non ho fatto in tempo a segnarli tutti. Dove posso ritrovare i riferimenti?
A: la maggior parte dei siti citati sono nelle slides della lezione. Altri li trovate in fondo al post di quella prima parte.
Q: interessante quello che avete mostrato, ma io volevo fare app per Android, e non tanto giochi
A: se l’idea è realizzare applicazioni e NON giochi il discorso cambia completamente. E’ praticamente impossibile fare app davvero multipiattaforma perché ogni sistema pretende (giustamente) che vengano utilizzati gli elementi della UI di sistema (perché le app abbiano tutte lo stesso look&feel) – quindi, nel caso, oltre al codice multipiattaforma per il core del vostro progetto, vi toccherà specializzare una parte più ampia in modo che sfrutti quanto disponibile. Tra l’altro, tenendo conto che l’interazione con il sistema diventa più importante, l’uso di C/C++ non è più così consigliato – suggerendo piuttosto di usare java per Android e Object-C per iOS.
Q: la seconda lezione ha dato una idea della programmazione multipiattaforma (in cui le parti di I/O, logica di gioco e accesso a grafica e suono sono separate) – ma io vorrei vedere la cosa più in dettaglio, magari leggendo qualcosa. Come posso fare?
A: quello che abbiamo mostrato è la nostra gestione (tra l’altro, una versione semplificata) di questo paradigma – che però è ovviamente comune a tante altre librerie/framework – una parte delle quali sono state citate nella prima lezione. Se volete avere esempi più completi e strutturati (una volta che avete dato una scorsa alla cosa con la lezione di ieri) potete affrontare una qualunque di quelle (fornite non solo di esempi, ma di norma anche di manuali).
Q: quali sono i limiti del “motore” sotto l’esempio di PacMan? Cosa devo sapere se voglio usarlo, modificandolo, per fare un mio gioco?
A: quella versione ha poche funzioni disponibili (anche se adatte per fare la maggior parte dei giochi 2D). I limiti riguardano il tipo di texture che è in grado di caricare (TGA a 32bit – quindi anche con eventuale trasparenza) e i suoni (solo WAV raw). Vedremo di fornire (nel prossimo esempio) una versione in grado di caricare anche almeno un altro formato file.
Q: quali sono i limiti dell’approccio che avete mostrato? ho visto cose belle e semplici realizzabili con sistemi più evoluti, le posso fare anche con il vostro sistema?
A: premesso che non è il nostro sistema (ma un approccio comune allo sviluppo di giochi multipiattaforma, semplicemente mostrato con codice scritto da noi), no, non ci sono limiti astratti. Se l’avete visto fare con un linguaggio evoluto, si può fare (con più o meno difficoltà, e in più o meno tempo) anche in C/C++. E’ possibile piuttosto il contrario (che ci siano limiti usando sistemi evoluti, bypassabili usando direttamente il C/C++). Ed è invece vero che possono esserci limiti (ce ne sono e tanti) nella implementazione che vi abbiamo reso disponibile (che è un esempio semplificato – non un framework completo).
Q: quello che mostrate è pure interessante, ma io preferisco usare un sistema RAD, dove faccio prima a fare tutto e non mi devo preoccupare dei dettagli. E penso che la mia sia la scelta migliore, concordate?
A: non c’è una scelta migliore in assoluto. Usare un sistema RAD (con linguaggi script) ha indubbi vantaggi (ne abbiamo appunto parlato all’inizio della prima lezione). Ma lavorare a basso livello fornisce più flessibilità e competenze – nel caso si voglia fare anche altro – e permette di essere multipiattaforma anche su target non (già) gestiti dal sistema RAD (che è stato programmato chiaramente NON con un sistema RAD a sua volta). Tra l’altro, nello sviluppo di giochi di norma l’aspetto di gestione delle meccaniche di gioco (e la creazione delle risorse e la sceneggiatura e il resto legato al gioco prima che al programma) dovrebbero essere la parte principale – e quelle non saranno così diverse da realizzare con un RAD o in C/C++, se non per la presenza di tool predisposti per compiti specifici (tool, come un map maker, che possono essere usati anche senza che siano inclusi in un ambiente RAD).
Q: durante la lezione hai usato Code-Blocks come IDE per il progetto di PacMan. E’ l’ambiente che consigliate di usare quindi?
A: no (o almeno non necessariamente). Code-Blocks è stato usato perché ne esiste una versione portable che funziona completamente da chiavetta USB – e perché (essendo relativamente minimale) è la controprova che per fare giochi NON serve un sistema particolarmente evoluto o complesso. Consigliamo di usare l’ambiente di sviluppo che preferite. Noi usiamo Visual Studio (per la programmazione sotto Windows), Eclipse (per compilare per Android) e X-Code (per lavorare su iOS).
Q: dove posso scaricare quello che mi serve per compilare su Android?
A: eclipse+adt budle e sdk: https://developer.android.com/sdk/index.html
cygwin (dalla 1.7+): http://www.cygwin.com/
ndk: https://developer.android.com/tools/sdk/ndk/index.html
openAL-soft x android: https://github.com/AerialX/openal-soft-android
Volevo chiedere ma e’ comunque possibile realizzare il gioco per esempio con le librerie allegro o sdk per poi implementarli per android? Se si, in che modo?
Non c’è una risposta generica: programmando in C/C++ si possono usare svariati SDK (ne abbiamo elencati alcuni anche durante la prima lezione) – e il passaggio su Android del risultato dipende dal fatto che quello specifico SDK sia Android-compatibile (o opensource, e che tu sia in grado di adattarlo).
Ma parlando esplicitamente di Allegro, comunque, sì, la versione 5.1 (solo quella) ha anche il supporto per Android. Ti consiglio di dare una occhiata alla documentazione ufficiale (http://alleg.sourceforge.net/readme.html) per i dettagli della compilazione per quel target specifico.