Gioco di squadra

Posted in Making Magic on 30 Novembre 2015

By Mark Rosewater

Working in R&D since '95, Mark became Magic head designer in '03. His hobbies: spending time with family, writing about Magic in all mediums, and creating short bios.

Benvenuti nella settimana dedicata ai team. Questo è il periodo dell'anno in cui si svolge la World Magic Cup, evento nel quale le squadre provenienti da tantissime nazioni di tutto il mondo si ritrovano per il ai più alto livello di competizione di Magic e per determinare quale nazione si fregerà del titolo di campione del Mondo. Mentre tutti gli altri parleranno di questo evento, io ho deciso di utilizzare questo tema in un modo leggermente diverso e di parlarvi di come le nostre varie "squadre" contribuiscono alla creazione di Magic.

Uno per tutti...

Iniziamo da un aspetto molto importante di come Magic viene progettato (e anche sviluppato). Magic è il risultato di un lavoro di collaborazione. Nessun singolo individuo crea il gioco; è un gruppo di persone a creare il gioco. Ogni volta che scrivo articoli di anteprima, inizio sempre presentandovi il team di progettazione. Quello è un gruppo di persone che ha lavorato insieme per creare la progettazione iniziale per un anno per le espansioni grandi e almeno quattro mesi per le espansioni piccole. Il lavoro viene poi passato a un team completamente diverso, che si occupa dello sviluppo ed è un secondo insieme di occhi che continua a lavorarci a lungo. Nel frattempo, un team di persone dedicate alla storia si impegna per garantire che l'espansione abbia una storia che viene trasmessa non solo attraverso le carte dell'espansione ma anche utilizzando più mezzi di comunicazione possibile. Un altro team si occupa delle illustrazioni, per fare in modo che il mondo abbia un aspetto coeso. Poi abbiamo un team di editing, un team di produzione, un team logistico, un team di vendita, vari team digitali, un team di gioco organizzato e molti altri team che mi sarò dimenticato di aggiungere a questa frase. Il messaggio che vi voglio trasmettere è che, per trasformare Magic da un foglio di carta vuoto alle carte stampate, vari team di persone devono riunirsi e collaborare per raggiungere un obiettivo comune.

L'articolo di oggi è relativo a uno di questi team: il team di progettazione, perché è la parte del processo di cui io vi scrivo ogni settimana. Ricordatevi però che ciò di cui vi parlo oggi è solo uno dei tanti elementi del meccanismo che permette di creare Magic.

Lo spirito di squadra

L'intero processo ha inizio ancor prima di avere un vero team di progettazione. Esistono infatti uno o due team che lavorano prima degli altri. Quando abbiamo l'idea di quali mondi vorremmo visitare in futuro, i dirigenti del team di Ricerca e Sviluppo di Magic si riuniscono e costruiscono una proposta, di solito definita nei dettagli dal team artistico e dal team narrativo, che descrive a grandi linee la direzione che la storia prenderà. In gruppo esaminiamo i molti potenziali mondi per avere una sensazione di quale luogo potrebbe essere un buon supporto alla storia che vogliamo raccontare e, preso a sé, sarebbe un mondo di Magic affascinante da visitare. A volte ritorniamo su un mondo già visitato e a volte ci avventuriamo in un mondo completamente nuovo che contiene gli elementi che stiamo cercando.

Le idee vengono messe insieme, in modo da offrirci una sensazione di quali aspetti individuali siano i più adatti. A volte decidiamo di realizzare dei mini-team per esplorare i diversi mondi, per garantire che ognuno abbia un sufficiente potenziale per la progettazione, la storia e le illustrazioni. A volte il gruppo del team di Ricerca e Sviluppo si trova d'accordo sui mondi più adatti e crea immediatamente una struttura di base. Questo è ciò a cui mi riferisco quando vi parlo del "piano da sette anni". Tendiamo a cercare sempre di costruire un'idea di massima di ciò che realizzeremo nei sette anni successivi, in modo da poter correttamente mettere a punto le nostre attività per ottenere il massimo del potenziale. Non pianifichiamo sette anni insieme, ma pianifichiamo vari anni che vengono aggiunti a ciò che abbiamo già pianificato.

Una volta ottenuta un'idea di massima dei prossimi mondi, i team di progettazione, narrativo e artistico realizzano una descrizione introduttiva del mondo, in modo che i responsabili possano avere un'idea di dove prevediamo di andare. Questo piano futuro non è però obbligatorio. Possono esserci avvenimenti che ci spingono a cambiare i nostri programmi; il futuro può sempre essere modificato, se la situazione è diversa da quella che avevamo previsto.

Morforama | Illustrazione di Fred Fields

A un certo punto però la scelta dei mondi viene confermata. Il primo lavoro su un'espansione, dietro il lavoro di preparazione richiesto per l'approvazione iniziale, viene svolto da quello che chiamiamo il team di costruzione preliminare dei mondi. Questa attività avviene prima della progettazione preliminare, perché abbiamo compreso che la progettazione è in grado di ottenere migliori risultati se il mondo e la storia sono già stati definiti in precedenza. Il team di costruzione preliminare dei mondi comprende sempre almeno un progettista, in modo che le conseguenze di progettazione vengano prese in considerazione durante la realizzazione del mondo.

Dopo il termine del lavoro del team di costruzione preliminare dei mondi, l'attività passa al team di progettazione preliminare. Proprio come si ha sempre un progettista nel team di costruzione preliminare dei mondi, si ha sempre un membro del team creativo (quasi sempre del team narrativo) nel team di progettazione preliminare. Il team di progettazione preliminare è composto da un gruppo di persone che si dedicano alla progettazione preliminare per mesi e ci permettono di avere molte informazioni sull'espansione da realizzare. L'obiettivo principale della progettazione preliminare è aiutare la progettazione a iniziare a comprendere l'ampiezza dei problemi che devono essere risolti. Il team crea anche molte meccaniche, per offrire al team di progettazione del materiale da cui partire.

Infine, il lavoro passa al team di progettazione. I team di progettazione vengono scelti da Mark Gottlieb (il manager dei team di progettazione) e da me. Ogni team di progettazione delle espansioni legali nel formato Standard deve possedere alcune componenti:

Un lead designer—Iniziamo sempre dalla scelta del lead designer. Questa persona viene scelta per prima perché vogliamo che sia coinvolta nella progettazione preliminare e vogliamo avere la sua opinione sui membri del team che vorrebbe avere con sé.

Un "valido vice"—Le persone possono ammalarsi o andare in vacanza o a volte non essere disponibili perché si stanno occupando di situazioni di emergenza. Vogliamo quindi che ogni team abbia un progettista in grado di porsi alla guida nel caso in cui il lead designer non sia più disponibile.

Un rappresentante del team di sviluppo—Ogni team di progettazione ha bisogno di uno sviluppatore, il quale ha due funzioni principali. Primo, ha la responsabilità di verificare che l'espansione che stiamo realizzando possa essere successivamente sviluppata (in collaborazione con l'head developer, Erik Lauer, e con il lead developer di quella specifica espansione). Secondo, ha la responsabilità di determinare i costi delle carte.

Un rappresentante del team creativo—Ogni team di progettazione ha bisogno di un membro del team creativo, il quale ha due funzioni principali. Primo, ha il ruolo di connessione tra i team creativi (storia e illustrazioni), comunica ciò che il team narrativo e il team artistico hanno realizzato e li informa del lavoro del team di progettazione. Secondo, ha la responsabilità dei nomi nel file delle carte, per garantire che trasmettano in modo corretto gli elementi narrativi dell'espansione.

Una persona nuova—Un altro aspetto importante per i team di progettazione è avere persone che non facciano di solito parte di un team di progettazione. Per i progettisti è molto facile rimanere sulle stesse idee e quindi una persona con un punto di vista diverso può aiutare a trovare nuovi modi per affrontare i problemi.

Un archivista—Questo ruolo è stato stabilito perché io ero molto impegnato e stavo cercando di ridurre il mio carico; tenere ordine nel file delle carte (tra cui inserire tutte le carte e applicare tutti gli aggiornamenti) necessitava di molto tempo. Ho scoperto che questo ruolo aveva un effetto secondario positivo: era un'ottima occasione per apprendere. Per imparare come un'espansione viene progettata, non c'è modo migliore rispetto ad avere la responsabilità di tenere traccia di ogni cambiamento. Questo ruolo esiste di solito solo per i team di progettazione di cui ho il ruolo di lead. Per le espansioni di cui ho il ruolo di lead insieme a un'altra persona, questa persona ha il ruolo di "valido vice" e di archivista.

