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.
Avendo fatto degli studi scientifico/informatici mi ritrovo molto nella frase di khoril. Agli inizi, quando leggevo un regolamento, soprattutto di un aspirante autore, mi veniva spontaneo cercare, prima ancora di giocare, i possibili bug. Deformazione professionale 
Trovare errori in un gioco prima di ancora di fare una partita, o ridurre al minimo i bug nel processo iniziale di ideazione, sicuramente ti fa risparmiare alcuni playtest e guadagnare tempo, ma poi, certamente, fare un bel gioco è tutta un'altra cosa. Personalmente, e l'ho sperimentato sulla mia pelle, essere troppo schematici/informatici rischia di rendere un gioco troppo freddo.
Ritengo l'approccio estremamente interessante, personalmente credo di approcciarmi al game design con gli stessi processi analitici che uso per realizzare musica, con la grossa differenza che il gioco è decisamente più difficile da controllare e da contenere.
E anche su questo sono d'accordo
Ciao
Una trasposizione scadente di una licenza in un gioco ha ottime possibilità di uccidere un potenziale nuovo giocatore, di stroncarne sul nascere l’entusiasmo e la volontà di scoprire se ci sono “altri giochi belli come questo” (A. Chiarvesio)