Concetto ed esecuzione

Posted in Making Magic on 19 Ottobre 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 alla settimana dedicata a vacuità e all'essenza incolore, nella quale parleremo del concetto di incolore e della meccanica vacuità. Oggi potrei parlarvi di un sacco di argomenti, ma ho deciso di concentrarmi su un problema che è stato nominato molte volte sui miei social media. Perché Battaglia per Zendikar deve utilizzare vacuità? Non ha alcun effetto. Non esistono modi migliori rispetto a sprecare una parola chiave?

Per trattare questo problema, vi voglio parlare di una questione molto più ampia, utilizzando vacuità come esempio. La questione è la differenza tra i concetti di progettazione e l'esecuzione finale. In questa rubrica, io pongo l'attenzione sul modo in cui il team di progettazione mette in pratica le idee, sulle nostre ispirazioni e su come inseriamo le sinergie nelle nostre progettazioni. Un aspetto a cui dedico meno tempo è l'enorme lavoro che svolgiamo per trasformare un'idea in qualcosa di concreto. L'articolo di oggi è dedicato a questo problema, una enorme questione per la progettazione (e per lo sviluppo).

"Costruitela voi"

Immaginiamo di uscire e di chiedere alle prime 100 persone che incontriamo di disegnare la casa più bella che hanno in mente. Non di disegnare una casa già esistente, ma di utilizzare l'immaginazione per realizzare una casa che non è mai esistita. Poi portiamo questi disegni a un architetto e gli chiediamo la sua opinione. Quale pensate che potrebbe essere il suo primo commento? Molto probabilmente sarà che molti disegni hanno un ottimo aspetto, ma che non possono essere messi in pratica. Perché? Perché un edificio deve avere un'integrità strutturale; deve esistere qualcosa che lo regga in piedi. Quando si mettono insieme le idee, un edificio con la forma di una clessidra potrebbe sembrare bello, ma è possibile realizzarlo? Esiste un modo per realizzarlo, in modo che non crolli?

Ciò che voglio dire è che è facile proporre delle idee, ma non sempre possono essere messe in pratica. Vale lo stesso per la progettazione di Magic. Il fatto che io e i miei colleghi progettisti abbiamo delle idee non vuol necessariamente dire che quelle idee funzioneranno all'interno dei confini del gioco. Analizziamo alcuni dei problemi che potrebbero presentarsi:

  • L'idea non rispetta le regole.

Un giorno ho realizzato una carta con questo effetto: "Le creature che controlli con forza pari o superiore a 4 hanno volare". L'espansione aveva una mini tematica che premiava chi aveva creature più grandi, quindi ho realizzato una carta che potesse offrire un'abilità evasiva. Quando ho fatto vedere questa carta al nostro rules manager (Matt Tabak), mi ha risposto che non era possibile realizzarla. Perché? Perché c'erano delle regole chiamate "livelli". Dovete sapere che, per fare in modo che il gioco conosca le qualità dei permanenti (che possono essere influenzate dagli effetti), esiste un determinato ordine di applicazione. Se un effetto crea un rapporto tra due attributi, l'attributo che viene influenzato deve avvenire in un livello precedente rispetto all'attributo che viene aggiunto. Volare viene determinato prima della forza di una creatura, quindi la carta che avrei voluto realizzare non avrebbe funzionato. Nel momento in cui volare viene applicato, il gioco non ha ancora determinato quali creature hanno forza pari o superiore a 4.

A causa di problemi relativi alle regole, in questi anni sono state bocciate varie idee di carte (anche se alcune sono riuscito ad aggiungerle alle espansioni a bordo argentato, per le quali abbiamo maggiore flessibilità... diciamo che sono un un-rules manager un po' spensierato). A volte non ci accorgiamo del problema causato da alcune sottosezioni delle regole che non conosciamo. Questo problema si presenta in particolare quando ci avventuriamo in spazi di progettazione inesplorati, che non sono ancora stati gestiti dalle regole. Il rules manager svolge un ottimo lavoro e aggiunge nuove regole, ma l'attuale infrastruttura a volte lo rende molto difficile, se non impossibile.

Council's Judgment | Art by Kev Walker

  • L'idea non vale la pena di modificare le regole che sarebbero necessarie.

Magic ha un insieme di regole molto robusto, ma con dei limiti. Per esempio, in Visione Futura, abbiamo cercato di realizzare una carta cronotraslata dal futuro con "attacco ritardato". L'idea era molto semplice. Esattamente come attacco improvviso avviene prima del normale danno da combattimento, attacco ritardato avviene dopo. Non abbiamo riscontrato alcun problema nelle nostre partite. Dal punto di vista logico funziona bene e sapevamo sempre come funzionava durante le partite, ma il rules manager di quel momento (Mark Gottlieb) ci ha spiegato che l'aggiunta di attacco ritardato al gioco avrebbe richiesto una modifica sostanziale del combattimento. Il sistema era costruito intorno al danno normale e ad attacco improvviso. L'aggiunta di altri livelli avrebbe richiesto un cambiamento notevole al sistema esistente. Gottlieb ha ritenuto che il lavoro necessario per realizzare questo cambiamento e l'impatto sul resto del gioco non valesse la pena per questa nuova meccanica, che è stata quindi abbandonata.

  • La carta ha un effetto impossibile da realizzare con un'abilità.

In progettazione, abbiamo la tendenza a scrivere le carte in un modo che sia semplicemente comprensibile. Tuttavia, per stamparle, la carta deve avere frasi con una determinata struttura (con il linguaggio giusto delle carte di Magic... che io chiamo "Magic-hese"). In questo momento stiamo rielaborando una meccanica per una delle prossime espansioni proprio perché gli editor ci hanno detto che non è possibile ottenere l'effetto che vogliamo noi con una frase prevista dalla struttura. La meccanica aveva alcuni elementi pittoreschi, che hanno messo in crisi il nostro sistema di linguaggio. Per utilizzare la meccanica, abbiamo dovuto modificarla leggermente, in modo da poterla esprimere con il nostro linguaggio.

  • Il testo è troppo lungo per la carta.

Quando abbiamo realizzato il ciclo degli oggetti delle divinità in Theros, molte persone ci hanno chiesto come mai non fossero Equipaggiamenti; la risposta era che erano già artefatti incantesimi leggendari. Non avevamo spazio a sufficienza nella riga del tipo di carta per aggiungere anche la parola "Equipaggiamento". Nella parte finale dello sviluppo, le carte vengono spesso modificate perché il testo di regole è troppo lungo. Molte persone immaginano che la progettazione sia un cielo azzurro senza confini, in grado di realizzare qualsiasi idea, ma esistono vincoli ai quali dobbiamo sottostare e la possibilità di inserire fisicamente gli effetti nel riquadro di testo è uno di questi vincoli.

  • La carta è in contraddizione con gli elementi narrativi.

Nella progettazione di Esodo, Mirri, Gatta Guerriera aveva originariamente protezione dal nero. C'era però un piccolo problema: Nella storia di Esodo, era stata uccisa da Crovax, un personaggio che, a causa di una maledizione, era stato trasformato in un vampiro. Crovax era un personaggio mononero. Le carte possono essere leggermente diverse rispetto alla storia e le meccaniche hanno un po' di flessibilità, ma questo caso sarebbe stato eccessivo. Sarebbe stato in piena contraddizione con la storia, quindi abbiamo rimosso la protezione dal nero e abbiamo aggiunto un punto alla costituzione.

  • La carta ha un problema di sviluppo.

Un motivo molto frequente che porta all'eliminazione di carte e meccaniche è quando il team di sviluppo ci avvisa che si dovrebbero correre notevoli rischi in fase di sviluppo per far funzionare una carta o una meccanica. A volte, l'unico modo per assegnare il giusto costo renderebbe la meccanica molto poco attraente. Altre volte, potrebbe essere un elemento in un'area problematica sulla quale abbiamo già lavorato in precedenza. Molti progetti vengono eliminati perché il loro sviluppo sarebbe troppo problematico.

  • La carta non funziona nel gioco digitale.

In Visione Futura, ho avuto l'idea di un ciclo di carte basato sulle carte Double di Unglued. Le carte avevano un effetto quando venivano giocate e generavano un effetto all'inizio della partita successiva. Quando hanno sentito parlare di queste carte, i miei colleghi che si occupano di Magic Online sono venuti da me e mi hanno detto che non avrebbero potuto realizzare effetti in una partita in grado di interagire con un'altra partita, dato che il sistema non aveva alcun modo per collegarle. Applicare questa modifica avrebbe richiesto un cambiamento troppo grande nel sistema e, anche se fosse stato realizzato, non saremmo stati sicuri del suo corretto funzionamento. Ho quindi rimosso questo ciclo (in realtà, questo ciclo aveva altre difficoltà e sarebbe probabilmente stato eliminato lo stesso, per motivi diversi).

  • La carta crea eccessivi problemi nel gioco digitale.

A volte il problema non è che l'idea non funzionerebbe nel mondo digitale, ma che la sua realizzazione sarebbe problematica. Una leggera modifica potrebbe spesso causare qualcosa che sarebbe molto difficile da programmare o qualcosa di problematico nell'esecuzione da parte dell'utente.

  • La carta crea problemi al gioco organizzato.

Così come le carte devono funzionare nel mondo digitale, devono anche funzionare nel mondo dei tornei. A volte realizziamo carte che generano problemi perché hanno un effetto che non è permesso dalle regole di torneo o che portano i giocatori a compiere azioni che normalmente non potrebbero compiere. La maggior parte delle volte, le regole di torneo possono essere modificate, ma ogni tanto è più semplice modificare leggermente una carta rispetto a causare un grande cambiamento in qualche aspetto del gioco organizzato.

  • La carta ha un problema di marchio.

Unglued e Unhinged sono state realizzate in uno spazio molto particolare e ci sono state numerose carte che il team dedicato al marchio ha gentilmente chiesto di modificare o di eliminare.

  • La carta ha un problema a livello legale.

Non ho la possibilità di darvi alcun esempio di questo caso, ma vi basti sapere che... è successo.

Il mio obiettivo è farvi capire che ci possono essere numerose trappole nel viaggio della creazione di un progetto funzionante in pratica. Abbiamo iniziato ad analizzare maggiormente ciò che dobbiamo eliminare immediatamente, se scopriamo che non avrà possibilità di funzionare.

Incolore per sempre

Passiamo ora alla storia di vacuità. Cosa è successo? Come mai è stata creata questa parola chiave?

Come vi ho spiegato nel mio articolo di anteprima, avevo bisogno di un modo per unificare gli Eldrazi. In Ascesa degli Eldrazi, lo abbiamo realizzato utilizzando il tipo di carta tribale, dando il sottotipo Eldrazi a tutte le carte Eldrazi. Non utilizziamo più il tipo di carta tribale, quindi questa possibilità non era utilizzabile. Gli Eldrazi erano associati all'essenza incolore, quindi ero interessato a scoprire se potessimo utilizzarla come componente meccanica per creare un legame tra tutti loro. Il problema era che avremmo avuto bisogno di un numero sufficiente di Eldrazi affinché fossero una minaccia dominante su Zendikar, ma creare così tante carte con solo costi di mana generici avrebbe generato troppi problemi (il blocco Mirrodin è un ottimo esempio di fonte di problemi, dato che la maggior parte delle carte più forti possono essere aggiunte a ogni mazzo).

La soluzione a questo problema è stata la carta cronotraslata dal futuro Fuoco Spettrale di Visione Futura. Si trattava di una carta che richiedeva il pagamento di mana rosso, ma che era incolore. Questo metodo permette di rendere incolore tutti gli Eldrazi, senza però creare problemi alla struttura dei colori, perché le carte risulterebbero separate in base ai loro costi di mana.

Le prime carte che abbiamo realizzato avevano semplicemente "Questa carta è incolore" vicino al lato superiore del riquadro di testo. Ho rapidamente deciso che non avrei voluto dover scrivere quella riga su ogni carta. Ci sarebbero state molte carte incolore e avremmo aggiunto quelle che mi sembravano parole superflue all'espansione.

La mia idea originale era di rendere fisicamente incolore le carte. Come avrebbero fatto i giocatori a sapere che la carta era incolore? Avrebbero guardato la cornice della carta e sarebbe stato ovvio. Ho quindi modificato tutte le carte del file e ho rimosso la riga "Questa carta è incolore". Questa scelta ha però creato un piccolo problema all'attività di playtest. L'essenza incolore era una qualità meccanicamente importante; i giocatori dovevano poter essere in grado di distinguere le carte incolore dalle altre carte (che realizzavamo con adesivi). La prima idea è stata di mettere gli adesivi di quelle carte su carte incolore, ma la mia preoccupazione era che le persone pensassero che fossero state messe su carte sbagliate. La soluzione che ho scelto alla fine era di utilizzare la parola incolore nella riga del tipo di carta, come se fosse un supertipo. Una stregoneria con vacuità, per esempio, avrebbe avuto la scritta "stregoneria incolore".

Per essere sicuro di essere almeno un po' realista, ho chiesto a Matt Tabak, l'attuale rules manager, se potessimo trasmettere il concetto di incolore in un modo diverso rispetto a scriverlo sulla carta. Matt è stato ottimista. Tutto sembrava procedere per il verso giusto.

Non si sono presentati problemi fino all'inizio dello sviluppo. Nelle prime fasi dello sviluppo, bisogna verificare se ci sono delle esigenze legate alla cornice delle carte; in caso di necessità, bisogna iniziare a lavorarci presto. Ho detto di aver immaginato che avessimo una cornice incolore simile a quella utilizzata in Ascesa degli Eldrazi, adattata alla nuova grafica delle carte. Ho immaginato che avremmo potuto utilizzare per le carte con vacuità la stessa cornice incolore che utilizziamo per le carte incolore vero (nella fase di progettazione abbiamo coniato l'espressione "incolore vero" per riferirci alle carte incolore con un costo di mana generico).

Quando più persone hanno iniziato a lavorare sulle carte con vacuità, la situazione è cambiata. Le carte apparivano bizzarre e non sono piaciute a molte persone del team di Ricerca e Sviluppo. Erano proprio necessarie? Ho risposto di sì, sia perché volevo essere in grado di legare meccanicamente tutte le magie Eldrazi, sia perché la tematica sull'essenza incolore era una delle principali dell'espansione, in quanto aiutava a dare una forte identità meccanica agli Eldrazi, soprattutto in Limited. Abbiamo parlato con le persone che avevano espresso dei dubbi e abbiamo iniziato a comprendere le loro difficoltà. La più grande era che la carta aveva bisogno di comunicare la richiesta di mana colorato quando è in mano, mentre doveva essere chiaramente incolore sul campo di battaglia. Come può una carta essere colorata in mano e incolore sul tavolo?

Questa è stata la difficoltà espressa a Liz Leo, membro del team artistico che si dedica alle questioni grafiche più ampie, come le cornici. Liz ha proposto una soluzione brillante. E se il titolo della carta avesse l'aspetto di una barra di un titolo di una carta colorata, mentre il resto della carta sottostante avesse l'aspetto di una carta incolore?

Prendiamo il Parassita dagli Aculei come esempio. In mano, il Parassita dagli Aculei sembra una carta rossa.

