C# è buono per lo sviluppo di giochi?

Potreste aver bisogno di lavorare almeno un po' in un linguaggio nativo, per fare alcune chiamate di sistema. Le chiamate di sistema che devi fare rientrano in 3 categorie:

• Apiù importanti della piattaforma (dispositivi di memorizzazione, finestre, ecc.). Per la maggior parte di queste, Microsoft fornisce interfacce C# e chiamarle è naturale.
• Apipe esterne/estensioni. Queste potrebbero essere librerie di terze parti integrate da voi stessi, o SDK di terze parti usati per accedere alle estensioni del sistema operativo. Esempi di questo sarebbero cose come OpenGL, Vulkan, SDL, OpenCL, PhysX, ecc. Alcuni di questi possono fornire una bella interfaccia C#, ma generalmente l'interfaccia comune denominatore è C. C# può chiamare C (ma non C++) attraverso il sistema P/Invoke, quindi questo non è ancora troppo male.
• Le librerie COM di Microsoft. COM stessa è progettata per legarsi facilmente a molti linguaggi, quindi molte parti delle API COM di Microsoft sono disponibili direttamente in C#. Tuttavia questo NON è il caso di DirectX. Microsoft ha tentato di fornire un'interfaccia nativa C# per DirectX, chiamata Managed DirectX, come parte di DirectX 9, ma è stata deprecata da tempo. Ci sono alcune librerie wrapper che potreste usare, o dovreste scriverne di vostre. Queste dovrebbero essere scritte in C/C++, con un'interfaccia C che può essere chiamata da P/Invoke. L'alternativa è C++/CLI, ma sta cadendo in disgrazia anche all'interno di Microsoft. Una nota aggiuntiva su Direct3D e Direct2D - Microsoft è in procinto di abbandonare WPF, quindi non si sono mai preoccupati di fare un ponte per il supporto al rendering Direct3D nelle finestre WPF per le versioni Direct3D superiori alla 9. Questo significa che se volete usare Direct3D 11 o 12 (dovreste sicuramente farlo di questi tempi), allora dovreste evitare del tutto il windowing WPF e usare finestre GDI. Potete farlo da C#, sempre usando P/Invoke. Se state costruendo un'applicazione GUI, questo è un gran mal di testa, ma se state costruendo un motore di gioco dove tutto sarà renderizzato nel motore, è meno di un problema. Ci sono alternative, ma hanno dei caveat che potreste voler evitare. C'è una nuova soluzione in arrivo da Microsoft per unificare tutto questo casino, ma è solo ora in stato di RC Preview, quindi non è nemmeno approvata da Microsoft per spedire applicazioni di produzione. Questo dovrebbe accadere quest'anno, ma sta allo sviluppatore decidere se vuole evitare i primi problemi di avviamento o essere a prova di futuro. Se stessi iniziando un motore di gioco oggi, propenderei per l'essere a prova di futuro, perché quando avrò quasi finito con un motore di gioco importante, il nuovo materiale dovrebbe aver avuto tutto il tempo di maturare.

Al di là dei problemi delle chiamate di sistema e delle librerie di terze parti, è perfettamente ragionevole costruire un motore di gioco in C#. Può essere fatto e nel complesso funzionerebbe bene. Ma aspettatevi di affrontare ostacoli alle prestazioni, in generale, in qualsiasi linguaggio che preveda la garbage collection. Costruire cose di basso livello in tempo reale in qualsiasi linguaggio con garbage collection è generalmente un problema perché controllare la garbage collection per evitare che interrompa le operazioni critiche è una sfida significativa. Per questo motivo, troverete che la maggior parte dei motori di gioco scritti in linguaggi gestiti come C# o Java, sono meno ambiziosi in termini di scopo, perché spingersi fino al limite delle prestazioni in tali linguaggi è difficile. Nonostante ciò che alcuni potrebbero sostenere, questo riguarda più la garbage collection che la macchina virtuale. La maggior parte delle moderne macchine virtuali per i linguaggi che sono stati progettati per la macchina virtuale, costano solo una piccola frazione di una penalità di prestazioni per la traduzione dell'esecuzione (circa l'1%). Ma il garbage collector può essere difficile da tenere fuori dai piedi, così la maggior parte dei motori più grandi e ambiziosi sono scritti in un linguaggio nativo che è o gestito manualmente in memoria, o contato come riferimento. In questi giorni questo significa C, C++, Rust, Swift, Kotlin Native, ecc. I linguaggi gestiti sono una scelta più popolare per la parte frontale del motore, come il sistema di scripting, mentre il backend sarà un linguaggio nativo. Un esempio di questo è Unity, che ha un front-end costruito intorno allo scripting C#, ma usa ancora C++ per il back-end di basso livello. In un'indagine sui principali motori di gioco, si troverebbe una grande varietà di linguaggi (o un sistema di scripting visivo, come Unreal Engine) usati per le aree di livello superiore, meno critiche in termini di tempo, mentre i compiti di basso livello, critici in termini di tempo (backend di rendering, ecc.) sono quasi universalmente scritti in C++.