High time for another update! I put off this update because this sort of thing doesn't look as cool or as 'progressy'. It might not be of interest to everyone, but maybe it's interesting to some.
Progress is steady, but most recent milestones have been in terms of tooling.
During a closed alpha test -meaning it was done in-house with a couple of friends- it became evident that I needed to revisit the combat map data and the way the game deals with walkable surfaces. Some surfaces are walkable for magnetized boots, some surfaces are not. A general exception is that on the moons, where gravity is greater than zero, every surface on the axis of gravity is walkable. This hasn’t changed, but the way the game determines these parameters is.
Why? Editing data for thousands of tiles isn’t feasible for the kind of combat maps I have in mind. In three dimensions, this adds up fast. I don’t want combat to be limited to set pieces. I want any area I designate as such to be a potential combat area. That means doing things by hand should be optional and not mandatory.
Tile Generator
The tile Generator takes a map and turns it into combat tiles, where something is either transversable (eg, not a solid object) or blocked. This hasn’t changed much, except I finetuned the system that detects whether something is transversable or not to accommodate half-tiles where you could duck under and things like that. I switched my test map from a shuttle battle set piece I made to a map with just three blocks so I can focus on pure functionality. Coincidentally this made me realize that it’s much more efficient to make a version of a map with rough shapes and use that for the tile generator so I can better separate aesthetics from mechanics. It’s a bit of extra effort per map on the front end that saves countless hours on the back end. I know grey blocking is common practice in game development for design, but its utility in parsing environments had eluded me until now.
Here you can see the results of the tile generator, where my visualization tool marks transversable grid elements as green, non-transversable elements as red and half-transversables as yellow.
The blue is much more complicated. These are calculated walkable surfaces. Meaning that if a grid tile is not transversable (ie blocked by an object) but has transversable neighbours (and is flagged as ‘magnetic’ but we’ll disregard that for now), it generates a walkable side on that face of the tile. Generating and visualizing these was a bit of a headache in and of itself, but nothing compared to using them as grids within grids. Which leads me to the next subject.
Pathfinding
I reworked the pathfinding to be modular and use walkable sides instead of the grid elements themselves when applicable. This meant I had to do some pioneering in the realm of pathfinding, but while playing 5D Multiverse Chess something clicked and I made it work. It’s too complicated to go into detail here, but this is the result.
Alright, so now I finally had a working system where characters could find paths across arbitrary planes in a 3D space. Amazing, and now that it’s a consistent mechanic it’s a lot more fun in combat. Notice something wrong, though?
That's right, the tiles don't rotate. They're cubes, after all, and we're only showing one side. Is it intuitive? No. So we need better camera controls.
Camera
“I’ll improve the camera controls so you can have the camera follow the currently selected character’s up orientation. Seems easy enough.”
It wasn’t. Multiplanar cameras are not trivial to implement. Fortunately Titan Outpost’s spherical map taught me how not to approach this. Smoothly moving from one plane to another is counterintuitive. Humans need a recognizable way to tell which way is up to map all cardinal directions to, even if there is no up. So I defined discrete camera planes that the player can select, including one approximating the current character’s up vector.
Tile shader
First, I drew meshes on each side of the grid tiles for visualization for the player. This was unoptimized placeholder that I knew I had to change eventually, but it worked in early development. Then I changed it to drawing optimized quads. Ultimately I realized that if I flipped the camera, the tile visualization would have to orient with it. Orienting all the planes was too slow, drawing and hiding them all took 10FPS off the rendering so that wasn’t an option either. So I ended up writing a shader that projects a tile visualization from the current camera plane on the grid. It also translates the ‘current grid level’ to the level on the axis you’re actually looking at. To explain what I mean, here is how it looks when the grid visualization changes orientation but doesn’t change planes:
Here is the new correct cross-planar movement:
We walked around underneath the enemy to an orthogonal plane and now we have a clear shot at the head.
11% thc because changing orientation decreases hit chance (can be mitigated with zero g skill) and this character's stats suck.
So. That's it for now. With all that out of the way, I reckon the pace will pick up again.
Progress is steady, but most recent milestones have been in terms of tooling.
During a closed alpha test -meaning it was done in-house with a couple of friends- it became evident that I needed to revisit the combat map data and the way the game deals with walkable surfaces. Some surfaces are walkable for magnetized boots, some surfaces are not. A general exception is that on the moons, where gravity is greater than zero, every surface on the axis of gravity is walkable. This hasn’t changed, but the way the game determines these parameters is.
Why? Editing data for thousands of tiles isn’t feasible for the kind of combat maps I have in mind. In three dimensions, this adds up fast. I don’t want combat to be limited to set pieces. I want any area I designate as such to be a potential combat area. That means doing things by hand should be optional and not mandatory.
Tile Generator
The tile Generator takes a map and turns it into combat tiles, where something is either transversable (eg, not a solid object) or blocked. This hasn’t changed much, except I finetuned the system that detects whether something is transversable or not to accommodate half-tiles where you could duck under and things like that. I switched my test map from a shuttle battle set piece I made to a map with just three blocks so I can focus on pure functionality. Coincidentally this made me realize that it’s much more efficient to make a version of a map with rough shapes and use that for the tile generator so I can better separate aesthetics from mechanics. It’s a bit of extra effort per map on the front end that saves countless hours on the back end. I know grey blocking is common practice in game development for design, but its utility in parsing environments had eluded me until now.
Here you can see the results of the tile generator, where my visualization tool marks transversable grid elements as green, non-transversable elements as red and half-transversables as yellow.
The blue is much more complicated. These are calculated walkable surfaces. Meaning that if a grid tile is not transversable (ie blocked by an object) but has transversable neighbours (and is flagged as ‘magnetic’ but we’ll disregard that for now), it generates a walkable side on that face of the tile. Generating and visualizing these was a bit of a headache in and of itself, but nothing compared to using them as grids within grids. Which leads me to the next subject.
Pathfinding
I reworked the pathfinding to be modular and use walkable sides instead of the grid elements themselves when applicable. This meant I had to do some pioneering in the realm of pathfinding, but while playing 5D Multiverse Chess something clicked and I made it work. It’s too complicated to go into detail here, but this is the result.
Alright, so now I finally had a working system where characters could find paths across arbitrary planes in a 3D space. Amazing, and now that it’s a consistent mechanic it’s a lot more fun in combat. Notice something wrong, though?
That's right, the tiles don't rotate. They're cubes, after all, and we're only showing one side. Is it intuitive? No. So we need better camera controls.
Camera
“I’ll improve the camera controls so you can have the camera follow the currently selected character’s up orientation. Seems easy enough.”
It wasn’t. Multiplanar cameras are not trivial to implement. Fortunately Titan Outpost’s spherical map taught me how not to approach this. Smoothly moving from one plane to another is counterintuitive. Humans need a recognizable way to tell which way is up to map all cardinal directions to, even if there is no up. So I defined discrete camera planes that the player can select, including one approximating the current character’s up vector.
Tile shader
First, I drew meshes on each side of the grid tiles for visualization for the player. This was unoptimized placeholder that I knew I had to change eventually, but it worked in early development. Then I changed it to drawing optimized quads. Ultimately I realized that if I flipped the camera, the tile visualization would have to orient with it. Orienting all the planes was too slow, drawing and hiding them all took 10FPS off the rendering so that wasn’t an option either. So I ended up writing a shader that projects a tile visualization from the current camera plane on the grid. It also translates the ‘current grid level’ to the level on the axis you’re actually looking at. To explain what I mean, here is how it looks when the grid visualization changes orientation but doesn’t change planes:
Here is the new correct cross-planar movement:
We walked around underneath the enemy to an orthogonal plane and now we have a clear shot at the head.
11% thc because changing orientation decreases hit chance (can be mitigated with zero g skill) and this character's stats suck.
So. That's it for now. With all that out of the way, I reckon the pace will pick up again.
Last edited:
