Home Page GDR-online.com

Login     Password       [registrati]  [password?] 

Non sei registrato al portale! Scopri come eliminare i pop-up ed accedere a tante funzionalità registrandoti gratuitamente!





 Sviluppare una meccanica per Gdr

Articolo pubblicato il 14/10/2009
Autore: RAIZINGHER


SVILUPPARE UNA MECCANICA PER GDR
La produzione di un gioco di ruolo, sia esso online, live o cartaceo, prima o poi giunge ad un nodo chiave, nodo di cui molto spesso si sottovaluta la complessità e l’importanza. Questo nodo è la meccanica.
Sul panorama ruolistico, non solo online, oggi le meccaniche di gioco sono un numero impressionante: dai “core” come il D20System o Savage Worlds, meccaniche nude e crude adattabili a qualunque ambientazione che vi si costruisca attorno, a meccaniche specifiche per le singole produzioni. Talvolta le meccaniche vengono prese, sviscerate e riapplicate ad altri metodi o altre ambientazioni, senza considerare che spesso non sono adatte ad essere trasposte in maniera diretta su un altro livello tecnologico, o essere passate dal cartaceo alla chat, perché sono meccaniche sviluppate ad hoc per un certo tipo o metodo di gioco.
Ma come si sviluppa una meccanica? Qual è il processo da seguire per ottenere una meccanica di gioco funzionale? Proviamo ad affrontare qualche punto. Parleremo dello sviluppo di una meccanica generica, non necessariamente in ambito di pbc.
Innanzitutto sfatiamo un mito: tutti i giochi di ruolo hanno una meccanica. Anche i pbc full diceless, che pure non usano dadi e parametri, hanno una meccanica. Lanciare un incantesimo in tre azioni, o alternare il turno di attacco a quello di difesa, è una meccanica. Una meccanica, di fatto, è un insieme di regole metodologiche che vengono seguite per giocare, quindi non sperate di poter saltare questa parte dello sviluppo se anche nella vostra land lascerete decidere tutto alle descrizioni, perché se non mettete nero su bianco “come funziona”, prima o poi avrete delle noie.
Per prima cosa, è necessario decidere il peso che la meccanica deve avere nel gioco. Più la meccanica viene utilizzata spesso, durante il gioco, e più è decisivo il suo utilizzo, e maggiore è l’attenzione che deve essere posta allo sviluppo e al testing della stessa. Una meccanica parametrica che dia una linea guida al gioco può e dovrebbe contenere poche caratteristiche e una semplice descrizione, poiché non avrebbe senso sviluppare una meccanica complessa in un metodo di gioco che poi non la sfrutta a pieno; invece una meccanica che ricalchi la complessità di un D20System et similia deve essere sviluppata, testata e descritta accuratamente.

TEST
Nei pbc può capitare che vengano omessi, se si parla di una meccanica diceless, ma generalmente i test, o prove, sono il fulcro principale della meccanica. Tramite i test che vengono fatti la meccanica viene chiamata in causa, ed è tramite i test che si vede se una meccanica funziona, quanto funziona e come funziona.
Innanzitutto si deve decidere con cosa i test vengono eseguiti, se con i dadi, con un random generico, con un mazzo di carte e così via. In questa fase è fondamentale mantenere coerenza: volendo si possono usare tutti i tipi di dado conosciuti, dal d3 al d100, ma il concetto base dev’essere lo stesso. Se per testare un’abilità ad un certo livello si usa un tipo di dado, si deve usare lo stesso tipo di dado per testare un’altra abilità che sia allo stesso livello. I giocatori devono trovare il filo conduttore che li guida attraverso i test, se la meccanica varia da una situazione all’altra solo perché cambia il parametro di riferimento finiscono per trovarsi in difficoltà, e la giocabilità ne risente.
I master non dovrebbero abusare dei test. Spesso è sufficiente valutare l’atteggiamento che i giocatori fanno tenere ai personaggi, o l’azione che scrivono nel caso delle chat, e i parametri che sono in scheda per prendere una decisione sull’esito di un tentativo. Un test vero e proprio va tentato nei casi in cui il successo o l’insuccesso possono seriamente cambiare la situazione per il personaggio, possono evitargli o meno un danno o possono comunque avere conseguenze importanti ai fini del gioco. In questi casi è consigliabile un test, sia perché si va a premiare, nel caso, il corretto utilizzo delle capacità del personaggio da parte del giocatore, sia perché il solo master non sempre può arrogarsi il diritto di scegliere bianco o nero.

