Move blocking for grid maps - a solution?

[evilC]

I am new to MT, so forgive me if I make some wild assumptions etc, but it seems to me that there is a not so bad solution to this problem.

The aim is:
For a square grid based game, allow the player full control of moving their token in a VBL / FOW environment, whilst eliminating the possibility that they could reveal any view that they could not have seen, and only allowing "legal" moves (ie not into or through a wall). Ideally this should include not exceeding their move allowance for that turn.

My proposed solution:
(Only really thought through so far for dungeon type environments)
Use the technique Wolph42 used in his drop-in Difficult Terrain code to instead draw a line of move-blocking tokens ("impossible terrain"). This square of "terrain" is so difficult to enter, it costs infinity movement points to move onto - viola, a move blocking layer.

This idea could be extended in all sorts of ways.
I propose maybe the system of using tokens to represent the data could each square could be refined.
How about using the state system to our advantage?
For example, you position two tokens, one at the top left of your dungeon, one at the bottom right, and click an "edit mode" button. It then creates a token for each square inside the box - one token per square of the dungeon.
Each square has the "Wall" state set by default. You drag a box to select all tokens inside a room and right click>change state to "Walkable".
This way, you could easily give each square one or more states, and the state icons stack, so with clever layout we can represent lots of states for each square through just one token.
For example, you could have split levels easily represented. Squares could be designated a height, and stairs could be represented too, so the possibilities are pretty endless.

Thoughts, ideas?

[wolph42]

you can block all movement through a wall with the use of the ward token. Or you can use area tokens as you already did. I *could* use tokens with states, but thats a LOT slower then the area method. Actually of all the methods the area method is by a long shot the fastest. Note that you can 'draw' area tokens with the right tool. Just select a token turn on the draw mode and start dragging the token to draw walls. Then when finished you can give the drawn area a name and assign certain macro to it like 'do not pass' or 'difficult terrain' etc.

[evilC]

Slower in what way, and at what point?

My guess is you are concerned about "run time" (ie when someone is playing a game) speed.

Looking at your code, each time you move a token, for each area, it checks for a match between the set of points in that area and the set of points moved through, twice (once for move difficulty, one for traps etc).

I think I maybe see what you are talking about re: speed - in order to know the number of "difficult" squares that you move through - it is quicker (on average) to run an intersect on all the areas than it is to iterate through each moved square and look at it's properties?

If so - surely that is just a cache. Change the UI such that each square has a token as I said, but when you exit edit mode, a coordinate list is built of all squares that are difficult. This would be faster than the current system (one big loop rather than lots of small ones - less overhead) plus the edit interface suddenly becomes much simpler and doesn't start falling over if you have lots of areas.

In fact you could speed it up more. by splitting the cache sets up into say chunks of 50x50, when you perform an intersect check, you could only check the affected chunks, vastly reducing the compare set.

[wolph42]

Slower in what way, and at what point?

My guess is you are concerned about "run time" (ie when someone is playing a game) speed.

Looking at your code, each time you move a token, for each area, it checks for a match between the set of points in that area and the set of points moved through, twice (once for move difficulty, one for traps etc).

I think I maybe see what you are talking about re: speed - in order to know the number of "difficult" squares that you move through - it is quicker (on average) to run an intersect on all the areas than it is to iterate through each moved square and look at it's properties?

Correct!

If so - surely that is just a cache. Change the UI such that each square has a token as I said, but when you exit edit mode, a coordinate list is built of all squares that are difficult. This would be faster than the current system (one big loop rather than lots of small ones - less overhead) plus the edit interface suddenly becomes much simpler and doesn't start falling over if you have lots of areas.

This IS how the current system works! A coordinate list IS build for all areaTokens (that is tokens with the 'special area' state). Then you give it a name e.g. 'difficult' and then you assign a macro to execute e.g. move*2. Note that areas do not require to be continuous so 40 patches of 'difficult terrain' is only 1 area in the system (unless you're doing it wrong). With that in mind how many areas can you conceive? And also if you would go for a diferent method, say the 'states' trick then you'd still have to cycle through at least that many different areas so it makes no difference.

In fact you could speed it up more. by splitting the cache sets up into say chunks of 50x50, when you perform an intersect check, you could only check the affected chunks, vastly reducing the compare set.

I've run some tests but the intersect is done at a java level which is significantly faster then a checkup loop which has to be done in MT and then in java. Also it would require either a lot of getLibProperty operations (which are slow) or a lot of json.get operation (which are slow). This requires 1 libget and 1 jsonget.

[evilC]

OK, I am starting to understand things I think, but at the moment it is the quirkiness of the MT language that is holding me back.

So it looks like ultimately my technique will be exactly the same speed at run-time, but it should significantly ease edit-time. Sounds like I am on to a winner.

To recap:
What I plan on doing results in the same data structure as you use, but with all data (eg difficult terrain) in one "area" instead of multiple areas.
As long as a cache is built for run-time, this is the same speed as your current system because it works in the same way, except it has one big "area" instead of lots of smaller ones.

To build the data structure, instead of drawing an area and defining that as "difficult", you define a "window" and a token is created for each square in that window. Change the state for each token to reflect it's difficulty, then hit submit, and for all non-normal squares (eg difficult terrain, walls), it makes an entry in the data structure for that square. All the tokens in the window are then removed.

[wolph42]

OK, I am starting to understand things I think, but at the moment it is the quirkiness of the MT language that is holding me back.

So it looks like ultimately my technique will be exactly the same speed at run-time, but it should significantly ease edit-time. Sounds like I am on to a winner.

I wouldn't be so sure about it, but its possible

To recap:
What I plan on doing results in the same data structure as you use, but with all data (eg difficult terrain) in one "area" instead of multiple areas.
As long as a cache is built for run-time, this is the same speed as your current system because it works in the same way, except it has one big "area" instead of lots of smaller ones.

apparently I failed to be clear: my methods DOES work with ONE BIG AREA per terrain TYPE for the WHOLE MAP.

To build the data structure, instead of drawing an area and defining that as "difficult", you define a "window" and a token is created for each square in that window. Change the state for each token to reflect it's difficulty, then hit submit, and for all non-normal squares (eg difficult terrain, walls), it makes an entry in the data structure for that square. All the tokens in the window are then removed.

AFAIK see the only thing your method has in advantage is that it can fill an area with tokens, this can relatively easily be done with copy paste, but creating a function for it is also peanuts. That is IF its useful.

Now what amazes me is that you're saying that 'select all the tokens for a certain area and set their state to a certain terrain difficulty' is *easier* then simply drawing those same tokens directly. I can see that in certain circumstances your method will be faster (e.g. large contiguous area with a single type) but for complex maps with different types my method will be easier.

And those are not the only issues. The biggest issue is that my method is system agnostic and yours isn't. Your methods requires pre-set token states that can be used for certain area types, but that is not in line with the philosophy of the BoT

edit: suddenly I remembered that the BoT *does* have the function to fill one area in one go. the method is slightly different as you describe: it requires to fill in the grid coordinates and it fils the area. The grid coords can simply be found by dragging a token to the spot where you want to start and looking at the bottom right of your window. The function is called 'fill area' (vs draw area which was the function I was talking about).

[evilC]

Ah, Ok, I think I misunderstood how to operate your app.

What I thought was that for each block of difficult terrain, you added one "area".
I now see that no, this is not the intended usage.


However, I still think my edit method is better.

Yours:
Somehow define an area, and tokens appear for that area.
You do not appear to be able to duplicate these tokens to expand the area, you must "paint" more.
etc...

Mine:
Define the top left and bottom right of the "edit window" with two markers, hit "Go".
A token appears for each square inside the "edit window" area.
Drag-select around the squares you wish to alter, and do state->difficult area
Click "Done". The tokens disappear and the squares are updated.

[wolph42]

Lets fill in the gaps.:

Yours:
1.Define the top left and bottom right of the "edit window" with two markers, hit "Go".
2. token appears for each square inside the "edit window" area.
3. Drag-select around the squares you wish to alter, and do state->difficult area
4. Click "Done". The tokens disappear and the squares are updated.

Mine (Note this is ONE method I have several alternatives):
1. Run 'fill macro' and Define Upper left and width and height of the area: hit "go"
2. A token appears for each square inside the "edit window" area.
3. delete (or copy paste/move) the tokens you do not want (in the area).
4. Click "Define Area" and set everything up to your liking.

Now exactly what is it that makes your method 'better' ?

PS: I've updated the fill area function in the BoT with your suggestion to preset the area depending on two tokens that are selected. That is a good suggestion. So now when you select two tokens and then run fill area, all the 'correct' coordinates are pre-set.

edit:
LOL I just checked something else and it turns out I completely forgotten that the 'define' function looks like this:

Spoiler

Untitled picture.png (34.24 KiB) Viewed 2254 times

.
Note the: "name of state token" in "method 1". In short this means that this function can also work EXACTLY as you describe...

[evilC]

First off, let me say that maybe I came across a bit wrong. I really appreciate what you do, I am just something of a perfectionist and have a bit of an OCD thing going on when it comes to the man-machine interface. To the point where I cannot play a game or use a system when I have to think more about the interface than the game or data I am working on.

I have been using the standalone difficult terrain dropin not BoT as BoT does seem to work for me - the difficult terrain demo in it does nothing for me for example.

I tried the "Draw area" feature, it does not work for me either

I appreciate that I got it wrong and your token creation method is basically the same as mine, but there is still one subtle difference that I think may affect usability quite dramatically.

If I, as an experienced IT person and sometime coder can make that mistake, others can too. Even knowing how to use it, there could be unintended bugs - if someone does not realise a certain square is assigned a certain property, it may rear it's head mid-game etc. In order to avoid this, you need to turn each area on, look around the map to see where it is used, then turn it off. Rinse and repeat for each area (ie square attribute).

With what I am proposing, you start with the 1st area of the dungeon, define a window around that, and ALL state information is showed for each square on ONE token. Because state icons can stack, one token could have symbols for "difficult terrain", "trap trigger 1" and "elevation -10'". Each token has code in onTokenMove such that even the GM cannot move it. It is also sized 50%, so you can easily drag select a box from within a block.

Even at creation time it is better. If I am trying to enable a map for use with this system - what I am proposing seems superior also.
Now in BoT in the terrain demo, you can show all of the areas at one time, but with the following limitations:
1) You can only show the whole area, not a "window" of it. Yes you could define multiple copies of "difficult terrain", but I have already mentioned why this is a bad idea.
2) Squares seem to be able to hold more that one bit of information, but if trying to view all data for a square at one time, you will be dealing with two tokens in one square.
3) It is not trivial to change a square from one terrain type to another. You must delete it from one area, then define a new square in the new area.

With what I am proposing, all these problems are trivial, and work flow becomes much much faster.
Define a window around the first couple of rooms.
Drag a box around all tokens in the first wall, right click->wall. Repeat for walls.
Drag a box around difficult area, right click->difficult.
Select token in the middle, right click->trap trigger 1
Decide to change some of the squares to very difficult, ctrl-click a bunch of squares, right click->v difficult
So now you have just defined a big section of the map without the mouse cursor having to leave the map pane, without having to showing or hide areas each time you started editing a different attribute, etc.

You click close window, Area makers disappear, Window marker appears - move that to new area, show markers for that section, move on.

If you are doing debugging on a part of the map, draw a window around it, show the area markers and you instantly can see what attributes are assigned to every square of the map.

See what I am saying? More user-friendly, less ambiguity, all the power of your already excellent system.

I have been working on a prototype lately, but it has been pretty hard going. The strange syntax, it being difficult to work out why lib functions fail (Often macro editable by players lol) and not having gotten a decent IDE going yet are all hampering efforts.
Now I know a bit more, I may start looking at the BoT source - you have so much of the other goodness in there that I would like, that I think I need to man up and understand all your code.

[wolph42]

First off, let me say that maybe I came across a bit wrong. I really appreciate what you do, I am just something of a perfectionist and have a bit of an OCD thing going on when it comes to the man-machine interface. To the point where I cannot play a game or use a system when I have to think more about the interface than the game or data I am working on.

no not really... i *was* a perfectionist once as well but I learned to deal with it and now Im result driven which is way more effective. Still I finetune e.g. the BoT constantly hence the reason I go into this discussion.

I have been using the standalone difficult terrain dropin not BoT as BoT does seem to work for me - the difficult terrain demo in it does nothing for me for example.

that because it does not run 'out of the box' and thats because I've turned that setting off as its not system agnostic. If you want to see how it works:
bot-settings -->toggles tab --> enter a number in the 'movement limiter' --> ok. Now drag a token over the difficult terrain and check the chat window.

I tried the "Draw area" feature, it does not work for me either

what did you do?
I checked and: dragged a token onto map, selected it, 'draw area' macro, pop-up->clicked ok, dragged the token over the map and it was copy pasted.
To create an marked area you'll need to select the area marker token from the dropdown list and drag that one around.

With what I am proposing, you start with the 1st area of the dungeon, define a window around that,

how? And with that I mean literally what does the user do?

and ALL state information is showed for each square on ONE token. Because state icons can stack, one token could have symbols for "difficult terrain", "trap trigger 1" and "elevation -10'".

I've been thinking about this one and the first question that popped up was: which states? are they defined, does the user do that himself, how does the BoT know which they are etc. can you give me a process description keeping in mind that IT HAS TO BE SYSTEM AGNOSTIC !!
Also, what do you mean with

Each token has code in onTokenMove such that even the GM cannot move it.

It is also sized 50%, so you can easily drag select a box from within a block.

I don't get this two remarks, what do you mean with both of them.?

Define a window around the first couple of rooms.

again: how? What does the user do?

Drag a box around all tokens in the first wall, right click->wall. Repeat for walls.
Drag a box around difficult area, right click->difficult.

I don't get the 'box' part how do you 'drag a box around all tokens'. If you mean 'select them' then you're into java code and not MT code. The MT script is limited. Somehow you need to define the 'box' either by input or markers.

Select token in the middle, right click->trap trigger 1

again not following you... AH WAIT: you mean: select all the token (by dragging a box around them), right click set state to 'difficult', select token in the middle, right click set state to 'trap trigger' that is what you mean?

So now you have just defined a big section of the map without the mouse cursor having to leave the map pane, without having to showing or hide areas each time you started editing a different attribute, etc.
...
See what I am saying? More user-friendly, less ambiguity, all the power of your already excellent system.

yes indeed and as I've said: I've been thinking about this one... I do have lots of questions though. And before I commit to something I need to have a very clear picture in my head of the 'end game' as I always design from a user interface perspective and then translate back to required code. This process usually demands a toll on the UI as MT script is limited but the result is as close as I envisioned it.

I have been working on a prototype lately, but it has been pretty hard going. The strange syntax, it being difficult to work out why lib functions fail (Often macro editable by players lol) and not having gotten a decent IDE going yet are all hampering efforts.
Now I know a bit more, I may start looking at the BoT source - you have so much of the other goodness in there that I would like, that I think I need to man up and understand all your code.

I work on another project (W40K campaign) with another person and we develop through dropbox and oneNote. First of all, this discussion goes a LOT smoother in oneNote and if you're going straight into the source code then it may be prudent to also work with latest product.
So: do you have access to dropbox and oneNote if so, do you want to collaborate on this and if so: pm me your email addres and at least one windows email address (for oneNote) eg. @live or @hotmail.

Then we can go into this further.

Keep in mind though that I did A LOT of thorough testing and there is a reason why made the choices that I made. That however does not mean that I constantly like to improve this.

[evilC]

Sounds like you are finally seeing my idea.

Yes, to be totally clear:

You have two "Viewport" tokens - Top Left (TL) and Bottom Right (BR).
Place the TL one at top left of an area you want to edit, then BR at bottom right, click "Show Area".

Tokens appear, one for each square inside the box (AKA the "Edit Viewport")
To edit the properties of a square, you edit the token for that square. So drag a select box around all tokens for squares you wish to alter and either right-click > state or you could click a macro button instead.

Either way, the point is you have one token per square within the window and each token can be set to any or all of the area types you wish. You could create the tokens in other ways such as how you have already done, it is just that one token always represents all the data for one square.

When you click submit, all the tokens are processed and then removed, and the database entry for each square is updated according to the properties of token. If nothing was set for a token, no db entry is made, so "normal" space does not need a DB entry, same as current system.

This obviously means that you have one JSON structure with one entry for each square, and various bits of data dangling off that. If you need one dataset of all the coordinates for difficult terrain only, you can build this as a cache (ie a separate JSON variable) at compile-time (after done editing).

I have dropbox, but I am not sure about the ms email address. I should have a hotmail address, but I think I made my regular email address a MS one. Try adding [email protected] to both.

[wolph42]

so far a non ms address has never worked... but i don't mind to give it another shot. possibly send you the mail later. btw you can better pm you email the post it on the forum as 'golddiggers' scrounge fora searching for email addresses which will eventually increase your spam count.

[wolph42]

Sounds like you are finally seeing my idea.

Yes, to be totally clear:

You have two "Viewport" tokens - Top Left (TL) and Bottom Right (BR).
Place the TL one at top left of an area you want to edit, then BR at bottom right, click "Show Area".

Tokens appear, one for each square inside the box (AKA the "Edit Viewport")
To edit the properties of a square, you edit the token for that square. So drag a select box around all tokens for squares you wish to alter and either right-click > state or you could click a macro button instead.

Either way, the point is you have one token per square within the window and each token can be set to any or all of the area types you wish. You could create the tokens in other ways such as how you have already done, it is just that one token always represents all the data for one square.

When you click submit, all the tokens are processed and then removed, and the database entry for each square is updated according to the properties of token. If nothing was set for a token, no db entry is made, so "normal" space does not need a DB entry, same as current system.

This obviously means that you have one JSON structure with one entry for each square, and various bits of data dangling off that. If you need one dataset of all the coordinates for difficult terrain only, you can build this as a cache (ie a separate JSON variable) at compile-time (after done editing).

I have dropbox, but I am not sure about the ms email address. I should have a hotmail address, but I think I made my regular email address a MS one. Try adding [email protected] to both.

Ok I've translated the above to a more MT feasible outline. I've put it in oneNote which makes discussing this a lot easier and it shows the color markers I use. But since you have not yet access I'll also post it here (using code tags so the layout keeps intact). Maybe others have something to add.
Keep in mind that I've started with the above quoted text and after roughly 10 rewrites this came out of it, which is quite different in certain area due to either MT limitation or simplifying the code structure (so keep an open mind when reading it). Basically your viewport model is out of the viewport . Partially cause some things can't be done in MT (well they could be with the necessary work-arounds but then you get a VERY SLOW and bug prone code) and partially cause its simply a lot easier to do it as described below AND you have an instant overview of ALL area's at once instead of a 'viewport'.

Code: Select all

CREATING AREAS
	1. Click 'Show Areas'
	2. A "Show Areas" (SA) HTML form appears with 
		a. Dropdown box with four layers ("Choose edit layer:")
		b. Button: Edit areas
	3. User chooses layer and clicks 'Edit areas'
	4. ALL the areas are shown on the map in the form of Area Marker (AM) tokens with their corresponding state. Tricky part is to have multiple states on one AM… need to think this through 
	5. SA is closed and a New HTML form appears: "Edit Areas" EA
		a. onChangeSelection method and 
		b. Button: "fill area" 
		c. button: "process /submit".
		d. List of all currently used states (name and image?) followed by a textbox containing its current name. Keep in mind that if the name is changed the linkedAreas json (and the other one?) needs to be rebuild as well!!
		e. When a state is added it appears in the EA form together with a textbox where you can fill in the name of the area. Need to check how to handle this. Two methods:
			a. First time: When tokens are selected (onChangeSelection): store the current selected tokens 
			b. In repeat: When tokens are selected: go through the tokens that WERE selected and get their states. If a new state is found add it to the EA form.
		OR
			a. Onchange selection get all the AM  tokens and foreach through them checking their states. 
			b. If a new state is discovered add it to the EA form
		Maybe not only show a text box but also show a dropdown list of current stored area with OR in between.
		What do we do when a certain state is no longer used? Needs to be removed from the EA form.
	6. When user clicks FILL AREA:
		a. Two FA tokens - Top Left (TL) and Bottom Right (BR) with a picture of two arrows pointing to the corner appear. 
		b. Text appears on EA form: "To create new areas place the viewport markers...yadayada. Note that if you use a certain state that ALL token with THAT state on the EDIT LAYER will be used to create the area. Thus also outside the filled area (should you use that). After you have placed the FA tokens click 'fill area' again.". So the macro works slightly different:
			(i) First check if there are FA tokens on the EDIT layer of the map. If not place them ELSE fill area between FA tokens and update text on EA form.
			(ii) Store the result of copyToken--> change into coords array and json.intersect that with all the areas. The result should be coords where double tokens area--> Remove these. 
		What do the "fill area tokens" look like?  Could use the curren area markers without the state.
	7. EDITING AREAS. This is simply done by changing the states of the AM tokens using right mouse click and select. We could also add  an extra button to the states on the EA form: "Apply" wich adds that state to the currently selected tokens. 
	8. When user clicks PROCESS/SUBMIT:  Since ALL areas on the map are shown you can rebuild the ENTIRE json object. The huge advantage is that only the othe two json needs to be cleaned.
		a. Foreach through all the listed states on the EA form: use same method as 'Area Marker' state to retrieve all tokens on EDIT LAYER with that state.
		b. assign the areas with the area name and store them in the json. {area name:[coords]}
		c. Keep track of which state is used for which area. (needs to be a separate json)
		d. Remove the AM tokens from map
		e. Chat output: the following areas created: name and coords

[Jagged]

Hey wolph42, I notice you've been double posting quite a bit in the last few days. I think your browser must have developed a stutter

[wolph42]

Hey wolph42, I notice you've been double posting quite a bit in the last few days. I think your browser must have developed a stutter

crud. Yes I *have* noticed and indeed my browser *has* some stutters lately. Usually though I remove them as soon as I noticed it (like now). Thanks.