Costruzione
di interfacce aa 04/05
Esame
I appello
V1.05
- 14/1/05 11:15
L'esame consiste nel
completamento del gioco visto a lezione; partite dai sorgenti che vi metto a
disposizione( MM_V1.1.zip aggiornati il
13/1/05) e procedete come indicato nel resto del documento. L'esame va svolto
in gruppi di una, due o tre persone. Gli asterischi indicano tutte le
funzionalità da implementare a seconda del numero di persone del gruppo:
-
una persona deve fare *
-
due persone devono fare * e **
-
tre persone devono fare * , ** , e ***
Scadenza 21/1/05 ore 24:00
Entro il 18/1/05 i gruppi che
intendono consegnare il progetto, devono comunicarlo con una mail al docente (e
non al gruppo); soggetto della mail [CI][Esame] Iscrizione; contenuto della
mail, cognome, nome, matricola e login su yahoo dei componenti del gruppo.
Il forum del corso sarà considerato il
luogo principale per tutte le comunicazioni (chiarimenti e modifiche alle
specifiche e sorgenti distribuiti).
Modalità di consegna
Per posta elettronica con
un mail con soggetto "[CI] Esame - Consegna". La mail deve avere come
attachment uno zip contenente i sorgenti del gioco strutturati come nella
distribuzione, i due esegubili, e un breve documento testo (una paginetta o
due) in cui elencate le migliorie fatte all'editor ed al player durante la
ripulitura. Lo zip deve contenere anche la directory MM e gli eseguibili devono
stare (e funzionare) in tale directory ed assumere che i livelli stiano nella
dir levels, mentre texture e dati aggiuntivi stiano nella dir data. Assumete
che glew e sdl siano al solito nella dir c:\code (come nei .pro che vi
distribuisco)
Il nome dello Zip deve
essere dato dalla giustapposizione dei cognomi in ordine alfabetico dei
partecipanti al gruppo con la prima iniziale del cognome di ogni persona in
maiuscolo (e.g. CaioSempronioTizio.zip PallinoPinco.zip
Serbellonimazzantiviendalmare.zip). Lo zip non deve contenere NESSUN file che
possa essere generato automaticamente a partire dal .pro (e.g. no .obj, .ilk,
vprj, .sln, .pdb, moc_*, Makefile, ecc.) e dovrebbe essere < 1mb. Se
avete particolari esigenze per texture e cubemap e proprio non ce la
fate a stare in questi limiti fatemelo sapere tramite forum.
Note: per compilare avete bisogno di
due librerie (entrambe opensource e portabili);
-
-
SDL
http://www.libsdl.org/index.php
Simple DirectMedia Layer is a cross-platform multimedia library designed to
provide low level access to audio, keyboard, mouse, joystick, 3D hardware via
OpenGL, and 2D video framebuffer
Player
In SDL a tutto schermo; qt
deve essere usato solo per loading (img e xml) e funzioni utlity da console ed
assolutamente non per dialoghi vari (ad es. non usate il file open dialog di qt
nel player).
Durante il gioco si deve
controllare la pallina con il mouse e la vista con i tasti cursore
(left-right rotazione, up-down inclinazione, pageup pagedown zoom sulla
pallina). La camera durante il gioco deve essere sempre centrata sulla pallina
(e di conseguenza anche tutte le rotazioni e zoom). Il movimento
della pallina viene trasmesso tramite azioni di drag del mouse. Ogni azione di
drag definisce una retta nello spazio dello schermo, la forza impressa alla
pallina deve essere nella direzione corrispondente a tale retta proiettata sul
piano della griglia e l'intensità della forza deve essere proporzionale alla
lunghezza.
Il player deve:
-
* Mostrare una schermata intro con credits: il
minimo e' che contenga il titolo del gioco, il nome degli autori e un minimo
menu' che permetta di accedere alla lista di livelli,uscire ecc. (animazioni
varie solo se vi fa voglia...)
-
* Mostrare lista di file da caricare e permettere la
scelta del livello
-
* Caricare livello
-
* Permettere di giocare interattivamente mostrando
una schemata di vittoria se si finisce il livello (si raggunge l'end)
o di gameover se finisce il tempo o se la pallina cade da troppo alto.
-
*** Permettere di mettere il gioco in pausa
(mantenendo la possibilità di ruotare la vista)
-
*** implementare un meccanismo di preview dei
livelli con thumbnails
-
** la pallina deve avere una texture che permetta di
capire come sta ruotando e ovviamente far ruotare la pallina in relazione al
movimento
Editor
Realizzato usando QT per
gestire l`interfaccia utente. Partire da quello mostrato a lezione; ripulire e
risistemare l'interfaccia (miglior disposizione dei widget e rimozione di tutti
i bachetti che trovate). Notare che alcune funzionalità implicano cambiamenti
nella dinamica del gioco e quindi possono anche coinvolgere il player
Aggiungere le seguenti
funzionalità:
-
* Settare start e end e tempo per il livello (di end
ce ne possono essere piu'di uno)
-
* texture sulle pareti della cella: oltre ad un
unica texture per la parte superiore delle celle, aggiungere un'altra texture
per le pareti verticali (uguale per tutte le celle, ma differente da quella
della parte superiore)
-
*** modalità di test del livello (durante la quale si può anche
guidare la pallina come nel player, ma mostrata nel widget di qt) con
possibilità di far partire la pallina da dove si vuole.
-
*** texture customizzabile per singola cella (solo
la texture della parte superiore).
-
* mattonelle ghiaccio o colla: sulla colla la
pallina va piu' lentamente, sul ghiaccio gli input del player sulla pallina non
hanno quasi effetto e quindi il giocatore non puo controllare la pallina; le
celle ghiaccio e colla hanno una texture sulla parte superiore differente dalle
altre celle per distinguerle durante il gioco.
-
** Una a scelta tra
-
blocco girevole: un parallelepipedo di
dimensioni scelte dall'editor in che ruota con velocità angolare costante
e che può colpire la pallina,
-
sponde: delle ringhiere da piazzare su selezioni
rettangolari di 1xN celle, che abbiano la prima e ultima cella diverse (inizio
e fine della ringhiera) e che a scelta dell'editor possano far rimbalzare la
pallina più o meno forte.
-
funzionalità di editing della griglia (modificano
solo le altezze delle celle della griglia):
-
* smoothing orizzontale e verticale: uno smooth che
permetta discontinuità sui bordi ottenute mediando, sul bordo, solo con
gli altri vertici per riga o per colonna della griglia; nello smooth normale
tutti i vertici sono sostituiti simultaneamente con la media degli
adiacenti, qui, limitatamente ai vertici di bordo di riga/colonna, si
deve sostituire con la media dei due adiacenti o nel senso della
riga/colonna . In pratica l'effetto dell'applicazione ripetuta dello
smooth classico è quello, per le altezze delle celle della zona
selezionata di simulare il comportamento di una membrana elastica in
cui i bordi sono bloccati sulle posizioni iniziali. Nello smoothing
orizzontale/verticale l'effetto è lo stesso solo che i bordi
orizzontai/verticali non sono vincolati.
-
** costruzione di rampa automatica: data una
selezione rettangolare, spiana (flatten) i lati piu stretti del rettangolo
e costrisce il piano inclinato che li collega.
-
*** valle: data una selezione rettangolare dargli
una forma 'a valle' nel senso della maggior lunghezza del rettangolo. In
pratica applicare alla selezione uno smoothing oriz o vert. a seconda delle
proporzioni della selezione e aggiungere un offset negativo ai vertici delle
celle interne alla selezione che dipende dalla distanza dal bordo della
selezione.
-
** Evitare di far creare le pareti verticali, tra le
celle, non strettamente necessarie (in una funzione di postprocessing):
-
se due celle adiacenti hanno l'edge condiviso ad
eguale altezza, non generare nessuna parete;
-
se due celle adiacenti hanno l'edge sul lato in
comune ad altezza diversa fare una sola parete che parta dall'edge più in basso
fino all'altro.