Benvenuti alla settimana dedicata a sfruttare, in cui analizzeremo la meccanica preferita di Silumgar e dei suoi seguaci. Durante le settimane di anteprima, vi ho accennato il modo in cui abbiamo creato la meccanica sfruttare e vi ho parlato rapidamente di come abbiamo lavorato su una meccanica simile durante la progettazione di Assalto. Penso di aver dato l'idea che le due progettazioni fossero collegate, che avessimo creato la meccanica durante la progettazione di Assalto, che non l'avessimo utilizzata e poi che l'avessimo tirata fuori da un cassetto quando stavamo lavorando su Draghi di Tarkir. La verità è che la creazione delle due meccaniche ha avuto inizio da idee completamente diverse e ha portato alla stessa conclusione per caso. Questo fenomeno è noto come progettazione parallela e si presenta abbastanza spesso. Nell'articolo di oggi vi spiegherò questo fenomeno e vi presenterò i diversi tipi esistenti e gli insegnamenti che possiamo trarne.

La progettazione parallela può funzionare in alcuni modi diversi. Vediamoli insieme.

Progettazione parallela 1: stessi elementi di partenza

Allora, chi ha progettato la meccanica accelerare? Io. E anche Sam Stoddard. Abbiamo lavorato insieme? No. L'abbiamo creata in modo indipendente, nello stesso momento. Vi spiego subito. Nella progettazione, il lead designer di un'espansione assegna delle attività al team, da svolgere nel tempo libero e portare alla riunione successiva (o in un altro momento). Il lead designer dà di solito informazioni molto specifiche su ciò che desidera. A volte, a seconda della fase della progettazione in cui ci si trova, può richiedere di colmare una specifica carenza; altre volte, può essere una richiesta di idee in una determinata area.

Goblin Laceracalcagni | Illustrazione di Jesper Ejsing

Per la prima attività relativa a Draghi di Tarkir, Mark Gottlieb, che era il lead designer, voleva che lavorassimo sulle meccaniche delle fazioni. Vi ricordo che la progettazione di Draghi di Tarkir ha avuto inizio dopo quattro mesi dall'inizio della progettazione di I Khan di Tarkir, molti mesi prima dell'inizio della progettazione di Riforgiare il Destino, quindi eravamo alla ricerca di cinque meccaniche e una variante di metamorfosi. Riforgiare il Destino ne avrebbe successivamente utilizzate due (accelerare e sostenere sono state le due meccaniche scelte). La prima attività che ci è stata assegnata è stata relativa a queste meccaniche. I Khan di Tarkir aveva le sue meccaniche di fazione e il nostro compito era di fare in modo che le altre meccaniche fossero in armonia con le loro versioni di Khan.

Io e Sam abbiamo lavorato con lo stesso obiettivo: realizzare una meccanica per la fazione rosso-nera (tendente al rosso) che interagisse in modo corretto con incursione. Non è quindi sorprendente che abbiamo proposto la stessa meccanica. Abbiamo ricevuto gli stessi parametri e abbiamo seguito una logica simile. Ciò non significa che due progettisti non possano spesso proporre due progettazioni diverse partendo dagli stessi elementi iniziali, ma il fatto che a volte realizziamo delle progettazioni parallele è prevedibile.

Questo è il tipo più frequente di progettazione parallela. Il nostro lavoro prevede una grande collaborazione, quindi trascorriamo molto tempo in gruppo per cercare di comprendere ciò che funziona e ciò che non funziona. Simili processi mentali di progettazione corrispondono al pensiero del gruppo, grazie alla costante interazione con gli altri membri del gruppo.

