Quando você deve rolar seu próprio mecanismo de jogo? [fechadas]

Sou desenvolvedor de software há 5 anos e quero entrar no desenvolvimento de jogos para iOS. Eu brinquei com o SDK do iOS por cerca de 2 anos, participando de reuniões com cocoaheads, e sinto que tenho uma boa noção do objetivo-c, cacau e até c e c ++.

Tenho uma ideia de jogo e sei que usarei o Box2D, mas estou pensando se devo usar o cocos2D ou não. Os principais motivos são:

1. Talvez eu queira fazer coisas, em termos de gráficos, que não estão disponíveis no cocos2d.
2. Se eu rodar meu próprio mecanismo de jogo, terei mais controle.

Obviamente, o principal motivo para usar um mecanismo de jogo já existente é o tempo que economiza e facilita as coisas difíceis; mas para alguém que tem as técnicas necessárias para fazer o seu, isso faz sentido?

A maioria das outras postagens será "faça um jogo, não um mecanismo", mas vou assumir que você tem um jogo em particular que deseja criar e quer saber quando é uma boa idéia começar com o código de outra pessoa base ou começar do zero.

Você não deve usar sua própria tecnologia, a menos que saiba que precisa usar sua própria tecnologia . Isso pode parecer irreverente, mas é realmente a única resposta correta. Como na maioria das decisões, existem compensações. Somente você pode determinar para sua situação específica a análise de custo / benefício.

Você deve entender as seguintes coisas (essa lista dificilmente inclui tudo).

• Que middleware já existe por aí que você poderia usar ("mecanismo" ou não)
• O que esse middleware traz para a mesa, é interessante.
• Quão maduro / comprovado é o middleware, especialmente se você se preocupa com o suporte multiplataforma
• Que tipo de ferramentas o middleware fornece ou não fornece para ajudar a acelerar o desenvolvimento (não descarte ferramentas com sua própria tecnologia)
• Quais são as limitações do middleware (como exemplo simples, o Unity 3.x não fez sombras em tempo real a partir das luzes dinâmicas no iOS)
• Quais recursos específicos seu jogo em particular precisa ter .
• Quais são seus prazos e quanto tempo você precisará gastar para chegar ao ponto em que o middleware o levará em relação a quanto custa o middleware.
• Quão extensível é o middleware (por exemplo, você pode contornar o problema de sombra no iOS no Unity usando sombras de blob. Ou talvez sombras de projeção.)

(Observe que eu especificamente não coloquei "mais controle" lá em cima. Essa é uma frase carregada que pode variar de "Não gosto de código que não escrevo" a "Preciso ser capaz de ver, entender e ajuste todas as variáveis ​​no mecanismo de física para obter esse efeito específico. "A primeira não é realmente uma consideração válida, mas a segunda é.)

Pessoalmente, acho que rolar sua própria tecnologia para um jogo de baixo orçamento quase nunca vale o esforço. A quantidade de energia que você recebe nos motores baratos atualmente é ridícula. Você não está em um momento em que está decidindo uma licença de motor tripla A multimilionária ou não. Você não será capaz de vencer o que, digamos, o Unity oferece a você por US $ 3 mil. Ou o Cocos2d por qualquer preço (não é grátis?).

Agora, se o seu jogo estiver focado principalmente em algum tipo de tecnologia que outros mecanismos não podem fornecer ou não podem fornecer em uma taxa de quadros razoável, pode valer a pena investigar o que você pode fazer. Isso não significa que você jogue fora o outro meio completamente. Só porque você precisa do seu próprio processador, digamos, não significa que não possa usar outro middleware para física, som ou interface do usuário ou o que você tem.

Não role seu próprio motor. Role seu próprio jogo. Se você escrever um mecanismo ao mesmo tempo, será bom para você; caso contrário, você sempre pode refatorar quaisquer peças que queira reutilizar para torná-lo mais parecido com o "mecanismo".

As pessoas geralmente superestimam o que é necessário para escrever a parte "motor" de um jogo. Se você fizer apenas o que precisa, não demorará muito. A parte mais difícil é não ficar preso à infraestrutura de gravação e escrever apenas o que é absolutamente necessário para solucionar seu problema.

Eu usaria um mecanismo existente quando:

• Eu tenho um prazo apertado
• Eu tenho um conjunto de recursos fixos conhecido para poder escolher um mecanismo para esse

Eu acho que você deveria apenas escrever seu jogo, e talvez você acabe com um mecanismo mais tarde . Escrever o mecanismo gráfico (do que parece que você está falando) do zero sem usar nada, mas o OpenGL provavelmente só vai desperdiçar seu tempo. É um problema relativamente bem resolvido, portanto, geralmente você só mudaria o formato da API sem adicionar muito em termos de novos recursos significativos em relação a qualquer outra solução de terceiros disponível no mercado.

Se o Cocos2D ou alguma outra camada gráfica atender aos seus requisitos agora, use-o. Se seus requisitos mudarem durante o desenvolvimento, você poderá trocar o backend de renderização com relativa facilidade - se você realmente acredita ter a experiência e os meios necessários para criar um mecanismo, certamente deve ter o que é necessário para estruturar seu jogo, de modo a trocar o backend de renderização é uma operação relativamente trivial.

Crie seu jogo, permita que suas necessidades específicas controlem o conjunto de recursos do código que você escreve e escreva o código com reutilização e boa arquitetura em mente. Você acabará naturalmente com um "mecanismo" depois de concluir alguns projetos como este, e os concluirá mais rapidamente porque está impedindo-se de ficar atolado na fluência de recursos no nível da estrutura.

É muito simples. Qual é o seu principal objetivo: aprender ou chegar ao mercado?

Evite usar uma biblioteca se seu objetivo principal é aprender com a experiência de implementar os conceitos resolvidos pela biblioteca. Sempre que desenvolvo um jogo (meio período), meu objetivo é puramente aprender. Eu não me importo quanto tempo leva, é por isso que estou fazendo tudo do zero! Agora você decide.

Você deve rolar seu próprio mecanismo de jogo quando souber que é necessário .

Por exemplo, digamos que você não tenha dinheiro para gastar no Unity. Ou você prefere gastá-lo em novo hardware. Ou há problemas de desempenho com os mecanismos gratuitos disponíveis ou você precisa ter mais controle em um nível baixo.

Se você gosta de escrever software para escrever, então vai adorar escrever um mecanismo de jogo. Uma armadilha comum dos programadores iniciantes de jogos é ser pego escrevendo um mecanismo como um projeto perpétuo. Sinceramente, acredito que foi assim que surgiram todos esses mecanismos de jogos de código aberto - programadores de jogos que realmente não

Nesse caso, escreva seu próprio mecanismo.