Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account
This post has been closed. You can still view previous posts, but you can't post any new replies.

Grid properties allowing for automated movement calculations and other features

October 14 (12 years ago)
What I think would be extremely helpful to the GM as well as players would be a grid highlighting feature. Imagine that when you click on your token it causes the grid squares that are within its movement range to highlight as one color and if the distance would be considered running speed it could be highlighted as another color. A perfect example of this would be the original final fantasy tactics(except they didn't have variable movement)
October 14 (12 years ago)
Which takes us back to other discussions about the way to calculate distances and the difficulty to enter the movement costs values for different types of terrains. Both of which would be needed if you want Roll20 to ba able to display move distances.
FFT is not a good exemple, being a programmed game with fixed maps, programmers were able to insert any terrain effects needed when making the game. A VTT has to be much more flexible.
October 14 (12 years ago)
I would just make a field to where you set the distance of the squares or hexes manually, and could be set to a default of 5, and the highlighting would display every possible square that the token could move to. If you give that control of the terrain distance to the GM , this solves the problem of tracking movement because they set it to whatever distance they want. Then all that has to be taken into consideration is the math of figuring out the shortest path that would get the token from point a to b. I'd also recommend highlighting the original square red so that the players know where they moved from
October 14 (12 years ago)
I don't understand. If you just highlight the squares that are within the token maximum distance, you are going to highlight a lot of squares it won't be able to reach due to the presence of obstacles or the costs of moving. So, you are going to recalculate anyway. I don't really see the use.
October 14 (12 years ago)
Lets say you have an obstacle that halves movement , then inside that square you would set the movement to take up twice the actual distance or however you want to handle it. Movement through objects could be handled by setting up a barrier system that doesn't allow movement to pass through
October 14 (12 years ago)
The system that I'm suggesting would basically allow you to set properties for each individual square or hex on the grid, if this were possible there would be a lot of possible benefits , like status effect environments, traps , etc.
October 14 (12 years ago)
Yes, but that would mean setting up values for each and every square of your map before playing. One value for each square terrain, four values for each squares side (if there is an obstacle costing movement points between them). and possibly one value one way and another value the other way, if your rules have different costs for ascending and descending a terrain height.
For a (small) 20x20 map squares, it is a minimum of 400 + 1600 possible values to enter. For the same map with hexes 400 + 2400.
Frankly, I find it a little overkill in preparation for something that can be easily calculated during play. Every gamer does it quickly and routinely during tabletop games.
October 14 (12 years ago)
Not all squares are going to have difficult terrain, there would be a way to set all the squares to a standard. I don't often run into situations where that much detail is required for movement, If its rough terrain one way it's the same every other way. Detail is good , but settings for each side would be pointless. I never suggested having to go through and do every single square one at a time, that would take forever.
October 14 (12 years ago)
If there is a special feature you want one square to have, yes you'd easily be able to do that, but I'd also want to be able to select many squares and alter their properties at the same time
October 14 (12 years ago)
Axel Castilla
KS Backer
On the other hand, instead showing the distances and paths available for displacing a particular token, it should be possible to just dynamically highlight (and to stream to others) the grid cells used for displacing a token, without adding any automatic calculation on movement costs according to this or that specific game system. This would be simple to add --I think-- and also useful.

Now, I'd like this optionally having into account rotation / facing changes as well, in some way that I can't figure right now, because facing changes very well can be part of movement according to some rule systems.

I think that a distinction between available distances for "walking" and "running" modes is, BTW, rules specific and non system agnostic, especially if these available distances can't be customized --which involves complexity: there are systems in which that distinction would be rather pointless and arbitrary, like for instance those just stating that if you use the 50% of your available movement, you're walking, and if you spend the 100% of your available movement in a turn, you're running. Or think about rule systems increasing your available walking or running distance if you burn fatigue points or the equivalent.
October 14 (12 years ago)
Differentiating between walking and running would just be a matter of creating a series of movement properties for each token. It could remain perfectly rules agnostic if its done properly. It would just be a matter of converting the games movement to a generic movement, since the values of such would be completely customizable. Same goes for facing, it would just be a matter of calculating the turn and subtracting it from the maximum distance that the token should be able to move after subtracting any obstacles etc.
October 15 (12 years ago)
It seems very complicated to me, to have it work automatically (complicated to include all the possibilities, but also complicated to setup the map if all those possibilities were included), for a really small payoff (it would just replace counting the squares on the map, and you would still have to count the substractions for facing or other obstacles).
October 15 (12 years ago)
Not if you included those details in the different properties, it would be rather simple really, if every square has regular movement you set them to the distance of say 5 feet, if its rough terrain and you move half speed through it set it as 10 feet etc. which games count facing , I've never come across this, but if it was necessary that could be fixed by adding an algorithm that figures the original facing to the new facing and adding it before the movement.
October 16 (12 years ago)
Not if you included those details in the different properties, it would be rather simple really, if every square has regular movement you set them to the distance of say 5 feet, if its rough terrain and you move half speed through it set it as 10 feet etc. which games count facing , I've never come across this, but if it was necessary that could be fixed by adding an algorithm that figures the original facing to the new facing and adding it before the movement.

YMMV, but that's what I call complicated and it doesn't even count obstacles between squares (like a fence, for exemple). Or different costs for going up or down a slope.
It would be a lot of work to setup a map this way.
October 16 (12 years ago)
Something you can do if you like is set a Aura around each person showing their movement. It does not change for terrain but will let you know how far you can move under normal movements.

This may at lest help until something better is made.
October 16 (12 years ago)
You would just increase the superficial distance of the square in the properties tab for obstacles like that, in most cases jumping over a fence would take the same effort as moving 5 feet. As far as the uphill downhill thing is concerned, you might think that it is easier to go down hill than it is to go up hill, and it is on certain parts of the body, but a lot more taxing on other parts. I go hiking and backpacking all the time and usually going downhill is harder, especially with a 60lb pack on your shoulders. It's only as complicated as you want it to be. The ability to the properties of each square would be an awesome feature, imagine how you could set the square to give off a magical aura, or some other effect, or hiding a trap that way. Your only limited by your imagination
October 16 (12 years ago)
As for going up and down hills, I know that I am slowed and that I can not run up a slope, whilst I can certainly run fast down a slope (and from painful experience, I can say that the problem is not running, but stopping). That means different movements costs going up slope, down slope or across slope (in the same square).

Yes, I know that you can factor easily a penalty for crossing a fence. That's not the point. The point is that, if you want to automate the movements costs, you have to allow for setting costs of movements between squares. I am not sure I understand what you mean by "You would just increase the superficial distance of the square in the properties tab for obstacles".

As for squares properties, this is something completely different from automated move costs computing. I think that the effects you suggest could be prepared on the GM layer and changed to the normal layer when in use (displaying the trap or showing the aura).
October 16 (12 years ago)
The superficial distance of the square meaning that if you are having 5 feet for your regular squares and you come across a difficult terrain you could change the distance propery of that square to be whatever distance you want, multiples of the the regular square would be easiest. So the actual distance the square represents is still 5 feet , but the cost to move through it would be 10. I didn't really intend for this method to apply to vertical movement, but that is easily solved by adding another algorithm and another two properties in the grid, it would be the degree of the slope and its direction.

The square properties is the whole way of making this work, the values used for the automated move cost computing would be derived from the properties that the user defines for each square. Not sure what you mean by moving between squares, either your in a square or your not, I mean sure you can turn off snap to Grid but the distances would still be the same.
October 16 (12 years ago)
Sorry if I am not clear. I just mean going from square A to square B: if, for exemple square B is difficult terrain, going from A to B costs 10 feet of movement. You can assign a value of 10 to square B. But if there is a fence between square C and square B, it costs a further 5 feet to cross from C to B. But you can not assign a value of 15 to square B, because the 5 feet penalty only applies to those coming from one of its side.
So you must be able to assign a value on square B for the terrain type, but you must also be able to assign a value on the sides of square B for the obstacle between B and C. There is a cost in the square and there is a further cost between squares.

All of that means that you would have to potentially be able to assign a lot of properties to each square and to each square side to have a working system. And doing it would be quite time consuming.

I wouldn't mind the complexity and the workload if I could see a real benefit. But moving a token from square to square and computing mentally the move costs is not a taxing activity. It doesn't even slow down moving the tokens. So going all the way to automate a function that I am not sure needs automatization looks a little like overkill to me.
October 16 (12 years ago)
I do see your point now. it would still be nice to have certain properties associated with each square though. Highlighting the square of origin would still be useful as well. I do still the the grid highlighting would be useful for other things, like melee and ranged attacks and magic templates, thought these would be handled a little differently and would not be static to the grid itself.
October 16 (12 years ago)
Yes, on the general idea of associating properties to squares or zones, there could be some uses.
Ranges are not as much affected by the nature of the terrain, for exemple. Other templates would probably work also.
It is automated movement costs computing that I think wouldn't work, because there are, I think, too many variables that have to be taken into account (and programmed by the GM beforehand).