s.c.u.R.F. :: Script Creation Utility for Reality Factory

[Azrael]

Ok, tnx per le risposte

[ada83]

Ciao

Complimenti per il progetto che stai portando avanti.
Ci voleva proprio un tool come quello che stai sviluppando

Una piccola curiosità, sarà possibile creare avventure con visuale anche in prima persona?

[Actarus]

che tu sia la benvenuta,ada(da ada wong?)! anche tu rara estimatrice,come me,degli adventure in soggettiva? favoloso!

[Azrael]

Visto che si parla di prima persona, sarà possibile anche impostare ag tipo Gabriel Knight 3?
Quindi con personaggio 3D però con telecamera che si può muovere a piacimento.

[uomoartificiale]

domande interessanti...
Il progetto si chiama scuRF perchè vuole essere una versione 3d dello scumm e mantenerne alcune caratteristiche: visuale in terza persona, inventario e verbi "a vista", sistema di dialogo etc..
quindi almeno in partenza non ho intenzione di implementare altri tipi di camera. In linea di massima però non dovrebbero esserci problemi a fare modifiche. Voglio dire in sostanza che gestire una camera in prima persona è molto più facile che gestire camera cinematiche in terza persona. Andrebbe tuttavia riconsiderato il ruolo dell'inventario e dell'interazione con gli oggetti: puntatore libero oppure "embedded" nel movimento in prima persona della camera? Ammetto di non avere molta dimestichezza co questo tipo di giochi. In realtà non ho più dimestichezza con i giochi in generale. Gli unici giochi con cui ho mai giocato veramente, a parte microprose soccer su C64 (e molto più tardi metal gear sorrata), sono state le avventure lucas. Sulla terza persona si potrebbe fare lo stesso discorso. Sono soluzioni possibili ed anzi ben meno sofisticate delle camere cinematiche. Il problema semmai è il design generale (vedi il problema dell'interazione con gli oggetti in prima persona). Infatti all'inizio avevo pensato ad implementare i verbi ed, insieme, il "medaglione" (alla Full Throttle, Curse of MI). Ora sono orientato ad una soluzione intermedia con i simboli delle azioni (Mani, Occhi, Bocca, più l'azione "combina") dentro l'inventario "a vista" ed una barra della sintassi nel vecchio stile lucas in cui appaia la frase dell'azione risultante dalla combinazione scelta (ad es. mani+interruttore = premi l'interruttore, bocca+acqua=bevi l'acqua, bocca+Cacciari=filosofeggia con Cacciari).
Per il momento quindi il sistema nascerà seguendo un solo design. Naturalmente voglio confrontarmi con voi - che siete molto più esperti di me in questo campo - sulle ragioni di questo design. In seguito posso io stesso fare un hack del sistema per adeguarlo ad altre esigenze. Se qualcheduno fosse veramente interessato a sviluppare un'avventura usando il sistema, non esiterei a modificarlo per adeguarlo alle richieste.

La settimana si sta rivelando dura come mi aspettavo. Il lavoro tuttavia continua. Ora il sistema genera automaticamente una lista delle risposte disponibili in quel momento senza fare buchi. Purtroppo non sarà possibile avere un infinito numero di risposte. Per adesso ho settato otto risposte possibili. Possono essere visualizzate su schermo quattro risposte per volta. Se ve ne sono più di quattro appaiono le freccine per navigare la lista (anche qui: lucas-style). C'è un bug che non capisco ma con un po' di lavoro lo risolverò.
otto risposte sono troppo poche? Ricreare un duello d'insulti non sarà possibile (sigh!), tuttavia mi sembra che le avventure che sono in giro adesso non abbiano dialoghi così articolati (censuratemi senza pietà se necessario).
La prossima tappa, dopo l'implementazione del sistema logico per la visualizzazione delle opzioni di risposta (già fatto - necessita testing), consiste nell'implementazione di un comando per far "saltare" da una frase dell'interlocutore alle opzioni di risposta di un'altro set. Ciò permette di collegare più frasi dell'interlocutore allo stesso set di opzioni di risposta.

abitualmente terrorizzo le persone intorno a me, voi state reggendo bene... grazie.

[uomoartificiale]

Mi piacciono molto i vostri commenti e devo dire che mi sento a casa in questo forum. Quindi mi permetto di insistere.

Fino a domani sera non posso continuare il lavoro, perciò posto adesso qualche news.
Il sistema di conversazione è pronto all'80%. Il bug precedente nasceva da un conflitto nell'input e ora sembra risolto (richiede qualche approfondimento). La lista sembra comporsi perfettamente. Le frecce di navigazione appaiono se necessario. Ho re-implementato la possibilità di definire le animazioni per il parlato e per la pausa anche per l'interlocutore.
Sono riuscito a definire la possibilità di un salto da una frase dell'interlocutore ad un'altro set di risposte del protagonista. Nell'esempio che sto creando (leggi: altro demo in arrivo per mostrare il sistema di conversazione) l'interlocutore chiede se abbiamo l'oggetto che sta cercando ed appare una lista di quello che abbiamo nell'inventario (se lo abbiamo, naturalmente). Se scegliamo l'oggetto sbagliato egli ci risponde dicendo che il tal oggetto non è quello giusto e ci rimanda alla lista di risposte precedente (che in realtà appartiene al set domanda/risposta in cui l'interlocutore ci poneva la domanda iniziale). Spero di essermi spiegato.
Rimangono da aggiungere:
1) comandi per permettere all'interlocutore di troncare la conversazione
2) opzioni per mantenere la struttura della frase dell'interlocutore omettendo alcune parti a seconda che il tal evento sia già accaduto (oggetto nell'inventario, trigger su true/false etc...). Utile per evitare pappardelloni ogni qualvolta sia necessario parlare con lo stesso personaggio più volte.
Entrambi i punti sono già sviluppati e richiedono testing.

