di  -  lunedì 29 settembre 2014

Oggi vi presentiamo il quinto capitolo di una serie di articoli in cui ospitiamo Simone Bernacchia, sviluppatore italiano residente in America, collaboratore del progetto AROS e amighista da sempre. Qui trovate la prima parte, qui la seconda, qui la terza, qui la quarta.

Cercando la nostra Identità

Fu Maltese a proporre il nome e il logo per il nostro team; siccome nessuno di noi aveva idee migliori, questi furono accettati. In un secondo tempo misi il nostro logo in uno dei cartelloni di City – non sono sicuro sia ancora lì, però. Il nome era Five Stars VG Studio; ed il logo aveva cinque stelle in alto (ovviamente), poi in Microgramma la scritta STARS, una scritta VG incavata in mezzo e sotto la scritta STUDIO sempre in Microgramma.

Il logo dei Five Stars VG Studio in un cartellone del livello City

Cominciai anche a fare dei test per il logo del gioco: al di là del già menzionato logo di Prototype, avevo cominciato a disegnare dei loghi alternativi di Powder. Ai tempi i logotipi stile Psygnosis erano abbastanza trendy ed io stavo cercando di seguire un po’ quello stile:

Un primo test logo con due prove colore

 

 

Un altro testo per logotipo: la seconda schermata contiene linee guida in italiano per i programmatori nel caso si decidesse di animarlo.

Questi due test furono rifiutati, e io tornai a cercare idee.

WolfSoft

Alla fine del 1992 – come già spiegato, io e Marco proponemmo Powder a Mr. CornFlakes della WolfSoft ma lui si disse non interessato. Successivamente io provai a lavorare con la WolfSoft come collaboratore esterno in un tentativo di creare la grafica per un clone del gioco World Rally della Gaelco; purtroppo avevo sottovalutato la complessità del layout grafico – che probabilmente necessitava di essere diviso in più strati.

E non ho della grafica da mostrare di questo progetto a causa della morte del dischetto su cui lavoravo.

Quando stavo facendo questo lavoretto eravamo già nel 1994 e il mercato si stava spostando su PC: mi ricordo Mr.CornFlakes mostrarmi in anteprima l’introduzione di un gioco 3D con una ambientazione simil-Robotech che usava animazioni di modellini a passo uno per l’introduzione ed i filmati: indubbiamente avere un media come un disco fisso o anche un CD-ROM faceva la differenza!

L’Influenza di Manga e Consoles

Il padre di Marco era sovente in estremo oriente per affari: una volta tornò con una quantità notevole di riviste di videogiochi giapponesi: una che ricordo bene era chiamata Technopolis ed era rivolta ai Personal Computers, le altre erano orientate al PC-Engine.

Nonostante gli evidenti problemi di lingua – ai tempi la mia conoscenza del giapponese era quasi nulla – queste riviste ci fornirono molte più informazioni sui giochi su console di moda in quel momento nel sol levante – in confronto con le riviste locali e britanniche che compravo mensilmente, specialmente CU Amiga, Amiga Format e C+VG; tra gli sparatutto spiccavano Rayxamber II, Rayxamber III, Spriggan ed altri.

Altra fonte di informazioni fu un mio amico compaesano, giocatore professionista e collezionista accanito di consoles e video giochi – ai tempi principalmente Amiga, Megadrive e Super Nintendo, principalmente di importazione parallela: questo mi permetteva di vedere i giochi non solo su rivista ma anche dal vero, nelle console di provenienza nipponica. Le custodie e i manuali – soprattutto quelli giapponesi dei giochi Megadrive avevano per me – studente di Scuola d’arte e sensibile a tematiche come il packaging – un grande fascino: custodie di plastica ed etichette e manuali a colori davano l’aspetto di un prodotto solido e ben curato.

