Dove sono

Contattami

Address

Abito da qualche parte su questa minuscola sfera nuvolosa. In un pezzo di terra e rocce a forma di stivale, dove l'abitante medio è il furbetto che si lamenta se gli altri fanno i furbetti.

Squared Bobble

Squared Bobble
Dec
23

Quando il prof iniziò a dirci che dovevamo sviluppare dei giochini, subito tentai di sbizzarrirmi pensando alle possibili meccaniche di gameplay che potevo creare, in fin dei conti pensavo di avere carta bianca, potevo fare un gioco unico come uno snake al contrario (dove il serpente si muove da solo e il giocatore mette il cibo), oppure prendere spunto da uno dei tanti classici per DOS che mi ha fatto perdere vagonate di ore da piccolo.

Invece i progetti vennero assegnati con già il gameplay prestabilito, bisognava semplicemente copiare un gioco già fatto e replicarlo in Python partendo da una classe data.

Faccio andare il programma di base… Ok, mostra una finestra con un draghetto che passa attraverso pavimenti. Bello… Non salta, si muove a malapena, sbatte contro i bordi della finestra. Un punto di inizio se non altro. Avendo fatto pochi esercizi in Python prima, non ho ingranato subito, specialmente con la questione della programmazione ad oggetti e la gestione logica dei componenti.

La fisica di sicuro è stata la parte più ostica. Determinare come un oggetto collide con un muro non è difficile, e per il modello a scatole (quadratoni che collidono) è anche intuitivo da implementare. Diversamente facile è capire come si deve comportare in presenza di pavimenti! Il suddetto gioco è un platformer simile a Super Mario, dove i muri sono sempre solidi, ma dal basso verso l’alto si può passare da un pavimento all’altro; quindi nel mio caso dovevo fare in modo che se il draghetto entrava dal basso, allora non veniva respinto. Ci sta, purtroppo introdusse una serie di bugs (su carta) che non potevano essere risolti… scartata. Pensai a creare dei punti cardinali di collisione con cui decidere come il personaggio collide con muri e pavimenti, la cosa funzionò meglio, ma aveva comunque limitazioni, per esempio se uno spigolo collide con un altro spigolo si crea una situazione di indecisione, e la cosa produsse solo errori grafici, fatica, frustrazione, carta sprecata, tempo perso.

Dopo altri stupidi tentativi decisi che la cosa migliore era quella di demarcare cosa è un pavimento e cosa è un muro. Facendo così molti problemi vennero eliminati, e con l’aggiunta di una modalità automatica (se è più alto che largo allora è un muro) tutto si risolse.

Bene, collisioni a posto. Ora il salto.

Eh, il salto. Da come lo ho visto negli altri programmi vuol dire che si alza… rimane a mezz’aria fermo per qualche decimo di secondo… poi atterra. A me fa schifo, non so gli altri, forse non glie ne frega dato che non gli è mai stato chiesto, ma io una cosa simile non la consegno. Non è per niente realistico, va a scatti, si ferma in mezzo al nulla, quando cade non accelera.

Mi misi ad implementare un motore fisico migliore. E ce ne volle, passai ore a tentare diversissime implementazioni della formula della gravità (nah, quella standard non va proprio bene), collaudi, diverse dislocazioni dei metodi e dei parametri, calcolo dell’inerzia, poi finalmente una soluzione funzionante. Ogni oggetto tiene la sua inerzia corrente, e lo spostamento è calcolato da un unico metodo dell’oggetto contenitore, che a sua volta ha la gravità e la formula di calcolo centralizzati. Bello, il personaggio cade ed accelera. Ma ogni tanto passa attraverso le superfici sottili.

Perchè succede? Quando viene eseguito uno step dell’animazione, il personaggio in realtà non si muove pixel per pixel, ma esegue una serie di saltelli, quindi se va molto veloce potrebbe oltrepassare una superficie senza neanche accorgersi che esiste.

Risolto in modo eccezionale, ogni volta che si calcola la collisione tra il giocatore ed un oggetto, si somma alla profondità dell’oggetto il prossimo intervallo di movimento più una unità.

Ok, ho la meccanica di gioco, ho la collisione, ho creato quattro muri per farlo girare… i nemici. Implementati con una classe simile a quella del giocatore, ma nel metodo di movimento ho introdotto dei timers casuali per indicare la direzione e il salto. Venne difficile evitarli, non solo i nemici sono imprevedibili, ma sono anche eccessivamente stupidi, quindi sono doppiamente imprevedibili! Andando a caso non c’è modo di capire cosa vogliono fare, c’è solo da starci lontani. Un paio di regolazioni li resero più docili.

Ora il personaggio doveva essere in grado di sparare bolle, nel frattempo cambiai tutto con dei quadrati generici per non fare confusione con le risorse, implementai una classe delle bolle, dei metodi per fare male ai giocatori, una gestione delle vite e degli stati, la fisica di accelerazione contraria dei nemici catturati e così via.

Carino. Ho una serie di quadratoni che si muovono, saltano e sparano. La grafica faceva veramente cagare.

Provai a dare una occhiata alle risorse che si trovano in giro per Bubble Bobble (ma che cazzo di nome è!?) e rimasi ovviamente deluso, tante sprites, niente ambiente.

Ok, proviamo a decidere dei colori per lo sfondo e i muri… nessuno andava bene. Dopo circa un’ora persa unicamente per decidere i colori mi incazzo e scrivo una funzione che cambia colore in continuazione.

Mica male! Un po’ come 140…

Screenshot 2014-12-15 20.45.38

La volta dopo chiesi al prof se era assolutamente necessario fare esattamente la grafica del draghetto, e a quanto mi è sembrato a lui interessava solo la meccanica di gioco. Bene… bene..!

Divisi il file principale in due files, uno per il gioco l’altro per il render, tenendo separate le classi per l’arena e gli oggetti di gioco. Creai un render, un paio di funzioni che cambiavano una serie di colori a seconda del numero corrente di una successione di interi, e dopo la stesura del codice del menu implementai la modalità due giocatori, tra la ideazione della filosofia del gioco e l’animazione della schermata introduttiva misi a posto il codice rendendolo leggibile.

Il risultato fu buono. Venne uno dei migliori risultati della classe, con un tocco diverso dagli altri, uno stile unico e psichedelico, una meccanica efficace. Difficile.

Video del gioco in azione

Lo pubblico qui dato che tenerlo archiviato vorrebbe dire solo lavoro sprecato.

Si può scaricare dal link git:

https://code.mc128k.info/mc128k/SquaredBobble.git

Per compilare PyGame:

https://wiki.mc128k.info/index.php/PyGame

 

Comments (0)
Leave a Comment