PARAMETRI
Generalmente una meccanica prevede parametri di almeno due tipi, che sono chiamate comunemente caratteristiche e abilità. Le prime rappresentano i tratti specifici, principalmente fisici e mentali, del personaggio, mentre le seconde coprono le sue attitudini e la sua conoscenza teorica e pratica. Indipendentemente da come si vogliano chiamare o raggruppare, un test ha bisogno di parametri di riferimento. Non ha senso improntare un test senza parametri d’appoggio, come se fosse un testa o croce, perché a quel punto entra in gioco solo la fortuna del giocatore che lo esegue. Un test effettuato su un parametro alto deve concettualmente avere più possibilità di riuscita, in assenza di modificatori, di un test effettuato su un parametro basso. Un buon giocatore di ruolo deve anche saper gestire i punti forti e i punti deboli del proprio personaggio, e la meccanica deve dargli modo di farlo.
I parametri devono essere facilmente identificabili tramite nome e descrizione, e devono essere il più coerenti possibile a livello di “specializzazione”. Avere un solo parametro mentale come Intelligenza e poi avere quattro parametri fisici come Forza, Destrezza, Resistenza e Velocità è indice di squilibrio nella meccanica. Specializzare eccessivamente può portare ad una lista di parametri troppo lunga e dispersiva: nel caso è consigliabile sempre sviluppare per esteso, e pian piano accorpare generalizzando, non il contrario. È più facile accorpare due abilità in una che le riunisca piuttosto che specializzarne una preesistente in due nuove.
Per finire, la lista dei parametri deve permettere una rapida e immediata applicabilità dei test. Se ai giocatori vengono dei dubbi su quale parametro devono testare significa che la lista è confusa o non copre tutte le possibili situazioni di gioco. Ricordiamoci che anche se il gioco che si sta sviluppando vuole essere principalmente d’azione, non è impossibile che i personaggi possano trovarsi in situazioni totalmente diverse: in un gioco di ruolo può accadere di tutto.

MODIFICATORI
Un passaggio molto sottovalutato dello sviluppo della parte dei test sono i modificatori. Bonus e malus sono una parte importante dei test, poiché rispecchiano l’impatto che una situazione specifica può avere negli esiti di un tentativo. Sparare con una pistola stando in groppa ad un cavallo al galoppo può essere molto più difficile che sparare stando fermi sui propri piedi.
Una buona meccanica deve prevedere modificatori positivi e negativi. Generalmente, i modificatori sono in prevalenza negativi, questo perché è molto più facile che una situazione arrechi un disagio al personaggio piuttosto che un vantaggio. L’errore principale degli sviluppatori e dei master è quello di non definire coerentemente i modificatori ma, spesso, di inventarli ed applicarli sul momento. Questo può accadere, perché ci sarà sempre qualche situazione non contemplata dalla meccanica, ma non deve essere la regola. Innanzitutto perché si rischia, anche involontariamente, di applicare due pesi e due misure, applicando modificatori diversi a due personaggi diversi che si trovano nella medesima situazione, solo per essersi dimenticati di che modificatore si era usato in precedenza. Secondariamente perché i modificatori non sono semplici +1 e -1 da buttare in mezzo, ma devono essere calibrati sul test. Se la somma di modificatori negativi rende impossibile che si possa ottenere un successo, quando in realtà a senso logico un margine di successo esiste, significa che i modificatori sono stati calibrati male.

