Hi Shri

You are right, currently all cells have the same cost. I think it wouldn't be difficult to add different costs. I may be wrong because I wrote that code a very long time ago and I can't remember the details, but if you look for the line that says (around line 948 of iso.js I believe):

var tentativeGScore = currentNode.gScore + 1;

It should just be a case of replacing the "1" with a cost associated with the current node. And by node I mean iso cell.

There will be a new version of wade.iso soon, but it won't include this change. We are working on a whole new version of Wade (WADE 3.0) to release at the beginning of April if everything goes according to our plans. It will have many exciting new iso and non-iso improvements, but I think we'll have to wait for 3.1 for this one.

As we are soon starting to work on our own iso game, the iso plug-in will be updated quite frequently in the short term, so this may only be a few weeks away.

Gio,

Thanks for the reply.

I looked into it a little bit and implemented variable grid movment costs and movement limitations in the iso source code.

Movement costs mean that different grids have different costs. This is accomplished through the setDetail function.

For example, a grid which is swampy would have a movement cost higher (say 3) than a grass grid (say 1).

If you never call setDetail, then the movement costs default to 1 for each grid.

Movement limits are a way of dynamically allowing/preventing iso objects from passing through grids.

For example, if you had a character who couldn't cross water and then they acquired some water walking shoes,

you could reset the characters costLimit so that it could walk on the water.

Or if you had characters which were land bound versus characters that could fly, they would have different movment limits.

This is simply a number which is checked against an individual grids movement cost. If your movement limit is less than the grid movment cost, then you can't go through that grid. It seems like you currently do this with collision maps, but this would be another simple way of doing it. If no movment limit is set, then just do pathing based on movement costs like usual.

Here are the changes to the iso source code in a nutshell

- terrainBehavior.js: Added cost field to the setDetail data structure.To set a movement cost for a grid, you would call setDetail and include {cost: number} in the data field. If no cost is associated with a grid, then it defaults to 1 like in the old findPath routine.

- isoCharacter.js: Added isoObjCostLimit parameter to setDestination() parameters

- iso.js: Added isoObjCostLimit parameter to findPath() parameters. Modified code in findPath to ignore a grid if it's movment cost exceeds the objects cost limit. Modified code so that movement costs of grids is taken into account when finding best path.If no movement limit is passed in, then just carry on like usual.

I think it is less then 20 lines of code in total.

If you search the iso source files for 'Ashatej', you can find the specific sections

I created a little demo where an iso world is created . There is a blue guy who goes to grids based on where you click. The grids go green-blue-red-black in order of movment cost. The current setting is that the costLimit does not allow the character to move over the black grids.

To modify the player cost limit, search for player.avatar.costLimit or COST_LIMIT in the game file.

To modify the costs associated with grids, look at how the costs are assigned in the world file.

Assignment of the grid colors is in the levelData.json file.

I tested it out and it seems to work as expected.

I have zipped up the code and the test files and attached them to this reply.

It should run right out of the box once you unzip it.

Anyway, I know there is a lot on you plate, but this would seem to be a simple and useful thing to add to the iso plugin if you have the time.

cheers,

Shri

Thanks for looking into it Shri.

We'll see what we can do for the next version, my comment above was referring to the fact that from WADE 3.0 onward the iso plug-in will be completely integrated with the online editor, so any changes like this one will have to be reflected in the editor (i.e. there must be a way of assigning costs from the visual editor too), which is why it can be a fair bit of work. Not ruling it out for 3.0 though, it definitely looks useful. It just depends on how much time we end up spending on other things.

Gio,

Is there a way to do this with the new height stuff in the iso module ? It looks like if you set the height, then the tiles are offset up or down. But there are height and heightOffset settings ?

I don't want to visually offset the tile heights, but I want do something like - this character can't cross water - which is the same height visually as the grass.

Anyway, I can still roll my own, but I wasn't sure if I was missing something in how I could do it in the existing engine with the height stuff.

cheers,

Shri

Hi Shri

Regarding crossing water have you looked in the tile template editor?. You can check the collisions box for a terrain tile and it should prevent a character using that square I believe

Foxcode,

Thanks for the reply, but collisions aren't exactly what I was looking for.

I put together a little demo to show what I am after. It should run out of the box. Click the map to fly our trusty dragon around.

All tiles on the map have a "cost" associated with them which is set via the iso.setTile() function. These costs are then taken into account when an iso character tries to find a path. If the dragon is not moving, you can change tile types (and their associated costs) by pressing a keyboard key and then clicking the map (g=grass cost: 2, w=water cost: 5, s=sand cost: 10, l=lava cost: 20, v=void cost: 150). As the costs of the map tiles change, the dragon varies how if flies around based on the modified findPath() function in iso.js.

The void implements a tile which execeeds the dragons "costLimit" the result being that the dragon can't fly over a void tile. If you surround the dragon with void tiles, you should see that it is trapped inside the box you just made.

My original post a while back was asking about implementing this because it is (in my opinion) more inclusive than height. For example, height matters if you are walking, but if you are flying not so much.

The original idea for this came from an isometric tower defense game. The enemies would move to a target goal, but how they move about the map would change depending on where the player places towers (which in turn would raise movement cost for tiles around towers) or alternatively, enemies would "see" where dead bodies were and modify their paths to avoid those kill zones.

Anyway, my original question from a couple of days ago was whether I could do this with the newly implemented height stuff rather than rolling my own. Even though it is a pretty simple change (two lines in isoCharacter.js and nine lines changed or added to iso.js). I wanted to use the built in methods if they were available.

As before, the dragon graphics are from here please respect the rights of the copyright holder.

cheers,

Shri

**Update: I changed the code so the movement cost is now attached to the tile data rather than the detail data. It occurred to me that you may want to have/change the detail of a tile. I uploaded a newer version of the demo which should all run using the tile data. It seems to work as expected - cheers

Hey Shri

Thanks for that.

There is currently no easy way to do what you wanted to do without changing the WADE source. You could try to hack it with heights and heightOffsets, and it may work but I wouldn't recommended as they're just meant for something else.

Your modifications make sense (and I like the idea of storing the information in the tile data rather than detail) - it's something that really should be supported by the isometric engine by default. However we need to find a way to expose these cost values to the editor so that people can easily visualize and change them, before we can include these changes in the engine. I've been thinking about it, and have a couple of ideas to try out. We'll see how that goes.