Gentechegioca
Gente Che Gioca => Sotto il cofano => Topic aperto da: rgrassi - 2009-03-31 16:06:57
-
Come suggerisce Moreno, scrivo in "Sotto il cofano".
Non so se conoscete le avventure testuali. Se non le conoscete, scrivetemi, ve ne parlerò. Se le conoscete procedete pure.
Sono certamente modellizzabili e "simili" in alcune cose al gdr.
Esse sono senza ombra di dubbio 'task based', con authority = 0 da parte del giocatore.
Uno degli argomenti ricorrenti sulle AT è. Sino a quanto deve spingersi la granularità dei "task" da chiedere al giocatore?
In altre parole (con una evidente esagerazione), se uno scrive sul parser:
> WIN
Vince il gioco e finisce tutto in un solo colpo?
Nell'ambito del mio modello 'unico' per i roleplaying sto ragionando su come questo aspetto possa essere declinato nei gdr, ed in particolare in quelli conflict-oriented.
In altre parole, sempre per esagerare, cosa accadrebbe se la posta fosse subito quella "massima" e la partita finisse in un turno?
Immagino che questo sia "impedito" in due modi.
A) Fisicamente non possibile, perchè il giocatore non ha mai modo di poter vincere un conflitto con una posta cosi' alta.
B) Logicamente non possibile, nel senso che gli altri giocatori rifiutano una posta così alta...
Potete illuminarmi?
Rob
-
1) In non tutti i gdr puoi fissare la posta.
2) fra quelli dove puoi fissare la posta, in non tutti (anzi, in pochissimi) puoi fissarla da solo senza concordarla con qualcun altro.
3) in quelli dove puoi fissarla da solo, in pochi non ci sono limiti di scala alla posta (il più comune è "qui e adesso" )
4) in molti gdr esiste un ulteriore veto formale a giocate di questo tipo.
5) anche dove non c'è il veto formale, esiste l'informale "bullshit rule" che in italiano si potrebbe tradurre come "dai, non dire cazzate e gioca".
-
Quindi, mi sembra di capire che ci avevo azzeccato.
E se dovessimo provare a formularla, esisterebbe una posta 'unica' per giochi come LmvcP o CnV?
Giusto 'pour parler'.
Rob
-
Più in dettaglio sui giochi tradotti:
Spione: non c'è posta.
La Mia Vita col Padrone: le poste sono prefissate in categorie generiche.
Cani nella Vigna: la posta va concordata, e c'è un veto formale.
Avventure in prima serata: la posta riguarda il "qui e ora", va concordata, e comunque qualunque posta non potrebbe mai concludere la serie.
Non cedere al sonno: è un po' che non lo rileggo e potrei sbagliarmi, ma mi sembra che la posta sia legata al "qui e ora"
-
Forse mi sono spiegato male.
Sto parlando di un 'estremo teorico'.
Non esistono giochi di avventure testuali in cui scrivi:
> RISOLVI TUTTI GLI ENIGMI E VINCI
(anche se ogni tanto qualcuno che si diletta a fare questi 'abuse' si trova sempre)
Ma SE PROPRIO VOLESSIMO sarebbe possibile individuare una posta 'unica' che farebbe terminare il gioco se il giocatore la vincesse?
Non so, qualcosa del tipo:
> Convinco il giovane Zacharia ad uccidere il suo demone interiore, e vado via dalla città così come ci ero arrivato?
Rob
-
Non puoi parlare genericamente di cosa fanno i gdr forgiti usando il concetto di "posta", perchè è semplicemente una tecnica fra tante altre, la maggior parte dei giochi non la usa. Sarebbe come trarre una classificazione delle automobili in base al tipo di ABS...
[edit: sei troppo veloce a rispondere, io sto rispondendo da inizio thread al tuo messaggio precedente all'ultimo...]
-
Moreno, non voglio parlare dei gdr forgiti. Voglio cercare di capire sino a che punto ci siano una serie di argomenti 'comuni' tra due generi di gioco che appaiono differenti, ma che, a mio modo di vedere, affrontano gli stessi "problemi" di design.
[edit: aspetto a scrivere, ma spero che sia chiaro quello che intendo altrimenti continuiamo a rincorrerci]
Rob
-
Non ho capito quale sarebbe il "secondo genere di gioco" oltre alle avventure testuali... tutti i gdr? Come si fa a definire caratteristiche comuni in un insieme non definito? Nessuno ha mai dato una definizione soddisfacente di gdr, o che non dovesse venire corretta ultimamente ogni sei mesi...
-
Ciao,
[cite]Postato da: Moreno Roncucci[/cite][p]Non ho capito quale sarebbe il "secondo genere di gioco" oltre alle avventure testuali... tutti i gdr?
Allora, cerco di ripartire da zero.
Cosa hanno in comune (la maggior parte delle) AT e (la maggior parte dei) GDR?
Che sono 'turn based'. In altre parole, esiste un "turn" in cui il giocatore puo' dichiarare la propria intenzione. Sto analizzando questo sottoinsieme, fittiziamente definito.
Questa "intenzione" (lasciami passare questa semplificazione) può avere una granularità bassa (un task) o più ampia (un conflict). Le AT, per ovvi motivi di limitazione tecnologica, consentono solo i "task" (anche se un approccio conflict sebbene limitato sia implementabile). I GDR possono usare 'entrambi'.
Nel campo delle AT, si discute quale debba essere la natura di questo 'task'. In altre parole, è ovvio che non puoi dire "Trovo il tesoro" e vinci.
Nel campo dei GDR, non puoi dire (un esempio sui task):
"Entro nel dungeon, uccido il mostro, prendo il tesoro ed esco" e giocartela in un solo colpo.
Andando sul conflict, mi chiedevo se sia possibile definire, almeno dal punto di vista 'teorico' un unico conflitto *teorico* su cui si basa il gioco (probabilmente sarebbe un conflitto da costruire sul tema), e ovviamente diverso da gioco a gioco.
Rob
-
Attenzione, la tua differenziazione fra "task" e "conflict" non è esatta. Non ha nulla a che vedere con la "scala"
Esempi: task: "distruggere l'intero pianeta Terra con un cucchiaino da caffè e tanta, tanta pazienza", o, se preferisci, "voglio fare un tiro di intelligenza per capire subito chi è l'assassino appena lo vedo"
Conflict: "voglio riuscire a muovere il pollice prima di lui", o, se preferisci "lui ha nascosto l'arma del delitto? Io voglio vedere se riesco comunque a scoprirla"
Un task è "faccio questa cosa", un conflict è "vinco questo conflitto", senza dire nulla su quale dei due sia il più lungo, largo, lento o cosa sia contenuto dentro l'altro.
Tolto di mezzo questo equivoco, passiamo al tema del thread.
Il caso più generico e generale che riesco ad immaginare, cercando di astrarre dai meccanismi dei singoli gdr: visto che i gdr almeno per adesso sono tutti basati sulla comunicazione (testuale, corporea, scritta, tc.) il caso più generico è qualcuno che comunichi agli altri giocatori, "x", con "x" variabile da gioco a gioco e indefinibile a priori ma che è l'equivalente concettuale del dire "voglio fare un solo tiro e scoprire l'assasino" o "siete tutti morti, ho vinto". In ogni caso, qualcosa che concluda il gioco in anticipo lasciando insoddisfatti tutti gli altri giocatori.
Se non inseriamo limitazioni di sorta al gioco, la prima cosa che noto è che questo non è assolutamente vietato da tutti i regolamenti: in tutti i gdr con la "regola zero" il GM può dire questo, da regolamento, e nessuno può contestarlo.
Essendo il gdr un attività sociale, si vede però che l'unica limitazione generale e generica è appunto di tipo sociale: "ma va a cagare, con te non ci gioco più".
Per qualcosa di più specifico (e magari basata sul sistema di gioco e non sul livello sociale) bisogna iniziare a fare dei distinguo sui singoli giochi.
Riguardo alla tua domanda nell'ultimo paragrafo: non solo è possibile spesso (non sempre) definire un conflitto "teorico" su cui si basa un gioco (anche se "conflitto" non è sempre esatto, se non parli di giochi gamisti), ma alcuni giochi lo fanno come parte della preparazione (Trollbabe per esempio identifica in partenza una situazione che può avere come minimo due outcomes differenti. I PG possono intervenire in favore di un outcome o di un altro o ignorare la situazione, a loro totale piacimento - per questo non si può parlare genericamente di "conflitto" se non hai una situazione in un gdr gamista dove "lo scopo del gioco è vincere contro x" - ma una volta che uno degli outcomes si è realizzato l'avventura è finita)
Altro esempio, forse migliore:. The Mountain Witch: ogni singola partita è la storia della sfida contro the mountain witch, ma è un backdrop, non lo scopo del gioco (tanto che lo stregone non ha nemmeno stats)
Esempio di gioco che non ha un conflitto identificabile: Avventure in Prima serata. Ogni giocatore / personaggio ha un issue da risolvere in qualche maniera, non il gruppo intero.
Noto comunque una bruttissima piega che hanno preso le discussioni di teoria nel forum da un po' di tempo: ci stiamo allontanando a gambe levate, di corsa, da qualunque actual play, per discutere sempre più spesso del numero di angeli che può danzare sulla capocchia di uno spillo. E' un film già visto, era successo su the forge nel 2005, rendendo completamente inutili le sottosezioni dedicate alla teoria, e forzando l'introduzione di un regolamento molto restrittivo che impone di fare esempi di actual play in ogni singolo thread di teoria. Noi siamo ancora ben lontani da questo livello di fumosità, per fortuna, ma comunque c'è già nel regolamento del forum la richiesta di cercare di fare possibilmente esempi di actual play.
-
[cite]Postato da: Moreno Roncucci[/cite]1) In non tutti i gdr puoi fissare la posta.
2) fra quelli dove puoi fissare la posta, in non tutti (anzi, in pochissimi) puoi fissarla da solo senza concordarla con qualcun altro.
3) in quelli dove puoi fissarla da solo, in pochi non ci sono limiti di scala alla posta (il più comune è "qui e adesso" )
A questo aggiungerei anche che in un sistema a Poste libere, ai giocatori NON CONVIENE stabilire Poste troppo piccole o troppo grandi.
Nel primo caso, "vincono" o "perdono" troppo poco.
Nel secondo, rischiano tutto in un colpo solo.
Prova a pensare in AiPS o CnV (oh, lo so, parlo sempre di questi due giochi, portate pazienza, son quelli che conosco meglio!).
AiPS: se vinci una Posta enorme, ok... Ma se la perdi? Davvero vuoi rischiare TUTTO in un solo giro di carte, giocatore?
CnV: benissimo, giocatore, fammi una Posta enorme. Non la cederai MAI, ora ti faccio passare un rilancino bastardo tipo "e tua madre muore". Ma che peccato, non hai da Parare e non puoi mollare perchè ti sei fregato da solo alzando una Posta immensa. ]:)
-
Vado leggermente OT, perchè questa discussione mi interessa molto... Moreno, bloccami se stiamo entrando in una spirale di distruzione.
[cite]Postato da: Moreno Roncucci[/cite][p]Attenzione, la tua differenziazione fra "task" e "conflict" non è esatta. Non ha nulla a che vedere con la "scala"[/p][p]Esempi: task: "distruggere l'intero pianeta Terra con un cucchiaino da caffè e tanta, tanta pazienza", o, se preferisci, "voglio fare un tiro di intelligenza per capire subito chi è l'assassino appena lo vedo"
Conflict: "voglio riuscire a muovere il pollice prima di lui", o, se preferisci "lui ha nascosto l'arma del delitto? Io voglio vedere se riesco comunque a scoprirla"[/p][p]Un task è "faccio questa cosa", un conflict è "vinco questo conflitto", senza dire nulla su quale dei due sia il più lungo, largo, lento o cosa sia contenuto dentro l'altro.
Io invece (sbagliando?) penso che un conflict sia SEMPRE decomponibile in task più granulari che lo compongono e che possono concorrere alla sua descrizione. (Attenzione, non sto dicendo che questa sia una cosa 'utile' ai fini del game design, ma utile solo ai fini di una analisi 'microscopica' di un GDR)
In questo senso, un conflict può essere visto come una "serie di task" (dove per serie intendo proprio una sequenza temporale). Uno di questi task, in particolare, è quello che obbliga il giocatore/personaggio a dover interagire con (i desideri o le volontà di) un altro giocatore/personaggio.
In altre parole, penso che il task sia una "unità d'azione".
Hai voglia di ragionare su questo?
Dopo aver chiuso questa parentesi torno sugli altri tuoi (interessanti) commenti.
Rob
-
[cite]Postato da: rgrassi[/cite]Io invece (sbagliando?) penso che un conflict sia SEMPRE decomponibile in task più granulari che lo compongono e che possono concorrere alla sua descrizione. (Attenzione, non sto dicendo che questa sia una cosa 'utile' ai fini del game design, ma utile solo ai fini di una analisi 'microscopica' di un GDR)
In questo senso, un conflict può essere visto come una "serie di task"
Dipende da cosa intendi con task: nel manuale di Cani nella Vigna c'è l'esempio di un Conflitto, che nella storia dura un istante, per chi in un duello estrarrà e sparerà per primo; si gioca sui timori, sul sole che acceca, sulla tensione, sul ricordo di chi ti ha insegnato a sparare, ma è tutto in quell'istante prima che l'orologio scatti sul Mezzogiorno. Sicuramente lo si può suddividere in porta la mano alla pistola, prendi la pistola, estraila, puntala, tira indietro il cane, premi il grilletto; ma ha senso?
Su Risoluzione a Conflitti e Risoluzione ad azioni, ti consiglio questa (http://www.lumpley.com/hardcore.html) pagina (cerca Conflict Resolution vs. Task Resolution per il pezzo in questione).
-
Ho già detto che potrebbe non aver senso per la "risoluzione" ma ai fini "dello studio" si (e se non la vedi in questo modo è difficile che si possano fare passi avanti.)
Per 'task' non intendo qualcosa di diverso da quello che immagini tu, e naturalmente so bene che il task si puo' decomporre in infiniti sotto-task.
Mi aveva colpito il post di Moreno per cui 'task' e 'conflict' non sono (e non potrebbero) essere in relazione tra di loro.
Mentre invece tu mi dici di si (se ho capito bene il tuo post).
Il mio dubbio è, dunque:
Task e conflict hanno SEMPRE una relazione che li lega?
Questa relazione è SEMPRE identificabile (indipendentemente dalla granularità sia del task che del conflict?) (ad esempio questa relazione potrebbe essere che il conflict è SEMPRE costituito da task)
Rob
-
[cite]Postato da: rgrassi[/cite]Io invece (sbagliando?) penso che un conflict sia SEMPRE decomponibile in task più granulari che lo compongono e che possono concorrere alla sua descrizione. (Attenzione, non sto dicendo che questa sia una cosa 'utile' ai fini del game design, ma utile solo ai fini di una analisi 'microscopica' di un GDR)
non "sbagliando" ma dimenticando che
1) un conflitto può essere suddiviso ANCHE in una serie di conflitti più granulari
2) ANCHE un task è sempre decomponibile in una serie di task più granulari
3) non ultimo: teoricamente un task può essere decomponibile in una serie di conflitti più granulari.
per cui continua a non essere necessariamente vero Conflitto > Task
-
E' il paradosso di Achille e della tartaruga. Ogni azione si può scomporre in più azioni più piccole. Basta chiamare "task" queste azioni, anche se non avresti mai utilizzato task resolution per vedere se il tuo personaggio riusciva a cammnare per 10 cm per esempio, ed ecco che all'apparenza ogni conflitto è diviso in task. Se li chiamavi "conflitti", con la stessa "dimostrazione", ogni task era diviso in conflitti.
-
A livello temporale-funzionale per un eventuale mondo virtuale in cui i personaggi esistono fisicamente, qualsiasi "tiro" è una concatenazione di "tasks" in senso letterale. Anche l'antico dado percentuale per scalare le pareti di D&D era 1 solo tiro che simulava una "serie di azioni".
La differenza è:
task -> giocatore "scalo la parete e scappo", roll d%, confronta tabella/livello di difficoltà, result[yes|no]. Descrizione della scena. SI METTE IN DISCUSSIONE CHE LA PARETE VENGA SCALATA.
conflict -> giocatore "scalo la parete e scappo", narratore "non fai in tempo ad arrivare alla cima prima che la balestra del mago Bargle (ghghghghg) ti colpisca sulla 4a vertebra lombare", roll[quello che il sistema chiede], risoluzione meccanica sulla base della quale passa una o l'altra versione. Descrizione della scena. SI METTE IN DUBBIO LA SALVEZZA DEL PG, senza dubitare né del fatto che la parete venga scalata, né che il mago Bargle possa e riesca a sparare.
Altro esempio in scala più grande:
task -> giocatore "programmo il satellite militare per puntare un paio di testate tattiche su Mosca", roll wits+technologies a difficoltà 8, conto i successi, result[yes|no]. Descrizione della scena. SI METTE IN DISCUSSIONE CHE IL PG RIESCA A PROGRAMMARE IL SATELLITE.
conflict -> giocatore "programmo il satellite militare per puntare un paio di testate tattiche su Mosca", narratore "ci riesci, ma il firewall crittografico neurale ti manda addosso svariati bot di ricerca non appena apri il socket", roll[quello che è], risoluzione meccanica del confilitto. Descrizione. QUI NON SI METTE IN DISCUSSIONE NULLA, si tira per vedere se il personaggio viene intercettato o meno senza dubitare della sua capacità di riprogrammare un satellite militare... d'altronde è un Virtual Adept che ha partecipato 20 anni fa ai progetti della Iteration-x e del NWO per il controllo planetario dei sistemi informativi, sarebbe anche stupido che non sappia farlo.
-
Tanto per non perdersi: la granularita' non ha NIENTE a che fare con la differenza tra Task e Conflict.
L'unica discriminante e' la "esplicitazione dell'intento" (e di conseguenza il suo ottenimento a seguito del conflitto).
La Task Resolution funziona anche se non viene mai esplicitato l'intento.
La Conflict Resolution senza esplicitazione dell'intento non e' possibile.
Tutto il resto e' opzionale (granularita', risoluzione di scena, poste, contro poste, "denti", whatever). L'unico sistema che conosco troppo poco e mi lascia un dubbio di classificazione e' Spione, ma non sono sicuro che usi una CR vera e propria, ma piuttosto un "qualcosa" di originale e nuovo. Moreno?
(devo recuperare lo schemino fatto da Fred tempo fa su story games che tentava di chiarire i dubbi su TR vs CR)
-
Io non sono convinto che il task non sia sempre di una granularità inferiore del conflict.
Mi fate un esempio di conflict con granularità inferiore ad un task?
E, naturalmente, per funzionare, dovete dimostrarmi che è un conflict "non decomponibile" in altri task.
Sulla differenza sostanziale della esplicitazione dell'intento sono ovviamente d'accordo.
Rob
-
@Rob: il problema non e' la scala. Il problema e' che e' del tutto irrilevante ed ortogonale. A che serve?
-
Renato, tu dici che la granularità NON ha a che fare con la differenza tra task e conflict.
Io dico di sì. C'è un modo per capire chi è nel giusto?
Quanto al servire, ripeto, che molte persone vedono scopi diversi rispetto alle cose che studiano.
Capire cosa sia meglio a livello di design "in assoluto" o "relativamente a qualcosa" è solo uno dei modi di approcciare.
Nel mio caso, sto cercando di capire quanto abbiano in comune due generi di giochi 'differenti', ma con aspetti comuni, per certi versi, e descrivibili da un modello comune.
Serve, nel mio caso, per capire questo.
Ad esempio, potrebbe servire, nel mondo delle avventure testuali, per capire se è implementabile il concetto di conflict in maniera relativamente indolore, oppure nel mondo dei gdr, se migliorare la task resolution sulla base della esperienza proveniente da un altro genere di giochi.
Rob
-
[cite]Postato da: rgrassi[/cite]Renato, tu dici che la granularità NON ha a che fare con la differenza tra task e conflict.
Io dico di sì. C'è un modo per capire chi è nel giusto?
Se un Conflitto è sempre scomponibile in azioni e un'azione è sempre scomponibile in Conflitto, direi che si entra in un circolo. Inoltre, ogni azione che si possa pensare può essere giocata come Conflitto, basta mettere il risultato dell'azione come intento; azione: colpisco (tiro per colpire); Conflitto: voglio colpire (Conflitto per colpire). In Fino alla Fine del Mondo il manuale stesso riporta un esempio in cui un singolo colpo di spada è trattato come Conflitto.
Prendendo un altro esempio (cito dal sito di Baker, pagina già indicata): Whether you roll for each flash of the blade or only for the whole fight is a whole nother issue: scale, not task vs. conflict. This is sometimes confusing for people; you say "conflict resolution" and they think you mean "resolve the whole scene with one roll." No, actually you can conflict-resolve a single blow, or task-resolve the whole fight in one roll:
"I slash at his face, like ha!" "Why?" "To force him off-balance!"
Conflict Resolution: do you force him off-balance?
Roll: Loss!
"He ducks side to side, like fwip fwip! He keeps his feet and grins."
"I fight him!" "Why?" "To get past him to the ship before it sails!"
Task Resolution: do you win the fight (that is, do you fight him successfully)?
Roll: Success!
"You beat him! You disarm him and kick his butt!"
(Unresolved, left up to the GM: do you get to the ship before it sails?)
(Those examples show small-scale conflict resolution vs. large-scale task resolution.)
-
Ciao,
[cite]Postato da: Mauro[/cite]Se un Conflitto è sempre scomponibile in azioni e un'azione è sempre scomponibile in Conflitto, direi che si entra in un circolo.
Non so se sia chiaro che io NON sono convinto del fatto che una azione sia SEMPRE scomponibile in conflitto.
Oppure è un dogma cui devo credere "per fede"?
Inoltre, ogni azione che si possa pensare può essere giocata come Conflitto, basta mettere il risultato dell'azione come intento; azione: colpisco (tiro per colpire); Conflitto: voglio colpire (Conflitto per colpire). InFino alla Fine del Mondoil manuale stesso riporta un esempio in cui un singolo colpo di spada è trattato come Conflitto.
Mi è chiaro quello che dici dopo... :)
Ma non è quello di cui sto 'discutendo'.
Rob
-
[cite]Postato da: rgrassi[/cite]Mi fate un esempio di conflict con granularità inferiore ad un task?
G1. Lo fisso intensamente negli occhi e con questo sguardo deve capire che contro di me non ha speranze.
G2. Fingo imbarazzo e sottomissione per fargli credere di non avere speranze.
L'azione, in scena, è un solo sguardo incrociato.
Il tiro, nel sistema, è un solo conflitto.
G1 tira per "deve capire che contro di me non ha speranze".
G2 tira per "fargli credere di non avere speranze".
Il fatto che uno sguardo incrociato esista non viene messo in discussione da nessuno, se ne mette in discussione l'esito, perché i giocatori tirano sull'intento di quell'azione e non sulla possibilità della sua fattibilità fisica.
-
Te ne aggiungo un altro... con un'aggiunta di spiegazione che è tecnica, ma dal punto di vista della sceneggiatura e -non- di modelli di GdR.
Risulta Conflict a granularità "uno" anche un:
G1. Muovo i miei contatti per attivare un conflitto nucleare su scala planetaria.
G2. Muovo i miei contatti per riuscire a capire chi sta cercando di far partire un conflitto nucleare.
Il fatto che tu, Roberto Grassi, -IMMAGINI- che all'interno di queste 2 dichiarazioni avvengano degli eventi "task" granulari è una tua personale scelta, perché la sceneggiatura della storia -non li prevede-.
Un GdR non è una simulazione di "vita", ma una forma di letteratura interattiva non lineare che sfiora l'interpretazione e l'improvvisazione teatrale.
I tagli narrativi sono validi.
I flashback sono validi.
I monologhi interiori sono validi.
Il sistema non deve simulare la "vita vera" con qualche strano meccanismo di riduzionismo matematico interfacciato da dadi/carte/interiora di vitello, ma deve consentire ai giocatori di narrare storie interessanti.
Nessuno si è mai chiesto "quali strane peripezie hanno fatto Luke, Lehila e Han Solo per uscire dalla discarica dei rifiuti dopo che il meccanismo della pressa è stato bloccato?" perché questo "dopo" non interessa a nessuno. La parte interessante è il come si salvano, quale sia la transizione granulare che li porta dal festeggiamento per averla scampata, alla scena successiva in cui entrano nella sala di controllo (e sono pure puliti :D), non è narrativamente importante.
-
Io continuo a NON essere convinto che ciò che stai dicendo NON sia scomponibile in task (e sappiamo bene entrambi che è così). E so bene che la scena che proponi può essere risolta in mille modi diversi (ad esempio, anche in Levity la risolverei con UN solo tiro).
Inoltre, mi continui a fare un esempio al tavolo di "ciò che davvero interessa". NON E' quello di cui sto parlando. Sto facendo una domanda *teorica* avulsa da "ciò che interessa" o "ciò che serve".
L'esempio che porti può essere decomposto in un sacco di task con 100% di probabilità di riuscita (ed è questo il motivo per cui nessuno si oppone) sino ad identificare un "task speciale" che mette in relazione il mio personaggio con l'oggetto della interazione (e la controparte del conflitto).
Rob
-
Ciao,
[cite]Postato da: khana[/cite][p]Te ne aggiungo un altro... con un'aggiunta di spiegazione che è tecnica, ma dal punto di vista della sceneggiatura e -non- di modelli di GdR.
Khana, guarda che non devi insegnarmi queste cose, perchè ne uso a piene mani quando gioco... :D
Il fatto che tu, Roberto Grassi, -IMMAGINI- che all'interno di queste 2 dichiarazioni avvengano degli eventi "task" granulari è una tua personale scelta, perché la sceneggiatura della storia -non li prevede-.
Un GdR non è una simulazione di "vita", ma una forma di letteratura interattiva non lineare che sfiora l'interpretazione e l'improvvisazione teatrale.
Assolutamente, ma devi anche capire che NON TUTTI giocano allo stesso modo o 'immaginano' allo stesso modo o "pensano" allo stesso modo. Quello di cui tu mi parli sono tecniche di narrazione. Non c'entra NULLA con quello di cui sto parlando.
Nessuno si è mai chiesto "quali strane peripezie hanno fatto Luke, Lehila e Han Solo per uscire dalla discarica dei rifiutidopo che il meccanismo della pressa è stato bloccato?" perché questo "dopo" non interessa a nessuno.
Ripeto... :)
NON E' questo quello di cui sto parlando.
Non di "ciò che rende bella una storia", "ciò che serve", "ciò che funziona."
Ho chiesto un esempio di conflict che NON si possa decomporre in task ma non ne ho visti, ancora. :D
Rob
-
@Rob: il ragionamento e' circolare. Si puo' o non si puo' scomporre? Che cambia? A che ti serve saperlo?
Facciamo cosi': si puo'. Quindi?
In ogni caso non potrai istituire una funzione bidirezionale dalla Classe CR alla Classe TR perche' le due classi non sono davvero in relazione: servono a fare cose diverse!
Mi pare ti stia infilando in uno dei soliti discorsi iperteorici che alla fine non hanno nessuna ricaduta, come quando (regolarmente, sui forum italici) si tira in ballo la semiotica, la filosofia e la filologia romanza. :)
Ok, e quindi?
-
[cite]Postato da: rgrassi[/cite]L'esempio che porti può essere decomposto in un sacco di task con 100% di probabilità di riuscita (ed è questo il motivo per cui nessuno si oppone) sino ad identificare un "task speciale" che mette in relazione il mio personaggio con l'oggetto della interazione (e la controparte del conflitto).
Ma su questo sono perfettamente d'accordo, solo che, ai fini pratici (e una teoria senza fini pratici è sofismo), quei "task" con riuscita 100% sono del tutto trascurabili e tautologici.
Oltretutto, il termine "Task Resolution" usato nel BM rappresenta una particolare tecnica di utilizzo del sistema che fa tirare dei dadi per confrontare una Caratteristica-indice-di-capacità contro una Difficoltà-indice-di-errore, fattuale e meccanico rispetto alla dichiarazione dell'intento.
La "granularità intrinseca" di una azione vista come catena di causa-effetto non ha nulla a che vedere con la scelta di fare un sistema Task o uno Conflict.
Il Conflict è un sistema basato su risoluzioni di conflitti di intenti (uso intenti e non interessi, perché in italiano il Conflitto di Interessi ha ormai un senso politico-giuridico definito), dove i GIOCATORI si confrontano su quelle che sono le risoluzioni degli scontri di intenti dei loro Personaggi.
Il Task è un sistema basato su risoluzioni di azioni meccaniche dovei i PERSONAGGI si confrontano con l'ambiente virtuale intorno a loro.
In entrambi i casi, sia CR che TR posso avere vari livelli di quella che tu chiami "granularità di task", ma questa "granularità di task" non ha nulla a che vedere con la TECNICA di risoluzioni di azioni per GdR definita Task Resolution.
G1. Muovo i miei contatti per scatenare l'olocausto nucleare.
MASTER. Tirami "conoscenze politiche" + "agganci cospirativi", -1 perché i fusi orari rallentano le tue comunicazioni, -1 perché il tuo sistema è sotto controllo, -1 perché è appena stato firmato il Nuovo Accordo di Ginevra che ha mosso l'opinione pubblica contro il Nucleare.
Task resolution, 1 tiro.
-
[cite]Postato da: renatoram[/cite]Mi pare ti stia infilando in uno dei soliti discorsi iperteorici che alla fine non hanno nessuna ricaduta, come quando (regolarmente, sui forum italici) si tira in ballo la semiotica, la filosofia e la filologia romanza. :)
Questo perché chi li tira in ballo non sa dove andare a parare :D:D
Oppure chi li legge non capisce dove si sta andando a parare :D
Chiederei gentilmente di evitare parallelismi Filosofie = Inutilità, altrimenti io parto con Matematiche = Nazifascismi ideologici :D
Il fatto che la stragrande maggioranza delle persone non sappia una cippa secca di Filosofia, non inficia il valore della Filosofia ;)
-
[cite]Postato da: rgrassi[/cite]Non so se sia chiaro che io NON sono convinto del fatto che una azione sia SEMPRE scomponibile in conflitto
Hai in mente un esempio di azione non scomponibile?
A parte questo, se ogni azione può essere giocata come Conflitto (vedi mio scorso messaggio) direi che comunque la domanda ha ricevuto risposta: l'azione ha sempre granularità inferiore al Conflitto? No, visto che poter giocare ogni azione come Conflitto significa granularità uguale. A questo punto resterebbe da vedere se un'azione sia sempre scomponibile in Conflitti inferiori e se un Conflitto sia sempre scomponibile in azioni, ma la risposta non cambia quanto detto prima.
-
Ola',
[cite]Postato da: renatoram[/cite][p]@Rob: il ragionamento e' circolare.
Non direi.
Si puo' o non si puo' scomporre?
That's the question.
Che cambia? A che ti serve saperlo?
Non è ancora chiaro? Penso di averlo già detto nei post precedenti.
Facciamo cosi': si puo'. Quindi?
Quindi, NON E' vero che la granularità è irrilevante, come dicevi prima.
Ed E' vero che si può pensare al task come ad una "unità di misura di azione".
In ogni caso non potrai istituire una funzione bidirezionale dalla Classe CR alla Classe TR perche' le due classi non sono davvero in relazione: servono a fare cose diverse!
Un mattone può servire ad un mucchio di cose.
Tanti mattoni, messi in un certo modo, servono a fare una casa.
Una casa serve a rendere gradevole la vita di chi ci vice dentro.
Il mattone e la casa servono per fare cose diverse.
E c'è naturalmente chi si specializza a fare 'mattoni migliori' e chi 'case migliori'.
Ma nessuno dei due può pensare di non essere in relazione con l'altro.
Le due classi SONO "davvero in relazione". Anzi, più di una relazione.
[/p][p]Mi pare ti stia infilando in uno dei soliti discorsi iperteorici che alla fine non hanno nessuna ricaduta, come quando (regolarmente, sui forum italici) si tira in ballo la semiotica, la filosofia e la filologia romanza. :)[/p][p]Ok, e quindi?[/p]
E quindi, NEGARE che ci sia una relazione non è il modo migliore per procedere con l'approfondire lo studio dei mattoni per "renderli migliori" o lo studio delle case, per "renderle piu' abitabili".
Rob
-
Ciao,
[cite]Postato da: khana[/cite]Ma su questo sono perfettamente d'accordo, solo che, ai fini pratici (e una teoria senza fini pratici è sofismo), quei "task" con riuscita 100% sono del tutto trascurabili e tautologici.
Ti è chiaro che la mia teoria sta cercando di andare al di fuori del BM e dei gdr-tabletop?
E che quindi i fini pratici possono sembrare trascurabili per un campo di applicazione ma fondamentale per altri?
E che quindi, potrebbe capitare che io debba parlare di "Task o Conflict" non nel senso del Big Model?
E che quando parlo di "granularità di task" NON intendo dire che ci debbano essere vagonate di dadi sul tavolo? :)
Rob
-
[cite]Postato da: rgrassi[/cite]Ed E' vero che si può pensare al task come ad una "unità di misura di azione".
Rob, questo "sì", ma "NO" se associ questa definizione di "task" alla "Task Resolution".
Sono 2 cose diverse.
E' -plausibile- pensare ad un sistema Conflict Resolution che inserisca elementi di interazione con la meccanica di risoluzione che tengano conto del "numero" di task granulari utilizzate all'interno della scena descritta, ma come dice Renato, questa granularità non ha nulla a che vedere con TR/CR.
-
@Khana: liberissimo. Sarei anche d'accordo. Entrambi i campi se non vengono mai ri-applicati alla realta' possono essere esteticamente ed intellettualmente piacevoli e stimolanti, ma sono comunque contemplazioni ombelicali.
@Rob: no, non ho e' capito dove vuoi andare a parare (saro' stordito).
Actual Play, non esempi teorici creati ad hoc, please :-P
Tanto per lasciare un ultimo pezzettino... supponendo la possibilita' di una correlazione 1:1 (o meglio, 1:molti oppure molti:1) tra i due insiemi (che ci puo' anche stare)... i due insiemi sono incompatibili. Nel momento in cui includi l'elemento di "intento" (ovvero non "faccio questa azione" ma "faccio questa azione perche' voglio ottenere X") non sei piu' in Task Resolution.
@tutti: mi ritiro dal thread, ha raggiunto la mia personale quota di umbilicalismo. Se ho il tempo di recuperare lo schemino di Fred cui accennavo lo posto qua sotto. :)
-
Ciao,
[cite]Postato da: khana[/cite]Rob, questo "sì", ma "NO" se associ questa definizione di "task" alla "Task Resolution".
Mi cospargo il capo di cenere e, per l'ennesima volta, mi pento di non aver fatto quella famosa tabella di decodifica tra lo "Spaghetti Model" ed il "Big Model".
Certo, è vero, hai ragione.
Rob
-
[cite]Postato da: rgrassi[/cite]E che quindi,potrebbe capitareche io debba parlare di "Task o Conflict" non nel senso del Big Model?
OK, sono d'accordo :D ma ti è chiaro che quindi non puoi fare prallelismi tra Task(RGrassi) e Task Resolution(BM), specialmente perché tu consideri il termine "TASK" come "unità attuo-temporale minima", mentre il BM considera "Task" come semplificazione di "Task Resolution", ossia una possibile tecnica di "System"?
-
Ciao,
[cite]Postato da: renatoram[/cite]Tanto per lasciare un ultimo pezzettino... supponendo la possibilita' di una correlazione 1:1 (o meglio, 1:molti oppure molti:1) tra i due insiemi (che ci puo' anche stare)... i due insiemi sono incompatibili. Nel momento in cui includi l'elemento di "intento" (ovvero non "faccio questa azione" ma "faccio questa azione perche' voglio ottenere X") non sei piu' in Task Resolution.
Non parliamo di "Resolution", parliamo di "Task" e "Conflict". Mi è chiaro e condivido quello che dici (per la parte delle definizioni relative al BM).
Poco sopra ho coniato il termine di "Task Speciale", nel senso che è un task DIVERSO DAGLI ALTRI, in cui potrei decomporre una azione (o una scena o ciò che sto immaginando) , e che dichiara l'ente verso il quale vuole mettersi in relazione per ottenere uno scopo. Questa cosa può sembrare banale, ma non lo è (se vuoi posso iniziare a scrivere papiri di roba cui questo argomento è collegato.)
@Mauro.
NON ho in mente task che non siano decomponibili perchè, come ho già detto, il task è l'unità di azione più piccola che posso immaginare. Significa che possiamo andare indietro all'infinito descrivendo concatenazioni di task.
Mi sembra che concordiamo, pero', sul fatto che qualunque sia lo "scope" (introduco questo importante concetto) del conflict, esso è sempre decomponibile in tasks.
Rob
-
Ciao,
[cite]Postato da: khana[/cite]ma ti è chiaro che quindi non puoi fare parallelismi tra Task(RGrassi) e Task Resolution(BM), specialmente perché tu consideri il termine "TASK" come "unità attuo-temporale minima", mentre il BM considera "Task" come semplificazione di "Task Resolution", ossia una possibile tecnica di "System"?[/p]
Piu' che chiaro, chiarissimo... Ma fatemi capire una cosa.
Devo mettere un disclaimer all'inizio di ogni post dicendo che NON sto usando i termini nel senso forgita ma in quello 'del resto del mondo'? :)
A me sembrerebbe piu' intuitivo il contrario, ma tant'è, il popolo ha sempre ragione. :D
Rob
-
[cite]Postato da: rgrassi[/cite]NON ho in mente task che non siano decomponibili perchè, come ho già detto, il task è l'unità di azione più piccola che posso immaginare. Significa che possiamo andare indietro all'infinito descrivendo concatenazioni di task.
Mi sembra che concordiamo, pero', sul fatto che qualunque sia lo "scope" (introduco questo importante concetto) del conflict, esso è sempre decomponibile in tasks
Il punto è che se concordiamo su questo perché non si riescono a immagine Conflitti non scomponibili in azioni, non capisco perché non riuscire a immaginare azioni non scomponibili in Conflitti non faccia concordare sul fatto che un'azione è sempre scomponibile in Conflitti; certo, si può assumere l'azione come unità piú piccola immaginabile, però finché non si trova un'azione non scomponibile in Conflitti è un'assunzione non piú valida del contrario. Altrimenti basterebbe dire "NON ho in mente Conflitti che non siano decomponibili perché il Conflitto è l'unità di azione più piccola che posso immaginare" per rendere il Conflitto non scomponibile: se è solo questione di definizione si può dire di tutto, ma all'atto pratico il "la considero tale" dovrebbe essere accompagnata dalla dimostrazione che è tale.
Tu giustamente dici "Ho chiesto un esempio di conflict che NON si possa decomporre in task ma non ne ho visti, ancora", ma parimenti io replico "Ho chiesto un esempio di un'azione che NON si possa decomporre in Conflitti ma non ne ho visti, ancora"; se l'assenza di risposte nel tuo caso supporta la scomponibilità di Conflitti in azioni, l'assenza di risposte nel mio supporta la scomponibilità di azioni in Conflitti.
Se poi è cosí semplicemente perché lo si pone come vero salvo falsificazione ovviamente non c'è molto da discutere, ma personalmente non vedo motivi per cui debba essere tale.
Aggiunta: salvo che tu nella tua teoria non assuma come definizione che "azione" è minore di "conflitto", mettendo un paletto "prima è azione dopo è conflitto" (anche solo negando che l'azione piú piccola possibile possa essere trattata come conflitto); in tal caso è ovvio che sia cosí, basta definire le due cose in modo che sia vero, ma allora mi sfugge il senso della discussione.
-
[cite]Postato da: rgrassi[/cite]Mi sembra che concordiamo, pero', sul fatto che qualunque sia lo "scope" (introduco questo importante concetto) del conflict, esso è sempre decomponibile in tasks.
e
[cite]Postato da: rgrassi[/cite]evo mettere un disclaimer all'inizio di ogni post dicendo che NON sto usando i termini nel senso forgita ma in quello 'del resto del mondo'? :)
Vedi, questa è la classica situazione in cui un lettore che si approccia a questo forum può cadere in pesanti incomprensioni terminologiche.
Hai ragione a dire che il senso "comune" delle parole dovrebbe prevalere, ma qui dovrebbe partire un thread apposta che definisce "quale sia" il senso comune di queste parole, in questo contesto.
Il tuo modello è funzionale all'interno del suo specifico intento, anche se io l'ho trovato in una fase ancora di definizione; nel senso che il PDF che mi linkasti mesi fa assomiglia più ad un indice che ad un vero modello completo ed esaustivo. Come ti ho detto però è riferito ad uno scopo differente da quello del BM, quindi fare parallelismi può essere un'impresa ardua (per te :P :D).
Ad esempio, il BM dichiara palesemente che quei task(RGrassi) che definisci tu non sono fondamentali per la risoluzione meccanica di una situazione, sia in termini di TR che di CR e anzi, la "moda" ultima dei sistemi NW (talebani e non) e di andare al risparmio coi tiri, esattamente come dici tu.
Se vuoi un esempio pratico, l'hack che ho proposto dello Storytelling di fatto possiede dei task(RGrassi) granulari, ma si definiscono a posteriori, ossia il task(RGrassi) di ogni singola fase viene definito in base alla risoluzione del conflict(BM) in quella specifica fase, quindi è un task(RGrassi) desunto e non presunto.
La domanda quindi rimane quella di Renato: a cosa ti serve scomporre quell'azione in task(RGrassi)?
[cite]Postato da: rgrassi[/cite]Significa che possiamo andare indietro all'infinito descrivendo concatenazioni di task.
hm? in che senso? mi fai un esempio, perché secondo me la catena causa-effetto non è risalibile e non sei mai in grado di ricostruire la causa guardando solo l'effetto (salvo rare eccezioni che ricadono nel concetto di "esperienza", no-GdR, intendo "io sì che ne ho viste cose...").
-
Ciao Mauro,
[cite]Postato da: Mauro[/cite]Il punto è che se concordiamo su questo perché non si riescono a immagine Conflitti non scomponibili in azioni, non capisco perché non riuscire a immaginare azioni non scomponibili in Conflitti non faccia concordare sul fatto che un'azione è sempre scomponibile in Conflitti
Mi sembra quindi di capire che tu voglia esempi di "azioni che non siano scomponibili in conflitti."
; certo, si può assumere l'azione come unità piú piccola immaginabile, però finché non si trova un'azione non scomponibile in Conflitti è un'assunzione non piú valida del contrario.
"Alzo il braccio destro."
Tu giustamente dici "Ho chiesto un esempio di conflict che NON si possa decomporre in task ma non ne ho visti, ancora", ma parimenti io replico "Ho chiesto un esempio di un'azione che NON si possa decomporre in Conflitti ma non ne ho visti, ancora";
Ne ho proposto uno.
Rob
-
[cite]Postato da: rgrassi[/cite]"Alzo il braccio destro."
Te la scompongo in Conflitti(BM).
ATTENZIONE, IL CONTENUTO DELLA SEGUENTE FRASE E' VOLUTAMENTE FORTE E MOLTO POCO POLITICALLY CORRECT. Leggete a vostro rischio.
Sei un ebreo in un campo di concentramento e la SS ha appena chiesto chi ha davvero il coraggio di alzare il braccio destro e gridare "sì, sono ebreo".
Quanto sei disposto a far pesare il tuo orgoglio culturale? Fino alla morte?
-
Ciao,
[cite]Postato da: khana[/cite]Come ti ho detto però è riferito ad uno scopo differente da quello del BM, quindi fare parallelismi può essere un'impresa ardua (per te :P :D).
Certo. Ma mi sembra che i termini che uso siano MOLTO piu' vicini al senso comune. Tanto è vero che molte persone, di diversi campi, hanno letto quell'articolo e hanno capito di cosa si parlasse, senza la necessità di doverlo convertire al loro linguaggio tecnico.
Ad esempio, il BM dichiara palesemente che quei task(RGrassi) che definisci tu non sono fondamentali per la risoluzione meccanica di una situazione, sia in termini di TR che di CR e anzi, la "moda" ultima dei sistemi NW (talebani e non) e di andare al risparmio coi tiri, esattamente come dici tu.
D'accordo. E questa è una scelta di 'design' che può piacere o no. Ne sono conscio e la uso massicciamente.
D'altra parte trovo anomalo che si definisca un "Task Resolution" senza capire cosa sia un Task.
Come parlare di "Pagamento della Bolletta della luce" senza definire cosa sia una bolletta della luce. :D
La domanda quindi rimane quella di Renato: a cosa ti serve scomporre quell'azione in task(RGrassi)?
Nello specifico gioco, in quello specifico momento, NON mi serve.
Ma mi chiedo, esiste per voi qualcosa che vada al di la' del tavolo da gioco di gdr?
Se noto analogie fra generi di gioco che "sembrano" diversi ma non lo sono, è possibile cercare di capire quali siano le cose in comune e quelle NON in comune?
"I bianchi sono diversi dai neri perchè hanno un colore di pelle diverso."
"Si, ma il sangue è dello stesso colore."
"Allora forse fanno parte dello stesso genere."
Capire l'esistenza e la natura del task (per l'esempio di prima, capire se bianchi e neri hanno il sangue e se lo hanno dello stesso colore) POTREBBE essere l'aggancio tra un genere di gioco (ad esempio le avventure testuali) ed un altro (i gdr tabletop). Capire questo potrebbe portare a migliorare molto le teorie e le conoscenze tra i diversi generi perche' sappiamo quali cose buone di un genere possono essere integrate nell'altro, e perche'.
Alla mia domanda, quindi: "Ma i bianchi e i neri hanno il sangue?"
Voi mi state rispondendo: "A cosa ti serve saperlo? La saliva serve per disinfettarsi le ferite superficiali."
Significa che possiamo andare indietro all'infinito descrivendo concatenazioni di task.
[p]hm? in che senso? mi fai un esempio, perché secondo me la catena causa-effetto non è risalibile e non sei mai in grado di ricostruire la causa guardando solo l'effetto (salvo rare eccezioni che ricadono nel concetto di "esperienza", no-GdR, intendo "io sì che ne ho viste cose...").
Non pensare al "motore immobile", Dav, perchè gia' lo so che ti stai facendo i trip.
Sto dicendo che quale che sia il task, si puo' procedere ad una decomposizione che si fermerà, nel caso specifico dei giocatori attorno ad un tavolo per convenzione, consenso o buon senso, ad uno "scope" concordato.
Alzo il braccio e lo porto al volto può essere "accettato" come un task unico, o decomposto in molti sotto task.
In una avventura testuale può essere DIGITATO come unico comando ma viene sempre decomposto in due comandi diversi (perchè entrambi hanno impatti diversi rispetto al world-model).
Rob
-
Ciao,
[cite]Postato da: khana[/cite][cite]Postato da: rgrassi[/cite][p]"Alzo il braccio destro."[/p]
[p]Te la scompongo in Conflitti(BM).[/p][p]ATTENZIONE, IL CONTENUTO DELLA SEGUENTE FRASE E' VOLUTAMENTE FORTE E MOLTO POCO POLITICALLY CORRECT. Leggete a vostro rischio.[/p][p]Sei un ebreo in un campo di concentramento e la SS ha appena chiesto chi ha davvero il coraggio di alzare il braccio destro e gridare "sì, sono ebreo".
Quanto sei disposto a far pesare il tuo orgoglio culturale? Fino alla morte?[/p]
Questa non è una decomposizione (cioè definire enti piu' piccoli che sono componenti di un ente piu' grande, o magari il BM ha ridefinito pure decomposition e non lo so?).
Rob
-
[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".
-
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
-
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 :D
-
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...
-
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. :D
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. :D
-
La discussione è un pezzo che si è arenata...
Comunque, la mia risposta a cui mi riferisco era la numero 16 (http://www.gentechegioca.it/vanilla/comments.php?DiscussionID=682&page=1#Item_16), la tua "sfida" era la numero 19 (http://www.gentechegioca.it/vanilla/comments.php?DiscussionID=682&page=1#Item_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.
-
[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.
-
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) :D
Penso che non ne veniamo fuori via forum. Forse una discussione 'de visu' risolverebbe le incomprensioni.
Rob
-
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? :)
-
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
-
A parte l'uso del termine "sis", nulla di quello che ha detto è specifico del Big Model. E' semplicemente come funzionano i gdr.
-
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. :D
Rob
-
[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.
-
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...
-
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.
-
Nella mia ignoranza, mi permetto di intervenire solo per dire che questa discussione mi sembra un esempio da manuale di come i discorsi teorici, sganciati dalle esperienze reali (AP), si trasformino in boli convoluti e indecifrabili in cui neanche i postatori si capiscono più fra loro... Va sempre a finire così :[
-
Moreno, se ci vediamo a qualche con e siamo liberi, promettiamoci di riservarci una ventina di minuti per parlare 'de visu'...
Ora passiamo agli Actual Play.
Vorrei che mi dicessi, se hai voglia, COSA SONO le cose che ti riporto qui sotto, in particolare quello che viene digitato dopo ">" e le risposte del computer.
****************************************************************************************************************
Welcome to Zork (originally Dungeon). This version created 11-MAR-91 (PHP mod 03-AUG-05)
There are 21 users playing Zork. Of those, 18 have not logged in.
There are 43069 registered adventurers.
You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
> open mailbox
Opening the mailbox reveals:
A leaflet.
> get leaflet
Taken.
> read leaflet
Welcome to Zork (originally Dungeon)!
Dungeon is a game of adventure, danger, and low cunning. In it
you will explore some of the most amazing territory ever seen by mortal
man. Hardened adventurers have run screaming from the terrors contained
within.
In Dungeon, the intrepid explorer delves into the forgotten secrets
of a lost labyrinth deep in the bowels of the earth, searching for
vast treasures long hidden from prying eyes, treasures guarded by
fearsome monsters and diabolical traps!
No DECsystem should be without one!
Dungeon was created at the Programming Technology Division of the MIT
Laboratory for Computer Science by Tim Anderson, Marc Blank, Bruce
Daniels, and Dave Lebling. It was inspired by the Adventure game of
Crowther and Woods, and the Dungeons and Dragons game of Gygax
and Arneson. The original version was written in MDL (alias MUDDLE).
The current version was translated from MDL into FORTRAN IV by
a somewhat paranoid DEC engineer who prefers to remain anonymous,
and was later translated to C.
On-line information may be obtained with the commands HELP and INFO.
This version is a PHP web hack of the original Dungeon, which allows
you to LOGIN, SAVE, and RESTORE your game. You can see your fellow
players, but since they are running their own instance of the game
you can't do much other than SAY things to them.. or at least you will
be able to once that bit has been coded. It is a work in progress.
Have fun.
> go north and examine me
You are facing the north side of a white house. There is no door here,
and all the windows are barred.
****************************************************************************************************************
Rob
-
Input in un gioco per PC? Istruzioni? Parole? Comunicazione? Non so, sono tante cose, dipende dall'ottica con cui li osservi. Dal punto di vista del BM non sono niente, sono cose esterne al modello.
Di sicuro non sono task resolution. Non avviene nessuna "risoluzione", sono azioni permesse dal programma, altre non sono permesse. L'equivalente in un gdr sarebbe appunto "vado verso la finestra" nei due casi "la finestra esiste" e "non c0è nessuna finestra". Non è task resolution perchè non c'è nessuna risoluzione.
Questi sono i tipi di vicoli ciechi concettuali in cui ti ficchi quando invece di considerare il gioco come costruito dalla comunicazione, te lo immagini come una "realtà alternativa da esplorare", e cominci a dimenticarti che questa realtà è fatta di parole, non di atomi. E perdi la differenza fra risoluzione e enunciazione (che come ordine di grandezza della sbandata, è l'equivalente rpg-istico dello scambiare un paracarro per una pesca in botanica...)
-
Ola',
[cite]Postato da: Moreno Roncucci[/cite][p]Input in un gioco per PC? Istruzioni? Parole? Comunicazione?
Li vogliamo chiamare 'task'? Per me che digito sono "input". Per il mio avatar sono 'task' da eseguire.
Non so, sono tante cose, dipende dall'ottica con cui li osservi. Dal punto di vista del BM non sono niente, sono cose esterne al modello.[/p][p]Di sicuro non sono task resolution. Non avviene nessuna "risoluzione", sono azioni permesse dal programma, altre non sono permesse.
Se hai voglia seguimi ancora 5 minuti...
Dici che non c'è "resolution" (BM).
Allora vado a vedere la definizione di resolution.
"Establishing fictional events into the time-sequence of the Shared Imaginary Space. Includes DFK, IIEE, and narration, among other things. A necessary feature of System. "
Vedo cosa vuol dire "Establish" (molte cose)
http://www.wordreference.com/definition/establish
e ne deduco che 'establish' in sostanza è il processo delegato a dire quali eventi esistono nel SIS (significa che sono quelli che sono passati ad ogni vaglio e sono concordati da tutti i giocatori).
Questa 'resolution' esiste dunque nelle avventure testuali? O meglio, si può "mutuare" il concetto di resolution del BM al mondo delle AT? Mi sembra di sì. E' quello che verifica il programma per capire se:
- Il personaggio può eseguire 'fisicamente l'azione' (indipendentemente da dove si trova, ad esempio se non ha le braccia non potrà mai 'prendere qualcosa').
- Il personaggio può eseguirla 'fisicamente rispetto al contesto' (ad esempio se l'oggetto con cui vuole interagire è "in scope" o no).
- Il personaggio può eseguirla 'logicamente' rispetto al contesto. (la mia spada è vicino a me, ma al di là del troll. Il giocatore può DIGITARE "> prendi spada", in base a ciò che ha previsto l'autore del gioco il programma genererà un output di testo conseguente. (Nota, in questo caso è identico all'inizio della definizione di 'parpuzio', in cui IL GIOCO MI DICE cosa vedo e descrivo le conseguenze delle mie azioni).
- Aggiorna lo 'stato del mondo' al termine dell'azione.
"Who establish a fictional event" nel mondo delle AT?
Il programma che esegue il gioco. In particolare i "fictional events" possibili sono predeterminati e possono essere di diverso tipo (ma qui entriamo troppo nel tecnico di un determinato tipo di giochi e glisso).
> Questi sono i tipi di vicoli ciechi concettuali in cui ti ficchi quando invece di considerare il gioco come costruito dalla
> comunicazione, te lo immagini come una "realtà alternativa da esplorare", e cominci a dimenticarti che questa realtà
> è fatta di parole, non di atomi.
Questa realtà è fatta "solo" di parole solo in alcuni tipi di Gdr. In altri tipi di Gdr no. Ma MOLTI tipi di gioco diversi parlano di se' stessi come giochi di ruolo e moltissime persone sentono una 'vicinanza' tra forme diverse di gioco, al punto che si 'travasano' allegramente tra il gdr tabletop e le AT, tra il gdr tabletop ed il librogame, tra il gdrtabletop ed il mud, tra il gdr tabletop ed il MMORPG...
Queste sono altre forme di gdr fatte "solo" di paragrafi da leggere, di pulsanti da schiacciare su un controller, di tasti e comandi da digitare su una tastiera, etc...
Pensi che queste persone percepiscano davvero cosi' tante differenze tra queste forme di gioco?
Rob
-
Un paio di cose
[ulist]- Te lo chiedo per favore, Roberto. Non fare anche tu un overload dei termini del BM. Lo hanno fatto (in un altro ambito) quei %&//%&$/% che hanno scritto il LISP ed il Prolog con molti dei termini dei linguaggi procedurali, ed il risultato è stato - per dirla con un efufemismo - "una certa confusione". La faccia del creatore del LISP la ho sul bersaglio delle freccette, e non dico altro. Se sono gli stessi concetti, chiamali con il loro nome, se sono concetti diferenti trova parole differenti. Non vorrai mica finire a fare da bersaglio alle freccette anche te? ;-)
- Non ho capito dove si vuole andare a parare con tutta questa disquisizione. Sono millemila messaggi che non vi riesco più neppure a seguire. Quale è il caso pratico che ha generato la discussino e quale è l'obbiettivo che si pone?
[/ulist]
-
[cite]Postato da: rgrassi[/cite][p]Ola',[/p][cite]Postato da: Moreno Roncucci[/cite][p]Input in un gioco per PC? Istruzioni? Parole? Comunicazione?[/p]
[p]Li vogliamo chiamare 'task'?[/p]
Come ti hanno già detto, se chiami tutto "task", è ovvio che poi trovi "task" dappertutto.
Visto che hai tirato fuori tu wordreference.com...
task
A noun
1 job, task, chore
a specific piece of work required to be done as a duty or for a specific fee; "estimates of the city's loss on that job ranged as high as a million dollars"; "the job of repairing the engine took several hours"; "the endless task of classifying the sample
2 undertaking, project, task, labor
any piece of work that is undertaken or attempted; "he prepared for great undertakings"
Non mi sembra molto applicabile a micromovimenti di pochi millimetri per volta come volevi fare tu per poter dire che qualunque conflitto era fatto di task... :-)
Per me che digito sono "input". Per il mio avatar sono 'task' da eseguire.
Non esiste nessun "avatar" e nessun ambiente in cui si muove il tuo Avatar, se non nell'immaginazione.
Non puoi studiare la "macchina" che crea quell'illusione (il gioco) se continui a credere nell'illusione. E' l'errore concettuale di quelli che vedono ancora il sistema come "la fisica del mondo di gioco"
Se vuoi studiare il gioco, devi vedere quello che avviene REALMENTE, al tavolo o nel computer. Non quello che ti immagini nella tua fantasia mentre giochi.
Dici che non c'è "resolution" (BM).
Allora vado a vedere la definizione di resolution.
"Establishing fictional events into the time-sequence of the Shared Imaginary Space. Includes DFK, IIEE, and narration, among other things. A necessary feature of System. "
Vedo cosa vuol dire "Establish" (molte cose)
http://www.wordreference.com/definition/establish
e ne deduco che 'establish'in sostanzaè il processo delegato a dire quali eventi esistono nel SIS (significa che sono quelli che sono passati ad ogni vaglio e sono concordati da tutti i giocatori).
Vedi, io sinceramente non ci credo che ti sei andato a vedere "resolution" e "estabilih", e non ti sei ancora andato a vedere "task resolution", di cui stai parlando dal principio... allora perché non quoti anche quello?
Forse perché taglierebbe la testa al toro evitando un lunghissimo thread che gira sempre intorno al ripetere le stesse cose?
Task resolution: A Technique in which the Resolution mechanisms of play focus on within-game cause, in linear in-game time, in terms of whether the acting character is competent to perform a task. Contrast with
Conflict resolution.
-
[cite]Postato da: rgrassi[/cite]Si traducono in "risoluzione di un task" e "risoluzione di un conflitto".
No, si traducono in "sistema a Risoluzione tramite Task" e "sistema a Risoluzione tramite Conflitti", dove "Task" è specificatamente inteso come quell'atto per cui il personaggio compie un'azione rappresentata in modo quantitativo da una caratteristica, che viene contrapposta ad una difficoltà numerica e il rapporto delle due è risolto dal tiro di un dado e dove "Conflict" è invece una divergenza di intenti tra i giocatori sul "come", spesso sul "perché" un'azione viene fatta, ma soprattutto su "a cosa porta".
[cite]Postato da: rgrassi[/cite]You are facing the north side of a white house. There is no door here,
and all the windows are barred.
Il problema è che in un gioco "forgita" non puoi limitare le opzioni del personaggio imponendo su di lui l'ambiente, perché l'attenzione è "girata" verso il modo in cui i giocatori sono in grado, attraverso i loro personaggi, di creare storie, di creare scene "divertenti" dove per "divertente" si intende "produrre scene che siano coerenti con il tema del gioco".
In quest'ottica, io ci vedo una netta inversione di rotta, dove l'ambiente diventa uno strumento e smette di essere un limite, mentre i limiti sono proprio quelle "caratteristiche" che nei giochi precedenti erano strumenti. Limiti che, come già detto in altri post da altre persone, sono "positivi" in quanto aiutano la creatività a generare narrazione.
Con l'avventura testuale che hai proposto tu, posso decidere io giocatore cosa c'è nella casa e perché le porte sono chiuse? O è prestabilito da un "autore"?
-
EDIT: ok, ho capito, Moreno ha modificato il messaggio dopo che Michele ha postato il suo e l'ordine si è invertito... :D divertente :D
-
Direi di no... Mi stai spiegando quello che il BM dice.
no, ti sto spiegando che tu confondi "quello che succede" con "le tecniche usate per accettare che succeda quelcosa"
-
[cite]Postato da: MicheleGelli[/cite]Non ho capito dove si vuole andare a parare con tutta questa disquisizione. Sono millemila messaggi che non vi riesco più neppure a seguire. Quale è il caso pratico che ha generato la discussino e quale è l'obbiettivo che si pone?
non avrei saputo dirlo meglio ... la risposta aiuterebbe i lurkatori :P
-
[cite]Postato da: MicheleGelli[/cite]Non ho capito dove si vuole andare a parare con tutta questa disquisizione. Sono millemila messaggi che non vi riesco più neppure a seguire. Quale è il caso pratico che ha generato la discussino e quale è l'obbiettivo che si pone?
Mi accodo alla richiesta. Questo renderebbe anche più chiara la discussione e potrebbe magari evitare ulteriori fraintendimenti.
-
Purtroppo non sono riuscito ad andare a Torino... Peccato.
Allora, provo a ripartire da zero.
Domanda 1 (cui la mia risposta è SI, ma vediamo cosa ne pensate voi)
"Secondo voi hanno qualcosa in comune i gdr tabletop, i librogame (cartacei ed elettronici), le avventure testuali, i MUD, i CRPG, i MMORPG, etc...?"
Domanda 2
"Se la risposta alla domanda 1 è SI, allora vi chiedo COSA HANNO IN COMUNE?"
@Moreno
'Establish' me lo sono letto, così come 'Resolution', così come 'Task Resolution'. Ti metto la parte su cui sto discutendo in neretto.
Task resolution: A Technique in which the Resolution mechanisms of play focus on within-game cause, in linear in-game time, in terms of whether the acting character is competent to perform a task. Contrast with
Conflict resolution.
"Competent to perform a TASK". Vi chiedo, dunque, cosa è (cosa può essere) un task? O la domanda è illegittima?
Rob
-
[cite]Postato da: rgrassi[/cite][p]Purtroppo non sono riuscito ad andare a Torino... Peccato.
Allora, provo a ripartire da zero.[/p][p]Domanda 1 (cui la mia risposta è SI, ma vediamo cosa ne pensate voi)
"Secondo voi hanno qualcosa in comune i gdr tabletop, i librogame (cartacei ed elettronici), le avventure testuali, i MUD, i CRPG, i MMORPG, etc...?"[/p][p]Domanda 2
"Se la risposta alla domanda 1 è SI, allora vi chiedo COSA HANNO IN COMUNE?"[/p][p]@Moreno
'Establish' me lo sono letto, così come 'Resolution', così come 'Task Resolution'. Ti metto la parte su cui sto discutendo in neretto.
Task resolution: A Technique in which the Resolution mechanisms of play focus on within-game cause, in linear in-game time,in terms of whether the acting character is competent to perform a task. Contrast with
Conflict resolution.[/p][p]"Competent to perform aTASK". Vi chiedo, dunque, cosa è (cosa può essere) un task? O la domanda è illegittima?
Rob[/p]
scusate l'OT, ma a me piace lurkare queste discussioni sulla teoria anche perché essendo in italiano e su un forum che seguo anche per altre ragioni mi rendono la vita semplice e vorrei capire bene dove sta andando questa discussione e qual'è l'argomento
infatti io non capisco dove vogliamo andare: confronti tra modelli diversi dal BM?
trovare falle nel BM
discussioni sul sesso degli angeli: qui io metto tutto ciò che è discutere a livello "filosofico" della natura vera delle cose ma senza arrivare ad un punto pratico. cioé argomentare senza un chiaro punto di arrivo che possa essere usato in termini pratici
boh mi piacerebbe capire dove vogliamo anare a parare. ad esempio: Rob hai fatto una domanda e ti sei dato una risposta. perché? pura conoscenza dell'opinione degli altri? o vuoi portare avanti un idea che hai? se la seconda è la risposta magari metti anche la teoria che hai
cioé mettiamo chiarezza per i semplici lettori. perché alle volte mi leggo una pagina di post e mi chiedo che significa .... e vabbé che il tempo non è denaro ...
per me la risposta è SI, li uso per divertirmi.
-
Scusate, io penso che si andrebbe piu' veloci ad essere chiari...
Antonio, puoi darmi una risposta a questa domanda?
"Secondo te hanno qualcosa in comune i gdr tabletop, i librogame (cartacei ed elettronici), le avventure testuali, i MUD, i CRPG, i MMORPG, etc...?"
Questo non è sesso degli angeli. Non rispondere pensando a secondi fini. Rispondi serenamente. SI? NO? Si, pero'? No, pero'?
Rob
-
Ok, quindi la risposta è SI, perchè li usi per divertirti.
Ora ti chiedo, ma proprio non vedi nessun altro punto in comune?
Mi sembra ovvio che se mi dici NO, non ci saranno altri punti di discussione comuni.
Se invece c'è qualcuno, tra di voi, che pensa che ci siano altre cose in comune, a parte il fatto che uno li usi per divertirsi, allora può diventare un buon interlocutore.
Rob
-
La domanda di Antonio mi pare pienamente legittima, e avrei dovuto farla io da un bel po' prima di arrivare al post numero 75. Ha chiesto lo SCOPO di questa discussione, e Roberto ha risposto per due volte con un altra domanda.
E' un sondaggio? Per vedere cosa pensano gli utenti di questo forum? O vuoi dimostrare qualcosa? Che cosa?
Perché è importante saperlo? Perché se si vuole fare una discussione seria, non si può imporre in partenza di non seguire altre vie, altri esempi ed altri ragionamenti se non quelli che vuoi imporre tu. Se dici subito la tua tesi, la si può affrontare da più angoli e discuterne sul serio. Se invece fai una serie di domande di cui non si capisce il senso, più che una discussione pare un interrogatorio. "qualunque cosa dirai potrà essere usata contro di te". Soprattutto in un ambito dove le parole spesso possono essere equivocate e potrei rispondere a qualcosa nel post n.80 e scoprire nel post 200 che da 120 post stai completamente equivocando quello che avevo risposto.
Ed è assurdo che dopo 75 post di questa manfrina, ancora continui sulla stessa strada.
Non ho voglia di perdere altro tempo in giochini. Se vuoi discutere di una tesi, postala, altrimenti per me il thread finisce qui.
-
Lo scopo di questa discussione era, riprendendo dal post iniziale, capire se si possa identificare, nei gdr, UN UNICO task o UN UNICO conflitto tale per cui, dichiarandolo e risolvendolo il gioco finisce in un turno. In altre parole, ci si trova attorno al tavolo e la sessione dura un secondo. Ma poiche', mi rendo conto ora, questo non è il forum adatto per parlarne, vado a rispondere alla domanda di Moreno, "Perchè è importante saperlo?"
Moreno, se ancora non si fosse capito, la mia "tesi" è questa.
http://nuke.robertograssi.net/Portals/0/RpgFiles/IFondamentiDelRole-Playing.pdf
+ questa:
http://nuke.robertograssi.net/Portals/0/RpgFiles/IFRP-ConcettoDiRuolo.pdf
Sono due articoli, per ora, ma aumenteranno, appena il tempo tiranno lo consentirà.
Ora ti chiedo, questi articoli li hai letti? Io penso di no.
Ma ti ricopio l'introduzione del primo, a tuo beneficio.
******************************************
Questo è il primo articolo, di una serie, che si pongono l’obiettivo di definire un modello
unificato ed un glossario comune per molte forme e giochi che vanno sotto il nome di narrazione
interattiva e gioco di ruolo.
In base alla mia esperienza, ho riscontrato che molte forme di gioco diverse usano un lessico
differente, nonostante il concetto da esprimere sia identico. Questo impedisce di poter analizzare
con una certa facilità i problemi e le teorie sottostanti (design, miglioramento della giocabilità) di
questi tipi di gioco e di forme di narrazione.
Un elenco, certamente non esaustivo, comprende:
· Avventure testuali
· Interactive Fiction
· Avventure Grafiche
· CRPG
· MUD
· MMORPG
· MUSH
· Tabletop RPG
· RPG Live
· Free Form
· Chamber games
· Giochi di narrazione
· Librogame
L’obiettivo, ambizioso, sarà quello di iniziare a delineare elementi comuni ad ognuna di
queste forme di role-playing e di gioco in modo da poter costruire una teoria ed un modello
unificati.
Dopodichè, mappare le teorie esistenti su questo modello ed infine produrre teorie ed idee
innovative per poter migliorare il design e consentire ai creatori di questi giochi di ampliare la
conoscenza teorica, utilizzando concetti di un campo di applicazione in altri.
******************************************
Dunque la mia tesi è che SI, ci sono molte cose in comune tra questi generi di gioco (e che non ci si limita al fatto che uno li usa per divertirsi.) E queste cose in comune sono rappresentabili tramite un modello, sufficientemente generico, che possa dare un'unica descrizione del framework comune.
Ogni genere di gioco istanzia quel modello secondo tecniche e pratiche specifiche.
Ecco, come vogliamo procedere ora?
Dimmelo tu.
Devo/posso fare una domanda?
Rob
-
[cite]Postato da: rgrassi[/cite]Lo scopo di questa discussione era,riprendendo dal post iniziale, capire se si possa identificare, nei gdr, UN UNICO task o UN UNICO conflitto tale per cui, dichiarandolo e risolvendolo il gioco finisce in un turno.
Ora che è formulato in un'unica frase ^_- ti dò il mio parere:
"SI', è teoricamente possibile, ma estremamente insoddisfacente in pratica. La differenza è un po'tra guardare Romeo E Giulietta e leggere un riassunto che dice <>! "
-
Risposta: no. Non esiste.
O meglio, potrebbe esistere in casi particolari (un gdr in cui ci sia una missione esplicita: "sconfiggere il mago xztk!", il primo giocatore fa un conflitto per sconfiggere il mago) ma non è applicabile in generale.
E per saperlo, ti bastava giocare, per esempio, ad Avventure in Prima Serata, o La Mia Vita Col Padrone, o Spione, che hanno condizioni di fine gioco non raggiungibili immediatamente.
In ogni caso, non si tratterebbe di un caso pratico: a quale tavolo di gioco la cosa sarebbe accettata?
Auguri per il modello. Non mi sembra un compito facile. In ogni caso, cerca di usare una terminologia separata per non generare equivoci quando parli del tuo modello e non del Big Model.
-
[cite]Postato da: rgrassi[/cite][p]Purtroppo non sono riuscito ad andare a Torino... Peccato.
Allora, provo a ripartire da zero.[/p][p]Domanda 1 (cui la mia risposta è SI, ma vediamo cosa ne pensate voi)
"Secondo voi hanno qualcosa in comune i gdr tabletop, i librogame (cartacei ed elettronici), le avventure testuali, i MUD, i CRPG, i MMORPG, etc...?"[/p][p]Domanda 2
"Se la risposta alla domanda 1 è SI, allora vi chiedo COSA HANNO IN COMUNE?"[/p]
Rob[/p]
trovo difficile dare risposta a una domanda del genere perchè troppo ambigua
Tendenzialmente potrei rispondere un sì che in realtà è molto fuoriviante.
Ad esempio è come chiedere se sono accomunabili il calcio e il nuoto, chiesto così senza specificazioni dare come risposta tutto e il contrario di tutto, tipo "sì, sono sport", "Sì non mi piaciono", "no uno è di squadra, l'altro singolo", "no, uno è uno sport, l'altro un business", "sì, sono professioni", "no, uno si pratica nell'acqua, l'altro sull'erba".
A seconda del Frame di riferimento le concezioni che citi possono essere accomunabili tutti o separabili tutti, oppure si potrebbero raggruppare per cluster. Però non espliciti nessun frame, questo comporta che ognuno ragiona rispetto al suo implicito e da adito a quel che si è visto, incomprensioni, frustrazioni e financo flame.
La mia non vuole essere una critica alla intenzione bensì al metodo, però trovo l'ipotesi portata dal tuo articolo sperimentalmente e accademicamente invalida. Mi spiego.
Sembrerebbe di intuire tu voglia fare un'analisi comparata o una sintesi teorico-formativa tra gli stumenti che hai elencato, ma per farlo quale approccio teorico stai utilizzando? A quali costrutti (sociali, psicologici, antropologici, ingegneristici etc.) fai riferimento? All'interno di quale disciplina scientifica vuoi stare?
Senza elementi simili il rischio è quello di navigare a braccio, senza strumentazione, in un mare in tempesta, ci si deve barcamenare tra cose come comportamenti, riti, atteggiamenti, inconscio, personalità, influenza sociale, storia personale, desideri e chissà quanto altro. Purtroppo fare riferimento a un approccio limita le possibilità di comprensione di un fenomeno, ma limitare il campo (pressocchè infinito) di possibilità è l'unica maniera che l'uomo ha appreso per rendere comprensibile ogni oggetto che studia.
In soldoni... Se non espliciti approcci teorici e costrutti di riferimento finirà che farai una analisi basata su modelli inconsci e non esplicitati, quindi il modello che ne trarrai non potrà avere pretesa di universalità (ma questo vale per tutti i modelli) ne pretesa di scientificità, e si rivelerà presto sterile, fallato e inconcludente.
Infine do la mia risposta (articolata) alla domanda...
la risposta è NO, mai! A qualcuno potrebbe venire spontaneo dire sì, ma soltanto finchè non si esplicita una cornice di riferimento. Ma ogni volta che viene data una cornice (che banalmente significa concretizzare, o legare le parole a fatti reali) sicuramente ci sarà sempre qualcosa che non c'entra con gli altri.
Ciò che elenchi ha scopi, funzioni e pretese diverse. Addirittura tentando una generalizzazione secondo un approccio psico-sociologico (un po' vanilla) potremmo al massimo generare tre cluster analitici:
1- oggetti che riguardano un rapporto sociale diretto tra attori (es. Freeform)
2- oggetti che riguardano un rapporto sociale mediato (da uno strumento) tra attori (es. MMORPG o giochi di narrazione)
3- oggetti che riguardano un rapporto tra un attore e uno strumento (es. Librogame, avventura grafica)
Queste le mie ipotesi, queste le mie critiche, queste le mie idee.
Sicuramente criticabili.
-
[cite]Postato da: rgrassi[/cite]Lo scopo di questa discussione era,riprendendo dal post iniziale, capire se si possa identificare, nei gdr, UN UNICO task o UN UNICO conflitto tale per cui, dichiarandolo e risolvendolo il gioco finisce in un turno. In altre parole, ci si trova attorno al tavolo e la sessione dura un secondo.
Premettendo che trovo il quesito piuttosto assurdo e che, nonostante questa spiegazione, non capisco a cosa possa servire in pratica la mia risposta è che sì, e possibile, ma che è anche tremendamente inutile e noioso. Qualcuno vorrebbe mai giocare ad un gioco del genere?
-
[cite]Postato da: rgrassi[/cite]Un elenco, certamente non esaustivo, comprende:
· Avventure testuali
· Interactive Fiction
· Avventure Grafiche
· CRPG
· MUD
· MMORPG
· MUSH
· Tabletop RPG
· RPG Live
· Free Form
· Chamber games
· Giochi di narrazione
· Librogame
Io non sono per niente d'accordo sul fatto che questi tipi di gioco siano poi così accumunabili. Il design di un Libro Game è "pura" preparation, quell'elemento che di fatto dai GdR ultimamente si sta rimuovendo per sostituirlo con gli interventi di giocatori al tavolo.
Teorie come il BM e altri modelli stanno proprio insistendo sulla differenza di interazione "passiva", da spettatore, da giocatore che subisce lo scenario del master e può solo "tirare per salvarsi", a situazioni in cui lo scenario è il -risultato- della sessione.
Se invece prendi in considerazione il GdR "tradizionale", forse puoi avere ragione ad accomunarli con questi altri tipi che declini, ma solo perché dai peso a tutti quegli elementi del GdR tradizionale che il Design forgita sta cercando di rimuovere.
-
[cite]Postato da: rgrassi[/cite]Vi chiedo, dunque, cosa è (cosa può essere) un task?
già risposto
[cite]Postato da: khana[/cite]dove "Task" è specificatamente inteso come quell'atto per cui il personaggio compie un'azione rappresentata in modo quantitativo da una caratteristica, che viene contrapposta ad una difficoltà numerica e il rapporto delle due è risolto dal tiro di un dado
-
Sicuramente per colpa mia, non riesco ad innescare un feedback sugli argomenti che mi stanno a cuore e che ritengo possano essere interessanti per creare un 'ponte' tra diversi campi.
Un saluto.
Rob
-
Rob, mi spiace che tu la prenda così... ma il problema della divisione in unità di tempo/azione millesimali nel desing del GdR a cui al momento si fa riferimento qui, non c'è.
La cosa più prossima che esiste è il concetto di IIEE, che però è una divisione soggettiva ed introspettiva. Questo IIEE è il motivo per cui Renato ed altri ti hanno risposto che ogni Task(BM) o task(RGrassi) è a sua volta divisibile in Conflicts(BM), perché ogni singola azione meccanica quale anche "alzo il braccio" può essere siddivisa in "motivo per cui alzo braccio", "intenzione di alzare il braccio", "conseguenza percepita dell'alzare il braccio", "conseguenza reale"... Non c'è più l'interesse nel suddividere un'azione in 10 unità di Iniziativa da sommare al d10 per vedere chi termina per primo la sua azione, c'è l'interesse di narrare quale siano i motivi psicologicamente profilati sulla scheda del personaggio tali per cui quell'azione avviene o meno e che conseguenze ha per il personaggio.
Quell'incipit di avventura ipertestuale interattiva che hai messo è un buon terreno di esempi. Per un GdR NW sarà uno dei giocatori che a dire cosa trova nella cassetta delle lettere e chi l'ha mandato, non c'è il processo del giocatore che apre e aspetta che il Master gli dica "come è il mondo intorno a lui". Nei giochi NW sono i giocatori che dicono al "Master" come è il mondo intorno a loro e il "Master" si preoccupa di far diventare quel mondo un buon motore dialettico per creare "storie", stando attento a quando far intervenire il sistema.
E' proprio opposto il punto di vista: non si gioca verso l'ambiente, si gioca verso i personaggi, quindi l'esito di un tiro non definisce cosa avviene, ma definisce come il personaggio viene modificato dalla cosa che è avvenuta.
Ci sono sistemi che non stanno neanche a sindacare sul fatto che una cosa sia avvenuta o meno: se un giocatore la dichiara, è avvenuta; quindi non mi interessa sapere quante task(RGrassi) impiego per farla, perché è sempre e comunque una: la dichiaro; ed è "una" dal punto di vista del Giocatore, non del Personaggio. Al Personaggio "interessa" solo sapere come questa unica task(RGrassi) del Giocatore va a rompergli le palle sul lato del profilo designato dalla scheda.
Se un'azione non modifica il personaggio, non è nemmeno una task(RGrassi).
Rimane il dubbio su cosa intendi tu per conflitto(RGrassi), forse sbrogliare questo significato potrebbe aiutare entrambe le parti.
Il problema è che Conflict(BM) definisce una precisa pratica tecnica di operare ed intendere l'uso delle meccaniche di un GdR, ossia il definire una Posta(BM) e con l'aiuto del sistema vedere se/quando/come/chi riesce a realizzare la Posta(BM). Il Conflict(BM) non è solo e necessariamente una contesa tra 2 Personaggi. Volendo, è più una contesa tra 2 Giocatori...
-
Non l'ho mica presa a male... :) Evidentemente non riesco a spiegarmi bene, amen. Che ci posso fare?
NON E' mia intenzione parlare di parametri estetici, nel senso di "questa cosa è tecnicamente fattibile, ma chi giocherebbe ad un gioco del genere?", o funzionali "a livello di design è una cosa che non ti fa ottenere ciò che vuoi", nè sto parlando assolutamente di "chi narra cosa e come."
Proverò a fare questa tabella di transcodifica (ne dovrò fare una per ogni campo che 'invoco'), evidentemente sono un alieno. Come tale, sono io che devo aprire un canale di comunicazione.
Rob
-
Per l'ennesima volta: il concetto di "conflict resolution" non presuppone l'esistenza di una "posta"... =:-I
Anche perché altrimenti ci si chiede come si facesse a usare la conflict resolution per anni prima che venisse introdotto il concetto di "posta"...
Che "posta" c'è in Sorcerer? o IAWA?
Non scambiate una tecnica specifica usata in Avventura in Prima Serata per una regola generale, please...
-
A More', dillo a Khana... :)
E non usare il 'voi'.
Rob
-
[cite]Postato da: Moreno Roncucci[/cite]Per l'ennesima volta: il concetto di "conflict resolution" non presuppone l'esistenza di una "posta"... =:-I
Cercherò di recuperare il tuo post dove scrivevi in caratteri cubitali "what's at stake?" spiegando i principi con cui si profila il Conflict Resolution :) (sempre che tu non l'abbia già corretto).