Engine para criação de jogos Brasileira em Java - Parallax

"Apesar do uso de biblioteca de terceiros carregar consigo o problema da garantia citada, isso não é de forma alguma um problema exclusivo do Java.

Enquanto algumas pessoas hoje em dia criam jogos do zero, isso não é produtivo e a maioria das pessoas vai recorrer a diversos frameworks para facilitar as tarefas. Seja física, input, gráficos, som, o que for; muito raramente um jogo usará a plataforma nativa para todos esses recursos, sem o uso de nenhuma biblioteca de terceiros.

Se formos procurar uma plataforma completa para jogos, uma que não requer absolutamente nada de terceiros para funcionar, acho que ficaremos a ver navios. C e C++ por si só tem APIs padrões limitadas, suas bibliotecas padrões não tem condições de possibilitar a criação de jogos sem custos gigantescos. OpenGL, OpenAL, DirectX, Box2D, Havoc, todas essas são bibliotecas de terceiros se formos pensar apenas na API ?standard? da linguagem, a diferença sendo apenas que muitas dessas bibliotecas tem o suporte de grandes organizações enquanto as bibliotecas citadas do Java são mantidas pela comunidade. DirectX não é mais ?oficial? em relação ao ANSI C do que LWJGL em relação ao JAVA.

Achei interessante você incluir SDL como uma plataforma adequada e com garantias, visto que da mesma forma que LWJGL, SDL é uma biblioteca mantida pela comunidade e possui binding para várias linguagens, incluindo Java, todos mantidos por esta mesma comunidade.

Onde concordamos é que Java não é adequado para jogos e que não houve um investimento por parte da Oracle na área, mas a Google investiu na linguagem (mesmo desenvolvendo sua própria VM) e hoje vemos jogos exclusivos para o Xperia Play, incluindo ports de Playstation, e a qualquer momento podemos ver consoles portáteis (e quem sabe caseiros) exclusívos baseados em Android. Apenas não acredito que existem razões técnicas para isso não ter acontecido ainda, as razões até o momento foram todas comerciais."
By Dancovich

Já que estamos meio que espiritualmente falando com o Dancovich, nada mais justo que suas colocações seja postadas aqui também.

Esse argumento não transforma imediatamente o binding em código Java. O Java dá suporte a rodar código não Java. Mas usar JNI é só um jeito mais integrado de fazer “Runtime.exec”.

Binding tem que ser encarado como um último recurso. É uma ponte, colocada para a plataforma, justamente para não restringir o desenvolvedor quando a plataforma não der conta do recado.

Mas a própria Oracle ressalta que JNI é um recurso que deve ser usado “por sua própria conta e risco” e desaconselha fortemente o uso quando a plataforma não der conta de outra forma. Código JNI não roda na VM, não está sujeito a garbage collection e, portanto, não dá as garantias que código sobre a plataforma java dá.

Eu só quero que fique claro que para mim existe a distinção entre:

  1. Ser possível fazer games de alta qualidade usando o Java, mesmo que recorrendo a bindings;
  2. Ser o java uma plataforma completa para games;

O #1 é uma verdade inegável, e o Minecraft está aí para provar isso. Sua engine é também uma prova de que o Java pode ser usado por desenvolvedores de games.

Já o #2 não é uma afirmação verdadeira (e boa parte, por desinteresse da própria Oracle, como já concordamos). Você pode usar Java, mas pelo fato da plataforma não ser completa, sempre haverá junto um binding. A sorte é que a comunidade hoje preenche bem esse gap, com APIs de alta qualidade, como a LWJGL.

Espero que fique claro que as duas argumentações são completamente diferentes.

E que as minhas críticas se baseiam SOMENTE na segunda.
Quando se diz que o Minecraft ou a Parallax é a prova de que a plataforma java está completa.

Concordei sobre o item 1 e 2, dito acima!

Se programo utilizando a linguagem Java, rodo sobre a JVM, uso um binding para acesso a algumas bibliotecas nativas, onde o binding foi criado por terceiros usando a linguagem Java (Código Java para acesso aos bindings “JNI”) para poder ter acesso a algo que calhou que a JVM não tem suporte nativo, no final não dizer que usei Java é tenso, é como acessar um banco de dados usando ODBC via VB, Delphi ou qualquer outro e dizer que não programei em Delphi/VB/etc. Mas realmente não estou fazendo 100% uso da plataforma, justamente pela JVM não me da suporte a alguns recursos, forçando o uso de binding).

  • Quanto a funcionar em qualquer lugar que rode uma JVM, é legal termos algumas informações:
  • Quais sistemas operacionais existem bindings para (Windows 32/64, Linux 32/64, MacOSX, Solaris), disponíveis pela própria LWGL e atualizados.

  • Para Android, o slick esta com um projeto de ter uma versão dele para Android, e esta sendo trabalhado e evoluído (Ando acompanhando, e estou bem empolgado com seu avanço).

Curiosidade: Existe o projeto “LibGDX”, uma lib para desenvolvimento Desktop e Android usa opcionalmente LWJGL, feito usando a linguagem Java e o Slick esta analizando e pelo visto usando para agilizar esta compatibilidade.
http://code.google.com/p/libgdx/

  • Quanto a Symbian LWJGL também atua neste ambiente.

No site http://www.einformacao.com.br/parallax/introducao
Procure: “Tecnologias envolvidas”

  • Vai ver que não deixo uma tecnologia importante de fora, das que uso, além da linguagem Java, não deixo quem vem no site do projeto ficar no escuro, pelo contrario quanto mais eles souberem melhor, se não fica difícil até eles ajudarem caso queiram contribuir.

Rolou um outro bate papo entre eu, viny e danilo nos comentarios, que complementa esta daqui.
http://cosmiceffect.com.br/2012/03/12/minecraft-o-software/#comment-4080

Espero que possam dar uma olhada com carinho no projeto Parallax depois, divulgar e até contribuir, seja de que forma for.
Viny pode ter certeza que te inclui neste texto, rsrsrs…

Sim. Hoje a LWJGL realmente cobre todas as plataformas que existe uma VM.

Mas a questão do binding envolve também a garantia de cobrirem futuras VMs. Acredito que o pessoal da LWJGL terá essa preocupação, mas você terá que espera-los fazerem o port antes de sair o usando seu programa. Haverá aí um intervalo de tempo com VM e sem binding.

A engine Slick2D, para jogos é muito interessante. E tem suporte a mais plataformas que o próprio J2SE, justamente por estar sendo portada para Android.

Michel, você está dizendo coisas que não procedem, numa boa. A questão não é gostar ou desgostar de linguagens, você precisa ser imparcial quando começar a afirmar alguma coisa.
A linguagem c++ hoje é a que possui maior cobertura em ferramentas para jogos, e esse cenário não vai mudar tão cedo porque existe investimento em pesquisa em cima disso. E é muito grande. A maioria opensource e de grande qualidade.


http://irrlicht.sourceforge.net/

Uma lista com grande parte das engines disponíveis(a grande maioria é c++ então como não se possibilita a criação de jogos com custos menores?)

OpenGL não é uma biblioteca de terceiros. Ela é mantida por um grupo gigantesco incluindo NVIDIA e AMD. Ela é embarcada em todos os sistemas operacionais. Em um post lá atras você disse que ela possui dependências( de hardware, isso não procede porque ela é aberta e é um padrão a ser implementado por todos os sistemas). Eu nem vou citar aquele post porque ficou muito feia essa afirmação.

DirectX também não é biblioteca de terceiros porque o windows depende dela. A maior parte das apis, frameworks e engines(para windows) a usam, inclusive o java 3d.

Existe uma grande diferença entre DirectX e Opengl. A primeira é um framework completo(vídeo, input(hardware) e áudio), a segunda é uma biblioteca de baixo nível escrita em c, para servir sistemas operacionais com recursos de vídeo(não serve somente para jogos(aliás jogos é o de menos)). Não se pode comparar essas duas como bibliotecas do jeito que você postou acima.

É possível desenvolver jogos com qualquer ferramenta, mas usando c++ é inegável que haja ganho de produtividade e qualidade devido a essas razões(quantidade de ferramentas disponíveis).

[quote=juliocbq][quote=Michel.Montenegro]

Se formos procurar uma plataforma completa para jogos, uma que não requer absolutamente nada de terceiros para funcionar, acho que ficaremos a ver navios. C e C++ por si só tem APIs padrões limitadas, suas bibliotecas padrões não tem condições de possibilitar a criação de jogos sem custos gigantescos. OpenGL, OpenAL, DirectX, Box2D, Havoc, todas essas são bibliotecas de terceiros se formos pensar apenas na API ?standard? da linguagem, a diferença sendo apenas que muitas dessas bibliotecas tem o suporte de grandes organizações enquanto as bibliotecas citadas do Java são mantidas pela comunidade. DirectX não é mais ?oficial? em relação ao ANSI C do que LWJGL em relação ao JAVA.
[/quote]

Michel, você está dizendo coisas que não procedem, numa boa. A questão não é gostar ou desgostar de linguagens, você precisa ser imparcial quando começar a afirmar alguma coisa.
A linguagem c++ hoje é a que possui maior cobertura em ferramentas para jogos, e esse cenário não vai mudar tão cedo porque existe investimento em pesquisa em cima disso. E é muito grande. A maioria opensource e de grande qualidade.


http://irrlicht.sourceforge.net/

Uma lista com grande parte das engines disponíveis(a grande maioria é c++ então como não se possibilita a criação de jogos com custos menores?)

OpenGL não é uma biblioteca de terceiros. Ela é mantida por um grupo gigantesco incluindo NVIDIA e AMD. Ela é embarcada em todos os sistemas operacionais. Em um post lá atras você disse que ela possui dependências( de hardware, isso não procede porque ela é aberta e é um padrão a ser implementado por todos os sistemas). Eu nem vou citar aquele post porque ficou muito feia essa afirmação.

DirectX também não é biblioteca de terceiros porque o windows depende dela. A maior parte das apis, frameworks e engines(para windows) a usam, inclusive o java 3d.

Existe uma grande diferença entre DirectX e Opengl. A primeira é um framework completo(vídeo, input(hardware) e áudio), a segunda é uma biblioteca de baixo nível escrita em c, para servir sistemas operacionais com recursos de vídeo(não serve somente para jogos(aliás jogos é o de menos)). Não se pode comparar essas duas como bibliotecas do jeito que você postou acima.

É possível desenvolver jogos com qualquer ferramenta, mas usando c++ é inegável que haja ganho de produtividade e qualidade devido a essas razões(quantidade de ferramentas disponíveis).

[/quote]

julio, tem certeza que leste com atenção o que foi escrito ou pensou “vou fazer flame”?
Vou partir do principio que não quiseste “provocar”, só foste desatento.

Veja no final do texto

Estava ocorrendo duas conversas aqui e no Cosmiceffect, como em um determinado ponto viny postou lá e cá, assim como eu, resolvi dar o contexto do que falávamos, trouxe o texto do autor do outro artigo, ao qual postei o link aqui, de uma lida lá e responda a sua afirmação ao autor do mesmo. Feio é não prestar atenção no que se lê e sair fazendo afirmações, por favor, só peço que leia direito antes de sair postando algo, para não ficar mais feio do que já esta.

Imparcial eu sou, tanto que nem te deste ao trabalho de ler os textos acima, não de verdade, isso esta claro, veja os posts acima, onde não discordei do Viny em sua ultima afirmação, pois também concordo com elas, só que em um debate se todos concordarem com a mesma coisa, deixa de ser um debate e se torna um repetição de comentarios. Se tivesse lido todos os post com atenção, incluso no outro site, já teria percebido que eu e viny não discordamos necessariamente da mesma coisa, a diferença esta nas questões estrategicas, como é o caso dos bindings.

OpenGL é um padrão adotado para permitir que fabricantes de hardware de video que o adotem, possam ter seu equipamento rodando em mais de um S.O que suportem OpenGL, como tal ele não tem um “dono”, é uma comunidade que o mantem vivo sim, não vi erro nesta afirmativa (Mas é de certo que ela possui o apio de grandes empresas, o que da mais credibilidade, fato!).

Sobre o direct X, eu definitivamente acho que você devia ler com calma os textos antes de postar, leia, mas leia bem a:
Afirmação do danilo.

Também não discordo de nenhuma das duas afirmações dele.

Acima outra afirmação feita pelo danilo, leia atentamente a afirmativa dele, ele diz que se for usar apenas os recursos nativos do C++, sem se valer de nenhuma outra tecnologia agregada (de terceiros), os custos para fazer algo seriam muito grandes (afinal tudo teria que ser feito do Zero a cada projeto por exemplo), só me dei ao trabalho de explicar o texto dele, para não ter nenhuma falsa afirmação aqui, que possa novamente induzir o leitor ao erro (Dica: Errar é humano, saber abordar alguem em uma conversa é uma arte, “com a mesma força que julgas também sera julgado” deixo este conselho profissional para ti).

Eu te pergunto quem esta sendo passional aqui?

  • Eu que em nenhum momento desmereço, ou digo que Java é mais popular que C++, apenas defendo que ela é uma ferramenta/linguagem como outra qualquer, mesmo não tendo alguns facilitadores naturais devido a falta de atenção da Oracle, é muito bem capaz de suprir isto, se valendo de forças externas, assim como muitas tecnologias o fazem para diversas situações. Agora me pergunto se você que “na boa” e sem “ler” vem fazendo uma campanha como se o c++ estivesse sendo atacado? esquecendo que o assunto aqui é só analisar as possibilidades com Java e o que pode ou não ser feito sobre isto e até a viabilidade do mesmo (Lembrando que já chegaste descascando Java neste tema, e em nenhum momento te vi dizer algo positivo em relação a linguagem), então te devolvo a frase "você está dizendo coisas que não procedem, numa boa. A questão não é gostar ou desgostar de linguagens, você precisa ser imparcial quando começar a afirmar alguma coisa. ".

julio relaxa, releia todos os comentários, incluindo o do link do cosmic effect para te situar do contexto geral, não pense que esta é a comunidade c++ e nem que o mesmo é agredido, pense que a comunidade aqui é Java e devemos ao menos tentar buscar soluções para Java e nos focar nisto, até para não perdermos o fio da meada que é a proposta deste grupo. Se não tu vai acabar iniciando uma conversa só para repetir o que eu e viny viemos conversando desde os primeiros tópicos para no final ter o mesmo consenso ou parecido (Como foi o caso mais acima).

Inspirado em todo este bate papo resolvi fazer um artigo no site: Java no mundo 2D - Iniciando o “Caminho das Pedras”

