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.

To Grid or not To Grid, Question about Grid in TB RPG

mutonizer

Arcane
Patron
Joined
Sep 4, 2014
Messages
1,041
I want to say 100% hex grid but I've been grinding my brain to the ground for a fucking long time on how to make it workable with an RPG. Pardon the rambling which might be off topic slightly but since this shit been on my mind for a long ass time as said, I'm in a hijacking mood.

For outside areas this works great and it's very simple but fuck me if I can sort out how to handle hex grid in an actual dungeon.
The "best" use of them for an RPG I've seen lately is Blackguards 1 & 2 but EVERYTHING in there is pre-designed and you can ONLY fight in widely open areas as it carefully prevents the player (though it's between battle/forced encounter system) from ever having to do anything where hex grid can be an issue, ie: corridors and whatnot. All the maps have carefully pre-rendered backgrounds made to fit perfectly for it's intended hex grid, and that sucks balls (and look structurally fucked up sometimes).

If you're not willing to go the "let's fuck the player over" way like that, it means opening up areas that can be a bitch for hex grids, dynamic generation AND structurally/architecturally sound areas.

As an example of what I mean:

iu

How the fuck do you do this kind of areas that can actually work with a hex grid system...dynamically for a cRPG.

Just look online, do a search for hex grid. Nearly ALL of them are outdoor hex-crawl stuff. There are almost no actually usable dungeon hex grid maps anywhere that are somewhat sensical, as if nobody ever figured out how the fuck to make it work and not look out of Gibbson's fucked up brain.

Even some interesting concepts like the one below (which might be used more dynamically) is actually a nightmare if you think about it (take the upper wall and imaging it continues right...in between hexes...)
GURPSDungeonPieces.jpg~original


Another solution is to use hex geomorphs which would be pre-generated with their various attributes and would just connect when dropped. In code that's not too hard, just have a bunch of tables storing the various values and whenever you insert a geomorph, insert that table (since this is hex based, it's of course a fucked up table) at the right place into your "overall map table" (or whatever). The advantage is that you can provide variation via rotation, keep "movement" areas pre-registered (including all terrain modifiers, semi-walls, etc) on the geomorph object itself, and yet keep the whole thing structurally sound while being dynamically generated.

After that you can drop couple tables, doors and other props in there, maybe in random "pre-calculated" hook points and you have a perfectly usable hex grid for all other mechanics you need, that still looks somewhat decent.

Formationtest-1.jpg

By keeping all "transit" areas on geomorph faces and keeping track of other connection types (open wall, etc), you can pretty much connect anything with anything relevant.....

Edit:
Another huge advantage of these is if you do "multi level layers", ie: balconnies, etc. As they are all geomorphs, they'll stay structurally sound with what's around them and what's above/below them as well, which is a HUGE plus once you start to play around with that shit...



Other than that...yea...hex grid for the win..and the nightmare.
As for square grids, I wish I could just "accept" them as they are so simple to fuck around with but they just won't do.
 
Last edited:

Davaris

Australian Game Developers
Developer
Joined
Mar 7, 2005
Messages
6,453
Location
Idiocracy
Use both. Square grids for regular floor plans, hex grids for organic shapes and the big outdoors.
 

mutonizer

Arcane
Patron
Joined
Sep 4, 2014
Messages
1,041
Been toying around with another system for a couple days: a mix of free movement and "hex positional".

Basically, all movement outside of some kind of melee engagement is semi free and gridless. It's actually a square based but just to make pathing/AI and shit like that easier, it's somewhat invisible otherwise as the squares are very small (like 20cm equivalent or something), but it's there. Movement cost is actually 100% distance based (in meter), just adjusted when snapped back onto the closest square. All rotations are "stepped" of 60°.
However, each "token" has an hex engagement grid emanating from them, size and shape depending on the weapon wielded (ie: polearms wielded for long reach have bigger engagement grids, horses have different shapes then humans, etc) and when moving your token, it's constantly looking if it can lock onto something (usually an enemy or at least another actor), but could be a prop (ie: door, chest, etc) as well I guess to simulate cover position (kneeling behind a crate), actions based on props (bashing a door) etc.
If it does, it'll override the "square" lock and use the "hex grid" lock instead, snapping exactly to the target token.


It's a bit odd at first and still in design phase but already that seem to solve a lot of the issue hex grid caused me, at least in theory. It should allow me to design everything very freefrom, from dungeons to overland areas, mix cramped and wide open areas as well, without worrying at all about fitting that onto an hex grid constantly, or even being annoying at how weird hex movement can look when represented on a computer game.
And yet, it allows proper use of facing and all other rules I wanted in there (based on GURPS mechanics really).