COMBATTIMENTO, MAGIA E ALTRE SITUAZIONI SPECIALI
Le situazioni di combattimento, così come l’uso della magia o di abilità speciali, sono spesso caratterizzate in maniera più approfondita rispetto alle altre parti della meccanica. Questo perché mentre sull’effettivo esito di un tentativo è possibile comunque, da parte del master, spaziare e aggiustare in base alle situazioni e ai risultati del test, generalmente in queste situazioni si cerca di mantenere rigidità e si deve tenere conto di parametri secondari come ad esempio la salute o l’affaticamento.
Il sistema di combattimento è la parte che più indica la qualità di una meccanica. Se il combattimento si svolge in maniera fluida, con due, massimo tre lanci per ogni passaggio, ed è facile per i giocatori gestire la salute del proprio personaggio senza rallentare il ritmo, significa che la meccanica è ben studiata. A volte voler essere troppo specifici o troppo puntigliosi sulle ferite, sulle locazioni dei danni, sulle protezioni e così via porta solo a creare una meccanica farraginosa e complessa che fa perdere un sacco di tempo a master e personaggi per trovare il bandolo della matassa. Generalmente, un singolo attacco dovrebbe prevedere due, massimo massimo tre lanci per i casi straordinari, la valutazione nel caso di una o due tabelle di dimensioni contenute e un rapido aggiornamento della scheda del personaggio: di fatto non più di un minuto di calcolo congiunto tra giocatori e master nei casi più complessi. Se la meccanica richiede più tempo (eccezion fatta per i primi tempi, quando si deve ancora entrare nel meccanismo) significa che probabilmente è stata mal calibrata. Ricordiamoci che i parametri mal si abbracciano al realismo a tutti i costi, specialmente quando si deve mantenere un certo ritmo. In questi casi è molto più conveniente dividere il compito tra il risultato della meccanica e la libertà decisionale del master. Una volta che la meccanica ti dice quanto danno hai subito, ad esempio, lascia che sia il master, coerentemente con la situazione, a decidere dove piazzarlo.
Inoltre, dobbiamo ricordarci che un attacco di combattimento è a tutti gli effetti un test fatto sul parametro che rappresenta l’abilità in quel tipo di attacco. Se il “tiro per colpire” viene gestito in maniera diversa da uno qualunque dei test sugli altri parametri vuol dire che la meccanica non è omogenea, e può creare delle difficoltà ai giocatori, oltre che causare un peso diverso di certi parametri rispetto ad altri.
Gli stessi concetti base del combattimento si applicano all’uso della magia o di tecniche speciali, che di fatto sono situazioni particolari, su cui si deve fare un’attenzione e un rigore maggiore.
Chiariamo un concetto: meccanica e ambientazione vanno a braccetto, e la complessità del sistema di combattimento deve integrarsi con l’ambientazione utilizzata. Se l’ambientazione prevede che i personaggi siano esperti di arti marziali, approfondire il sistema di combattimento, prevedendo tecniche, posture, metodi di attacchi e di difesa non è un aumento gratuito della complessità, ma è una logica caratterizzazione del sistema di combattimento. In un’ambientazione western, se il combattimento non prevede un metodo logico e funzionale per i duelli forse significa che la meccanica manca di qualcosa di importante nell’ottica specifica dell’ambientazione. In fase di testing è necessario approfondire con criterio queste situazioni particolari, valutando l’utilità o meno di inserirle e il metodo migliore per farlo.

TESTING E STRESSING
Non basta scrivere una meccanica per farla funzionare: va testata. Sotto questo aspetto progettare una meccanica è come programmare un codice: potete scriverlo ed giurare di averlo scritto bene, ma ne avrete la certezza solo quando lo farete girare.
Il testing dev’essere approfondito, possibilmente con l’ausilio di uno o più compagni. Attenzione particolare va posta ai modificatori, in modo che risultino calibrati correttamente, e al combattimento, che deve essere equilibrato e deve rispondere alle aspettative, specialmente per quanto riguarda la perdita di salute. Molto spesso ci si rende conto che la meccanica ha delle falle importanti soltanto quando si va a testarla, e poi sembra incredibile come ci sia potuto sfuggire un dettaglio tanto importante.
Un modo valido per testare la meccanica è quello che personalmente chiamo stressing: “mettere sotto stress” la meccanica, creando casi particolari e inscenando situazioni di gioco che comprendano più modificatori e variabili possibili e più casi ai limiti del regolamento. Lo stressing permette facilmente di vedere se i modificatori si integrano bene tra loro, come varia la probabilità di riuscita di un test nei casi più svantaggiosi (o vantaggiosi), come variano i risultati del combattimento in base all’uso di armi specifiche o di posizioni particolari dei personaggi. Capita spesso che i limiti di una meccanica vengano fuori durante il gioco, e ci si trovi a fronteggiare situazioni tutt’altro che rare ma che non si erano comunque previste: quando questo accade, significa che la meccanica non è stata stressata abbastanza in fase di sviluppo.

APPLICAZIONI AI PBC
Seguono una serie di semplici e diretti consigli relativi alla progettazione e all’applicazione di meccaniche nell’ambito del gdr pbc.

Siate coerenti col vostro metodo di gioco. Se non volete usare i test, perché non vi piace che sia un dado a decidere, non create una meccanica bestiale: bastano pochi parametri di riferimento, per evitare il “powerplay autorizzato”, ossia quella situazione in cui un giocatore è in grado di descrivere bene tutto ad un livello tale che tutto quello che il personaggio tenta riesce, senza che voi abbiate niente in mano per impedirglielo. Il fatto che un giocatore sappia descrivere bene non significa che sia un buon giocatore: se facciamo far bene una cosa al nostro personaggio quando in realtà non è sensato che sappia farla, stiamo sbagliando. Un sistema parametrico senza l’uso dei dadi consente di dare una linea guida ai giocatori, in modo che se un personaggio ha un basso valore di destrezza, ad esempio, diventi chiaro che se il giocatore gli fa fare un meraviglioso tiro con l’arco sta uscendo dalla coerenza interpretativa del suo pg.

Create set di abilità coerenti ed equilibrate. Anche se la vostra land prevede molti scontri, creare solo abilità di combattimento squilibra fortemente le caratterizzazioni e la crescita dei personaggi verso il combattimento. Cercate di mantenere coerenza per dare anche ai giocatori che preferiscono un ruolo sociale un modo per caratterizzare i loro personaggi.

Non strafate. Non serve creare una meccanica che comprenda una miriade di tabelle e di casi particolari. Non state giocando ad un cartaceo, quindi non potete mettere il mondo in pausa per andare a cercare la tabella giusta. Fate in modo che la meccanica copra tutti quei casi che possono sensatamente capitare più che una volta al mese, costruite una linea generale di interpretazione dei casi più rari e fatevi una ragione del fatto che riuscire a prevedere ogni possibile situazione è impossibile, e integrare la meccanica per coprirla ogni volta che se ne scopre una nuova è insensato. La vostra meccanica deve riuscire a coprire il più possibile le situazioni di gioco, con e senza master, ma accettate il fatto che prima o poi capiterà un caso che non avete previsto. Meglio poi che prima.

Lavorate con senso critico. Non tutti gli standard e le consuetudini usate nelle altre land sono parimenti applicabili alla vostra. Il concetto di tre azioni per l’uso di un’arma a distanza, per esempio, o per lanciare un incantesimo, è nato nelle land fantasy, dove la differenza di velocità tra un colpo di spada o di mazza rispetto al lancio di una freccia fa si che diventi necessario rallentare il secondo per mantenere un rapporto coerente di rapidità d’esecuzione. In una land moderna, pretendere tre azioni per usare un’arma da fuoco è semplicemente ridicolo, perché a premere un grilletto, volendo, ci vuole molto meno che a tirare una coltellata. Non accettate passivamente i metodi altrui, sviscerateli e valutate la loro adattabilità al vostro contesto. E questo vale anche per le trasposizioni dirette di meccaniche da cartaceo sulla chat, visto che spesso è impossibile trasportare meccaniche cartacee su chat nella loro interezza senza che il ritmo di gioco ne risenta.

