INVERSUS is a mind-bending action-strategy game for one to four friends. Player movement is constrained to opposite colors of a black and white grid. Shoot tiles to flip their color in an attempt to block, trap and close in on the enemy. With every action changing the play space, each round evolves into a unique battlefield.
Interpolating between two points comes up all the time in game development. Most of the time, only a simple linear interpolation is needed. Linear interpolations are great because you can't really get them wrong. There is only one possible line connecting the points. Just follow it. When a curved interpolation is required, the solution gets far more complicated. There are an infinite number of curves to choose from and many methods for generating them: NURBS, Catmull-Rom, Bézier, Hermite, etc. I want to discuss a less common method that will generate circular shaped arcs.
Why would you want a circular interpolation? One reason might be that it is pleasing to eye, but it also has some practical use. If you are making a level editing tool that places roads (or making a game with procedural roads), you will may want turns to resemble their real-world counterparts. A second example, and the one I most often run across, is generating trails behind swords. Sword swings are often animated very fast. You only get a few sample points as the sword arcs through the attack. If you play the animation in slow motion, you'll find that the tip of the sword takes a rather circular path. By generating circular arcs between the sample points, a clean trail can be generated.
Here's an example of the sword trails I programmed for Spyborgs. There might have been only five or six samples along the whole spin, but I was able to create a smooth arc of vertices. The Spyborgs algorithm was a bit different from what I'm going to present here, but generated similar results (they were actually slightly worse if you know what to look for).
So, how are we going to create these curves? The solution lies in a piece of geometry called a biarc.
As far as I could find (as of today - March 5, 2014), there are only two open source implementations of floating-point to string conversion that are efficient, accurate and output "pretty" results. Each one uses a license requiring attribution in accompanying documentation . Personally, I don't use anything with an MIT or BSD style license because I'd rather avoid the legal annoyance of collating a ton of licenses into a user interface screen in the off chance that some PlayStation user really wants to see which open source library I used. Unfortunately, all of the public domain or Zlib-licensed alternatives don't produce accurate results (sometimes knowingly).
As an everyday tool that is often taken for granted, it might be surprising that it is so rarely implemented, but it's actually nontrivial to solve. It's also one of those problems complex enough where a wise engineer might recommend that "you never write your own", but I like a challenge and have been interested in it for a while. After spending a couple weeks investigating and experimenting, hopefully I can make it a bit more digestible for the curious.
I've worked on third-person camera systems for numerous games and I often need a method for smoothing camera motion as the player moves through the world. The player’s motion may create sharp, discontinuous changes in direction, speed or even position. The camera, however, should:
Avoid discontinuities in motion. Accelerate and decelerate as needed rather than snap to a new velocity.
Never let the player outrun the camera. The farther away he gets, the faster the camera needs to move.
Move exactly the same with respect to time regardless of frame rate.
To solve this problem, I often simulate the camera with a set of damped springs.