domenica 30 gennaio 2011

Primo design per theRoom

Ecco la prima foto del mio design per il gioco che sto pensando per la jam somanyrooms.
Sto lavorando a salti, purtroppo, con i figli ammalati è una fatica ma sono positivo nel riuscire ad procedere verso una meta.
Volevo cimentarmi su un platform, probabilmente seguendo l'esempio proposto dal sito, ma temo sarà un genere inflazionato. Inoltre il tempo è poco, sono (volutamente) solo e un platform richiede molto più lavoro.

Volevo sperimentare qualcosa di nuovo e credo di essere sulla strada giusta.
Diciamo che è qualcosa di completamente diverso dal solito e con molta meno grafica del solito, così posso concentrarmi completamente sullo spessore del design e sulla qualità globale.
O almeno credo.
Presto con altre news.

sabato 29 gennaio 2011

Ancora 48 ore -The room jam

Domani incomincia the room jam, organizzato da Alec Holowka e pensato da Devin Reimer.
É una jam di 48 ore in cui ogni gruppo di sviluppatori crea una propria "stanza", ovvero un personale mini gioco che verrà poi messo assieme a tutti gli altri con lo scopo di creare un maxi gioco.
Il linguaggio di programmazione obbligatorio è l'AS3, quindi rigorosamente FLASH, con un obbligatorio fade in e fade out dal nero per l'ingresso e l'uscita del gioco, così da creare un flusso continuo tra le stanze - qui la pagina di spiega.
Niente loading, niente controlli sui suoni, niente uso di mouse, niente immagini caricate da url esterne, il gioco deve essete dentro un unico file, controlli via freccine per il movimento e Z+X per le azioni di gioco.
La tipologia di gioco è libera, l'eventuale eroe dovrebbe quanto più simile possibile a quello proposto nella pagina. C'è anche un chiarissimo esempio, fatto in flash punk.
Dal sito si deve scaricare un pacchettino di classi pre-impostate come progetto per FlashDevelop, ben documentate e decisamente comode. Si può usare una qualsiasi libreria oppure ci sono 2 template personalizzati per Flixel e Flash Punk.
A fine progetto basta inviare l'swf realizzato e i propri dati.
Se tutto dovesse filare liscio il proprio mini gioco verrà infilato nel progetto globale assieme a tutte le altre stanze, messo online e probabilmente inserito anche dentro il Winnitron.

La home del sito della Jam è questa, ci si può ancora iscrivere, anche perché chi non potesse partecipare questo week end e andare a Winnipeg, può sempre farlo online e addirittura in un secondo momento stando sempre, però, dentro le 48 di sviluppo.
Alla fine mi sono iscritto. 48 ore le troverò.

giovedì 27 gennaio 2011

Senocular Transformation Tool

Se c'è un tool di cui non posso proprio fare a meno nel mio lavoro è il pacchetto di classi di Tween di greensock, il Tweenmax con tutta la sua famiglia.
Diciamolo, non solo è comodissima e zeppa di features, ma ha anche un'ottima curva di apprendimento con una logica davvero semplice e funziona davvero bene. La pagina di esempio è di una chiarezza disarmante, chiunque può in breve tempo capirne il funzionamento e le potenzialità.
(Tra parentesi, Jack Doyle, alias "mr green sock", nasce come autodidatta - pensare che sia riuscito a fare tanto la dice lunga).

Esiste però la possibilità di espandere ulteriormente le sue funzioni, ovvero entrando, pagando, a far parte del greensock club. Per quanto suoni (personalmente) come una promozione anni 90, in realtà offre un sacco di vantaggi e aiuti nello sviluppo.
Alcuni esempi: la classe LiquidStage per gestire il ridimensionamento del browser con swf fullscreen, splitTextField per la gestione di effetti su campi di testo e il trasformManagerAS3 per comode trasformazioni come rotazioni, scala e stiramento di oggetti.
Non parlo solo per citazione, in ufficio hanno scelto di fare l'acquisto e, permettetemi di dire, questo fa onore ai miei capoccia. :)

Cmq, tornando al TweenMax c'è un sacco di roba davvero utile. In questi giorni sto programmando una pagina per creare mini strisce a fumetti per una nuova serie. Una delle feature da implementare è troprio la trasformazione degli oggetti che ho risolto con il tweenmax base.
Oggi, però, il mio collega mi ha girato una classe nuova dal sito di senocular, alias Trevor McCauley. É ancora in via di sviluppo, ma completamente free per fare proprio trasformazioni su oggetti .
La semplicità è estrema: si crea un proprio oggetto, diciamo uno Sprite, poi si istanzia il TransformTool passando come target il nostro Sprite. Fine.
Per capirci:

  1. var quadrato:Sprite = new Sprite();

  2. addChild(quadrato);

  3. quadrato.graphics.beginFill(0xAACCDD);

  4. quadrato.graphics.drawRect(-50, -50, 100, 100);

  5. quadrato.x = 100;

  6. quadrato.y = 100;

  7. //

  8. var tool:TransformTool = new TransformTool();

  9. addChild(tool);

  10. tool.target = quadrato;

  11. // per evitare lo skew

  12. tool.skewEnabled = false;

  13. // se non si vuol far ruotare oggetto

  14. tool.rotationEnabled = false;


Ovviamente è tutto costumizzabile, in particolare anche le ancore di controllo che nell'esempio rimangono sempre visibili essendo l'oggetto da trasformare sempre e solo uno .
Nella pagina di senocular ci sono molti dettagli e un bell'esempio che consiglio caldamente di provare.

Se qualcuno vuole vedere un mio esempio on-the-fly, ho messo online uno zip con un test su 4 oggetti distinti. Lo trovate qui, ovviamente dovete avere anche le classi di senocular per compilarlo che NON sono comprese nel pacco.
L'swf direttamente lo potete provare qui.

martedì 25 gennaio 2011

A proposito di Josh

Questa mattina ho aperto firefox in ufficio e mi sono accorto che c'era ancora il tab aperto con il post dello sviluppatore di GrindShock che citavo nel post precedente.
Josh Tynjala, questo il suo nome, ha anche riprodotto il suo gioco in html5 tramite la libreria javascript Crafty, con un risultato degno di nota.
Ma non è di questo che volevo scrivere, per quanto molto interessante.
Volevo invece citare questo suo post in cui spiega la sua esperienza come sviluppatore indie per l'anno 2010.
Ragiona con una serie di cifre alla mano, tempi di lavoro, licenze, progetti paralleli per poter sviluppare le proprie idee e molto altro.
É molto interessante e istruttivo, in particolare perché Josh aveva già fatto il punto della situazione alla fine del 2009 e non era molto contento del risultato (cito):
"In short, games did not pay the bills this year".
Purtroppo, però, anche il 2010 non è stato rose e fiori, infatti il post incomincia così:
"I had big plans for Bowler Hat Games in 2010, but I guess I spent my time going in the wrong directions"

Josh ha guadagnato 20.009 dollari nel 2010, 32% in meno dell'anno precedente, investendo lo stesso quantitativo di tempo nello sviluppo dei giochi.
Con le app sono entrati 131 dollari al mese, alcuni giochi flash del 2009 hanno reso 198 dollari al mese e ha venduto un gioco flash con licenza non esclusiva per 150 dollari. Facendo i conti, scrive, sono circa 1667 dollari al mese.
Nel paragrafo "Mobile isn’t a walk in the park" dice proprio che la resa nel mondo del mobile è stata per lui una noce più grossa del previsto: "Ultimately, I believe that I spent too much time on mobile this year".

L'analisi mi a caricato anche se a prima vista potrebbe sembrare scoraggiante.
Le scelte e i risultati di questo suo un anno di lavoro meritano una riflessione, in particolare se siete sviluppatori come me.
Concludo aggiungendo semplicemente che amio avviso il passa parola e un minimo di pubblicità faccia davvero la differenza e devono essere messe in preventivo e ho come l'impressione che per i giochi di Josh ce ne sia stata davvero poca. Non voglio fargliene una colpa, è solo il mio pensiero dopo un po' di ricerca. Insomma, mi pare di capire che sia praticamente da solo in questo suo viaggio e di sicuro non è semplice gestire tutto a 360 gradi con buoni risultati in tutti i settori.
Cmq io, per esempio, se non vedevo i suoi giochi nel sito di Lee Brimelow onestamente non credo ne sarei mai venuto a conoscenza e il fatto che al momento i due giochi che ho scaricato per l'iPod non abbiano nessuna recensione (almeno da noi) sostiene, almeno in parte, la mia tesi.

