Sempre que faço uma pergunta sobre o desenvolvimento de jogos em um fórum on-line, sempre recebo sugestões como aprender algoritmos de desenho de linha, manipulação de imagem no nível de bits e descompressão de vídeo etc.
No entanto, olhando para jogos como God of War 3, acho difícil acreditar que esses jogos possam ser desenvolvidos usando essas técnicas de baixo nível.
A enorme grandiosidade de tais jogos desafia qualquer metodologia de programação compreensível (para mim).
Além do hardware de jogos é realmente um monstro hoje em dia. Portanto, é lógico que os desenvolvedores trabalhariam em um nível mais alto de abstração.
Qual é a mais recente metodologia de desenvolvimento na indústria de jogos? Como é que uma equipe de 30 a 35 desenvolvedores (dos quais a maioria é de gerência e marketing) é capaz de criar jogos tão incompreensíveis?
Se a pergunta parecer muito geral, você poderia explicar a arquitetura de God of War 3? Ou como você produziria um clone? Que eu acho que deveria ser objetivamente responsável.
fonte
Respostas:
Disclaimer: Eu não sou desenvolvedor de videogames. Mas eu tenho um interesse "hobby" por isso.
A maioria dos jogos AAA que você vê são feitos usando motores. Eles não são escritos do zero. Pense em um mecanismo como uma estrutura. Você possui o .NET framework, o Java SDK, o cacau toolkit.
Tudo para facilitar o trabalho de criar software e abstrair o código da pia da cozinha. É necessário, mas escrevê-lo toda vez é muito improdutivo.
Usando esses mecanismos, o desenvolvedor pode criar seu jogo e não precisa se preocupar com parte do código subjacente. ( Não se engane, o desenvolvimento de jogos é um dos ramos mais difíceis da engenharia de software. )
Por exemplo, o Unreal Engine 4 possui um kit e um estúdio de desenvolvimento matador:
http://www.youtube.com/watch?v=MOvfn1p92_8
Existem muitos motores diferentes por aí. Alguns pagam, outros grátis, outros mais para o metal, outros oferecem uma abstração mais alta.
Por exemplo:
fonte
Em referência ao comentário de gbjbaanb, algumas das coisas que tornam a programação de jogos divertida são a vida útil limitada da base de código e a falta de exigir precisões. Por exemplo, se você está criando um jogo FPS, e seu algoritmo de movimento às vezes coloca o personagem do jogo a alguns pixels de distância, não é grande coisa e as chances são de que ninguém notará. Se você está projetando um software comercial e, ocasionalmente, sua função de soma lhe oferece alguns dólares, isso é um bug muito mais sério. Portanto, ao projetar jogos, alguns aspectos podem ser muito menos precisos (e precisam passar apenas por testes em humanos, em vez de um conjunto de testes automatizados que verifica se as respostas estão exatamente corretas).
Minha experiência tem sido que a programação de jogos, especialmente para jogos em tempo real, é uma experiência muito diferente de ... quase qualquer outro desenvolvimento de software que eu tenha feito, talvez exceto pelo trabalho da GUI. É algo que você tem que tentar!
fonte
A resposta é "motores". Muitos jogos são construídos sobre vários gráficos e mecanismos de jogabilidade que são basicamente grandes bibliotecas ou estruturas.
No mundo OSS, dê uma olhada no Ogre, por exemplo, para jogos comerciais, você tem coisas como o Source.
Existem outros fatores em jogo, como grande parte do código é descartável e não passaria despercebida em um ambiente de negócios - mas isso ocorre porque a vida útil limitada de um jogo e as escalas de tempo de desenvolvimento aceleradas significam que o código é (quase) projetado apenas para trabalhar, não para ser mantido.
fonte
O Unity3D é muito bom. Aqui estão alguns pontos que eu gosto sobre isso:
http://en.wikipedia.org/wiki/Unity_(game_engine)#Major_features
http://unity3d.com/unity/licenses
http://unity3d.com/unity/editor/importing (role um pouco para baixo)
A codificação (script) pode ser feita em C #, que é uma linguagem interessante, com uma boa API e verificações de tempo de compilação. Vem com um bom ambiente de desenvolvimento (IDE e tudo). Se você quiser algo diferente, ele também suporta Javascript.
Tem muito bom suporte físico (colisões, gravidade, forças, etc.):
http://docs.unity3d.com/Documentation/Manual/Physics.html
Possui uma loja de ativos que permite comprar vários modelos, scripts, animações, etc.
Por último, mas não menos importante, é decentemente rápido. Confira as demos móveis, IMHO eles se movem muito bem e têm gráficos muito decentes:
http://unity3d.com/gallery/made-with-unity/game-list
Aqui está um bom projeto do Unity que estou esperando atualmente:
Área deserta 2 de Brian Fargo
Eles têm uma boa entrada no blog sobre por que escolheram o Unity , bem como outros discutindo como o trabalho com ele ocorre .
fonte
A ID Software é um dos fornecedores que geralmente publica jogos de última geração. Alguns anos depois, eles geralmente os liberam como código aberto. Em http://fabiensanglard.net/quake3/index.php, você pode encontrar uma análise do código fonte do Quake3. Esta é uma descrição bastante detalhada e, embora o Quake3 seja bastante antigo, os conceitos ainda devem ser relevantes para os jogos modernos.
E sim, se você deseja criar um mecanismo de jogo rápido e competitivo de ponta, precisará conhecer todas essas peças de baixo nível. Se você não quer se preocupar com isso: existem mecanismos diferentes (mecanismo quake3 ou os de outras respostas) disponíveis, mas bem, então você não está criando um novo jogo revolucionário ;-)
fonte
Como muitas respostas mencionam, mecanismos de jogos e bibliotecas desempenham um papel importante. No entanto, observe que isso se aplica a jogos comerciais de médio e grande porte mais do que a pequenos jogos "independentes".
Por exemplo, em plataformas móveis, a maioria dos jogos é escrita usando apenas um conjunto de bibliotecas relativamente primitivas, em vez de depender de mecanismos de jogo completos e estruturas. Eles existem, mas, na maioria das vezes, é sobre reutilizar seu próprio código de projetos anteriores.
fonte