Bubble Touch ! un videogame made in italy oggi disponibile in appstore…! Ci hanno messo piu’ di un anno, ma la loro idea, la loro passione li ha portati a termine.. probabilmente non con pochi problemi, indecisioni, e situazioni che nel corso di questi 2 anni hanno rivoluzionato il mondo iPhone, e dei developer in generale.

Un simpatico gioco, adatto ai piu’ piccoli ma divertente anche per i piu’ adulti, da livelli base (easy) per passare sempre piu’ a livelli avanzati alla ricerca della Bubble da toccare !!

Bella grafica, fluida.. e ottima giocabilita’… ma che dire… a sentire gli autori pochi giorni fa… se da un lato si aspettano e hanno avuto un discreto successo, dall’altro guardano ai piccoli errori, e a quella che potrebbe gia’ diventare una nuova versione di Bubble Touch !.

Speriamo che presto ci vogliano raccontare tutti i retroscena di questa bella avventura tutta italiana e delle esperienze positive e negative che hanno vissuto…

Nel frattempo vi riepilogo gli articoli che hanno dato inizio a questa avventura :

Bubble Touch dei gemelli PiXy e BugMaN … inizia l’avventura !

Bubble Touch per iPhone e la definizione del progetto.

Voglio fare un gioco per iPhone anch’io, come posso iniziare ? da Bubble Touch, PiXy ci dice come

Gestione file XML su iPhone / iPod Touch (BubbleTouch)

Diario di un videogame per iPhone: Bubble Touch ! per iPhone and Go.

Per ora e’ tutto

iPhoneandGo.

P.s. Per chi e’ curioso, e desideroso di acquistare questa bella applicazione questo e’ l’appstore link.

Hanno molte cose ancora da raccontarci ed oggi ci vogliono spiegare un argomento molto specifico e tecnico: l’ottimizzazione delle texture utilizzando il formato PVR.

Oggi parliamo di Texture con particolare riguardo a qualche ottimizzazione che possiamo fare per i nostri
programmi che usano OpenGLES.

Di base l’Iphone SDK supporta vari formati grafici e come molti di voi sanno di solito viene usato il formato PNG per gestire le texture.

Quello che proponiamo con questo tutorial è l’utilizzo di un formato non molto noto ma che ha molti vantaggi se utilizzato in certi casi.

Il formato in questione è il PVR in particolare PVRTC compression format che devira da PowerVR, analizziamo brevemente vantaggi e svantaggi che si hanno nell’utilizzare tale formato.

I vantaggi ad utilizzare tale formato:
• riduce lo spazio richiesto dalla texture (è un formato compresso)
• minore spazio equivale a minore banda utilizzata e quindi caricamento della texture più veloce
• la decompressione della texture è fatta tramite l’hardware grafico messo a disposizione dall’Iphone / Ipod Touch ergo è più veloce
• caricamento e conversione molto facile da implementare

Mentre gli svantaggi / limiti sono:
• qualità più bassa (parliamo di texture compresse)
• altezza e larghezza della texture devono essere una potenza di 2
• altezza e larghezza della texture devono coincidere

Per quanto riguarda la creazione di texture in formato PVR l’Iphone SDK ha un tool al suo interno che permette di convertire
da formati grafici noti ( PNG, JPG, TIFF e altri ) al formato PVR il tutto tramite riga di comando da un semplice terminale.

Se abbiamo XCode con l’Iphone SDK installato nella cartella di default (/Developer/Platforms/) avremo allora il tool chiamato texturetool direttamente dentro la cartella /Developer/Platforms/Iphone.platform/Developer/usr/bin/.

Texturetool permette di creare 4 varianti del formato PVRTC, in base a queste possiamo quindi trovare un buon compromesso tra compressione e perdita di qualità.

I parametri da passare a texturetool sono molto semplici e li possiamo vedere anche attraverso l’help del programma stesso:
user$ texturetool -h
Usage: texturetool [-hlm] [-e ] [-p
] -o [-f
] input_image
-h Display this help menu.
-l List available encoders, individual encoder options, and file formats.
-m Generate a complete mipmap chain from the input image.
-e Encode texture levels with .
-p
Output a PNG preview of the encoded output to
. Requires -e option.
-o Write processed image to .
-f
Set file
for image.

In particolare come encoder utilizzeremo proprio PVRTC mentre possiamo giocare con il formato scegliendo tra PVR o RAW con le seguenti opzioni aggiuntive:
–channel-weighting-linear
–channel-weighting-perceptual
–bits-per-pixel-2
–bits-per-pixel-4
Di base se lanciamo texturetool senza specificare opzioni avremo il formato –bits-per-pixel-4, –channel-weighting-linear.

Per convertire un ipotetico file prova.png in prova.pvr (con formato a 4bpp (bits per pixel)) scriviamo:
texturetool -e PVRTC -f PVR –channel-weighting-linear –bits-per-pixel-4 -o prova.pvr prova.png

