Questa esperienza mi aiuta anche molto nella fase di risoluzione problemi. In qualche modo mi accorgo che nella mia mente si attivano dei 'pattern', delle procedure o dei ventagli di soluzione che mi aiutano a sistemare squilibri nei giochi. Insomma, non è più un processo puramente empirico (provo così, poi provo così, no magari così…), ma so che a certi tipi di problemi corrispondono certi tipi di soluzione.
ho giusto provato sulla mia pelle questa cosa all'inizio di questa settimana. provando un proto mi accorgo che c'è assolutamente un dettaglio da sistemare, ne parlo il giorno dopo con paolo e lui l'aveva già immaginato… a me erano occorse due partite (il caso era che l'azione la potevi compiere una o due volte, il dettaglio era che per funzionare dovevi farla per forza in due “zone” diverse). se moltiplichiamo questa cosa per ogni dettaglio di un gioco otteniamo una difficoltà di lavorazione molto maggiore per chi non “legge il codice”.
e proprio sul codice mi soffermo. più di una volta ho paragonato il gamedesign alla programmazione di un software. in questo caso un autore esperto è come se avesse a disposizione un framework (se non sapete cosa è date un'occhiata su wikipedia) molto efficiente, con una libreria di soluzioni già sperimentate (i pattern di cui parla paolo) e una sensibilità maggiore per trovare e risolvere i bug.