Quando devo usar um mecanismo de física? [fechadas]

Desde que descobri o Box2D , estou usando-o para qualquer tipo de aplicativo semelhante ao jogo que tento escrever, desde protótipos muito pequenos ou programas pequenos para testar algo a projetos reais.

Graças a isso, é muito fácil lidar com qualquer coisa, desde colisões até a física real.

Às vezes, porém, tenho algumas dúvidas: se eu apenas tiver que lidar com círculos ou AABB e não precisar de ferramentas físicas avançadas (juntas ou coisas assim), acho que um mecanismo de física poderia adicionar algo grande, sobrecarga desnecessária.

Para retomar minha pergunta: você usaria o Box2D (ou outros mecanismos de física) em um jogo em que a física é realmente simples (como Super Mario, digamos)? E se não, por que?

Se a memória, o espaço em disco, o esforço de desenvolvimento ou o tempo do processador usado para o Box2D forem muito altos para seus objetivos, não o utilize. Caso contrário, não há razão para evitá-lo se você achar útil.

Algo tão fácil quanto o Super Mario não, pois ele realmente não tem muita física. (Mario não afeta a física de outro objeto com seu salto)

se você estiver usando física no sentido de vários itens (mais de um) usando física para afetar o resultado de outros objetos, eu usaria um mecanismo.

Minha resposta é sim, use absolutamente um mecanismo de física como o Box2D para coisas simples, porque você não deve gastar tempo desnecessário de desenvolvimento implementando alguns dos recursos que obtém rapidamente de um mecanismo de física. Por exemplo, defina um corpo estático e solte um corpo dinâmico, e aplique força ao seu corpo dinâmico para entrada direcional, e você terá um jogo de plataformas em alguns minutos. Não acho que um mecanismo adicione sobrecarga suficiente para fazer com que isso não valha a pena.

Se a "física" em um jogo é simples, não há necessidade de importar um mecanismo de física.

Uso o termo física livremente, já que há uma diferença entre modelar física e simular phyiscs. Uma coisa muito importante para diferenciar.

Por exemplo, em Mario Bros. quando você corre e para, desliza um pouco. Pense em como você pode implementar isso.

Você pode modelá-lo definindo todas as variáveis ​​necessárias: por exemplo. massa, gravidade, coeficiente de atrito, empuxo etc. e depois calcular sua nova velocidade, aceleração etc.

Mas vale a pena? Você pode simular o mesmo efeito, diminuindo a velocidade dos jogadores enquanto eles não estão em movimento ...

Algo como:

if( pressing movement key ) { 
 speed = 5; 
} else { 
 if(speed) speed--; // slide!
} 

A diferença é que uma é física e a outra não. Há prós e contras para ambos. Mas como regra geral para jogos simples, é muito mais fácil falsificá-lo.

Você deve decidir de acordo com a situação

Profissionais usando seu mecanismo personalizado

• Software sob controle (nenhuma alteração devido a nova versão)
• Adequado para o seu jogo (apenas os recursos necessários para o jogo, da maneira que você precisa)
• Flexibilidade (qualquer dinâmica louca que você quiser pode ser codificada, qualquer recurso futuro não dependeria do mecanismo)
• Experiência de aprendizado (talvez um dia você precise aprimorar um mecanismo e criar um)
• Menos estudo e programação de recursos simples (às vezes, fazer algo com um mecanismo pode exigir a compreensão profunda de sua estrutura. E pode não ser digno)
• Maior desempenho para recursos simples (para recursos específicos simples, você pode obter um desempenho superior ao de um mecanismo de uso geral)
• Menos memória (o objeto e o código podem ocupar muito menos espaço e memória quando apenas os recursos necessários são usados)

Profissionais do mecanismo físico de prateleira:

• Pode se adaptar ao novo hardware e novo sistema operacional sem muito esforço
• Menos esforço de estudo e programação para recursos complexos
• Maior desempenho para recursos complexos