| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

View
 

Livello 3: Elementi Formali nei Giochi

Page history last edited by Ciro Continisio 12 years, 2 months ago

 

< Ritorna all'indice delle lezioni in italiano

 

Livello 3: Elementi Formali nei Giochi 

 

Oggi é l'ultimo giorno che continuiamo a costruire un vocabolario critico per parlare di videogiochi; da giovedì ci tufferemo direttamente nel processo di game design. Oggi vorrei che gli ultimi pezzi andassero a posto: ci serve un metodo per dissezionare ed analizzare un gioco discutendo delle sue parti costitutive e di come si uniscono fra loro. Può tornare utile quando si discute dei giochi di altri (sarebbe bello ad esempio se potessero farlo in modo corretto sempre più professionisti delle recensioni videoludiche), ma é anche utile quando vogliamo creare il nostro gioco. Dopo tutto, come si può creare un gioco se non si sa come le sue parti sono tenute insieme?

 

Annunci del Corso

Come al solito, ci sono un pò di cose che vorrei annunciare e rendere chiare:

  • Sono felice di riportare che il wiki del corso é ora aperto al pubblic (in sola lettura). Il wiki é gestito quasi interamente dai partecipanti al corso. Tra le altre cose, i post dei blog sono stati tradotti già in cinque lingue. Sono impressionato ed intimidito dal livello di partecipazione, e vorrei incoraggiare i visitatori di passaggio a farci un salto.
  • Ho notato un pò di confusione su questa cosa e vorrei chiarire: quando dico che dovete leggere capitoli del libro Challenges, non dovete per forza risolvere tutti gli esercizi alla fine del capitolo. Potete farlo se volete, ma molti capitoli hanno 5 esercizi lunghi e 10 corti, e direi che sono un sacco di compiti per un corso che va così veloce. Ripeto, non dovete fare tutti gli esercizi (a meno che non lo dica esplicitamente qui sul blog). 

 

Una Nota Sulle Letture di Oggi

Una delle letture per oggi era il pezzo di Doug Church Formal Abstract Design Tools. Vorrei menzionare un paio di cose. Per prima cosa, lui parla di tre cose che conviene mettere nella nostra cassetta degli attrezzi del designer:

  • L'intenzione del giocatore é definita come l'abilità del giocatore di immaginare i propri obbiettivi e riuscire a raggiungerli. Ci torneremo dopo durante il corso, ma per ora ricordate solo che é importante in tanti giochi lasciare al giocatore la possibilità di creare un piano d'azione.

  • Conseguenze percepibili vengono definite come una reazione chiaramente percepibile del gioco alle azioni del giocatore. La chiarezza é importante qui: se il gioco reagisce ma non vi rendete conto che lo stato del gioco é cambiato, potreste avere difficoltà a collegare le vostre azioni alle conseguenze delle azioni stesse. Vorrei far notare che le “conseguenze percepibili” vengono spesso chiamate con un nome più comune: feedback.

  • Storia é il filo narrativo del gioco. Notate che un gioco può avere due tipi diversi di storia: la storia "integrata" (creata dal designer) e la storia "emergente" (creata dai giocatori). la storia emergente viene creata quando, ad esempio, raccontate agli amici di un gioco recente e di cosa é successo durante la partita: “Ho conquistato tutta l'Africa, ma non sono riuscito a tenere il giocatore blu fuori dallo Zaire.” La storia "integrata" invece é quella a cui pensiamo normalmente come la "narrazione" in un gioco: “Stai interpretando un cavaliere coraggioso che si avventura nel castello di un mago malvagio.” Quello che intende Doug é che la storia integrata compete con l'intenzione e con le conseguenze — cioé più il gioco é "su binari", meno il giocatore può influenzare il risultato. Quando Costikyan in “I Have No Words” dice che i giochi non sono storie, Doug spiega con parole più efficaci quello che intendeva Costikyan.

Ecco un esempio del perché l'intenzione del giocatore e le conseguenze percepibili sono così importanti. Considerate questa situazione: state giocando un FPS. Arrivate da un muro che ha un interruttore. Attivate l'interruttore. Non succede niente. Beh in realtà qualcosa é successo, ma il gioco non dà indicazioni su cosa. Forse si é aperta una porta da qualche parte nel livello. Forse avete appena scatenato un gruppo di mostri nell'area, e vi ci imbatterete appena usciti dalla stanza. Forse ci sono una serie di interruttori e devono essere posizionati nella sequenza precisa acceso/spento (o devono essere attivati in un ordine preciso) per aprire una via verso l'uscita del livello. Ma non avete modo di saperlo, e vi sentite frustrati perché dovete fare una ricerca in tutto il livello nei posti già visitati per scoprire se l'interruttore ha prodotto qualche cambiamento.

 

