A program should take input, process it and give output. So what exactly does a physics engine take as input and provide as output?
A physics engine is responsible for simulating the motions and reaction of objects as if they were under the constraints of real-world (or similar to real-world) physics. It is, I should note, not usually a standalone program but rather a component of a larger, more interesting program (such as a game).
The input to a physics simulation is generally a collection of objects ("bodies") with properties (such as whether they are rigid or soft, their masses, shapes, and so on) as well as the collection of forces acting on those bodies.
Based on that input, the engine simulates updated positions and orientations of the bodies and applies ("outputs") them. Generally, when objects collide or overlap, that is included in the output of a simulation step in the form of a callback that client code can hook into to handle the specific gameplay logic relevant to the collision.
The input it speed, mass, and time, the output is new speeds. Sometimes rotation/angular momentum is an input and output too.
Essentially Physics engines try to simulate the effects of both gravity and collisions. For better physics engines that means they include both permanent and temporary deformation of objects, including splitting objects into multiple objects, and angular momentum of objects. Ideally they'd also simulate stress, e.g. how many trucks can cross that bridge until it collapses, but that's quite rare. Further simulation variables like air resistance would also count as physics engine, but as far as I know these haven't made it into any game yet.
Most physics engines are specialized to some degree and will simulate physics to a point that's necessary for the game. Physics engines for car games are often quite different from physics engines for 3D shooters. And the physics engine of a golf game might have excessive calculations of the interactions of the golf ball and the individual grass leaves, while completely missing the handling of high speed collisions and deformation of a car (in case it get's hit by a golf ball).
Typically a physics engine is used to make object in a game behave in a realistic manner relative to their environment without having to design specific animations for every possible scenario.
Specifically a physics engine will take a model with a set of properties (mass, joints etc) and render it in-game according to a set of parameters.
An early example of this were raggdoll engines (eg in Unreal) which modelled the way that limp bodies would fall down steps etc.
In current technology physics engines will often be closely integrated in an overall game deign package along with AI, in-game UI, cutscene generation etc.
You could certainly argue that physics engines go back to the dawn of games design eg pong could be considered a crude physics engine. However the main point is that a physics engine is capable of generating animation points on the fly based on a set of parameters rather than just using predetermined animation sequences from motion capture or manual animation.
As mentioned in other answers, in some classes or game like driving or flight simulation the physics engine may be fundamental to the game play and as such will be the main input driving the on-screen animation. Although typically the term is used for a general purpose tool which can be applied to a variety of situations without requiring very specific knowledge of or analysis of the context in question on the part of the developer, rather than a very specific simulator built from the ground up for a specific application.
A physics engine is responsible for simulating the motion of objects in "the world" (whatever that means in the context of the engine). Most physics engines nowadays use Newtonian mechanics to do this, as they are relatively simple to simulate and "accurate enough" for most purposes unless you're doing a space sim.
In theory, a "pure" physics engine would take three inputs:
- The state of the world (the objects, their positions, and their velocities) as of the last "tick" (the last instant in time that the engine had to model)
- How much time has passed since the last tick happened
- A list of the forces that have been acting on various objects in the world since the last tick
Taking inertia and the forces into account, the engine moves the objects around. The output of the physics engine is simply the new state of "the world", which the game can then read out and modify as necessary.
In practice, physics engines are not necessarily so "pure". Objects need to be created and destroyed, and sometimes they need to be moved around in ways that the physics engine's laws would not allow. This can sometimes be done outside of the engine, but sometimes it's done inside, and to do that, the engine needs more inputs. But the three inputs stated above cover the basics.
For example, let's say that you needed to move a character in a game using a joystick. If you aren't using a physics engine, this is pretty straightforward: when you see that the user is moving the joystick, you move the object accordingly. With a physics engine, you don't move the object directly: you apply a force to it, corresponding to the direction you want the object to go, and let the engine handle actually moving it.
What's the difference? Even if there is nothing else in the world, the object is unlikely to move in quite the same way, because the physics engine will handle things like realistic acceleration. But it is also possible that other forces might be acting on the object at the same time, as might inertia, and the engine will take all of them into account. For example, if you apply a northward force on the object, but something else is applying a westward force (or the object was already moving westward and nothing is slowing that down), then the engine will move the object northwest.
That's what a physics engine gets you: It keeps track of objects, their positions and velocities, and the forces acting on them. Thanks to the laws of mechanics, it can even create some forces on its own, to automatically handle things like collisions, friction, and gravity, all without you, the game developer, having to do anything extra.
A Physics Engine is basically a simulator of physics bodies.
It allows you do create a body (or multiple ones) specifying its physics properties like mass, size, density, etc...
It also allow you to define the properties of the physics world where the simulation occurs (e.g. gravity).
Finally it allows you to apply forces or create joints among bodies.
Once you defined all these things you can start the simulation and the Physics Engine will tell you where every body will be placed on the next timestep (which usually correspond to the next frame in your game). And the next one, and so on...
You see the Sprites moving on the screen because every frame the Game Engine ask the Physics Engine
Where is this body now?
and the Game Engine updates the graphics representation accordingly.
I usually like to see the Physics Engine like a tool to apply the physics laws in a declarative way.
Infact instead of writing code to describe which computations should be performed to determine where a body will be on the next timestep I simply describe the physics world setting the attributes of the bodies (and of the physics world itself) and I let the physics engine answer that question for me.