Por que apenas alguns videogames são escritos em Java? [fechadas]

Por que muitos videogames 3D comerciais (não 2D aleatórios de código aberto) são escritos em Java? Em teoria, faz muito sentido: você obtém um aumento de produtividade e um aplicativo de plataforma cruzada quase de graça, entre outras coisas, como a grande quantidade de bibliotecas Java e a coleta de lixo integrada (embora eu admita que ' não tenho certeza se o último é uma coisa boa). Então, por que é raramente usado? Só consigo pensar em alguns jogos comerciais populares escritos para a plataforma Java.

É por causa do desempenho? Se sim, a maior parte do trabalho pesado não seria feita pela GPU?

O mundo do desenvolvimento de jogos é engraçado: por um lado, eles geralmente aceitam novas idéias, por outro lado, ainda estão na idade da pedra.

A verdade é que raramente há muito incentivo para mudar para .NET / Java / qualquer coisa que não seja C / C ++.

Muitas empresas de jogos licenciam partes do mecanismo de jogos de outras empresas. Essas partes são escritas em C ++ e, embora você possa ter acesso à fonte para poder portá-la, é preciso muito esforço (e, é claro, a licença precisa permitir).

Além disso, já existe muito código herdado em C ++. Se o código de projetos anteriores puder ser reutilizado (por exemplo, se você estiver escrevendo uma sequência), isso conta ainda mais a favor de continuar com o mesmo idioma, em vez de reescrevê-lo em um novo idioma (mais porque você provavelmente reintroduzirá uma tonelada de bugs que você precisará gastar tempo resolvendo.

Finalmente, é raro os jogos serem escritos em 100% C ++ de qualquer maneira - muito é feito usando linguagens de script, sejam personalizadas ou apenas integrando linguagens existentes (Lua é uma das mais populares atualmente).

No que diz respeito à coleta de lixo, isso pode ser um pouco problemático. O problema não é tanto o que existe, é mais como ele funciona - o coletor de lixo DEVE não bloquear (ou pelo menos garantir um bloqueio muito breve), pois é simplesmente inaceitável que o jogo congele por 10 segundos enquanto ele verifica toda a memória alocada para ver o que pode ser liberado. Eu sei que o Java tende a engasgar bastante no GC quando está quase ficando sem memória (e para alguns jogos por aí, isso acontecerá).

Você também é um pouco mais restrito no que pode fazer: não pode explorar completamente o hardware devido à sobrecarga do tempo de execução. Imagine o Crysis sendo escrito em Java ... mesmo que essa seja a única diferença visível, não seria a mesma (também tenho certeza de que você precisaria de um Core i7 para executá-lo.).

Isso não significa que essas linguagens não têm seu lugar no desenvolvimento de jogos - e não, não estou me referindo apenas à programação de ferramentas. Para a maioria dos jogos, você não precisa do desempenho extra que obtém do C ++, incluindo jogos em 3D, e se estiver escrevendo tudo do zero, pode fazer sentido usar algo como XNA - na verdade, há um boa chance que vai.

No que diz respeito aos jogos comerciais - o RuneScape conta? Esse pode ser o jogo Java mais bem-sucedido do mercado.

Eu acho que John Carmack disse isso melhor com:

O maior problema é que o Java é realmente lento. Em um nível puro de CPU / memória / tela / comunicação, os telefones celulares mais modernos devem ser plataformas de jogos consideravelmente melhores do que um Game Boy Advanced. Com o Java, na maioria dos telefones, você fica com a potência da CPU de um PC IBM original de 4,77 mhz e um péssimo controle sobre tudo. [... snip ...] Escreva uma vez, execute em qualquer lugar. Ha. Hahahahaha. No momento, estamos testando apenas em quatro plataformas, e nem um único par tem exatamente as mesmas peculiaridades. Todos os jogos comerciais são aprimorados e compilados individualmente para cada plataforma (geralmente mais de 100). Portabilidade não é uma justificativa para o desempenho terrível.

( fonte )

É verdade que ele estava falando de plataformas móveis, mas eu encontrei problemas semelhantes com o Java como um todo, oriundos de C ++. Sinto falta de poder alocar memória na pilha / heap nos meus próprios termos.

Por um lado, a falta de sobrecarga de operadores do Java torna toda a matemática com a qual você precisa lidar para obter um pipeline de gráficos de trabalho muito, muito chato e difícil de ler.

Toda a multiplicação de matrizes e vetores afins com os quais você precisa lidar são muito mais fáceis de seguir se estiverem em expressões matemáticas bem formadas, em vez de expressões orientadas a objetos, como

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

Isso é terrível. A matemática não deveria ser assim.

Eu acho que o .NET tinha (tem) muitos dos mesmos problemas percebidos que o Java tem. A Microsoft acaba de fazer um trabalho melhor de marketing para desenvolvedores com o XNA :-)

Pontos menores primeiro:

• qualquer aumento de produtividade do Java é hipotético. A sintaxe é quase idêntica ao C ++; portanto, você está realmente apenas aproveitando as economias do gerenciamento de memória e das bibliotecas padrão. As bibliotecas têm pouco a oferecer aos desenvolvedores de jogos e o gerenciamento de memória é um problema controverso devido à coleta de lixo.

• multiplataforma "de graça" não é tão bom quanto você pensa, porque poucos desenvolvedores desejam usar o OpenGL e várias plataformas principais provavelmente não possuem uma boa implementação ou wrappers Java para suas bibliotecas nativas, seja para gráficos, áudio, redes etc.

Mas, principalmente, o problema é a compatibilidade com versões anteriores. Os desenvolvedores de jogos mudaram para C ++ de C e para C de assembly apenas porque a rota de migração foi tranquila. Cada um interopera intimamente com o anterior e todo o código anterior era utilizável no novo idioma, geralmente por meio de um único compilador. Portanto, a migração foi tão lenta ou rápida quanto você gostou. Por exemplo, alguns de nossos cabeçalhos antigos em uso hoje ainda têm #ifdef WATCOMCe acho que ninguém usou o compilador Watcom aqui em uma década ou mais. Há um investimento maciço no código antigo e cada bit é substituído apenas conforme necessário. Esse processo de substituição e atualização de bits e partes de um jogo para o outro não chega nem perto de ser prático se você mudar para um idioma que não interage nativamente com o código existente. Sim, a interoperabilidade C ++ / Java é possível, mas muito impraticável em comparação com simplesmente escrever "C com um pouco de C ++" ou incorporar blocos asm em C.

Para substituir adequadamente o C ++ como a linguagem de escolha dos desenvolvedores de jogos, ele deve fazer uma de duas coisas:

1. Seja facilmente interoperável com o código legado existente, preservando assim o investimento e mantendo o acesso às bibliotecas e ferramentas existentes, OU
2. Demonstravelmente, demonstre antecipadamente um aumento de produtividade para que o custo de reescrever todo o seu próprio código (ou retrabalhar as interfaces em componentes reutilizáveis ​​que possam ser usados ​​nesse idioma) seja mais do que coberto.

Subjetivamente, não acho que o Java atenda a nenhum deles. Uma linguagem de nível superior pode encontrar a segunda, se alguém for corajoso o suficiente para ser o pioneiro. (O EVE Online é provavelmente o melhor exemplo que temos de que o Python é utilizável, mas que usa uma bifurcação da linguagem principal do Python, muitos componentes C ++ para desempenho, e mesmo isso é para um jogo bastante pouco exigente em termos modernos.)

Eu estou jogando o The Sims 3, e eu fiz algumas cutucadas. O mecanismo gráfico é C ++, enquanto o mecanismo de script e comportamento é C # / Mono. Portanto, enquanto o C ++ está disponível para bits críticos no tempo, outras coisas como .interaction, lógica do jogo, a IA está em uma linguagem gerenciada orientada a objetos.

• Existem boas portas de mecanismos / bibliotecas de jogos?
• Muitos desenvolvedores de C / C ++, principalmente os do Windows (onde a maioria dos jogos comerciais são gravados), estão familiarizados com o Visual Studio. Não há comparação nos IDEs.
• Em geral, o Java foi vendido para empresas devido à sua digitação sólida e à percepção de não haver problemas de gerenciamento de memória.
• E sim, Java ainda sofre com a percepção de que é lento, e seu gerenciamento de memória é ruim e, para jogos, provavelmente não é adequado para a tarefa. Conforme declarado em algumas das outras respostas, a coleta de lixo não será suficiente quando você estiver lidando com requisitos de alto desempenho em tempo real. Os videogames levam as CPUs e GPUs ao limite.

Uma das maiores razões pelas quais Java e outras linguagens de máquina virtual não são usadas para jogos é devido à coleta de lixo. O mesmo vale para o .NET. A coleta de lixo já percorreu um longo caminho e funciona muito bem na maioria dos tipos de aplicativos. Porém, para fazer a coleta de lixo, você precisa pausar e interromper o aplicativo para coletar o lixo. Isso pode causar atraso periódico quando a coleta acontece.

Java tem o mesmo problema para aplicativos em tempo real. Quando as tarefas precisam ser executadas em um horário específico, é difícil que uma tarefa automatizada, como a coleta de lixo, respeite isso.

Não é que o Java seja lento. É que Java não é bom em lidar com tarefas em tempo real.

Um grande motivo é que os videogames exigem conhecimento direto do hardware abaixo, muitas vezes, e realmente não existe uma ótima implementação para muitas arquiteturas. É o conhecimento da arquitetura de hardware subjacente que permite aos desenvolvedores extrair cada grama de desempenho de um sistema de jogo. Por que você dedica algum tempo para portar o Java para uma plataforma de jogos e depois escreve um jogo em cima dessa porta quando você pode simplesmente escrever o jogo?

edit: isto significa que é mais do que um problema de "velocidade" ou "não tem as bibliotecas corretas". Essas duas coisas andam de mãos dadas com isso, mas é mais uma questão de "como faço para que um sistema como a célula execute meu código java? Não existem realmente bons compiladores java que possam gerenciar os pipelines e vetores como eu preciso .. "

Problema de desempenho é o primeiro motivo. Quando você vê o tipo de código C ++ hiper otimizado que está nos mecanismos do Quake ( http://www.codemaestro.com/reviews/9 ), você sabe que eles não vão perder tempo com uma máquina virtual.

Claro que pode haver alguns jogos .NET (quais? Estou interessado. Existem alguns realmente intensivos em CPU / GPU?), Mas acho que é mais porque muitas pessoas são especialistas em tecnologias de MS e seguiram a Microsoft quando lançaram sua nova tecnologia.

Ah, e multiplataforma simplesmente não está na mente das empresas de videogames. O Linux é apenas cerca de 1% do mercado, o Mac OS é um pouco mais. Eles definitivamente acham que não vale a pena despejar tecnologias e bibliotecas somente para Windows, como o DirectX.

Você pode perguntar por que os aplicativos Web também não são escritos em C ou C ++. O poder do Java reside em sua pilha de rede e design orientado a objetos. É claro que C e C ++ também têm isso. Mas em uma abstração mais baixa. Isso não é nada negativo, mas você não quer reinventar a roda toda vez, não é?

Java também não possui acesso direto ao hardware, o que significa que você está preso à API de qualquer estrutura.

Equívocos sobre desempenho e otimizações ruins da JVM seriam o meu palpite. Digo equívocos sobre desempenho porque existem algumas portas Java de jogos em C ++ que executam mais rapidamente do que suas contrapartes em C ++ (consulte Jake 2). O verdadeiro problema, IMHO, é que muitos programadores Java não se concentram tanto no desempenho de ponta, como na facilidade de uso e na compreensibilidade / manutenção do código. No lado C / C ++, você está basicamente codificando em uma linguagem assembly de nível um pouco mais alto e é o mais próximo possível do hardware, sem escrever código assembly ou código de máquina direto.

A lista de mecanismos de jogos na Wikipedia lista muitos mecanismos de jogos junto com a linguagem de programação em que estão escritos.

Existem vários mecanismos de jogos Java listados.

Clicar em alguns dos links levará a exemplos de jogos e demos escritos em Java. Aqui estão alguns:

• Ardour3D
• Bytonic Software

Para certos jogos e situações, as compensações do Java podem ser aceitáveis.

O .NET definitivamente tem alguns dos mesmos problemas que o Java tem quando se trata de intenso desempenho em 3D. A Microsoft também investiu muito mais tempo e dinheiro no desenvolvimento das bibliotecas quando se trata de trabalhar com operações pesadas em 3D.

(... pessoalmente, eu também acho que eles tiveram uma vantagem sobre a mágica entre DirectX e .NET)

1. Java é lento, a maior parte do trabalho pesado não é realizada pela GPU. Ainda há animação, física e IA atingindo a CPU, que consomem muito tempo.

2. O Java não existe nos consoles, e os consoles são um dos principais alvos dos jogos comerciais. Se você usa Java no PC, está eliminando sua capacidade de portar para consoles dentro de um prazo e orçamento razoáveis.

3. Muitos dos codificadores mais experientes da indústria de jogos usam C e C ++ muito antes de o Java se tornar popular. Os dois pontos acima podem contribuir para isso, mas espero que muitos codificadores profissionais de jogos simplesmente não conheçam muito bem o Java.

4. O argumento de outra pessoa sobre o middleware acima foi bom, então estou adicionando à minha resposta. Há muito código legado e middleware escrito especificamente para vincular ao C / C ++, e a última vez que verifiquei o Java não tem boa interoperabilidade. O uso do Java para a maioria das empresas envolveria a liberação de muitos códigos, muitos dos quais pagos de uma maneira ou de outra.

Na verdade, é muito possível que o código gerenciado faça jogos em 3D, o problema são os mecanismos de trás. Com o .Net, por um breve período, houve um wrapper do DirectX gerenciado para o DirectX 9 da Microsoft. Isso foi antes da abstração que agora é XNA.

Tendo acesso total às APIs do DirectX, os jogos .Net funcionam muito bem. O melhor exemplo que conheço é www.entombed.co.uk, escrito em VB.Net.

Infelizmente, do lado do Java, falta seriamente - principalmente pelo fato de o DirectX não estar disponível para Java, e os programadores de jogos conhecerem e entenderem a API do DirectX - por que aprender mais uma API quando você voltará ao DirectX?

O marketing de jogos é um processo comercial; os editores desejam retornos quantificáveis ​​de baixo risco para seus investimentos. Como conseqüência, o foco geralmente está em truques tecnológicos (com exceções) que os consumidores compram para produzir um retorno confiável - esses tendem a ser efeitos visuais superficiais, como reflexo da lente ou resolução mais alta. Esses efeitos são confiáveis ​​porque eles simplesmente usam aumentos no poder de processamento - eles exploram os aumentos de hardware / lei de Moore. isso implica o uso de C / C ++ - o java geralmente é muito abstrato do hardware para explorar esses benefícios.

Eu acho que a velocidade ainda é o problema. A plataforma cruzada será um problema, pois você não sabe qual placa 3D está disponível ao escrever o código? O java tem algo para oferecer suporte à descoberta automática de recursos 3D? E eu acho que existem ferramentas para facilitar a portabilidade de um jogo entre o wii, xbox e ps3, mas aposto caro.

O ps3 tem java, através do suporte blue ray. Verifique o site bd-j.

Mesmo os jogos escritos na plataforma .Net geralmente são altamente otimizados para velocidade, como acesso direto à memória e ao barramento. O .Net permite usar C / C ++ e misturá-lo com linguagens de nível superior, como C #.

Os estúdios de desenvolvimento de jogos geralmente trabalham em conjunto com fornecedores de hardware, que fornecem acesso a interfaces de baixo nível de seus produtos. Este é um mundo em que você precisa usar o ASM e o C para a comunicação do dispositivo. Um ambiente virtual desaceleraria essas partes do programa.

De qualquer forma, os jogos 3D modernos de fato usam linguagens de nível superior. Muitas vezes, você encontrará a lógica do jogo escrita em linguagens como Lua ou Python. Mas o núcleo (E / S, threads, agendamento de tarefas) do jogo 3D típico será escrito em idiomas de baixo nível pelos próximos 25 anos ou enquanto os dispositivos não permitirem abstração e virtualização por si mesmos (que virá).

Concordo com os outros posts sobre como alavancar elementos de uma base de código, desempenho, etc. preexistentes / licenciados

Uma coisa que eu gostaria de acrescentar é que é difícil fazer truques desagradáveis ​​de DRM através de uma máquina virtual.

Também acho que há um componente de arrogância em que os gerentes de projeto pensam que podem criar código estável / confiável com C ++ com todas as vantagens de ter controle absoluto sobre suas ferramentas e recursos, MAS sem todos os negativos que complicam e atrapalham a concorrência porque "nós" são mais inteligentes do que são ".

O Runescape da Jagex é escrito em Java, a tag "video game" pode não se aplicar especificamente, pois é um jogo on-line, mas possui um número razoável de seguidores.

Já se falou muito sobre isso, você pode encontrar até no Wiki as razões ...

• C / C ++ para o mecanismo do jogo e todas as coisas intensivas.
• Lua ou Python para scripts no jogo.
• Java - desempenho muito ruim, uso de muita memória + não está disponível nos consoles de jogos (é usado em alguns jogos muito simples (sim, o Runescape conta aqui, não é Battlefield ou Crysis ou o que mais existe), apenas porque existem muitos programadores que conhecem essa linguagem de programação).
• C # - uso de memória grande (é usado para alguns jogos muito simples, apenas porque existem praticamente programadores que conhecem essa linguagem de programação).

E eu ouvi cada vez mais programadores Java que tentam convencer as pessoas de que o Java não é lento, não é lento para desenhar um widget na tela e desenhar alguns caracteres ASCII no widget, para receber e enviar dados pela rede (e é É recomendável usá-lo nesses casos (manipulação de dados de rede) em vez de C / C ++) ... Mas é muito lento quando se trata de coisas sérias, como cálculos matemáticos, alocação / manipulação de memória e muitas dessas coisas boas.

Lembro-me de um artigo no site do MIT onde eles mostram o que o C / C ++ pode fazer se você usar os recursos de linguagem e compilador: Um multiplicador de matriz (2 matrizes), 1 implementação em Java e 1 implementação em C / C ++, com recursos de C / C ++ e otimizações apropriadas do compilador ativadas, a implementação do C / C ++ foi ~ 296 260 vezes mais rápida que a implementação do Java.

Espero que você entenda agora por que as pessoas usam C / C ++ em vez de Java em jogos, imagine o Crysis em Java, não haveria nenhum computador neste mundo capaz de lidar com isso ... + A coleta de lixo funciona bem para Widgets que acabam de destruir uma imagem mas ainda está armazenado em cache e precisa ser limpo, mas não para jogos, com certeza, você terá ainda mais atrasos em cada ativação da coleta de lixo.

Edit : Como alguém pediu o artigo, aqui, procurei no arquivo da web para obter isso, espero que esteja satisfeito ... Estudo de caso do MIT

E para adicionar, não, o Java para jogos ainda é uma péssima idéia. Apenas alguns dias atrás, uma grande empresa que eu não citaria começou a reescrever seu cliente de jogo de Java para C ++ porque um jogo muito simples (em termos de gráficos) atrasava e aquecia os laptops i7 com as poderosas placas de vídeo da geração nVidia GT 5xx e 6xx ( não apenas na nVidia, o ponto aqui é que essas placas poderosas que podem lidar com as configurações de Max na maioria dos jogos novos e não com esse jogo) e o consumo de memória foram de ~ 2,5 a 2,6 GB de RAM. Para gráficos tão simples, ele precisa de uma máquina animal.