martedì 17 aprile 2007

Giochiamo



Second Life. Vita alternativa. Fuga dalla realtà. Realtà ricostruita. Nowhere place in cui abbiamo il coraggio di rischiare, perchè non perdiamo nulla. Nowhere man. Incontri. Giochi.
L'homo ludens ha bisogno di estraniarsi. Recupera tempo al lavoro e, al posto che spenderlo nella vita, gioca.
Un po' come me, con questo blog, quanto sto giocando?
Avremmo ben altre cose più importanti da fare.
Esistono obiettivi assoluti e, invece, perdiamo tempo a giocare.

Siccome continuo ad essere adamantino nella mia ricerca di tali obiettivi e non mi lascio distrarre da nulla, non gioco mica, io.

Mi diverto di più a programmarli, i videogiochi.
Dopo il lavoro, per estraniarmi dall'informatica.



Da piccolino, correva l'anno (scolastico) 1982-1983, iniziai a programmare.
Seguii un corso, consigliato da un compagno di classe.
Ai tempi i PC non erano diffusi. Quasi non esistevano.
Infatti, io immaginavo di trovarmi di fronte ad una specie di armadio, con tante lucine colorate, bocche metalliche da cui doveva uscire un rotolo di carta, nastri che continuavano ad avvolgersi ininterrottamente.
Un po' come il computer di Spazio 1999 (mi piaceva, l'ho visto di recente, che tristezza...).

Invece no. Un VIC 20. 1,5K di RAM.
Un corso impostato molto bene: flow-chart fin dal primo giorno (e che altro volevate, con 1,5K? Più si sta lontani dal televisore - non monitor, televisore -, meno se ne vedono i limiti).

