Linguagens para criação de games

Venho desenvolvendo alguns games, como muitos sabem cerca de 70% dos games produzidos utilizam C++,
que é uma linguagem extramamente rápida. Mas vejo uma tendência para Java muito grande, outra linguagem que
eu acho que será o futuro é o C#. C++, é a que tem mais suporte, e é usada na industria de jogos, além do mais, C++ e Java são parecidos, então é melhor, se quiser aprender algo agora, aprenda C++, que é a linguagem usada pelos desenvolvedores de jogos.
Nintendo, Sony, Sega, Square-enix, Namco, Capcom, Nipon Ichi Software, Level 5, Electonic Arts, Bandai, Cyber Connect 2, [Insira o nome de qualquer empresa que desenvolva pra consoles aqui] usam C++. Mas em um futuro próximo qual linguagem utilizar ?
Eu realmente estou surpreendindo com o framework 3.0 da Microsoft, com certeza será deixará de ser um tendência para ser uma realidade.
A Microsoft desenvolveu uma biblioteca para games muito poderosa, inclusive é a mesma utilizada pelo XBOX 360. XNA, com ela você pode fazer jogo em C# ao mesmo tempo para o windows Vista e para o XBOX 360, exemplo de jogo feito nela: www.shadowrun.com.
Na opinião de vocês qual será a linguagem preferida dos desenvolvedores no futuro ?

Acredito que será o C#, apesar de existir o Garbage Collector para essa linguagem, você também tem a opção de manusear os
objetos diretamente na memória através da palavra chave unsafe, cada dia que passa fico mais supreendido com c# na minha opinião e um Java melhorado. Se você manupular os objetos diretamente na memória você ganha muito em relação a performace.
Em relação a outras linguagens:
Linguagens como Delphi/Pascal são muito mais lerdas e pesadas que C/C++.
1º) Delphi especificamente: O ambiente em que vc desenvolve faz as coisas pra você. Por isso, ele precisa usar um modelo na hora de criar o código executável que funcione pra criar todos os benditos componentes que você queira colocar no form. Por isso, ele inclui no seu programa coisas que não seriam exatamente necessárias para o que você quer fazer. Programação não-visual permite que você tenha mais controle sobre o código. Claro que, se você usar a opção “C++ Builder” do delphi pra programar visualmente em C++, não vai haver uma grande vantagem.
2º) Java: Java é INTERPRETADO. Quando você usa o “javac”, o compilador Java, ele não compila em “binário”, ou seja, não compila para a linguagem que o seu processador e sistema operacional entendem. Ele compila para uma linguagem que depois é lida por um interpretador, a Java Virtual Machine. Por isso roda em qualquer pc. Java é vantajoso para fazer jogos pra serem rodados via Browser, como Runescape, mas uma opção seria usar outra linguagem e disponibilizar uma versão compilada para cada Sistema.
3º) Qualquer linguagem interpretada (Ruby, Phyton, Perl, Java, whatever): Linguagens interpretadas SÃO mais lentas. Por quê? Porque é um programa que está rodando no processador que lê e executa as instruções. Como elas não são lidas diretamente pelo processador, perde-se muito tempo.
4º) Outras linguagens compiladas (Pascal, C#, etc): C é, excetuando-se assembly, a linguagem que te ajuda menos. C oferece uma grande liberdade mas não te ajuda em muita coisa se você fizar algum acesso inválido, ou algo do gênero. Se você declarar em Pascal um array de 20 elementos e tentar acessar o 21º, ele não compila o programa. Se você fizer o mesmo em C++, problema é seu, você que tem que saber o que faz. Para restringir acessos inválidos, ou, no caso de C#, fazer o gerenciamento automático de memória, entre outras coisas, essas linguagens adicionam código ao seu executável. C++ não faz isso, poupando memória e processamento.

C++ não é rapida. Nenhuma linguagem é rapida ou lenta. O que pode ser rápida é a sua implementação.

Vc tem varios compiladores C++ (o GNU, o da Intel, etc) que podem ser utilizados de muitas formas diferentes, resultando um código com desempenho razoavel ou não (como as opções de otimização de código).

Não confunda o engine gráfico com o jogo em si: o engine pode ser em C/C++ para fazer uso do hardware de maneira extremamente louca, enquanto o jogo pode utilizar linguagens interpretadas como Lua para desenvolvimento das regras (ou de parte delas).

Eu, pessoalmente, acredito que linguagens como Lua, Ruby e Javascript terão muito futuro.

Quanto ao java, desde a 1.3 ou 1.4 (não sei ao certo), a JVM não apenas interpreta bytecodes, ela usa a compilação Just-In-Time para compilar os bytecodes em códigos nativos e executar o código nativo, ganhando desempenho.

O java 6 vai mais longe. Ele sai interpretando o código ao mesmo tempo que está compilando. Quando termina a compilação ele pula do modo interpretado para o compilado.

Daí a questão não é muito compilado X interpretado, e sim o grau de otimização que o compilador/interpretador é capaz de obter.

Quanto a jogos em java, o Swing+AWT+Java2D+Java3D+whatever é bem rico para fazer isso. O grande problema é que a curva de aprendizado para desenvolver jogos em Swing+AWT+Java2D+Java3D+whatever é acentuada e o código resultante é significativamente mais complexo do que seria em C, C++ ou Delphi. Mas vencida essa barreira, o resultado é surpreendente.

Bom dia,

Já deu uma olhada em Python? Diversos jogos a utilizam como linguagem de script para elaboração de controles de mercado, vilas, por exemplo (no caso Civilization IV, foi utilizada também para criação das telas do jogo e interface, dê uma lida abaixo).

Citando Soren Johnson (lead designer do Civ IV):

[quote]Soren Johnson:
We chose to use python because we wanted a well-supported scripting language that could extend our core code. Indeed, we wrote much more code in python than we were expecting, including all in-game screens and the main interface. It was a huge win for the project because writing code in a language with garbage collection simply goes faster than writing code in C++. The fact that users will be able to easily mod the interface is a nice plus as well. The downside of python was that it significantly increased our build times, mostly from linking with Boost. XML was chosen because it is a very flexible system for storing data, which is important for a game like Civilization that is essentially “built” from numbers. Using an off-the-shelf XML editor, anyone from our designers to end users could modify our game data. We also have a high-level file system which allows you to override any specific art, sound, python, or XML file simply by setting a specific “mod directory” that contains only the modified files. If a specific file is not found in this directory, the game just uses the default one.[/quote]

Entrevista completa aqui: http://games.slashdot.org/games/05/10/27/059220.shtml?tid=206&tid=11

Eu tenho a impressão de que Python pode ser utilizada em todas as áreas do desenvolvimento, exceto talvez para o processamento gráfico onde C++ pode ser mais rápida.
Existem diversas ferramentas, tais quais Pygame, PyKyra, Soya.
Você pode conferir algumas outras informações aqui:
Python Games: http://wiki.python.org/moin/PythonGames
Pygame: http://www.pygame.org/news.html
PyKyra: http://www.alobbs.com/pykyra
Soya3D: http://home.gna.org/oomadness/en/soya3d/index.html
E, para uma boa introdução com um exemplo de um Space Invaders-like: http://www.gustavobarbieri.com.br/jogos/jogo/doc/
Abraços :slight_smile:

ps.: Uma nota adicional, o pessoal do Pygame vem trabalhando para integrá-lo junto ao flash, permitindo executar jogos via browser. Dê uma olhada no site.

Vou de Lua, embora ache o Python uma ótima alternativa.

C++ pro core e Lua pras tarefas repetitivas e de controle da interface / I.A de alto nível etc.

Jogos cada dia tem menos código em C / C++ e mais em linguagens de alto nível. As linguagens mais comuns são lua e python para isso. Python é um desastre com múltiplos core e ambas não tem boa performance. Por esses motivos e outros, VMs de performance muito superior, como o mono, estão ganhando espaço na parte de scripting dos jogos.

Olá

Complementando o que já foi dito… mas posso estar dizendo bobagens porque de Jogos sofisticados não entendo nada.

  1. Java não é um linguagem interpretada como o Ruby por exemplo. Java é compilada para bytecodes e isto é diferente do que se chama uma linguagem estritamente interpretada. Por este e por muitos outros motivos, há por ái vários benchmarks comparando casos desenvolvidos em Java com melhor desempenho do que seu semelhante em C/C++.

  2. Java poderia ser uma linguagem excelente para desenvolver jogos. Aliás, se procurarem no google encontrarão muitos jogos feitos em Java. E há livros ensinando como fazer isto Mas porque Java nem sempre é a melhor opção? Um dos motivos que um cara da Hoplon me disse porque faziam em C/C++ é a dificuldade de acessar diretamente o S.O. e ao hardware. E neste quesito, tanto C# como F#, permitem acesso mais fácil ao Windows. Outro motivo é o uso de bibliotecas do tipo OpenGL e aí neste quesito Java talvez seja melhor do que C#/F# mas pior do que C/C++

[]s
Luca

O C++ é uma linguagem excelente para se desenvolver jogos. Além de existirem diversas Engines de ótima qualidade, tanto para 2D quanto para 3D, é uma linguagem rápida, que permite muita otimização, inclusive de baixo nível se for necessário.

Agora, a menos que você esteja desenvolvendo um jogo Triple A, para concorrer com caras como o Crysis, duvido muito que você vá precisar otimizar tanto um código. Nesse caso, java é uma excelente opção para desenvolvimento, mesmo no caso de jogos 3D, como demonstra a JMonkeyEngine: http://www.jmonkeyengine.com/

Que aliás, não usa Java puro, mas baseia-se num binding para OpenGL. Nada mais natural, já que o hardware de vídeo é imprescindível para jogos desse tipo.

Aliás, benchmarks comprovam que a maior demora não está na linguagem escolhida pelo desenvolvimento, exceto nos casos de jogos muitíssimos baseados em inteligência artificial, como é o caso dos jogos RTS. O grande gargalo de um jogo está na placa de vídeo (GPU) ou nos batchs entre a CPU e a GPU (no barramento de comunicação). Nesse caso, faz pouca diferença escolher entre Java e C++. Se você quer otimizar, saia do pipeline gráfico tradicional e otimize escrevendo bons shaders.

Além disso, procure organizar seu código para fazer poucos batchs, criando para isso um scene manager que agrupe objetos de mesma textura num único batch, mande triângulos numa ordem que otimize o cache do vídeo, pinte o que está na frente antes do que está atrás para aproveitar z-buffer e faça um bom camera culling, entre outras coisas.

Finalmente, é bom ressaltar que para jogos casuais em applets e jogos de celular, Java é a melhor opção hoje em dia.

Agora, respondendo a sua pergunta. Acho meio difícil o Java retirar o lugar do C++ nos consoles por duas razões principais:
a) Não há interesse dos fabricantes de console em ter uma plataforma comum;
b) Java não é uma linguagem que aproveita bem as potencialidades do hardware.

