Ancora parallelismi

[Davide Losito - ( Khana )]

[cite]Postato da: rgrassi[/cite]Questa non è una decomposizione

Adesso ho capito cosa intendi per decomposizione, ma stai andando sempre di più verso un modello funzionale, nel senso comune di "modello formato su serie di funzioni conseguenti".
L'azione di "digitare il comando" è una task? intendo, secondo i tuoi termini, esistono task Out Of Game?
Oppure è uno strumento per risolvere una "task" che esiste solo In Game? se è uno strumento, qual'è il "quid" che mi identifica univocamente l'alpha e l'omega dell'unità di misura "task"? Cioè, in che modo sono in grado di identificare "task"? Solo perché è intrinsecamente atomica?

Rispondendo invece a questo

[cite]Postato da: rgrassi[/cite]Ma mi chiedo, esiste per voi qualcosa che vada al di la' del tavolo da gioco di gdr?

Se parliamo di teoria di GdR, no... ^^
Non sono ancora entrato nel merito dei parallelismi che proponi tra Libro-game e GdR o altre strutture di narrativa interattiva, ma io di base non riesco a identificarli come "la stessa cosa"; sono cose diverse che attingono da meccanismi simili, come la moto e la macchina (Libro-game e GdR) o come la moto e l'areoplano (entrambi hanno un motore che li fa muovere). Ma questo può essere un limite mio.
Considera che per me un GdR table top e un Live non sono "la stessa cosa".

[rgrassi]

Ciao,

[cite]Postato da: khana[/cite]Intendo, secondo i tuoi termini, esistono task Out Of Game?

Certo che si.
I task Out-Of-Game sono, in prima approssimazione, quello che accade (le unità di azione) nel mondo Out-Of-Game e che è visibile ad un ipotetico osservatore esterno (che quindi, te lo dico prima che tu possa fare obiezioni, è li' che guarda l'albero che cade e che registra il rumore che fa).
Anche questi task sono decomponibili 'a piacere' sino ad arrivare ad una granularità che il modello di riferimento ritenga interessante osservare per lo studio e l'analisi.

Oppure è uno strumento per risolvere una "task" che esiste solo In Game? se è uno strumento, qual'è il "quid" che mi identifica univocamente l'alpha e l'omega dell'unità di misura "task"? Cioè, in che modo sono in grado di identificare "task"? Solo perché è intrinsecamente atomica?

