Saturday, December 14, 2013

Predicting Physics

Predicting physics in games is the use of characteristics of an object’s current status and movement to predict where it will end up. Although there are many uses for predicting physics and trajectory in games and at least as many strategies for accomplishing it, the most basic example would be looking at two objects with constant velocities, a target and a projectile, perhaps, and determining when the projectile should be fired in order to hit the target. Given a constant velocity and a starting point for each it is easy to calculate the point at which they should collide and, from there see how long it would take for each of the objects to reach the newly calculated end point; as soon as those two time values are the same, the projectile should be fired to guarantee that it will arrive at the collision point at the same time as the target. Physics prediction can be applied to something as simple as this, or as complicated as predicting the landing location of a projectile launched into a system with multiple points of gravity acting on the projectile based on the projectile’s relative location, which is what I set out to do.

A probably the most common way complexity is added to a projectile is to have it affected by a gravity force, causing it to follow an arch trajectory rather than just a straight line until it hits something. This kind of trajectory is demonstrated in games like Angry Birds and many combat-based games that involve jumping attacks or grenade-like weapons. Based on the basic kinematic equations, which take into account the acceleration due to gravity which is constant in most systems, the calculation of the time to reach an intersection point is quadratic. Once that is accurately implemented, however, the system should work in the same way.

Obviously, the more contributing factors to a projectile’s trajectory, the more complicated prediction becomes. Sometimes it just becomes over-complicated and inefficient beyond feasibility to calculate the trajectory in one shot. Depending on the complexity and the variability of the results, an iterative process can be used to make guesses about the required initial velocity to get within a certain degree of accuracy of a target’s location. Using this strategy, an initial guess would usually be made ignoring the complicating factors, then the real final location would be calculated based on that guess and, based on where that is relative to the target location, assign it as a boundary and make another guess that is higher or lower, depending on what was wrong with the initial guess. This would be iterated through until a guess is made that falls within a certain pre-determined degree of accuracy (Millington).

In my prediction system, the landing point was one of any number of planets in a solar system and there is little correlation between the initial velocity and the landing position, as it would apply to the aforementioned iteration system. I instead used iteration to basically run a limited simulation, feeding in the initial position and velocity and stepping through each frame to determine what forces would be applied and, thus, how the trajectory would be affected frame-by-frame. I iterated through each time step until either a collision was found or the prediction timed out according to a limit I determined. You can see in the screenshots that the pink dots are positions along the trajectory of the projectile, the yellow dot with a yellow trail.

Predicting physics is not innately too processor intensive, or have any specific platform requirements. Obviously iterative prediction methods are going to be significantly more processor intensive, with an increase in demand based on how accurate the calculated trajectory must be or how long until a simulation-based iteration will continue without reaching a target. Simple things such as the first example involving constant velocities and calculating just the timing takes only a few simple operations.

Works Cited:
Millington, Ian, and John Funge. "Predicting Physics." Artificial Intelligence for Games. 2nd ed. Burlington, MA: Morgan Kaufmann, 2009. 120-33. Print.

Monday, September 30, 2013

Networking for Games Game Jam Space Jam Games and Jam

Our task: create a slightly simplified version of Space Wars that could be played by 2-4 networked players in about two and a half hours.
The result: at the end of two and a half hours we had something that almost entirely didn't run.
Over the next few days Ian the Super Fantastic and I worked to finish it up and mend all the breaks.

The end product featured:
  • independent momentum and turning
  • toggle-able gravity and center planet
  • screen-wrapped player and projectile movement
  • a color selection lobby for player differentiation

The biggest challenge we faced was, what initially seemed to be, random data loss. Turns out we were trying to pack way too much data into single packets so it would try to read in data, get about halfway through it and run out of data to read. This lead to all sorts of interesting behavior and, considering the magnitude of the problem, surprisingly few breaks. Finally we decided to send packets that contained just a data identifier and the actual data  instead of packing everything into a single packet and sending it once a frame.

One thing I think we definitely should have done differently is handling player movement over the network. Currently each player simply sends it's screen coordinates every frame and each player updates the local version of that player. What we should have done was send the player's input when it was provided and let the actual movement be handled locally, perhaps with an actual position update every couple seconds to make sure things did not go horribly, horribly awry.

There were a couple things that went well, on the other hand. I think the general gravity and momentum based movement we implemented worked very smoothly. The color-selection lobby state I made is pretty spiffy as well. Each player flies around and chooses a color as indicated by color-overlays; the game refuses to start until there is only one player per color (as determined by the host), which we felt was a better way to determine the in-game differentiation without worrying about player order and assigning things based on it.

Ian Percoco is awesome: Ian's post