La mia storia preferita per questo tipo di progettazione parallela riguarda Innistrad. Ho dato inizio ai lavori chiedendo al mio team di progettare le carte partendo dall'idea generale di un'ambientazione horror. Per la prima riunione non avevo neanche dato alcun elemento, per lasciarli liberi di progettare partendo dalle loro idee. Ci siamo seduti al tavolo per la prima riunione e abbiamo analizzato ciò che ognuno aveva ideato. Ognuno aveva progettato un Paletto di Legno e gli aveva dato lo stesso effetto; si trattava di un equipaggiamento che aumentava la forza della creatura equipaggiata e uccideva i vampiri a cui avrebbe inflitto danno. Quando qualcuno mi chiede chi abbia progettato il Paletto di Legno, la mia risposta è "tutti".

Progettazione parallela 2: stessa idea, diversi momenti

All'uscita di Worldwake, ho scritto un articolo sulla progettazione delle singole carte ("Worldwake Me Up Before You Go-Go"), nel quale ho descritto la progettazione di una carta chiamata Minaccia Bestiale.

Molti anni prima, influenzato da una carta chiamata Cono di Fiamme (dell'espansione Cavalcavento), ho inventato una carta chiamata Cono di Creature, che metteva in gioco delle pedine 1/1, 2/2 e 3/3. Ho cercato di aggiungerla a diverse espansioni, ma i tre tipi diversi di pedina creavano confusione e l'idea è stata sempre scartata. Ho anche parlato pubblicamente di questa carta nel 2002, in un articolo che avevo scritto sulle pedine ("Tokens of My Affection").

La carta è stata finalmente stampata in Worldwake (aiutata dal fatto che ora aggiungiamo le carte pedina nelle buste), quindi ho spiegato nell'articolo che avevo cercato per anni di proporre questa carta e alla fine mi ero arreso. Ho immaginato che Ken Nagle, lead designer dell'espansione, avesse trovato il mio gioiello e avesse approvato il Cono di Creature. Dopo aver consegnato l'articolo, ho ricevuto un messaggio dal mio editore, a quel tempo Kelly Digges (che ha lavorato per l'editing, poi nel team creativo e, come attività extra, ha la supervisione della rubrica "Uncharted Realms"). Kelly mi ha detto che avevo commesso un errore. Lui aveva progettato la carta. Non aveva mai sentito parlare del Cono di Creature. Sembra proprio che Kelly abbia seguito un percorso di progettazione simile al mio. Lo ha semplicemente seguito dieci anni dopo, senza aver idea della mia creazione.

Questa situazione avviene costantemente. Capita così spesso che a volte vedo una carta in un file, la riconosco come una carta che avevo disegnato tanto tempo prima e chiedo "L'ho fatta io questa?". Ho anche un altro problema: a volte mi capita di proporre l'idea di una carta e qualcun altro mi risponde che l'abbiamo già realizzata, mi dice il nome della carta e l'espansione in cui è contenuta e, dopo un attimo, rispondo "Hai ragione, l'avevo già progettata".

Un altro esempio classico di questo tipo di progettazione è la meccanica miracolo dell'espansione Ritorno di Avacyn. Durante la progettazione di Tempesta (in cui ho avuto il ruolo di design lead per la prima volta), mi era venuta l'idea di carte che generano un effetto quando vengono pescate, ma non ero riuscito a trovare un modo per farle funzionare correttamente e ho abbandonato l'idea. Quindici anni dopo, Brian Tinsman, senza sapere dei miei tentativi durante la progettazione di Tempesta, ha cercato di realizzare la stessa meccanica, ma ha trovato anche un modo per farla funzionare (dopo quindici anni, è stato anche aiutato dal fatto che Magic permette di avere idee più creative per le carte a bordo nero).

La chiave per questo tipo di progettazione parallela è che alcune idee sono così valide che diversi progettisti le propongono in diversi momenti.

Progettazione parallela 3: processi ripetuti

I Jeskai avevano bisogno di una meccanica per I Khan di Tarkir. Come al solito, abbiamo definito vari parametri. Il blu e il rosso sono i colori con la più elevata percentuale di magie, quindi sarebbe stata più opportuna una meccanica relativa a istantanei e stregonerie. I Jeskai avevano lo stile dei monaci Shaolin, quindi volevamo che avessero qualche abilità che permettesse loro di combattere. Jeskai era la fazione dell'astuzia, quindi volevamo una meccanica elegante. Considerando tutti questi vincoli, ho dato il mio suggerimento per la nuova meccanica.