No, ho già detto che lo "scope" del task (cioè cosa è dentro e cosa è fuori e sino a che punto il gruppo tollera i contenuti ed i dettagli descrittivi di una azione) non è definibile apriori in forma astratta, ma che viene concordato al tavolo sulla base di molti parametri (come ad esempio, l'età, la cultura dei partecipanti, il tempo a disposizione, il 'buon senso', etc...)

Non sono ancora entrato nel merito dei parallelismi che proponi tra Libro-game e GdR o altre strutture di narrativa interattiva, ma io di base non riesco a identificarli come "la stessa cosa"; sono cose diverse che attingono da meccanismi simili, come la moto e la macchina (Libro-game e GdR) o come la moto e l'areoplano (entrambi hanno un motore che li fa muovere).

Credo che abbiano molte cose in comune, che sono declinate in ambiti diversi in modi (ovviamente diversi).

Considera che per me un GdR table top e un Live non sono "la stessa cosa".

Ci sono molte cose in comune, dal punto di vista dei giocatori, che vengono implementate in modi diversi.
E, dal mio punto di vista, la cosa che mi attira di piu' è cercare di capire come vengono risolti problemi 'simili' in modi diversi. In particolare, capire se il diverso dipende dal fatto che ci sono caratteristiche "inerenti" al tipo di gioco (e quindi non esportabili in altri contesti) o se invece possono essere riusati con successo in altri campi.
Rob

[Davide Losito - ( Khana )]

qui dovrebbe intervenire Moreno dopo che si è letto il tuo modello, ma a prima vista mi pare che allora i task(RGrassi), sia IG che OOG, siano Tecniche(BM), unite ad altri elementi di System(BM).

La definizione di task(RGrassi) che dai è interessante, ma paralellando con il BM hai unito un tot di concetti, come le famose Lines e Veils di altri post, quello che io ho chiamato "pertinenza" e in genere altri elementi che fanno parte di Color(BM) e di ulteriori elementi di System(BM).

[cite]Postato da: rgrassi[/cite]la cosa che mi attira di piu' è cercare di capire come vengono risolti problemi 'simili' in modi diversi

Ho capito l'intento, ma a questo punto ti conviene concentrarti su giochi o sistemi specifici piuttosto che sul BM, dato che il BM no dà nessun tipo di suggerimento per risolvere problemi di questo tipo... cioè, non parla neanche di questo tipo di problemi

[Moreno Roncucci]

Roberto, che senso ha che tu faccia domande ignorando la risposta che ti ho già dato? Ogni azione si può scomporre in altre azioni, se le chiami "task" (incorrettamente) ottieni che tutto è divisibile in task, se le chiami "conflitti" (incorrettamente) tutto è divisibile in conflitti, se le chiami "roberti" tutto è divisibile in Roberti.

Che senso ha, di fronte a questa risposta, una sfida a "trovarti un azione non scomponibile"? Stai leggendo questo thread o hai la lista delle domande già pronta dall'inizio?

P.S.: "task resolution" e "conflict resolution" non hanno alcun significato in "linguaggio comune" a cui puoi appigliarti, è il nome tecnico di due tecniche in linguaggio forgita, esattamente come "piano americano" è un termine tecnico del cinema, anche se usa parole comuni del vocabolario. Non puoi dare una tua definizione di "piano americano" come "schermata con cow-boys" e sostenere che stai usando il senso comune del termine contro i cinematografari sporchi e cattivi che vogliono monopolizzarlo...

[rgrassi]

Ciao,

[cite]Postato da: Moreno Roncucci[/cite]Ogni azione si può scomporre in altre azioni, se le chiami "task" (incorrettamente) ottieni che tutto è divisibile in task, se le chiami "conflitti" (incorrettamente) tutto è divisibile in conflitti, se le chiami "roberti" tutto è divisibile in Roberti.

?
Ti è chiaro che io sto dicendo che i task e i conflict NON sono la stessa cosa?
Che quindi non posso/voglio chiamare cose diverse con lo stesso nome?
Che ho detto quale è, a mio parere, la relazione tra di loro?
Che non sto parlando di 'task' e 'conflict' nel senso del BM?

Che senso ha, di fronte a questa risposta, una sfida a "trovarti un azione non scomponibile"? Stai leggendo questo thread o hai la lista delle domande già pronta dall'inizio?

??
Io il thread lo sto leggendo.
Forse tu non l'hai letto.
Perchè siamo andati ben oltre la tua (non) risposta.

P.S.: "task resolution" e "conflict resolution" non hanno alcun significato in "linguaggio comune" a cui puoi appigliarti, è il nome tecnico di due tecniche in linguaggio forgita

Non è che siano poi cosi' esoterici. Si traducono in "risoluzione di un task" e "risoluzione di un conflitto".
Mi sembrano anche piu' intuitivi del "piano americano" (che tra l'altro, esiste solo in italiano. Se chiedi agli americani cosa sia, ti dicono, eh?)

Ad ogni modo, riassumo per Moreno, che è ovvio che non possa leggersi tutti i post (chissà in quali altri polemiche su quanti altri forum è impegnato).
E' possibile dire che:
1) Un Conflict è un "Task Speciale" in cui viene dichiarata una interazione tra due oggetti (fisici o logici, non importa) e l'intenzione (ovvero l'esito desiderato) da quella interazione. IN altre parole: "TASK" + "Intenzione per cui viene dichiarato quel task" = Conflict
1b) Nel BM questo concetto viene esteso al fatto che ci sia conflitto di interessi tra quello che vogliono i giocatori.

2) Un Task costituisce la più piccola unità descrittiva di una azione (nel mondo In-Game). Un Task "semplice" NON descrive un esito desiderato. In altre parole: "Task = Task"

Se valgono 1 e 2, si deduce che:

3) Un Conflict è SEMPRE composto da almeno un Task.
4) La somma di Task NON sempre porta ad un conflict.