Vediamo dal punto di vista della grandezza quanto conviene:

Ad esempio una texture a 32bpp di dimensioni 256×256 occupa non compressa circa 256kb, se usiamo una compressione a 4bbp avremo
una texture che occupa 32kb più qualcosina per l’header del formato .pvr.

Per il caricamento delle texture dentro la nostra applicazione utilizziamo un’estensione di OPENGLES chiamata glCompressedTexImage2D;
in particolare per chi ha accesso al Developer Connection di Apple è presente una classe PVRTextureLoader che fa già tutto quello che ci serve
per caricare texture compresse in PVR.

Per voi e’ tutto i ragazzi PiXy e BugMaN…e un ringraziamento da Sir. Lodux !

BugMaN: In questo mese, visto il poco tempo a disposizione, abbiamo continuato a sviluppare la parte di gestione dei Menù: in particolare
oltre al lavoro svolto a Febbraio si è cercato di dare un volto ai menù relativi agli obiettivi di ogni singolo livello e ai risultati una
volta che il livello è stato completato.

Ma vediamo con ordine cosa abbiamo realizzato:

Codice:

Scelta del pianeta:

Ora i pianeti attivi danzando allegramente mentre quelli ancora non sbloccati non saranno visualizzabili e quindi selezionabili finché
non si completano tutti i livelli (in tutto 9) del pianeta precedente.

E’ stato cambiato il tasto per tornare al menù principale (ma ancora non ci siamo!!!).

Scelta del livello:

PiXy ha realizzato un nuovo font (versione black e versione white) che utilizzeremo per tutto il gioco.
Ora per la realizzazione di questa schermata (e anche di altre) è stata aggiunta alla classe che gestisce i menù
la possibilità di gestire dei piccoli widgets esterni che hanno anche la possibilità di essere animati.

Se l’utente fa clic (in questo caso touch) su un tassello che compone un livello, sulla destra vengono visualizzati
nome, punteggio e stelle (un modo immediato per sapere come si è finito precedentemente il livello).

Il tasto Play permette di giocare il livello selezionato mentre con Back si torna alla scelta dei pianeti.

Obiettivi:

Una volta scelto un livello apparirà una schermata che riassume gli obiettivi da raggiungere per completarlo:
• In alto avremo nome del livello e stelle (se è già stato completato/giocato)
• Al centro troviamo il numero di palline da colpire (per ogni colore)
• In basso abbiamo invece:
• la direzione da dove escono le palline
• il numero totale di palline
• il tasto play per giocare il livello

Risultati:

In base al raggiungimento degli obiettivi abbiamo 2 schermate differenti.

La prima è “Level completed” che appare in caso di superamento del livello, in questa
schermata sono state realizzate le animazioni delle varie zone ma mancano ancora da inserire
le statistiche e il punteggio in stelle.

La seconda è utilizzata in caso non si raggiunga l’obiettivo… non abbiamo ancora deciso
se visualizzare le statistiche o meno.

BugMaN: Dal solo punto di vista del codice abbiamo:
• Convertito tutti gli sfondi nel formato PVR (ne parleremo nella prossima puntata)
• studiato possibilità per implementare la gestione dell’Audio tramite OpenAL
• iniziato a studiare e valutare l’utilizzo di Facebook Connect

Design:

Bonus (Bubble)

PiXy: Finalmente durante il mese di Marzo abbiamo definito una lista completa dei bonus che saranno presenti all’interno
del gioco. Tutti questi bonus prenderanno il nome di Bubble, in quanto saranno racchiusi tutti all’interno
di una bolla.
Il nome del gioco Bubble Touch, vuole proprio indicare che saranno loro i protagonisti, in quanto renderanno
il gioco divertente e pieno di imprevisti.
Come gia’ accennato nelle puntate precedenti, all’interno del gioco sara’ presente una “Bubble Gallery” dove
potremmo guardare tutte le bolle che abbiamo scoppiato e capire bene quali sono i loro effetti.

Definito il design dei bonus ho subito pensato a fare una prima bozza grafica per ognuno di loro, alcune Bubble
sono venute proprio bene e credo le manterro’ anche nella versione definitiva, altre sono sicuramente da sistemare.

Ecco, in anteprima, un’immagine in cui sono presenti tutti i bonus :

Grafica:
Mappe dei pianeti

PiXy: Durante la fine del mese ho incominciato a lavorare alle mappe dei 5 pianeti, in particolare alle immagini che
saranno poi suddivise in nove parti (una per livello) e che si comporanno quando il giocatore avra’ completato
un intero pianeta.

Musica:

PiXy: Abbiamo pensato di avere una soundtrack musicale differente per ogni pianeta, ho quindi incominciato a comporre
qualcosina. Per realizzare la musica del gioco sto utilizzando MilkyTracker, un’applicazione open source che si rifa’
al buon vecchio FT2 (Fast Tracker 2).
I tracker in genere sono software che fanno da sequencer e servono per comporre musica utilizzando campioni sonori
(ad esempio file .wav) da disporre all’interno di pattern.
Un pattern altro non e’ che un “foglio” di musica, formato da differenti righe che viene suonato sequenzialmente.
Maggiori informazioni su programmi di questo tipo le potete trovare qui: http://en.wikipedia.org/wiki/Tracker

per voi Sir. Lodux !

Box2d è un simulatore di corpi rigidi in 2D sviluppato in C++. E’ molto utile perché permette in poche righe di creare un motore fisico e quindi al posto di crearsi tutte quelle routine per l’animazione degli oggetti lasciamo ad Dott. Isaac Newton di farlo per noi attraverso le regole della Fisica

Caratteristiche del motore fisico:

Collision

• Continuous collision detection.
• Contact callbacks: add, persist, remove.
• Convex polyons and circles.
• Multiple shapes per body
• One-shot contact manifolds
• Incremental sweep-and-prune broadphase
• Efficient pair management
• Fast broadphase AABB queries
• Collision groups and categories

continua…

Physics

• Continuous physics with time of impact island solver.
• Persistent body-joint-contact graph
• Island solution and sleep management
• Contact, friction, and restitution
• Stable stacking with a linear-time solver
• Revolute, prismatic, distance, pulley, gear, and mouse joints
• Joint limits, motors, and friction
• Momentum decoupled position correction
• Fairly accurate reaction forces/impulses

System

• Small block and stack allocators
• Centralized tuning parameters
• Highly portable C++ with no use of STL containers

Testbed

• OpenGL with Freeglut
• Graphical user interface with GLUI
• Easily switch between tests using GUI
• Test framework for easily adding new tests
• Mouse picking and the bomb!
• VC8 project files

In particolare il TestBed ha anche un progetto per Xcode così da poter provare su Macosx
i vari esempi (sono tanti e tutti documentatissimi).

Dicevamo che è scritto in C++, in particolare la maggior parte delle funzioni e dei tipi iniziano con il prefisso b2.

E’ facilmente integrabile in qualunque progetto per Iphone, vediamo brevemente quali sono i passi da compiere per crearsi un progetto che abbia un motore Box2d al suo interno.

1) Scaricarsi il codice sorgente di Box2d da http://sourceforge.net/projects/box2d

Attualmente la versione è la 2.0.1  (13 Aprile 2008)

2) Scompattare il tutto su una cartella

3) Creare o aprirsi un progetto Xcode (magari uno che abbia una vista OpenGLEs)

4) Copiare (anche tramite drag & drop) la cartella Source dentro il nostro progetto Xcode

5) Nella propria view includere l’header di Box2d

#include “Box2D.h”

6) Rinominare il file della view in .mm (per mischiare C++ e objective C)

7) Inizialiare un mondo prima di procedere con l’attivazione della vista OpenGLES

Qualcosa di simile:

Da qualche parte definisco le variabili:

b2AABB worldAABB;
b2World *m_world;

E poi l’init del mondo è :

// inizializzo le coordinate del mondo
worldAABB.lowerBound.Set(-100.0f, -100.0f);
worldAABB.upperBound.Set(100.0f, 100.0f);

// Definisco il vettore di gravità
b2Vec2 gravity(0, -9.81f);

// Do we want to let bodies sleep?
bool doSleep = true;

// Costruisco il mondo
m_world= new b2World(worldAABB, gravity, doSleep);

// Definisco il corpo ground (terreno)
b2BodyDef groundBodyDef;
groundBodyDef.position.Set(0.0f, -15.0f);

// Call the body factory which allocates memory for the ground body
// from a pool and creates the ground box shape (also from a pool).
// The body is also added to the world.
b2Body* groundBody = m_world->CreateBody(&groundBodyDef);

// Define the ground box shape.
b2PolygonDef groundShapeDef;

// The extents are the half-widths of the box.
groundShapeDef.SetAsBox(50.0f, 10.0f);

// Add the ground shape to the ground body.
groundBody->CreateShape(&groundShapeDef);

8 ) Nel main loop (se vogliamo la DrawView della nostra vista OpenGLES) faccio avanzare
la fisica del mondo:

float32 timeStep = 1.0f / 60.0f;
int32 iterations = 10;

// Instruct the world to perform a single step of simulation. It is
// generally best to keep the time step and iterations fixed.
m_world->Step(timeStep, iteration);

(timeStep può essere benissimo animationInterval che usiamo per la view)

9) a questo punto si possono creare oggetti e usando una draw adatta disegnarli per vedere cosa
succede, per esempio se mi creo un cerchio in questo modo:

posX e posY sono la posizione del cerchio
m_body è un oggetto (body) inizializzato così: b2Body *m_body;
m_world è il nostro mondo creato in precedenza
ang è l’angolo di rotazione (in radianti)

// Define the dynamic body. We set its position and call the body
b2BodyDef bodyDef;

