Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SolarShado]

If you don't mind my asking, just what are you using for path-finding?

[Lemunde]

If you don't mind my asking, just what are you using for path-finding?

The system doesn't really have a name.  It's just something I came up with on my own.  I tried to explain it earlier but I'll go over it again.  In all honesty it's not even pathfinding in the traditional sense.  The AI doesn't build a path to it's destination like in A*. 

Every round the AI checks to see if it has a line of sight to it's target.  If it does, it records the target's location and moves a tile towards it.  If it does not have line of sight, it moves towards the last recorded location of the target.  Once it reaches the last known location it checks for line of sight to the target.  If it doesn't have line of sight it basically gives up and goes back to whatever it was doing before.  If it does have line of sight, it repeats the process.

From an economical standpoint it's amazing.  The only difficult calculation it uses is calculating the line of sight which is a drop in the bucket compared to proper pathfinding algorithms.  I'd describe it as efficient but very limited.  It will never get the AI through a maze unless it's following the player.  But it will make the AI reliably chase down the player until the player has either moved out of range or turned enough corners to keep out of sight.  But in the end it's only half a step up from no pathfinding at all.

[Blacken]

I don't know why you've decided to take such a hostile stance but it's getting old.  I am not going to change the way I program to appease you and I don't feel obligated to explain why.  End of story.  I will not discuss this further.

You can "not discuss this further" all you want, and I'm sorry that you've chosen to become offended over fairly simple questions, but you're wrong. And I don't care if you're wrong, but I care that you might infect others. As I said: I don't really care what you do, but I care very much that people might see this thread and mistakenly think what you're doing is an effective or good method of operation. Your way is less optimal with regards to every single significant factor: development time (polymorphism can be more quickly duplicated than a mass of string parsing), program efficiency (.NET's String class is very slow, and as instead of using single scalar values you are checking over an entire IEnumerable), debugging (if an error happens in an inherited class, you can actually find it), and so on. There are many good ways to write code. Good programmers understand this, even if they don't agree with them. There are also many, many more bad ways to write code, and it is more important to understand when you are writing bad code than almost anything else in programming.

It isn't "hostile" to challenge the correctness of your claims. Nor is it "hostile" to expect a dialogue, if you are on a discussion forum. If you want to just wank about how wonderful you are without people (who, not for nothing, have a hell of a lot more experience doing this stuff than you do) asking you questions, why not just start a blog?

[Lemunde]

Let me reiterate so this is perfectly clear.  Any further criticizing of my techniques or design decisions will not be tolerated.  This has not and has never been the purpose of this thread.  I am open to any suggestions but I will not have my judgment insulted.  This ends now.  Violators will be reported.

[Total_Meltdown]

Let me reiterate so this is perfectly clear.  Any further criticizing of my techniques or design decisions will not be tolerated.  This has not and has never been the purpose of this thread.  I am open to any suggestions but I will not have my judgment insulted.  This ends now.  Violators will be reported.

I'll consider it.

[G-Flex]

Let me reiterate so this is perfectly clear.  Any further criticizing of my techniques or design decisions will not be tolerated.  This has not and has never been the purpose of this thread.  I am open to any suggestions but I will not have my judgment insulted.  This ends now.  Violators will be reported.

Wait, so you're open to suggestions, as long as you already agree with them? I honestly don't think that's a very productive way to do things.


Look, you're embarking on relatively complex creative endeavors here. You have to be able to accept criticism if you're going to do this, occasionally from people who aren't always the most tactful about it (see: Blacken), because they can often provide solid advice, especially if they have experience in the matter.

Programming is a complex skill and an art; you can't expect to be good at it right away, and in fact you won't be. If you ever want to actually be good at it - like anything else - you're going to have to learn how to accept negative feedback and try to get something out of it regardless of how it's said.

[Lemunde]

The opening post has been updated with ground rules.  Please review them.

[SolarShado]

@Blacken: Let Lemunde do it his way (it's not like you can force him to change over the 'net). Surely, if he's making bad choices, he'll eventually realize it. I get the impression that he's still rather new to programming, or at least this area. IMO the best way to learn is by doing, because in the process you make mistakes and, unless you're a total and complete idiot, you learn from them. Surely you've done the same thing? TBH, I wouldn't believe you if you answered "no" to that.

I respect that you're trying to help; but you're going about it the wrong way, and sounding like an a$$ in the process.

@Lemunde: Thanks for the explanation! I may have skimmed over an earlier explanation

EDIT: sorry if this goes against any of your rules, typed it up before you added them

[G-Flex]

The system doesn't really have a name.  It's just something I came up with on my own.  I tried to explain it earlier but I'll go over it again.  In all honesty it's not even pathfinding in the traditional sense.  The AI doesn't build a path to it's destination like in A*.

If you're not actually having the AI find a path to its destination, then you're doing something very, very, very wrong; it should be clear why.

Every round the AI checks to see if it has a line of sight to it's target.  If it does, it records the target's location and moves a tile towards it. If it does not have line of sight, it moves towards the last recorded location of the target.

The problem here is that you have to define "move towards". If there's a wall between the creature and the last known location of the target, where does the creature go? Towards the wall? What then? He'll never, ever reach the destination, because you aren't actually calculating an appropriate path; he has no idea which direction will actually lead him to the goal.

This won't even necessarily work for chasing the player around. What if the player is across an area that allows LoS but not passage (water, windows, etc.)? What if the monsters is forcibly placed into a situation where there's no straight-line path to either the player or the last known location of the player? What if the map changes in any way (passable tiles becoming impassable or vice-versa, transparent tiles becoming opaque or vice-versa)? What if something or someone gets, say, teleported? You're working on way too many assumptions here, and they're very, very easy and likely to be broken.

[SolarShado]

If there's a wall between the creature and the last known location of the target

I don't think this is likely... unless creatures have x-ray vision. He said it works on LoS. It "paths" to the last place the player was seen (rather like it would work IRL actually...)

You do make interesting points about windows and such... As for teleporting/etc., I imagine the creature would just go back to it's "idle" action. Re-checking for LoS to the last known location should solve the "changing terrain" problem.

I rather like the algorithm, sure it's not the most resilient solution, but it's simple, and seems to get the job done for now. He's already admitted to the possibility of having to replace it later.

[G-Flex]

I don't think this is likely... unless creatures have x-ray vision. He said it works on LoS. It "paths" to the last place the player was seen (rather like it would work IRL actually...)

It doesn't "path"; that's the entire problem. The creature just moves in a straight line, regardless of what obstacles, hazards, etc. might be in the way.

You do make interesting points about windows and such... As for teleporting/etc., I imagine the creature would just go back to it's "idle" action. Re-checking for LoS to the last known location should solve the "changing terrain" problem.

Yes, but that means that if the LoS between the creature and the target's last known location is ever blocked, the creature will immediately give up, which isn't very adequate.

[Lemunde]

The system doesn't really have a name.  It's just something I came up with on my own.  I tried to explain it earlier but I'll go over it again.  In all honesty it's not even pathfinding in the traditional sense.  The AI doesn't build a path to it's destination like in A*.

If you're not actually having the AI find a path to its destination, then you're doing something very, very, very wrong; it should be clear why.

Every round the AI checks to see if it has a line of sight to it's target.  If it does, it records the target's location and moves a tile towards it. If it does not have line of sight, it moves towards the last recorded location of the target.

The problem here is that you have to define "move towards". If there's a wall between the creature and the last known location of the target, where does the creature go? Towards the wall? What then? He'll never, ever reach the destination, because you aren't actually calculating an appropriate path; he has no idea which direction will actually lead him to the goal.

This won't even necessarily work for chasing the player around. What if the player is across an area that allows LoS but not passage (water, windows, etc.)? What if the monsters is forcibly placed into a situation where there's no straight-line path to either the player or the last known location of the player? What if the map changes in any way (passable tiles becoming impassable or vice-versa, transparent tiles becoming opaque or vice-versa)? What if something or someone gets, say, teleported? You're working on way too many assumptions here, and they're very, very easy and likely to be broken.

Please review the rules.

First of all, I already explained that the game doesn't need more complex pathfinding at this time.  This may change as the game develops and it's easily adjustable.

Don't let the phrase "line of sight" confuse you.  The function I'm using accounts for any impassable tile, including tiles occupied by creatures and tiles changed during gameplay.  I can even make the LoS function exclude Creatures for certain situations.  For pathfinding I include Creatures. 

The pathfinding relies heavily on the flow of the gameplay.  If the Creature starts off with a wall between it and the player, it will not have the player as a target.  If the Creature does not have a valid target it will continue searching every round until it finds one.  Once it has LoS to the player it will accept him as a valid target.  If the player moves behind an obstacle the Creature will move to the player's last known position then try to reacquire the player.

Yes, it is far from perfect.  That much is clear.  But it is fast, easy to implement and it's good enough for now.

[G-Flex]

Don't let the phrase "line of sight" confuse you.  The function I'm using accounts for any impassable tile, including tiles occupied by creatures and tiles changed during gameplay.  I can even make the LoS function exclude Creatures for certain situations.  For pathfinding I include Creatures.

I'm not sure what you mean by this, since it's my understanding that you have no "pathfinding" aside from the "line of sight".

Yes, it is far from perfect.  That much is clear.  But it is fast, easy to implement and it's good enough for now.

The problem with "good enough for now" is that there's an extremely good chance that at some point in the near future it won't be good enough, at which point you may indeed wind up kicking yourself for not implementing something more proper.

[Lemunde]

Don't let the phrase "line of sight" confuse you.  The function I'm using accounts for any impassable tile, including tiles occupied by creatures and tiles changed during gameplay.  I can even make the LoS function exclude Creatures for certain situations.  For pathfinding I include Creatures.

I'm not sure what you mean by this, since it's my understanding that you have no "pathfinding" aside from the "line of sight".

Yes, it is far from perfect.  That much is clear.  But it is fast, easy to implement and it's good enough for now.

The problem with "good enough for now" is that there's an extremely good chance that at some point in the near future it won't be good enough, at which point you may indeed wind up kicking yourself for not implementing something more proper.

I'm not going to argue semantics.  I haven't invented a word yet to describe what they're doing so for now I'm calling it "pathfinding".  And for Creatures they do make adjustments to try to move around them so in a sense it is pathfinding.

This won't be the first game I've made that uses a system like this so I have a pretty good idea of it's limitations.  It will work for the goals I have planned.

[G-Flex]

I wasn't arguing semantics. You said that the "LoS" function excludes Creatures, but that "pathfinding" includes them, but I have no idea what you mean by "pathfinding" since you have none beyond the previously-mentioned LoS.