Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Questioni di progettazione: automatismi

Cari amici,
è possibile che ne avessimo già parlato in passato, ad ogni modo
vorrei un vostro parere sulla questione dell'implementazione di
automatismi di varia natura al fine di sgravare il giocatore dallo
svolgere azioni meccaniche.
La maggior parte delle guide alla progettazione di avventure testuali
incoraggiano l'introduzione di azioni eseguite implicitamente ed
automaticamente; parlo delle ormai classiche porte che si aprono
automaticamente, o che addirittura si sbloccano se il giocatore
possiede la chiave appropriata, ma gli esempi potrebbero essere
numerosi, basta pensarci un attimo.
Se è vero che sbloccare una porta con la chiave, aprirla e passarci
attraverso può sembrare una sequenza di azioni tediosa da eseguire, io
trovo che l'illusione della manipolazione dell'oggetto attraverso
questi semplici gesti restituisca una piacevole sensazione di
interazione e di manipolabilità, contribuendo ad immergere il
giocatore in un'illusione più tangibile e facendolo sentire padrone
delle proprie azioni.
Probabilmente il buon senso sta nel mezzo, ma mi interessano le vostre
opinioni, sia come sviluppatori che come giocatori.
PaoloM

A mio parere devono essere evitate se l'impianto del gioco tende al
narrativo.
Se invece si tratta di un gioco "smanettone" una mossa in piu' o una in
meno non fa la differenza.
Rob

 ha scritto nel messaggio
news:1126942809.1...@g44g2000cwa.googlegroups.com...


 opinioni, sia come sviluppatori che come giocatori.
io sono nettamente contrario all'idea della azioni automatiche e 
favorevole alla "vecchia scuola" in cui il giocatore deve fare tutto, 
anche le azioni ovvie. Mi sono sempre chiesto che problema sarà mai 
dover aprire esplicitamente una porta chiusa...
ciao
S

 "l'automatismo" non deve andare oltre le solite (tediose) azioni ripetitive.
Parole sante.
Rob

dover aprire esplicitamente una porta chiusa...
Musica per le mie orecchie ;-)
PM

Per questo... dipende dall'impianto del gioco.
Faccio mio il parere del buon Stefano Gaburri.
Credo che il giudizio sugli automatismi possa e debba andare oltre
l'enigma vero e proprio. Sto parlando del gusto perverso della
digitazione... dell'immagine che mi si forma nella mente mentre
visualizzo il mio personaggio frugarsi in tasca per prendere la
chiave, allungando poi la mano per aprire la porta. E se sono
costretto a farlo esplicitamente, l'immagine è più viva. Altrimenti è
come se un'annoiata voce invisibile mi dicesse: "Ok ok, ho capito cosa
vuoi fare. Ora vai avanti, su".
Fastidioso.
In fondo stiamo parlando di gusti personali, ognuno la vedrà a modo
suo, ma anche io appoggio la vecchia scuola e credo che i miei lavori
procederanno su questo binario, ma senza integralismi.
PaoloM

dover aprire esplicitamente una porta chiusa...
Se l'azione e' "ordinaria" ma non e' un problema per te digitarla,
perche' allora non dover digitare "spingi avanti il piede sinistro" e
"spingi avanti il piede destro"?
Rob

"spingi avanti il piede destro"?
Perché la libreria standard non prevede i piedi..... :-)
Scherzi a parte, allora sarebbe il caso di abolire tutte le porte che
non sono protagoniste di enigmi? Voglio dire, se la manipolazione di
una porta ordinaria è automatica, quella porta è solo scenario. Se non
devo manipolarla per usarla, è come se non ci fosse. Tanto vale
citarla solo casualmente nella descrizione dell'ambiente e amen.
Ma così facendo il gioco si impoverirebbe parrecchio, credo.
PM

 > "

 
Scusate se intervengo. Potrei definirmi un profano, in quanto è 
relativamente da poco che gioco alle avventure testuali, ed è 
ancora meno che provo a scriverne una...
Però mi sento di dire che sono d'accordo sia con Paolo che con 
Stefano... un oggetto in una stanza, se c'è e viene menzionato 
chiaramente, deve essere usato in qualche modo.
--  
Postato da Virgilio Newsgroup: scopri i nuovi gruppi 
Eros, foto e video a 
http://newsgroup.eros.virgilio.it

 "spingi avanti il piede destro"?