Here's a very crude mockup:

mockup_hexcombat.jpg
 

Ippolit

Educated
Patron
Joined
Dec 9, 2015
Messages
84
RPG Wokedex Bubbles In Memoria [Steve gets a Kidney but I don't even get a tag.]
How the fuck do you do this kind of areas that can actually work with a hex grid system...dynamically for a cRPG.

What about a combatsystem that treats 'cropped' hexes like for example a half-sized one next to a wall like combatground with heavy penalties/bonuses?
You could be able to hug the wall on that halved hex but you wouldn't be able to dodge. Or you step on a hex covered partially with crates/rubble etc. and get penalties for movement and a bonus for cover.
This way you would translate difficulties in areabuilding into a bunch of numbers needing to be adjusted.
 

Sitra Achara

Arcane
Joined
Sep 1, 2003
Messages
1,810
Codex 2012 Codex 2013 Codex 2014 PC RPG Website of the Year, 2015
Just wanted to add that continuous / dense grid can be a mess when dealing with AoOs / interrupts. Currently experiencing this with ToEE :negative:
 

mutonizer

Arcane
Patron
Joined
Sep 4, 2014
Messages
1,041
Just wanted to add that continuous / dense grid can be a mess when dealing with AoOs / interrupts. Currently experiencing this with ToEE :negative:


Not sure I'd call ToEE system really grid based, or really fucked up one indeed. With a grid system (as long as your unit size fits with your grid that is), you don't usually get the movement/placement/pathfinding clusterfuck that you get all the time in ToEE. Grid systems also make pathfinding itself fairly easy to process and if there's one thing that clearly no computer finds "easy" in ToEE, it's that fucking insane pathfinding :)
 

Sitra Achara

Arcane
Joined
Sep 1, 2003
Messages
1,810
Codex 2012 Codex 2013 Codex 2014 PC RPG Website of the Year, 2015
That's exactly what I meant, hehe. ToEE has an underlying grid for pathfinding, tile properties etc. (probably an Arcanum inheritance), but it's a very dense one. It does allow for a floating point offset though.
The grid tile size is roughly 2/3 of a typical human character's diameter, and it is further subdivided into 1/3 size sub-tiles, which is what the PF system uses. So while it's technically grid based, the grid is very dense and might as well be continuous.

To complicate things, it applies a 0.7 factor to the object radius when doing collision detection for the intermediate path points - which can cause errors when paths get truncated due to AoOs or Ready Vs. Approach actions.
 

mutonizer

Arcane
Patron
Joined
Sep 4, 2014
Messages
1,041
I see, and I see what you mean now related to my post and it's a good point, thanks :)

The "hex based " snapping mechanism I mentioned should in theory prevent some of the issues since soon as either active actor or target actor enters the reach threshold, the square grid is ignored and active actor just "snapped" onto the proper Hex. No "fucked up" positioning and pixel search like ToEE.
There is also no "free form" exploration at any time so pathfinding is only there in combat and would only look for fairly close positions (1 turn movement, for one unit at a time, and since 1 turn is 1 second, it's fairly small usually), which should also prevent the issue from popping up.

Finally GURPS mechanics allows for "through actor/obstacle" movement in many ways, "half hex" positioning is a thing and I want to follow that and allow for a lot of tactical interactions on the field, so apart from a couple things, there will be no real "obstacles" anywhere, but instead a waypoint system (so you can go around as you wish, doing your own pathfinding) and action node system (if you want to do something somewhere). For example, a tree isn't an obstacle, just a node (with the same kind of Hex auto snap of sort) which can be used in many ways (climb, use item on, climb, use as cover, etc) or "walked/ran through". A table is also a node, which can be used (go under, flip and use as cover, use item on, climb onto, go under, etc) but not an obstacle either. To go around, active actor can just manually waypoints outside snapping range as he wants or waypoints straight through it in which case pathing detects nodes on path and offer various movement options through each nodes (squeeze past, jump over, slide under, slam, etc) depending on the node type (or terrain, to jump over or dive in river, mud pits etc). To interact, just snap on it.
Likewise, other actors can be dodged through (both enemies and friendlies), slammed, rammed, trampled, or just engaged (at various reaches) so apart from a couple checks to prevent stopping in inappropriate areas (which can be just snapping them in proper hex), no a big deal, pathfinding wise that is. :)

For the AI, that's another discussion...
 

Sitra Achara

Arcane
Joined
Sep 1, 2003
Messages
1,810
Codex 2012 Codex 2013 Codex 2014 PC RPG Website of the Year, 2015
Yeah, I imagine it would need some sort of long-term planning which is where you might bump into these things. Probably not nearly as bad though.

And it sounds like a really cool system!
 

Hellwalker

Animmal
Developer
Joined
Jul 11, 2015
Messages
95
hmm a lot of interesting posts. I certainly want to use grid now. Probably square, since hex so many problems and I want to draw a grid on terrain.
 

Alchemist

Arcane
Joined
Jun 3, 2013
Messages
1,439
Finally GURPS mechanics allows for "through actor/obstacle" movement in many ways, "half hex" positioning is a thing and I want to follow that and allow for a lot of tactical interactions on the field, so apart from a couple things, there will be no real "obstacles" anywhere, but instead a waypoint system (so you can go around as you wish, doing your own pathfinding) and action node system (if you want to do something somewhere). For example, a tree isn't an obstacle, just a node (with the same kind of Hex auto snap of sort) which can be used in many ways (climb, use item on, climb, use as cover, etc) or "walked/ran through". A table is also a node, which can be used (go under, flip and use as cover, use item on, climb onto, go under, etc) but not an obstacle either. To go around, active actor can just manually waypoints outside snapping range as he wants or waypoints straight through it in which case pathing detects nodes on path and offer various movement options through each nodes (squeeze past, jump over, slide under, slam, etc) depending on the node type (or terrain, to jump over or dive in river, mud pits etc). To interact, just snap on it.
Just wanted to say that action node system sounds awesome. It seems like a great way to add interactivity and tactical options to the environment.

And a great thread topic by the way, I've been enjoying the debate and discussion.
 

mutonizer

Arcane
Patron
Joined
Sep 4, 2014
Messages
1,041
Been working on a prototype on this for a turn base combat system using mechanics similar to GURPS. Lots to do still but so far I'm happy with the overall concept as it seems viable and a good mix.
Once I've ironed out a couple issues with waypoints not hooking proper, how to react to "within hooking area" movement and other couple things, I'll have a look at adapting this to the action node system that would work with environment props as well (since this is just a "enemy" target).

(Might need to turn on "Annotations" if you have them off)
 

deuxhero

Arcane
Joined
Jul 30, 2007
Messages
10,092
Location
Flowery Land
I vaguely remember seing a video in which some developers of the Free and Open Source game FreeDroidRPG described some problems they encountered during development. Gameplaywise, FreeDroidRPG is a Diablo-clone, and so has no player-visible grid. They said one major problem they had was in programming the pathfinding code -- that the pathfinding algorithms they knew of depended on a grid and that without a grid they had great difficulty (I imagine that treating every pixel as a node may be prohibitive for performance). If I remember correctly, in the end, they used a user-invisible grid "behind" the terrain for the pathfinding, with pixel-based pathfinding within each square (generally, everything within a square would be passable).

So... You may want to consider the extra complexity of pathinding code (and other things) if you eschew a user-visible grid.

Golden Sun and the sequels also used an invisible grid on area maps, enabling the player (and NPCs who have a standard routine to wander in a limited area randomly) to move around in pixels, but all puzzles and spells that interact with puzzles snap to the grid, greatly simplifying everything from ToEE and DoS's shared problem where spells can be positioned so they are just barely in someone's space. It also serves the very nice mechanical function of enabling you to turn in place without greatly complicating the control scheme (either requiring a very precise light tap most players won't even realize is possible like Pokemon does, or the ackward need to press twice to about face, but that's only important with a d-pad), which is important for a lot of puzzles.

The newest Pokemon games also have free movement when the player uses rollerblades and snaps everything else to the grid (including the player if he moves in any other way). Not as elegant as Golden Sun, though part of it is due to the 3DS's questionable d-pad.
 
Last edited:

Telengard

Arcane
Joined
Nov 27, 2011
Messages
1,621
Location
The end of every place
Humans don't architectually design things to a hex, which is why it will always look wrong. Bees do, though, so you can make a nice hive with them. Humans are orderly creatures, who like things on the octagon shape, which the square grid represents (with diagonals). Nature is much more random than a hexagon, but hexagons look more right when used for outdoor maps simply because it jagged-izes the orderliness, which tricks the eye into not seeing order where there is a lot of order. Unless, that is, you're someone with a lot of spatial awareness, as those people just see math shapes when they look at a hex grid.

There isn't really a creative fix for bending shapes into a different shape and not having it look alien. If you absolutely must use a system with fewer points of attack and you absolutely must prevent line abreast in a third of the grid alignments, then your best bet to making something that looks human is to develop a unique architecture built around hex hubs. Don't think in rigid lines. Build your rooms in triangle orientation, so corridors are Vs, and thus reach 3 rooms, instead of binary between 2.
 

Severian Silk

Guest
Rectangular things are cheaper to build most of the time.
 

Galdred

Studio Draconis
Patron
Developer
Joined
May 6, 2011
Messages
3,880
Location
Middle Empire
[Steve gets a Kidney but I don't even get a tag.]
You can make hexgrids much easier to represent using staggered rectangles :
medium.jpg

Basically, make each hex tile composed of 2 rectangles, thos being staggered.
It works better outdoor, but can still work indoor.
Of course, some perspectives are out if you do this (you basically have to stick with JRPG perspective :
TUTO_chap3_ISOAXORM3.png

Otherwise, using preset, like you pointed out, can work well. I plan to do that for the indoor areas in my game : preset rooms and corridor sections semi randomly assembled. But you can see that walls are a nightmare to trace from the screenshots in my game's thread (the NW->SE ones are not aligned with the hex directions):
2oGSBor.png

The walls alternate on 3 hex positions instead of the usual 2 (it was done because of perspective).
If I were starting over, given the headache to get hexagonal tilesets done (2^6 border cases instead of 2^4, so 64 variations instead of 16 for the border between 2 environments), I would stick with RPG representation and the staggered 2 rectangular half tiles.
5XcXHNZ.png

Here is the tiled automap rule for forest to grassland borders for instance
 
Last edited:

DraQ

Arcane
Joined
Oct 24, 2007
Messages
32,828
Location
Chrząszczyżewoszyce, powiat Łękołody
Been toying around with another system for a couple days: a mix of free movement and "hex positional".

Basically, all movement outside of some kind of melee engagement is semi free and gridless. It's actually a square based but just to make pathing/AI and shit like that easier, it's somewhat invisible otherwise as the squares are very small (like 20cm equivalent or something), but it's there. Movement cost is actually 100% distance based (in meter), just adjusted when snapped back onto the closest square. All rotations are "stepped" of 60°.
However, each "token" has an hex engagement grid emanating from them, size and shape depending on the weapon wielded (ie: polearms wielded for long reach have bigger engagement grids, horses have different shapes then humans, etc) and when moving your token, it's constantly looking if it can lock onto something (usually an enemy or at least another actor), but could be a prop (ie: door, chest, etc) as well I guess to simulate cover position (kneeling behind a crate), actions based on props (bashing a door) etc.
If it does, it'll override the "square" lock and use the "hex grid" lock instead, snapping exactly to the target token.


It's a bit odd at first and still in design phase but already that seem to solve a lot of the issue hex grid caused me, at least in theory. It should allow me to design everything very freefrom, from dungeons to overland areas, mix cramped and wide open areas as well, without worrying at all about fitting that onto an hex grid constantly, or even being annoying at how weird hex movement can look when represented on a computer game.
And yet, it allows proper use of facing and all other rules I wanted in there (based on GURPS mechanics really).

Here's a very crude mockup:

mockup_hexcombat.jpg
And what would be the point of this?

If you just want locking you could have a radius/angle area doing the same thing with addition of not being fixed and being able to rotate freely.

How the fuck do you do this kind of areas that can actually work with a hex grid system...dynamically for a cRPG.

What about a combatsystem that treats 'cropped' hexes like for example a half-sized one next to a wall like combatground with heavy penalties/bonuses?
You could be able to hug the wall on that halved hex but you wouldn't be able to dodge. Or you step on a hex covered partially with crates/rubble etc. and get penalties for movement and a bonus for cover.
This way you would translate difficulties in areabuilding into a bunch of numbers needing to be adjusted.
Good idea.

If you really want grid for gameplay, it shouldn't be hard to either have common sizes of fraction hexes, or even calculate the modifiers and available areas dynamically - then you could have different grid, grids or even semi-tiled system (like what devs used for locations in Skyrim) for environments and have the game hexify them on the fly or at least when building the level.
 

mutonizer

Arcane
Patron
Joined
Sep 4, 2014
Messages
1,041
And what would be the point of this?
If you just want locking you could have a radius/angle area doing the same thing with addition of not being fixed and being able to rotate freely.

Idea is to force movement locks into an Hex grid (6 60° splits per medium sized actor, but works for larger actors as well) to avoid pixel hunting and positional buggeries, make engaging combattants (or nodes) and being engaged clear, fit nicely with the GURPS tactical combat mechanics (especially on longer reaches since they're just extended hexes locks) and I just like the look/feel of it. Meanwhile, outside of engagement/node locks, you can just move freely basically, this to avoid having everything on a hex based grid system that is, for anything not outdoor, always completely fucked up (as exampled by Galdred - no offense man!).
The only difference is that you cannot rotate freely but otherwise, it is a radius/angle system, based on 60° splits, and force-locking on certain conditions.
 

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