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.