Você não constrói um hardware dedicado para nivelarem tudo sobre uma VM. E os fabricantes gostam muito de ter títulos próprios, não portáveis. Como video-games dominam a indústria de jogos, chego a conclusão que o Java (e outras linguagens, exceto talvez o C# por causa do X-BOX) fiquem afastadas desse mercado.

PS: Louds, vc exagerou um pouco. A presença de scripts é realmente grande em jogos, mas o mainstream ainda é o C++. Aliás, hoje até há a tendência de se fugir um pouco dos scripts e tentar implementar uma IA mais convicente e menos previsível. O grande problema dos scripts é que eles transformam jogo num filme e, se o jogador começar a sentir que as ações dele tem pouco (ou nenhum) impacto no jogo, vai certamente ficar frustrado.

Falou o mestre em jogos do GUJ :slight_smile:

Vini, que mal lhe pergunte, mas você trabalha diretamente com jogos atualmente ou você mexe com isso só por hobby?

Outra pergunta agora mais no assunto, você bota fé no XNA como plataforma de desenvolvimento de jogos?

[quote=Puppets]…
2º) Java: Java é INTERPRETADO. Quando você usa o “javac”, o compilador Java, ele não compila em “binário”, ou seja, não compila para a linguagem que o seu processador e sistema operacional entendem. Ele compila para uma linguagem que depois é lida por um interpretador, a Java Virtual Machine. Por isso roda em qualquer pc. Java é vantajoso para fazer jogos pra serem rodados via Browser, como Runescape, mas uma opção seria usar outra linguagem e disponibilizar uma versão compilada para cada Sistema.
…[/quote]
E no que isso difere do C# ( que tanto falaste bem )? O que difere o Java criar o bytecode e o C# criar o MSIL? Ou o Java rodar em cima da JVM e o C# em cima da CLR ?