Costringete i vostri giocatori a costruire la scheda del personaggio. Troppo spesso i giocatori riempiono le schede dei pg a casaccio, o si tengono i valori predefiniti proposti dal sistema. Non mettete automaticamente i valori nei form di iscrizione, costringete i giocatori a inserirli manualmente. In un gioco di ruolo con una meccanica parametrica, avere i parametri tutti uguali significa non averne affatto, e ai fini della meccanica il personaggio non conterà assolutamente niente e non risponderà alle aspettative. I parametri devono rispecchiare le caratterizzazioni dei personaggi, e viceversa. Se proprio vedete che i giocatori mettono i dati a caso perché non sanno che personaggio fare, cambiate il metodo di iscrizione in modo da permettere loro di completare la scheda una volta registrati e entrati nella land.

Combattete l’ignoranza. Create (ma fatelo!) delle guide semplici ed immediate, fatele leggere a degli amici, magari con un po’ di esperienza, che vi sappiano dare un parere. La meccanica è fatta e spiegata bene se i giocatori sono in grado di capire almeno tre quarti dei concetti principali senza dover andare a chiedere ad un master o al gestore.

Fate in modo che i giocatori siano i primi a fare affidamento sulla meccanica. Fate fare i test in situazioni analoghe a tutti i personaggi, senza creare preferenze, non usate i test come punizione (hai fatto una cavolata? Adesso fai un test, così impari!) a meno che i giocatori non siano in malafede o facciano infilare i personaggi in veri e propri gineprai, chiarite i dubbi e spiegate perché avete applicato un modificatore e non un altro. I giocatori devono accettare la presenza della meccanica ed essere propensi ad usarla correttamente anche in assenza di un master.

Sfruttate la meccanica per alleggerire il ritmo del gioco quando serve. Per quanto possa piacere scrivere azioni lunghe e dettagliate, se alla fine è comunque un test che definisce l’esito del tentativo, non serve farcire le azioni di troppi dettagli. Le situazioni di combattimento specialmente devono essere gestite con fluidità, perché nel combattimento i ritmi di gioco rallentano, ci sono più test da fare, più cose da calcolare, e quindi è bene cercare di guadagnare tempo. La vostra qualità di giocatori non ne risentirà se darete la precedenza alla meccanica durante le situazioni che lo richiedono: è li per farvi da supporto, ma se non la sfruttate arrecate soltanto un disagio al gioco incorso.

Il successo sta nella plasmabilità. Una meccanica applicata alla lettera non funzionerà mai, perché prima o poi capiteranno situazioni in cui applicare esattamente le regole della meccanica castrerebbe il gioco. Un buon master è in grado di plasmare la meccanica alla situazione, non il contrario. Se una situazione non è contemplata, il master dev’essere rapido ad inventare un modificatore equilibrato, reinterpretare una regola, decidere superpartes come sbrogliare la faccenda. La meccanica dev’essere al servizio del gioco, non il contrario.

Spero che questa serie di appunti e di consigli possa risultare utile al vostro compito di sviluppatori. Non sono regole fisse o scritte, sono soltanto una serie di intuizioni e esperienze personali raccolti in anni di hobbistico sviluppo e gioco nell’ambiente del gdr più o meno tradizionale.

Raiz.




Lascia un commento all'articolo


 Commenti degli Utenti
ghennadi
72

MASCHIO  7 ottobre


Roma

   

15/10/2009 - :)