se è per questo posso guardare la cosa a livelli di astrazione ancora 
inferiori e (pensare di) pilotare i singoli muscoli, fibre muscolari, 
neuroni... è chiaro che la domanda è provocatoria, la risposta peraltro 
è molto banale: il livello di astrazione che propongo (quello in cui le 
azioni hanno una granularità come "apri la porta") è quello usato da 
sempre in tutte le AT classiche, e ha dimostrato di fondere bene 
giocabilità e livello di precisione. Ovviamente ci sono altre 
possibilità, ma allora si va nel campo dei pareri - e io ho espresso 
proprio il mio...
ciao
S

Rob
Saluti da
Vincenzo Scarpa
http://www.casalengo.it/vscarpa/inform/manuale


wrote:

Beh... se io gioco a un'avventura tipo Deadline che si svolge in una
casa, perché devo necessariamente aprire tutte le porte con la chiave?



wrote:

Uffa stasera sono fuso. Volevo dire... perché non prevedere l'azione
automatica di apertura della porta in un'avventura come quella sopra
citata? :)


 Perché la libreria standard non prevede i piedi..... :-)
Esatto, Paolo... esatto.
Ma noi non dobbiamo ragionare in base alla libreria standard.
Rob

 Ma noi non dobbiamo ragionare in base alla libreria standard.
non è questione di libreria... lo stesso discorso potresti farlo per la 
narrativa, perché Tolkien non ha descritto tutte le volte che Frodo ha 
mosso avanti una gamba e poi l'altra? Perché sarebbe stata una cazzata. 
Se l'IF è fiction, il livello di astrazione dev'essere (più o meno) 
quello della fiction.
A me sinceramente tutto il discorso sembra un non-problema; è chiaro che 
se ci sono venti stanze TUTTE chiuse a chiave con chiavi diverse mi 
sfracasso le palle; ma quella non è colpa del livello di 
astrazione/narrazione, ma di un designer deficiente...
ciao
S

 quello della fiction.
E qual e' il livello di astrazione della fiction?
Dipende dal contesto.
In un racconto normale non si perderebbe tempo a descrivere in
dettaglio alcune locazioni, nella IF si, perche' devi dare al giocatore
il punto di "innesto" di un ramo potenzialmente interattivo.
Rob

sfracasso le palle
Certamente. In effetti non volevo evidenziare un problema ma una
pratica piů o meno diffusa (quella degli automatismi, e non solo
relativi alle porte) che, per indole personale, mi vede un po'
dubbioso. Dal momento che l'implementazione dei suddetti richiede un
certo dispendio di neuroni e di codice, mi chiedevo quanto la cosa
fosse sentita e quanto valesse la pena concentrarsi su questo aspetto
collaterale affinché il proprio lavoro venga meglio apprezzato e
goduto.
Ma ecco la soluzione: in un'avventura di fantascienza che ho nel
cassetto, e che riprenderň in tempi brevi..... porte scorrevoli! :-)
Viva la tecnologia....
PM

citata? :)
Questo era un altro parere che mi interessava sentire. No, non c'è
motivo per non farlo. Come giocatore non ne sentirei la mancanza per
motivi che ormai ho chiarito, ma è evidente che i punti di vista
possono essere differenti, quindi investire un po' di energia di
sviluppo in questa direzione può essere opportuno.
Inoltre, come ha detto Stefano, è anche vero che il progettista si fa
carico di non creare un mondo in cui sia presente la necessità di un
numero eccessivo di azioni "tediose".
PM



Beh... tutto serve e allo stesso tempo tutto non serve. Dipende da
cosa si deve fare e soprattutto come, almeno imho. 
Insomma... se scrivo un'at incentrata su enigmi che non riguardano le
porte di per sé (nel senso che non ci sono porte particolari che
richiedano chissà quali chiavi o quant'altro per essere aperte) ok,
altrimenti no. :)



INMHO non e' un'azione, pur ripetitiva , che rende un gioco tedioso o meno ,
non e' l'implementazione (non si vive di solo INFORM e compagnia (peraltro
ottimi))
Se l'AT e' ben congegnata e la trama intrigante il giocatore aprira' anche
trecento porte..
e alla fine pensera' :"peccato le ho gia' aperte tutte! l'At e' finita...a
quando un'altra porta?"
Se , al contrario , la trama e' "soporifera" (x usare un eufenismo) allora
anche l'unica porta finestra puo' essere un problema !;))
Ciao
Roby.


 citarla solo casualmente nella descrizione dell'ambiente e amen.
Qui non sono troppo d'accordo. Se qualche oggetti compare nella 
narrazione, deve esistere e deve essere in qualche modo interattivo. Si 
possono anche, IMHO, trascurare completamente degli elementi e dei 
dettagli che non entrano in alcun modo nella narrazione, ma non si puo' 
trascurare qualcosa che viene citato. Se la porta appare nella 
descrizione dell'ambiente, allora deve essere esaminabile, apribile, 
chiudibile e tutto il resto. Se non serve a niente, meglio non citarla 
affatto.
bye
-- 
Paolo Lucchesi
email: plucchesi(at)tin(dot)it
home page: 
http://www.paololucchesi.it

affatto.
In effetti la mia affermazione era provocatoria... :-)
PM

Vincenzo Scarpa wrote:

A mio giudizio non ci dovrebbe essere più di una porta chiusa a chiave per
avventura. A cosa servirebbero due porte chiuse a chiave? Poprio non si può
trovare un modo + fantasioso di tagliare il giocatore fuori da una parte
dell'area di gioco? Tipo un ponte levatoio, una serracinesca da far aprire
in qualche modo, un muro illusorio, un passaggio segreto, un guardiano
troll, un agente di sicurezza, un virus letale, un gas omicida ... e che
minchia, abbiamo proprio bisogno di così tante porte chiuse a chiave che
serve un automatismo per aprirle? Allora, se permettete, il problema sta da
qualche altra parte.
Gian.



Come ho sostenuto nel thread parallelo.
Gian.

 qualche altra parte. 
GRANDE! :D
Rob

qualche altra parte.
Certo. La questione infatti non voleva limitarsi solo alle porte
chiuse, ma al discorso automatismi in generale.
PM

 ha scritto nel messaggio
news:df43j1loa8cc3hrdh...@4ax.com...

Scusate la frase un po' porvocatoria... x me ci stiamo facendo delle seghe
mentali... ci vorrebbe un automatismo per le idee.... ;)
Roby

Questa interessante discussione mi spinge a scrivere un articolo per
Terra d'IF nella rubrica "Design Review" (che e' aperta al contributo
di tutti, peraltro, come tutti i contenuti di Terra d'IF).
Sto giocando Gumshoe, un gioco del 1996 e all'inizio del gioco c'e'
proprio una porta da aprire e chiudere in continuazione.
Credo che sia un perfetto esempio per l'argomento di cui stiamo
parlando.
Rob

 qualche altra parte.
Se vedessimo la porta chiusa a chiave solo come un enigma (o 
semplicemente un modo di regolare il flusso di trama del gioco) potrei 
anche essere d'accordo con te. Ma spesso alcune porte (che siano o non 
siano chiuse a chiave) sono un elemento logico, integrale e importante 
dell'ambiente descritto e narrato. Devono stare in un certo posto 
perche' in quel posto ci deve essere una porta; e se voglio tener fuori 
il giocatore dal vecchio mulino abbandonato, la cosa piu' logica da 
usare e' una porta chiusa a chiave.
In quest'ottica un automatismo per aprire le porte (sbloccate) al 
passaggio, e magari per sbloccare automaticamente le porte bloccate (ma 
non per aprire e sbloccare automaticamente al passaggio le porte 
bloccate), puo' essere utile al giocatore.
Per fare un esempio, Anchorhead ha svariate porte chiuse a chiave, e i 
suoi buoni automatismi. E funziona bene, non e' pesante da giocare, e il 
numero alto di porte non rappresenta un problema.
Ok, come ha detto qualcuno, e' Anchorhead, e IMHO sarebbe piacevole da 
giocare anche se si dovesse muovere specificatamente ogni fibra 
muscolare... ;-)
Anchorhead ha anche un altro automatismo molto interessante, che e' 
esattamente il contrario di quello che proponeva Roby qualche messaggio 
piu' in su: quando un oggetto viene raccolto, viene automaticamente 
esaminato. Niente male, comodo davvero...
Infine, comunque, mi viene da pensare che una discreta alternativa 
potrebbe essere quella di lasciare al giocatore la scelta (con un 
comando o una voce di menu').


 bye
"prendex?" :-)
Gian.

 avventura, ma di quanti mulini chiusi a chiave hai bisogno?
