O C ++ está sendo substituído pelo C # nos jogos do setor?

Em jogos da indústria, quero dizer como Quake, CoD etc.

Em certo sentido, o C ++ está realmente sendo substituído - não apenas pelo C #, mas por vários outros idiomas. Mas se você perguntar, será substituído completamente - então a resposta é definitivamente não .

Isso ocorre porque o C ++ é tradicionalmente usado em duas capacidades. Primeiro, para criar o mecanismo de jogo : os componentes de baixo nível que carregam recursos, pressionam os polígonos para filtrar e processar números em simulações de física. Segundo, para codificar a lógica do jogo : as regras reais que fazem a jogabilidade.

Essa segunda capacidade não requer pontos fortes do C ++ (como controle completo sobre detalhes de baixo nível), mas sofre de suas fraquezas (como gerenciamento de memória codificado manualmente, propenso a erros). E nessa segunda capacidade, o C ++ está sendo substituído por diferentes linguagens de script. Muitos desenvolvedores usam Lua; alguns usam Python. Mas se uma plataforma CLI estiver disponível, no formato .NET ou Mono, ela apresentará um ótimo candidato a host de script. Essas plataformas são bastante rápidas, confiáveis, oferecem uma linguagem amplamente conhecida (C #) e uma abrangente biblioteca de classes base. Não vamos esquecer as ferramentas: o MS Visual studio e o SharpDevelop / MonoDevelop podem não ser os melhores IDEs do mundo, mas são muito bons.

Dito isto, o motor do jogo não será escrito em C # (ou Lua ou Python). Por quê? Porque eles não são rápidos o suficiente.

Ao contrário de muitas crenças populares, o maior maior desempenho atualmente é devido à latência da memória . Isso significa que acessar a memória é um negócio sério. E os idiomas gerenciados não permitem que o usuário controle o acesso à memória - é exatamente por isso que eles são "gerenciados" em primeiro lugar. Portanto, nenhuma linguagem gerenciada permitirá escrever um mecanismo de jogo muito rápido. Na verdade, todos os grandes mecanismos "C #" que consigo pensar - XNA, MOGRE, Unity - são baseados no código C ++ nativo ; mas permita escrever a lógica do jogo em C #.

Para resumir : C # será usado no lugar de C ++ ou outras linguagens. Mas nunca substituirá o C ++, pelo menos até que alguém invente a memória de acesso instantâneo e sem latência.

A escolha do idioma depende muito da plataforma. No momento, parece realmente improvável que qualquer coisa, menos uma plataforma da Microsoft, realmente exija o .NET como implementação.

O senso comum diria que uma pequena plataforma precisaria estar próxima do metal para ter desempenho, mas, por outro lado, plataformas gerenciadas são mais seguras . Essa é provavelmente a razão pela qual o Windows Phone 7 força você a usar o .NET.

Certamente seria interessante se o novo Xbox exigisse uma plataforma gerenciada. Se o hardware de um telefone puder lidar com isso (e funciona), eu certamente os veria usando-o em um console de tamanho normal. Isso agitaria bastante o ecossistema do console, pois seria mais difícil escrever jogos de plataforma cruzada sem escrever todo o código do jogo em uma linguagem de script. Se for esse o caso, o C # não substituirá C ++, mas andaria de mãos dadas.

No momento, você pode usar o Mono como um back-end de script (semelhante ao que o Unity faz), mas eu imagino que a maioria dos fabricantes de mecanismos deseje criar seus próprios, ou use algo mais compacto como Lua ou Python que C #.

De qualquer forma, é tudo sobre a ferramenta certa para o trabalho certo. Você realmente deve aprender as duas linguagens de qualquer maneira, pois o C # facilita a execução de certas coisas (desenvolvimento de ferramentas, provavelmente desenvolvimento de servidor, etc), e você não pode usar nada além de C ++ em alguns casos.

Não é provável. O C ++ tem o benefício de ser de baixo nível, para que os desenvolvedores possam realmente ajustar os mínimos detalhes para obter o melhor desempenho possível.

Com C # e .NET, você tem uma coleta de lixo muito útil, mas ao trabalhar com plataformas com memória e recursos limitados (consoles portáteis e, em certa medida, consoles domésticos), você precisa ter o máximo de controle possível sobre a memória para fazer o melhor uso dos recursos. Permitir que os idiomas gerenciados aloquem e liberem memória para você provavelmente causaria muitos problemas.

A velocidade também é um problema (embora provavelmente menos). Com o tempo, tenho certeza de que as linguagens gerenciadas podem ter um desempenho comparável aos compiladores C ++.

De maneira geral, na minha experiência, os desenvolvedores de jogos tendem a ser loucos por controle quando se trata de memória, tempo e recursos da CPU (para extrair o máximo de desempenho possível), e é por isso que C / C ++ são as linguagens usadas principalmente.

O AFAIK .NET GC ainda sofre com a interrupção do algoritmo de estilo mundial . Embora isso possa ser apropriado para uma ampla variedade de aplicativos - é inaceitável para aplicativos em tempo real, como jogos.

De fato, é muito difícil usar linguagens gerenciadas efetivamente para programas em tempo real até que tenhamos algumas inovações no GC.

Não. Dependendo do .NET, seria necessário reescrever em massa para plataformas sem o Framework disponível, como o PS3, e as desvantagens de desempenho podem ser perfeitamente aceitáveis ​​no PC ou nos jogos do Live Arcade, mas os jogos maiores precisarão de todos os recados. desempenho de seus consoles para executar com rapidez suficiente. Mais do que isso, existem imensas bases de código existentes em C ++ que ninguém poderia dar ao luxo de atualizar, mesmo que quisesse. O C ++ está na indústria de jogos e permanecerá lá por um longo tempo.

Nos momentos em que a energia do computador é escassa, tudo precisa ser programado em C ou C ++, simplesmente porque as linguagens de coleta de lixo retiram o controle da memória do programador e, portanto, o desempenho pode diminuir.

Atualmente, os computadores são mais rápidos, mas, como Knuth diz e, resumindo, a otimização pode ser ruim:

• é óbvio que as funcionalidades básicas de baixo nível precisam ser otimizadas, porque a computação em geometria 3D, física, colisões, iluminação pode inchar rapidamente o melhor processador disponível. Você pode facilmente perceber que o aumento da qualidade visual em uma máquina quase sempre reduz significativamente o desempenho.

• Agora, existem outras funcionalidades, como estados do jogo, IA, som, entrada, rede, que ainda são importantes em um jogo, mas que dificilmente exigirão tanto recurso do computador. Essas funcionalidades, na maioria das vezes, não precisam ser otimizadas. Esse é o objetivo da linguagem de script e das linguagens de coleta de lixo: você não precisa pensar na coerência da memória e na organização do aplicativo, porque o código que você escreverá com essas linguagens, se não estiver codificando coisas de baixo nível, nunca será um gargalo.

Exemplo com 2 casos

• Envie 500 kg de móveis com um caminhão.
• Envie 30 toneladas de material com um barco.

ambos estão a 500 km de distância.

Nos dois casos, é importante acelerar o processo de carregamento / descarregamento para diminuir o tempo de transporte, sabendo que você NÃO pode fazer o barco nem o caminhão se moverem mais rápido?

A resposta é: isso importava com o caminhão, mas não com o barco, porque você já fazia muito movendo o material com o barco.

Não sei se você entende essa metáfora, mas, de certa forma, pode fazer você imaginar o problema matemático, que é mais importante do que entender a resposta.

As linguagens de script permitem acelerar os jogos se você já possui um mecanismo programado em C / C ++: o mecanismo 3D resolve os problemas de baixo nível, agora você precisa fazer o jogo com seus scripts.

Mas lembre-se: você nunca poderá substituir a linguagem compilada de baixo nível, NUNCA. Linguagens compiladas, de tipo estático, são o núcleo do desempenho e você NÃO pode descartá-las, seja um kernel, um mecanismo 3D ou um driver de placa gráfica.

Mas é claro que, se o seu jogo é graficamente simples e não requer muita computação vetorial, você pode se concentrar na jogabilidade e esquecer a otimização, porque nesse caso você nunca terá que lidar com a otimização, pois sua máquina é muito rápida por isso

Exceto se você planeja portar ir no DS. Mas eu vou parar por aí.

Olha, eu sei que isso é um discurso retórico, mas não estou apenas dividindo os cabelos. Eu sinto que a maioria dos programadores realmente não reúne isso. Um idioma em si não tem nada a ver com velocidade / desempenho de execução. É o compilador / framework. Você poderia argumentar melhor o gcc contra o cl (microsoft compiler pre 2010) ou msbuild (atual compilador c ++ para 2010). A cada versão, esses compiladores ficam melhores e você também precisa compará-los com as versões anteriores. Estou muito impressionado com o .net e ele tem um bom desempenho, mas mesmo que tenha um desempenho um pouco melhor, não o vejo assumindo o controle, uma razão: portabilidade.

Os jogos AAA querem estar no Windows, Linux, Mac, XBox, PS3, Nintendo, etc.