Articolo molto interessante sull´approccio teorico alla ideazione di una meccanica di gioco, e anche dal punto di vista "pratico" vedo espressi diversi buoni consigli.

A mio parere il primo consiglio da dare a un aspirante gestore, perlomeno a uno che sia intenzionato a spremersi un po´ le meningi sulla progettazione e non solo a installare un pacchetto OS dopo averne modificato l´aspetto grafico, é di ricordarsi quali sono i limiti dell´ambiente di gioco primario: la webchat.

A meno che l´aspirante gestore non abbia intenzione di fare un pesante uso di automatismi posti fuori dal sistema della chat (costruendo quindi un web-game più che un gdr online basato su chat) avrà a che fare con TRE limiti pesantissimi, che rischiano di vanificare ore e ore di neuroni consumati sulla stesura delle regole.

Limite 1: L´assenza del TEMPO
I videogame operano in tempo reale. Il cartaceo usa i turni e ha diversi sistemi per rapportare il tempo reale al tempo di gioco. La webchat no. Già gli spostamenti da una chat a un´altra frullano alla base qualunque velleità di "realismo". La "turnazione", ossia la convenzione dell´aspettare l´invio del testo altrui, é una approssimazione molto limitante, per non dire ridicola.
Si fa l´esempio dell´assurdità delle tre azioni per sparare, ma non é che scoccare in tre azioni sia meno assurdo, quando in tre azioni é comunissimo che un giocatore normale entri in una taverna, passi tra i tavoli palpeggiando culi di cameriere e si sieda al bancone per ordinare da bere... con eventuale tragico corredo di iridi ghiaccee che scorrono per il locale come se fossero biglie sul pavimento.

Limite 2: L´assenza dello SPAZIO
Una chat può essere una stanza come una piazza, Un vicolo stretto e lungo come una foresta o un passo montano. In uno spazio aperto o chiuso possono esserci ostacoli, il terreno può essere piatto o in pendenza, liscio o accidentato. Scoccare o sparare contro qualcuno che può nascondersi dietro un muro o avendo la protezione di un tronco d´albero non é lo stesso che scoccare/sparare contro qualcuno che sta in mezzo a una piana desertica. Anche qui il realismo va a farsi benedire, soprattutto nel caso degli automatismi: se non c´é un "arbitro" in grado di ponderare questo tipo di elementi (affidati al descrittivo dei giocatori) avere un ottimo sistema di skill e parametri trattati automaticamente può generare situazioni assurde e irrealistiche ancora peggiori di quelle determinate da un Master poco capace.

Limite 3: La necessità di ABRITRATO UMANO
Se non si é capito ho poca o quasi nessuna fiducia nei confronti del ricorso eccessivo ad automatismi in un gdr basato su webchat, per i due limiti evidenziati sopra, che se non vengono correttamente considerati al momento della stesura delle regole e della meccanica di gioco possono vanificare (ossia rendere inefficace, irrealistico e in ultima analisi non divertente per i giocatori) qualunque sistema "teoricamente" perfetto. Perchè scarica o sui giocatori o sui master l´incombenza di determinare gli esiti in situazioni che nessun automatismo da webchat é in grado di affrontare. Nel caso dipenda dai giocatori, tutto é subordinato alla loro buona volontà, correttezza e conoscenza delle regole e capacità di applicarle autonomamente; nel caso dei master, oltre a quanto già vale per i giocatori, tutto é subordinato alla loro disponibilità ad essere presenti nel momento in cui si gioca, il che significa condannarli ai lavori forzati il più delle volte.

Il rischio del collasso della meccanica di gioco e/o della condanna ai lavori forzati per i master, paradossalmente, a mio parere aumenta, anziché diminuire, in proporzione diretta (se non esponenziale) alla fiducia che l´aspirante gestore (mal)ripone nell´elaborazione di una meccanica di gioco dettagliata e tendente al realismo, soprattutto laddove l´aspirante gestore si dimentica che sta ideando una webchat e non un MMORPG o un videogioco di strategia in tempo reale e si illuda che possano essere gli automatismi a regolare quelle situazioni che statisticamente generano il maggior numero di polemiche e maldipancia nelle tipiche giocate di gdr online.