bodyDef.position.Set(posX, posY);
bodyDef.angle = ang; // the body’s angle in radians.
//bodyDef.linearDamping = 0.0f;
//bodyDef.angularDamping = 0.01f;
//bodyDef.isBullet = false;
bodyDef.angularDamping = 0.02f;

m_body = m_world->CreateBody(&bodyDef);

// Define box shape for our dynamic body.
b2CircleDef circleDef;

// Set the box density to be non-zero, so it will be dynamic.
circleDef.density = 1.0f;

// Override the default friction.
circleDef.friction = 0.3f;

// Add the shape to the body.
m_body->CreateShape(&circleDef);

// Now tell the dynamic body to compute it’s mass properties base
// on its shape.
m_body->SetMassFromShapes();

Se vedete il codice al body va associato uno shape che sarà poi la forma che permette di controllarne la fisica, le collisioni e molto altro.
Se poi vogliamo disegnare questo oggetto procediamo in opengles a disegnare uno Sprite (c’e’ l’esempio dell’SDK che puo’ tornare utile) con la posizione corretta che prendiamo in questo modo:

// Vettore posizione del body:

b2Vec2 position = m_body->GetPosition();

// X sarà position.x e Y sarà position.y

// Angolo di rotazione del body

float32 angle = m_body->GetAngle();

Una volta presi questi parametri il disegno dell’oggetto è semplicemente tuto codice openGLES:

glPushMatrix();

glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, spriteTexture);

if(m_isBlend) {
// Set a blending function to use
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
// Enable blending
glEnable(GL_BLEND);
}

glTranslatef(position.x, position.y, 0.0f);
glRotatef(angle*(180/b2_pi), 0.0, 0.0, 1.0f);

glVertexPointer(2, GL_FLOAT, 0, m_vertices);
glEnableClientState(GL_VERTEX_ARRAY);

// va tolto il colore se è textured!!! SI MA LO FACCIO SU SETTEXTURE
glColor4f(m_color_r, m_color_g, m_color_b, 1.0);

glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

if(m_isBlend) {
glDisable(GL_BLEND);
}

if(m_isTextured) {
glDisable(GL_TEXTURE_2D);
}

glPopMatrix();

Per voi BugMan e un caloroso ringraziamento da Sir. Lodux !

Durante il mese di Febbraio il gioco non ha subito grosse evoluzioni dal punto di vista del gameplay.
Questo perchè abbiamo preferito concentrarci sui menu, sulla pulizia e il refactoring (mettere a fattor comune classi e metodi) del codice. Inoltre abbiamo cercato di rendere il codice sorgente molto piu’ corto, leggibile e semplice da usare. Tutti gli sforzi fatti sicuramente andranno ad incidere positivamente anche per i mesi successivi e per i prossimi giochi (se ce ne saranno) che potranno riutilizzare il codice scritto per Bubble Touch.
Ma vediamo nel dettaglio cosa e’ stato fatto questo mese:

•    Menu del gioco

Finalmente abbiamo completato il design del menu principale, e dei sottomenu utili per accedere e poter giocare ad un livello. L’idea e’ quella di rendere i menu facilmente intuibili ed utilizzabili, senza troppe spiegazioni e perdite di tempo.
Personalmente crediamo che un gioco per iPhone deve essere semplice e facile da usare, fin dal suo primo utilizzo: i primi 3/4 minuti di gioco devono impressionare chi gioca, e devono puntare quindi tutto su semplicita’ e giocabilita’.
Questo e’ ancora piu’ importante per Bubble Touch, che puo’ essere giocato anche per 2/3 minuti alla volta.

•    Bottone Play

Una volta cliccato sul bottone Play appare la schermata di selezione del pianeta:

Molto semplicemente i pianeti selezionabili appaiono nel loro “splendore” danzando, mentre per i pianeti non ancora sbloccati vedremo un’ombra.  Ogni pianeta è composto da 9 livelli che si sbloccheranno in ordine cronologico man mano che per ogni livello si raggiunge l’obiettivo prefissato.
Dopo aver scelto il pianeta (all’inizio del gioco sarà possibile solo giocare sul Blue Planet)  si accede alla selezione del livello:

Come gia’ descritto nel design, il livello e’ rappresentato con una mappa divisa in 9 singoli pezzi. I pezzi completati mostrano una parte di disegno che si andra’ a formare interamente quando il pianeta sara’ totalmente completato, mentre se un livello è disponibile ma non ancora “superato” il pezzo di mappa apparirà oscurato.
Selezionando un livello (con un clic – touch) sulla destra appariranno delle statistiche.
In particolare vedremo il numero del livello (Livello 1-1 nell’esempio in figura), un  bottone Play per poter giocare e se il livello è stato superato il punteggio massimo ottenuto.
La grafica di questa sezione e’ ancora in via di sviluppo, si possono notare le stelline che abbiamo deciso di utilizzare per sapere se il punteggio raggiunto è buono o meno.
Il box in grigio che vedete in figura rappresenta lo spazio dedicato al bottone Play che ancora non è stato disegnato graficamente.

