Euler Integration is one of the most basic and intuitive concepts in game programming. It is common for beginners to implement it in their projects without knowing exactly what it is, although they may have seen it before. To demonstrate, this is the generic form of Euler Integration as it applies to game programming:
Horizontal Speed = (Horizontal Speed + Horizontal Acceleration)* Time Step;
Vertical Speed = (Vertical Speed + Vertical Acceleration) * Time Step;
X Position = X Position + Horizontal Speed;
Y Position = Y Position + Vertical Speed;
However, it is also common to see Euler Integration simplified to this:
Horizontal Speed = Chosen Value For Horizontal Speed;
Vertical Speed = Chosen Value For Vertical Speed;
X Position = X Position + Horizontal Speed;
Y Position = Y Position + Vertical Speed;
Essentially, with Euler Integration, the programmer has absolute control over the values of the Horizontal Speed and the Vertical Speed of an object at any given time. This is a double edged sword, unfortunately: The control Euler Integration gives the programmer over these two values is at the price of always needing to check if the Horizontal Speed and the Vertical Speed are behaving properly. Euler Integration is not naturally capable of adapting these values to a given situation.
Here is a diagram showing the basic behavior pattern of Euler Integration:
images.associatedcontent.com/image/A1269/1269656/470_1269656.png
As can be seen, there is no association between the Previous Speed value and the Speed value. They have no interrelation. The result is that in certain situations, like collision detection, the programmer must not only write an algorithm to move the colliding objects away from each other, but must also write an algorithm to calculate and apply the changes in velocity for each object.
However, there are even more complicated situations than merely collision detection where Euler Integration is a poor choice, like preserving momentum, swinging from a rope (or position constraints in general), and advanced physics simulations where the rotation of objects is taken into account. Unfortunately, these can be fairly common design goals, and Euler Integration does not give programmers the proper tools to handle them. It’s possible to use Euler Integration for these things, but incredibly difficult.
However, it would be wrong to call Euler Integration all bad. For situations where acceleration will not be a factor, Euler Integration is simpler and faster than other integration techniques, like Verlet Integration and Runge-Kutta. It all depends on the situation which is best to use and it takes a good deal of experience to make the proper choice, although I can offer several guidelines:
1. Euler Integration is a natural reduction of other Integration techniques in cases where acceleration will not change and the speed of an object is constant. For straight projectile weapons Euler Integration can often be the preferred choice.
2. Euler Integration is acceptable for situations where movement is overly simple. For example, in games like Pacman or Space Invaders, Euler Integration is ideal. In games like Galaga where the movement is erratic and unpredictable, however, Verlet Integration might be the preferred choice.
3. Euler Integration can be suited to scripted animations or events where the implied motion is more important than the accuracy of the motion. For example: Particle effects. There is rarely a need for the particles to behave accurately, they do not usually affect game play.
A good understanding of Euler Integration and its uses and its downfalls is integral to competent game design. Everyone who fancies themselves a game programmer should spend a good deal of time experimenting with it until it is familiar in implementation and nature.
