Il contributo dello sviluppo alla progettazione

Posted in Latest Developments on 13 Marzo 2015

By Sam Stoddard

Sam Stoddard came to Wizards of the Coast as an intern in May 2012. He is currently a game designer working on final design and development for Magic: The Gathering.

L'anno scorso ho chiesto a Shawn Main di scrivere un articolo per Latest Developments nel quale vi ha raccontato il ruolo del rappresentante della progettazione nei team di sviluppo. Questo processo esiste in entrambe le direzioni; anche i team di progettazione includono un membro del team di sviluppo. Avere persone con diverse esperienze e punti di forza, in grado di condividere le conoscenze tra un team e l'altro, è uno dei motivi per cui le nostre espansioni sono costantemente di elevata qualità. Nel caso di Draghi di Tarkir, io ho avuto il ruolo di rappresentante dello sviluppo nel team di progettazione e ho potuto quindi anche trasferire i concetti dalla progettazione allo sviluppo.

Uno dei motivi per cui abbiamo membri di ogni team per ogni espansione è per fare in modo che nessun team venga colto di sorpresa. Sebbene sia relativamente semplice tenere traccia di ciò che avviene per ogni espansione nel multiverso, è necessario osservare l'espansione per scoprire le novità. Considerando sia team di progettazione che il team di sviluppo, i lavori in corso sono relativi a circa sei espansioni, quindi è difficile tenere un occhio su tutto.

Occhio delle Streghe | Illustrazione di Daniel Ljunggren

Il team di sviluppo ha bisogno di frequenti aggiornamenti da parte di uno dei suoi membri, per essere a conoscenza dei piani relativi alle espansioni future, in modo da poterli supportare; ancora più importante, il team di sviluppo non vuole inavvertitamente bloccare la creazione di un'espansione a causa della stampa di carte che renderebbero l'espansione non utilizzabile una volta giunta alla fase di sviluppo. In maniera simile, il membro del team di progettazione ha come obiettivi generare molte delle nuove carte e garantire che lo sviluppo non entri in conflitto con i piani del team di progettazione.

L'approccio mentale della progettazione

Il ruolo dello sviluppatore nel team di progettazione non è di insegnare al team di progettazione ciò che deve o non deve fare; non è neanche quello di bloccare tutto ciò che non sembra andare per il verso giusto. Il ruolo è di lavorare come progettista e di avere intuizioni che aiutino il processo creativo, mantenendo il controllo sulle idee più strampalate, o almeno di trovare modi in cui quelle idee potrebbero essere trasferite su carte giocabili in Constructed. Una meccanica può apparire incredibilmente divertente e interessante ma, se lo sviluppo non riesce a darle il giusto equilibrio, risulta difficile realizzare carte che le persone desiderino avere. Non voglio dire che lo sviluppo non possa realizzare carte speciali anche se non sono eccessivamente forti; il fatto è che non riteniamo che ci siano tanti progetti che sono speciali sulla carta e che funzionano altrettanto bene nella realtà.

Uno degli aspetti più difficili del lavoro in un team di progettazione è, per me, cercare di mettere da parte il mio desiderio di risolvere i problemi continuamente. Una parte della progettazione è la ricerca di nuove idee; inevitabilmente, molte idee non funzionano. Ho voluto spesso saltare le attività di playtest, per passare immediatamente alla fase di ricerca di qualcosa di diverso. Il fatto è che i fallimenti sono parte del processo; individuare quali parti di una meccanica scartata sono effettivamente divertenti è uno dei modi utilizzati dal team di progettazione per realizzare meccaniche divertenti. Un'attività di playtest spesso non porta ad alcuna meccanica utilizzabile, ma porta il team un passo più vicino alla scoperta del tipo di possibilità esistente per esprimere lo stile dell'espansione.

La strada giusta

Sebbene sia importante non trascorrere troppo tempo cercando di dire altri progettisti ciò che sarà o non sarà accettato in fase di sviluppo, il ruolo dello sviluppatore è di guidare la creazione nella direzione giusta e garantire che le meccaniche e le carte ideate dal team di progettazione siano effettivamente utilizzabili dal team di sviluppo.

Per esempio, quando il team di progettazione ha avuto l'idea delle carte a doppia faccia, Tom LaPille aveva il ruolo di rappresentante del team di sviluppo. Realizzare quelle carte nel modo corretto sarebbe stato sicuramente difficile, ma non sono state aggiunte altre difficoltà per lo sviluppo. Quel tipo di carta avrebbe generato difficoltà ad altre persone nella catena di produzione, come il team creativo (che avrebbe dovuto ottenere più illustrazioni) e tutte le persone il cui lavoro sarebbe stato di comporre graficamente la carta per la stampa. Lui ha ritenuto che la meccanica avrebbe potuto funzionare e ha fatto del suo meglio per rendere le carte abbastanza divertenti e forti da convincere della scelta le altre persone del team di Ricerca e Sviluppo di Magic.

Una meccanica che non è stata approvata per Draghi di Tarkir è stata "Auramorfosi". Uno dei concetti originali del blocco Tarkir prevedeva di assegnare metamorfosi alle creature in Khan, alle terre in Destino e alle non creature in Draghi. La prima versione che abbiamo provato era Auramorfosi, che avrebbe avuto l'obiettivo di evidenziare alcune sinergie con il blocco Theros basato sugli incantesimi.

Essendo il rappresentante del team di sviluppo, ho immediatamente fatto notare alcuni problemi che vedevo in questa idea. Non erano dovuti alla ricerca di equilibrio delle carte, ma difetti maggiori nella struttura del gioco, che il team di sviluppo non avrebbe potuto risolvere facilmente. Poiché (in quel momento) metamorfosi di Riforgiare il Destino non era prevista per le creature, non sarebbe stato possibile girare a faccia in su una creatura a faccia in giù nel formato Limited con Draghi e avere una creatura più grande, quindi un 2/3 avrebbe potuto bloccare qualsiasi creatura a faccia in giù senza correre rischi (tranne in caso di magie di potenziamento); in questo modo sarebbe andato perso ciò che per me era il divertimento principale della meccanica metamorfosi.

Abbiamo cercato di risolvere velocemente il problema, realizzando Aure con strane abilità innescate (come un costo ridotto per essere girate a faccia in su, nel caso non venissero bloccate, per finire a incantare l'avversario oppure essere Aure dall'effetto negativo, che potevano andare a incantare la creatura bloccante quando venivano girate a faccia in su), ma abbiamo compreso che l'intera idea non avrebbe avuto successo e ci siamo dedicati ad altre varianti di metamorfosi per le creature.

Non penso che non sarebbero giunti alla stessa conclusione anche senza uno sviluppatore nel team, ma mi auguro che lo sviluppatore sia sempre in grado di individuare questi aspetti negativi più velocemente e spingere il team di progettazione verso aree più semplici per permettere allo sviluppo di creare carte sia divertenti che forti. Più tempo ha a disposizione il team di progettazione per far funzionare meccaniche come questa, più tempo ha anche il team di sviluppo per renderle nella loro versione finale... situazione che penso porti ad avere espansioni più divertenti rispetto a quando è il team di sviluppo a realizzare molte carte.

L'importanza del costo

Uno degli obiettivi della progettazione è di effettuare attività di playtest con livelli di forza equilibrati. Ciò non significa che ogni carta deve avere lo stesso livello di forza, ma che vogliamo garantire che gli elementi che l'espansione deve avere siano abbastanza forti da non aver partite Limited decise da semplici creature volanti e rimozioni. In progettazione, vogliamo che le rimozioni siano abbastanza forti da impedire a una creatura con un'Aura di dominare il campo di battaglia, ma non così forti da impedire giocate interessanti. Se la forza principale della progettazione risiede nell'interazione tra carte e meccaniche, allora possiamo facilmente determinare se sarà divertente. Se non aggiungono carte forti, non c'è nessun problema da risolvere; se le aggiungono, vale la pena dedicare un po' di tempo per determinare come farle funzionare al meglio in sviluppo.

Sorvegliante Demoniaco | Illustrazione di Chris Rahn

Durante le riunioni di progettazione, lo sviluppatore ha il compito di suggerire i costi di lancio o i valori di forza e costo delle carte. Possiamo sempre cambiare le carte all'ultimo momento, ma chiedere a tutti di aggiungere un mana a una carta durante le attività di playtest non è l'ideale. Per questo motivo, lo sviluppatore nel team di progettazione deve analizzare il file frequentemente e verificare i costi delle carte per fare in modo che le attività di playtest si svolgano in modo più corretto possibile.

In generale, la maggior parte dei progettisti è in grado di determinare quanto mana dovrebbe costare la grande maggioranza delle carte. Un 4/4 non comune con volare e legame vitale? Sarei sorpreso di vedere un progettista mettere un costo diverso da sei mana. D'altra parte, esistono molte nuove meccaniche di cui è molto più difficile stimare il costo ed è molto utile avere una persona con maggiore esperienza nella messa a punto dei livelli di forza disponibile a dare la prima occhiata.

Uno degli obiettivi del supporto durante tutta la fase di progettazione è ottenere un prodotto che (in teoria) è pronto per la stampa. Il file non deve essere definitivo, ma sarebbe un peccato avere carte e meccaniche a cui il team di progettazione tiene molto che funzionano solo perché il loro costo è eccessivamente ridotto. Risulta normale che alle persone piacciano gli elementi più potenti. Realizzare una delle meccaniche di un'espansione più potente delle altre porterebbe a una reazione del tipo "questa meccanica era proprio divertente, ma le altre erano noiose". Questa risposta è naturale; gli elementi che funzionano attirano l'attenzione delle persone, mentre quelli che non funzionano sono deludenti. Il compito dello sviluppatore che entra a far parte del team di progettazione è di cercare di riportare tutti gli elementi a livelli di forza più simili possibile, in modo che noi possiamo determinare ciò che sarà divertente una volta raggiunto il giusto equilibrio, non solo nella realizzazione iniziale.

Contemporaneamente, è importante che il rappresentante dello sviluppo garantisca che l'espansione funzioni bene nel mondo reale e non semplicemente da sola, durante le prove iniziali. Ogni meccanica può funzionare, se le viene costruita un'espansione intorno, ma lo sviluppo ha bisogno che funzioni non solo nel formato Limited con una sola espansione, ma anche in Standard. Le meccaniche di rinforzo come le Aure possono funzionare bene in Limited, se le rimozioni sono molto deboli; a meno che il piano non sia di avere un formato Standard senza rimozioni potenti, questo tipo di meccaniche non avrà un grande impatto. Più il rappresentante dello sviluppo è in grado di guidare il team di progettazione verso aree che non richiedono grandi sconvolgimenti successivi, più rifinita sarà l'espansione finale e più idee della progettazione potranno essere mantenute.

Questo è tutto per questa settimana. Ci rivediamo la prossima settimana, con l'edizione degli M-Files di Draghi di Tarkir.

Alla prossima

Sam (@samstod)

Latest Latest Developments Articles

LATEST DEVELOPMENTS

29 Aprile 2016

I giorni del Futuro Futuro: Ombre su Innistrad by, Sam Stoddard

Ciao a tutti e bentornati a un'altra edizione dei Giorni del Futuro Futuro, la sezione di Latest Developments nella quale vi presento alcune delle liste dei mazzi della nostra Lega del Fu...

Learn More

LATEST DEVELOPMENTS

22 Aprile 2016

Le domande più frequenti della Lega del Futuro Futuro by, Sam Stoddard

Circa una volta per espansione, mi piace pubblicare alcune delle liste dei mazzi della nostra Lega del Futuro Futuro, che portano spesso a molte domande. Perché avete inserito questa cart...

Learn More

Articoli

Articoli

Latest Developments Archive

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

See All