•    Pagina dei risultati

Stiamo ancora lavorando sulla pagina dei risultati che apparira’ quando il giocatore ha terminato un livello.
Uno screenshot ancora in fase di costruzione che puo’ dare un’idea di come saranno presentati i risultati è il seguente:

In particolare in alto troveremo il risultato (livello completato o meno) mentre nel riquadro ora vuoto avremo le statistiche di bolle colpite divise per colori. Lo spazio dedicato alle stelle ci darà un valore visivo del punteggio che invece apparirà nella zona in basso subito dopo la scritta “Score:”.  Infine il pulsante “Map” farà tornare il giocare alla schermata di selezione del livello.

•    Supporto Texture PVR e Texture Atlas

Durante la fase di pulizia del codice ne abbiamo approfittato per migliorare la gestione delle texture atlas ed inserire il supporto per le texture PVR .
Probabilmente abbandoneremo il formato .png in favore del formato PVR in modo da occupare meno spazio su disco e migliorare le perfomance.
Inoltre abbiamo concluso l’implementazione del Texture Manager inserendo la possibilità di usare i Texture Atlas per ottimizzare il numero di immagini da gestire.

PiXy & BugMaN / PixMapBrothers per iPhone and Go….

un ringraziamento da sir. Lodux !

XML (eXtensible Markup Language) e’ un linguaggio (o meglio un meta-linguaggio) di markup (come ad esempio HTML, utilizzato per strutturare le pagine web)
che puo’ essere utilizzato per memorizzare e gestire dati di qualunque tipo.
Come per il linguaggio HTML un file XML e’ quindi composto da una serie di tag.

Un tag, nel nostro caso, non rappresenta la firma di un writers, ma e’ un elemento sintattico che serve
per strutturare un documento XML (o anche HTML).
Un tag ha sempre un nome, puo’ avere degli attributi, e contenere anche dei dati (caratteri).

Alcune piccole regole:

- i tag non possono iniziare con numeri o caratteri speciali e non possono contenere spazi;
- i tag devono essere bilanciati, ogni tag aperto deve essere chiuso e non sono consentiti errori di annidamento, ad esempio:

<rubrica>
<nome>Mario</nome>
<cognome>Rossi
</rubrica>

il tag cognome non e’ stato chiuso quindi l’XML non e’ ben formato.

Un tag generico ha quindi la seguente sintassi:

<nometag attributo1=”valore1″ attributo2=”valore2″>  caratteri… </nometag>

oppure, in forma abbreviata (nel caso in cui il tag non contenga nessun dato/carattere) :

<nometag attributo1=”valore1″ attributo2=”valore2″ />

In un file XML i tag non appartengono ad un insieme prefissato e limitato (come nel caso dell’HTML)
ma possono essere di qualunque tipo e forma in base all’esigenze dell’utente.

La prima riga di un file XML, chiamata solitamente prologo,
serve a definire la versione in uso e la specifica standard per la sua corretta
implementazione.

Infine ogni file XML deve contenere un unico elemento che racchiude tutti gli altri (chiamato elemento radice (root)).

Un esempio completo di un XML ben formato e’ il seguente:

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<utenti>
<utente>
<nome>Luca</nome>
<cognome>Ruggero</cognome>
<indirizzo>Milano</indirizzo>
</utente>
<utente>
<nome>Max</nome>
<cognome>Rossi</cognome>
<indirizzo>Roma</indirizzo>
</utente>
</utenti>

2. Quando posso utilizzare l’XML all’interno di un’applicazione per iPod Touch/iPhone ?

Per la gestione dei dati tre sono le possibili alternative, entrambi molto semplici da utilizzare:

1. Utilizzare file XML
2. Utilizzare file sqlite (database)
3. Utilizzare i file di plist (property list)

Mentre le property list sono piu’ appropriate per salvare le opzioni dell’applicazione, e l’utilizzo di un file
sqlite, quindi di un database, e’ consigliato quando la mole di dati e’ molto vasta ed e’ necessario effettuare delle ricerche,
l’XML puo’ essere utilizzato per piccole quantita’ di dati da memorizzare, o per comunicare con applicazione esterne.

Nel nostro gioco (Bubble Touch), per fare un esempio concreto, stiamo utilizzando file XML per gestire la configurazione dei livelli (tipi di palline presenti,
bonus, malus, oggetti presenti sullo sfondo, obiettivo del livello) e anche lo stato del gioco (livelli completati, punteggi).

Questo ci permette di creare e modificare il comportamento di un livello semplicemente editando un file XML senza la necessita’ di dover
ricompilare ogni volta tutta l’aaplicazione.
Inoltre in questo modo potremmo benissimo creare un editor di livelli (su Mac o anche su PC) che permette di gestire i parametri di un livello
attraverso un’interfaccia grafica e salvarli poi nel formato XML (che ricordiamo e’ semplicemente un file di testo).