[quote=Michel.Montenegro
julio, tem certeza que leste com atenção o que foi escrito ou pensou “vou fazer flame”?
Vou partir do principio que não quiseste “provocar”, só foste desatento.

Veja no final do texto

By Dancovich
Já que estamos meio que espiritualmente falando com o Dancovich, nada mais justo que suas colocações sejam postadas aqui também.
[/quote]

Sim, li muito bem, e digo você concordou e afirmou o que vou postado. E vou citar agora:

OpenGL não depende de linux nem de placa de vídeo, ela é uma especificação para desenvolvedores de hardware. Você só tem resultados melhores usando uma aceleradora porque a biblioteca não precisa desenhar por software.

Aqui em baixo eu concordo com você

[quote=Michel.Montenegro]
DirectX não é mais ‘oficial’ em relação ao ANSI C do que LWJGL em relação ao JAVA.[/quote]

[quote]O próprio XNA da Microsoft nada mais é que uma coleção de bindings para o DirectX e nem por isso deixa de ter desempenho mais que adequado

Também não discordo de nenhuma das duas afirmações dele.[/quote]
O directx é escrito em c++. Não tem que respeitar nenhum padrão “ansi c”.
Novamente concordou aqui, fazendo dele suas palavras.

Sim, as bibliotecas que acompanham os compiladores c++ são as da opengl, mas mesmo assim elas possibilitam a criação de engines(porque existe investimento). Java 2d não possibilita nada disso.
Eu não estou sendo parcial, só estou contra argumentando a favor de uma tecnologia enraízada fortemente neste segmento.

Só um update, sobre o que falava a respeito da única engine 2D que presta em Java ser mantida por uma pessoa física. A Slick2D, que já estava sem manutenção faz tempo, saiu fora do ar: http://www.slick2d.org/

O Kevin Glass, que era o mantenedor do projeto, avisou no fórum da Slick que não irá mais manter a API, mas qualquer um pode baixar os fontes o BitBucket.

É mais uma má notícia para os games em Java, que já vinham mal faz tempo. Agora só resta torcer pelo Ouya, ou focar mesmo em Android.

API pra jogos em Java só tem esse Ouya?

O Ouya não é uma API, e sim um console. E usa Android, ou seja, não usa J2SE.

Para J2SE, uma das principais APIs era o Slick2D, que ainda assim usava LWJGL para renderizar gráficos usando a OpenGL e não o JDK.

No fundo, a única coisa que tem hoje é o JavaFX, que está vindo em péssima hora. Está nascendo ao mesmo tempo que o Flash morre e o HTML5 toma conta.

O Ouya não é uma API, e sim um console. E usa Android, ou seja, não usa J2SE.

Para J2SE, uma das principais APIs era o Slick2D, que ainda assim usava LWJGL para renderizar gráficos usando a OpenGL e não o JDK.

No fundo, a única coisa que tem hoje é o JavaFX, que está vindo em péssima hora. Está nascendo ao mesmo tempo que o Flash morre e o HTML5 toma conta.[/quote]

Desde a versão 2 o JavaFX não tem o objetivo de concorrer com o Flash, mas em substituir o Swing pra aplicações desktop, embora ainda possa ser usado como applet no browser.

Mas então se eu quiser programar um jogo em java, o único caminho hoje é o JavaFX?

[quote=marcosalex]Desde a versão 2 o JavaFX não tem o objetivo de concorrer com o Flash, mas em substituir o Swing pra aplicações desktop, embora ainda possa ser usado como applet no browser.

Mas então se eu quiser programar um jogo em java, o único caminho hoje é o JavaFX?[/quote]

Ou:
J2SE - Se for um game 2D simples;
JMonkeyEngine - Se for um game 3D;
LWJGL - Se você quiser montar sua própria engine.

Os dois últimos, assim como era a Slick2D, usam JNI para acessar o OpenGL. Não são J2SE puro.

[quote=ViniGodoy][quote=marcosalex]Desde a versão 2 o JavaFX não tem o objetivo de concorrer com o Flash, mas em substituir o Swing pra aplicações desktop, embora ainda possa ser usado como applet no browser.

Mas então se eu quiser programar um jogo em java, o único caminho hoje é o JavaFX?[/quote]

Ou:
J2SE - Se for um game 2D simples;
JMonkeyEngine - Se for um game 3D;
LWJGL - Se você quiser montar sua própria engine.

Os dois últimos, assim como era a Slick2D, usam JNI para acessar o OpenGL. Não são J2SE puro.[/quote]

Entendi. Uma outra dúvida: quando desenvolvo pra Android ele roda sobre a VM pura ou ele consegue utilizar código nativo? E no .NET com XNA?

O Android roda sobre a VM. Claro que isso é bem relativo hoje, pois temos compilação Just-in-time.

Mas é importante não confundir. Embora o Android use como linguagem o Java, ele é uma plataforma a parte, sem as limitações da plataforma Java.

O .net usa uma estratégia similar, mas também foi descontinuado pela MS. A alternativa agora é usar o Direct X, em C#, que aí é compilado e roda sobre a API do Windows 8.
Ou o DirectX com C++. Para jogos 2D, desenvolveram uma biblioteca para torna-lo similar ao XNA.

Estou considerando 3 plataformas: Android, Java e .NET.
Então o resumo da ópera é que se quiser rodar 3D sob a VM, somente o Android na Dalvik ou usando JavaFX no Java. E o .NET hoje usa uma forma nativa, como as outras bibliotecas Java que voce citou. Certo?

Slick2D ainda esta sofrendo alteração pelos que estavam com o criador do mesmo, mas independente de qualquer coisa para jogos 2D Slick continua sendo muito bom.

Mas a alternativa mais atual e na minha opinião melhor, seria a LibGDX, para jogos em Java (Suportando inclusive a criação do mesmo em Android e Desktop, não testei para html5, mas pareceu uma alternativa interessante). :wink:

[quote=Michel.Montenegro]Slick2D ainda esta sofrendo alteração pelos que estavam com o criador do mesmo, mas independente de qualquer coisa para jogos 2D Slick continua sendo muito bom.

Mas a alternativa mais atual e na minha opinião melhor, seria a LibGDX, para jogos em Java (Suportando inclusive a criação do mesmo em Android e Desktop, não testei para html5, mas pareceu uma alternativa interessante). ;)[/quote]

Com certeza.

Mas novamente: usa apenas a linguagem Java, mas não a plataforma. Essa inclusive tem “Performance critical parts written in C/C++”.

Como sempre, meu argumento não é sobre a linguagem e sim sobre o J2SE ou Android como plataforma para games.

Para 2D a tendência para ser mesmo usar APIs extremamente portáveis (e não multiplataforma), como é o caso da LibGDX, Haxen, etc.