La meccanica avrebbe fornito +1/+1 alle creature ogni volta che fosse stata giocata una magia. Troppo forte. Allora solo per gli istantanei e le stregonerie. Troppo debole. Allora per tutte le magie non creatura? Per un certo periodo, abbiamo anche provato con una meccanica legata alle magie non creatura per I Khan di Tarkir e alle magie creatura per Draghi di Tarkir. Abbiamo armeggiato con la meccanica finché non siamo giunti a prodezza.

Saggio Jeskai | Illustrazione di Craig J Spearing

Poi, un giorno, Jon Loucks stava effettuando le attività di playtest per I Khan di Tarkir e ha detto che era contento che avessimo scelto la sua meccanica galvanizzare che aveva proposto nella seconda Grande Ricerca di Progettisti. Il fatto interessante è stato che non eravamo partiti dalla sua meccanica, ma ci eravamo giunti attraverso le nostre evoluzioni. Abbiamo infatti compiuto un passo in più, risolvendo anche un problema che avevo notato quando avevo dovuto giudicare la meccanica durante la Seconda Grande Ricerca di Progettisti.

Il motivo per cui questa categoria è diversa dalla precedente è il fatto che almeno una delle persone che realizzano le carte nuove hanno avuto un'interazione con le carte vecchie, subendo quindi un'influenza, anche se a livello inconscio. Per esempio, io ho lavorato su così tante espansioni da non riuscire a ricordarmi ogni dettaglio ma, quando lavoro su meccaniche o carte singole, mi accorgo spesso che sto creando in un'area che abbiamo già esplorato.

In molti modi, questa categoria è meno parallela delle altre, perché si basa su una correlazione, ma porta a un tipo di situazioni molto simili a quelle della categoria precedente, in cui si scopre che le nuove idee sono in realtà basate su qualcosa che avevamo già provato in precedenza.

Progettazione parallela 4: approcci diversi

Dato che siamo nella settimana dedicata alla meccanica sfruttare, mi sembra opportuno parlarvi di come è stata creata. Permettetemi di raccontarvi delle due diverse progettazioni che hanno portato a sfruttare. La prima è stata realizzata nel 2000, quando lavoravamo su Assalto. La progettazione del blocco Assalto aveva avuto molti cambiamenti di direzione (un giorno scriverò un articolo a riguardo; per ora è disponibile un podcast che potete ascoltare qui), ma l'aspetto importante per oggi è la mia insistenza per avere una tematica tribale.

Questa situazione si è presentata prima che la tematica tribale fosse consolidata, quindi stavo proponendo una novità che pensavo sarebbe piaciuta ai giocatori. Una parte importante dell'idea era la creazione di un numero sufficiente di carte e meccaniche per renderla rilevante. Ho iniziato esplorando tutte le possibilità più ovvie. Ho realizzato i signori per le creature, carte che bersagliavano solo alcuni tipi di creatura e carte che avevano bisogno di un numero minimo di creature di un determinato tipo per funzionare. Ho realizzato un sacco di progetti validi, ma ho scoperto che gli effetti che stavo generando erano un po' troppo complessi.

Per esempio, le magie contavano il numero di creature di un determinato tipo, potevano bersagliare solo quel tipo di creatura o tendevano ad avere un testo molto lungo. Non vedevo l'ora di trovare una meccanica che mi permettesse di realizzare effetti semplici, ma in un modo che mettesse in evidenza una tematica tribale. A un certo punto ho provato anche con un approccio insolito, una carta split di cui una metà fosse un istantaneo o una stregoneria e l'altra metà una creatura di uno dei tipi previsti. L'idea era di avere uno zombie o una magia di tipo zombie. C'era solo un piccolo problema: le carte split non prevedono di diventare permanenti.

Zombie Scacciavita | Illustrazione di Min Yum