3. Come si usa ?

Per scrivere un file XML basta un qualunque editor di testo, cosi’ come a livello di codice, basta preparsi una stringa e salvarla poi su file.
Solitamente i file XML hanno un estensione .xml.

Per leggere un file XML e’ necessario effettuare il riconoscimento dei tag, dei loro attributi e dei caratteri che li contengono.
Come durante la compilazione di un linguaggio di programmazione devono essere riconosciuti i costrutti, le istruzioni e verificata la sintassi, allo
stesso modo dobbiamo fare noi con il nostro file XML.

La verifica della correttezza e della validita’ del file XML (fase successiva) la tralasciamo in quanto richiederebbe maggiori spiegazioni.

4. Parsing

La prima fase, riconoscere i tag, gli attributi e i dati, viene chiamata (come per i linguaggi di programmazione) parsing.
Il parsing analizza una stringa e cerca di ricavare la sua struttura grammaticale, il parser e’ l’oggetto che si occupa di fare questa operazione.

Per poter effettuare il parsing di un file XML solitamente si utilizzano due differenti tipi di interfacce, presenti ed implementate
nella maggior parte dei linguaggi di programmazione:

1. SAX (Simple API for XML)
2. DOM (Document Object Model)

Cocoa Touch mette a disposizione una classe NSXMLParser che permette di analizzare XML utilizzando l’interfaccia SAX.
In Cocoa esiste anche una classe NSXMLDocument che permette di utilizzare l’interfaccia DOM ma non e’ stata inclusa nelle librerie per iPhone (Cocoa Touch).
Sono presenti inoltre molte altre librerie esterne (lib2xml, touchXML, TouchJSON) che permettono di utilizzare anche l’interfaccia DOM e hanno
alcuni vantaggi in termini di perfomance.

5. Il parser SAX : NSXMLParser

NSXMLParser e’ una classe figlia di NSObject (ovviamente) che, come acccennato ci permette di utilizzare l’interfaccia SAX.

Questa interfaccia lavora, leggendo il file XML linea per linea ed e’ basata su eventi.
Durante la lettura al verificarsi di un evento (ad esempio: apertura di un tag, chiusura di un tag, etc..) viene chiamata una funzione specifica
che puo’ gestirlo. Tale funzione prende il nome di handler.

I vantaggi dell’interfaccia SAX sono principalmente legati alla velocita’ e all’utilizzo di memoria (pensate che l’interfaccia DOM costruisce un vero e proprio albero
in memoria che contiene tutta la struttura XML). Con tale interfaccia non e’ possibile scrivere file XML ma solamente leggerli e processarli.

Allora NSXMLParser, essendo un parser SAX, itererà tra tutti gli elementi presenti all’interno del file XML.
Tecnicamente utilizza un delegato per invocare i metodi al verificarsi degli eventi descritti precedentemente.

Ci sono tre metodi che bisogna implementare nella classe che dovrà leggere il file XML:

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string

Come suggerito dal loro nome didStartElement viene chiamato quando si incontra l’inizio di un tag, didEndElement alla fine di un tag, e foundCharaters serve per poter
ottenere il dato (solitamente caratteri) contenuto all’interno di un elemento (tag).

Incominciamo dal primo metodo: didStartElement

Questo metodo viene chiamato ogni volta che il parser incontra un nuovo tag.
Il puntatore elementName ci dà il nome dell’elemento. Se abbiamo ad esempio un elemento del tipo

<Nominativo Nome=”Angelo Cognome=”Moriconi”></nominativo>

o in forma abbreviata,

<Nominativo Nome=”Angelo” Cognome=”Moriconi />

che non contiene caratteri e ha due attributi, il codice all’iterno di didStartElement per poter prendere il valore dei due attributi sarà il seguente:

if([elementName isEqualToString:@"Nominativo"])
{
std::string nome = [[attributeDict objectForKey:@"Nome"] cString];
std::string cognome = [[attributeDict objectForKey:@"Cognome"] cString];
}

Come potete vedere attributeDict e’ un dizionario che contiene la lista di tutti gli attributi, e con il metodo objectForKey:key possiamo attingere al valore dell’attributo con chiave key.
Tale metodo ci ritorna un oggetto NSString. Nell’esempio tale oggetto è stato convertito in una stringa std (libreria standard del linguaggio c++).

Quindi quello che faremo all’interno di didStartElement solitamente si tradurrà in una serie di if in cascata (per controllare l’inizio di ogni elemento) dove, una volta riconosciuto il tag dato il suo nome possiamo procedere alla memorizzazione dei dati.

Nell’esempio non facciamo assolutamente nulla, possiamo comunque ricostruire la nostra struttura dati passo dopo passo all’interno di questo metodo.

Il metodo didEndElement viene invece utilizzato in maniera simmetrica quando arriva un evento di tag chiuso.
Utilizzato in combinazione con didStartElement ci permette di capire quando abbiamo finito di memorizzare i nostri dati e possiamo finalmente salvarli sulla nostra struttra.