Invece, sul campo di battaglia ha più l'aspetto di una carta incolore.

Perfetto, avevamo la cornice giusta. Eravamo pronti, vero? Non del tutto.

Un vento incolore

C'era però un problema. Le regole dicono che esistono tre modi per determinare il colore. Primo: il colore può essere definito dal mana colorato (o dalla mancanza di mana colorato) nel costo di mana. Questo modo non funziona con le carte con vacuità, dato che non hanno lo stesso colore del mana colorato nel loro costo di mana. Secondo: il colore può essere indicato nel testo di regole. Non volevo utilizzare questo metodo, perché stavo cercando di evitare che le carte con vacuità contenessero quello che a me sembrava testo superfluo. Terzo: le carte possono avere un indicatore di colore. Penso che l'indicatore di colore sia stato creato per le carte a doppia faccia, che avevano una faccia senza costo di mana, nelle quali non volevamo scriverlo nel testo di regole, quindi abbiamo utilizzato un cerchio colorato subito prima della parola "Creatura" nella riga del tipo di carta.

Se il primo metodo non funziona e non vogliamo utilizzare il secondo, la nostra unica risposta è la terza opzione. Avevamo bisogno di un indicatore di colore che trasmettesse l'essenza incolore. Liz ha provato alcune soluzioni e le abbiamo fatte provare ai dipendenti Wizards of the Coast che sapevano giocare a Magic e che non avevano mai visto le carte con vacuità. L'insegnamento è stato: è quasi impossibile trasmettere il concetto di essenza incolore con un cerchio colorato. Se è grigio, dà un'idea di grigio. Se è marrone, dà un'idea di marrone. Se è trasparente, dà un'idea del colore dell'illustrazione sottostante. Abbiamo provato in molti modi ed è stato evidente che le persone non lo coglievano.

Una volta esclusa la terza opzione, ci è rimasta solo la seconda. Avremmo dovuto utilizzare delle parole. Siamo quindi tornati all'inizio e abbiamo aggiunto il testo "Questa carta è incolore".

Abbiamo eseguito altre prove e abbiamo riscontrato un altro problema. Mostravamo ai nuovi giocatori le carte e chiedevamo "Questa carta è incolore?"; la risposta era sì. Poi chiedevamo "Questa carta è rossa?" (nel caso di una carta con vacuità e il rosso nel costo di mana); anche in questo caso la risposta era sì. I giocatori credevano che fosse possibile che una carta fosse sia incolore che di un colore.

Il testo di regole che avremmo voluto utilizzare, "Questa carta non ha colore", non funziona come testo di regole. Utilizza un gergo che potrebbe essere semplice da comprendere, ma non segue il linguaggio di programmazione della struttura delle frasi di Magic. Tim Aten, editor dell'espansione, ci ha offerto la soluzione. Se avessimo utilizzato una parola chiave, avremmo potuto utilizzare la frase che volevamo come testo di richiamo. Il testo di richiamo ha una maggiore flessibilità come struttura rispetto al testo di regole. Inoltre, l'utilizzo di una parola chiave avrebbe risolto un altro problema. Come avrebbero potuto fare i giocatori a parlare delle carte con vacuità, se non avessero avuto un nome assegnato? Chiamarle carte incolore sarebbe stato scorretto, perché l'espansione era piena di carte incolore vero, cioè carte incolore con costi di mana generici. Utilizzare una parola chiave per questa abilità ha permesso ai giocatori di dare un nome a un sottoinsieme di carte.

Questo è un esempio di come un'idea che è iniziata come concetto ha portato a un'esecuzione molto diversa. Perché vacuità deve essere così com'è? Perché ogni altra versione che abbiamo provato non ha funzionato.

La soluzione finale

L'articolo di oggi non è solo relativo a vacuità. È relativo a come la progettazione di un gioco (e, in generale, qualsiasi progettazione) debba affrontare alcune verità. Avere una bella idea è magnifico, ma se l'idea non può essere messa in pratica, diventa inutile. La chiave è prendere una bella idea e determinare ciò che è necessario in modo che qualcun altro possa utilizzarla. Non fila sempre tutto liscio e a volte si finisce lontano dal punto di partenza, ma questa è la dolorosa verità della creazione. I concetti sono magnifici, ma un concetto senza un'esecuzione non è nulla più che un sogno. Se vogliamo lavorare in un ambito in cui vengono prodotti risultati tangibili e prodotti finiti, dobbiamo affrontare la realtà di scendere a compromessi per far funzionare le idee. Vacuità è semplicemente il più recente esempio in Magic di questo principio.

Questo è tutto per oggi. Mi auguro che la storia su vacuità sia stata di vostro gradimento. Come sempre, sono molto interessato alle vostre opinioni. Potete mandarmi una email o contattarmi attraverso uno dei miei social media (Twitter, Tumblr, Google+, Instagram).

Ci rivediamo la prossima settimana, quando sarò di fianco a me stesso.

Nel frattempo, che i vostri concetti trovino la loro esecuzione.


"Drive to Work #270—10 Aspetti necessari a ogni gioco: gli elementi narrativi"

Questa è la nona parte della mia serie da 10 sui "10 aspetti necessari a ogni gioco". Oggi vi parlo dell'importanza degli elementi narrativi.

"Drive to Work #271—Un-Rules Manager"

Questo podcast è relativo a uno dei miei lavori di cui parlo raramente: il ruolo di rules manager per le espansioni a bordo argentato di Magic.

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