Escrevendo o Game Engine do zero com o OpenGL [fechado]

Fechadas. Esta questão está fora de tópico . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela esteja no tópico do Game Development Stack Exchange.

Fechado há 6 anos .

Quero começar a escrever meu mecanismo de jogo do zero para fins de aprendizado, quais são os pré-requisitos e como fazer isso, quais linguagens de programação e coisas que você me recomenda? Além disso, se você tiver bons artigos e livros sobre isso, será ótimo. Desde já, obrigado!

Minhas linguagens e ferramentas de programação são:

C / C ++ é bom usar apenas C?
Pitão
OpenGL
Git
GDB

O que eu quero aprender com isso:

Motor de Jogo Principal
Renderização / Gráficos
Regras do jogo
Entrada (teclado / mouse / controladores, etc)

Em Renderização / Gráficos:

3D
Sombreamento
Iluminação
Texturização

c++ c

— Wazery
fonte

Dois pontos: essa questão, como é, é muito ampla. Quais recursos você deseja, quais plataformas deseja apoiar, quais paradigmas deseja explorar, quanta responsabilidade deseja colocar em uma linguagem de script (se houver) e várias outras coisas que eu ' Não vou me incomodar em continuar listando.

— Tetrad 30/04

Segundo: Existe uma sabedoria comum predominante que outras pessoas dirão que você não deve se concentrar em criar um motor sem um jogo. Um mecanismo sem jogo significa que você não pode provar que seu mecanismo é útil . Bons motores exigem que as pessoas comam sua própria comida de cachorro, por assim dizer. Um comumente ligada-TO blog vai em mais desse argumento é aqui: scientificninja.com/blog/write-games-not-engines

— Tétrada

^ Não apenas isso, mas escrever um mecanismo sem um jogo para motivar os requisitos de recursos resulta em fluência de recursos e design de API ruim. Até que você saiba o que precisa, sugerido pelos requisitos do jogo, você não poderá colocar coisas úteis em seu mecanismo. Da mesma forma, se você não precisou usar o mecanismo para programar, pode achar que algumas de suas decisões são realmente desajeitadas.

— ChrisE

Não vejo o ponto em suas listagens. O fato de você conhecer C / C ++ e Python nos ajuda, mas por que listar que você pode usar o controle de versão e um depurador?

— The Duck comunista

@TheCommunistDuck: Ei, isso é melhor do que alguns desenvolvedores. :)

— ChrisE

Respostas:

Você pode escrever um mecanismo de jogo em praticamente qualquer idioma usando praticamente qualquer método de renderização. Você pode escrever um mecanismo de jogo no bash usando a saída do console, por exemplo.

Então, acho que seria melhor definir exatamente o que você deseja aprender escrevendo seu próprio mecanismo. Existem muitos "campos" no desenvolvimento de jogos.

Motor de Jogo Principal
Renderização / Gráficos
AI
Trabalho em rede
Regras do jogo
Som
Entrada (teclado / mouse / controladores, etc)

etc .. A partir daí você pode até ter sub-tópicos. Em Renderização / Gráficos

2d ou 3d?
Modelagem
Sombreamento
Iluminação
Texturização
GUIs / Huds / Interfaces.
etc etc

Apenas um desses sub-tópicos poderia consumir muitas horas (ou anos!) De estudo!

Então, primeiro defina o que você deseja aprender. Comece simples.

Use qualquer idioma com o qual você se sinta confortável - embora alguns sejam mais adequados para determinadas tarefas. Por exemplo, o mecanismo principal e a renderização provavelmente são melhores com uma linguagem de nível "inferior", como C / C ++ (se você precisar de desempenho); mas algo como IA ou regras do jogo pode ser melhor realizado em um idioma de nível superior. Nada diz que você não pode misturar e combinar. Você pode escrever seu mecanismo em C ++, sua renderização em C (já que funciona bem com o OpenGL) e, em seguida, usar LUA para criar scripts para suas Regras de Jogo, etc.

Até o exemplo, existe um mecanismo de jogo chamado Slick2D. É escrito em Java e é de código aberto. É um exemplo de um mecanismo 2D simples, escrito e projetado muito bem. Você pode aprender conceitos básicos com isso, como loops de jogos, gerenciamento de estados de jogos etc.

Se você está confortável com C / C ++; Eu sugeriria dar uma olhada no SDL / OpenGL. Ele lida com algumas tarefas domésticas, como entrada, som, criação de janelas etc. e pode se concentrar em outras coisas.

— user697111
fonte

Ahh os dias quando eu estava aprendendo C ++ e consola de jogos eram divertidos incrível ... [cria novo projeto de console ...]

— Nick Bedford

Eu atualizei a minha pergunta, espero me dar um monte de recursos impressionantes :)

— Wazery

O SDL + OpenGL é uma excelente opção para iniciar um mecanismo de jogo personalizado.