Se ad esempio abbiamo un XML del tipo:

<DatiAnagrafici>

<Nome value=”Angelo” />
<Cognome value=”Moriconi” />
…
…
</DatiAnagrafici>

Possiamo memorizzarci tutti i dati in delle variabili, e, quando l’elemento DatiAnagrafici è terminato possiamo poi salvarci la nostra struttura sulle classi che stiamo utilizzando nella nostra applicazione.

Il metodo foundCharacters viene chiamato anche più di una volta all’interno dello stesso tag, conviene quindi utilizzare una NSMutableString
che deve essere rinizializzata ad ogni nuovo elemento e chiamare il metodo appendString: per poter memorizzare correttamente tutto il contenuto presente all’interno di un elemento.

Come facciamo a creare una classe ed utilizzare i delegati per leggere il file XML ?

Molto semplicemente basta definire una classe figlia di NSObject che può avere anche un solo metodo:

@interface XMLReader: NSObject

- (BOOL)parseXMLFile:(NSString *)URL;

@end

Nel file .m possiamo poi implementare il metodo parseXMLFile facendo in modo che la nostra classe XMLReader sia un delegato di NSXMLParser:

- (BOOL)parseXMLFile:(NSString *)URL
{
//Bisogna convertire il file in una NSURL altrimenti non funziona
NSURL *xmlURL = [NSURL fileURLWithPath:URL];

// Creiamo il parser
NSXMLParser *parser = [[ NSXMLParser alloc] initWithContentsOfURL:xmlURL];
// Il delegato del parser e’ la classe stessa (self)
[parser setDelegate:self];
[parser setShouldProcessNamespaces:NO]; // Non utilizziamo namespace
[parser setShouldReportNamespacePrefixes:NO];
[parser setShouldResolveExternalEntities:NO]; // Vogliamo solamente i dati e non altro…
// Effettuiamo il parser
[parser parse];
// Rilasciamo l’oggetto NSXMLParser
[parser release];
return YES;
}

Infine, sempre nel file .m dovremo implementare i 3 metodi sopra descritti:

- (void)parser:(NSXMLParser *)parser
didStartElement:(N SString *)elementName
namespaceURI:(NSString *)namespaceURI
qualifiedName:(NSString *)qName
attributes:(NSDictionary *)attributeDict
{
NSLog(@”Inizio elemento: %@”, elementName);
}

//—————————————————————————-

- (void)parser:(NSXMLParser *)parser
didEndElement:(NSString *)elementName
namespaceURI:(NSString *)namespaceURI
qualifiedName:(NSString *)qName
{
NSLog(@”Fine Elemento: %@”, elementName);
}

//—————————————————————————-

// ATT: Questo metodo viene essere chiamato più volte all’interno dello stesso elemento
- (void)parser:(NSXMLParser *)parser
foundCharacters:(NSString *)ch
{
NSLog(@”carattere: %@”, ch);
}

Esiste poi un ulteriore metodo che ci permette di scovare eventuali errori durante il parser:

//—————————————————————————-

- (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError *)parseError {
NSLog(@”ERROR:%@”, [parseError localizedDescription]);
}

Con questo è tutto !

PiXy / PixMapBrothers e un ringraziamento da sir. Lodux !

LINGUAGGIO DI PROGRAMMAZIONE:

Molto semplicemente, se si conosce gia’ qualcosa di C / C ++ conviene utilizzare direttamente questo linguaggio ed impararsi i costrutti e i fondamenti di Objective-C.
Objective-C deve essere necessariamente utilizzato per poter comunicare direttamente con le API del dispositivo e gestire il suo HW (ad esempio per poter creare una view che contiene una finestra OpenGL ES, oppure per poter gestire il touch (o il multitouch), l’accellerometro, … ).

Se non si conosce nessun linguaggio tanto vale imparare l’objective-c da 0.

Quali sono i vantaggi e gli svantaggi di una scelta (C/C++) piuttosto che l’altra (Objective-C) ?

Principalmente la portabilita’. Se scrivo un codice C++, utilizzando le librerie standard il gioco che scrivero’ sara’ molto facile da portare su altre piattaforme (anche su PC stesso) senza troppe modifiche. Per quanto riguarda i dispositivi mobili, windows CE (o mobile), il vecchio Symbian, o anche le stesse Qt (ora passate a Nokia) utilizzano estensivamente e in maniera completa il C++. Android di Google e’ l’unico sistema di API che attualemente utilizza Java e per cui il porting richiede la riscrittura di buona parte di codice.

Conoscendo solo l’Objective-C, per poter fare il porting (trasferire cioe’ l’applicazione da un dispositivo ad un altro) probabilmente ci sara’ molto piu’ lavoro da fare.

Ma non e’ che scrivere in Objective-C porta vantaggi nelle performance dell’applicazione ?

Assolutamente No. Il compilatore GCC e’ in grado di compilare allo stesso modo (ed anche in modo promiscuo) cocice C/C++ ed Objective-C. Molti sviluppatori non hanno trovato nessun calo dal punto di vista delle performance.

E’ possibile “mischiare” codice C++ ed Objective-C ?

Si ! Ed e’ quello che attualmente facciamo noi nel nostro gioco, se si conoscono e si utilizzano entrambi i linguaggi si puo’ prendere il meglio dall’uno e dall’altro e farli convivere tranquillamente.
Ad esempio il codice del nostro gioco che legge i livelli (che sono semplicemente file XML) utilizza il parser presente in Cocoa (la NSXMLParser ) fornendo metodi e comunicando con oggetti C++.

CONCLUSIONI:

Questi i nostri consigli:

Se si conosce gia’ il C++ incominciare ad imparare, quando serve e necessario, Objective-C (le basi sono comunque obbligatorie).

Se si hanno necessita’ e si pensa in futuro di riscrivere il codice per altri dispositivi pensare al C++ come linguaggio “primario”.

Se non si conosce nessun linguaggio e si vuole sviluppare solo per iPod /iPhone (ed al massimo Mac) imparare da 0 e per bene Objective-C.

OpenGL ES:

Se si vuole fare un gioco (sia 2D che 3D) penso la cosa migliore sia imparare ed utilizzare OpenGL ES.
OpenGL ES e’ un API (Application Programming Interface) di basso livello dedicata alla grafica tridimensionale e non solo.
E’ vero che per sviluppare una semplice applicazione 2D probabilmente anche le librerie messe a disposizione da Cocoa (nell’SDK di iPhone) potrebbero essere sufficienti, credo sia comunque meglio imparare OpenGL ES in quanto permette poi di poter sviluppare anche applicazioni 3D e sopratutto (cosa piu’ importante) comunicano a basso livello direttamente con il sottosistema grafico (scheda grafica + GPU).

Ci sono alcuni semplici esempi di utilizzo, basilare di OpenGL ES per una semplice applicazione 2D o 3D che possono essere “studiati”.

FISICA (physics engine):

Un buon gioco ha oramai anche un buon motore fisico alle spalle per gestire collisioni, interazioni tra oggetti, gravita’ , frizione, etc. etc.
Su iPhone vengono attualmente utilizzate due librerie:

* Box2D (nel prossimo articolo)
* Chipmunk (molto piu’ semplice e snella)

LIBRERIE AD ALTO LIVELLO:

Se volete utilizzare delle librerie (o motori grafici) di alto livello per sviluppare (evitando di dover imparare i concetti di basso livello) potete provare benissimo
Cocos2D (per il 2D) (che e’ scritta in Objective-C) o altre librerie gia’ esistenti per il 3D (simili).

AUDIO:

Per l’audio conviene utilizzare le librerie e le API messe a disposizione da Apple nell’SDK.
Ecco… per voi PiXy…! e un grazie da iPhone and Go.

PiXy e BugMaN hanno stilato un documento di nove pagine (fin’ora) molto dettagliato su quello che deve essere il concetto, la struttura, le sezioni, insomma tutto il necessario per argomentare tutti i punti che formeranno il gioco.

Si comincia con una descrizione tecnica, come l’orientamento del gioco, le opzioni di multiplayer o singleplayer, e le librerie da utilizzare BOX2d, OpenGLES; si passerà poi alla descrizione del gioco, come funzionerà, lo scopo, ecc; in seguito si troveranno le sezioni menu che comporranno il gioco e le loro specifiche.

Il documento che potrete facilmente scaricare da questo link e’ molto completo e ben fatto. PiXy e BugMaN nella loro avventura discutono, con domande aperte, su quelle che sono le soluzioni migliori da adottare per la realizzazione di Bubble Touch.

Ognuno di noi e’ libero di partecipare ponendo domande o semplicemente commentando ciò che sente nella speranza di dare un campo di prova molto importante prima della sua realizzazione completa finale !.

Per voi Sir. Lodux !

Ha inizio l’avventura, PiXy e BugMan ci racconteranno la loro esperienza, ci diranno come e’ nata la loro passione dei video games dai tempi del famoso C64 e dei giochi come Bubble Bobble, si racconteranno delle loro esperienze professionali e la loro sinergia come fratelli per realizzare i loro sogni comuni.

Impareremo !… Impareremo !… Bubble Touch e’ il loro videogame, si basa sulla fisica dei corpi 2D e la simulazioni di essi attraverso componenti disegnati appositamente per la loro realizzazione Box2d; PiXy e BugMaN ci insegneranno e mostreranno articolo dopo articolo, il codice necessario a realizzare queste splendide simulazioni in videogame.

Spero che tutti seguiranno insieme a me questo contributo e possano commentare ed aiutare PiXy e BugMaN in questa loro avventura!..

Sir. Lodux !