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

77

Não sou desenvolvedor de jogos nem nada, mas sei que o Java não é muito usado no desenvolvimento de jogos. O Java deve ser rápido o suficiente para a maioria dos jogos, então onde está o problema? Eu posso pensar em alguns motivos:

Falta de desenvolvedores de jogos com experiência em Java
Falta de boas estruturas de desenvolvimento de jogos
Os programadores não querem aceitar Java como uma linguagem de programação de jogos. A maioria só aceita C ++ como isso?
Não há suporte para consoles de jogos (embora o mercado de PCs ainda exista)

Claro que poderia ser outra coisa. Alguém que conhece os negócios melhor do que eu poderia explicar por que o Java não está ganhando impulso no que diz respeito ao desenvolvimento de jogos?

java game-development

— Anto
fonte

37

E agora aguarde todas as respostas "Java é lento, C ++ é rápido" que realmente tocam a superfície do problema de uma maneira excessivamente ampla e completamente correta. Esteja ciente de que as pessoas que respondem dessa maneira quase certamente não são desenvolvedores de jogos profissionais.

— Ed S.

20

De fato, Java é usado para desenvolvimento de jogos; ou seja, no mercado móvel. Java ME, Android.

— precisa saber é o seguinte

21

Por que deveria ser usado? O que o Java oferece a um desenvolvedor de jogos, que as linguagens mais usadas não possuem? O Java fornece ecossistemas extremamente ricos para os desenvolvedores de aplicativos de negócios, que superam suas deficiências como linguagem, mas quando se trata de desenvolvimento de jogos, a plataforma Java oferece poucas ferramentas em comparação com várias alternativas.

— precisa saber é o seguinte

14

Curiosamente, o Minecraft é baseado em Java.

— Uri

5

@ Codificador Parece que o código C ++ foi fortemente otimizado, mas o código Java não. Portanto, é uma comparação inválida.

— Izkata

94

Várias razões:

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

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

— Uri
fonte

14

+1 "A maioria dos consoles (por exemplo, 360, PS3) não possui uma JVM, portanto, não é possível reutilizar o código da versão para PC. É muito mais fácil compilar o código C ++ para suportar vários dispositivos" Se o dispositivo não tiver o tempo de execução , você não verá jogos desenvolvidos com base nesse tempo de execução indisponível. O Xbox 360 e o Windows phone gerenciaram os tempos de execução da .Net, portanto, o desenvolvimento de jogos é possível e, provavelmente, uma tendência crescente. No entanto, como o tempo de execução não está nas outras plataformas principais (PS3 e, em menor grau, no Wii), é difícil justificar uma base de código completamente separada. Realmente não é um problema de desempenho.

— JustinC 6/03

2

Chama-se XNA, que atualmente é um subconjunto da estrutura .Net 2.0. Existem outros frameworks interessantes na natureza: MonoXNA, MonoTouch e XnaTouch, entre outros.

— 23611 JustinC

7

A previsibilidade do desempenho não é possível com uma JVM.

— Klaim

5

Muito bons pontos. No entanto, acrescentaria o fato de que o GC pode causar pausas / carregamento imprevisíveis. Se isso não é um problema para aplicativos de servidor, é para um jogo em tempo real. Por exemplo, isso é visível em minecraft.

— deadalnix

2

@Klaim Também não é possível com mallocou new, portanto, se isso for uma preocupação, você implementará o pool, não importa o quê. Independentemente desse ponto, um grande problema do Java é que ele não suporta tipos de valor, ao contrário do C #.

— Doval

80

Razões técnicas:

A maioria dos melhores mecanismos de jogos em 3D é escrita em C / C ++. Isso é muito importante, já que a maioria dos desenvolvedores de jogos não quer comprometer seu mecanismo 3D, mas também não quer escrever um do zero. O Java tem o jMonkeyEngine, que é de código aberto e realmente muito bom, mas ainda não pode competir com o Unreal Engine .
Para algumas situações muito raras, há vantagens em se aproximar do metal em linguagem C ou assembly, especificamente para acessar recursos especiais de hardware. Isso não é tão importante hoje em dia, mas os desenvolvedores profissionais de jogos ainda gostam de ter a opção ...
Java tem um lixo coletado , tempo de execução gerenciado. 99% das vezes, essa é 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, causa um problema de latência ocasional nos jogos, pois os ciclos de coleta de lixo podem causar pausas visíveis. Isso está ficando menos problemático com as JVMs de baixa latência mais recentes, mas ainda é um problema para jogos graficamente intensivos, em que a manutenção de um FPS alto é fundamental.