Io—Essendo head designer, uno dei miei compiti è tenere sotto osservazione ogni team di progettazione. Tentativi ed errori hanno dimostrato che il modo più facile per svolgere questo ruolo è di far parte di tutti i team di progettazione. È interessante notare che seguire le modifiche al file richiede più tempo rispetto a partecipare solamente alle riunioni. Per esigenze di tempo, nel caso delle espansioni piccole, partecipo solo a metà delle riunioni.

Se contiamo tutti i ruoli, il totale è sei (il ruolo di archivista esiste solo quando sono io il lead designer). Ciò significa che ogni team di progettazione ha un minimo di sei persone e un massimo di sette (solo un paio di team hanno avuto sette persone).

Radunare la Legione | Illustrazione di Eric Deschamps

Le dinamiche del team

Allora, a cosa serve avere un team per la progettazione? Perché non sarebbe più efficace avere una persona dedicata? Posso darvi una risposta da un punto di vista che quasi nessun altro ha, perché ho progettato un'espansione da solo. Tanto tempo fa, mi è stata assegnata la progettazione di Destino di Urza e, poiché in quel periodo eravamo a corto di persone, ho chiesto se avrei potuto occuparmi da solo della progettazione. Mi è stato concesso il permesso e ho composto l'unico "team di progettazione da una sola persona" delle espansioni legali nel formato Standard nella storia del gioco. Quell'esperienza mi ha offerto un'interessante conoscenza del valore di un team di progettazione.

1) Si hanno più idee

Sei o sette persone sono semplicemente in grado di produrre più di una persona sola. Il volume di materiale prodotto ha una maggiore quantità e una maggiore qualità.

2) Si hanno idee diverse

Una sola persona affronta tutti i problemi in modo simile. Il pensiero di una sola persona è unico e influenza il tipo di idee. Un team ha diversi individui, ognuno con il suo punto di vista; ciò significa che, quando si ha un problema da risolvere, un team ha maggiori probabilità di risolverlo, in vari modi.

3) Ognuno può prendere ispirazione dagli altri

Le migliori creazioni non vengono realizzate in un colpo solo. Al contrario, una prima idea può dare l'ispirazione per una seconda, la quale porta a una terza e così via. I migliori progetti sono il risultato di una lunga messa a punto, che ha origine dalle idee che nascono e dai continui miglioramenti. Un maggior numero di menti e un maggior numero di punti di vista portano semplicemente a un numero maggiore di possibilità di combinazioni. Una persona può dare origine a un'idea, ma ciò tende ad avvenire più lentamente rispetto che in un gruppo.

4) Si ha il vantaggio delle diverse competenze

Avete potuto notare che, quando ho elencato i ruoli dei membri del team di progettazione, alcuni di loro hanno la responsabilità di mantenere la connessione tra il team di progettazione e gli altri team. Queste diverse competenze si sono rivelate di elevato valore per il processo di progettazione, perché, nel momento in cui nasce un'idea, offrono informazioni immediate sugli eventuali problemi relativi allo sviluppo o agli elementi narrativi. Contemporaneamente, si hanno sempre membri del team di progettazione che collaborano con altri team di progettazione, in modo da ottenere informazioni su ciò che avviene nelle espansioni precedenti o successive. Possiamo ottenere informazioni su ciò che succede nel team di Ricerca e Sviluppo che potrebbe avere un impatto sulla progettazione. Tutto ciò avviene durante la progettazione e permette di adattarci, immediatamente, in base alle nuove informazioni.

5) Si ha il vantaggio dei punti di forza dei diversi progettisti

Questa è una conseguenza del punto precedente. Proprio come i diversi membri del team di progettazione hanno diverse conoscenze, hanno anche diversi punti di forza. Con un intero team di progettazione abbiamo la possibilità di assegnare i compiti ai membri più adatti per i compiti specifici.

6) Si hanno dinamiche diverse

