Da un po'
di tempo a questa parte ogni mese cerchiamo di proporre un semplice
esempio di un qualcosa che permetta di realizzare in maniera veloce
una piccola applicazione con la quale imparare a muoversi nella programmazione
di questo linguaggio.Questo mese vediamo come si può realizzare
un semplice gioco, il famoso Arkanoid, e magari divertirsi un po'. Il gioco
è inserito nella pagina raggiungibile cliccando qui
 Arkanoid
era un gioco che andava di moda alla fine degli anni ottanta, consisteva
nel far colpire ad una pallina tramite un paletta una serie di mattoncini
colorati.
Volendo
realizzare il gioco in java occorre modellizzarlo secondo la logica della
programmazione ad oggetti. Per far ciò dobbiamo individuare le classi
fondamentali che compongono il sistema. Queste classi sono la pallina,
il mattoncino e la paletta. Una volta identificate le classi base del sistema
ci si accorge che esse hanno delle proprietà in comune, ad esempio
tutte occupano una particolare posizione sullo schermo, tutte avranno un
colore che le distingue ecc. Da questa analisi possiamo dire che tutte
le classi derivano da una classe base che chiamerò “Figura”
e che ad esempio la classe “Paletta” non è altro che una specializzazione
della classe “ Mattone”.
A questo punto
lo schema di rappresentazione degli elementi che compongono il sistema
diventa il seguente:
Il
gioco risulta quindi essere costituito da una pallina, una paletta, una
serie di mattoncini che possono essere rappresentati da una lista ed un
contesto di gioco. Il sistema dovrà anche occuparsi del controllo
delle interazioni tra la pallina e i vari oggetti che compongono il gioco.
Lo schema
del funzionamento del gioco può ora essere rappresentato nel modo
seguente:
Analizzando
lo schema di funzionamento ci si accorge che il gioco si può trovare
in uno dei seguenti stati:
1. Gioco in
esecuzione: per intenderci è quando il giocatore sta effettivamente
manovrando la paletta mentre la pallina è in movimento
2. Gioco
in pausa: il gioco è in pausa quando il giocatore può
muovere la paletta ma la pallina è ferma
3. Fine vita:
si è in questo stato quando il giocatore perde un vita
4. Fine partita:
quando il giocatore ha perso tutte le vite a disposizione
5. Mattone
colpito: quando la pallina colpisce un mattoncino
6. Mattoni
finiti: quando il giocatore colpisce l’ultimo mattoncino di uno schema
Individuati
gli stati e lo schema di funzionamento del gioco è necessario ora
stabilire come mantenere il controllo di esecuzione del gioco. Nel mio
caso ho deciso di sviluppare una classe controllo che contiene tutti gli
elementi del gioco, si occupa della gestione delle interazioni e tramite
un metodo definito Controllo individua lo stato del gioco e si comporta
di conseguenza.
Nel realizzare
la classe di controllo il problema più spinoso da risolvere è
stato quello di realizzare una procedura che: riuscisse a controllare l’interazione
della pallina con un mattoncino; determinare la direzione di provenienza
della pallina ed il lato della figura colpito. Queste informazioni sono
necessarie per riuscire a ricalcolare la direzione della pallina, ad esempio
se la pallina ha direzione Nord-Est e colpisce il lato a Sud del mattone,
successivamente la direzione della pallina sarà Sud-Est
; diversamente se il lato colpito fosse stato quello ad Ovest, la
direzione della pallina sarebbe stata Nord-Ovest.
figura 4: movimenti
della pallina durante il gioco
La fase di controllo
dei mattoni è così articolata
Per
determinare il lato in cui il mattoncino viene colpito seguo un procedimento
un po’ particolare: determino la coordinata y del lato sud (è data
dalla posizione del mattoncimo + la metà della sua altezza), gli
sottraggo la coordinata y della pallina, se il risultato in valore assoluto
è minore o uguale al raggio della pallina significa che il lato
è stato colpito. Può sembrare un ragionamento contorto ma
non ho trovato di meglio!…, graficamente comunque è molto più
semplice da vedere:
Alla
fine abbiamo la classe Applet che si occupa del ridisegno del gioco e la
classe Controllo che si occupa della gestione del gioco vero e proprio.
Sarebbe stato possibile scrivere solo la classe Applet ma ai tempi in cui
ho scritto il gioco ero alle mie prime esperienze con java.
Prestazioni
e miglioramenti
Come ho già
detto i mattoncini li gestisco con una lista e questo determina un’esecuzione
dell’Applet non molto brillante se fatto girare su un browser, mentre se
si fa girare con Appletviewer il gioco risulta essere molto più
fluido. Il motivo principale della lentezza del programma è che
il metodo di controllo deve scandire tutta la lista di mattoni per determinare
se c’è stata interazione o meno. Per aumentare le performance di
esecuzione si potrebbero gestire i mattoncini con una matrice vincolata
alla posizione del mattoncino stesso, in questo modo risulterebbe anche
semplificato il metodo che determina se un mattoncino è stato colpito
o meno dato che basterebbe guardare la posizione della pallina e andare
a scandire solo i mattoncini vicini.
Invito
chiunque volesse a modificare liberamente il codice sorgente per migliorare
il gioco stesso, per qualsiasi problema potete scrivermi al mio indirizzo
e_mail.
Mi spiace di
non aver avuto il tempo di commentare adeguatamente il codice e di migliorare
io stesso il gioco ma sono un po’ “incasinato”con la mia tesi.
Voglio
ringraziare la direzione di MokaByte e in particolar modo Giovanni Puliti
che mi ha dato man forte nell’utilizzo delle librerie JDBC e RMI. Un
ciao a tutti.
Download
Scarica
Arkanoid
|
