The Elder Scrolls V: Skyrim (Bethesda Game Studios, 2011) is currently one of the most recent, commonly recognized open-world role playing games (RPGs). It, as well as its predecessors, have been widely regarded as paragons of open-world RPGs and because of the greater amount of environmental immersion that that status demands, Skyrim and the few more recent installments of the series have enabled physics simulation on very large amounts of their game worlds. Just about any tool, piece of clothing, or other human-usable item has its own physics properties (center of gravity, varying degrees of flexibility, etc.) and can be knocked around, thrown, and sometimes broken into smaller pieces. The game also makes use of what's known as "ragdoll physics", which are applied to dead, unconscious, or otherwise incapacitated creatures, as well as some other fun fluid and fire spreading techniques and Newtonian physics for projectiles (arrows hitting objects, etc.).
When you begin to stack that amount of complexity into a simulated environment, you're bound to have some bugs. Some of the most notable physics-related bugs in Skyrim can be seen below:
Giants in Skyrim are actually very scientific creatures. They've even set about starting their own space program! Unfortunately, their test pilots have a nasty habit of dying horribly.
This is one of the most popular physics snafus in the game. It takes place during the opening sequence of the game, meant to be a grim, dramatic intro into the world during which the player barely escapes execution. Instead, the poor horses tend to take most of the punishment here. There are several different accounts of what is effectively the same bug, and many of them are recorded here.
Both of these bugs, as well as many (if not most) of the other physics related bugs commonly known in Skyrim, are caused by pesky limitations on how many physics calculations can be made in a given period of time, and how fast those calculations can be rendered to the environment. One of these such limitations is based on the frames per second (fps) at which the scene is being rendered. Throughout the course of game play, the fps fluctuates based on what load is being placed on the processing hardware by other processes running on the machine, and the number of objects being rendered in the game. The fps will also have different resting areas between computers depending on various combinations of hardware and software specifications.
When a physics enabled object is moved, it travels a certain distance in a certain period of time – giving it distance, velocity, and acceleration in all 3 dimensions just as we would understand it in the real world. The difference, however, is that the concept of a second is much less useful to a computer than it is to us, because computers are making calculations at speeds much faster; Speeds which also vary between machines. Therefore, the time parameter needs to be defined relative to the computer's processing speed. It turns out a nice way to do this is to define time as a number of frames. (Frames in rendering can be understood much the same way as in film – a frame is a single period in which all motion is static, from which the scene will progress to another frame, and so on at a speed that simulates fluid motion.) This is helpful because the number of frames being rendered over an amount of real time (frames per second) is relative to the machine doing the calculations. This helps ensure that operations will take the same amount of time regardless of the machine running them (as long as it meets certain minimum specifications). Otherwise, a computer running more calculations per second than another would launch that horse down the trail much faster.
The fact that physics calculations must be based on fps requires that we figure out a way to convert from a static measurement of time we can understand (seconds) to the nice frames that a computer can use. This requires the creation of a value, sometimes called the "optimal fps". It represents a rendering speed, in frames per second, at which an operation will take a certain amount of real time, that is:
To think of this from a development perspective, this means that if I want a spider to scurry at a simulated speed of 2 meters per second over a simulated distance of 3 meters, it would naturally mean that it should take 3/2 second to move that distance. In order to make that work in a rendering setting, I then have to assume I am operating at a fixed, optimal fps rendering rate, in Skyrim's case, 60 fps. I can then multiply:
Of course, in an actual development situation, this calculation is done during the model building and animating process, and is done on a much smaller scale, as any one animation in an interactive game will be very short and looped or permutated to facilitate any amount of time the user chooses to run the operation for.
Now, this is all great, but the rendering rate (fps) is almost never optimal, or even constant ‐ it is constantly fluctuating on any machine, at different rates and between different values depending on the software and hardware environment the game is running in. In order to compensate for this, a computer must also keep track of the rendering process' deviance from the selected optimal fps value. The calculation to determine deviance must run every single processing cycle alongside all of the other calculations that depend on it, although it is quite simple:
the deviance can then simply be used as a coefficient to time in any calculation, to scale the time appropriately to the current rendering speed.
For example:
My spider running at 2 meters per second with an optimal 60fps is doing so in 90 frames. Great! However, the user's pesky antivirus begins a full system scan, eating valuable system resources such as processor time and RAM. At the same time, the spider's brethren emerge from their dens in the surrounding area. The frame rate suddenly drops to 30fps. This means that my deviance is now no longer 1 (perfect, optimal frame rate), it is now 60/30=2. This means that those 90 frames now take 3 seconds to render, instead of 3/2 seconds! However, me being the excellent programmer I am, I multiplied my spider's velocity by the deviance value every processing cycle, which means that my spider's velocity as the computer understands it scales to 4 meters per second, which we would normally expect to cause the spider to traverse its 3 meters in 3/4 second. However, what we have just done by doubling the spider's velocity is half the number of frames required, to 30. In essence, when our game environment "slowed down" to 30fps, we simply doubled the spider's velocity so that the real-world time taken up by that operation is the same.
How does this relate to flying, stretching horses, you ask? The bugs shown above in Skyrim result from users running the game at frame rates higher than 60fps, which is Skyrim's optimal rendering rate. This causes the deviance to decrease to values less than one, which one would imagine would continue to work fine on the same principal as when frame rate drops. Problems begin to occur, however, when the frame rate begins to increase too far. What happens is we begin multiplying velocities, accelerations, and other time-dependent values by a coefficient so small that our velocities and accelerations (and therefore forces and all dependent quantities) grow very very large. This can cause two things:
1) eventually, some threshold somewhere is broken, whether it is the amount of space that was allocated to store that value, or the amount of force required to swing a carriage's hitch around to the side.
2) objects begin moving so fast that the frequency at which master calculations, such as fps deviance, are made cannot keep up with the objects' changes in position (and therefore speed, acceleration, force, etc.). This results in the computer being unable to account for any more forces acting on the object from its environment, so a small hill causes a carriage to accelerate rapidly upward, without the computer having time to say "gravity says no!!". This is also the cause of another Skyrim high fps bug in which objects will randomly fall through shelves, or fly off of them, sometimes causing chain reactions to devastating (and hilarious) effect.
Overall, our perception and use of time presents a limitation on the fidelity of our physics simulations that we have yet to overcome.
