I have pathfinding in two segments of the game. But in one i want to make it different.
Basicly it is a turn based pathfinding. So you click a tile within your range and go there. And the tiles within range are shown.
I have the range and the obstacles set up. Now what is bugging me how would i show the farthest tile the unit can go if the tile is really close but the unit needs to go around obstacles? Basicly the unit cannot go around so much, but since it is in range it shows like it can. And that doesnt really affect much but its confusing. since it should only show the possible moves.
Should i loop to find path for all possible steps or is there another way to do it, since im quite confused.
If so, you will have to use a fastloop to check each tile individually, to see whether it can be reached. To save a bit of time, you only need to check for paths to the tiles that are within normal range (ie. if there are no obstacles anywhere).
Yeah, i figured it out, but it takes quite a long time to do it. I should try to make it a little faster, i am using two loops, and surely i could use only one to do it, or atleast to separate them.
I didnt do unit obstacles and loop for obstacles and it loops all blocks... but i since already have those stuff in my project and i did this separatly from it.
Your code doesn't wrap the view around objects properly. There are parts which you can potentially get to based on your square grid that you don't show. I just wrote my own example and it produced results looking like this:
It's quite a bit more complicated and takes a little while to work. Path finding type problems usually take a little while and my implementation is inefficient because I am not able to add objects to a list (which means iterating over all of the objects numerous times - a square complexity O(n^2) ). The best way to solve this problem is to do it in stages per codeloop, so that the screen can refresh. Do 1 iteration per codeloop or something. I will release my code at some point.
The problem there is that the vision range is not fixed - it varies between 5 and 7 squares.
In a lot of cases (incl. any strategy game) that's not good enough - for movement or vision.
It does have the advantage of being more circular, rather than diamond-shape, so it would be better in some cases.
This kind of thing is easy in MMF1, using the "Grid" extension, but in MMF2 it seems to be more difficult.
The "APF" extension is more powerful, but makes everything very complicated - even a basic example takes lines and lines of code.
The "Pathfinding" extension just doesn't seem to work for me - even opening the example files causes MMF2 to crash.
My example uses a user-defined VisibleRadius property, so each of those blue player objects can have a variable visible radius. The grid is generated using that property for each of those obejcts. In this example each player has his own grid but in practice I would use a single grid of the largest user-defined radius and use this for all players.
Suppose a unit can move 5 squares per turn.
Your method is showing squares as being reachable, when they are not.
Or, supposing a unit can move 7 squares per turn - then you are not showing squares as being reacable, when they actually are.
Now, if your method is actually for calculating the line-of-sight, and not movement-range, (as I suspect is the case) then it still doesn't work properly.
The spaces marked with a red "X" should not be visible.
"Your code doesn't wrap the view around objects properly."
I dont know what you meant by that, but it does wrap the view around objects properly. It is exactly what it does. And yours does not. as you shown in the example.
And if you wanted to do line of sight you didnt do that aswell... as sketchy sketched it out for ya.
And that oval thing can be achieved easily by just adding to the loop to compare distance to maxsteps*gridblocksize
Anyway the stupidiest thing is, that i made this code for my main project, i now merged it in. And it doesn't work. The game crashes. And everything is the same, i checked everything to find why it crashes but there is no reason at all. I copy pasted, changed the objects, checked the loops, spreads, and everything should work. But it just doesnt.
I made an example of a pretty simple and efficient system, using the pathfinding extension.
It only uses one fastloop, and only checks the squares within the normal movement range.
If you have trouble getting it to work, then you could send me your pathfinding.cox and I'll make it work with that - I think maybe we have different versions or something.
Line of sight is clearly not what was achieved from the example I looked at. It actually gave some squares you would cross out as was done so in a previous post. I could only assume that you would want to display the attainable square (i.e. a square that a path exists for). So evidently the squares that you can see are places that can be reached within the specified radius and would test line of sight to those positions independently (i.e you wouldn't attempt to go to a destination that you couldn't see, even though there is a possible path for it). If you are just interested in a region available in the line of sight then that's just an additional restriction of the grid I am displaying. Basically what that means is: you should keep your retarded comments to yourself.
Sketchy
The code that limits the visible region is a single condition. Combine this with the 2 loops that actually create this grid then theoretically I can make the region any shape I want. In the case of N moves, the limitations are based on the sum of the x and y indices rather than the sum of the square of the indices. My example would then restrict the grid to just the squares that a path within the region exists for, and then you could restrict this further by any other condition i.e. line of sight. Having said that, I would expect that visible sqaures are a subset of the path-reachable squares. Depending on how you want to implement this though, having a set of squares representing the reachable squares within x moves is useful given that this is player controlled. If you can see the position then it doesn't matter that the player cannot. I can imagine that for some enemy AI purposes you would only want to get the squares visible to the enemy object.
Granted MMF is not very good at doing this kind of stuff. The pathfinding object sounds like a good idea.
Advertisement
Post Reply
Edited by Don Luciano