E non scordiamoci lo shock culturale che fu portato dalla diffusione dei Manga in occidente: successa in sordina durante gli anni ottanta, esplose come sottocultura negli anni novanta e mi trovò a braccia aperte sia come aspirante fumettista, come animatore, come grafico di videogiochi e musicista: i gusti musicali e cromatici differenti (certe volte pacchiani o stridenti per noi occidentali e per me provincialotto) mi stavano aprendo nuovi mondi e prospettive, pur non sconosciute: conoscevo un po’ di katakana sin dagli anni ottanta (Eureka!) e cercai di imparare la lingua di più successivamente: oggi posso leggere i due kanas e diversi kanji ma sento che codesta conoscenza sta sparendo…

Parliamo dei Tools

Il Map Editor o MED era abbastanza semplice da usare: si caricava il sorgente del MED in ASM-ONE e si indicavano i path per la mappa, per i tilesets , la lunghtezza in scehermate della mappa; quindi si usava A per assemblare il tool. L’editor era composto principalmente da due schermate: la prima era la mappa vera e propria e la seconda era la schermata di selezione delle tiles; in basso ad entrambe il pannello di controllo, con dodici spazi vuoti dove caricare i blocchi. L’utente cliccava in un blocco della mappa che intendeva piazzare nella selezione e lo depositava nello spazio vuoto; quindi procedeva alla schermata di edit, selezionava il blocco e lo disegnava su schermo. Un altro bottone salvava poi la mappa e, se ricordo bene, premere ESC chiudeva il programma.

L’Enemy Editor – o Eneditor – era anche l’engine principale del gioco. Modificando alcuni parametri era possibile assemblare o l’editor o la versione finale del gioco; usando i parametri nel codice sorgente si poteva puntare ai files da caricare.

Prima di quello, però, era necessario preparare i nemici con un altro tool – trovato da Thomas e Filippo e probabilmente proveniente dalla demoscene, mi pare si chiamasse RawEdit; con questo dovevamo allineare le animazioni degli sprites una vicino all’altra in una singola immagine per poi selezionare le varie aree e salvarle in .bmap; io chiamavo codesti files con il prefisso MasterClipper.

Un file Masterclipper per Ruins

Per inserire un nemico nell’Eneditor si faceva scorrere la mappa fino al punto interesato qundi di andava nello schermo di selezione. Da li era possibile scegliere uno degli sprites nemici, definire animazione, comportamento ed altri parametri, quindi si tornava nello schermo a scorrimento e si posizionava. C’era la possibilità di usare dei NullObjects – ovvero dei marker a cui assegnare un evento o un nemico in trasformazione. Attraverso i selettori dell’editor si potevano aggiungere dei contatori per la trasformazione o come tempo (linee raster se ricordo) o come numero di colpi subiti; era anche possibile definire delle gerarchie di tipo parent-child e quindi avere nemici composti di sprites multipli e si poteva anche generare delle situazioni discretamente complesse, come un nullObject che, dopo 300 unità tempo si trasforma in un Boss coi tre cannoncini linkati e un generatore di missili e che necessita 100 colpi per morire e vale 10.000 punti e 20 crediti.

Altri parametri associabili erano il passaggio di sprites di foreground per la parallasse, la possibilità di fermare lo scroll e quella di terminare il livello.

La introduzione, le schermate e la fine che non furono – quasi

E’ noto che su Amiga si creò il trend per le introduzioni animate ai giochi, grazie principalmente a Psygnosis; meno noto è che i giochi giapponesi su computer avevano intro con testo, e che il Neo Geo consolidò le intro cosiddette ‘a Sagome’ o ‘Cutboard’, fatte con sprites ed animazioni semplici e che occupano poca memoria.

Visto che Powder cercava di mantenere un feeling da Arcade o quantomeno da gioco su console, pensai che lo stile Cutboard di intro era quello ideale. ci sono stati almeno due tentativi da parte mia di creare una intro per Powder: il primo prevedeva una visione del pianeta con la nave madre più delle vignette sovrapposte che mostravano l’apertura dell’hangar, la navetta che accende i razzi e così via; siccome era una mia iniziativa indipendente fu poi scartata, anche perche’ Marco notò che avevo sbagliato il design della M1 (le doppie code sono parallele, non inclinate).

La seconda versione era ispirata da un lavoro animato di Marco che aveva presentato al Bit.Movie 1992, dove si era piazzato se ricordo ottavo, chiamato 500 TL vs Ferrari; questo era fatto con il Deluxe Paint ed usava solo 8 colori – per usare meno memoria.

La sua animazione mi ispiro’ e mi fece pensare che probabilmente usando un approccio simile mi sarebbe stato possibile creare una intro animata quasi a livello Psygnosis e, allo stesso tempo, essere in grado di creare brevi storie animate: uno dei miei sogni.

Successivamente, nel 1993 feci una animazione test e la mandai al Pixel Art Expo di Roma, dove si piazzò – se ricordo bene – ottava.

Powder from simone bernacchia on Vimeo.

Perche’ alla fine l’animazione non fu messa nella versione CD? Tra le varie ragioni c’era che avrei dovuto suddividere tutti gli sprites e metterli nell’Eneditor per ricreare l’animazione; la seconda ragione – piu’ importante – è che nella fretta di finire ce ne siam dimenticati.

E l’intro non è la sola cosa rimossa: tra i vari fossati non colmati che Powder lasciava dietro, avevamo anche altri piani per rendere il gioco graficamente più presentabile. Alla fine del 1992 Agony uscì e fece scalpore anche per le sue stupende schermate introduttive per ogni livello. Anche li pensai che fosse una cosa interesasnte e che avremmo potuto usare un approccio simile per il gioco. Cominciai a lavorare sul Deluxe Paint in modalità half-brite per creare delle schermate introduttive o che esaltassero certe situazioni del gioco. La prima ad essere completata fu la schermata di Game Over:

La schermata di Game Over – mi scuso per la cattiva qualita’, l’ho grabbata da un video.

Quindi continuai dedicandomi a diversi livelli, usando tecniche miste: ad esempio Factory era basata sulla digitalizzazione di un fotogramma della sequenza iniziale di “Blade Runner” poi ritoccata pesantemente a mano: siccome la qualita’ della digitalizzazione non era buona non venne secondo me troppo bene…

La schermata di City invece è fatta a mano, e ho tentato di usare delle prospettive un po’ ardite e riflessi anche quelli fatti a mano (è comunque apparsa nella copertina del manuale);

Ecco la schermata per ruins:

E quella per Clouds, non finita ma probabilmente una delle migliori…

Feci anche un test per una mappa tra livelli, anche questa non finita, ma usa solo 32 colori:

Stavo cercando anche un buon finale: una delle mie idee era di far atterrare la nave su una portaerei nel mare: avevo composto anche una musica per quello:

Music: Powder – End Game music (1992) [unreleased] from simone bernacchia on Vimeo.

 

Ma poi alla fine la canzone dei credits fu rimpiazzata dalla attuale, più leggera e inclusa nello stesso .mod del tema iniziale.

Cosa che finora ho sempre scordato di menzionare è che a quei tempi in cui lavoravo a Powder non avevo un monitor: tutta la grafica veniva fatta usando il mio fido TV Grundig 15 pollici portatile attraverso modulatore: le cose indubbiamente sembravano meglio li che in un monitor, ma siccome Filippo, Nicola e Marco i monitor li avevano, stavano sempre a puntare le inaccuratezze che mi sfuggivano.

Ed altre parti del gioco stavano prendendo vita: avevo finalmente le colonne sonore di Ruins, Factory e Space.

Ed anche i boss cominciavano a prendere una forma più definitiva: i primi due boss concepiti furono City e Space. Per City la prima idea era una enorme nave corazzata che, però a causa della riduzione colori non aveva un bell’aspetto, e ricordava un po’ un calabrone come distribuzione dei pesi:

Quindi un giorno decidetti di ridisegnarla usando il metodo della giustapposizione e con un occhiolino a Thunderforce: il risultato fu una stupenda ed incazzereccia nave madre che spara laser da davanti e ha due aperture da cui escono continuamente caccia dello stesso tipo di quelli triangolari nella city, ma stavolta rossi, e che necessita di essere distrutta in due fasi.

