In questa parte tratteremo gli argomenti fino alla classe impostazioni. Riporterò il codice completo, comprese le funzioni che abbiamo già analizzato nelle puntate precedenti (specificando eventuali modifiche).
Come al solito, non si capirà immediatamente lo scopo del programma, ma seguendolo passo passo, arriverete a comprendere tranquillamente questi concetti. Pensate solamente che queste basilari nozioni possono essere implementate secondo le vostre singole necessità, la base è sempre la stessa: creatività ed ingegno per risolvere un problema (però anche la soluzione non deve essere troppo ostica o difficile per poter essere applicata!!!).
Le funzioni tps e carica_imm_sprite sono rimaste immutate, compreso il loro funzionamento, quindi non spenderò ulteriori parole a riguardo.
La classe giocatore è simile alla classe sprite che abbiamo creato nell’esempio precedente. Unica differenza sostanziale è la mancata gestione di Rect, perché in questo caso vogliamo solo muovere il nostro giocatore sullo schermo e memorizzare la sua posizione con un salvataggio. La gestione dell’animazione è identica, come la sua renderizzazione.
Passiamo invece alla nuova classe ingame:
Questa classe ha il compito di mantere e gestire l’istanza di gioco. In questo caso viene inizializzata con il giocatore corrente, lo schermo dove si deve renderizzare e l’immagine dello sfondo.
Il render è molto semplice e consiste solo nel fatto di stampare a video l’immagine dello sfondo con il giocatore.
Questa classe è necessaria, in questo esempio, per passare dal menù al gioco e viceversa. Separando le due cose infatti, è più semplice gestire quello che sono le semplici meccaniche di gioco dalla gestione esterna. Nella nostra situazione però, come già accennato, sarà sempre il menù ad avere il “comando” della situazione.
Anche la classe impostazioni fa la sua prima comparsa in questo esempio:
Come possiamo vedere, questa classe ha bisogno solo di essere inizializzata con delle impostazioni di base. Per ora non abbiamo impostato nessun metodo che lavori su di essa, perché ho preferito agire direttamente sui suoi componenti per cambiare lo stato delle cose. Essendo gestita in questo modo, non ha bisogno di altro perché ci servirà solo per creare il nostro primo oggetto impostazioni, che sarà salvato con cPickle (vedremo in seguito come), per poi essere modificato dal menù a seconda delle nostre esigenze.
Le componenti di questa classe sono le seguenti:
Larghezza ed altezza dello schermo.
Quattro variabili booleane per memorizzare lo stato dei flag : full (Fullscreen o no), bool_hw (per l’accelerazione hardware), bool_buff (per l’utilizzo del Double Buffer), bool_opengl (per settare l’utilizzo dell’opengl).
Depth indica la profondità dello schermo.
Frequenza, dimensione, canali e buffer invece rappresentano le variabili di controllo per inizializzare il mixer. In questo esempio non eseguiremo cambiamenti a queste ultime, ma basterà aggiungere poche righe per adattarlo anche a questo compito, visto che il caricamento delle impostazione è sempre lo stesso e viene eseguito con tutti gli elementi di impostazioni. Dimensione ha un valore negativo per ovviare a problemi di compatibilità con sistemi operativi differenti da windows (infatti quest’ultimo non fa distinzioni e comunque sia, la qualità audio non cambia).
Per ora l’opengl è solo impostabile come flag, ma quasi sicuramente riscontrerete degli errori. Questo perché ancora non abbiamo visto come inizializzare una scena in OpenGL. Più avanti toccheremo anche questo tasto, un pò più pesante da digerire.
Conclusioni
Iniziamo così la nostra analisi riguardante questo nuovo esempio. Per ora c’è poco da dire e da capire, ma con la prossima parte le cose saranno più complicate, visto che parleremo della classe menù. Quello che continuerei a sottolineare è il fatto che non è facile trovare la soluzione alle proprie esigenze, ed è ancora più difficile trovare una soluzione adattabile a molte situazioni.
Essendo proprio quest’ultimo il mio obbiettivo, potete un pò capire il mio disagio nel presentarvi questi esempi, perché potrebbero essere utili solo ai miei scopi, ma inutili e difficilmente comprensibili e/o utilizzabili dalla maggior parte delle persone che leggono.
Per questo cerco sempre di specificare anche le differenti possibilità di utilizzo delle funzioni che presento, così da far capire le varie scelte che si possono presentare durante la stesura del codice o nella creazione del videogioco in se, mettendovi in condizione di gestire la situazione con le vostre forze.
Con questo vi saluto e vi do appuntamento alla prossima parte.
In Appunti Digitali cerchiamo di esprimere punti di vista informati su questioni che conosciamo, materie che pratichiamo professionalmente o passioni seguite a lungo e con metodo. Nei limiti del poco tempo che possiamo dedicare alla scrittura di articoli, speriamo di aiutarvi a costruirvi un’opinione su materie complesse, informarvi e se possibile divertirvi. I conti del server li paghiamo di tasca nostra e ci riserviamo perciò di moderare i commenti a nostra discrezione.
