Autore Topic: Mb/superm/frozen Bav  (Letto 4763 volte)

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« il: 09 Gennaio 2007, 20:56:58 »
 No, il titolo ancora non è scelto e alla fine potrebbe diventare qualcosa ancora diverso dai 3 proposti.
In ogni caso si tratta del prossimo 4KB minigame che durante una settimana nelle nevi ho previsto di sviluppare per la prossima combo (ovviamente mi prendo in anticipo...).
In ogni caso si tratta di fare un porting di Frozen Bubble sul C64 (spero che lo conosciate, così potete seguire la descrizione tecnica che segue).
Ho avuto modo di giocarci pure su telefonino, oltre che su pc, e direi che come giocabilità è uno dei migliori.
Lo schermo prevede al max 12 palline in orrizzontale e 12 in verticale (una riga con 12 e una con 11), pertanto usando char di 2x2 ottengo l'area di 24x24 char.
Rimane una riga vuota per mettere la barra verticale sopra che scende al tempo stabilito. In orrizzontale, la schermata va centrata (o tenuta a sinistra), in modo comunque da non superare i 255 bits per la posizione dello sprite (così da risparmiare sul codice).
I caratteri saranno multicolore e (abbozzati su carta), direi che ho il modo di rendere pure l'effetto Frozen che avviene quando si perde.
La pallina che si muove sarà fatta con uno sprite multicolore, che verrà rimpiazzato da caratteri appena la pallina entra nelle griglia fissa.
Un problema è quello di far cadere le palline che sono state colpite. Questo potrebbe implicare l'utillizzo di 1 sprite multiplexor per far cadere le palline in contemporanea (facendo cadere al max 8 palline su una riga, le altre 4 farle cadere in ritardo dopo).
Ho però escluso questa possibilità perchè il codice verrebbe troppo oneroso.
Penso invece che un effetto che andrebbe bene sia far esplodere la pallina (con una animazione). In mente avrei pure l'effetto che la pallina (supposta un disco), ruoti e si veda che diventa una linea (lo spessore del disco), prima di scomparire. Purtroppo questo verrebbe bene solo riuscendo aa disegnare in simil 3d quando ruota e senza provare sul editor grafico a mente non so se potrebbe risultare bene.

A questo punto il bordo inferiore deve essere aperto e sotto si vedrebbe 4 sprites: il cannone che ruota, il disco da sparare e il prossimo da sparare (non ho cacolato se ci starà come spazio, spero di si), e in fianco il pinguino che spara.