Razões não técnicas:

As casas profissionais de desenvolvimento de jogos são investidas pesadamente em habilidades e tecnologias C / C ++. Isso cria uma enorme quantidade de inércia .
A percepção amplamente irracional de que o Java é lento. Possivelmente verdade nos anos 90, definitivamente não é verdade agora - você certamente pode escrever um jogo 3D comercial e lucrativo com Java ( Runescape alguém? Ou o Minecraft ?)
Uma percepção bastante 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 entre plataformas, mas certamente é verdade no momento.

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

Portabilidade - à medida que o número de plataformas de destino se prolifera, o Java se torna cada vez mais atraente, com a capacidade praticamente sem paralelo de criar binários genuinamente entre plataformas
Ecossistema de bibliotecas - com a exceção muito importante dos mecanismos de jogos em 3D, Java possui a melhor variedade de bibliotecas em geral de qualquer plataforma. Rede, som, IA, processamento de imagem, armazenamento de dados de chave / valor, o nome do tópico e provavelmente há uma biblioteca Java de código aberto.
Desenvolvimento do lado do servidor - Java é uma ótima linguagem / plataforma para o servidor e, à medida que mais jogos incorporam elementos massivamente para vários jogadores, o lado do servidor se torna cada vez mais importante. Java no Linux parece bastante atraente aqui como uma plataforma.
A JVM - é provavelmente o ambiente de execução de VM mais bem projetado do mundo, com fantástica coleta de lixo, compilador JIT, suporte a simultaneidade etc. Isso só vai melhorar e, à medida que os desenvolvedores de jogos começam a usar linguagens dinâmicas em seus jogos, eles desejam o melhor ambiente de tempo de execução possível.
Outras linguagens da JVM - Java é uma base sólida de trabalho, mas a inovação real está acontecendo com as novas linguagens da JVM (Scala, Clojure em particular). Essas linguagens obtêm todas as vantagens da plataforma Java / JVM, além de serem linguagens modernas extremamente poderosas.

— Mikera
fonte

19

Não, a protabilidade não é melhor em Java no mundo dos videogames. A maioria dos console não possui uma JVM. Por motivos de portabilidade, o C ++ é preferível ao java no mundo dos videogames.

— deadalnix

5

Por que o ecossistema de bibliotecas é um bônus para Java? Rede, som, pares de valores-chave - isso não é uma coisa; que está disponível em todos os lugares hoje em dia. Na verdade, eu argumentaria que a IA e o processamento de imagens são muito mais fáceis com as bibliotecas C / C ++ (fann, OpenCV).

— MrFox

4

Mais importante que o FPS, talvez eu enfatizasse taxas de quadros consistentes . Posso ter o meu jogo rodando a 100FPS, mas se alguns desses quadros demorarem meio segundo, isso simplesmente não funcionará. Mesmo se o GC for rápido, se causar irregularidades visíveis, ainda será um problema. (Isto fala nada para o desempenho de Java em particular, apenas um problema geral para se manter em mente)

— Gankro

1

Escrevi um jogo de tiro em primeira pessoa em Java e nunca tive problemas com o coletor de lixo, mesmo quando não o utilizava com baixa latência. De qualquer forma, quando a memória não está alocada no heap Java, cabe a mim lidar com isso sem o coletor de lixo e a maior parte da minha pegada de memória vem dos VBOs. Em outros termos, a coleta de lixo não é um problema, porque funciona quando é usada para o que foi projetada e não cabe a lidar com objetos grandes na GPU ou na pilha nativa (! = Pilha Java). Não culpe uma bigorna por não ser um meio eficiente de escovar os dentes.

