O C# é bom para o desenvolvimento de jogos?

Pode ser necessário trabalhar pelo menos um pouco em uma língua nativa, para fazer algumas chamadas ao sistema. As chamadas de sistema que você precisa fazer se encaixam em 3 categorias:

• Principais API da plataforma (dispositivos de armazenamento, janelas, etc). A maioria delas, a Microsoft fornece interfaces C# para e chamá-las é natural.
• External/extension API. Estas podem ser bibliotecas de terceiros que você mesmo integra, ou SDKs de terceiros usados para acessar extensões de sistemas operacionais. Exemplos disso seriam coisas como OpenGL, Vulkan, SDL, OpenCL, PhysX, etc. Algumas delas podem fornecer uma boa interface C#, mas geralmente a interface do denominador comum é C. C# pode chamar C (mas não C++) através do sistema P/Invoke, então isto ainda não é muito ruim.>li>Bibliotecas COM da Microsoft. COM em si é projetado para se ligar facilmente a muitas linguagens, de modo que grandes partes das APIs COM da Microsoft estão disponíveis diretamente em C#. No entanto, este NÃO é o caso do DirectX. A Microsoft tentou fornecer uma interface nativa em C# para DirectX, chamada Managed DirectX, como parte do DirectX 9, mas há muito tempo foi depreciada. Existem algumas bibliotecas de wrapper que você poderia usar, ou você teria que escrever a sua própria. Estas teriam que ser escritas em C/C++, com uma interface C que pode ser chamada por P/Invoke. A alternativa é C++/CLI, mas isso está caindo em desuso mesmo dentro da Microsoft. Uma nota adicional sobre Direct3D e Direct2D - A Microsoft está no processo de abandonar o WPF, por isso eles nunca se preocuparam em fazer a ponte entre o suporte para renderização do Direct3D nas janelas WPF para versões Direct3D acima de 9. Isso significa que se você quiser usar o Direct3D 11 ou 12 (você definitivamente deve hoje em dia), então você deve evitar completamente a janela WPF e usar as janelas GDI. Você pode fazer isso a partir de C#, novamente usando P/Invoke. Se você estava construindo uma aplicação GUI, isso causa uma grande dor de cabeça, mas se você está construindo um mecanismo de jogo onde tudo será renderizado no mecanismo, isso é menos problemático. Há alternativas, mas há advertências que talvez queiras evitar. Há uma nova solução que vem da Microsoft para unificar toda esta confusão, mas só agora está no estado de RC Preview, por isso nem sequer é aprovada pela Microsoft para enviar aplicações de produção. Isso deve acontecer este ano, mas cabe ao desenvolvedor fazer uma chamada sobre querer evitar problemas no início dos dentes em vez de ser à prova de futuro. Se eu estivesse iniciando uma engine de jogos hoje, eu estaria inclinado a ser à prova de futuro porque quando eu estiver quase pronto com uma grande engine de jogos, o novo material já deve ter tido muito tempo para amadurecer.

>p>Além dos problemas de chamadas de sistema e bibliotecas de terceiros, é perfeitamente razoável construir uma engine de jogos em C#. Isso pode ser feito e, de modo geral, funcionaria bem. Mas espere enfrentar obstáculos de desempenho, geralmente, em qualquer linguagem que apresente coleta de lixo. Construir coisas de baixo nível em tempo real em qualquer linguagem de coleta de lixo é geralmente um problema porque controlar a coleta de lixo para evitar que ela interrompa operações críticas de tempo é um desafio significativo. Por esta razão, você verá que a maioria dos motores de jogo escritos em linguagens gerenciadas como C# ou Java, são menos ambiciosos no escopo, porque empurrar direto para o limite sangrento do desempenho em tais linguagens é difícil. Apesar do que alguns argumentariam, isto é mais sobre a coleta de lixo do que sobre a máquina virtual. A maioria das máquinas virtuais modernas para linguagens que foram projetadas para máquinas virtuais, custam apenas uma pequena fração de uma penalidade de performance para tradução de execução (cerca de 1%). Mas o catador de lixo pode ser difícil de manter fora do seu caminho, por isso a maioria dos motores maiores e mais ambiciosos são escritos em um idioma nativo que é gerenciado pela memória manual, ou pela contagem de referência. Hoje em dia isto significa C, C++, Ferrugem, Swift, Kotlin Native, etc. As linguagens gerenciadas são uma escolha mais popular para a parte frontal do motor, como o sistema de scripting, enquanto o backend será uma língua nativa. Um exemplo disso é o Unity, que tem um front end construído em torno do C# scripting, mas ainda usa C++ para o backend de baixo nível. Em um levantamento das principais engine de jogos, você encontrará uma grande variedade de linguagens (ou um sistema de script visual, como Unreal Engine) usadas para o nível superior, menos áreas críticas de tempo, enquanto as tarefas críticas de baixo nível e tempo (renderização de backend, etc.) são quase universalmente escritas em C++.