Un artista deve sapere come implementare nel motore?

Qualche giorno fa Soph Podesta (vi consiglio di seguirla) ha fatto un tweet (mi rifiuto di chiamarlo “X”) in cui ha sollevato una questione molto semplice ma fondamentale:

Secondo voi, un artista di videogiochi deve sapere come implementare nel motore SÌ o NO? Giustificate

Onestamente, questo argomento, anche senza essere un artista, mi interessa molto perché per me è una questione di lavoro di squadra e non tanto di ruoli. Prima di dare la mia opinione è chiaro che non devo avere ragione e va detto che non stiamo parlando di diventare un “Tech Artist” o qualcosa del genere.

La domanda è orientata a se un artista che si occupa solo di disegni (digitali), possiamo chiamarlo anche illustratore, dovrebbe sapere come importare le risorse che crea nel motore e “implementarle” (se sono sprite per un’animazione, metterli in quella corrispondente, nell’ordine in cui dovrebbero essere, se è uno sfondo o tile per una tilemap, sapere come generarli e testarli, ecc.)

Da un lato, la mia filosofia è che tutti gli sviluppatori dovrebbero comprendere tutti i ruoli e l’implementazione nel motore è una parte del tutto. Questo è un po’ per il mio modo di essere e un po’ per l’obbligo intrinseco che ho avuto studiando una laurea universitaria (dove devi passare attraverso tutte le materie, che coprono diversi ruoli, e fare pratica).

Capisco che la specializzazione sia la cosa più importante e che questi siano gli sviluppatori più ricercati; tuttavia, sto iniziando lentamente a vedere una tendenza crescente nel richiedere un approccio “T-Shape”, dove non importa quanto tu sia specialista, devi avere conoscenza di altre discipline che compongono lo sviluppo di un videogioco. E non lo vedo solo negli studi di medie dimensioni (in quelli piccoli, per necessità, non puoi lavorare in altro modo se non indossando “molti cappelli”), si vede anche nelle offerte di lavoro di grandi studi.

Quindi, dovrei? Dal mio punto di vista, sì. Non è obbligatorio, non smetterei di lavorare con un artista solo perché non sa farlo. Ma è più che ovvio per chiunque abbia esperienza di sviluppo che è un vantaggio importante.

Quante volte ci siamo trovati nella seguente situazione?: Artista: Ecco, ho finito con gli asset per tale cosa. Programmatore: ok, li importo ora e controllo … Dopo un po’ Programmatore: guarda, questo e quello Sprite non sono venuti bene, e il colore di questo sfondo non sembra giusto nel gioco. Ho già controllato con il designer e mi ha detto che deve essere modificato Artista: uh, ok, lo faccio ora … Dopo un po’ Artista: Ho finito con gli asset per questa cosa. Programmatore: ok, li importo ora e controllo

Il loop della morte, come mi piace chiamarlo, quello che succede ogni “poco tempo” occupa molto tempo di sviluppo. E la descrizione che ho fatto è una delle situazioni più semplici, non parliamo nemmeno di quando l’artista stava già facendo qualcos’altro “urgente” quando gli è stato detto che la cosa precedente richiedeva modifiche… ufff.

Un artista che sa implementare nel motore taglia tutti questi tempi “morti”, può produrre gli asset, testarli nel motore, rilevare difetti o miglioramenti necessari in anticipo, parlare direttamente con il designer, e tutto prima che arrivi nelle mani di un programmatore (che, d’altra parte, non è sempre la persona più adatta per determinare se un asset è corretto o meno per essere implementato). Non sto nemmeno parlando di implementare per fare push su un branch e avere quei cambiamenti implementati direttamente da lui o lei (sì, so che gli artisti odiano GIT e che ci sono VCS migliori, ma questa è una discussione per un altro giorno), sto semplicemente dicendo che possono fare questo flusso di lavoro:

• Creare l’asset
• Aprire il motore
• Importare l’asset
• Implementarlo dove dovrebbe essere
• Decidere se soddisfa i requisiti o consultare in caso di dubbio
• Una volta che questa decisione è “sì, tutto è OK” far sapere che gli asset sono pronti e caricarli dove appropriato.

A mio parere, in questo modo miglioriamo molto il lavoro di squadra, tagliamo tempi di sviluppo che spesso non hanno senso e alziamo un po’ la qualità del processo di sviluppo.

Crediti: Immagine di Freepik