Mostro alcune immagini della lista delle risposte. Le frecce per navigare la lista sono presenti solo se necessarie. Come al solito si sceglie con un click.
http://img149.imageshack.us/my.php?image=screen004tc9.jpg
http://img149.imageshack.us/my.php?image=screen003gx2.jpg
http://img149.imageshack.us/my.php?image=screen001mb6.jpg

[The Uninvited Guest]

Sempre più interessante! Promette bene!!!

Attendo con ansia la nuova demo

[balbinella]

che tu sia la benvenuta,ada(da ada wong?)! anche tu rara estimatrice,come me,degli adventure in soggettiva? favoloso!

credo sia un uomo, raz...

[alexrestaino]

che tu sia la benvenuta,ada(da ada wong?)! anche tu rara estimatrice,come me,degli adventure in soggettiva? favoloso!

credo sia un uomo, raz...

sono anni che gli dico che quel nick è troppo ambiguo...

[uomoartificiale]

2) opzioni per mantenere la struttura della frase dell'interlocutore omettendo alcune parti a seconda che il tal evento sia già accaduto (oggetto nell'inventario, trigger su true/false etc...). Utile per evitare pappardelloni ogni qualvolta sia necessario parlare con lo stesso personaggio più volte.

Lo sviluppo di questo punto ha sollevato dei problemi inaspettati ed è stato momentaneamente accantonato. Il punto 1 invece (comandi per far interrompere la conversazione all'interlocutore) è stato facilmente implementato. Il sistema di conversazione è quindi pronto, finito e funzionante. Sto lavorando ad un piccolo demo per mostrarvelo in azione. La prossima settimana sarà dedicata all'internazionalizzazione dell'interfaccia ed al design dei personaggi non giocanti.
In seguito andranno definite alcune costanti di design per poter raggruppare tutti i comandi sul gameplay in un unico file. Ora la logica che fa partire le conversazioni va definita nei file dello script di conversazione, quella che definisce le scene cinematiche è invece all'inizio dello script del motore cinematico. Questo non è difficile.

Quale pensate dovrebbe essere il comportamento degli NPC (personaggi non giocanti)? Come avevo già scritto, a parte quelli statici, ovvero animati ma non semoventi, ho intenzione di aggiungerne di due tipi diversi. Al momento però le idee mi si sono un po' confuse ed i due tipi mi appaiono un po' troppo simili.
Comunque ho idea di fare prima il design di quelli secondari, i quali dovrebbero semplicemente aggirarsi per il livello e fermarsi se il protagonista si avvicina. Sto pensando anche alla possibilità di programmare che arretrino se scontrati frontalmente (oppure si "scostino" lateralmente se necessario) per evitare che il protagonista si incastri nei passaggi stretti.
Parlando realisticamente, quali elementi credete siano necessari per gli NPC? ad esempio, è necessario che discutano tra loro?

[Actarus]

be' proprio indispensabile non credo,ma come in shenmue aumenterebbe di molto l'immersivita' nell'ambiente di gioco.
Pensi di includere il labiale?(lo chiedo perche' anche qualora non si effettui un doppiaggio puo' essere cmq gradevole)
ancora complimenti!

[Azrael]

Parlando realisticamente, quali elementi credete siano necessari per gli NPC? ad esempio, è necessario che discutano tra loro?

Beh non credo sia strettamente necessario che discutano tra loro a meno che non si parli di eventi particolari o di cutscene.
Certo passare e vedere gli NPC che parlano fra loro del più e del meno renderebbe il tutto più realistico, ovviamente però che possano essere interrotti dal personaggio principale.
Ah ecco, è possibile far fare ad un NPC un'azione "complessa"? Cioè del tipo a seguito di un dialogo questo prende un oggetto e scappa.

Cmq per gli NPC potresti intanto introdurre quelli fissi e quelli che camminano in giro, e poi vedere se è il caso di introdurne anche altri. Penso che già con questi due un'ag si possa fare più che tranquillamente

[uomoartificiale]

lavorando al demo del sistema di conversazione ho invece affrontato il problema dell'internazionalizzazione ed ho trovato una soluzione piuttosto semplice. L'interfaccia può essere tradotta a parte definendo le parole che identificano delle azioni. In questo momento il "core" è ancora in inglese (cioè: in maccheronio ) ma i verbi vengono visualizzati in italiano. Per adesso ho accantonato l'idea di aggiungere in corrispondenza di ogni oggetto una sottodefinizione del verbo d'azione (ad esempio: agisci/apri/premi/manipola...) solo perchè vi cose più importanti da sviluppare. Il meccanismo è tuttavia lo stesso che ho appena escogitato per l'interfaccia, e va solo implementato.

Al riguardo delle azioni complesse degli NPC. Sono confuso sul ruolo dei personaggi non giocanti per due ragioni. A parte gli statici, quelli dinamici che sto progettando possono già fare molte cose. Una nota per farvi capire. Nell'editor RF è possibile definire delle entità che si chiamano scriptpoints. Sono semplicemente dei "segnaposto" identificati da un nome, una posizione (coordinate XYZ), un orientamento (gradi su assi XYZ) ed un ulteriore nome che identifica il successivo scriptpoint. Gli scriptpoint sono così legati l'uno all'altro e formano dei "sentieri" invisibili. Io uso questi per far muovere le telecamere cinematiche (teletrasportandole oppure facendole muovere attraverso i "punti" del sentiero) e li userò per far muovere gli NPC nel livello. Il mio approccio attuale prevede che nel nome dello scriptpoint vi siano dei comandi. Ad esempio, fermarsi, compiere la tale azione, prendere, lasciare un oggetto e simili. Quindi il tutto è già abbastanza complesso. Il punto della questione è: fino a che punto spingersi?
Infatti con una scena cinematica (non un filmato) è piuttosto facile "inscenare" un'azione complessa

Cioè del tipo a seguito di un dialogo questo prende un oggetto e scappa.

questo si può fare con una scena cinematica, ma sono in dubbio e forse anche io preferirei che accadesse in-game (con l'inventario attivo e le telecamere del livello per capirci). Qui ci troviamo nella frontiera AG/RPG...
che ne pensate?

[Actarus]

ehm...scusate l'intromissione....ormai il thread e' divenuto un botta e risposta fra voi due .....avrei porto una domanda,poco piu' sopra.
thank you in advance,uomo

[uomoartificiale]

che cafone che sono! scusa, mi ero perso il tuo post...
uso il thread sia come discussione, sia come blog, se incasino perdonatemi. Lo faccio perchè trovo che sia molto fastidioso quando un progetto non da segni di vita per settimane. Visto che quasi ogni giorno combino qualcosa, per piccola che sia, ne do notizia. le vostre osservazioni sono molto utili nel processo di sviluppo, e nell'ideazione.

Dicevamo...

Pensi di includere il labiale?(lo chiedo perche' anche qualora non si effettui un doppiaggio puo' essere cmq gradevole)

Già ora può essere definita un'animazione per ogni frase pronunciata dal giocatore oppure dall'interlocutore. Ciò permette il lip sync particolare (ogni frase ha una unica animazione che perfettamente collima con l'audio e con il testo) e quindi è possibile anche un lipsync generico che agisca quando non è definita un'animazione in particolare. Tuttavia vi sono alcune questioni da sciogliere:
RF supporta solo animazioni su scheletro, ovvero i vertici di un modello devono essere "linkati" ad uno "scheletro" ed animati muovendo le "ossa" (vi consiglio di cercare su google milkshape3d per capire...). Nei giochi di solito le animazioni facciali sono invece fatte usando le animazioni a "deformazione" (Morph animations) perchè sono più facili da gestire. C'è un solo programma che permette di avere il riconoscimento vocale istantaneo su modelli del viso che utilizzano lo scheletro: si chiama lipsync tool ma costa e per il momento non l'ho provato. C'è un programma che permette di fare il lipsync "a mano" con RF che si chiama ActView+ ma, seppure sia possibile, è un bel lavoraccio fare in questo modo la sincronia di tutta un'avventura.
D'altra parte, ciò che caratterizza la parlata non sembra essere più di tanto il labiale ma la posa complessiva del personaggio, oppure l'espressione facciale indipendentemente dal movimento delle labbra (occhi, angoli della bocca...). E' quindi importante che vi sia anche un set di pose corporee.
Quindi, le soluzioni possibili sono molte. Al momento non ho (e, nonostante le mie prove ripetute, non sono riuscito ad ottenere) un modello che avesse lo skeletro anche sul viso, altrimenti le parlate avrebbero già un'animazione facciale generica. Ho provato a staccare la testa dal corpo dei personaggi per tenere i due set di animazione separati: da una parte il corpo e dall'altra solo il labiale e le espressioni del viso. La testa si animava bene ma il risultato complessivo non era soddisfacente poichè camminando essa si muoveva sempre con un po' di ritardo rispetto al corpo.
Se solo conoscessi meglio 3ds max, potrei riuscire a linkare sul biped le ossa del viso, ma al momento non ci sono riuscito e questo sembra essere l'unico modo per avere entrambe le cose. Infatti a mio parere è molto importante che la sorgente delle animazioni rimanga il biped di max, per poter utilizzare gli archivi di animazioni motion capture presenti in rete (altrimenti sarà difficile svilupare un'avventura con le bellicose animazioni degli sparatutto) e per riutilizzare le animazioni per più personaggi.
Quello del lipsync è quindi un capitolo ancora aperto.
La soluzione che al momento sembra più facilmente percorribile è quella di tenere un lipsync generico per lo svolgimento del gioco e fare il lipsync particolare a mano per le scene cinematiche. In entrambi i casi bisogna risolvere la questione dentro 3ds max.
Spero di avere risposto esaurientemente alla tua domanda.

[Actarus]

certo.grazie ancora.

[uomoartificiale]

solo una nota. Nella creazione concreta di un'avventura vengono fuori gli errori ed è lì che si svolge il vero bug-testing. Altrimenti si continuano a far girare gli stessi loop di codice nello stesso ordine e non si vedono i problemi. Nella creazione del demo del sistema di conversazione sono saltati fuori un paio di bug:
1)la conversazione non veniva re-inizializzata correttamente.
2) non era possibile far partire una scena cinematica dall'interno della conversazione.