Il problema "generale" e' fare in modo che le azioni non siano
ripetitive.
Quando un "enigma" e' stato risolto, non ci deve essere bisogno di
"ripetere" le azioni.
Se l'enigma include il fatto che una porzione di mappa sia inibita
fisicamente (e quindi
siamo in presenza di una porta, del gabelliere o di un ragno gigante)
l'ostacolo fisico
(quando l'enigma e' risolto) non dovrebbe piu' essere presente.
In "Isle of The Cult" c'e' un enigma carino che prevede di dover
mettere le mani in una sostanza
collosa per potersi arrampicare su una statua.
Dopo averlo risolto la prima volta, non viene piu' riproposto.
Ogni volta che si scrive "climb statue" viene detto: "Vai alla spiaggia
--", (che e' distante N locazioni)
"-- e ti spalmi la colla sulle mani", dopodiche' sale la statua.
Rob

rgrassi wrote:

Una buona soluzione; ma cosa succede se ci sono dei timer, dei daemon, dei
personaggi erranti che potrei incotrare sul percorso, ecc?
Personalmente avrei risolto la cosa permettendo al giocatore di prendere la
sostanza collosa (i.e. in un contenitore) e usarla (anche in automatico)
quando preferisce. La sostanza dell'enigma non cambia, e l'avventura
diventa + flessibile. Oppure, permettendo al giocatore di salire sulla
statua una sola volta (non starò a spiegare come, ci sono molti modi
eleganti per farlo).
Certo, se non prevedi timer, daemon, personaggi erranti, mappe variabili
ecc, non c'è nessun motivo per non farlo, ma tendenzialmente preferisco i
design che mi consentono la massima flessibilità. Sarebbe seccante, a metà
della progettazione, avere una buona idea per rendere il gioco più
interessante, ma dover rinunciare perché oramai hai fatto una così bella
routine per la soluzione in automatico di certi enigmi precedenti.
Gian.

 personaggi erranti che potrei incotrare sul percorso, ecc?
Quello e' un *altro* enigma (e un altro discorso).
Rob


Il concetto di automatismo, come evidenziato in questi ultimi post,
non è un discorso semplice perché dipende da chi lo esamina, infatti
qui abbiamo da un lato la problematica del designer (gian) e dalla'altra
l'occhio dell'utente (rob). Questo tipo di problema lo si riscontra
frequentemente per chi sviluppa software (a me è capitato diverse volte),
e non di rado l'automatismo porta a "saltare" certi meccanismi di
implementazione adottati. Come sempre, in termini di sviluppo, la soluzione
è una buona progettazione, ma come fare quando ad esempio ti viene
in mente un buon enigma/puzzle? ecco che come nel lavoro, inizi a mettere
le "pezze" per tener contento il cliente... pardòn il player!!!

 le "pezze" per tener contento il cliente... pardòn il player!!!
Se ad un certo punto della implementazione devi iniziare a mettere
'pezze' per
tenere conto del "cliente" allora vuol dire che non era un buon enigma
oppure che
l'hai disegnato male.
Il "cliente" non e' l'ultimo anello della catena, ma il primo.
Rob

 Il "cliente" non e' l'ultimo anello della catena, ma il primo.
Certo ma non sempre, le at ne sono una dimostrazione.

 Certo ma non sempre, le at ne sono una dimostrazione.
Sono una dimostrazione *da non seguire*, secondo me.
Rob

 Sono una dimostrazione *da non seguire*, secondo me.
La richiesta di automatismo nasce dall'esperienza o dall'utilizzo
di un mezzo... quindi a prima botta non lo avrai mai, almeno che
tu non sia esperto del dominio, ma l'esperienza implica l'affermazione
di cui sopra...

 tu non sia esperto del dominio
Sono quasi 30 anni che le AT sono note.
E' sufficiente per te, come 'esperienza' o dobbiamo ancora aspettare?
Rob

rgrassi wrote:

Hey Rob, io sono + che d'accordo nell'utilizzo degli automatismi,
ne ho implementati tanti... (solo schizo ne contiene una decina)...
Tu avrai 20 anni di esperienza, io ne avrò 7... ciccio 2, io volevo 
semplicemente dire che molte volte tu non puoi prevedere tutti gli automatismi
quando ancora la storia è solo su carta... e anche se lo fosse (mo' torno al mio 
primo post) l'occhio di chi sviluppa è diverso da quello di chi gioca...
Un esempio è quello del classico Go To (location), facile da implementare,
però magari prima ci hai messo eventi legati al tuo passaggio, Npc che ti segue,
un altro che fa lo spione, un'auto che deve spuntare dal nulla...

 gli automatismi quando ancora la storia è solo su carta...
Beh, su questo sono d'accordo.
Pero' credo che possa servire mettere giu' una serie di "automatismi"
che
dovrebbero entrare a far parte del "corredo" di un designer di AT,
proprio come
le uscite da citare SEMPRE nelle descrizioni.
Rob