I replicated my work on the sphere onto flat world. I picked up a few bugs along the way. It makes it all worth while. I'm not sure whether flatworld will see the light of day, but the being able to write the code twice so to speak does reduce the bug count and make the code more robust (IMHO).
I just finished re-using the code for the flatworld. The smoothing is a bit messed up along the borders. I'll have to amp down the noise for path finding. Still it is quite interesting visually.
Here is the path finding results of the nav mesh solution.
Here are my results of my dynamic regions. You can see the original in the first image. The next one shows what happens when a block is placed (the region becomes a few smaller ones). Then you can see what happens when the block is removed. Noticed the fragmentation. I can't really recreate the regions every time a block is added or moved.
I hope to have a navmesh style pathing going soon. The hexagon graph search pathing works fine.
These are the convex pathing polygons. You can see how they will speed up and make pathing much more natural.
Below, the dots in red show a natural super highway.
Here are my results from my water shed processing. Red borders a non-pathable area. Basically the borders of polygons. I'm going this in yet another separate worker lockless thread with the idea that when tiles are moves, the regions (nav mesh) can be recalculated. This is one of the first steps for creating a nav mesh.
This game has been meandering around quite a bit.
It has actually given me some time to thinking about where this game is going.
First of all, I'm still very keen on the spherical world. The idea is that each player will more or less own their planet and be able to visit others for various different reasons. Being a spherical world, it creates a natural limit on how much can be built out. In a sense you can complete a world and not be forever extending in different directions. There are different size worlds, some small, some big. The other thing is that the height map of each planet is limited as the hexagons get bigger as they get further away from the core. However I'm thinking that one way to deal with this is to have layers, each separated by some sort of air gap. One layer could be the ground, another the cloud layer (think floating islands) and yet another some subterranean cave system.
I like tactical games as well, so the game play focus is on tactical game play. So, the story will be fairly limited. An it will also mean a third person camera.
I like multiplayer games. The multiplayer aspect will be something like you can visit another player while the other player is off line. From a game play perspective, this could mean a lot of auto defense.
Just taking a break from putting pathing into yet another thread, I thought I would try some real textures. The yellow box is a light. I'm only using 4 static lights for performance.
What the thread does is both refresh the lookup tables (used for determine pathing between hexagons) when the terrain in modified and also perform any path searches. It is a lockless design so this pathing thread has it's own view of the world that it keeps up to date as frequently as possible.
The pathing is harder since I have ramps, but ramps are necessary. I really need to implement a nav mesh solution. This is not so much for performance, but so that the AIs don't move in a dog leg fashion.
One issue I had early on, is pathing and scale.
If I went a popular way of doing things, one could simply step up blocks. However this would mean the critters would need to be about the same size or bigger than the hexagons. This creates pathing issues.
I also didn't want this because I want Strange Orbitz to be more of a tactical game, players to really have a sense of place and for the cliffs to form barriers. I also need to limit the depth of hexagons. The issue here is that they grow larger as you go further out of the centre.
I wrote a program that creates the fbx meshes for each tile. There are literally hundreds of permutations because each hexagon is not the same in terms of symmetry. I created enough to make sure they look right and blend in ok.
If any one is actually reading this, once my grey box game is mostly there, I'm planing on bring in an artist to create textures and models.
One of my next tasks is to create the dynamic nav meshes. I have my hex based nav working ok, but nav mesh is a critical step up. With ramps this will become easier because the convex areas will hopefully become larger. I am doing most of the work in a separate thread. I'm planing of doing the nav mesh in yet another thread.
There will be roots spreading in organic ways across your planet - friend or foe, I need to test them. The cylinders are just representive - enough to detect errors.