Come possiamo aggiustare ciò? Aggiungendo un feedback migliore. Un modo potrebbe essere di fornire al giocatore una mappa, e di evidenziare dove é stato premuto l'interruttore. O mostrare una breve sequenza che evidenzia che una porta é stata aperta in qualche posto. Sono sicuro che riuscirete a pensare ad altri modi.

 

Parlando d'altro, Doug ha anche incluso una nota alla fine dell'articolo in cui dice quanto gli sta a cuore il testing, e che la metà dei suoi lettori dice che le prime due pagine sono molto lente, quindi suggerisce di iniziare da pagina 3 se siete in quella metà. Questo sarebbe un esempio di iterazione nel design del suo saggio, una cosa di cui abbiamo parlato precedentemente.

Ora sono sicuro che sembra una cosa scherzosa, ma prendiamola un secondo seriamente. C'é un piccolo problema con questa soluzione (cioé la nota a fine testo, ndT): non potete leggere la nota finché non avete letto tutto il testo, e ormai é troppo tardi. Se Doug avesse iterato sul suo design almeno una volta, cosa gli avreste suggerito di fare? (ho sentito diverse risposte dai miei studenti in passato)

 

Le Qualità dei Giochi

E' stato detto più volte nei commenti al blog del primo post, che mi sono contraddetto da solo: Ho insistito per un vocabolario critico condiviso, e poi ho detto che definire perfettamente la parola "gioco" é impossibile. Cerchiamo di riconciliare questo apparente paradosso.

Diamo uno sguardo alle definizioni elencate il primo giorno. Separate tutte le qualità elencate da ogni definizione che si potrebbero applicarsi ai giochi. A volte vediamo temi ricorrenti: i giochi hanno regole, conflitti, obbiettivi, decisioni, e un risultato incerto. I giochi sono attività, sono artificiali / sicuri / fuori dalla vita di tutti i giorni, sono volontari, contengono elementi di fantasia / rappresentazione / simulazione, sono inefficienti, sono arte, sono sistemi chiusi. Pensate per un momento di altre cose comuni a tutti (o a molti) giochi.

Questo ci dà un punto di partenza per identificare i singoli elementi dei giochi.

Mi riferisco a questi di nuovo come “elementi formali” non perché abbiano a che fare col vestire con giacca e cravatta, ma perché sono “formali” nel senso matematico e scientifico: qualcosa che può essere esplicitamente definito. In Challenges ci riferiamo ad essi come “atomi” — nel senso che sono le parti più piccole del gioco che possono essere separate e studiate individualmente.

 

Quali sono gli elementi atomici di un gioco?

Questo dipende da chi ve lo chiede. Ho visto diverso schemi di classificazione. Come la definizione di "gioco", nessuno di questi era perfetto, ma guardandoli possiamo vedere alcuni temi emergere che possono gettare luce sul tipo di cose di cui abbiamo bisogno per creare come game designer se siamo al lavoro sui giochi.

 

Ciò che segue sono alcune parti di giochi, e alcune cose che un designer deve considerare quando studia queste parti atomiche.

 

Giocatori

Quanti giocatori possono partecipare al gioco? Deve essere un numero esatto (4 giocatori soltanto), o un numero variabile (da 2 a 5 giocatori)? Può un giocatore entrare o uscire durante il gioco? Che cosa comporta questo per il gioco?