Quando ripenso alla progettazione di Destino di Urza, il mio ricordo è sempre di uno schermo di un computer e di un foglio di carta. Dovevo realizzare la progettazione e la mia attenzione era sempre sulla ricerca di una soluzione a un problema. Le riunioni dei team di progettazione hanno un funzionamento diverso. Certo, ci riuniamo per progettare un'espansione, ma c'è una giocosità che non è possibile quando si progetta da soli. Scherziamo, ci prendiamo in giro e ridiamo insieme. Esiste una frivolezza in quelle riunioni che può crearsi solo quando persone simili si ritrovano. Ciò ha un impatto profondo sul lavoro, perché rende l'intera esperienza più divertente. La progettazione è un compito mentale e lo stato mentale dei partecipanti ha una grande influenza sulla qualità del lavoro prodotto.

Radunare la Banda | Illustrazione di Igor Kieryluk

7) L'attività procede anche in assenza di una o più persone

Durante la progettazione di Destino di Urza ci sono stati dei momenti in cui altri argomenti hanno attirato la mia attenzione. In quelle situazioni, ho dovuto interrompere le attività di progettazione dell'espansione perché l'intero "team di progettazione" era impegnato. Con un vero team di progettazione, il team può continuare a lavorare anche quando uno o più membri non sono disponibili. Infatti, anche quando è assente il lead designer, il team può ricevere istruzioni sulle attività da portare avanti in sua assenza (vi ricordo anche che abbiamo un "valido vice" preposto a gestire le attività proprio in questi casi).

8) Si hanno più occhi in grado di scoprire gli errori

Uno degli aspetti più difficili quando si lavora da soli è il fatto di sapere ciò che si intende, anche se non corrisponde a ciò che si scrive. È molto facile per un singolo compiere errori che non vengono scoperti proprio perché si è troppo vicini alla decisione. Un team più ampio permette invece di avere molti occhi, la maggior parte dei quali non dà per scontato di sapere ciò che intendiamo e deve invece leggere le nostre parole.

Nel complesso, i team portano a vantaggi, ma si presentano anche alcune difficoltà create proprio dai team:

1) I membri del team possono essere in disaccordo tra loro

Non mi ricordo alcun litigio durante la progettazione di Destino di Urza. Non posso dire lo stesso per nessun altro team di progettazione a cui ho partecipato. La presenza di più persone porta occasionalmente a differenze di opinioni. A volte anche a discussioni accese tra i membri del team. Nella mia mente ciò è in realtà un valore aggiunto, poiché questi disaccordi portano spesso a nuove scoperte. Ho però assistito a (e anche partecipato a) un numero tale di discussioni accese che comprendo che un team possa essere portato fuori strada in modi non possibili nel caso di singoli individui.

2) Le dinamiche del team portano a volte a compromessi insoddisfacenti

Una parte del lavoro in team è identificare un modo per rendere tutti i membri del team soddisfatti della progettazione; se non si fa attenzione, la situazione può a volte degenerare fino a un punto in cui nessuno è insoddisfatto ma neanche davvero soddisfatto. I compromessi possono spesso portare a scoperte valide, ma altre volte possono forzare decisioni che nessun individuo avrebbe compiuto.

3) Si hanno più perdite di tempo

Lo stesso ambiente che può portare a momenti di divertimento può a volte essere causa di lunghi momenti di mancanza di produzione. Una singola persona sa che il compito è di sua responsabilità, mentre è più facile che un gruppo non prenda la giusta responsabilità.

Il funzionamento del team

Dopo avervi parlato dei vantaggi e degli svantaggi di avere un team di progettazione, vorrei parlarvi delle dinamiche di come funziona esattamente un team di progettazione. Per fare ciò, vi descriverò alcuni tipi di riunioni di progettazione e vi spiegherò ciò che succede.

La riunione delle discussioni di gruppo

Questo è un tipo di riunione che avviene nella fase iniziale della progettazione. La chiave di questo tipo di riunione è il fatto che il lead designer presenta un argomento di discussione e i membri del team forniscono le loro idee. Vi faccio un esempio da una progettazione del passato. Nella prima riunione della progettazione di Innistrad abbiamo parlato di tutti gli elementi horror che avremmo preso in considerazione. Abbiamo riempito un'intera lavagna con tutti gli elementi dei diversi tipi di mostri che ci immaginavamo di trovare, i tipi di luoghi più adatti e gli oggetti che immaginavamo potessero esistere. Una volta terminato il nostro elenco, abbiamo parlato dei tipi di carte su cui avremmo potuto inserire ogni elemento.