Spero di non essere stato distruttivo :P




master_a
lex

MASCHIO


Roma

   

14/10/2009 - Articolo molto interessante.


Io provengo dalla scuola dei cartacei, e devo dire che andando anche a piegare regolamenti già esistenti o creando anche da zero (mi è successo...) un GDR cartaceo, sebbene si abbia la collaborazione di amici o ci si accordi in maniera talvolta anche informale (cosa non fattibile per un GDR on line PbC), una meccanica va comunque studiata.


Sono appunti che possono essere molto utili. Io lo vedo come un problema "da ingegneri", del tipo: ho un problema (es: regolare come si spara con una certa arma in un certo contesto...), devo trovare la soluzione...


Le strade, come è stato scritto, sono tante. L´ideale è saper equilibrare. Il d20system non è oro colato. Funziona bene, ma si può fare anche meglio.


Per il PbC credo non vada benissimo, anzi... citerò solo un esempio: ho provato ad iscrivermi ad un GDR Western, ultimamente... Ma poi quando ho visto la miriade di modificatori (simili alla tabellina di D&D) da calcolare per estrarre una pistola e sparare, mi è preso un mezzo colpo. Questo per dire che un sistema mutuato sul d20System non è sempre ottimo.


Tuttavia, + ci si scosta, + la cosa è difficile. Non scordiamoci poi che il PbC campa sulle descrizioni praticamente da sempre... Per cui io direi che come al solito:



"In medio stat virtus". L´invito migliore che possiamo trarre da questi utilissimi appunti è, nella mia personalissima opinione, di mediare.

Per i + arditi, invece, di sfruttare queste note per creare qualcosa di innovativo. ^^




Grazie quindi per l´articolo. ^^




raizingh
er

MASCHIO  17 dicembre


Siena

   

14/10/2009 - Approfitto del commento di Herduk per fare una precisazione: l´articolo non è inteso per l´ambiente specifico del pbc, ma per una impostazione mentale di sviluppo generica sul gioco di ruolo, sia esso online o cartaceo, quindi rimane volutamente generico. Di per se sviluppare una meccanica non è eccessivamente complesso, lo diventa renderla coerente con i metodi e l´ambito neiquali si intende applicarla.

Per quanto riguarda l´immediato del pbc si, indubbiamente è qualcosa che va affrontato eoni prima di scaricarsi gdrcd XD e soprattutto ne va tenuto fortemente conto in fase di realizzazione tecnica e documentale.




herduk
MASCHIO

Bergamo

   

14/10/2009 - Bello l´articolo.
Un po´ generico e "ampio", ma fornisce un´ottima panoramica su cosa si debba fare MOLTO PRIMA di scaricarsi GDRCD :)

Personalmente, se non si ha già un´ambientazione rigida e definita, consiglierei l´uso di una meccanica già collaudata e abbastanza (es. D20 System) che si adatta al tipo di ambientazione per poi lavorare a raffinare l´ambientazione.

Costruire una meccanica SERIA e COERENTE è quanto di più difficile ci sia, molto più che la programmazione.




Pagine commenti:


 Altri Articoli


Twitter ed i Gdr
Il fenomeno del momento: Twitter! Come possono sfruttarlo i gdr-online?




Luca Ferrara
Intervista al creatore di Star Trek Genesis...




Cucina Medievale
Articolo sulla cucina medievale. Riscopri gli antichi sapori...








Top 

P.Iva IT09033551004
GDR-online.com è pubblicato sotto licenza "Creative Commons Attribuzione-Non commerciale-Non opere derivate 3.0" 2004/2012

Utilità: Scrivici - Note Legali - Partner - Pubblicità