Per una tassonomia videoludica intelligente [Re] — Vol. 6

Degli input archetipali.

In cinque volumi lo sviluppo tassonomico dell’elemento “videogioco” ci ha permesso di ottenere delle strutture fisse che partono da concetti fondamentali che sono stati prima dati per essenziali e poi uno a uno confutati e confermati. Quel viaggio dal punto A al punto B (e lungo tutti i punti intermedi) si fissa attraverso i tre interattori fondamentali — giocatore, personaggio e ostacolo — e ognuno di essi è essenziale e insito nel videogioco stesso. A ognuno di questi corrispondono, nei modi studiati in questi precedenti cinque volumi, tre concetti — stimoli, input e reazioni.

Il giocatore viene costantemente stimolato a far sì che il personaggio, attraverso una serie di input, raggiunga il punto B. Gli ostacoli, necessari al viaggio, possono reagire alle azioni del personaggio, e quindi di conseguenza possono reagire agli input del giocatore.

Ci siamo lasciati nel volume precedente con una riflessione legata alla natura stessa di questi input: essi non sono legati alla natura del personaggio, che diventa semplicemente avatar passivo del giocatore — o meglio, della sua determinazione — e non sono legati in nessun modo alle periferiche che il giocatore utilizza. L’intera questione, quindi, si riduce alla comprensione di quali siano quegli input archetipali di base a cui fare riferimento per costruire l’intero spazio di connessioni tra giocatore e personaggio.

Il punto, quindi, è tutto nel modo in cui il personaggio risponde alle manipolazioni che il giocatore fa su di lui in quanto avatar/marionetta della sua determinazione. Se però la natura del personaggio — singolo o collettivo che sia — e le sue azioni nel gioco non possono essere rilevanti a livello concettuale (e quindi non possono avere valore attivo nella differenziazione tassonomica degli input) l’insieme delle possibili manipolazioni effettivamente rilevanti si riduce di gran lunga. O almeno, si riduce l’insieme delle partizioni in cui si fissano input indipendenti tra loro. D’altra parte questi input archetipali non sono legati né ai comandi in sé né alle azioni del personaggio, perché altrimenti non potrebbero superare la prova del tempo e non potrebbero essere esaustivi. Quindi non sono — e non potranno mai — trovarsi sulle periferiche né su elementi del gioco — menù, abilità, etc.

Insomma, stiamo cercando qualcosa che sia insito in qualunque videogioco e che contemporaneamente permetta di definire e separare le modalità di controllo dell’avatar. È proprio la “modalità di controllo” a darci una direzione verso cui guardare con più attenzione: se controllare una penna, un avatar di forma umana o un esercito non porta a differenze concettuali, perché in ogni caso il giocatore determina specificatamente le azioni dei personaggi, le cose cambiano (di molto) davanti alla possibilità di controllo indiretto dell’avatar.

Controllare direttamente l’azione di un avatar è concettualmente diverso dal controllarla indirettamente attraverso azioni che hanno come risultato il superamento degli ostacoli da parte del personaggio. Una volta chiarito che sia impossibile realizzare un videogioco che non contiene input (perché in tal caso si perde l’elemento interattivo, visto che il personaggio agisce da sé senza necessitare della determinazione del giocatore, e quindi dei suoi stimoli), appare istintivo procedere per due seed semplici: input diretti (Id) e input non-diretti (In). Si svilupperebbero, così, tre diverse categorie tassonomiche per il concetto “input”: Id, In, Idn.

Nascono però alcune perplessità alle quali è necessario rispondere con attenzione. Come si può stabilire che un controllo sia diretto o indiretto? In altri termini, cosa rende indiretta l’azione del giocatore? Ad esempio, modificare le impostazioni della formazione in un simulatore calcistico fa sì che il comportamento del collettivo si modifichi indirettamente, mentre l’azione dei nostri input sui singoli giocatori è espressamente diretta. Ancora, in un gioco in cui si costruisce una pista da sci e poi si fa sciare il personaggio fino a condurlo al traguardo (direttamente) la costruzione della pista è un’azione indiretta che viene operata sul personaggio. Ma allora anche l’inserimento di statistiche e punti forza in un personaggio di un gioco di ruolo o qualunque azione tattica in uno strategico è un’azione indiretta per il personaggio che si trova sotto il controllo diretto del giocatore.

Ha senso quindi chiamare “input diretto” quello che agisce sul personaggio per far sì che esso possa avvicinarsi idealmente all’obiettivo, o a una parte di esso.

