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

Hellwalker

Animmal
Developer
Joined
Jul 11, 2015
Messages
98
Hello,

I'm in the process of researching a tech base for the RPG game, which will feature Turn-Based Combat in the manner of Fallout 1,2, Age of decadence, etc. That is to say a cRPG style of Turn-Based game, where you actually move around the map during combat. I decided to throw a little prototype and had some trouble creating a decent grid mechanics. I started looking at how other games handled it and my first stop was the Enhanced Edition of Divinity: Original Sin. I noticed they actually didn't have any grid, the game used distance to calculate your point cost for movement and used some additional UI to show spell ranges and the like.

Now, Codex being Codex I'm sure there will be a million reasons and one about why and how Divinity: Original Sin is a worst thing in the history of life. But assuming the art of separating individual components and judging them on their own right has not been wiped from the face of the earth yet, lets employ it now and take User Interface and User Experience portion of Divine: Original Sin. While not without flaws, I think UI and general feel and polish of the gameplay is some of the very best I have seen in turn based games. Playing around with some of the combat scenarios inside I got to like this system. It feels to me i have more options for character placement, it does not feel as constricting, it's more immersive because of the terrain and lack of giant ass grid interface printed all over landscape. But there is also a feel you are loosing some of the tactical overview depth.

I wanted to get a second opinion on the subject, if anyone cares to share their thoughts please do. Do you prefer grid system or distance based system? and of course most importantly why?
 

DraQ

Arcane
Joined
Oct 24, 2007
Messages
32,828
Location
Chrząszczyżewoszyce, powiat Łękołody
Gameplay wise there is no point having grid, but if you don't then you'd better make sure you have GUI that's up to the task when it comes to ranges, blocking, movement cost, etc. as the player can no longer rely on grid to judge whether or not they can reach an enemy or block a passage.

DivOs is mostly VERY solid combat gameplay-wise, but not without flaw - for instance it fails to convey to the player whether their chosen path crosses into environmental hazards which is quite important.
 

Niektory

one of some
Patron
Joined
Mar 15, 2005
Messages
808
Location
the great potato in the sky
I prefer grids. Distance system sounds cool on paper, but in practice it's too fiddly. It makes judging distance more difficult - on a grid, a difference between 3 and 4 tiles distance is immediately visible, without a grid it's much less obvious whether it's 3, 2.9 or 3.14159 meters. And it's something you need to know if you can move at most 3 meters or attack with a range of 3. It also results in more micromanagement of movement, if a difference of a few pixels can mean a difference between life and death. It results in a lot of ambiguity and guesswork which is not present when you have a grid.

These concerns can be alleviated with a good UI, but it's a lot of work and easy to screw up. Using a grid you'll save yourself a lot of trouble, so that's what I'd recommend if you don't have strong reasons to do otherwise.
 

Hellwalker

Animmal
Developer
Joined
Jul 11, 2015
Messages
98
Thanks for the feedback.

Gameplay wise there is no point having grid, but if you don't then you'd better make sure you have GUI that's up to the task when it comes to ranges, blocking, movement cost, etc. as the player can no longer rely on grid to judge whether or not they can reach an enemy or block a passage.

DivOs is mostly VERY solid combat gameplay-wise, but not without flaw - for instance it fails to convey to the player whether their chosen path crosses into environmental hazards which is quite important.
actually they added that stuff in enhanced edition.
http://imgur.com/jJ1wF0j
I prefer grids. Distance system sounds cool on paper, but in practice it's too fiddly. It makes judging distance more difficult - on a grid, a difference between 3 and 4 tiles distance is immediately visible, without a grid it's much less obvious whether it's 3, 2.9 or 3.14159 meters. And it's something you need to know if you can move at most 3 meters or attack with a range of 3. It also results in more micromanagement of movement, if a difference of a few pixels can mean a difference between life and death. It results in a lot of ambiguity and guesswork which is not present when you have a grid.

These concerns can be alleviated with a good UI, but it's a lot of work and easy to screw up. Using a grid you'll save yourself a lot of trouble, so that's what I'd recommend if you don't have strong reasons to do otherwise.
I see what you mean, with grid you can tell exactly what the distance between you and enemies will be.
 

Haraldur

Augur
Joined
Oct 1, 2007
Messages
308
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.
 

Hellwalker

Animmal
Developer
Joined
Jul 11, 2015
Messages
98
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.
I will most likely use Unity 3d game engine. I have most experience in it and asset store is a big plus on saving time on non-essential functionality.
Unity comes with decent path finding system that is based on generating a navigation mesh. It should at least be able to handle Turn Based Strategy terrain pretty well.
In that regards, at least from initial tech scouting so to say, grid system looks like a lot of extra work and in fields I have very little experience in (Shaders).
I will still need to get my hands dirty with actual prototypes to know for sure.
 

Nathaniel3W

Rockwell Studios
Patron
Developer
Joined
Feb 5, 2015
Messages
1,225
Location
Washington, DC
Strap Yourselves In Codex Year of the Donut Codex+ Now Streaming!
Another thing you'll want to consider is drawing the characters' paths. In Himeko Sutori (which uses UDK), I'm using grids, and each node in the grid draws its part of the path (it's a decal in UDK terms) if the characters pass through it. If you don't use a battle grid, showing your players the movement path might be harder. And as DraQ said, not being able to see the path can be really bothersome.
 

DraQ

Arcane
Joined
Oct 24, 2007
Messages
32,828
Location
Chrząszczyżewoszyce, powiat Łękołody
actually they added that stuff in enhanced edition.
http://imgur.com/jJ1wF0j
Not really. You still can't tell if the line is barely skirting dangerous ground or cloud, or if it's actually just a tiny bit inside.
This may be the sole difference between brilliant tactical maneuver and getting AIEEE*FWOOSH!*'d.

Drawing a colorful markers in points where line crosses into hazards and coloring the segment inside would be a simple solution.
 

vonAchdorf

Arcane
Joined
Sep 20, 2014
Messages
13,465
Grid-less systems make blocking paths, zones-of-control etc. less obvious.
 

Mr. Pink

Travelling Gourmand, Crab Specialist
Joined
Jan 9, 2015
Messages
3,042
PC RPG Website of the Year, 2015 Codex 2016 - The Age of Grimoire Steve gets a Kidney but I don't even get a tag.
Hexagons, lad. It's got to be hexagons.

I prefer grids for most games though, especially ones where movement is limited by movement points, since nothing is more infuriating than being short by 0.0001 meters out of range.
 
Self-Ejected

Davaris

Self-Ejected
Developer
Joined
Mar 7, 2005
Messages
6,547
Location
Idiocracy
I will most likely use Unity 3d game engine. I have most experience in it and asset store is a big plus on saving time on non-essential functionality.
Unity comes with decent path finding system that is based on generating a navigation mesh. It should at least be able to handle Turn Based Strategy terrain pretty well.
In that regards, at least from initial tech scouting so to say, grid system looks like a lot of extra work and in fields I have very little experience in (Shaders).
I will still need to get my hands dirty with actual prototypes to know for sure.

If you go with Unity and want to do hex or square grids, check out MapNav 2. I've got it and the code base is tidy.
http://plyoung.com/
 

Tigranes

Arcane
Joined
Jan 8, 2009
Messages
10,350
As others have pointed out, grids have no special benefit, but non-grid solutions like DOS often add nothing significant while making things less intuitive and usable. You don't want to end up with situations where players think they're close enough to attack but they're not, or they can't tell how close they can get to X without touching it, etc. Also easier to balance encounter design, APs, etc. when you're working with a grid system.
 

zwanzig_zwoelf

Graverobber Foundation
Developer
Joined
Nov 21, 2015
Messages
3,081
Location
デゼニランド
Magna Carta: POA had a pretty good combat system. It's pretty flawed with dumb AI and a few other things, but it's a good example of gridless TB combat.
And yeah, I'm talking about the PC version.
 

DraQ

Arcane
Joined
Oct 24, 2007
Messages
32,828
Location
Chrząszczyżewoszyce, powiat Łękołody
As others have pointed out, grids have no special benefit, but non-grid solutions like DOS often add nothing significant while making things less intuitive and usable. You don't want to end up with situations where players think they're close enough to attack but they're not, or they can't tell how close they can get to X without touching it, etc. Also easier to balance encounter design, APs, etc. when you're working with a grid system.
The main benefit of any non-discrete solution over a discrete one is fine control.
Of course reducing player's control makes balancing easier but is it worth the cost?

As for intuitiveness, making UI to make up for those "problems" isn't exactly rocket science - draw reach "shadow" at destination and highlight all potential targets withing reach, draw enemy reach ranges when player is moving (DOS does this already), mark any parts of the chosen route crossing over hazards, always choose route avoiding hazards when pathfinding, unless explicitly told to move through them (DOS doesn't do this, but it could have and should have), etc.

Some problems also go away when de-abstracting further, for example switching from binary blocked/passable or can reach/can't reach fuzzier and/or less deterministic approach (squeeze through at the cost of extra time and penalties, can barely scratch the target) will make the exact measurement less relevant and put more stress on robust solutions that don't hinge on near misses and borderline hits.
 

Tigranes

Arcane
Joined
Jan 8, 2009
Messages
10,350
As others have pointed out, grids have no special benefit, but non-grid solutions like DOS often add nothing significant while making things less intuitive and usable. You don't want to end up with situations where players think they're close enough to attack but they're not, or they can't tell how close they can get to X without touching it, etc. Also easier to balance encounter design, APs, etc. when you're working with a grid system.
The main benefit of any non-discrete solution over a discrete one is fine control.
Of course reducing player's control makes balancing easier but is it worth the cost?

As for intuitiveness, making UI to make up for those "problems" isn't exactly rocket science - draw reach "shadow" at destination and highlight all potential targets withing reach, draw enemy reach ranges when player is moving (DOS does this already), mark any parts of the chosen route crossing over hazards, always choose route avoiding hazards when pathfinding, unless explicitly told to move through them (DOS doesn't do this, but it could have and should have), etc.

Some problems also go away when de-abstracting further, for example switching from binary blocked/passable or can reach/can't reach fuzzier and/or less deterministic approach (squeeze through at the cost of extra time and penalties, can barely scratch the target) will make the exact measurement less relevant and put more stress on robust solutions that don't hinge on near misses and borderline hits.

Exactly. A fine control whose benefits are neither required nor leveraged in most TBS mechanics. E.g. one obvious benefit is that you can specify exactly where your AOE hits, and not an arbitrary grid designation, but the result is that you end up getting your ruler out to see if you can't make your fireball hit exactly on the fringes of these two dudes. (Which is exactly what you do with grids, except it takes less time, and nobody really thinks "it's fucking bullshit that grids cause me to not target this dude here"). Even if we take something like lightning bolt, again, the only real difference is that you're now trying to squirm out by tinier margins to escape that line AOE (or to hit them with it), and the satisfaction is really the same as hitting/dodging that line in a grid.

I'm open to examples of features or situations where an existing grid solution is inadequate/frustrating/unrealistic/etc, and a non-grid system provides a way to significantly change the situation.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
The question regarding grids is not whether to implement one or not. It is a question of how large to make the grid squares. After all, you aren't going to allow a character to move a fraction of a pixel.

For the reasons listed by others above, making grid squares too small has the drawback of turning every movement and area attack into a pixel hunt. It is tedious and it is not related to the core mechanic of the game that provides the player fun. (If they thought pixel hunts were fun they would be playing a hidden object game.)

If you want to provide the most robust experience possible, consider making your grid cells a quarter of the size of a standard character. Instead of taking up a 1x1 square, a normal character occupies 2x2. I'm not aware of any mainstream games that take this approach. I have prototyped it, and it has a number of advantages:

-Creatures smaller than humanoids can be represented without special rules.

-Since creatures that occupy more than one space are a core part of the system, adding large (4x4 ogre) or non-standard (6x10 dragon) creatures is easy and creates fewer bugs.

-Twice as many melee weapon ranges are available. A dagger can require being right next to someone (range 1) and a long sword can be better than that (range 2) without intruding on the capabilities of a pike (range 4).

-The "square-fireball problem" is alleviated.

-Levels with diagonal terrain and buildings are easier to construct.

This is a good item from the Unity asset store for working with grids:
http://gamelogic.co.za/grids/
http://artificerentertainment.blogspot.ca/2014/09/guildcraft-dev-diary-part-xii.html

PS: This is not an endorsement of Unity.
 

DraQ

Arcane
Joined
Oct 24, 2007
Messages
32,828
Location
Chrząszczyżewoszyce, powiat Łękołody
The question regarding grids is not whether to implement one or not. It is a question of how large to make the grid squares. After all, you aren't going to allow a character to move a fraction of a pixel.

For the reasons listed by others above, making grid squares too small has the drawback of turning every movement and area attack into a pixel hunt. It is tedious and it is not related to the core mechanic of the game that provides the player fun. (If they thought pixel hunts were fun they would be playing a hidden object game.)

If you want to provide the most robust experience possible, consider making your grid cells a quarter of the size of a standard character. Instead of taking up a 1x1 square, a normal character occupies 2x2. I'm not aware of any mainstream games that take this approach. I have prototyped it, and it has a number of advantages:

-Creatures smaller than humanoids can be represented without special rules.

-Since creatures that occupy more than one space are a core part of the system, adding large (4x4 ogre) or non-standard (6x10 dragon) creatures is easy and creates fewer bugs.

-Twice as many melee weapon ranges are available. A dagger can require being right next to someone (range 1) and a long sword can be better than that (range 2) without intruding on the capabilities of a pike (range 4).

-The "square-fireball problem" is alleviated.

-Levels with diagonal terrain and buildings are easier to construct.
Taken to logical conclusion it becomes a gridless system.
+M

Exactly. A fine control whose benefits are neither required nor leveraged in most TBS mechanics.
TBS maybe, but TB RPGs with few and non-expendable units under player's control really need all the control they can get.

E.g. one obvious benefit is that you can specify exactly where your AOE hits, and not an arbitrary grid designation, but the result is that you end up getting your ruler out to see if you can't make your fireball hit exactly on the fringes of these two dudes. (Which is exactly what you do with grids, except it takes less time, and nobody really thinks "it's fucking bullshit that grids cause me to not target this dude here").
And which is bullshit because it rewards fragile "everything must go exactly as planned" plans.

Fuzzying the fringes up and applying some randomness there would reward more robust planning, in the same vein virtual dicerolls already do.

Too much randomness is bad, but a little randomness makes it possible to distinguish between solid plans and ones that fall into pieces at the slightest nudge.
 

DraQ

Arcane
Joined
Oct 24, 2007
Messages
32,828
Location
Chrząszczyżewoszyce, powiat Łękołody
Grids are better.
Counting to
1128.jpg
is clearly the best.
:M
 
Joined
Jan 7, 2012
Messages
14,099
The question regarding grids is not whether to implement one or not. It is a question of how large to make the grid squares. After all, you aren't going to allow a character to move a fraction of a pixel.

For the reasons listed by others above, making grid squares too small has the drawback of turning every movement and area attack into a pixel hunt. It is tedious and it is not related to the core mechanic of the game that provides the player fun. (If they thought pixel hunts were fun they would be playing a hidden object game.)

If you want to provide the most robust experience possible, consider making your grid cells a quarter of the size of a standard character. Instead of taking up a 1x1 square, a normal character occupies 2x2. I'm not aware of any mainstream games that take this approach. I have prototyped it, and it has a number of advantages:

-Creatures smaller than humanoids can be represented without special rules.

-Since creatures that occupy more than one space are a core part of the system, adding large (4x4 ogre) or non-standard (6x10 dragon) creatures is easy and creates fewer bugs.

-Twice as many melee weapon ranges are available. A dagger can require being right next to someone (range 1) and a long sword can be better than that (range 2) without intruding on the capabilities of a pike (range 4).

-The "square-fireball problem" is alleviated.

-Levels with diagonal terrain and buildings are easier to construct.

This is a good item from the Unity asset store for working with grids:
http://gamelogic.co.za/grids/
http://artificerentertainment.blogspot.ca/2014/09/guildcraft-dev-diary-part-xii.html

PS: This is not an endorsement of Unity.

This is what I was about to post. Though I would go with a more fine grid, 3x3 or 7-hex human at least.

If you have a drawn grid then the main drawback of smaller and smaller grid sizes (being harder to judge distances, like its gridless) can be alleviated through bolding the integer ranges or even not showing partial-squares unless moused over.
 

odrzut

Arcane
Joined
Apr 30, 2011
Messages
1,082
Location
Poland
I haven't played divinity, but I've played some 4x space conquest games with gridless turn-based battles. It was OK, but the pixel-hunting to get your ship where you want it was frustrating on many occasions. Especially when there were like 3x1 pixels where you actually could have moved your ship to turn back and shoot. It's not enough to change cursor when the move is invalid - you have to highlight the possible moves and invent some way to avoid pixel hunting for that 3x1 square (maybe TAB should move between centers of consecutive areas of valid moves?).

Another frustrating thing in that game (maybe irrelevant for your game) was that ships had pixel-perfect collision detection, and were very irregular (concave shapes with many elongated corners) - it was impossible to tell sometimes whether you will be able to rotate your ship after flying near the enemy. It's frustrating to fly behind the enemy and be unable to shoot because you can't turn to face him.

Also - I think gridless systems make it much harder to make proper AI. AI for turn based games on a grid is a solved problem - just do minmax with alpha-beta pruning. For games where every piece can move to 100 slightly different places on each turn - it's unfeasible to use that I think (3 turns ahead, 3v3 units battle = 100^36 possible moves, not counting attacks and skills).

I would go with grids, just because it's more intuitive for players, and easier to implement.
 
Last edited:

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