Estrutura ou biblioteca do Game Engine [fechada]

Estou nos estágios de planejamento de um mecanismo de jogo interno que estou prestes a começar a criar, que será usado para todos os meus jogos daqui para frente. Mas estou lutando um pouco com a forma como deve ser construído.

As opções se resumem a: estrutura ou biblioteca.

Meu objetivo básico é ocultar os detalhes do mecanismo o máximo possível para manter o desenvolvimento de jogos de alto nível em scripts e arquivos de configuração, tanto quanto possível. Mas também para reutilizar o mecanismo principal de qualquer ferramenta que possamos desenvolver no futuro.

As estruturas podem facilitar e facilitar as coisas para o desenvolvimento, mas você fica bloqueado. As bibliotecas são boas se você estiver interessado apenas em um subsistema específico. Mas precisamos colar tudo juntos em um jogo por jogo.

Bem, há também outro, construindo o mecanismo como um exe independente que lida com todos os recursos do jogo e todos os subsistemas. A lógica do jogo (e outras coisas dinâmicas por jogo) é feita exclusivamente em scripts com arquivos de configuração para configurar cada subsistema de mecanismo interno.

Qual deles me dará mais flexibilidade no futuro.

Obrigado.

Edit: Obrigado a todos, acho que eu estava olhando para isso na perspectiva errada. Não podemos realmente planejar algo assim sem o conhecimento prévio do que os jogos precisam; acho que é por isso que não existe um mecanismo geral para todos os gêneros.

Vou me concentrar primeiro no jogo propriamente dito e, depois de analisar iterativamente, no final de cada jogo, como fazer abstrações decentes para bibliotecas ou estruturas, dependendo do meu fluxo de trabalho (ou possivelmente de uma equipe futura).

Não se preocupe com o futuro ainda. Se preocupe com o seu jogo atual, agora. Caso contrário, você não vai chegar a lugar algum porque está preocupado com os detalhes.

Você deve se concentrar na criação do jogo primeiro e, depois, se o jogo tiver sido bem-sucedido o suficiente, você poderá extraí-lo para algo reutilizável para o seu próximo jogo. Isso evitará que você fique preso a outra coisa e lhe dará controle total sobre o seu projeto.

Construa uma estrutura.

Eu tenho experiência com a construção de ambos. Eu prefiro usar bibliotecas sobre estruturas. Os frameworks parecem muito restritivos e "mandões" . Então, quando criei meu primeiro jogo, quis criar um mecanismo composto de muitas bibliotecas que pudessem ser facilmente reutilizadas em outros projetos.

Foi um desastre. Gastei metade do meu tempo escrevendo código de cola entre minhas várias bibliotecas. Minhas bibliotecas também tendiam a ser inchadas com abstrações extras, de modo que se tornou uma tarefa enorme adicionar recursos às bibliotecas / componentes.

Agora, no entanto, meus mecanismos são construídos com o jogo que estou escrevendo em mente. Ainda mantenho meus olhos abertos para abstrações que me permitam reutilizá-lo ou os novos recursos que adiciono em jogos posteriores. Sou muito mais feliz e produtivo.

Para mim, o ponto de virada foi decidir não publicar meu mecanismo. Ainda posso publicá-lo, mas por enquanto, sabendo que não preciso justificar meus hacks específicos de jogos para outros usuários, criei um mecanismo mais adequado aos meus jogos.

Eu vejo isso com muita frequência.
Por que construir um mecanismo para usar em jogos futuros, quando você não sabe quais jogos precisam?
Por que não construir o jogo primeiro e depois outro e outro, reutilizando o mais rápido possível.
Então você tem uma biblioteca de códigos, provavelmente desorganizada, mas todas demonstradas como úteis.
Então você pode organizá-lo.

E para 'framework vs library', eu baseava o quanto você se cansa de escrever um loop de jogo repetidamente e coisas assim. ;)

Uma estrutura não precisa necessariamente prendê-lo. Veja o XNA.

Mantenha simples.

Se você não tiver certeza de qual caminho seguir - faça o que seu jogo exigir. Tente escrever bibliotecas pequenas e básicas para as coisas que você acha que podem ser usadas no futuro. Examine o desenvolvimento de software orientado a dados. Eu sugiro olhar para sistemas de entidade baseados em componentes. Não baseie o código em coisas únicas, como um jogador. Um jogador é apenas outro objeto, como qualquer outra coisa. Uma entidade possui componentes, talvez uma lista de componentes.

