Corso di Laurea in Tecnologie Web e Multimediali
Esame di Programmazione e laboratorio, A.A. 2007/08
Progetto per l'appello 14,16/04/2008:
Implementazione di un semplice gioco adventure
Premessa
Leggete bene tutte le istruzioni! In particolare i
paragrafi modalità e raccomandazioni.
Introduzione
Un adventure è un gioco a tappe in cui bisogna
scegliere le opzioni giuste ad ogni tappa per riuscire a trovare il
percorso vincente. Tipicamente le tappe vengono mostrate una alla
volta, in formato testo o grafico.
Descrizione del lavoro
Si richiede di implementare un programma che, tramite
un'interfaccia grafica, consenta all'utente di "giocare" un semplice
adventure, descritto in un file di testo formattato opportunamente. Il
programma deve:
- Consentire la scelta del nome del file di testo da cui leggere le
varie tappe da linea di comando (parametro del main).
- Gestire opportunamente il caso in cui il file specificato
dall'utente non esista (visualizzando un messaggio opportuno).
- Avere un'interfaccia utente grafica per gestire la comunicazione
con l'utente.
- Visualizzare il contenuto della tappa corrente in un'area di
testo.
- Consentire all'utente di scegliere la tappa successiva tramite un
insieme opportuno di pulsanti. Deve esserci un pulsante per ogni
opzione possibile (ossia per ogni tappa immediatamente raggiungibile
dalla tappa corrente) e ogni pulsante deve avere come etichetta il
numero della tappa successiva corrispondente. La GUI è quindi
dinamica e cambia a seconda della tappa in cui ci si
trova.
- Mettere a disposizione dell'utente un'area di testo in cui
"segnarsi" alcune scelte effettuate per mezzo di caratteri.
Un esempio di interfaccia del programma è riportato nella
figura seguente. L'area di testo non editabile in alto a sinistra
mostra il testo della tappa corrente. L'area di testo sulla destra
serve all'utente per "segnarsi" le scelte effettuate. Il pannello in
basso contiene tanti pulsanti (2) quante sono le tappe successive
possibili (la 11 e la 10).
Ovviamente, questa è solo una delle molte possibili
implementazioni, che viene fornita solo per esempio, e che
quindi siete liberissimi di modificare.
Il formato del file contenente le tappe è il seguente:
- Una prima riga contenente un numero intero uguale al numero di
tappe totali.
- Per ogni tappa:
- Una prima riga contenente il numero identificativo della tappa (1
per la prima, 2 per la seconda, ecc.)
- Una seconda riga contenente un numero intero (chiamiamolo
N) che indica quante delle righe successive contengono il
testo da visualizzare per quella tappa.
- N righe contenenti il testo da visualizzare per quella
tappa.
- Una riga contenente un numero intero (chiamiamolo M) che
indica quante opzioni sono possibili per quella tappa.
- M righe contenenti ognuna un intero che indica la tappa
successiva a seconda dell'opzione scelta.
Nel file le tappe sono ordinate (il file comincia con la prima
tappa, poi c'è la seconda, ecc.). Il programma deve funzionare
con qualsiasi file che rispetti le convenzioni suddette. A titolo di
esempio, vi forniamo un "adventure" per la
realizzazione del progetto di programmazione. Notate la tappa
numero 9, corrispondente alla figura precedente:
9
3
Ormai non c'e' piu' tempo per trovare qualcun altro che non sia gia' in un gruppo.
Se decidi di fare da solo, segna 1 e vai al 11.
Se decidi di cercare qualche altro gruppo a cui manca un componente e aggregarti a loro, vai al 10.
2
11
10
Siete ovviamente liberi di divertirvi e sperimentare altri file...
Suggerimenti
- Rappresentate in un'opportuna struttura dati in memoria tutte le
tappe (quindi leggerete il file un'unica volta all'inizio
dell'esecuzione del programma...).
- Potreste aver bisogno di una classe
Tappa
, definita da
voi, per rappresentare una singola tappa...
- Vi servirà il metodo
Integer.parseInt(String)
per convertire una stringa in un intero (ad esempio, la stringa
"5"
nell'int 5
)
- I pulsanti in basso andranno
cancellati e ricreati ad ogni tappa. Per farlo, vi possono essere
utili i metodi:
public void remove(Component comp)
di
java.awt.Container
(ereditato da
Frame
...);
public void validate()
di java.awt.Container
(ereditato da Frame
...); e
-
public void repaint(long
tm)
di java.awt.Component
(ereditato da
Frame
...).
Guardate la documentazione delle API corrispondente.
Il livello di complessità del programma prodotto può
essere deciso liberamente dagli studenti; ovviamente, progetti
più articolati e complessi otterranno una valutazione migliore
di progetti più semplici, ma si consiglia di fare "poco
e bene" piuttosto che "tanto e male": progetti semplici
possono comunque ottenere il massimo punteggio, purché ben
fatti. La durata prevista del lavoro, considerando un gruppo di 3
persone che lavorano a tempo pieno, è di una settimana al
massimo.
Il progetto va realizzato in gruppi di 3 persone (a meno di accordi
particolari con il docente, possibili solo in casi di reale e
comprovata necessità), e tutti i componenti di
un gruppo devono conoscere tutti i dettagli del
progetto, come se l'avessero realizzato da soli.
Va preparata una breve relazione, preferibilmente (ma non
necessariamente) in XHTML + CSS, sul lavoro effettuato. La relazione
deve contenere:
- Una breve analisi del problema ed una descrizione intuitiva della
vostra soluzione (meno di 2 pagine!).
- Le eventuali semplificazioni apportate rispetto alla versione
completa richiesta (poche righe). Le semplificazioni vanno
adeguatamente motivate. Ovviamente, le semplificazioni porteranno a
valutazioni inferiori, e in alcuni casi (quando le semplificazioni sono
eccessive) a progetti insufficienti.
- Eventuali aggiunte (cose in più non richieste; ad esempio
uso di componenti dell'AWT non spiegati a lezione, uso delle Swing,
aggiunta di funzionalità non richieste, aggiunta di menu,
ecc. ecc.). Prima di aggiungere qualsiasi cosa, pensate a fare
bene quello che è richiesto.
- Le motivazioni di tutte le scelte effettuate (ad
esempio, perché avete apportato una semplificazione,
perché avete deciso di usare certi componenti grafici e non
altri, perché avete fatto certe scelte di progetto piuttosto
che altre, e così via).
- Il listato completo del programma, con commenti
(in javadoc, ma non solo), scritto in font non proporzionale (come
questo: la "i" e la "m" occupano la stessa larghezza) e
opportunamente incolonnato ("indentato").
- Una "prova di esecuzione" (di circa 3 pagine) che illustri il
funzionamento del programma: una spiegazione con testo e figure del
modo in cui il programma funziona (aspetto dell'interfaccia utente,
esempio di esecuzione adeguatamente spiegato, ecc.)
Il progetto va consegnato inderogabilmente entro l'inizio
della prova scritta dell'appello, ossia il 14 aprile 2008 ore 14:00,
sia in forma cartacea (1 copia), sia via posta elettronica (2
copie, una per docente, indirizzi: coppola@uniud.it e
mizzaro@dimi.uniud.it). Si richiede un
unico messaggio:
- con oggetto "Progetto per Programmazione [TWM]",
- contenente nel corpo i nomi dei componenti del progetto e,
- in allegato ("attach"), in un unico file compresso (ad
es. zippato), la relazione, il codice sorgente (i file ".java") e il
bytecode (i ".class").
Il progetto in forma cartacea può essere consegnato a
mano subito prima del compito scritto oppure può essere
consegnato nei giorni precedenti lo scritto direttamente a uno dei
docenti o nella casella della posta del dipartimento di matematica e
informatica.
NOTA Questo progetto è valido per chi intende
sostenere l'esame nell'appello del 14, 16 aprile 2008, e va quindi consegnato entro la scadenza. Non si
accetteranno ritardi per nessun motivo. Per gli appelli successivi
saranno predisposti altri progetti.
Alla valutazione del progetto concorrono vari aspetti (rilevanza delle
semplificazioni apportate, qualità della relazione, ecc.), ma
è di prioritaria importanza la qualità del
programma prodotto, soprattutto per quanto concerne le caratteristiche
di leggibilità, modificabilità... Esempi di criteri per
ottenere una valutazione positiva:
- Il programma funziona?
- Resiste agli errori di interazione con l'utente?
- Si riescono ad apportare piccole modifiche nel comportamento senza
riscrivere molto codice?
- L'interfaccia utente grafica è ridimensionabile? (ossia: non
avete usato
setResizable(false)
)? E quindi la si può
usare su schermi di varie dimensioni?
- Avete usato i layout manager?
- Il codice è scritto correttamente, e avete seguito i
principi della programmazione strutturata, dell'occultamento delle
informazioni e dell'object oriented?
- Il codice è commentato? Ci sono abbastanza commenti? Non ci
sono troppi commenti? I commenti non sono scontati? I tre tipi di
commenti disponibili in Java sono stati usati in modo corretto?
- La relazione è chiara?
- Le variabili d'istanza e di classe non possono essere ridefinite
come variabili locali?
- ecc. ecc.
Altre raccomandazioni:
- Non dichiarate una variabile se poi la usate una sola
volta. Potete sicuramente scrivere un programma analogo senza quella
variabile.
- Non copiare scriteriatamente il codice trovato su Internet:
chiunque può scrivere su Internet e non è detto che
sappia cosa sta facendo.
- Evitate al massimo
setPreferredSize
. Piuttosto
pensate ad un layout che funzioni con qualsiasi dimensione
sensata.
- Evitate commenti del tipo
x = 2; //assegno 2 a x
:
qualunque programmatore sa cosa vuol dire x=2;
!!
- Non usate
static
solo perché il compilatore dà
errore. Usatelo solo se serve veramente.
- Limitate al massimo l'uso delle variabili d'istanza e di
classe, preferite le variabili locali ai metodi.
- Non usate
public
solo perché il compilatore dà
errore. Usatelo solo se serve veramente.
Per eventuali dubbi rivolgersi ai docenti, o durante l'orario di
ricevimento o per posta elettronica.