Per quanto riguarda la musica, già gli effetti sonori (sul telefonino) sono già molto buoni (se poi si riesci a fare l'effetto NOOOO di quando si freeza sarebbe il massimo).
In caso di spazio ci starebbe un motivetto da mettere in sottofondo.

Adesso sto scaricando la versione java del gioco, poi scarico la versione in C per telefonino, più quella originale in Perl, in modo da partire col vedere come realizzare in assembler l'algoritmo di collisione e rimozione palline che è la parte cruciale del gioco.
Nel contempo parto con disegnare la grafica (appena ho qualcosa di pronto posto il link ai sorgenti).

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #1 il: 11 Gennaio 2007, 20:21:04 »
 Per quanto riguarda i colori, la scelta che mi sembra più appropriata (considerando che i primi 8 colori sono da riservare come colore primario della pallina), sono:
15 di sfondo (è un grigino). Forse era meglio il 14 (che è ad esempio quello sui telefonini, ma poi l'unico carattere per il frozen sarebbe il 13, un pò bruttino).
14 colore secondario 1 per l'effetto forzen (è un azzurrino)
12 colore secondario 2 per l'effetto 3D (ombra)
Sto sperimentando come mettere l'ombra: tutto intorno (ma è un pò pesantina quando le palline sono allineate), oppure solo sul lato destro inferiore (fermo restando un cerchietto pure sull'interno).
Posterò un immagine dei più promettendi da scegliere, appena abbozzo altre 2-3 palline
 

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #2 il: 14 Gennaio 2007, 18:11:12 »
 

Ecco come appaiono le palline normali e in frozen sull'editor grafico.
L'effetto frozen però è da migliorare

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #3 il: 21 Gennaio 2007, 19:44:34 »
 Chiassa perchè ero convinto che fossero 12, ma in realtà sono solo 8 le palline in orrizontale (per 9 o 10 a seconda dell'implementazione in verticale).
Questo significa che idealmente con uno sprite multiplexor sarebbe già più semplice realizzare la cascata di palline quando colpite.
In ogni caso procedo con la grafica a caratteri.
Le posizioni del cannone sono ben 40 (quindi idelmente 20 sprite da specchire), il che comunque è un bel gruzzolo di bytes.

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #4 il: 27 Gennaio 2007, 20:51:36 »
 Alcune considerazioni tecniche, relativa al movimento della pallina
La pallina può partire con un angolo tra 0 e 180°, ma limitiamoci a vedere solo 90°, per l'atra direzione basta invertire il segno della spostamento in x.
La barra può spostarsi di 5° (18 valori), detto @ l'angolo di sparo rispetto all'asse x, abbiamo che:
Sx=V*Cos(@)*t  e  Sy=V*Sen(@)*t
dove V è la velocità con cui è sparata la pallina e t è il tempo di 1 frame.

Posto V=4 pixel per frame, otteniamo i valori Sx e Sy di spostamento della posizione della pallina da dare ad ogni frame.
Il problema è che tale spostamento è un numero decimale:
4*cos(50°)=2,57115044
Per ovviare a questo bisogna prevedere un tabella di valori di spostamento per correggere il movimento.
Ovviamente dobbiamo risparmiare spazio. Innanzi tutto bisogna sfruttare le relazioni tra seno e coseno per ridurre il calcolo a una sola tabella per entrambi.
Dopo di che proverò a partire con 2 valori per lo sparo e aumentare fino a 4 sperando che siano sufficenti a garantire il movimento corretto, es:
2,57 può essere approssimato da questi valori per i casi con 2, 3, 4 valori da usare:
-> 2 3     (2+3)/2=2,5
-> 3 2 3   (2+3+2)/3=2,33
-> 2 3 2 3 (2+3+2+3)/4=2,5

Ovviamente questa è solo teoria, poi bisogna vedere se il movimento sarà effettivamente coerente o l'errore intrinseco porterà a traettorie errate.

 

iAN CooG

  • Utente
  • **
  • Post: 1774
    • http://iancoog.altervista.org
  • Gioco Preferito: Turbo Assembler, ActionReplay Monitor, DiskDemon
Mb/superm/frozen Bav
« Risposta #5 il: 27 Gennaio 2007, 21:46:01 »
 Non conosco questo Frozen bubble, ma dalle descrizioni direi che si tratta a sua volta di un clone di Bust-a-move/Puzzle bobble. Ben venga una versione C=64  :D  
-=[]=--- iAN CooG/HVSC^C64Intros ---=[]=-
- http://hvsc.c64.org - http://intros.c64.org -

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #6 il: 27 Gennaio 2007, 22:45:51 »
 In effetti è la versione Open Source per Linux (e quindi piena di pinguini e ghiaccio) di Puzlle Bubble

Cbm

  • Utente
  • **
  • Post: 423
  • Gioco Preferito: Wonderboy
Mb/superm/frozen Bav
« Risposta #7 il: 28 Gennaio 2007, 00:22:57 »
 Ciao ragazzi, mi sbaglio o non c'è ancora nulla del genere per Commodore 64? Qualche anno fa avevo appunto cercato il gioco e non avevo trovato nulla, quindi mi fa doppiamente piacere che la scelta per la prossima competizione 4K sia caduta su questo gioco.
C= - Dal 1985! Lunga vita e prosperità.

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #8 il: 10 Febbraio 2007, 21:04:54 »
 Nel frattempo il lavoro procede nella grafica:
disegnato lo sprite della pallina come da caratteri e iniziato a disegnare il cannone dello sparo.
Dato che il cannone cambia direzione e "ruota" attorno alla pallina (ovvero non ruota sul suo baricentro, ma su quello della pallina), in uno sprite ci starebbero le animazioni di un semisfero 0-90° (8bits metà palline + 10 bits cannone), per l'altro emisfero (90-180°) i sprite andranno mirrorati e posizionato spostati in x della giusta qunatità.
In questo caso GIMP è assolutamente essenziale per disegnare il cannone che ruota: ho riprodotto il cannone e la pallina, poi applicando rotazioni di 4,5° alla volta, disegno il risultato sullo sprite.
Nota che bosigna utilizzare un palette bianco e nero (lo psrite sarà monocolore per avere maggior risoluzione), altrimenti gimp metterebbe l'antialiasing.
In caso di gioco non vincolato a 4KB, l'ideale sarebbe utilizzare 2 sprite sovrapposti e utilizzare una palette di 2 colori, in modo da avere un minimo di antialiasing.
Appena disegno il tutto, poi posto i sorgenti che ormai cominciano a crescere.

Roberto

  • Administrator
  • Utente
  • *****
  • Post: 2415
    • https://ready64.org
  • Gioco Preferito: Impossible Mission
Mb/superm/frozen Bav
« Risposta #9 il: 25 Febbraio 2007, 17:37:18 »
 
Citazione da: "ice00"
In caso di gioco non vincolato a 4KB
Io faccio apertamente il tifo per un gioco senza limitazioni a 4Kb :)
Le limitazioni, se da una parte costituiscono una sfida per il programmatore, dall'altra mettono in mano all'utente finale un prodotto frutto spesso di rinunce e compromessi (grafici, sonori e di giocabilita') e quindi con una cura ed un fattore di (ri)giocabilita' piu' basso.
Quali sono al momento le probabilita' che tu possa realizzare una versione "piena"?

PS
Nemmeno io conoscevo Frozen Bobble. Avevo capito che si trattava di Puzzle Bobble dalla descrizione.
Per collaborare, segnalare un errore (o qualsiasi altra comunicazione importante) utilizzare la pagina dei contatti:
https://ready64.org/informazioni/contatti.php

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #10 il: 25 Febbraio 2007, 19:35:39 »
 
Citazione
Quali sono al momento le probabilita' che tu possa realizzare una versione "piena"?
Diciamo che ci avevo pensato alla versione full, e in effetti, una volta che l'engine di gioco è funzionante (in 4KB), l'estensione consisterebbe in:
-grafica con antialiasing per cannone, con tanto di parte posteriore (che in 4KB sarà evitata)
-animazioni di Tux quando si spara e si vince
-effetti sonori come da originale con tanto di parlato
-riproduzione su Sid della traccia originale (o quantomeno un bel brano appropriato)
-multiplexor per simulare caduta di tutte le palline (max 8 per riga)

E' chiaro che tutto dipende da quanto tempo libero avrò a disposizione (ad esempio al momento ho disegnato solo metà degli sprite per il cannone, nonostante siano settimane che ho iniziato questo task).
L'ideale sarebbe stato avere la Jum competition appena dopo la fine della minigame compo (invece sembra inizierà tra pochi giorni), così da poter lavorare in parallelo sulla versione 4K e unsize.

Comunque se qualcuno volesse nel frattempo lavorare sugli sprite per Tux, sulla musica, ecc, per una versione full... magari al momento buono potrebbero tornare utile ;)

 

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #11 il: 11 Marzo 2007, 20:59:45 »
 Ho finito la creazione sprite per cannone e h oappena creato i caratteri per l'animazione pallina che sparisce (quando colpita). Adesso si tratta di inserire tutto il codice degli sprite e caratteri nel sorgente.


ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #12 il: 13 Maggio 2007, 19:33:29 »
 Un pò a rilento, comunque il lavoro avanza.
Qui la bozza dell'arena di gioco con tanto di simil iglu come nell'originale.
Qui risulta un pò più piccola in y, dato che sto usando l'editor di LSS 2 per crearla (che usa 20 caratteri)
http://utenti.lycos.it/ice00/test/back.png
modificato [IMG] in [URL] perche' l'immagine e' troppo grande

Loky

  • Utente
  • **
  • Post: 130
Mb/superm/frozen Bav
« Risposta #13 il: 13 Maggio 2007, 19:41:34 »
 io conosco pure fB.

Se ci riesci sei un grande... tifo per te.

io avevo cominciato a realizzarne una versone per cellulare tramite Java ME, ma mi sono bloccato nel farmi le seghe mentali sugli algoritmi per incastrare le palline...
 

ice00

  • Utente
  • **
  • Post: 469
    • http://digilander.iol.it/ice00
Mb/superm/frozen Bav
« Risposta #14 il: 26 Maggio 2007, 10:58:10 »
 Sembra che la mia scelta dei colori sia stata poco felice: dovendo aprire il bordo per poter visualizzare la seconda pallina, il risultato è quello in figura.
Le alternative sono sue: ridisegnare tutta la grafica invertendo i colori sfondo (i due grigi) in modo da avere colori sfondo scuri.
Oppure creare due irq "abbastanza" stabili che cambiano il coloro del bordo superiore e inferiore nel modo giusto. Il timing deve essere abbastanza preciso, altrimenti ci sarebbe flichering sul colore bordo