O Java é uma boa escolha para jogos multiplataforma? [fechadas]

13

Estou procurando criar um jogo em Java e gostaria que ele funcionasse no Windows, Linux e Mac. Tenho certeza de que o C # é uma má escolha para isso e não tenho experiência suficiente em C ou C ++. Eu quero ficar longe do Flash. Portanto, o Java é uma boa escolha para mim? Principalmente, uso C # e acho que o Java é semelhante, portanto, presumo que não será tão difícil de aprender. Mas é rápido o suficiente? Existe uma linguagem mais adequada para minhas necessidades do que Java?

CommunistPancake
fonte
8
Depende do estilo de jogo que você deseja fazer. Dependendo do estilo desejado, pode ser que o HTML5 e algum javascript funcionem para você, se não o java.
Patrick Hughes
A Oddlab vende jogos baseados em Java, por exemplo, Tribal Trouble. Você pode ver detalhes de seu motor em oddlabs.com/technology.php
5
O Minecraft é um ótimo exemplo de um jogo multiplataforma escrito em Java. Quando nosso rapaz tem seus amigos para uma sessão séria do Minecraft, eles estão jogando no OSX, Windows e Linux.
Kev
Dois anos depois, o C # agora é bastante bom para essas coisas com a ajuda do mecanismo Unity e / ou Monogame, ambos compatíveis com iOS, Android e WP8.
Magus

Respostas:

28

Java é extremamente adequado para a criação de jogos multiplataforma. Vantagens principais:

  • Portabilidade - Em geral, você pode escrever um jogo em Java e esperar que ele continue inalterado na maioria das plataformas. É provavelmente a opção mais portátil de qualquer idioma - C / C ++ é a outra opção altamente portátil, mas precisa ser recompilada para cada plataforma e, em muitos casos, as bibliotecas têm recursos específicos da plataforma que limitam a portabilidade.
  • Desempenho - o código Java, se bem escrito, terá um desempenho semelhante ao de qualquer outra linguagem, incluindo C / C ++. O compilador JVM JIT é extremamente bom. Você pode escrever um jogo de alta qualidade e sucesso em Java (Minecraft, por exemplo).
  • Bibliotecas - há uma enorme variedade de bibliotecas disponíveis para Java que cobrem quase todos os recursos que você pode querer em jogos, desde redes a gráficos, sons e IA. A maioria das bibliotecas Java é de código aberto.

A principal decisão que você terá que tomar é qual estrutura de GUI você usará. Existem algumas opções diferentes, mas as mais importantes são:

  • jMonkeyEngine - mecanismo 3D completo. Se você deseja fazer um jogo em 3D, esta provavelmente é a sua melhor escolha - contém muitos recursos do mecanismo de jogo, como gráficos de cena, geração de terreno etc.
  • LWJGL - uma biblioteca de nível mais baixo com acesso direto ao OpenGL. É provável que o atraia se você deseja desempenho máximo e não se importa de escrever muito do seu mecanismo a partir do zero.
  • Swing - tem a vantagem de ser extremamente portátil e está incluído no tempo de execução Java, portanto não precisa de uma dependência extra. É bom para jogos 2D não intensivos em gráficos (jogos de estratégia, jogos de cartas etc.)
  • Slick - uma biblioteca de jogos 2D baseada em LWJGL. Provavelmente bom se você quiser escrever um jogo em 2D, mas ainda precisar de um bom desempenho gráfico (shoot-em-ups, jogos de plataforma com rolagem etc.)
  • JavaFX - projetado para aplicativos avançados da Internet, mais ou menos como o Flash. Tem muitos recursos interessantes que seriam bons para jogos, embora eu ainda não o tenha visto muito usado. O JavaFX 2.0, em particular, parece bastante promissor.

As principais desvantagens do Java para jogos são realmente os "casos extremos" que provavelmente não afetarão você, mas são relevantes para algumas classes de jogos:

  • Disponibilidade do mecanismo 3D - embora as ferramentas e os mecanismos listados acima sejam bons, eles ainda não alcançam o nível dos mecanismos C / C ++, como o Unreal Engine, usado por empresas profissionais de jogos. Portanto, o Java possivelmente não será sua primeira escolha se você estiver tentando desenvolver um grande FPS com um orçamento de vários milhões - o C / C ++ ainda vence aqui.
  • A coleta de lixo Java da latência do GC é, em geral, um grande benefício, mas pode causar pequenas pausas quando ocorrem ciclos do GC. Isso está ficando muito melhor com as novas JVMs de baixa latência, mas ainda pode ser um problema para jogos com requisitos de latência muito baixa (atiradores em primeira pessoa, talvez). Uma solução alternativa é usar bibliotecas de baixa latência como http://javolution.org/ , no entanto, essas parecem ser mais direcionadas para sistemas de negociação de alta frequência ou em tempo real do que para jogos.
  • Falta de capacidade de explorar otimizações de baixo nível - embora o compilador Java JIT seja incrivelmente bom, ele ainda impõe algumas restrições que você não pode evitar (verificação de limites em matrizes, por exemplo). Se você realmente precisa obter acesso nativo no nível do código da máquina para otimizar esse tipo de coisa, provavelmente preferirá C / C ++ em vez de Java.

Observe que também existem algumas opções de implantação a serem consideradas:

  • Applet - roda em um navegador, muito conveniente para os usuários, no entanto, os applets são bastante restritos no que eles podem fazer por razões de segurança. Observe que você pode assinar miniaplicativos para obter privilégios extras de segurança, embora isso cause um prompt um pouco assustador para a maioria dos usuários.
  • Java Web Start - melhor para jogos mais sofisticados que precisam de um download local completo e também precisam acessar os recursos do sistema local. Também funciona de uma maneira independente de plataforma. Provavelmente, o melhor caminho para um jogo de tamanho médio ou algo que precisa escapar das restrições de segurança do miniaplicativo.
  • Download do instalador - Você pode escrever um instalador para um jogo Java da mesma forma que em qualquer outro idioma. É um pouco mais trabalhoso configurar e testar, é claro, pois os instaladores tendem a ter alguns recursos específicos da plataforma.
  • Web - você pode escrever um aplicativo Web HTML5 e usar a força do Java exclusivamente no servidor. Vale a pena considerar para um jogo na web para vários jogadores.

Finalmente, também vale a pena considerar algumas das outras linguagens da JVM - elas têm todos os benefícios da plataforma Java listada acima, mas alguns as consideram linguagens melhores do que o próprio Java. Scala, Clojure e Groovy seriam os mais importantes, e todos eles podem fazer uso das ferramentas e bibliotecas Java listadas acima.

Mikera
fonte
1
O JWS realmente não acrescenta muito mais a miniaplicativos além de separar seu aplicativo do navegador. Nos dois casos, acho que você desejará assinar seu código se estiver usando uma biblioteca OpenGL.
Peter Taylor
2
Eu diria que o acesso ao sistema local é realmente um grande "excesso" de restrições de applet para muitos jogos sérios, especialmente para vários jogadores. O HTML5 é legal, mas ainda é um pouco pequenino, com suporte irregular e bits importantes como GL e Sockets desativados em muitos navegadores, além do áudio ainda não ser adequado para o uso em jogos.
Patrick Hughes
1
@PatrickHughes, se você quiser que o sistema local acesse o JWS sem grandes diálogos assustadores, precisará assinar seu código - e um applet assinado também terá acesso ao sistema local também.
Peter Taylor
Você também pode usar o Inno Setup para distribuir seus jogos Java.
Mahmoud Hossam
1
Você pode adicionar LIBGDX à lista de pacotes que o ajudam a escrever seu próprio mecanismo; possui configurações e otimizações de JNI para várias plataformas e até Android e até o OpenGL ES.
Patrick Hughes
4

Minecraft e Blocks that Matter são construídos em Java, então sim, é muito bom para criar jogos. O principal problema que você encontrará ao usar Java é portar para plataformas móveis, se você optar por seguir esse caminho e escrever um aplicativo nativo. O Android é um tipo de Java SE frankensteined com uma biblioteca separada. O Blackberry da RIM usa Java ME. Em teoria, o iOS pode ser programado com Java, embora o Objective-C provavelmente seja uma escolha melhor para essa plataforma.

Java é bastante semelhante ao c #. Costumo achar código C # compreensível, apesar de conhecer apenas Java. Eles têm uma filosofia de design diferente, mas na medida em que são amplamente implementáveis ​​com o mínimo de problemas, ambos se encaixam na conta. O C # não é uma escolha terrível para jogos de forma alguma, embora sua implantação móvel seja mais difícil e a implantação em plataformas que não sejam Windows consuma mais tempo ou dificuldade, dependendo de quais bibliotecas externas específicas e assim por diante você acaba usando.

Engenheiro Mundial
fonte
1
Java no celular: compile uma vez, depure em todos os lugares: '(.
deadalnix 27/02/2012
0

A maneira mais óbvia e menos resistente é usar o combo HTML5 + javascript. Qualquer aplicativo ou jogo criado usando isso será executado em quase todos os dispositivos e navegadores.

Vantagem : - Você precisará de configuração zero para fazer seu jogo rodar em várias plataformas e dispositivos.

NOTA: - Vi alguns jogos construídos usando as tecnologias mencionadas acima, mas elas eram menores em estatura. Mas, suponho que, se se pode fazer manteiga com leite, o queijo não é impossível

Pankaj Upadhyay
fonte
0

É possível usar o Scala e o Scheme Bigloo no Eclipse para usar a JVM para código estressado ou ação paralela dentro do seu jogo Java.

Com o Pattern Design e o UML2, você também pode proteger o código com a OCL, tudo em Topcased.org.

Dominar essas ferramentas leva tempo, mas elas são o plano de fundo do Java, a base que o levará ao topo.

cl-r
fonte
-10

