A glitch refers to any unexpected and undesired result from a software simulation. Most commonly, the term refers to a geometry glitch, which occurs when objects do not behave as expected during interaction or collision. The result is the unexpected movement of one object through another, or two objects becoming entangled.
Implications for Gameplay[edit | edit source]
In the context of State of Decay, a glitch will typically result in a hostile mobile (zombie) seeming to move in an impossible way: through a wall, closed door, or another object. Consequently, the result is that the player is not as safe as expected; while a wall or closed door should stop a zombie, due to the geometry glitch, the zombie ends up coming through the barrier and is able to attack.
Glitches occur at the software level due to problems with collision detection, an algorithm designed to determine if two objects are coming into contact with each other and, if they are, handling the event. Consequently, there is no way to avoid glitching or predict when it will occur, but glitches are most common when a large number of mobiles (zombies) are clustered together.
Within the Simulation[edit | edit source]
Many simulations, including State of Decay, use a bounding-box approach to collision detection. An invisible box is drawn around every object, character, and structure in the game. This box, commonly called a "hitbox," serves as the simulation's way of tracking when two objects collide. When their hitboxes come into contact, the simulation should detect the collision and follow rules to prevent the further movement of the objects toward one another. In terms of gameplay, this is seamless and invisible to the player as it causes predictable results: running into a wall stops a car, two people cannot walk through each other.
Hitboxes are not precise, however, and are general approximations of the objects they represent. They do not match contours and sizes exactly and are typically slightly larger than their parent objects. Players experience this often in driving simulations: a car collides with an object even though it appeared as though there should have been enough clearance to miss it. This is because the hitbox for the car and the object in question came into contact, each being slightly larger than the objects drawn on screen.
This is all the result of using discrete, or a posteriori, collision detection. The simulation does not predict that two objects will collide; it only responds to collisions once they occur. Ordinarily, this is not a significant problem. However, when a large number of actors (in this case, zombies) cluster together, the system registers multiple hitbox interactions simultaneously. If the system is unable to cope with collisions quickly enough, an exception can occur, where two objects actually intersect. Rather than their hitboxes causing them to bounce off one another, the two are allowed to occupy the same place at the same time. This is immediately flagged as an error by the simulation and a correction routine is run.
The simplest solution for an intersection error is to move one of the objects, clearing the conflict. The simulation chooses one actor of the offending pair and repositions it a fixed distance in the X-Y-Z coordinate system of the game world. When the group is in the open, this correction may not even be visible. But when a group of actors is pressed up against a barrier, such as a wall, this repositioning can result in the moved actor appearing on the other side of the barrier. This is the actual simulation-based sequence of events that occurs when someone says that something "glitched through a wall."
While more sophisticated means to determine collisions, including a priori or predictive collision detection occur, developers are in a constant battle between providing a convincing simulation while being constrained by limited resources. This is why glitches are more common on a console than a PC or other, more powerful platform; the console's limited memory and number of compute cycles mean that the developers must shortchange some processes to ensure that there's enough memory and processor power left to drive other features, like detailed graphics and sound.