Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Update #5 : Three Dimensions, No Restrictions

MF

The Boar Studio
Patron
Developer
Joined
Dec 8, 2002
Messages
915
Location
Amsterdam
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.
AD_4nXdmfjht5nuqaKosIjdaePXxcUWlUM0gtuQg-wL3wfyE1xjeBQy43xMjba1Y-tg1xT9a_K4QQQ7BHfQAtrzQfQcIIrVtVTgwsm6_nIjwynNkl8XOxHJ5uFjYrhtY3DapgnkjHAq6J73wt4u-Ygxqg8OThnWI


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.

AD_4nXfwUhCjSrvwL1y0ImQ6rpuGA7S9xQHPhEEVHT51Os4f0tZwLFeQvtBFwk70rvmmyTTOCVw_lhOrbHRveuUMQBabnHD0HV48qQc-gDb3PfPSuJZdEHUr6uUIuIPAD_DyAYyGN3s_p2BUXDQedq3fkmEDGwhF

AD_4nXdHBKnNKVlh2DkQYHhuBlqufaxYDZP7Fz8R4zgHeKba3-6qpojx8cquOGx7tP7ipDLW0HUrH78qdTJV2yiKPt75mJPC1dimurTXLbI0AM0L8dzVtO25Yix34jnfCxow-O8szStdCZ3BrFBDAzk9kBval029


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.

AD_4nXehnqRHmB2JJ7Kkt7GahS2Ph_KIbYK9XFmwI2Eiob45cviWLbnlef6ini5bhySFnV9Iq2UdWs7dEBwbTRv-pgg5Qvdog6NO3zWcDtgommW7i1kriJeqSSBJZALYwIlqIz7-QM_TDV5gvkfnLdtyoavJEUI

AD_4nXeL-_Ut7kODo3pdwJhEq3fYUaH1uyZgdIT1FVo1xdtA0Ix8zF4vWUi-gm1aRDPi8JQuQ9_GNbqhfu3Wcm4j6I3it-j6Z6OHeCkTVkHeepcewqEBn748YYSH_3ZAygGL_reSbD4N9xpnHo4bu6DDkws3Eqc

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:

AD_4nXesj2JZUsKQciVv7p44iK-mC7feOtfACWNL1Y5sT-Ykci-J45zzk46q1VUKDikwssMQuXyLKTXcpyKW92PEsa1SLY0TUUucAOER2rmv5bBZbdgIbbcXrkO8ZiqfEx5hLql4cHHLCxhXmA7z8lCglnOUPDwI


Here is the new correct cross-planar movement:
1719526874434.png
1719526921381.png

We walked around underneath the enemy to an orthogonal plane and now we have a clear shot at the head.
1719528005879.png

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:

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom