I have a bad habit of not posting updates here on anything like a regular schedule. This should change going forward, and I plan on having new blog post at least once a month if not more. The next alpha is not quite ready to go, but I do want to give you a little peak into the new climbing features I’ve been working on.
Tracking Ledges
To my knowledge, there are two common ways of determining what is climbable in a game. The first involves constantly checking the surrounding collision looking for something that the system considers to be a “ledge” or other climbable object. This has the advantage of theoretically working for any terrain, but can be difficult and computationally expensive to implement. The other – and I think more common – approach relies on hand-placed logical nodes that tell the system that a certain surface or ledge is climbable. This is often more reliable, as ledge traversal code can ask very specific questions to tailor-made objects, but it has the disadvantage of requiring a human to mark all of the objects that the player can climb on.
Freedom of Motion now features a hybridized version of those two approaches. The game analyzes the immediate area around the player, using the voxel data of the world to discover ledges. It builds a collection of Ledge objects that keep track of how wide and how deep the ledge is, as well as the distance to the ground from the ledge and a few other pieces of relevant information. With this map of the immediate area, the climbing code can make simple queries against a relatively stable set of information.
Here you can see a debug view of the ledge data around the player, with the discovered ledges highlighted in green. The green wire box denotes the search area for the system. Ledges are built and recycled as their terrain enters and leaves the search area. Since this information is cached, we avoid expensive physics-based computation such as the ray casts and capsule casts that powered the previous vaulting functionality.
Using Ledges
In theme with my previous post concerning code dependencies, the code that generates the ledges and the code that uses them are separated from each other. The state machine that manages all of the ledge-related movements expects a simple interface injection (ILedgeCollection) and knows nothing about the underlying voxels. A separate object (FoGLedgeCollection) implements ILedgeCollection and handles traversing the voxel octrees and responding to data changes. This separation of two very complex concerns means that the movement code isn’t tied to a particular data source; it doesn’t care how the ledges got there, just that it can read them.
Currently, the system supports vaulting over ledges, hanging from ledges with one or two hands, leaping from ledges, climbing up ledges, climbing between ledges, and dropping to a ledge from a side or crouch. Still to be added before Alpha 3 is network support for the climbing code so that remote players appear to be performing the correct actions.
In addition to climbing, this data can be used in other ways. For example, the current core movement system has severe trouble with standard steps. Eventually, the ledge data will be leveraged to allow the player to move smoothly up and down half-meter gaps. As always, you can follow my development via the release’s Trello board.