lunedì 24 gennaio 2011

Pinball dreams.. quasi

Questa settimana sono riuscito a fare poco con la mia programmazione per una serie di motivi, tra cui il pessimo stato di salute di mio figlio che ci ha costretti a notti in bianco...
Speravo di fare di più e postare qualcosa - almeno una volta a settimana, questa era l'idea. Anche se qualcosa ho fatto, in realtà, ovvero ho avuto un'ennesima esplosione di idee che spero di concretizzare anche in ufficio e sono riuscito ad ascoltare diversi video di tutorial di pygame.

La fortuna vuole invece che in ufficio il mio collega ha avuto la brillante idea di compilare un progetto flash di un piccolo flipper per android, tramite AIR. Il flipper usa il Box2D per la fisica della pallina che, nella versione originale online, ha reso davvero bene.
L'esportazione per android invece..
..e riccomi che riparto con la mia solita musica, ovvero che il risultato è stato qualitativamente basso come temevo. Sono ancora una volta deluso, ma non su tutto.
Il gioco in se risponde anche bene ma la falla sta nella fluidità che spesso cede, mostrando degli scatti che fanno proprio saltare le fasi del gioco con degli improvvisi "teletrasporti" della pallina.
Nel tentativo di risollevare la situazione la prima idea è stata quella di togliere alcuni elementi dello sfondo animati senza badare alle performance, rendendo il tavolo da gioco spoglio ma restituendo quel poco di fluidità che onestamente speravo, anche se ancora non è perfetto.
Ecco, diciamola tutta, io sto spingendo cmq per farne una versione free per il market, sostituendo tutti gli elementi di sfondo con una bella bitmap e animare lo stretto indispensabile.
Non so se alla fine verrà fatto, io insisterò ancora, magari mettendoci mano in prima persona, se ne avrò il tempo - anche perché non avendolo fatto io dovrei superare la soglia di comprensione del codice di altri, per quanto scritto bene. Vediamo se ne viene fuori qualcosa.
Ho ovviamente anche tentato con un'esportazione per iPhone, provandolo sia sul mio iPod Touch prima generazione, sia sull'iPhone 4G.
Risultato: uno schifo. Ingiocabile, lento, scattoso.
Una porcheria.
Insomma, android 1, apple 0. Onestamente, che frustrazione.

Ma ancora non mi do per vinto e non voglio chiudere tutte le porte all'esportazione fatta dalla Adobe.
Infatti dopo i post precedenti ho fatto un altro po' di ricerca e ho acquistato dall'app store dei giochi esportati con il pacchetto Adobe - alcuni di quelli che mister Lee mostrava sul sito (citavo nel post precendete).
Ho preso GrindShock e Qrossfire della Bowler Hat Games.
Sono due puzzle game in cui lo scopo è avvicinare almeno 3 pedine dello stesso colore per eliminarle e fare spazio nell'area di gioco. Si lotta ovviamente contro il tempo. I concept tra i 2 sono ben diversi eppure si vede che c'è stato del (giustissimo) riciclo del motore base.
Entrambi i casi sul piano grafico sono carini, nell'insieme c'è un certo stile semplice ma coerente.
Invece le parti di contenuti e "confezione" risultano spartane, con menù semplicissimi composti dallo stretto indispensabile, effetti praticamente innesistenti che danno al tutto una sensazione di freddezza. Anzi, forse più che freddezza dovrei dire che mi trasmettono fretta.
Oddio, l'utente medio probabilmente non ci farà (molto) caso, però considerando che uno costa 1.59 € e ci sono giochi da .99€ ben più ricchi, un pochino mi ha infastidito.
Ah, si, volendo GridShock offre due tipi di icone, con e senza pattern. Personalmente quelle con il pattern attivo sono orribili seppur non cambino la mia valutazione positiva del gioco.

I due giochi, infatti, sono più che decenti, anzi, ma sul piano tecnico c'è da dire che non richiedono chissà quali esplosioni di grafica (che cmq non hanno). Non che questo sia un male, ma è giusto per puntualizzarlo, diventando in questo modo termini di paragone relativi.
Devo dire che gira tutto abbastanza bene, i controlli sono ok e rispondo velocemente. L'unico intoppo avviene quando ci sono grosse quantità di pedine da eliminare. Si nota proprio un salto che fa perdere l'effetto di sparizione delle pedine eliminate.
Ovviamente è un male minore, in quanto non condiziona la giocabilità, però c'è, almeno sul mio iPod Touch prima generazione.
Notavo che sul sito mostrano in video le versioni android dei loro giochi, e fanno anche bene: sono decisamente più fluidi e più ricchi di effetti.

venerdì 14 gennaio 2011

Pecore in test su android

In questi giorni sono riuscito a metter mani su pygame e devo dire che mi sono trovato abbastanza bene. La configurazione su eclipse mi ha fatto penare un pochino, ma alla fine è andata.
Sono rimasto impressionato dalla velocità con cui è possibile montare grafica e rendere tutto interattivo. Sono partito dal mio libro, poi mi sono scaricato esempi dal sito di pygame - è tutto molto chiaro, sono decisamente sorpreso. Piacevolmente sorpreso.

..al contrario ieri è uscito un interessante post del team di byHook, che non conoscevo, ma dal loro sito, decisamente ben fatto, ho capito che sono sicuramente in gamba.
Nel post, visitabile qui, mostrano un interessantissimo test di prestazioni per android (via air) costituito da una serie di pecore che si muovono sullo schermo.
La cosa più utile è che, se uno ha android, può scaricarlo e testarlo sul proprio device, cosa che abbiamo fatto in ufficio. Ne esistono due versioni, una che sfrutta esclusivamente la GPU e una solo la CPU.

Nel menù è possibile selezionare la tipologia di disegno delle pecorelle in tre modalità: blip ovvero alla vecchia maniera con il copyPixel, oppure con sprite contenti bitmap, oppure vettori rasterizzati. Sul piano dell'animazione si può influenzare la quantità e il tipo di effetto ovvero se si muovono, se sono animate, se ruotano, renderle semi trasparente (ammazzando il device), applicare uno zoom in e out. Insomma, il test è ricco e mi pare proprio ben fatto.

Al contrario il risultato è, secondo me, deludente. Il post si conclude con delle tabelle di risultati che, personalmente, non ho ritenuto incoraggianti. Vederlo dal vivo sui device poi è stato un bel colpo basso.
Il team, però, non si è espresso così negativamente, anzi nei commenti Jake, l'autore del post, scrive:
«@felix, thanks for catching the URL issue! To answer your question, I think its very possible to make a game that runs at 30fps… I am currently working on 2 very different types of games using Air for Android. One is draw heavy (which is what spurred this demo) and one is SQLite and Memory heavy. The draw heavy one keeps up just fine really, even with touch inputs. SQLite one is a different story. But that one is no where near the optimization stage. The settings used in the data were meant to push the hardware. I’m guessing you won’t need to draw 100+ rotation, alpha, scaling, translating sheep at 30fps :) However if its frame-based animation heavy (eg. sprite sheets, timeline animation), I’m not sure. I haven’t found a fast way to do that yet. But there has to be some way.»

Sarà, ma finchè non vedo qualcosa di davvero valido (magari fatto proprio dal sottoscritto) rimango scettico.
Volendo, esistono già dei risultati che dovrebbero rendermi felice, e si possono vedere qui, sul sito di Lee Brimelow eppure finchè non vedo qualcosa di decente sul mio ipod touch rimango della mia idea. Anche perché mister Lee qui ha postato uno dei suoi ottimi video e questo finiva con due demo strabiglianti: una con un sacco di oggetti 2D che scorrevano sullo schermo, e un altro con 3 dadi 3D che ruotavano e rimbalzano. Tutto, ovviamente, ad altissime prestazioni.
Avesse rilasciato il codice, almeno del primo, dico io.. o almeno alcune righe della parte più importante e invece nulla. Sarà che sono scettico di natura.
Ad ogni modo, credo che prestissimo farò un mini gioco di prova stile (il bellissimo) drop7, quindi con poche animazioni ma solo concept, vediamo se quanto meno gira a un livello onesto. E magari poi faccio anche dei bei post.