— precisa saber é o seguinte

1

@deadalnix O mundo dos videogames não é apenas composto pelos consoles.

— precisa saber é o seguinte

27

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

Eu conheço o negócio de jogos extremamente bem, tendo estado nele por 25 anos. Eu também conheço Java em jogos extremamente bem, tendo sido o evangelista técnico da Sun Game em Java e lecionando como especialista 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 atualmente. Você pode escrever um 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 estão por um longo tempo.

Em termos de uso de memória, Java tem alguma sobrecarga. HelloWorld é um programa 4K em java. Mas essa sobrecarga não faz muito sentido nos sistemas atuais de vários GB. Finalmente, Java tem mais tempo de inicialização. Eu não recomendaria o uso de 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 insigrante.

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

Em termos de acesso direto à memória, Java tem isso há muito tempo; desde o Java 1.4 na forma de buffers nativos de bytes diretos. A modificação de bits no Java pode ser um pouco irritante devido à falta de tipos inteiros não assinados, mas as rodadas de trabalho são bem conhecidas e não são terrivelmente onerosas.

Embora seu verdadeiro Java nunca tenha sido vinculado ao Direct3D, é porque as tecnologias Java buscam a portabilidade. Possui DUAS ligações OpenGL (JOGL e LWJGL) e OpenAL (JOAL) e uma ligação de entrada portátil (JInput) que se vincula ao DirectInput no Windows, HID Manager no OSX e uma ligação do Linux (eu esqueço).

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

O pôster principal está correto que as duas maiores coisas que atrasaram o Java no desenvolvimento de jogos foram preconceito e portabilidade. Este último foi o maior problema. Embora você possa escrever um jogo Java e enviá-lo para Windows, OSX e Linux, nunca houve uma VM de console. Isso ocorreu devido à total inaptidão na gerência intermediária da Sun. Os poucos de nós que trabalhamos em Java em jogos realmente negociaram com a Sony nada menos que três vezes para obter uma VM em um Playstation e todas as três vezes em que a gerência média da Sun a matou.

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

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

— user430788
fonte

8

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

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

Não é fácil trabalhar com bibliotecas C ++ de linguagens de bytecode como Java (gravando uma camada JNI) e .net (muitos atributos de empacotamento / desmarcação, api / estrutura). Por isso, acrescenta bastante trabalho para pouco benefício.

Uma observação: alguns servidores de jogos usam Java.

— Graeme Wicksted
fonte

Você não precisa escrever JNI, basta usar o JogAmp ou qualquer biblioteca semelhante.

— precisa saber é o seguinte

Bom ponto. Eu usei o JOGL e o JMonkeyEngine em Java. Mais recenlty em eu usei XNA / MonoGame para DirectX e OpenTK para OpenGL com nvorbis / naudio / openal em C #. E eles funcionam muito bem para jogos pequenos e médios, especialmente quando se trabalha com shaders. Grande melhoria na produtividade em C ++. Então, seu único problema real é o mesmo que qualquer linguagem baseada no GC: impedindo / mitigando o GC. Ele interromperá sua taxa de quadros periodicamente, assim você desejará matrizes de tamanho fixo, alocações estáticas ou buffers de longa duração que podem ser lançados quando o jogo estiver parado (menus, carregamento, cinemática).

— Graeme Wicksted

Eu uso o JOGL desde 2006 e não tive esse tipo de problema, mesmo em hardware muito baixo no ambiente de desktop. O coletor de lixo não é o culpado porque os objetos maiores geralmente estão na RAM da GPU ou na pilha nativa (geralmente os buffers diretos da NIO), o primeiro não é gerenciado pela coleta de lixo "normal" e o segundo não é ' • Gerenciado diretamente pela coleta de lixo "normal", pois cuida dos objetos Java no heap Java. Cabe ao desenvolvedor liberar a memória alocada no heap nativo com eficiência.

— precisa saber é o seguinte