Rob
P.S. Mi sa che con Moreno la discussione si arena.

[Moreno Roncucci]

La discussione è un pezzo che si è arenata...

Comunque, la mia risposta a cui mi riferisco era la numero 16, la tua "sfida" era la numero 19, non hai nemmeno l'alibi del "non poterti leggere tutti i post nel mezzo", l'hai semplicemente ignorata (come metà delle risposte di questo thread, del resto...

Un altro dei problemi di questo thread è che usi termini tecnici forgiti (tali che, appena uno li sente, e non ti conosce, pensa subito che parli di Big Model) ma te li ridefinisci alla cazzo. Per una persona che aveva fatto persino un thread contro il "furore nominalistico" mi pare abbastanza paradossale: prima ti lamenti dei termini, e poi li usi pari pari per la tua teoria per fare confusione?

Riguardo al tuo "schemino":
La (1) nel big model è non corretta, non so nella tua teoria.
La (1b) nel Big Model è proprio una bestemmia. Dice esattamente il contrario.

La (2) non ha senso.

Quindi, quel "se valgono 1 e 2" ha una sola risposta: "no".

Sul perchè, ti ho già risposto nel post 16, e hai già ignorato la risposta.

[Mauro]

[cite]Postato da: rgrassi[/cite]"Alzo il braccio destro."

Caso in cui l'azione ha la stessa granularità del Conflitto (e quindi cade l'assioma "l'azione ha granularità inferiore al Conflitto"): metto come Posta alzare il braccio destro.
Azione scomposta in Conflitti: metto come posta il non avere un cedimento del muscolo (nota: se perdo e mi cede il muscolo posso sempre resistere al dolore e riuscire ad alzare il braccio, ma sarebbe un'altra cosa da controllare).

Il punto è che se io metto come Conflitto "Riesco ad alzare il braccio destro?" e tu lo scomponi in azione (cosa necessariamente fattibile, per il tuo assunto), semplicemente io metterò come Conflitto le azioni, e avanti cosí. Posto che io posso sempre mettere come Conflitto un'azione (basta porre il risultato dell'azione come intento), dire che un Conflitto è scomponibile in azioni automaticamente implica che un'azione è scomponibile in Conflitti (secondo lo schema azione = Conflitto => azioni = Conflitti, da cui azione => Conflitti, dove "A = B" indica porre A come B - azione come Conflitto, per esempio - e "A => B" indica che A viene scomposto in B).

[cite]Postato da: rgrassi[/cite]D'altra parte trovo anomalo che si definisca un "Task Resolution" senza capire cosa sia un Task

Se vuoi una definizione pratica (mi corregga se sbaglio chi sa piú di me di teoria), l'azione è ciò che il personaggio cerca di fare, l'intento ciò che cerca di ottenere: combatto (azione) per farmi notare dalla principessa (intento). Se la risoluzione dice se riesco nell'azione è ad Azione, se dice se riesco a ottenere l'intento è a Conflitto.
Il problema è che cosa cerca di fare il personaggio non ha un limite minimo: combatte una guerra? restringendo il campo, un gruppo di avversari? un avversario? cerca di colpirlo? solleva la spada? E cosí via. Ma tutti quelli sono anche intenti: il suo intento è colpire l'avversario? è sollevare la spada?

[cite]Postato da: rgrassi[/cite]1) Un Conflict è un "Task Speciale" in cui viene dichiarata una interazione tra due oggetti (fisici o logici, non importa) e l'intenzione (ovvero l'esito desiderato) da quella interazione. IN altre parole: "TASK" + "Intenzione per cui viene dichiarato quel task" = Conflict
[...]
3) Un Conflict è SEMPRE composto da almeno un Task

Quindi si ricade nell'ipotesi che ho fatto che sia tutto una questione di definizione: se semplicemente si costruisce una definizione in modo tale da avere che l'azione sia sempre piú piccola del Conflitto, qual è il punto della discussione? Chiedo senza intento critico, veramente mi sfugge, mi pare che la domanda sia "Se io definisco 'Azione' e 'Conflitto' in modo che un Conflitto sia sempre formato da azioni, un Conflitto è sempre formato da azioni?". Mi pare a dir poco tautologico...
Inoltre, se poniamo Azione + intento = Conflitto, mi pare andare da sé che l'azione non sia piú piccola del Conflitto: azione: "Alzo un braccio"; Conflitto: "Alzo un bracco per grattarmi". Il Conflitto ha la stessa granulosità dell'azione.

[rgrassi]

Ciao,

Il punto è che se io metto come Conflitto "Riesco ad alzare il braccio destro?" e tu lo scomponi in azione (cosa necessariamente fattibile, per il tuo assunto), semplicemente io metterò come Conflitto le azioni,

Per cui, per te:
"Alzo il braccio destro." PER COME E' SCRITTA è (può essere) sia un Conflitto che un Task?
Attenzione, non sto parlando del fatto che ci appiccichiamo cose PRIMA o DOPO.
Sto parlando della 'nuda affermazione'.
"Alzo il braccio destro." Puo' essere SIA un Task che un Conflict?

Posto che io posso sempre mettere come Conflitto un'azione (basta porre il risultato dell'azione come intento),

Si ma per farlo devi MODIFICARE quello che dici.

Quindi si ricade nell'ipotesi che ho fatto che sia tutto una questione di definizione: se semplicemente si costruisce una definizione in modo tale da avere che l'azione sia sempre piú piccola del Conflitto, qual è il punto della discussione?

Mauro, scusami. Non sto costruendo una definizione 'fittizia' per cui chiamo "pippo" una cosa perche' a me piace cosi'.
Per far si che ci sia un "conflitto" (e non parliamo di BM)...
"Conflict is actual or perceived opposition of needs, values and interests."
http://en.wikipedia.org/wiki/Conflict
Un "task"
http://en.wikipedia.org/wiki/Task
"In common language, a task is part of a set of actions which accomplish a job, problem or assignment."

Conflict ha il senso di "opposition" (di qualcosa o qualcuno). Nel caso dei gdr di qualcuno.
Task ha il senso di "set of actions". Se non c'è nessuno o nulla che si oppone io completo i miei task...
NON SONO 'la stessa cosa'.

Cmq, mi rendo conto che la situazione si sta accavallando... (Magnotta docet)
Penso che non ne veniamo fuori via forum. Forse una discussione 'de visu' risolverebbe le incomprensioni.
Rob

[Niccolò]

bob, è semplice: da una parte hai uno "svolgimento"

questo svolgimento può essere suddiviso infinitamente in sotto azioni.

QUANDO GIOCHI, puoi suddividere questo svolgimento in sottoazioni, e risolverle come task, oppure come conflitto. l'effetto è nettamente diverso. MA LO SVOLGIMENTO E LE SOTTO AZIONI, di per se, non sono task o conflitti. sono eventi. l'uso di task e conflitti è il modo in cui metti a contatto gli infiniti svolgimenti possibili con il sis. la relazione VERA è tra l'EVENTO e i SOTTOEVENTI, non tra il CONFLITTO e i (suoi presunti) task.

sono stato spiegato decentemente?

[rgrassi]

sono stato spiegato decentemente?

Direi di no... Mi stai spiegando quello che il BM dice.
Ti è chiaro che se volessi parlare di "avventure testuali" e "gdr" o "librogame" e "gdr" quello che stai dicendo ci azzecca sino ad un certo punto?
O, allargando il discorso, ti è chiaro che con l'autoreferenza non si va lontano?
Rob

[Moreno Roncucci]

A parte l'uso del termine "sis", nulla di quello che ha detto è specifico del Big Model. E' semplicemente come funzionano i gdr.

[rgrassi]

Strano, non ho visto subito questo post di Moreno...

[cite]Postato da: Moreno Roncucci[/cite]Un altro dei problemi di questo thread è che usi termini tecnici forgiti (tali che, appena uno li sente, e non ti conosce, pensa subito che parli di Big Model) ma te li ridefinisci alla cazzo.

Vero, ho questo peccato originale.
Deriva dall'ingenuità di pensare che una persona applichi prima il vocabolario "ordinario" e poi "quello tecnico".
D'altra parte qui non siamo su "The Forge". O lo mettiamo come 'disclaimer'? (Se volete postare in questo forum, prima imparatevi il glossario.)