E como já disseram, o que retrae a performance é o acesso aos dispositivos e não se ela é interpretada ou não.

Até!

[quote=Maurício Linhares]Falou o mestre em jogos do GUJ :slight_smile:
Vini, que mal lhe pergunte, mas você trabalha diretamente com jogos atualmente ou você mexe com isso só por hobby?
Outra pergunta agora mais no assunto, você bota fé no XNA como plataforma de desenvolvimento de jogos?[/quote]

Só por hobby… mas um hobby que tá beirando o vício.
Por conta disso fiz a pós de jogos aqui no Unicenp, iniciei o meu blog e já estou dando umas aulinhas de computação gráfica na Federal…

Se a oportunidade surgisse, eu toparia trabalhar com jogos. Mas também não faço qualquer coisa por isso. Teria que ser uma proposta melhor do que meu emprego atual, que é muito bom e muito legal também.

Desenvolver por hobby tem suas vantagens. Não tem prazo e você só desenvolve os jogos que você gosta.
Profissionalmente já é outra história. Não creio que seja muito diferente de um trabalho como qualquer outro.

Acho que o XNA tem futuro sim, especialmente no mercado de jogos casuais (apesar de que dá para fazer alguns jogos bem legais, nem tão casuais assim com ele). A MS usando ele no X-Box vai dar muito fôlego para a plataforma. Engraçado, quando o assunto é jogos, a Microsoft parece uma emrpresa bem diferente. Fala em plataformas abertas, uniformização e faz um excelente trabalho com o DirectX. Por favor, não iniciem um flame war por causa desse meu último comentário.

[quote=ViniGodoy]
PS: Louds, vc exagerou um pouco. A presença de scripts é realmente grande em jogos, mas o mainstream ainda é o C++. Aliás, hoje até há a tendência de se fugir um pouco dos scripts e tentar implementar uma IA mais convicente e menos previsível. O grande problema dos scripts é que eles transformam jogo num filme e, se o jogador começar a sentir que as ações dele tem pouco (ou nenhum) impacto no jogo, vai certamente ficar frustrado.[/quote]

Acho que vc exagerou na interpretação do que eu disse. Quando falei scripting não me referia a ter IA baseada em roteiros (scripts), nem falei de IA se vc ler mais atentamente. Usar uma linguagem de alto nível para as partes que exigem maior flexibilidade e produtividade é chamado de scripting desde sempre.

Nesse sentido VMs como Lua, Python e mono são cada vez mais presentes no mercado de jogos. Está cada dia mais difícil achar um fabricante de jogos disposto a investir em criar uma linguagem de scripting própria - prefere reaproveitar uma linguagem de alto nível já existente. Só ver que alguns títulos tripleA desde 2006 chegam ao ponto de ter mais código em uma dessas linguagens que as de baixo nível (C/C++/ASM).

Nesse sentido C++ está migrando de ser a principal ferramenta dos estúdios de jogos para ser quase que exclusiva dos fornecedores de bibliotecas e engines. Isso é basicamente o que pode ser visto na GDC, os estúdios cada vez mais usam fornecedores para os vários componentes de baixo nível de seu jogos e se preocupam apenas com o conteúdo.

Bom, da forma que você falou, não tinha outra interpretação possível.

Mas o que vc falou no último post é verdade. Cada vez mais a produção de jogos se torna um trabalho de integração de engines. É uma tendência forte (e bem positiva na minha opinião). Poucas são as produtoras que investem em engines novas, mas ainda há muito trabalho de personalização, feito no bom e velho C++.

Mas não dá para descartar o fato de que o código dessas engines é C++ e faz parte dos jogos, mesmo que vindo de terceiros. E foi exatamente isso que aquela sua frase não deu a entender.

Mas belê, agora está tudo esclarecido! :slight_smile: