5
\$\begingroup\$

What's the difference between a game engine and a physics engine? How do they work together, and what's the meeting point between them?

\$\endgroup\$
1

2 Answers 2

9
\$\begingroup\$

As far what physics engines do, I wrote an apparently decent post here: How does a collision engine work?

A game engine is software that is intended to make it easy to develop a game without needing to invest in a great deal of additional technology. In other words, it implements all the basic technologies of games like graphics, physics, networking, input, AI, etc. in such a way that they are easy to tie together with game-specific logic.

Some game engines are very specific to a certain genre or otherwise impose a lot of assumptions on the games being made with them. In exchange, they are almost complete out of the box solutions for those target games. Other game engines are much more generic, but require engineers to spend more time implementing genre-specific code.

A physics engine had the sole purpose of moving objects around in a simulated world. They take the physics properties of objects, such as mass, shape, material, current trajectory, etc. and then calculate a new position and state for all those objects.

The line between game engine and physics engine is relatively clear. In many cases, they are completely separate libraries, such as an Unreal Engine game using the PhysX physics library.

In general, the game engine feeds initial state data to the physics engine, and the respones to physics engine responses. For example, the game engine loads a level and tells the physics engine that there are 10 objects in the scene at given positions. The physics engine then process updates to those obects' states, as the game engine asks the physics engine to update the objects and report on their changes. Graphics data is often synced up to changes from physics, so that changes made by physics show up on the player's screen.

The game engine may respond to events from the physics engine. The physics engine might raise an event when two objects collide, or when two objects that were touching separate. The game engine will forward these events on to game logic code, which might respond by applying health damage to objects or adding points or so on.

Game logic may also influence the physics simulation. Game logics may decide that gravity is suddenly inverted because of a power up, or that the player's character gets a vertical force applied because the player hit the jump key, or so on. This is often accomplished by creating a new object as defined by the physics API in use, where the objects represents a force or such.

Game engines will typically try to unify all their systems behind a common API and object model. For example, a component-based game engine will typically have a ColliderComponent and a BodyComponent. The former will register a shape with the physics library (which also handles detection of colliding shapes without any physical response), and the later provides information to the physics library about how to handle collisions, forces, etc. An object in such an engine may only have a Collider if it is just looking to find out if objects collided (like a trigger).

Many games do not have a "game engine" per se. Smaller games typically have their game logic and their supporting code all merged together. Which is just fine: enforcing a strict separation increases complexity and wastes time if the code is not going to be reused for multiple titles in different genres.

Likewise, many "physics engines" are not generic and are integrated directly with the game engine. This is especially common in platformers, and many 2D games in general. Some games require such specific physics requirements that a general purpose physics engine simply makes little sense to use. Mario games, for instance, don't model anything in a physically accurate way, and the game behavior is almost entirely based on very specific physics behavior quite different than what a general physics simulator handles, so a general 2D physics library like Box2D is entirely illfitted to the game.

\$\endgroup\$
3
  • \$\begingroup\$ Well there goes user827992s thunder ! lol \$\endgroup\$
    – Sidar
    Commented Aug 22, 2012 at 2:44
  • 1
    \$\begingroup\$ @Sidar: just because it's a long-winded answer doesn't mean it's a good one. ;) \$\endgroup\$ Commented Aug 22, 2012 at 6:02
  • \$\begingroup\$ The votes seem to beg the differ ;D But then again what the majority thinks isn't always right... \$\endgroup\$
    – Sidar
    Commented Aug 22, 2012 at 14:29
3
\$\begingroup\$

Well, Game engine is a generic term, Physics engine is more specific, the "problem" is that the functionalities that a game engine provides are up to the developers that have coded that particular game engine.

There are very basic game engine that have no physic support or they expect you to add to it manually, and game engine that support physics and fractures in real time.

Your view shouldn't be about how they work together in the first place, just look at what a game engine offers and if you need a physics engine add it to your code.

There are also some engines that mimic the physic with pre-baked collision and explosions, there are several approach to this, depending on what you have, what you want to achieve and what is your target machine, you better look to the features and how they are implemented, only the name "physics engine" can't tell you what you are dealing with.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I would like to add that a Physics Engines are build to be modular. They aren't just used for games. Where a Game Engine is ( if done well )optimized specifically for games. I've always seen Game Engines as a collection of "engines" that drive the whole thing. At least with the big Game Engines that is. \$\endgroup\$
    – Sidar
    Commented Aug 21, 2012 at 22:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .