Por que o Java não é mais amplamente usado para desenvolvimento de jogos? [fechadas]

Várias razões:

• Antigamente, você precisava de "acesso direto" para desempenho e interface do usuário. Isso antecede os idiomas da VM, como Java e C #.
• A maioria dos consoles (por exemplo, 360, PS3) não tem uma JVM, portanto, você não pode reutilizar o código da versão para PC. É muito mais fácil compilar o código C ++ para suportar vários dispositivos.
• A maioria dos mecanismos de jogos principais (por exemplo, Unreal) tem ligações C ++. Existem alguns conectores Java (por exemplo, para OpenGL), mas nada como isso.
• Para jogos em PC, o DirectX realmente não tem suporte strong a Java (se for o caso).
• Jogos baseados na Web são executados em JavaScript ou Flash. Você poderia escrevê-los em Java usando coisas como o GWT.
• O iPhone executa uma variante do Objective-C.

O Java é usado principalmente em jogos para Android atualmente, simplesmente porque é o idioma principal dessa plataforma.

Razões técnicas:

• A maioria dos melhores mecanismos de jogos em 3D são gravados em C / C ++. Isso é um grande negócio, já que a maioria dos desenvolvedores de jogos não querem comprometer seu mecanismo 3D, mas também não querem escrever um do zero. Java tem jMonkeyEngine que é open source e realmente muito bom mas ainda não pode competir com o Unreal Engine .
• Em algumas situações muito raras, há vantagens em obter "próximo ao metal" em linguagem C ou assembly, especificamente para acesso a recursos especiais de hardware. Isso não é tão importante hoje em dia, mas desenvolvedores de jogos profissionais ainda gostam de ter a opção .....
• O Java tem um garbage collected , tempo de execução gerenciado. 99% das vezes é uma grande vantagem, certamente torna a codificação mais fácil e menos propensa a erros e é uma das grandes razões pelas quais o Java é tão popular. No entanto, isso causa um problema de latência ocasional para os jogos, já que os ciclos de coleta de lixo podem causar pausas perceptíveis. Isso está ficando menos problemático com as JVMs mais recentes de baixa latência, mas ainda é um problema para jogos intensivos em gráficos, em que a manutenção de altos FPS é fundamental.

Razões não técnicas:

• As casas de desenvolvimento de jogos profissionais são investidas pesadamente em habilidades e tecnologias C / C ++. Isso cria uma enorme quantidade de inércia .
• A percepção irracional em grande parte que Java é lenta. Possivelmente verdade nos anos 90, definitivamente não é verdade agora - você pode certamente escrever um lucrativo jogo comercial 3D com Java ( Runescape , qualquer um? sobre Minecraft ?
• Uma percepção clara justa de que o Java está mais focado em aplicativos de negócios e na Web do que em jogos. Isso pode mudar com o crescimento do Mobile e a necessidade de mais desenvolvimento multi-plataforma, mas é certamente verdade no momento.

Curiosamente, há também algumas boas razões pelas quais os desenvolvedores de jogos devem considerar o Java:

• Portabilidade - à medida que o número de plataformas de destino se prolifera, o Java torna-se cada vez mais atraente com a sua capacidade praticamente inigualável de criar binários genuinamente inter-plataformas
• Ecossistema da biblioteca - com a exceção muito importante dos mecanismos de jogos em 3D, o Java tem a melhor variedade de bibliotecas de todas as plataformas. Rede, som, AI, processamento de imagens, armazenamentos de dados chave / valor, você nomeia o tópico e provavelmente há uma biblioteca Java de código aberto para ele.
• Desenvolvimento do lado do servidor - O Java é uma excelente plataforma / plataforma para o servidor e, à medida que mais jogos incorporam elementos massivamente multi-player, o lado do servidor se tornará cada vez mais importante. Java no Linux parece bastante atraente aqui como uma plataforma.
• A JVM - é provavelmente o melhor ambiente de execução de VM projetado no mundo, com fantástica coleta de lixo, compilador JIT, suporte a concorrência etc. Ele só vai melhorar e os desenvolvedores de jogos começarem a usar dinamicamente idiomas dentro de seus jogos, eles desejarão o melhor ambiente de tempo de execução possível.
• Outras linguagens JVM - O Java é um cavalo de trabalho sólido, mas a inovação real está acontecendo com os novos idiomas da JVM (Scala, Clojure em particular). Essas linguagens obtêm todas as vantagens da plataforma Java / JVM, plus elas são linguagens modernas extremamente poderosas.

Ok, há muita desinformação neste tópico.

Eu conheço o negócio do jogo extremamente bem, tendo estado nele por 25 anos. Eu também conheço muito bem o Java em jogos, tendo sido o evangelista técnico do Java Game da Sun e lecionando especialistas em programação de desempenho em Java.

Em termos de velocidade computacional, o Java supera o C ++ em muitos benchmarks de computação científica atuais. Você pode escrever código patológico em qualquer idioma que tenha um desempenho ruim, se quiser, mas no geral, eles estão no mesmo nível e há muito tempo.

Em termos de uso de memória, o Java tem alguma sobrecarga. HelloWorld é um programa 4K em java. Mas essa sobrecarga é bastante sem sentido nos sistemas atuais de vários GB. Finalmente, o Java tem mais de um tempo de inicialização. Eu não recomendaria usar o Java para utilitários de tempo de execução curtos, como comandos de linha de comando do Unix. Nesses casos, a inicialização dominará seu desempenho. Em um jogo, no entanto, é bastante insiginante.

O código do jogo Java corretamente escrito não sofre pausas no GC. Assim como o código C / C ++, requer algum gerenciamento de memória ativo, mas não o nível C / C ++. Contanto que você mantenha seu uso de memória para objetos de vida longa (persistir para um nível ou jogo inteiro) e objetos de vida muito curta (vetores e similares, passados e rapidamente destruídos após o cálculo), gc não deve ser um problema visível. p>

Em termos de acesso direto à memória, o Java tem isso há muito tempo; desde o Java 1.4 na forma de buffers de bytes diretos nativos. O bit twiddling em Java pode ser um pouco irritante devido à falta de tipos inteiros sem sinal, mas as rodadas de trabalho são todas bem conhecidas e não terrivelmente onerosas.

Embora seu verdadeiro Java nunca tenha uma ligação Direct3D, isso ocorre porque as tecnologias Java buscam a portabilidade. Ele tem DOIS enlaces OpenGL (JOGL e LWJGL) e ligação OpenAL (JOAL) e uma ligação de entrada portátil (JInput) que liga sob o capô a DirectInput no Windows, o HID Manager no OSX e uma ligação do Linux (esqueci quais). / p>

É verdade que nenhum mecanismo de jogo completo incluiu o Java, como o Unity, tem o C # e isso é uma fraqueza no espaço independente. Por outro lado, havia dois bons APIS de nível Scenegraph que eram totalmente portáveis em plataformas em Windows, OSX e Linux. Ambos escritos por Josh Slack, o primeiro foi chamado JMonkey engine e o segundo Ardor3D.

O primeiro pôster está correto ao afirmar que as duas maiores coisas que fizeram Java voltar ao desenvolvimento de jogos foram o preconceito e a portabilidade. Este último foi o maior problema. Embora você possa escrever um jogo Java e enviá-lo para o Windows, OSX e Linux, nunca houve uma VM de console. Isso ocorreu devido à total inépcia no gerenciamento médio da Sun. Os poucos de nós que trabalhavam com Java em jogos realmente tinham acordos com a Sony não menos que 3 vezes para obter uma VM em um Playstation e todas as 3 vezes que a gerência intermediária da Sun a matou.

Embora a Sun tenha flertado com tecnologias de clientes, o fato é que o gerenciamento da Sun nunca recebeu produtos de consumo. É por isso que o Java como uma linguagem de cliente da Sun nunca teve sucesso em nenhuma forma, e por que o Google e a Dalvik (a VM semelhante a Java do Android) tornaram o Java um sucesso de plataforma em qualquer lugar.

E é por isso que eu codifico jogos em C # hoje. Porque Mono foi onde a gerência da Sun se recusou.

O Java é ótimo para lógica de negócios, servidores e código independente de plataforma que precisa ser executado de forma confiável. Existem vários fatores pelos quais o Java não é usado com frequência em jogos:

• verificação de limites & outros mecanismos de segurança (diferença de desempenho marginal nos dias de hoje)
• ter que converter entre estruturas de dados C ++ e estruturas de dados Java (não é possível copiar apenas memória entre buffers)
• muitos dos livros e tutoriais acompanham a multidão, por isso é difícil encontrar informações de desenvolvimento de jogos que não sejam C ++
• as principais bibliotecas gráficas (DirectX e OpenGL) e muitos mecanismos de prateleira são baseados em C / C ++
• muitos jogos tentam ser executados o mais rápido possível para que possam adicionar mais recursos visualmente atraentes

Não é fácil trabalhar com bibliotecas C ++ de linguagens bytecode como Java (escrevendo uma camada JNI) e .net (muitos atributos marshalling / unmarhallhall, api / structure). Por isso, adiciona um pouco de trabalho para pouco benefício.

Uma nota lateral: alguns servidores de jogos usam Java.

Post semelhante aqui : link

O Java não é rápido o suficiente para a maioria dos desenvolvimentos de jogos. É muito mais lento do que usar o C ++ / Assembly, que é o padrão. É a mesma razão pela qual mais desenvolvimento de jogos não é feito usando C # ou VB. Os desenvolvedores de jogos precisam e planejam até o último ciclo de clock que eles possam obter para cálculos de física, lógica de IA e interações de ambiente.

Para jogos mais simples, o Java pode ser usado de forma bastante eficaz. Se você quiser criar um clone do Tetris ou Bejeweled, ou algo mais desse nível de detalhe, então o Java funcionaria bem. Mas Java não pode criar jogos como Halo, Medal of Honor, Command & Conquiste e assim por diante e torne-o jogável. Pelo menos como existe hoje em dia.

E os motivos que você relacionou em sua pergunta também são válidos. Exceto, creio, pela falta de desenvolvedores de jogos com experiência em Java. Muitos jogos em telefones e outros dispositivos portáteis são escritos em Java (incluindo a maioria dos jogos Android), e alguns dos jogos são excelentes. Então eu acho que há uma base decente e crescente de desenvolvedores de jogos com conhecimento em Java.

O pensamento está mudando a capacidade de usar essas linguagens de nível superior para alguns dos jogos mais avançados. Por exemplo, um dos meus jogos favoritos, o Auran's Train Simulator, é escrito com grandes partes em C # e funciona muito bem. Então a base está crescendo e continuará a evoluir.

Os jogos modernos são todos sobre gráficos 3D que acontecem em hardware para fins especiais.

Mesmo em 2002, Jacob Marner encontrou em seu relatório "Avaliando Java para Desenvolvimento de Jogos" que Java era bastante utilizável para jogos, exceto para as partes dependentes de desempenho, e devido à robustez da linguagem e da JVM subjacente era mais barato fazer assim.

link

É minha opinião pessoal que com o progresso que aconteceu desde então, especialmente em gráficos 3D, e com as excelentes ligações ao OpenGL et al, que esta desvantagem é muito menos pronunciada nos dias de hoje.

Por isso, o problema deve estar em outro lugar. Uma razão provável é o tamanho do Java runtime (que é muito menos um problema nos dias de hoje com jogos multi-DVD) e outro a inércia do código existente. É notoriamente frágil começar a trabalhar com código nativo em Java. Uma terceira razão é o que os desenvolvedores de estrelas fazendo os jogos estão familiarizados. Um quarto é se o Java está disponível na plataforma.

Uma coisa é certa - a maioria dos jogos está sendo roteirizada em vez de ter tudo gravado em código C desde o início, e você quer o melhor tempo de execução sob sua linguagem de script. Atualmente, isso significa essencialmente o CLR ou a JVM.

Os desenvolvedores de jogos gostam de estar perto do metal e geralmente escrevem seus apertados loops internos na montagem. Java não oferece o mesmo nível de desempenho possível, tanto em termos de velocidade consistente quanto de uso de memória (executar um JIT tem seu preço).

Eu acho que o fator limitante para a maioria das pessoas é a (falta de) disponibilidade de bons mecanismos de jogos. Para ir muito longe, precisamos ver por que eles não estão disponíveis.

Eu olharia isso da outra direção por um momento. Desenvolver um mecanismo de jogo (por exemplo) é um lote de trabalho. Quem se beneficiaria o suficiente com o desenvolvimento de um para investir tempo e esforço para fazê-lo?

A maioria dos candidatos óbvios para o desenvolvimento semelhante a framework em / para Java (por exemplo, IBM, Oracle) parece ter zero interesse em jogos. Os candidatos óbvios ao desenvolvimento de jogos (por exemplo, Id, EA) parecem ter quase igualmente pouco interesse em Java.

Quase o candidato somente que eu acho que parece razoável seria o Google. A principal linguagem de desenvolvimento para o Android é o Java, e incentivar o desenvolvimento de jogos para o Android poderia fornecer uma vantagem real para a plataforma.

A pergunta é a de perguntar algo nas linhas de:

O que é melhor para alimentar seu carro, um motor de barco ou um motor a jato?

Tudo se resume a escalabilidade, prevenção de erros, velocidade, assinatura de memória, modularidade e muitas outras coisas. A questão não deve ser sobre o que é melhor como um padrão da indústria, a questão deve ser "o que é melhor para mim" como no que você sabe ou quão bem você sabe disso. Se ele faz o trabalho, então ele faz o trabalho, se você realmente pode vender a idéia, então funciona e quem sabe você pode até dobrar algumas colheres.

O Java não foi feito com o desenvolvimento do jogo em mente, o Java foi feito para ser uma linguagem "para a web".

Quanto ao desenvolvimento de jogos, a Sun realmente não suportava Java como uma linguagem de desenvolvimento de jogos como o Microsoft suportado pelo C #.

Acho que a falta de frameworks de desenvolvimento de jogos atraentes é o que realmente matou o Java nesse aspecto.

É mais fácil colar C mais diretamente em novos hardware e drivers não convencionais. Quanto mais cedo e mais perto um programador de jogos puder chegar ao hardware, melhor eles poderão superar os jogos concorrentes. Os programadores de jogos posteriores apenas seguem a mesma metodologia e ferramentas que os jogos anteriores.

Para jogos em que a otimização para o hardware mais recente é menos importante, como jogos casuais de telefone celular, usar o C dessa maneira é menos importante do que a maior portabilidade do Java.

Para algumas pessoas, o motivo não tem nada a ver com velocidade, bibliotecas ou disponibilidade. É simplesmente por causa da própria linguagem. Algumas pessoas simplesmente não gostam da linguagem Java. Outras pessoas preferem usar sua linguagem de programação favorita em vez de usar o Java para criar jogos.

It could of course be something else. Could someone who knows the business better than me explain why Java isn't getting momentum when it comes to game development?

É uma linguagem de interpretação, isto é, lenta. Você está lidando com placa gráfica e gráfica que é hardware. O que é uma boa linguagem para lidar com hardware? Bem C ++, é muito baixo, e você lida com ponteiros e tudo mais.

Se você quiser exibir gráficos malucos como crysis e o que for que você não fará Java por ele.

Não apenas isso, a Oracle é proprietária do Java, mas o pensamento de que uma empresa pode processá-lo não é bem ousado. Especialmente quando você quer construir seu próprio intérprete para JAVA para direcionar os jogos sem ser processado devido a FUD de fragmentação.