Alla fine ero convinto di saper programmare.
I miei cedettero e mi comprarono uno Spectrum (ma davvero, chiesi ai miei insegnanti, può arrivare a 48K? Con 8 colori e con i suoni? E il controllo sul singolo pixel? Beh, se c'è scritto su Byte, sarà vero).

Cosa fa un ragazzino che sa programmare, con il suo nuovo PC? Si programma Pac-Man, ovviamente.
Scoprii che non sapevo programmare.
Ci persi dietro tutta l'estate, per imparare a farlo (beh, insomma...).
Ben prima della fine dell'estate il mio Pac-Man aveva 5 livelli e 1 fantasma che mi inseguiva con cattiveria inusitata (al livello 5 mi mangiava in 7 secondi, alla faccia della giocabilità).

Programmai anche un gioco di una rana che stava su una foglia e doveva cercare di saltare, mangiarsi gli insetti che passavano, senza essere divorata da un improbabile uccello (rappresentato da 3 asterischi, lo ricordo ancora) e senza cadere in acqua.

Tradussi un bellissimo gioco che trovai su un giornale (in inglese) scritto per lo ZX81.
Mi insegnò che si possono creare n stanze, completamente differenti ogni volta che si gioca, completamente identiche ogni volta che si entra e si esce all'interno della stessa partita, dovendo memorizzare un solo byte di informazione.
Il seed della funzione random, ovviamente.

L'anno dopo, per riuscire a programmare un videogioco di corse di automobili, con scrolling verticale della strada, fui costretto ad imparare l'assembler dello Z80.

L'anno dopo lessi il famoso testo di Hofstadter sull'AI e persi la testa (ma questa è un'altra storia).

Non ho mai smesso, però, di programmare videogiochi, per divertimento.

E solo perchè non mi lasciano farlo per lavoro: non avete idea di quanto mi piacerebbe poter essere responsabile di un progetto simile, della durata di 5 anni, con un team di 20 persone, con background culturali e talenti totalmente differenti.

E, marketing o non marketing, se funziona o no, se piace o no, lo si capisce.
Perchè la programmazione di videogiochi, ha dentro grandi complessità.
Enormi complessità logiche.
E' una sfida continua. (il fatto che la vincano sempre loro è un'altra questione).

Ovvio che, ancora oggi, sia interessato dalla notizia dell'uscita dalla beta di uno YouTube per i videogiochi, che si chiama Kongregate.
Ovvio che sia deluso: ma si può, accettare solo videogiochi in Flash? I primi in cui mi sono imbattuto avevano pure una grafica da sito.
Che tristezza.

Tanto per tanto, quasi mi divertirebbe di più partecipare alla comunità di GameMaker.
GameMaker, oggi arrivato alla versione 7, è un simpatico strumento, creato da un professore universitario (o dalle tesi dei suoi studenti?), che permette di sviluppare giochi semplici in modo semplice, senza programmare (seguendo un modello ad eventi e utilizzando delle iconcine, come comandi), e giochi più complessi programmando (ad oggetti, con qualche limitazione).
Ne esiste una versione free, con un po' di funzionalità disabilitate, ma con quelle abilitate si possono già fare cose serie.
E tra quelle abilitate ne troverete una che permette di postare il vostro gioco sul sito della community.

E' famoso, GameMaker. Mi ha fatto divertire, fin dalla versione 5. Se programmare con lui è un po' come giocare a Tetris, a me serve qualcosa di rapportabile ad Oblivion (per la mia rabbia enorme mi servono giganti avrebbe detto Cyrano - va beh, Oblivion forse è un po' troppo, non ho così tanto tempo libero da dedicare alla programmazione di videogiochi, ma spero abbiate capito il concetto).

Fortuna che c'è Java e, soprattutto, che c'è un altro professore, Andrew Davison, che ha pubblicato online le primissime versioni di un suo bellissimo libro: Killer Game Programming in Java.

Che inizia spiegando che è ora di piantarla di dire che serve per forza il C, per andar veloci.
Che scrive una appendice che spiega cosa cercare, quando si scava nella Garbage Collection.
Che prosegue spiegandovi tutto sui timer di Java (con fare universitario, quindi esagera pure).
Che vi porta a fare, passo passo, in nemmeno 12 capitoli, giochi in 2D, come applicazioni (full screen e windowed), applet e Java Web Start.
Con una pretesa di framework (termine un po' eccessivo, nel caso specifico), con musica, side scrolling, Sprite.
Fino ai giochi isometrici tile-based.
Il tutto condito con diagrammi UML, così se non sapete progettare e programmare, lo imparate (scherzo: se non sapete programmare e progettare non riuscite neppure a leggerlo, questo libro).

Per chi sopravvive ai primi capitoli (non dovrebbe essere impossibile), ce ne sono molti di più sulla programmazione con Java3D (con chicca sulla generazione di alberi che crescono).
Per chi regge anche questi (non è da tutti), ci sono i capitoli sui controlli di input non standard (dalla Webcam, al Gamepad, al controllo del braccio dell'omino del videogioco con il nostro braccio destro, al guanto per la realtà virtuale, che certamente avrete tutti a casa).
E poi, JOGL (wrapper attorno ad OpenGL), giochi in rete, J2ME, Bluetooth, Mobile3D.
Serve altro?

Consigliato a chi pensa di conoscere Java.
Me compreso.

Bye
    Depa

P.S.: comunque potrebbe essere interessante mettersi a fare un framework che frulli assieme dei tool simil-GameMaker con le possibilità evidenziate dal testo di Davison...

5 commenti:

Depa ha detto...

OK, sono stordito.
C'è una simpatica via di mezzo, tra GameMaker e Java, da neppure poco tempo: si chiama G-Java e converte da GameMaker in Java.
Unico difetto (almeno teoricamente: l'ho appena trovato, non sono ancora riuscito a provarlo): dovete utilizzare NetBeans. Temo che sia perchè il suo sviluppatore ne preferisce l'IDE a Eclipse, soprattutto per gli aspetti di RAD visuale.
Esistono situazioni più critiche, sono fiducioso che si possa resistere.

MeDevil ha detto...

Ma dai... proprio tu che sei passato per l'assembly mi cadi sulla bellezza di un framework ben costruito... (java e c#).
Non ci credo... vabbè continuerò ad apprezzare la compilazione in nativa anziché il bytecode :P
Ah cmq, grazie per la visita ;)

Depa ha detto...

MeDevil,
e chi ha detto che cado? L'analisi delle performance riportata in killer game programming (immagino che ti riferissi a quello, quando parlavi di framework o, comunque al mio P.S., che a quello faceva riferimento - C# non c'entra, sebbene non si possa escludere a priori e nonostante l'attuale ostico framework, almeno per la parte free che ho potuto provare, fornito da Microsoft e chiamato XNA) non sembra poter dare una motivazione valida ad una compilazione nativa: la perdita del 10-20% delle performance è ampiamente riscossa da maggiori velocità di sviluppo, flessibilità e facilità di condivisione del disegno, che corrispondono anche ad abbassare i costi di produzione e ad estendere la possibilità di costruire videogame di livello.
Quel 15% medio potrebbe essere ancora importante in alcuni giochi, ma nel 90% dei casi è assolutamente inutile e certamente inciderà molto più sulle performance una programmazione poco attenta e poco profilata.
A me interessano, oggi, molto più giochi di strategia e tattica, che non hanno bisogno di una velocità straordinaria, ma possono fortemente godere dell'utilizzo di una progettazione OO.

Per quanto riguarda la visita... mi sembrava il minimo. Grazie a te per la citazione ;)

Anonimo ha detto...

Non posso che darti ragione. I "pro e contro" che intendevo io nel commento erano proprio questi. Con c/c++/assembly & co hai poca velocità nello sviluppare le cose, poiché devi gestirti molte più informazioni che nei linguaggi C# e java sono gestite automaticamente (gc, type-reflection, etc).
Ovviamente, tutto ciò ha un prezzo, sia da un lato (c,c++, in termini di tempo di sviluppo), sia dall'altro (c#,java,etc in termini di potenza).

Piccola nota: il framework del c# non è solo xna. si chiama .net (ma penso che tu già lo sappia) ed è veramente completo e potente (questo, detto da me che sono un accanito sostenitore dei linguaggi "puri" come il c o il c++, deve far riflettere :P).
Bel blog cmq!

Saluti, MeDevil

Depa ha detto...

Grazie per i complimenti.
Faccio finta di essere offeso per la nota riguardante .NET: XNA si basa su .NET, quindi come avrei mai potuto provarlo senza? ;)

Comunque .NET non è male, lo uso fin dalla sua prima versione per scopi professionali, prima ho usato anche ASP e VB, ma... che dire: pur non essendoci sostanziali differenze, a oggi, vedrai più frequentemente citare Java su questo blog, perchè lo conosco meglio e mi ci muovo dentro più agevolmente.

E basta, perchè non condivido le guerre di religione sul linguaggi di programmazione.