Na minha humilde opinião, o problema vem de algumas "otimizações" imaginadas por programadores que não estão em uma mentalidade Java que impedem que o coletor de lixo faça seu trabalho. Se você mantiver algumas referências fortes em alguns objetos Java inúteis vinculados a alguns recursos nativos, o coletor de lixo nunca os considerará recuperáveis. A alocação fora da pilha pode ser útil em alguns casos, mas se você abusar dela, seus recursos de longa duração permanecerão na memória e você não poderá criar novos objetos.

— precisa saber é o seguinte

Alguns programadores de jogos preferem alocar buffers enormes no início, cortando-os em tempo de execução e gerenciando essa memória sozinhos, mas provavelmente farão pior que o sistema operacional e, em seguida, Java gastará muito tempo para liberar espaço para criar novos objetos. Evitar o vazamento de memória não é mais difícil em Java e uma solução mais viável consiste em rastrear apenas os objetos cuja memória não está alocada no heap Java para liberá-los em um momento apropriado (durante uma pausa, ao alternar de um nível para outro) , ...), não tem nada a ver com o coletor de lixo.

— precisa saber é o seguinte

5

Java não é rápido o suficiente para a maioria dos jogos. É muito mais lento do que usar C ++ / Assembly, que é o padrão. É a mesma razão pela qual o desenvolvimento de jogos não é feito usando C # ou VB. Os desenvolvedores de jogos precisam e planejam todos os ciclos do relógio em que podem trabalhar, como cálculos de física, lógica de IA e interações com o ambiente.

Para jogos mais simples, o Java pode ser usado com bastante eficiência. Se você deseja criar um clone do Tetris ou um Bejeweled, ou qualquer outra coisa com esse nível de detalhe, o Java funcionaria bem. Mas o Java não pode criar jogos como Halo, Medal of Honor, Command & Conquer, etc., e torná-lo jogável. Pelo menos como existe hoje em dia.

E os motivos que você lista na sua pergunta também são válidos. Exceto, eu acho, 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 para Android), e alguns são excelentes. Então, acho que há uma base decente e crescente de desenvolvedores de jogos com conhecimento em Java.

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

— BBlake
fonte

17

Você deixa de fora um dos pontos mais importantes; a grande maioria das ferramentas e das APIs usadas seria escrita em C ++ e reescrevê-las para trabalhar com Java ou qualquer outra linguagem seria muito trabalhosa. Além disso, sua generalização de que "[Java é] muito mais lento que usar C ++ / Assembly " é muito ampla para ser precisa. Assembly não é usado com a frequência que você pensa em jogos para PC, porque um bom compilador provavelmente gerará código mais eficiente do que você escreverá assembler. No entanto, é necessário o uso determinístico de recursos e a capacidade de acertar no hardware.

— Ed.

15

Alguém realmente precisa criar um exemplo melhor dos recursos do Java que o Minecraft. Até que alguém possa criar o equivalente a WoW, C&C, MOH ou Starcraft em Java ou C #, continuarei mantendo o que disse.

— precisa saber é o seguinte

12

"O assembly não é usado com a frequência que você pensa em jogos para PC, porque um bom compilador provavelmente gerará código mais eficiente do que você escreverá o assembler." Essa é outra generalização. Ainda não vi um compilador capaz de gerar melhor linguagem de máquina IA32 do que um programador de linguagem assembly IA32 experiente. Compiladores geram código para uma máquina abstrata que é mapeada para uma máquina de destino. Um programador de linguagem assembly aproveita ao máximo o processador subjacente, incluindo expressões idiomáticas da máquina.

— precisa saber é o seguinte

10

Não esqueça o uso da memória. O uso da memória é provavelmente mais importante que a velocidade. Java não foi projetado para controle direto de memória como C ++ e o coletor de lixo significa que o uso de memória é sempre significativamente maior que C ++ para a mesma tarefa.

— Matthew Leia

9

Isso não é 1985. Temos mais de 640k de memória, processadores melhores que 50 mghz e mais de 1,44 mbs de armazenamento removível. O desafio dos desenvolvedores de jogos hoje não é o mesmo de 25 anos atrás. Vá em frente e encontre um exemplo de código x86 / ou ia64 criado à mão para um jogo moderno. Certos mitos estão completamente errados. O desafio é a portabilidade e clientes de nível inferior usando ambientes operacionais relativamente antigos. Menos denominador comum vs imersão convincente.

