Quand dois-je utiliser un moteur physique? [fermé]

12

Depuis que j'ai découvert Box2D , je l'utilise pour n'importe quelle application de type jeu que j'essaie d'écrire, de très petits prototypes ou de petits programmes pour tester quelque chose, à des projets réels.

Grâce à lui, il est tellement facile de gérer quoi que ce soit, des collisions à la physique réelle.

Parfois, cependant, j'ai quelques doutes à ce sujet: si je ne dois gérer que des cercles ou des AABB, et que je n'ai pas besoin d'outils de physique avancés (articulations ou des trucs comme ça), je pense qu'un moteur physique pourrait ajouter une sorte de gros, frais généraux inutiles.

Pour reprendre ma question: utiliseriez-vous Box2D (ou d'autres moteurs physiques) dans un jeu où la physique est vraiment simple (comme Super Mario, disons)? Et sinon, pourquoi?

physics peoro
la source
2
Faites ce qui vous semble bien. Pensez-vous que votre jeu a besoin d'un moteur physique? Pensez-vous que Mario bénéficierait de Box2D? Le plus récent Mario a certainement une sensation agréable avec une belle physique, mais il ne ressemble à rien de ce que j'ai vu construit dans Box2D.
Jeff
@Jeff: Cela dépend si la question "Quand dois-je utiliser Box2D?" ou "Quand dois-je utiliser un moteur physique?". Le nouveau Mario contient certainement un moteur physique.
1
@ Joe Wreschnig: Oui, mais y a-t-il un cas où un moteur physique n'est pas utilisé? Le seul moment auquel je peux penser serait une aventure textuelle, ou pointer et cliquer. Je suppose que cela dépend de la façon dont vous voulez définir votre moteur physique
Jeff
@Jeff: Peu de jeux de puzzle (non physiques) en ont besoin, par exemple Tetris, Bejeweled. Dans les jeux d'action, je pourrais affirmer que la plupart des shmups 2D ne bénéficient pas d'un moteur physique, car ils n'ont généralement besoin que de vérifications de chevauchement AABB / cercle, d'aucune réponse de collision, de trajectoires de mouvement absolument fixes et d'une vitesse constante. Les plateformes, cependant, sont toutes axées sur la physique.

Réponses:

8

Si la mémoire, l'espace disque, l'effort de développement ou le temps processeur utilisé pour Box2D est trop pour vos besoins, ne l'utilisez pas. Sinon, il n'y a aucune raison de l'éviter si vous le trouvez utile.

Gregory Avery-Weir
la source
2
C'est tout ce dont il s'agit. Si cela vous facilite la vie et ne vous bloque pas des plateformes que vous souhaitez, c'est une victoire, même si vous n'en utilisez pas certaines parties.
1
Ou, en d'autres termes - "La seule raison de réinventer la roue est d'apprendre à réinventer la roue."
Exilyth
4

Quelque chose d'aussi simple que Super Mario non, car il n'a pas vraiment beaucoup de physique. (Mario n'affecte pas la physique des autres objets avec son saut)

si vous utilisez la physique dans le sens de plusieurs éléments (plus d'un) en utilisant la physique pour affecter le résultat d'autres objets, alors j'utiliserais un moteur.

Spooks
la source
D'un autre côté, Mario a un élan, une accélération, une taille variable et une collision directionnelle, que vous obtenez tous "gratuitement" avec un moteur physique, et ne sont pas simplement de simples vérifications de chevauchement de limites.
Je suis d'accord - je pense que la plupart du temps, un moteur physique vous donnera beaucoup de choses qui seraient un peu une perte de temps pour vous implémenter.
Christopher Horenstein
3
Certes, il vaut toujours mieux ne pas inventer la roue, je trouve juste que si je veux juste une roue, je ne vais pas prendre un plan pour une voiture. En plus de cela, vous en saurez plus sur votre jeu dans son ensemble et plus facile à modifier / changer la physique.
Spooks
1
C'est une analogie vraiment horrible. C'est plus comme, vous voulez une roue et des essieux et peut-être une colonne de direction et un moteur mais peut-être pas le tableau de bord ou les vitres électriques.
3
qui ne voudrait pas de fenêtres électriques?
Spooks
2

Ma réponse est oui, utilisez absolument un moteur physique comme Box2D pour des choses simples, car vous ne devriez pas passer du temps de développement inutile à mettre en œuvre certaines des fonctionnalités que vous obtenez rapidement à partir d'un moteur physique. Par exemple, définissez un corps statique et déposez un corps dynamique dessus, et appliquez une force à votre corps dynamique pour une entrée directionnelle, et vous avez un jeu de plateforme en quelques minutes. Je ne pense pas qu'un moteur ajoute suffisamment de frais généraux pour que cela n'en vaille pas la peine.

Christopher Horenstein
la source
3
cependant, on pourrait dire que trouver comment implémenter et utiliser Box2D prendrait plus de temps que de créer une physique simple. (même si je suppose que cela dépend de l'étendue de l'utilisation de la physique)
Spooks
1
@Spooks: Je ne peux rien imaginer de "plus facile" que Box2D qui soit encore utile.
Je suis entièrement d'accord avec Joe ici; il n'y a tout simplement pas de remplacement simple pour l'utilité de l'utilisation de Box2D. Je ne peux pas imaginer coder quelque chose qui répondra à ses besoins plus rapidement que d'apprendre à créer des appareils et à définir la gravité avec Box2D.
Christopher Horenstein
1

Si la "physique" d'un jeu est simple, il n'est pas nécessaire d'importer un moteur physique.

J'utilise le terme physique de manière vague car il y a une différence entre la modélisation de la physique et la simulation de phyiscs. Une chose très importante à différencier.

Par exemple, dans Mario Bros. lorsque vous exécutez et arrêtez, vous glisserez un peu. Réfléchissez à la façon dont vous pourriez mettre cela en œuvre.

Vous pouvez le modéliser en définissant toutes les variables nécessaires: par exemple. masse, gravité, coefficient de frottement, poussée, etc., puis calcul de votre nouvelle vitesse, accélération, etc.

Mais est-ce que ça en vaut la peine? Vous pouvez simuler le même effet en diminuant la vitesse des joueurs lorsqu'ils ne bougent pas ...

Quelque chose comme:

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

La différence est que la physique n’est pas l’autre. Il y a des avantages et des inconvénients pour les deux. Mais en règle générale pour les jeux simples, il est beaucoup plus facile de le simuler.

aaronfarr
la source
1
Ce genre de physique est dégoûtant. Si vous allez le truquer, autant le rendre joli. friction = .9 ou un nombre inférieur à 1. speedX * = friction; speedY * = friction;
AttackingHobo
2
Bien sûr, à la fin du projet, cela se transforme en "si (en appuyant sur la touche de mouvement et sans bouger et sur la glace et non sous l'eau et vous avez ce bonus spécial et vous ne roulez pas dans une botte et ...)".
@AttackingHobo: Le but de l'article n'est pas de faire un bon algorithme de glissement. C'est pour illustrer la différence entre une simulation et un modèle.
aaronfarr
@Joe: Ce ne sont que des modifications de votre variable de friction. Peut-être que vous et @AttackingHobo devriez discuter: P Avec un moteur physique, vous devez définir les propriétés de chaque objet du jeu. Mon point est que brancher un moteur physique pour des jeux simples ne devrait pas être automatique. Sa situation.
aaronfarr
1
@aaronfarr: Il n'y a pas de différence entre une simulation et un modèle; à ces fins, ce sont des synonymes. Tout ce que vous avez montré, c'est qu'une partie isolée d'un modèle / simulation de jouet est moins codée que l'intégralité de Box2D.
0

Vous devez décider en fonction de la situation

Avantages à l'aide de votre moteur personnalisé

  • Logiciel sous contrôle (aucun changement en raison de la nouvelle version)
  • Adapté à votre jeu (uniquement les fonctionnalités dont vous avez besoin pour votre jeu, de la manière dont vous en avez besoin)
  • Flexibilité (toute dynamique folle que vous souhaitez peut être encodée, toute fonctionnalité future ne dépendra pas du moteur)
  • Expérience d'apprentissage (peut-être qu'un jour, vous devez améliorer un moteur et comment en créer un)
  • Moins d'étude et de programmation pour des fonctionnalités simples (parfois faire quelque chose avec un moteur peut nécessiter de comprendre sa structure en profondeur .. et peut ne pas être digne)
  • Performances supérieures pour des fonctionnalités simples (pour des fonctionnalités spécifiques simples, vous pouvez obtenir des performances supérieures à celles d'un moteur à usage général)
  • Moins de mémoire (l'objet et le code peuvent prendre beaucoup moins d'espace et de mémoire lorsque seules les fonctionnalités nécessaires sont utilisées)

Avantages du moteur physique standard:

  • Peut s'adapter au nouveau matériel et au nouveau système d'exploitation sans trop d'effort
  • Moins d'étude et de programmation pour les fonctionnalités complexes
  • Des performances supérieures pour des fonctionnalités complexes
Dimitri Ognibene
la source