Eu pessoalmente uso uma versão C-ish do C ++ porque descobri que funciona melhor para mim. Com isso quero dizer que não uso nenhuma exceção. Há duas razões para isso: a primeira e principal exceção exige código de exceção totalmente seguro, o que com o OpenGL e SDL não é exatamente fácil de obter. Mais importante, porém, dessa maneira, é muito fácil expor objetos C ++ sobre a ABI C, o que é incrivelmente útil se você tentar incluir uma linguagem de script na mistura.

Estou em um barco semelhante ao seu e escrevi algumas de minhas aventuras com SDL e OpenGL em um blog ( immersedcode.org ), no caso de alguém estar interessado.

Para a arquitetura geral, tenho duas sugestões: se você deseja um mecanismo 3D, consulte o livro "Game Engine Architecture", de Jason Lander. Se tudo o que você deseja é 2D, mantenha o design o mais simples possível e inspire-se com o XNA ou outros projetos.

Por fim: não ligue para o OpenGL em todo o lugar. Faça um favor a si mesmo e isole-o em alguns lugares, para que você possa alternar entre o OpenGL / OpenGL ES da área de trabalho ou até o DirectX posteriormente, se desejar.

— Armin Ronacher
fonte

Não use C, a menos que um detalhe de implementação o mantenha à mão. Caso contrário, use C ++, porque é uma linguagem muito mais capaz, e você sempre pode optar por não usar esses recursos posteriormente. Pessoalmente, não tenho nada a favor / contra Python, nunca o usei.

Eu não recomendaria o OpenGL contra o DirectX porque o DX possui uma abordagem moderna orientada a objetos, que é muito mais limpa e mais compreensível / menos propensa a erros. A interface oferecida pelo OpenGL é extremamente ruim em comparação.

A última coisa que tenho é que ouvi de muitas pessoas que confio que o GDB é uma porcaria, totalmente péssimo e o depurador do Visual Studio é de longe o melhor. Esta não é a minha experiência pessoal, então leve-a com um pouco de sal.

— DeadMG
fonte

"OpenGL vs. DX". O fato de o DirectX ter mais OO não é realmente importante. Tanto quanto é mais compreensível ... O OpenGL (anterior a 3) expõe uma interface bastante direta e fácil de digitalizar, pois é uma metodologia imperativa no estilo C. "Defina a matriz de projeção para isso. Inicie triângulos. Aqui está uma vert. Aqui está uma vert. Aqui está uma vert. A série 1.x de APIs OpenGL é boa para você se familiarizar com a programação gráfica e, combinada com SDL (ou mesmo GLUT ... urg), você pode criar um aplicativo em 30 a 50 linhas de código.

— ChrisE

@ Chris: Com certeza. Existe algo chamado extern "C", e seu uso apropriado torna a escrita de uma interface C bastante trivial, especialmente para Python, onde existe um conversor no Boost que facilita a ligação a ele. E os recursos da linguagem C ++? Eles são ótimos . Um maior uso dos recursos de linguagem do C ++ aumenta a confiabilidade de um projeto e a facilidade de codificação maciça para uma troca de desempenho muito menor do que aceitável. Os recursos de linguagem do C são patéticos em comparação. Por exemplo, o uso correto de um compilador C ++ moderno pode garantir que não haja vazamentos de memória. Fazer isso em C.

— DeadMG

@DeadMG: Se OOP era realmente um grande negócio, também, a resposta aqui é Java ou C #, e não C ++. O que eu discordo é que o uso dos recursos do C ++ não torna magicamente seu código melhor, mais rápido ou até mais confiável; você precisa saber como usar esses recursos e aprender um idioma, além de arquitetar um mecanismo, é realmente um bom uso do tempo? Não. Não é para alguém que faz isso pela primeira vez. Você pode aprender tudo em C em um dia ou dois, confortavelmente, e nunca se perguntar o que o idioma está fazendo. O OpenGL, a chamada básica útil definida de qualquer forma, oferece a mesma transparência.

— ChrisE

OOP não é grande coisa, nem em motores de jogos de alto desempenho. Claro que é útil, mas geralmente é a abstração errada. Ter um bom fluxo de dados, localidade e layout de memória geralmente é melhor. Embora muitas equipes estejam usando C ++, elas não usam a maioria dos recursos de C ++. Sem exceções, o menor número possível de virtuais, sem RTTI, sem STL / Boost. Por quê? Execução rápida e previsível e código pequeno em várias plataformas. Eu codifico em C e há apenas duas áreas nas quais eu prefiro usar C ++: bloqueios com escopo definido e matrizes genéricas. Não vale o incômodo IMHO.

— cancelado

No GL vs. D3D: Não há pilha de matrizes no núcleo GL3 / 4 e pilha de atributos. O GL e o D3D mapeiam a mesma arquitetura de hardware, mas muito tempo o GL parece mais fino. Certifique-se de que a máquina de estado GL seja um pouco complicada, mas também o hardware real;) Aprender qualquer uma delas é bom e, desde que você entenda o que realmente está acontecendo, você pode facilmente mudar para a outra (ou uma API do console).

— void