risolti entrambi ma hanno rubato del tempo. L'interesse di raziel per il doppiaggio mi ha spinto a preparare il codice per l'audio della conversazione e l'ho inserito, quindi sto registrando la voce di questa conversazione (che tra l'altro è stupidissima e molto poco fantasiosa). Stasera la mia compagna registrerà la voce dell'interlocutore (metterò un personaggio femminile). Come ho precedentemente scritto, ho messo le basi per il sistema di traduzione. Non è ancora completo quindi forse dovrò perderci ancora qualche giorno. Il prossimo demo quindi non mostrerà solo il sistema di conversazione, anche se la maggior parte delle modifiche sono state fatte "dietro le quinte" e sono visibili solo in parte.

[Azrael]

Ottimo, mi sembra tu stia procedendo benissimo.
Una tabella di marcia come questa molti progetti free se la sognano

[Actarus]

ben detto.

uomo,se vuoi,essendo io un fanatico duro del doppiaggio,nonche' doppiatore velleitario io stesso,mandami pure qualche testo(in qualunque lingua....mastico un po' di tutto ) in mp e provvedero' a registrare degli anelli "pattern",che potresti utilizzare all'occorrenza.

[uomoartificiale]

Grazie ancora a tutti dell'incoraggiamento.
Ti ringrazio raziel, terrò conto della tua disponibilità nello sviluppo del demo ufficiale, grazie. Per adesso ho usato la mia voce fessa perchè ho dovuto fare un po' di prove. La mia compagna Thaiz invece ha dato una grande prova d'attrice, caratterizzando perfettamente il personaggio femminile che stiamo utilizzando nel deo di conversazione (che abbiamo fatto un poco krukko...).
Ho raggiunto e superato il punto di sviluppo che mi ero prefissato per questa ulteriore alpha release.