Per una persona che aveva fatto persino un thread contro il "furore nominalistico" mi pare abbastanza paradossale: prima ti lamenti dei termini, e poi li usi pari pari per la tua teoria per fare confusione?

Mi lamento dei termini quando se ne inventano di nuovi per dire cose che potresti dire con termini già esistenti.
Cmq, passiamo oltre.

La (1) nel big model è non corretta, non so nella tua teoria.

Nel senso che nel BM non ha senso suddividere gli eventi in "task" e "conflict"?

La (1b) nel Big Model è proprio una bestemmia. Dice esattamente il contrario.

"A Technique in which the mechanisms of play focus on conflicts of interest, rather than on the component tasks within that conflict. When using this Technique, inanimate objects are conceived to have "interests" at odds with the character, if necessary."

Cosa dico io? "Un task di cui dichiaro l'intento e qualcuno o qualcosa si oppone (perchè ha interessi contrapposti).".
Non mi sembra "esattamente il contrario", ma la foga dialettica si fa sentire.
Cmq, molliamo l'ancora.
Rob

[Mauro]

[cite]Postato da: rgrassi[/cite]Deriva dall'ingenuità di pensare che una persona applichi prima il vocabolario "ordinario" e poi "quello tecnico".
D'altra parte qui non siamo su "The Forge". O lo mettiamo come 'disclaimer'? (Se volete postare in questo forum, prima imparatevi il glossario.)

Penso che sia piuttosto questione che, utilizzando da diverso tempo quei termini con quell'accezione, e usando quell'accezione la maggior parte degli utenti, soprattutto nella sezione dedicata alla teoria viene naturale leggerli in tal senso.

"A Technique in which the mechanisms of play focus on conflicts of interest, rather than on the component tasks within that conflict. When using this Technique, inanimate objects are conceived to have "interests" at odds with the character, if necessary."

Cosa dico io? "Un task di cui dichiaro l'intento e qualcuno o qualcosa si oppone (perchè ha interessi contrapposti)."

Moreno si è riferito all'"(1b)", quindi immagino parlasse di questo: "Nel BM questo concetto viene esteso al fatto che ci sia conflitto di interessi tra quello che vogliono i giocatori".

A parte questo, non hai un mente qualche uso specifico per la distinzione che vuoi fare? Forse aiutarebbe a capire cosa intendi.

[Moreno Roncucci]

Roberto,  mi vuoi cortesemente spiegare in quale ambito, a parte i gdr, esiste un qualcosa definito comunemente "task resolution"?

Visto che continui a usare termini di una teoria stravolgendone il senso, motivando la cosa con il fatto che li usi "nell'uso comune", dovresti cortesemente spiegare dove sarebbe tanto comune questo uso...

[Moreno Roncucci]

P.S., riguardo al fatto di doversi imparare i termini forgiti per poter parlare di teoria...

Attualmente, il Big Model non è una teoria fra tante, magari propugnata da pochi fanatici (come si illudono gli ultimi soldati giapponesi nascosti in qualche forum italiano...). E' di gran lunga la teoria piu' autorevole e utilizzata (oltre ad essere in pratica l'unica realmente diffusa).

Un "appassionato di teoria dei gdr" che non ne conosca il linguaggio è come un "appassionato di matematica" che non conosca i simboli delle operazioni più comuni, o della radice quadrata.

E' obbligatorio impararla per parlare di gdr? No, però in quel caso metti un disclaimer prima e poi non usi quel linguaggio tecnico. Cerchi di spiegarti in termini di actual play (cosa comunque sempre consigliabile) in maniera che si capisca di che parli, e anche chi ti risponde cercherà di non usare termini tecnici.

Ma utilizzare termini del Big Model e poi fare la vittima lamentandosi con cose tipo "cos'è diventato obbligatorio sapere il significato delle parole?".  Sì. Se le usi, sì, devi saperne il significato.  Altrimenti, se ti inventi un significato tuo personale senza sapere quello originale, finisci per parlarti da solo.