— 1111 JustinCelebr1:

5

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

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

http://java.coe.psu.ac.th/FreeOnline/Evaluating%20Java%20for%20Game%20Development.pdf

É minha opinião pessoal que, com o progresso que ocorreu desde então, especialmente nos gráficos 3D, e com as excelentes ligações com OpenGL et al, essa desvantagem é muito menos acentuada atualmente.

Portanto, o problema deve estar em outro lugar. Uma razão provável é o tamanho do tempo de execução Java (que é muito menos um problema nos dias de hoje com jogos com vários DVDs) e outra a inércia do código existente. É notoriamente frágil começar a trabalhar com código nativo em Java. Um terceiro motivo é o que os desenvolvedores famosos que estão fazendo os jogos estão familiarizados. Um quarto é se o Java está disponível na plataforma.

Porém, uma coisa é certa - a maioria dos jogos passa a ser programável em vez de ter tudo gravado no código C desde o início, e você deseja o melhor tempo de execução embaixo da sua linguagem de script. Atualmente, isso significa essencialmente o CLR ou a JVM.

— user1249
fonte

1

oddlabs.com/technology.php - " Baseamos nosso desenvolvimento na combinação de LWJGL e Java, que permite que o jogo seja executado em qualquer plataforma suportada por LWJGL sem modificações e a uma velocidade comparável ao código nativo dependente da plataforma".

O Jake2 superou o Quake2 há mais de 10 anos. Não estamos mais em 2002.

— gouessej

4

Os desenvolvedores de jogos gostam de estar próximos do metal e geralmente escrevem seus apertados circuitos internos na montagem. Java não oferece o mesmo nível de desempenho possível, em termos de velocidade consistente ou uso de memória (a execução de um JIT cobra seu preço).

— dan_waterworth
fonte

4

Eu acho que o fator limitante para a maioria das pessoas é a (falta de) disponibilidade de bons mecanismos de jogo. Para ir muito longe, precisamos analisar 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) é muito trabalhoso. Quem se beneficiaria o suficiente com o desenvolvimento de um para investir tempo e esforço para fazê-lo?

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

Quase o único candidato que consigo pensar que parece razoável seria o Google. A principal linguagem de desenvolvimento para o Android é Java, e o incentivo ao desenvolvimento de jogos para Android pode fornecer uma vantagem real para a plataforma.

Até onde eu sei, eles ainda não o fizeram (ainda?), O que deixa alguns limites bastante severos para quase todo mundo. Sem muito no caminho dos mecanismos de jogos modernos e de alto desempenho para usar o desenvolvimento em Java, significa um pouco de trabalho extra, com (o que me parece) poucas perspectivas de produzir muitos benefícios em troca desse trabalho extra.

— Jerry Coffin
fonte

Acho que você encontrou um problema importante com os mecanismos de jogo - acho que esse é o maior motivo pelo qual o Java não alcançou o C / C ++. É possível que o código aberto possa nivelar um pouco o campo de jogo - fiquei muito impressionado com o jMonkeyEngine ( jmonkeyengine.com ).

— Mikera #

e não esqueça que os desenvolvedores de jogos são extremamente conservadores em geral (tecnicamente), e a maioria das grandes lojas (influentes) existe há décadas e são centradas em C (++) / ASM, portanto, não investirão no desenvolvimento de Java, pois isso significaria um investimento extenso de tempo, dinheiro e outros recursos antecipadamente, quando uma arquitetura C (++) / ASM inteira estivesse pronta para ser lançada.

— Jwenting

1

A questão está no mesmo nível de perguntar algo nas linhas de:

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

Tudo se resume a escalabilidade, prevenção de erros, velocidade, assinatura de memória, modularidade e uma série de coisas. A questão não deve ser sobre o que é melhor como padrão do setor, a questão deve ser "o que é melhor para mim", como o que você sabe ou o quão bem você o conhece. Se ele faz o trabalho, ele faz o trabalho; se você pode realmente vender a idéia, ela funciona e quem sabe você pode até dobrar algumas colheres.