-sistema di traduzione completato. Non sarà proprio il metodo più agevole ma è possibile tradurre - oltre al frasario - l'interfaccia ed i nomi degli oggetti. In pratica vi sono due livelli: gli oggetti hanno un nome di sistema, che viene utilizzato per le variabili interne e gli attributi d'inventario, e poi hanno un nome pubblico che viene visualizzato su schermo. Quindi tutto può essere tradotto senza modificare i nomi di sistema che vengono utilizzati per definire la logica del gioco. Sulla possibilità di avere una versione multi-lingua non mi sono impegnato a trovare una soluzione. Eventualmente si creerà un programmino (si può fare perfino con flash) che copi i file da un archivio nel "posto giusto", sovrascrivendo i file di testo (ed audio eventualmente).

- Doppiaggio delle conversazioni. Ho eseguito il doppiaggio ed ho messo a punto il sistema audio nelle conversazioni separato dall'audio di fondo (è possibile riprodurre effetti audio durante la conversazione). Sono riuscito a mettere quattro ossa in viso ai personaggi e ho prodotto un lip-sync generico che accompagna il loro parlato. Utilizzando il programma di lipsync non è affatto chiaro ancora in quale maniera l'engine potrebbe reagire all'applicazione dell'animazione (non è possibile animare il tronco ma in-game ciò non sembra avere influenza - richiede testing). Ho utilizzato milkshape ed ho ottenuto un semplice blah-blah da usare come sottofondo per la parlata dei personaggi. se l'audio e l'animazione hanno una lunghezza compatibile l'effetto è gradevole.