Se però si cambia completamente prospettiva, la modifica delle impostazioni della formazione in un simulatore calcistico è un’azione diretta nei confronti della squadra nella sua interezza. Le azioni del giocatore — cioè gli input — sono sempre dirette verso qualcosa o qualcuno: tutto sta nel comprendere quindi se quel qualcosa o qualcuno possa essere identificabile con un personaggio. La squadra nel simulatore calcistico assume il ruolo di personaggio collettivo che sta tentando di raggiungere “il punto B”, quindi è nella direzione in cui si muove la determinazione del giocatore. Quindi il personaggio, avatar del giocatore, è colui che espleta la sua determinazione verso l’obiettivo, e il fatto che possa variare lungo fasi diverse della partita non deve stupire: è il senso stesso di collettivo. Il fatto che quindi un input risulti diretto verso un avatar e indiretto verso un altro — o una parte di essi — non rende differente a livello concettuale l’azione: si tratta sempre di input diretti verso il personaggio, qualunque esso sia, in qualunque istante.

Quindi adesso la questione si sposta su un aspetto molto più insidioso: esistono casi di input indiretto? O almeno, possono esistere? Se la risposta fosse negativa, la decisione di procedere per questi seed sarebbe sbagliata, perché non consentirebbe una partizione utile a un tentativo tassonomico. Come possono essere pensati e sviluppati quindi gli input indiretti? Sembra che ci siano due potenziali candidati: l’inserimento di statistiche e azioni sull’avatar non direttamente influenti sulle sue azioni e l’azione del giocatore direttamente sull’ostacolo.

Il primo candidato pecca subito di un vizio di forma: qual è la differenza strutturale tra un input che fa accelerare un’auto e un input che potenzia una caratteristica — ad esempio in forza — del proprio personaggio? In entrambi i casi l’azione del giocatore sviluppa una modifica nello stato del personaggio, esattamente come il movimento puro e semplice, quindi, seppure apparentemente sembrino differenti, queste azioni producono nel complesso sempre una variazione allo stato del personaggio che gli permette di avvicinarsi all’obiettivo — almeno idealmente. La modifica di statistiche del personaggio, quindi, agisce in modo diretto sulla forza dell’avatar. Anzi, sull’avatar stesso, perché gli permette, esattamente come succede per la formazione della squadra, di agire in determinati modi davanti a determinate situazioni.

Resta il secondo candidato: azioni che si sviluppano direttamente sull’ostacolo senza passare per il personaggio. Azioni di questo genere sono sicuramente rivolte in modo indiretto al superamento degli ostacoli da parte del personaggio: lo aiutano senza intervenire in modo diretto sulle sue azioni all’interno del gioco. Sono, cioè, i candidati ideali per la ricerca di un possibile elemento nel seed In.

Input del genere agiscono sull’ostacolo e non sul personaggio ed è impossibile che siano diretti perché altrimenti significherebbe che personaggio e ostacolo sono lo stesso elemento, ma questo è impossibile perché, come fondamenti della struttura ludica, agiscono in direzioni opposte all’obiettivo: in altri termini è impossibile che un avatar sia contemporaneamente personaggio e ostacolo, nelle definizioni poste in questo tentativo tassonomico. Input che agiscono sull’ostacolo, quindi, possono aiutare indirettamente il personaggio senza però agire direttamente su elementi dell’avatar: sono cioè input non-diretti — per costruzione indipendenti da quelli diretti.

È a questo punto sufficiente esporre un caso di input di questo tipo per garantire che la posizione fatta sia sensata, ben posta e soprattutto non vuota. Trovarla significa assicurarsi che lo spazio degli input possa svilupparsi a partire da Id e In, e quindi ottenere i tre elementi dello spazio degli input definiti sopra: Id, In e Idn. Ora, un caso del genere si può ritrovare all’interno di specifici tower defense in cui si può interagire direttamente sul nemico, come Rock of Ages: piazzare trappole significa agire direttamente sul personaggio (che è l’ambiente), ma colpire direttamente il nemico esclude l’avatar “personaggio” e aiuta l’ambiente (quindi l’avatar del personaggio) alla vittoria. È a tutti gli effetti un caso di Idn, e per questo contiene almeno un input indiretto, giustificando la posizione fatta negli ultimi due volumi di questa tassonomia.

Tutto questo completa la trattazione dei tre interattori — giocatore, personaggio e ostacolo — che da soli sviluppano il videogioco. Come tutto questo possa poi andare a convertirsi in una vera nuova divisione per generi dell’intero scibile videoludico sarà trattazione del prossimo — e ultimo — volume di questa “tassonomia videoludica intelligente”. Intanto, però, prendiamoci il giusto tempo per sviluppare riflessioni su questi risultati e come sempre parliamone su Discord!