— Meh
fonte

0

O Java não foi feito com o desenvolvimento de jogos 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, pois a Microsoft apoiava o C #.

Eu acho que a falta de estruturas de desenvolvimento de jogos convincentes é o que realmente matou o Java nesse aspecto.

— Mahmoud Hossam
fonte

3

Mas o C ++ também não foi feito como linguagem de jogos, mas como linguagem de programação de sistemas, como C. E a Sun realmente fez algum esforço no Java como linguagem de jogos, acho que eles estavam cooperando com a Sony para levar o Java ao PS2 ou alguma coisa, mas isso nunca aconteceu ...

— Anto 05/03

1

@ Phobia: Mas foi projetado para programação de sistemas.

— Anto

1

@ Phobia: Estou dizendo que é uma linguagem de programação de uso geral , assim como C ++. Na sua resposta, você diz que o Java não foi projetado como uma linguagem de programação de jogos, mas você esquece que o C ++ também não é projetado como tal.

— Anto

2

@ Joe Blow: Na página da Wikipedia sobre C: "Embora o C tenha sido projetado para implementar o software do sistema , ele também é amplamente utilizado para o desenvolvimento de aplicativos portáteis". Eu acho isso bem claro, não é?

— Anto

2

@ Phobia Sinto muito pelas suas preferências pessoais, mas elas são completamente irrelevantes para a discussão. Além disso, não quero contestar que hoje em dia o C ++ seja usado quase exclusivamente na programação de aplicativos. Não é sobre isso que trata esta discussão. Você afirma que o Java foi projetado com a programação da Web em mente. Bem, o C ++ foi projetado com a programação de sistemas em mente. Diz seu designer. Fim de discussão.

— Konrad Rudolph

-1

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

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

— hotpaw2
fonte

-4

Para algumas pessoas, a razão 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 Java para criar jogos.

— Eco
fonte

este lê mais como um comentário, consulte Como responder

— mosquito

-8

Claro que poderia ser outra coisa. Alguém que conhece os negócios melhor do que eu poderia explicar por que o Java não está ganhando impulso no que diz respeito ao desenvolvimento de jogos?

É uma linguagem de interpretação, ou seja, lenta. Você está lidando com placas gráficas e gráficas que são de hardware. Qual é uma boa linguagem para lidar com hardware? Bem, C ++, é bem baixo, e você lida com indicadores e o que for.

Se você deseja criar gráficos malucos como o crysis e o que quer que seja, não fará o Java por ele.

Além disso, a Oracle possui Java, o pensamento de que uma empresa pode processar você não é muito ousado. Especialmente quando você deseja criar seu próprio intérprete para JAVA para segmentar jogos sem ser processado devido à fragmentação do FUD.

— mythicalprogrammer
fonte

1

Você deve ler seriamente sobre compilação JIT, e olhar para alguns pontos de referência, onde Java é colocado contra a C ++

— Anto

1

Quem diabos votou nesta resposta? Toda essa questão está se tornando incrivelmente ridícula! Minha nossa.

— Fattie

7

@ Joe A resposta está errada. Java não é interpretado.

— Konrad Rudolph

3

@ Anto Esqueça esses benchmarks tolos. C ++ é uma ordem de magnitude mais rápida que Java, onde é importante, consulte programmers.stackexchange.com/questions/29109/29136#29136 e programmers.stackexchange.com/questions/368/13888#13888 .

— Konrad Rudolph

1

@ Anto O que eu devo olhar? Rapidez? C ++. Uso de memória? C ++. Olhe minecraft e tente hospedar um servidor e veja quanta memória o jogo está ocupando. Java consome muito mais memória versus C ++. Fazendo um jogo online, eu imagino que é bastante difícil em Java. Todos os benchmarks que eu vi até agora Java consomem mais memória, agora ter um jogo mmorpg em que o servidor central é codificado em java só soa bem se você ignorar o aspecto da memória ou alterar a definição de maciço no MMORPG.

— Mythicalprogrammer