Poi, parliamone: quando riduco i tempi di sviluppo ad 1/3 ed elimino metà degli errori solo perché ho scelto una tecnologia, per me quello è un vantaggio.
Dipende dalle persone con le quali lavori e se sai valorizzare le loro skills (sempre tenendo conto che le abbiano chiaro)
Pensi sul serio che tutti i giochi schifosi, in passivo o che non funzionano bene su AppStore siano solo dovuti al fatto che la gente non è capace? Metterci tre giorni invece che tre ore ha una ripercussione anche sulla qualità di quello che fai, se il tempo non è infinito. Non a caso molti giochi veri e belli che sono su AppStore sono port fatti da J2ME, che è tutto dire 
Quindi ora è java a fare belli i giochi? Diciamo piuttosto che è più facile fintanto che, citando monopoli, hai 4 gb di ram un processore quad core e la scheda video figadiddio con supporto dx11 e via andare.
Il discorso è questo: il gioco non è fatto dal linguaggio, il gioco è concepito da un game designer il quale chiede delle features a programmatori e grafici mentre progetta il gioco da farsi. Questi diranno, in base alla loro esperienza, skills, tempi di realizzazione, macchine obiettivo e quant'altro qual è la strada migliore per ottenere un dato risultato, cosa si può fare e cosa assolutamente no a partire dai requisiti dati.
Non c'è tanto da ragionar su per arrivare a capire che nel momento in cui ti spingi in ambienti quali dispositivi mobile e console, java lo prendi e gli dai un calcio perchè non puoi gestire quello che deve essere gestito in maniera ottimale.
Nel momento in cui sony, nintendo e microsoft stessa ci diranno che la strada migliore è java, allora gli sviluppatori di videogames, perchè di questo parliamo, migreranno li. Quando accadrà allora anche Monopoli probabilmente chiederà java ai colloqui.
No macché Java, era per dire che i giochi superiori alla media su AppStore spesso vengono da ambienti più maturi e produttivi, sviluppati su tecnologie e tool rodati, che ti lasciano spazio per divertirti ed essere creativo.
Cherno devi sapere di che parli però: J2ME gira con appena 32K di RAM e l'ultima volta che l'ho usato (5 anni fa) aveva dei tool per i giochi 3D paragonabili allo Unity di oggi (che infatti era nato come progetto open source ispirato a quelli). Ovviamente non con la stessa qualità. Un binario C# spesso ha bisogno di meno memoria di uno staticone C++ per una serie di ragioni che trovi scritte in un sacco di letteratura sulle virtual machine e sui sistemi operativi. Puoi verificarlo anche su MacOSX con Mono. Figurati su dispositivi con una VM hardware (non è il caso dei microcontrollori Apple).
La storiella del game designer, delle abilità è sbagliata in partenza per tutta una serie di ragioni. Le prime esigenze sono commerciali e le start-up o i progetti che davvero cambiano la vita a degli illustri sconosciuti da tempo non sono quasi più sviluppati a basso livello. Ci sarà un perché ed un percome ed è pure dimostrato scientificamente dall'ingegneria del software.
Il problema si riduce in: non lavoro in EA o Codemasters. Ho centomila euro ed un anno di tempo. Devo fare un bel gioco, con connettività online e tutto il resto. Lo faccio in C++ oppure magari in Flash, XNA, Unity o una tecnologia/middleware che mi garantisce meno rogne e lascia più spazio alle cose creative?
Avoja a dire la gente brava.. Se non ti bastano i soldi perché, a fare una semplice metrica ed una pianificazione di progetto, non ci sta dentro non ci sono cazzi. Puoi essere anche circondato da luminari ma quando una build va a puttane per una stringa sbagliata e perdi un giorno (e hai responsabilità diretta per quel giorno perso) le cose diventano tristi molto in fretta!
Gli asset e la parte creative sono un problema secondario e quasi invariante rispetto alla tecnologia che scegli. Qui il talento conta non ci stanno cazzi.
Per il tooling già sarebbe da parlarne... Non c'è cosa più inutile che perdere giorni a risolvere i bug di un tool che qualcuno ha voluto scrivere con wxWidget o Qt, invece di usare WPF.
In generale condivido il tuo ragionamento, che però non si basa su una visione d'insieme ma sul vantaggio soggettivo percepito (quello che conosco fa meno paura di quello che non conosco). Pensa quanto mi cago sotto io che ogni 6-8 mesi mi tocca fare pitch o inziare a lavorare su progetti o tecnologie praticamente ignote... La prima volta che ho messo mano su Ruby mi sono detto: "cazzo non ce la faremo mai", due mesi dopo avevamo un'efficienza che si era già ripagata il primo mese di lavoro dove sembrava di stare fermi.
Visual studio non si batte per il debugging. Dovresti vedere cosa fa con C#, una Xbox/WP7 e XNA!