- Scene cinematiche in-game. Qualcuno in precedenza ha sollevato la questione di gestire le azioni del giocatore, oppure degli NPC, che si svolgono durante il gioco. Ad esempio, al giocatore viene dato il comando di prendere un oggetto e la sequenza che ne deriva è maggiormente complessa del tipico cammina-fin-lì/allunga-la-mano/pronuncia-la-frase. La sua azione prevede anzi di muoversi per un percorso fino ad un punto, compiere più azioni, pronunciare più frasi ed ottenere in risposta più azioni e frasi in risposta dagli NPC. Ora questo è possibile.
Ho aggiunto un'opzione al motore cinematico affinchè la telecamera delle scene animate possa coincidere con quella del gioco. In questa maniera non si ha l'impressione di entrare in una cutscene. semplicemente la sequenza viene riprodotta come un elemento interno al gioco.

- Portare un oggetto. Ancora in fase di prototipo, richiede un po' di pulizia, ma funzionante. I personaggi possono portare un oggetto (uno solo ahimé) in mano, in testa, in faccia (baffi, occhiali...) che si muove con discreta precisione seguendone l'animazione. Ho aggiunto il comandi per poter definire nel motore cinematico l'aggiunta degli oggetti.

Tutto è pronto ma sto ancora finendo il demo della conversazione (in realtà sto finendo la scena cinematica che chiude la conversazione). Ancora pochi giorni...