Rito della Furia Tempestosa | Illustrazione di Svetlin Velinov

La riunione della creazione delle teorie

Le riunioni della progettazione sono spesso molto pratiche, ma a volte capita di prendere un'idea e di trattarla a fondo. Questo tipo di riunione avviene spesso quando abbiamo un'idea ma non abbiamo ancora determinato come utilizzarla al meglio.

La riunione della progettazione delle carte

In alcune riunioni prendiamo un'area nella quale vogliamo realizzare delle carte e le progettiamo. L'attenzione potrebbe essere su una meccanica, una determinata serie di spazi vuoti nel file, un ciclo, una progettazione dall'idea ai dettagli, ecc. Le progettazioni durante le riunioni sono utili per alcuni motivi. Primo, permettono al team di collaborare e di realizzare alcune carte molto belle. Per esempio, Incatenato alle Rocce e Salvataggio dall'Ade di Theros, due delle carte con contenuto narrativo migliore dell'intera espansione, sono state il risultato di una progettazione durante una riunione. Secondo, queste riunioni permettono al lead designer di scegliere carte specifiche da realizzare e di garantire che vengano aggiunte al file. Le riunioni di progettazione avvengono spesso appena prima delle riunioni di playtest, per riempire gli spazi vuoti.

La riunione di playtest

Vi dico spesso che la progettazione di Magic è un processo iterativo. Una parte fondamentale di questo processo è giocare con le carte e ricevere opinioni, in modo da poter comprendere ciò che funziona e ciò che non funziona nelle carte che abbiamo progettato. Le attività di playtest si svolgono durante tutta la fase di progettazione, ma diventano più frequenti verso la fine; le iterazioni diventano sempre più brevi. Le riunioni di playtest sono le riunioni in cui è più probabile che invitiamo degli ospiti esterni, perché avere delle impressioni nuove dell'espansione ha un elevato valore.

Le riunioni di playtest sono suddivise in due categorie: Limited e Constructed. Le sessioni di playtest Limited iniziano con il formato Sealed Deck nei primi periodi e poi diventano in formato Draft. Iniziamo dal Sealed perché, nelle prime riunioni di playtest, gli archetipi non sono ancora stati determinati... quindi draftare risulterebbe troppo fastidioso. Una volta che l'espansione è adatta al draft, cambiamo formato perché la maggior parte dei tornei Limited con l'espansione sarà sotto forma di draft.

Nelle riunioni di playtest Constructed, ogni membro del team di progettazione deve costruire un mazzo, principalmente con carte dell'espansione (o del blocco, se è un'espansione piccola) insieme a un gruppo di carte generiche che possiamo utilizzare per il playtest. I membri del team di progettazione giocano tra loro con i loro mazzi. Le attività di playtest Constructed sono importanti perché ci aiutano a comprendere se abbiamo tutti gli elementi per permettere ai giocatori di costruire i loro mazzi con le tematiche dell'espansione.

La riunione di controllo del file

Queste sono le riunioni in cui il lead designer presenta tutto o parte del file di progettazione e l'intero team lo analizza carta dopo carta. Le riunioni di controllo del file tendono a essere molto tattiche, in quanto il lead designer cerca di affrontare determinate problematiche. Queste riunioni sono spesso relative a specifici sottoinsiemi che richiedono maggiore attenzione. Le riunioni di analisi del file si svolgono spesso dopo le attività di playtest.

La riunione di analisi

Questo tipo di riunioni è simile a quello di controllo del file, tranne per il fatto che non si ha alcun file da analizzare. Queste riunioni servono al team di progettazione per valutare alcuni aspetti dell'espansione. Un tipo molto frequente di riunione di analisi avviene subito dopo le sessioni di playtest, in cui ogni singola persona offre le proprie opinioni sul playtest.

La riunione di risoluzione dei problemi

Questo è un tipo di riunione della progettazione in cui comprendiamo che qualcosa non sta funzionando e ci impegniamo per risolvere il problema. Noi usiamo l'espressione "breaking bones" per questo tipo di riunioni, perché prima di poter aggiustare qualcosa, è necessario prima romperlo per poi ricostruirlo.

Spaccaossa | Illustrazione di Darrell Riche

La riunione di presentazione

Questo è un tipo di riunione in cui il lead designer chiede a qualcuno (spesso esterno al team, ma non sempre) di preparare una presentazione su un argomento che è importante per la progettazione. Un valido esempio può essere una presentazione da parte della persona responsabile della storia, che ci descrive esattamente ciò che succede e quali sono i personaggi fondamentali. Dopo una novità nei concetti, è frequente che si abbia una riunione in cui Jeremy Jarvis (head art director di Magic) descrive al team il modo in cui apparirà il mondo. Questa riunione è importante perché spesso dà l'ispirazione alla progettazione per realizzare elementi che rappresentano aspetti del mondo che non esistono ancora sulle carte.

La riunione di analisi dei compiti assegnati

Alcune progettazioni vengono realizzate durante le riunioni, ma la maggior parte avviene al di fuori delle riunioni, di solito come "compito a casa". In questi casi, ogni membro del team stampa i propri progetti e ne offre una copia a ogni altro membro del team. La riunione inizia con la condivisione dei propri compiti e poi si ha una fase di analisi. Molto spesso, se l'assegnazione del compito era specifica, analizziamo ogni spazio vuoto e ciò che ogni progettista ha realizzato. Si possono presentare tre situazioni. Una carta viene scelta per il file, più carte vengono combinate per ottenere una carta per il file oppure non viene accettata nessuna carta e il compito viene riassegnato.

La riunione di ricerca

A volte il lead designer ritiene che il team possa ottenere maggiori informazioni di prima mano su alcuni aspetti dell'espansione su cui sta lavorando. L'esempio più comune sarebbe giocare con una vecchia espansione a cui fa riferimento quella nuova. Per esempio, all'inizio del lavoro su Battaglia per Zendikar, abbiamo giocato con Zendikar e Worldwake e poi anche con Ascesa degli Eldrazi.

Permettetemi di terminare dicendo che molte delle nostre riunioni non sono esattamente parte di una di queste categorie, ma sono un ibrido di due o più categorie. Potremmo iniziare con la costruzione della teoria per poi passare alla progettazione delle carte. Potremmo iniziare con una presentazione, poi avere delle discussioni e poi un'analisi delle idee che sono state nominate.

... tutti per uno

Mi auguro che l'articolo di oggi vi abbia offerto un'idea migliore del perché utilizziamo un team per la progettazione di Magic e anche del modo in cui operiamo. Come sempre, sono molto interessato alle vostre opinioni. Potete mandarmi una mail o contattarmi attraverso uno dei miei social media (Twitter, Tumblr, Google+ e Instagram).

Ci rivediamo la prossima settimana, quando sarà di nuovo ora di un insieme di argomenti.

Nel frattempo, che possiate trovare il vostro team.


"Drive to Work #282—Le domande più frequenti"

Per lavoro, vengo intervistato molto spesso. In questo podcast vi racconto le domande che mi chiedono più frequentemente e le risposte che do o che non do.

"Drive to Work #283—20 anni dopo"

Il 30 ottobre ho festeggiato il mio ventesimo anniversario in Wizards of the Coast. In questo podcast vi racconto le differenze in Magic e in Wizards tra il giorno in cui ho iniziato a lavorare e oggi, 20 anni dopo.

Latest Making Magic Articles

MAKING MAGIC

18 Gennaio 2021

L'alba di un mondo vichingo, parte 2 by, Mark Rosewater

La scorsa settimana, ho iniziato a raccontarvi la storia della progettazione di Kaldheim. Ho impostato il racconto in modo da suddividerlo negli otto argomenti che abbiamo definito durant...

Learn More

MAKING MAGIC

11 Gennaio 2021

L'alba di un mondo vichingo, parte 1 by, Mark Rosewater

Benvenuti al mio primo articolo di anteprima di Kaldheim. Nell’articolo di oggi e nella seconda parte della prossima settimana vi racconterò la storia della progettazione e vi farò vedere...

Learn More

Articoli

Articoli

Making Magic Archive

Desideri maggiori informazioni? Esplora gli archivi e naviga tra migliaia di articoli su Magic a cura dei tuoi autori preferiti.

See All