Resposta curta: não.

O Java não gera um executável binário, mas apenas um bytecode como o C # (CLI), e isso não é bom para negócios sérios em "ambientes abertos" por dois motivos principais:

  • a probabilidade de ficar preso na engenharia reversa é muito alta, especialmente em linguagens antigas e muito bem conhecidas, como Java
  • você não tem controle total sobre o desempenho da máquina; no caso de Java, a JVM desempenha um grande papel assumindo o controle total.

É claro que toda linguagem tem suas próprias bibliotecas, mas devido à grande quantidade delas para cada linguagem, isso não é um problema real e não acho que seja o objetivo deste tópico.

Talvez em um nível profissional, você possa encontrar algo que possa infringir a regra, como um dev-Kit que pode traduzir todas as instruções C # em código de montagem para uma máquina do mundo real, mas se esse tipo de abordagem não estiver nos cartões, você é praticamente forçado a considere apenas o C e o C ++ para o seu desenvolvimento quando você pretende vender seu produto em um ambiente aberto.

As coisas são um pouco diferentes para os dispositivos móveis porque são "ambiente fechado", mesmo o Android é praticamente fechado, considerando o fato de que a fonte das ROMs do mundo real não costuma estar disponível ao público, o Android pode ser considerado de código aberto, mas o 99 % das ROMs em dispositivos reais não são. Nesse caso, você não pode discutir muito, tudo já está definido para você e todas as plataformas têm seu próprio idioma, como todo mundo sabe.

No final, se você pretende vender esses produtos em ambientes abertos, só posso sugerir linguagens que produzam código compilado e binário / assembly, em ambientes fechados, a decisão é tipicamente mais fácil de tomar por diferentes razões.

Micro
fonte
7
Você parece acreditar que os binários compilados são mais difíceis de fazer engenharia reversa do que os binários de bytecode. Pode haver um pouco de verdade nisso, mas não muito. Na verdade, provavelmente mais pessoas podem trabalhar com o desmontador x86 e x64 do que com o CLI ou Java bytecode, e você ficaria surpreso com a utilidade de uma ferramenta como o IDA Pro (aviso de isenção de responsabilidade - não o uso desde a versão gratuita algumas anos atrás - provavelmente é ainda mais fácil agora). Um arquivo de bytecode ofuscado pode ser ainda mais difícil de fazer engenharia reversa e, em qualquer caso, a maioria das pessoas terá poucos motivos para se importar.
Steve314
2
Por que poucas razões para se importar? Bem, quantas pessoas escrevem seus próprios mecanismos de jogos proprietários de baixo nível? E mesmo se você fizer isso, quais são as chances de alguém preferir roubar o seu (necessitando de engenharia reversa, sem qualquer tipo de documentação etc.) - muito tempo desperdiçado lá, independentemente da linguagem de desenvolvimento), em vez de usar legalmente um mecanismo de código aberto gratuito bem documentado? A pirataria do programa completo é uma preocupação real muito mais provável do que a engenharia reversa para roubar idéias de código, e os piratas não parecem nem um pouco dissuadidos pelo código compilado nativo.
Steve314
1
Em níveis de abstração, as instruções da JVM são de nível extremamente baixo - não exatamente como no hardware, mas basicamente tão distantes da abstração da camada de aplicativo. Onde as camadas da contagem de abstração estão nas bibliotecas Java padrão, o que significa que realmente existem poucas camadas entre a plataforma e o aplicativo final. Exceto que normalmente acontece em C e C ++ de qualquer maneira (por que reinventar a libpng etc.) - a maioria das pessoas usa bibliotecas comuns que formam efetivamente um conjunto de plataformas amplamente conhecidas, e boas ferramentas de engenharia reversa podem reconhecê-las.
Steve314
3
Para satisfazer os requisitos, todo o código teria que ser enviado no FPGA e envolto em epóxi. Surpresa, até os pacotes de chips de caixa preta podem e têm engenharia reversa o tempo todo. Até gigantes poderosos como a Intel introduzem bugs em seus pacotes de CPU, para que sua caixa preta de hardware epoxy incorporada ainda sofra exposição à bibliotecas de hardware. Finalmente, a chamada à segurança pela obscuridade, isso não funciona. Reductio ad absurdum, eu sei, mas a resposta original também.
Patrick Hughes
3
Infelizmente, eu não tenho reputação suficiente para te rebaixar. Todos os seus argumentos falharam. Existem pessoas por aí descodificando, descompilando e invadindo jogos produzidos em C, C ++ ou qualquer outro idioma, portanto, ser um pacote binário não oferece muita segurança adicional. Além disso, se o OP estiver preocupado com isso, existem muitos ocultadores java muito bons por aí. Sobre o controle total do desempenho da máquina, a maioria dos programadores de C e C ++ também não tem isso, basta escrever um bom código e o compilador otimizará o que for necessário. E mesmo que isso seja um problema, você pode usar JNI ou JNA.
precisa saber é o seguinte