Home   |  Updates   |  Blog

This is the official page for information about updates and progress on Castle World. I'll publish about the game's progress and roadblocks here from time to time.

Jan 7, 2017

Wrote this page on algorithms and how the idea of Castle World came about.

Jan 1, 2017

There has been trouble between the pathfinding engine and the complexity of physics.

    Castle world was originally designed to be a tile-based world builder similar to Rollercoaster Tycoon. 3D and in a single dimension with Pathfinding and no physics solver. Pathfinding has become very complicated. More so than the original approach. I think implementing a collision solver but only for single objects would suffice to remove the burden of having to calculate exact locations for the player. It's also hard to figure out how to get the player to move smoothly across topology without creating waypoints between each triangle edge. If I added pathfinding I'd have to add nodes for each edge of each triangle. This would be painfully complicated and require a lot more data.

    If I want to add physics I'm going to have to figure out the simplest approach to doing so. I want every object to collide the world via its axis aligned bounding box. This prevents having to put abstract collision shapes into the world (sphere, ellipsoid, OBB). However it requires us to maintain all of the mesh geometry on the client. We could precompute the geometry however. This will allow us to do far better collision routines and keep the client-side triangles at a minimum. Since each cell has a vertex configuration. And it isn't interpolated, we can take this from a set of 255 precomputed tile shapes.

    We can't use simple downward raycasting since the world is convex although it's possible to simply snap the player's location to each polygon as he moves. Part of what the physics system solves is allowing the player to move smoothly across the terrain without needing to precompute vertex waypoints via pathfinding. We simply input a vertex, then generate a velocity vector, then the player moves in that direction. We adjust the player's position based on collisions with scenery. This is in every respect a physics solver, but simplified to 1 object at a time. It would require us to rewrite the tile code as well. A player may not end up at a tile if the velocity doesn't allow him to move there, so we can't pre-set the owned OBJ on the given tile. Most of the game determines pickup/grab logic by saying get/set OBJ for a specific tile. Since a player may be able to move freely about the terrain one tile can have multiple objects shared among other tiles. The OBB of a tree for instance would span several tiles. Each of those tiles would end up owning the object. So it'd be simpler to keep the tegular logic and assign the object to a single tile. Simply put... our tile-based approach is beginning to degrade. We want the player to move seamlessly, but also keep simple tile logic. Adding a physics solver for all objects decouples the GridObjs from their tile locations thus the tiles degrade into a simple polygon soup and grabbing an item for instance becomes finding an object within the radius of the player rather than looping the tiles next to him. Not hard to do, but it's more complicated. It's aesthetically more pleasing I'd argue to allow the player to move anywhere in the world, and also to show objects to fall with gravity, however the level of work required to do this could hinder or kill progress in this project since adding a 3D physics solver to a game is the most complicated thing to get working, next to an IK solver.

Back To Top