Qual è la relazione tra i giocatori: sono squadre, o individui? Le squadre possono essere irregolari? Qui ci sono alcuni esempi di strutture di giocatori; anche se non è certo un elenco completo:

  • Solitario (1 giocatore contro il sistema di gioco). L'esempio include giochi di carte come Klondike (alcune volte viene chiamato “Solitario”) e il videogioco Campo minato.

  • Testa-a-testa (1 giocatore contro 1 giocatore). Schacchi e Go sono esempi classici.

  • PvE” (più giocatori contro il sistema di gioco). Questo è comune in MMO come World of Warcraft. Esistono anche alcuni giochi da tavolo puramente cooperativi, come Knizia’s Lord of the Rings, Arkham Horror, e Pandemic.

  • Uno-contro-molti (1 giocatore contro giocatori multipli). Il gioco da tavolo Scotland Yard è un grande esempio; mette a confronto un singolo giocatore come Mr. X contro una squadra di detective.

  • Tutti contro tutti (1 giocatore contro 1 giocatore contro 1 giocatore...) Forse la struttura più comune per i giochi multigiocatore, si può trovare ovunque, da giochi da tavolo come Monopoli fino ai "multiplayer deathmatch" giocati per lo più in videogiochi “sparatutto in prima persona”.

  • Giocatori separati contro il sistema (1 giocatore contro una serie di altri giocatori). Il gioco del Blackjack è un esempio, dove il "Banco" gioca come un singolo giocatore contro diversi altri giocatori, ma questi altri giocatori non incidono l'uno sull'altro giocatori ed effettivamente non si aiutano né si ostacolano né giocano gli uni contro gli altri.

  • Competizione a squadre (giocaori multipli vs. giocatori multipli [ vs. giocatori multipli ...]). Anche questa è una struttura comune, trovando la sua strada nella maggior parte degli sport a squadre, giochi di carte come Bridge e Picche, giochi team-based online come "Capture the Flag" varianti di sparatutto in prima persona, e di numerosi altri giochi.

  • Predatore-preda. I giocatori formano un (reale o virtuale) cerchio. Ognuno ha l'obiettivo di attaccare il giocatore sulla sinistra, e difendersi dal giocatore sulla loro destra. Il gioco collettivo “Assassination” e il gioco di carte “Vampire: the Eternal Struggle” utilizzano questa struttura.

  • Stella a cinque punte. Ho visto per la prima volta questo gioco in un torneo di cinque giocatori nella variante di “Magic: The Gathering”. L'obiettivo è quello di eliminare entrambi i giocatori che non sono dal vostro lato.

 

Obiettivi

Qual'è l'obiettivo del gioco? Cosa stanno cercando di fare i giocatori? Questa è spesso la prima cosa che vi dovete chiedere quando progettate un gioco, se siete bloccati e non sapete da dove cominciare.

Una volta che sapete l'obbiettivo, vi sembrerà che molti degli altri elementi formali si definiranno da soli. Alcuni obiettivi comuni (di nuovo, questo non è un elenco completo):

 

  • Catturare/Distruggere. Elimina tutti i pezzi del tuo aversario dal gioco. Scacchi e Stratego sono esempi ben noti in cui è necessario eliminare le forze nemiche per vincere.

  • Controllo territoriale. L'obiettivo non è necessariamente distruggere l'avversario, ma prendere controllo di alcune aree sulla plancia. Tipo Risiko e Diplomacy

  • Colleziona. Il gioco di carte Rummy e le sue varianti richiede la collezione di set di carte per vincere. Bohnanza richiede la collezione di gruppi di fagioli. Molti videogiochi platform (come la serie Spyro) includono livelli dove bisogna collezionare un certo numero di oggetti sparsi per il livello.

  • Risolvi. Il gioco da tavola Clue (o Cluedo, a seconda di dove si abita), è un esempio di un gioco in cui l'obiettivo è quello di risolvere un puzzle. Esempi Meno noti (ma più interessanti) sono il Castle of Magic e Sleuth.

  • Inseguimento/corsa/fuga. Generalmente tutti quei giochi dove si corre verso l'obiettivo o si fugge da qualcosa; Per esempio Acchiapparello o i videogiochi come Super Mario Bros.

  • Allineamento spaziale. Un numero di giochi richiede il posizionamento di elementi come obbiettivo, include il gioco non-digitale Tris e Pente, e il videogiochi Tetris.

  • Costruire. L'opposto di "distruggere" - il tuo obiettivo è di far progredire il tuo personaggio o accumulare risorse fino a un certo livello. The Sims ha forti elementi di questo tipo; il gioco da tavolo Settlers of Catan è altrettanto un esempio di questo genere

  • Negazione di un obbiettivo. Alcuni giochi finiscono quando un giocatore compie un atto che è vietato dalle regole, e questo giocatore perde. Esempi sono i giochi di destrezza fisica come Twister o Jenga.

 

Regole (meccaniche)

Come detto la settimana scorsa ci sono tre categorie di regole: quelle di avvio (le cose che fate all'inizio del gioco), quelle di progressione del gioco (che avvengono durante il gioco) e quelle di risoluzione del gioco (quelle che causano la fine del gioco, e che indicano come viene calcolato il risultato in base allo stato di gioco).

Alcune condizioni sono automatiche: sono attivate in alcuni punti del gioco senza che i giocatori scelgano o interagiscano con il gioco ("Scegli una carta all'inizio del turno" o "Il timer del bonus diminuisce di 100 punti al secondo"). Altre regole definiscono le scelte o le azioni che i giocatori possono fare nel gioco, e gli effetti di queste azioni sullo stato di gioco.

Andiamo più a fondo. Rules of Play di Salen e Zimmerman classifica tre tipi di regole, chiamate operative, costitutive e implicite (non sono termini standard nell'industria, quindi i concetti sono più importanti della terminologia stavolta). Per farvi capire, consideriamo le regole del Tris.

  • Giocatori: 2
  • Preparazione: Disegnate una griglia di 3 quadrati per 3. Scegliete un giocatore che inizia con la X. L'avversario avrà il cerchio O.
  • Progresso di gioco: Al tuo turno, segna un quadrato vuoto con il tuo simbolo. Il gioco passa all'avversario.
  • Fine del gioco: Chi mette in fila 3 simboli del suo tipo (ortogonalmente o diagonalmente) é il vincitore. Se il campo di gioco si riempie e non c'é vincitore, é un pareggio.

Queste sono quelle che The Rules of Play chiama le regole "operative". Pensateci un secondo... sono le uniche regole del gioco?

 

E che succede se sto perdendo e mi rifiuto di giocare il mio turno? Le regole non danno un limite di tempo, quindi potrei mettere il gioco in "stallo" indefinitamente per evitare di perdere, e starei sempre giocando dentro le regole per come sono state definite. Tuttavia, nel gioco normale c'é sempre un limite di tempo ragionevole implicito. Non é parte delle regole formali (operative) del gioco, ma é sempre quello che Rules of Play chiama le regole "implicite". Il punto qui é che c'é un accordo non scritto fra i giocatori mentre giocano, e questo viene riconosciuto anche quando non esplicitato a priori.

Anche fra le regole formali ci sono due livelli. La tavola da 3x3 e i simboli "X" e "O" sono specifici del tema di gioco, ma potreste toglierli del tutto. Sostituendo i numeri da 1 al 9 ai quadrati, e trasformando l'allineamento spaziale in una regola matematica, avete Three-to-Fifteen. Anche se Tris e Three-to-Fifteen hanno implementazioni e aspetto diversi, le regole sottostanti sono le stesse. Non pensiamo a queste cose astratte come "regole", ma esse esistono comunque, sotto la superficie. Rules of Play le chiama regole "costitutive".

 

Ma é utile distinguere fra questi tre tipi di regole? Penso che sia importante tenerle a mente per due ragioni:

  • La distinzione fra regole "operative" e "costitutive" ci aiuta a capire perché un gioco é divertente rispetto ad un altro. Il classico Gauntlet ha un gameplay molto simile all'FPS Doom; la differenza principale é la posizione del punto di vista. Per quelli che giocano ai giochi da tavola moderni, si può dire che Puerto Rico sia simile a Race for the Galaxy. La similarità potrebbe non essere immediata perché i giochi sembrano molto simili all'apparenza, a meno che non li si guardi secondo gli stati di gioco e le regole.
  • Molti FPS contengono una regola secondo la quale quando un giocatore viene ucciso, esso può riapparire ("respawn") in una specifica locazione conosciuta. Un altro giocatore potrebbe mettersi vicino quella locazione e uccidere chiunque istantaneamente prima che abbia l'occasione di reagire. Questo viene chiamato "spawn-camping" (cioé "accamparsi vicino al respawn", ndT) e potrebbe essere un bel pò noioso per chi viene ucciso. Lo spawn-camping é parte del gioco (perché in effetti il gioco lo permette)? E' una buona strategia, o é imbrogliare? Dipende da chi interrogate in merito, poiché é parte delle regole "implicite" del gioco. Quando due giocatori operano secondo regole implicite differenti, alla fine uno dei due accuserà l'altro di essere un imbroglione (o solo di fare il furbo) mentre l'altro si metterà sulla difensiva dicendo che giocano secondo le regole e che non c'é motivo di limitarsi quando lo scopo é vincere.La lezione importante qui é che é importante per i game designer definire il più possibile queste regole, per evitare problemi durante il gioco.

 

Risorse e la loro Gestione

“Risorse” é una parola generica, e la uso per indicare tutto quello di cui é in controllo un singolo giocatore. Ovviamente questo include risorse explicite (il Legno e la Farina in Settlers of Catan, la salute e il mana e i soldi in World of Warcraft) ma potrebbe anche includere altre cose sotto il controllo del giocatore:

  • I territori in Risiko
  • Il numero di domande rimaste in Twenty Questions
  • Gli oggetti che si possono prendere nei videogames (armi e potenziamenti)
  • Il tempo (di gioco o reale, o entrambi)
  • Le informazioni (come i sospetti eliminati in Cluedo)

Che tipo di risorse controlla il giocatore? Come vengono manipolate durante il gioco? Queste sono cose che il designer dovrebbe definire esplicitamente.

 

Gli Stati del Gioco

Alcune cose simili alle risorse non sono in possesso di un giocatore, ma sono sempre parte del gioco: proprietà libere in Monopoly, le carte scoperte nel Texas Hold'em. Tutto quello che c'é in gioco, incluse le risorse attuali dei giocatori e tutto quello che compone un'istantanea del gioco in un certo punto si può definire Stato di Gioco.

Nei giochi da tavolo, definire esplicitamente gli stati di gioco non é necessario, ma a volte é utile pensare in questi termini. Dopo tutto, cosa sono le regole se non ciò che definisce come il gioco passa da uno stato all'altro?

Nei videogiochi qualcuno deve definire gli stati del gioco, perché ciò include dati di cui il computer deve tenere traccia. Normalmente questo dipende dal programmatore, ma se il designer può esplicitamente definire tutto lo stato di gioco ciò può essere di grande aiuto per la comprensione del gioco da parte della squadra di programmazione.

 

Informazioni

Quanto dello stato del gioco é visibile per ogni giocatore? Cambiare la quantità di informazioni disponibili per ogni giocatore ha un effetto drastico sul gioco, anche se tutti gli altri elementi formali rimangono uguali. Alcuni esempi di strutture di informazione nei giochi:

  • Pochi giochi offrono la conoscenza totale, dove tutti i giocatori sanno sempre tutto sullo stato di gioco. Scacchi e Go sono esempi classici fra i giochi da tavolo.
  • I giochi possono includere delle informazioni private per ogni individuo. Si pensi al Poker o ad altri giochi di carte dove ogni giocatore ha una mano che solo lui può vedere.
  • Un giocatore potrebbe avere delle informazioni privilegiate, e altri no. Questo é comune in giochi "uno contro molti" come Scotland Yard.
  • Il gioco stesso può contenere informazioni nascoste da tutti i giocatori. Giochi come Cluedo e Sleuth hanno la scoperta di tali informazioni addirittura come condizione di vittoria.
  • Tutte queste varianti possono essere combinate. Molti RTS elettronici chiamano "fog of war" ("nebbia di guerra", ndT) quelle sezioni della mappa nascoste ad ogni giocatore che non abbia un'unità in quel raggio di visuale. Alcune informazioni sono quindi nascoste per tutti. Oltre a questo i giocatori non possono vedere lo schermo degli altri, quindi ognuno non sa quali informazioni sono disponibili per i suoi avversari.

 

Sequenzialità

In che ordine agiscono i giocatori? Come fluisce il gioco da uno all'altro? I giochi possono funzionare in modo diverso a seconda della struttura a turni usata:

  • Alcuni giochi sono puramente a turni: in ogni momento é il turno di un giocatore, nel quale egli può agire. Quando ha finito, diventa il turno di un altro. Molti giochi da tavolo classici e strategici a turni funzionano così.
  • Altri giochi sono basati su turni ma con gioco simultaneo (ognuno fa il suo turno allo stesso momento, spesso scrivendo la sua azione o giocando carte a faccia in giù. Successivamente tutti rivelano insieme le loro azioni). Il gioco da tavolo Diplomacy funziona così. C'é anche una variante di Scacchi nella quale si pianifica la mossa insieme e poi si svela, (due pezzi che entrano nella stessa casella sono entrambi 'mangiati') e questo aggiunge tensione al gioco.
  • Altri giochi ancora sono in tempo reale, dove le azioni sono fatte alla velocità in cui i giocatori riescono a compierle. Molti videogiochi d'azione sono in questa categoria, ma anche alcuni giochi di carte (come Spit o Speed) funzionano così.
  • Ci sono altre varianti. Per un gioco a turni, quando può compiere il suo turno un giocatore? E' comune seguire i turni in senso orario. Fare a turno in senso orario e poi saltare il primo giocatore é comune in alcuni giochi da tavolo (per ridurre il vantaggio del primo a giocare). Ho anche visto giochi in cui l'ordine dei turni é a caso per ogni giro di turni, o dove i giocatori pagano una risorsa per il privilegio di andare per primi (o per ultimi), altri dove l'ordine é deciso dall'ordine dei giocatori (il giocatore che sta attualmente vincendo o perdendo).
  • I giochi a turni possono essere modificati ulteriormente dall'aggiunta di un limite di tempo, o un altra forma di pressione.

 

L'Interazione fra Giocatori

Questo é un aspetto dei giochi spesso dimenticato ma molto importante. Come interagiscono i giocatori fra loro? Come si possono influenzare? Ecco esempi di interazione fra giocatori:

  • Conflitto Diretto ("Ti attacco")
  • Negoziazione ("Se mi supporti mentre entro nel Mar Nero, io ti aiuterò ad entrare al Cairo al prossimo turno")
  • Commercio ("Ti dò del Legno in cambio di Farina")
  • Condivisione di informazioni ("Ho dato un'occhiata a quella casella lo scorso turno e ti avviso, se ci entri scatterà una trappola")

 

Tema (o narrativa, o storia di fondo, o ambientazione)

Questi termini hanno un significato distinto per le persone che scrivono storie in modo professionale, ma per i nostri scopi sono intercambiabili e stanno a significare parti del gioco che non influenzano per niente il gameplay.

Se non ha importanza in termini di gameplay, perché prendersi la briga di occuparcene? Ci sono due ragioni principali. Per prima cosa, l'ambientazione fornisce una connessione emotiva con il gioco. Trovo difficile prendermi cura dei pedoni sulla scacchiera nel modo in cui ci tengo al mio personaggio di Dungeons & Dragons. E anche se questo non fa necessariamente un gioco "migliore" di un altro, rende più semplice ai giocatori essere coinvolti emozionalmente nel gioco.

L'altra ragione é che un tema scelto con cura può rendere un gioco più facile e più semplice da giocare, perché le regole hanno senso. I movimenti dei pezzi negli Scacchi non hanno relazione con il tema del gioco e devono essere memorizzati da chi sta imparando a giocare. Per contrasto, i ruoli di Puerto Rico hanno una relazione con la loro funzione di gioco: il costruttore vi permette di costruire edifici, il sindaco recluta nuovi coloni, il capitano manda merci nel Vecchio Mondo, e così via. E' facile ricordare cosa fanno le azioni nel gioco perché sono legate al tema stesso.

 

I Giochi Come Sistemi

Mi piacerebbe sottoporre alla vostra attenzione due cose su questi elementi formali.

Per primo, se cambiate anche un solo elemento formale, il gioco potrebbe cambiare totalmente. Ogni elemento formale di un gioco contribuisce in maniera profonda all'esperienza del giocatore. Quando si crea il design di un gioco pensate a questi elementi per essere sicuri che siano tutte scelte accurate.

Secondo, notate che questi elementi sono correlati fra loro, e cambiarne uno può cambiarne altri. Le regole governano i cambi negli Stati di Gioco. Le informazioni a volte possono diventare una Risorsa. La Sequenza degli eventi può portare a diversi tipi di Interazione fra i Giocatori. Cambiare il numero di Giocatori può influenzare il tipo di Obbiettivi da definire. E così via.

A causa della interrelazione di queste parti, si può includere qualunque gioco in un sistema. (Una definizione della parola "sistema" é: una combinazione di cose o parti che formano un elemento unico complesso)

Nella realtà un gioco può contenere diversi sistemi separati. World of Warcraft ha un sistema di combattimento, un sistema di avventure, un sistema di gilde, un sistema di chat, e così via...

Un'altra proprietà dei sistemi é che è difficile capire bene o predire il risultato solo definendoli; potete avere una comprensione maggiore solo vedendoli in azione. Considerate il modello fisico di un proiettile in movimento. Potrei darvi l'equazione matematica che definisce il percorso di una palla lanciata, e potreste predirne il comportamento... ma il tutto ha più senso se vedete qualcuno che tira una palla per davvero.

Anche i giochi sono così. Potreste leggerne le regole e definire tutti gli elementi formali, ma per capirlo davvero dovreste giocarci. Questo é il perché molte persone non vedono subito il parallelo fra Tris e Three-to-Fifteen fino a che non ci giocano.

 

Analisi Critica dei Giochi

Cos'é l'analisi critica, e perché dovremmo interessarcene?

L'analisi critica non é solo una recensione. Non stiamo a guardare quante stelle su cinque prende il gioco, o un numero da 0 a 10, o se un gioco é "divertente" o no (e cosa ciò voglia significare) o se aiutare o no l'acquirente a decidere se comprare un gioco.

L'analisi critica non vuol dire solo trovare elementi sbagliati in un gioco. La parola "critica" in questo contesto non vuol dire criticare a priori, ma piuttosto dare un giudizio non influenzato da nulla.

L'analisi critica é utile quando si discute o si comparano giochi. Potreste dire "Mi piace il gioco di carte Bang! perché é divertente", ma questo non ci aiuta, come designer, a capire perché é divertente. Dobbiamo dare uno sguardo alle parti del gioco e vedere come ogni parte si lega all'esperienza di gioco.

L'analisi critica é anche utile quando esaminiamo i nostri lavori in corso d'opera. Per un gioco su cui si sta lavorando, come fate a sapere cosa aggiungere o rimuovere per renderlo migliore?

Ci sono molti modi di analizzare criticamente un gioco, ma io ho un processo fatto da tre fasi:

  1. Descrivere gli elementi formali del gioco. Non li interpretate ora, dite solo cosa c'é.
  2. Descrivere i risultati degli elementi formali quando vengono messi in moto. Come interagiscono diversi elementi? Com'é giocare al gioco? E' riuscito?
  3. Provate a capire perché il designer ha scelto questi elementi e non altri. Perché questa particolare struttura dei giocatori, e perché quel set di risorse? Che sarebbe successo se il designer avesse scelto diversamente?

Alcune domande da farsi durante un'analisi critica:

  • Che sfide affrontano i giocatori? Che azioni possono fare per superarle?
  • Come i giocatori si influenzano fra loro?
  • Il gioco viene percepito come giusto? (Attenzione che potrebbe in effetti non essere davvero giusto. La percezione e la realtà spesso differiscono).
  • Il gioco é rigiocabile? Ci sono più strade per la fine, varie posizioni iniziali, o regole opzionali che rendono l'esperienza diversa ogni volta?
  • Qual é il pubblico del gioco? E' un gioco appropriato per quel pubblico?
  • Qual é il "cuore" del gioco - quella cosa che fai ripetutamente e che rappresenta il fattore principale di "divertimento"?

 

Lezione Appresa

Abbiamo fatto molta strada oggi. I principali risultati:

  • I giochi sono sistemi.
  • Capire un gioco é più semplice se lo si gioca effettivamente. 
  • Analizzare un gioco richiede di prestare attenzione a tutte le parti di un gioco, e capire come queste si incastrino insieme generando un'esperienza di gioco.

  • Fare il design di un gioco richiede la creazione di tutte le parti del gioco. Se non avete definto in qualche maniera gli elementi formali del vostro gioco, allora non avete realmente un gioco... avete solo il seme di una idea. Questo è buono, ma per trasformarlo in un gioco dovete effettivamente realizzarne il design.

 

Giochi per Casa

Mi hanno fatto notare che ho utilizzato la prola “homeplay” per riferirmi alla lettura, e che la lettura non è un gioco a prescindere da quanto provi a nasconderlo. Questa critica è fondata; generalmente nelle lezioni dei miei corsi io uso “homeplay” per riferirmi agli incarichi di reale game design e non alla lettura, e mischio i termini anche qui. Cercherò di evitare questa confusione in futuro, perchè credo che cercare di trattare l'apprendimento come un'attività Non Divertente (come evidenziato dal fatto di usare parole dai suoni divertenti per descriverlo) è dannoso a lungo termine per il nostro benessere collettivo. Come si può vedere quando entriamo nella teoria del Flow, la realtà è esattamente l'opposto.

Detto questo, qui c'è un'attività che spero troviate interessante. Si basa sull'esercizio 2-5 nel libro Challenges, con alcune variazioni tanto per tenervi in svegli. Ecco come funziona. Per prima cosa, scegliete il vostro livello di difficoltà basandovi sulle vostre precedenti esperienze di game design. Gli sciatori potrebbero trovarlo familiare:

 

 

 

Facile          Difficile          Più difficile

Ecco la sfida:

Molti giochi a tema di guerra hanno un obbiettivo o di controllo del territorio o di cattura/distruzione (come descritti prima). Per questo esercizio dovrete spingervi oltre questi limiti tradizionali. Dovete creare un gioco non digitale che includa i seguenti:

GreenCircleIl tema deve essere associato alla Prima Guerra Mondiale. L'obbiettivo non può essere il controllo del territorio o la cattura/distruzione di obbiettivi.

BlueSquareNon potete usare il concetto di controllo del territorio o di cattura/uccisione come dinamiche di gioco. Cioé il gioco non può contenere i concetti di territorio o di morte in nessuna forma.

BlackDiamondCome sopra, e in più i giocatori non possono entrare in combattimento diretto, solo indiretto.

 

Ho creato nuove aree sul forum (una per ogni livello di difficoltà).

Postate le vostre regole di gioco nel forum appropriato entro Giovedì 9 Luglio alle 12 GMT. Siete incoraggiati a postare il prima possibile.

Quindi dopo aver postato, leggete almeno due altri post dal vostro livello di difficoltà e offrite una critica e un'analisi costruttive. Se siete del gruppo quadrato blu o rombo nero, leggete anche due post dal livello di difficoltà immediatamente sotto il vostro e offrite il beneficio della vostra esperienza a chi ne ha bisogno. Cercate di scegliere post che non hanno ancora risposte, così tutti possono avere un feedback. Inoltre fatelo entro mezzogiorno di giovedì.

 

Una Nota sulla Ricerca

Notate che dovrete fare un pò di ricerche per concludere questo progetto (anche solo guardare Wikipedia per ispirazione). E' tipico del game design. Molte persone pensano ai game designer come questi tizi che stanno seduti tutto il giorno alla scrivania e ad un certo punto proclamano, "ho questa Grande Idea di gioco! Ninja... e laser... nello spazio! Forza, costruitelo, mia armata di lacché programmatori e grafici. Io siederò qui finché non arriverà un'altra Grande Idea, mentre raccolgo i guadagni delle cinque precedenti". Questo non si avvicina neanche lontanamente alla realtà. Un grande design ha dettagli: definizione delle regole, certamente, ma anche una ricerca per essere sicuri che si rientri nei limiti appropriati al progetto.

 

Una Nota sulle Leggi di Protezione degli IP…

A qusto punto alcuni di voi penseranno di postare il gioco sul forum, e che magari qualcuno ruberà la vostra Grande Idea. Come potete proteggervi dalla possibilità che questo qualcuno rubi la vostra idea di base, la converta in un gioco funzionabile e vendibile, lasciandovi a mani vuote?

Uno dei partecipanti al corso, Dan Rosenthal, ha gentilmente scritto un articolo sui dettagli di base degli IP (Proprietà Intellettuali) e le loro leggi, in relazione ai giochi. Questo articolo é molto incentrato sugli USA, ma l'idea di base (che ripeterò qui) dovrebbe essere valida ovunque voi siate:

Ricordate, le idee non si possono coprire con un copyright, né con un trademark, né si possono rendere segrete, e sono sia difficili che proibitivamente costose da brevettare. Non potreste proteggerle in ogni caso, e non ci dovreste nemmeno provare - al contrario, cercate di trovarne di nuove, e lavorate su quelle buone. Non impazzite quando vedere i Game Jam, o questo corso e pensate "Ian ha detto che dovrei postare il mio lavoro sul forum, ma io ho avuto questa Grande Idea (tm) e non voglio che altri la rubino." Le idee sono comuni nei giochi, e il valore della vostra idea non é niente se comparato al valore dell'implementazione dell'idea, la vostra esperienza ed il duro lavoro nello sviluppare qualcosa che frutti soldi veri. Ma per di più la nostra industria é laterale, molto stretta e molto collaborativa. Troverete persone che scambiano idee alla GDC, che portano avanti progetti di collaborazione fra diversi studi, o che usano ispirazione dalle meccaniche di un gioco per ispirarne un altro. E' inutile opporsi. E' così che vanno le cose, e se abbracciate questa atmosfera rilassata, sarà molto meglio.

Comments (7)

Ciro Continisio said

at 11:46 am on Jul 6, 2009

grande iveshohler / OneManArmy o come ti devo chiamare! :D
Poi se non ti spiace dò una sistemata agli errori di digitazione.

One man army said

at 11:48 am on Jul 6, 2009

si assolutamente io scrivo e tu coreggi se ne hai voglia^^

Ciro Continisio said

at 11:56 am on Jul 6, 2009

ma sì, dobbiamo farla brillare questa traduzione! :D
ho messo il link alle lezioni sul forum di AIOMI, ora siamo sotto gli occhi di tutti [gli italiani]... non possiamo tradirli.

One man army said

at 6:07 pm on Jul 6, 2009

apparte che siamo i piu efficienti^^

Ciro Continisio said

at 8:05 am on Jul 7, 2009

Porca miseria com'é lunga questa lezione... almeno traducendo me la imparo anche!

One man army said

at 5:52 am on Jul 8, 2009

scusa sono stato molto impeganto ieri1

Ciro Continisio said

at 7:17 pm on Jul 8, 2009

FINITO...

You don't have permission to comment on this page.