Quindi ho fatto ciò che faccio sempre quando le regole impediscono a un'idea di funzionare: cerco un modo diverso per arrivare allo stesso risultato. Ciò che volevo era una carta che potesse essere una creatura oppure una magia. Potevo realizzare una magia modale e uno dei modi avrebbe creato una pedina, ma questa scelta avrebbe ridotto la possibilità di progettazione della meccanica. Ho poi valutato la possibilità di carte creatura su cui avrei potuto spendere mana e scartarle per ottenere un effetto. In questo spazio di progettazione avevamo realizzato la meccanica incanalare in Liberatori di Kamigawa e non sono stato soddisfatto dei risultati.

Poi ho avuto un'illuminazione: e se, al momento dell'entrata sul campo di battaglia, avessi permesso di sacrificare la creatura per ottenere un effetto? In questo modo avrei ottenuto l'idea di magia modale che volevo, ma non avevo ancora finito di elaborare l'idea, dato che volevo realizzare una meccanica modale. E se, invece di sacrificare quella creatura, avessi potuto sacrificare una creatura di uno specifico tipo? Eccone un esempio: (con il testo aggiornato ai modelli di oggi)

Plague-filled Zombie

3B

Creatura — Zombie

3/3

Quando NOMECARTA entra nel campo di battaglia, puoi sacrificare uno zombie. Se lo fai, una creatura bersaglio non nera prende -4/-4 fino alla fine del turno.

L'idea era che questa meccanica permettesse di trasformare qualsiasi Zombie in una rimozione. Abbiamo anche provato con l'idea di poter sacrificare un numero qualsiasi di Zombie e ottenere l'effetto per ognuno di essi. Che fine ha fatto questa meccanica? Assalto non ne ha avuto bisogno. Ogni progettazione realizza sempre più di quanto sia necessario, poi le idee vengono approvate o scartate in base alle necessità dell'espansione.

Facciamo ora un salto in avanti, dal 2000 al 2013. Draghi di Tarkir aveva bisogno di una meccanica blu-nera che interagisse in modo corretto con esumare. Per raggiungere questo risultato, ci siamo concentrati su meccaniche che mettessero carte nel cimitero. Abbiamo valutato gli effetti di sia scartare che auto-macinare, ma alla fine abbiamo preferito una forma di sacrificio. La domanda fondamentale era "Perché questa meccanica richiede di sacrificare le creature?". Abbiamo valutato diverse risposte, ma la più convincente era il fatto che generava un effetto simile a una magia. Sacrificare una creatura è un grande costo ma, se si ottiene un effetto di valore paragonabile alla carta, ne può valere la pena.

Alla fine, abbiamo aggiunto la meccanica alle creature, in modo da poter aver sempre qualcosa da sacrificare. Abbiamo realizzato le creature un po' più grandi, in modo da spingere a sacrificare un'altra creatura. Abbiamo anche progettato creature più piccole con effetti positivi legati al sacrificio, di cui la maggior parte è sotto forma di abilità innescata dalla loro morte. Diversamente dal caso di Assalto, questa volta la meccanica è stata stampata.

Quest'ultima categoria è la più bizzarra, dato che crea risultati simili da diversi elementi di partenza. Come mostra l'esempio di sfruttare, ognuno è giunto alla stessa meccanica, ma attraverso due percorsi molto diversi. Assalto ha ottenuto la meccanica attraverso una necessità tribale. Draghi di Tarkir ci è giunto attraverso una necessità di una meccanica che prevedesse il sacrificio. Le direzioni sono state letteralmente opposte. Assalto diceva "Possiamo anche realizzarla come creatura", mentre Draghi di Tarkir diceva "Possiamo anche realizzarla come magia".

Queste progettazioni disparate si presentano più spesso di quanto si possa pensare. Penso che avvengano per il fatto che alcuni concetti semplicemente funzionano bene nella struttura del gioco di Magic e, indipendentemente da come ci si avvicina, si finisce con esplorare lo stesso spazio di progettazione. O, in altre parole, quando iniziamo a esplorare determinati aspetti della progettazione, indipendentemente dal punto di partenza, siamo spinti in un'unica direzione.

Quali sono le conclusioni?

I motivi per cui è importante comprendere la progettazione parallela sono:

1) La progettazione è la ricerca dell'eleganza più che della novità

Più lavoro su progettazioni di Magic, più comprendo che un buon lavoro non porta alla scoperta di ciò che non è ancora stato realizzato, ma a determinare dove si trovi la parte elegante del gioco. La mia metafora preferita è con la scultura. La progettazione prevede di trovarsi davanti dei giganteschi blocchi di pietra. Il nostro lavoro è di trovare la statua che si nasconde dentro la pietra. Non creiamo la statua, la scopriamo. Dopo ventidue anni, l'esperienza nella progettazione di Magic mi ha portato a capire che è un'attività più di comprensione e di ritmo del gioco che di scoperta di territori inesplorati.

2) Per creare il futuro, bisogna comprendere il passato

Una delle risorse più grandi che posso offrire al team di progettazione è data dai miei venti anni di esperienza. È raro che ci avventuriamo in una nuova area di progettazione a cui non ci siamo mai neanche avvicinati prima. A volte abbiamo anche passato tanto tempo a valutare un filone di progettazione che poi non abbiamo utilizzato. Spesso, quando esploriamo un'area, chiedo al mio team di effettuare una ricerca nel materiale prodotto quando abbiamo affrontato la stessa tematica. Magic ha una storia molto lunga, che offre uno strumento molto utile che sarebbe sciocco non utilizzare.

3) La chiave per trovare le risposte è la definizione dei parametri

La progettazione parallela sottolinea l'idea che una valida progettazione porterà nella stessa direzione. Ciò significa che la chiave per trovare le risposte di progettazione è nella comprensione di ciò di cui abbiamo bisogno. Adottare questo approccio ci ha permesso di cambiare in modo in cui risolviamo i problemi. Invece di passare subito alla fase di analisi delle possibili soluzioni, dedichiamo più tempo alla definizione dei parametri.

4) La qualità di un'idea dipende dall'ambiente in cui viene applicata

Un altro importante insegnamento della progettazione parallela è che le idee non sono isolate. Per poterle valutare, è necessario tenere in considerazione l'ambiente in cui verrebbero applicate. Esistono meccaniche che possono brillare in un blocco ed essere pessime in un altro. Il contesto è importante. La sinergia è importante. Lo stile è importante. Una meccanica non viene aggiunta a un'espansione solo perché è una meccanica favolosa, ma perché è una meccanica favolosa in quella espansione.

5) Non esiste un solo modo di progettare

L'ultimo insegnamento della progettazione parallela è che il percorso verso un'idea brillante non è univoco. Per ogni idea, esistono diversi modi per arrivarci. La chiave è non concentrarsi troppo sul punto di partenza, bensì sul punto di arrivo.

Percorsi paralleli giungono alla stessa fine

Mi auguro che l'articolo di oggi vi abbia permesso di scoprire un nuovo aspetto della progettazione, che è molto meno visibile del prodotto finale. Come sempre, sono molto interessato alle vostre opinioni sull'articolo di oggi. Potete mandarmi una mail o contattarmi attraverso uno dei miei social media (Twitter, Tumblr, Google+ e Instagram). 

Ci rivediamo la prossima settimana, quando tornerò proprio all'inizio.

Nel frattempo, che possiate scoprire la progettazione parallela nella vostra vita.

"Drive to Work #218— Le carte di Innistrad, parte 3"

Questa è la terza parte di una serie di cinque sulla progettazione delle singole carte di Innistrad.

"Drive to Work #219—Verde/Bianco"

Questa è la quinta parte di una serie di dieci sulle coppie di colori, sulle loro filosofie e sulle sovrapposizioni delle meccaniche. Oggi vi parlo dell'ultima coppia di colori alleati: Verde e Bianco.