Test di montaggio del boss della city

Il fondale poi fu stato disegnato per assicurare un senso di continuità,ed infatit il livello viene giocato all’interno dell’Hangar in cui si entra alla fnie del livello City, pieno di navette ordinate in vari piani.

Uno screenshot del livello Boss City terminato

A questo punto tutti i tasselli stavano cominciando ad combinarsi insieme ed ero ottimista che Powder potesse essere finalmente finito e pubblicato, ed anche per aver trovato una nicchia lavorativa; ero inconscio della tragedia che lentamente si stava sviluppando dall’altra parte dell’oceano e che avrebbe cambiato le nostre vite per sempre…

…in WestChester, Pennsylvania.

8 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    giacomo
     scrive: 

    Ma l’immagine di Ruins non è “vagamente” ispirata alla sigla iniziale di Conan ragazzo del futuro? :)

  • # 2
    Katakis
     scrive: 

    cit:

    “ero inconscio della tragedia che lentamente si stava sviluppando dall’altra parte dell’oceano e che avrebbe cambiato le nostre vite per sempre…

    …in WestChester, Pennsylvania.”

    Mamma mia! Non oso pensare, dopo tutto il lavoro…

  • # 3
    simone bernacchia (Autore del post)
     scrive: 

    @giacomo
    Piu’ Nausicaa attualmente…

  • # 4
    Fatagnus
     scrive: 

    Da Amighista non posso che gradire simili post.

  • # 5
    Sisko212
     scrive: 

    Interessante, scusate se faccio domande banali, ma arrivo a leggere questi pezzi solo ora.
    Avrei una domanda su come venivano realizzate e fatti muovere i vari sprite o bob e le schermate.
    In pratica, se ho capito bene, nel caso dgli sprite, veniva prima disegnata la grafica, e ogni singolo frame, in una grossa btimap, con uno dei vari tools tipo Deluxe paint.
    Questa grossa bitmap, era divisa in una griglia di X*Y pixel e N celle.
    Veniva poi caricata in memoria, e nell’animazione dello sprite o bob, non si faceva altro che prendere la posizione della cella e poi veniva caricata nella zona di memoria riservata allo sprite ?
    Ossia come una specie di finestra che va a visualizzare solo una piccola porzione del tutto ?
    E per le schermate ? il concetto era simile ? ossia si creava la bitmap dello sfondo, sempre con un Deluxe Paint, e lo si poneva in un bitplane (dato che, se non ricordo male, su amiga, la gestione dei bitplane era in hardware) e poi lo si shiftava avanti-indetro-su-giu ?
    In sostanza, tutto lo spazio occupato dai giochi era più che altro per la grafica, che non per la logica di esecuzione del gioco.
    Grazie.

  • # 6
    hexaa
     scrive: 

    Long live the Amiga!
    Amiga per sempre.

  • # 7
    Sisko212
     scrive: 

    A proposito… se avete un vecchio Amiga con il floppy che non vi funziona, e avete una raspberry, potete, con poco tempo e quattro soldi, farvi un emulatore floppy…
    L’ho visto giusto ieri:
    http://amigadrive.blogspot.it
    E’ un pò uno sproposito usare un arm per emulare un floppy… però ok.. il costo è accessibile e ti fa sentire un pò hacker… :-D ;-D

  • # 8
    Simone Bernacchia (Autore del post)
     scrive: 

    @sisko

    Per le mappe non si memorizza la schermata intera: di solito viene usata una grid di blocchi (nel caso di Powder 16×16 pixel) e viene memorizzato l’id del blocco corrispondente all’elemento grafico, per dire se ho una mappa che usa tre tipi di blocchi – cielo terra e nuvoletta ed assegno a questi tre blocchi id 0, 1 e 2 avro’ una griglia alta 16 elementi (16×16 = 256) e lunga per quanto serve di numeri 0,1,2 che occupa meno memoria di una schermata intera; poi per il display, questo di solito e’ poco piu’ lungo del video visibile e nella parte nascosta i blocchi vengono disegnati e cancellati.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.