Ao escrever bibliotecas pequenas e contidas que interagem umas com as outras, você pode ir em frente e determinar quais usar novamente para o próximo jogo. Pessoalmente, tenho coisas como uma biblioteca "contêiner" para tipos de armazenamento de dados. Eu tenho uma biblioteca de matemática para essas coisas. Existem várias coisas como essas que você pode classificar e escrever como módulos. Câmera, efeitos, entrada, entidade, movimento, física, renderização, manipulação de recursos, encadeamento, a lista continua.

Escrever pequenos componentes independentes geralmente aumenta a legibilidade e as possibilidades de depuração do seu código.

Mike Acton e insomniac games (www.insomniacgames.com) escreveram muitos tópicos e discussões sobre desenvolvimento de jogos, em particular orientados por dados. Pesquise-os e veja que tipo de informação é complexa demais e que você acha interessante e compreensível. Eles são ótimos desenvolvedores com muita experiência.

Eu acho que você está fazendo generalização prematura. Não fique muito preso em perguntas de uso futuro no momento. Escolha uma resposta e corra com ela, aprenda com ela. Jogue uma moeda se você não tiver uma preferência.

Comece construindo um jogo. Ao criar seu segundo jogo, você terá uma idéia melhor de quais partes são reutilizáveis ​​e podem ser transformadas em funções robustas da biblioteca. Ao criar seu terceiro jogo, você terá uma idéia melhor de qual estrutura é reutilizável e pode ser transformada em uma estrutura robusta.

Em termos de flexibilidade, acho que você respondeu à sua própria pergunta: "As estruturas podem tornar as coisas agradáveis ​​e fáceis para o desenvolvimento, mas você fica preso ". Isso não significa que as estruturas tenham que ser inflexíveis; todo jogo, por exemplo, tem um loop de jogo. Framework XNA da Microsoft é uma biblioteca de 99%, mas o seu jogo estende a classe jogo que apenas fornece algumas funções em branco para as coisas que são garantidos para estar em cada jogo: LoadContent, Update, Draw. É um excelente exemplo de uma estrutura não restritiva.

Pode-se dizer que uma estrutura nada mais é do que uma biblioteca combinada com uma (s) classe (s) de modelo conectada (s) à biblioteca, pelo menos essa foi a minha experiência.

Costumo preferir bibliotecas a estruturas. O jMonkeyEngine , por exemplo, é ótimo, mas é uma estrutura e, como resultado, notei que ele recebe toneladas de críticas. O SDL , por outro lado, é incrivelmente popular; é apenas uma biblioteca. Ele fornece o que você precisa, mas sai do seu caminho para fazer o que quiser com ele.

Com uma biblioteca, não há necessariamente muita colagem a ser feita jogo a jogo - especialmente se você escrever partes da sua biblioteca para apoiar cada parte do ciclo do jogo; um contador / temporizador de quadros por segundo, por exemplo, impediria que a parte reescrita comummente precisasse ser reinventada a cada jogo.

Além disso, as bibliotecas podem ser tão gerais ou específicas quanto você deseja torná-las. Se você está criando um jogo de corrida e deseja que sua biblioteca tenha recursos específicos para corridas, tudo bem. É sua criação e você pode escolher exatamente o quão flexível você deseja. Isso seria muito viável em uma situação em que você tenha um contrato de longo prazo com a Nascar para desenvolver vários jogos de corrida, por exemplo. Você não gostaria necessariamente de uma estrutura para potencialmente amarrá-lo a um jogo clássico de corrida em círculo quando a Nascar aparecer e pedir um jogo offroad, mas você gostaria de uma biblioteca específica para jogos de corrida, já que sabe que a Nascar não é vai pedir um atirador.

Aqui está uma dica para o desenvolvimento também: se você escrever a biblioteca ao lado de um jogo, inevitavelmente acabará acidentalmente acoplando a biblioteca ao jogo ou tornando-a muito inflexível, não importa quanto planejamento você faça. Você descobrirá isso assim que tentar criar um jogo diferente com ele e passará algum tempo separando-o; isso não é necessariamente uma coisa ruim e você pode decidir conscientemente fazer isso, pois terá mais tempo livre após o lançamento do seu primeiro jogo. Mas se você está buscando uma biblioteca estelar desde o início, tente fazer dois jogos totalmente diferentes ao mesmo tempo e extraia as peças semelhantes na sua biblioteca. Você terá MUITO menos acoplamento, será muito mais flexível e seu terceiro jogo provavelmente ainda exporá algumas fraquezas, mas sua biblioteca será muito melhor no final. No entanto, é obviamente muito mais difícil e demorado.