Missiles

[Schmurk]

@Entropy

I just come with new results after testing the BSP tree. It takes around 4 times less memory than the actual collision map but it's really much slower. Moreover, it depends on the map where you use it. More the map has objects, longer it will be (which is quite logic btw).

 

For example, firing 476 rays in the path to the city of Idaloran takes around 830ms whereas it's computed in less than 60ms with the collision map.

 

So, I think we should stay on the collision map and try to optimize the memory as much as possible...

Edited January 24, 2007 by Schmurk

[Lunksnark]

I've been following this thread for a while and there is something bothering me about this ray approach and that is that in this system there is no concept of "difficulty" for a shot. If there is no concept of difficulty then applying a player skill modifier is near impossible. Take for example the following illustration. Using the ray approach A can see B and B can see A and therefore a shot can take place, but the reality is that B hitting A will be much more difficult that A hitting B.

 

 

How is it envisaged to take this into account?

[Learner]

I've been following this thread for a while and there is something bothering me about this ray approach and that is that in this system there is no concept of "difficulty" for a shot. If there is no concept of difficulty then applying a player skill modifier is near impossible. Take for example the following illustration. Using the ray approach A can see B and B can see A and therefore a shot can take place, but the reality is that B hitting A will be much more difficult that A hitting B.

 

 

How is it envisaged to take this into account?

That will be left until we get some basic missle support in place first.

[Lunksnark]

That will be left until we get some basic missle support in place first.

 

Basic missile support for a first person shooter (fps) and basic missile support an MMORPG are fundamentally different things. For example, in a FPS the "difficulty" concept is down to the mouse control and reactions of the RL player and what we really need to know is when they click the mouse button is that specific shot is possible. In an MMORPG such as EL the real driver would be, based on my character's skill how hard would this shot be. The skill of the RL player should have absolutely no bearing on the final result.

 

What I am trying to say (in a roundabout way) is that Basic missile support in an MMORPG IS the difficulty rating of a particular shot.

[Learner]

That will be left until we get some basic missle support in place first.

 

Basic missile support for a first person shooter (fps) and basic missile support an MMORPG are fundamentally different things. For example, in a FPS the "difficulty" concept is down to the mouse control and reactions of the RL player and what we really need to know is when they click the mouse button is that specific shot is possible. In an MMORPG such as EL the real driver would be, based on my character's skill how hard would this shot be. The skill of the RL player should have absolutely no bearing on the final result.

 

What I am trying to say (in a roundabout way) is that Basic missile support in an MMORPG IS the difficulty rating of a particular shot.

The basic missle support I'm talking about is the ability to even have a range weapon! That is before the difficulty concept is added, that is an additional refinement and improvement.

[Lunksnark]

The basic missle support I'm talking about is the ability to even have a range weapon! That is before the difficulty concept is added, that is an additional refinement and improvement.

The problem with the ray tracing approach is that it is only ever going to give you an absolute 'yes' or 'no' answer to whether you can hit an object or not. How do you plan on refining this to give a measure of difficulty?

 

The only way I can see it working is to apply an order of magnitude more processing power to the ray tracing algorithm, or use an additional statistical approach such as those shown earlier in the thread. If you are going for the former then there is a reason that fps style games are limited to 10's of players rather than 100's. And if we end up adding constraints and compromises in order to get the ray tracing approach to work at a sensible speed, then does this mean that we could have just as validly used a statistical approach right from the beginning?

 

If you want to get something up and running really quickly then why don't you define a basic api which takes the two actors and returns the difficulty. In the short term this just looks at the tiles between the two actors and computes the difficulty. Et voila missile support in short order and running in the test server for people to try out. Having the standard api also means this could be ripped out and replaced whole by the much more complicated ray tracing approach at a later date.

 

The reason I am bringing this up is that I have been responsible for coding on very large mission critical military and civilian real time systems for many years and learnt very early on that its worth spending time working a problem right the way through at the start because bad choices there cost serious time (and money) later on.

[The_Piper]

Piper, I think you are missing the point. Of course a bow can go further, but in EL it can't because you can see only like 9 meters away or so.

 

Right, you, the archer, can see the arrow only when its close to you. But:

 

Archer						  Enemy			(A)			 (E)
	  Bystander								   (B)

(A) End of visual range of Archer
(B) End of visual range of Bystander
(E) End of visual range of Enemy

 

Archer aims at Enemy but misses. When the arrow disappears at the end of the visual range of Archer (A), both Enemy and Bystander will see an arrow just disappearing or falling on the ground for no reason. And that may look a little bit strange, thats my point.

 

Piper

Edited January 24, 2007 by The_Piper

[TirunCollimdus]

Okay I am not a coder but I have a suggestion nonetheless. If you want to use the ray system and as Lunksnark says all it can do is give you a yes or no answer then why not make the answer always be yes. Every arrow hits all of the time but the difficulty level is worked into the damage calculation. Higher skill levels would equate to toughness and damage absorbed though not sure how you avoid giving experience for nondamaging hits. Can you trick the experience system into believing that non damage hits are actually not hits? Does it already do this? If so that should solve the problem except for possibly the memory usage in question.

 

Sorry I did not read the whole thread first but I hope the suggestion leads to a solution nonetheless.

 

TirunCollimdus

[Atlantis]

nvm

Edited January 25, 2007 by Atlantis

[ttlanhil]

Sorry I did not read the whole thread first but I hope the suggestion leads to a solution nonetheless.

You should read the whole thread, because your solution does not help.

why not?

You could assume that the missile always hits, but how much damages is based on skill (and perception, reaction, toughness, etc)... archery is a close-range attack, so you're aiming directly... skill can be the chance of hitting a vulnerable or critical point on your target. poor aim = low/no damage

 

another option is to follow the 'streak SRM' approach from mech-warrior series... you don't fire until it's guaranteed to hit. in this approach, your skill is checked to determine if you have a target lock yet. that's based on movement, range, visibility, etc. (all the same factors as above, just how you reduce it to dealing damage or not).

this also has the advantage of reducing projectiles in use (while not diminishing their use, since no-fire deals the same damage as a 0-hit)

[Atlantis]

nvm

Edited January 25, 2007 by Atlantis

[Entropy]

Lunksnark is wrong, for very obvious reasons.

 

To calculate the difficulty, and have an asymmetric path, you just apply a random displacement of the destination +/- value, depending on the distance to the target, skill of the person, visibility, arrow type, bow type, etc.

And voila, you have difficulty settings and asymmetric paths.

[Lunksnark]

Lunksnark is wrong, for very obvious reasons.

 

To calculate the difficulty, and have an asymmetric path, you just apply a random displacement of the destination

+/- value, depending on the distance to the target, skill of the person, visibility, arrow type, bow type, etc.

And voila, you have difficulty settings and asymmetric paths.

 

Lets break this down:

 

have an asymmetric path, you just apply a random displacement of the destination

I assume what are you saying is that when you shoot from A->B, you will apply a random offset to the destination point? For example if you go from A->B+d, where d is a (Gaussian) random offset, determined by the parameter set (distance, skill, visibility, arrow, bow).

 

However what d does not depend on, is the degree of clutter on the path, which would give the difficulty we would want to model. Meaning that a hit is possible (or guaranteed?) if there is an open path A->B+d.

 

The most obvious flaw in this model is that it does not allow skill to overcome path difficulty. Referring back to the diagram I drew earlier, this approach would still not solve the difficulty problem in hand.

 

Consider also a situation where the path for the exact line A->B+0 is blocked, but A->B+d (where d!=0) is open; as skill increases, d->0, so a shot which may be made by an unskilled character (blue arc) is not possible for a highly skilled one (red arc).

 

(Apologies for the stick men drawings. I am graphically challenged, but it seemed to be the best way of explaining things without the aid of whiteboard)

 

Visibility

Is this related to the ambient light level or the quantity of clutter between the source and the target? If its light level then this can be grouped with the items listed next. If its clutter then that its a different problem altogether.

 

distance to the target, skill of the person, arrow type, bow type

All valid modifiers that could/should be included in the final calculation, but unfortunately they are not the actual base difficulty of the intended shot.

 

I think ballistic weapons will be a great addition to the game, and could really change the whole makeup of combat and teamwork. But if some of those algorithm performance figures listed earlier in the thread hold true, you will have a set hard limit on how many players can fire a bow before the server suffers some serious performance issues. And all this before we know exactly how players will react to this exciting new feature.

 

I really do know where you are coming from though. Working in this industry for a long time it is always tempting to use an algorithm because its cool, new and interesting to write. At the end of the day though you have to look at it with your head rather than your heart. If we are taking the view that the calculation should be achieved though rough approximations using only the above factors then there really is no need to go with such a complex and expensive ray tracing approach. We end up cracking a walnut with the proverbial sledge hammer.

 

On an slightly unrelated note, there is good site on the physics of bows here

 

Looking at some of the values this gives:

Speed of arrow			   = 60m/s  (ish)
Time for arrow to travel 1m  = 1 / 60 = ~0.0166 seconds
Maximum Range of arrow	   = 9 meters
Time to target			   = 9 * 0.0166
						 = 0.15 seconds

Human perception rate		= 25 fps (frames per second)
Time for single frame		= 1 / 25 = 0.04 seconds

# Frames for distance covered by arrow =  0.15 / 0.04 = 3.75 frames

 

Based on this it would be *meaningful* to animate a few frames for the arrow, but it would have to look like an indescrete blur. There is really no point in getting fussed over whether it appears to go through a tree with that level of approximation.

Edited January 25, 2007 by Lunksnark

[Entropy]

We won't have ballistic weapons in EL. They can work in FPSes, but in EL the distance is very short, like 10 meters at most to the target. Which means that all the trajectory is linear. We also can't apply a formul based on speed because of the lag (a player might move by the time the arrow reaches them). Besides, for real life situation, an arrow would go 10 meters in less than 100 MS, so it can be aproximated as instantaneous.

 

The most obvious flaw in this model is that it does not allow skill to overcome path difficulty. Referring back to the diagram I drew earlier, this approach would still not solve the difficulty problem in hand.

Yes it will. A bad shooter (or bad bow, bad light, etc.) will have a higher offset, which means a higher angle, which in turn means that it will be very hard for a bad shooter to squeeze an arrow through a small opening if the distance is too big.

 

Consider also a situation where the path for the exact line A->B+0 is blocked, but A->B+d (where d!=0) is open; as skill increases, d->0, so a shot which may be made by an unskilled character (blue arc) is not possible for a highly skilled one (red arc).

No, because there will be two rays for each shooting, one ray to determine if shooting is possible under the best case scenario (0 displacement), and another one for the actual ray, with the displacement.

 

But if some of those algorithm performance figures listed earlier in the thread hold true, you will have a set hard limit on how many players can fire a bow before the server suffers some serious performance issues. And all this before we know exactly how players will react to this exciting new feature.

 

No, actually, if we have this level of performance, we will be very safe, being able to fire ~500 arrows in 100 MS (2 rays for each arrow). Given the fact that curently the server uses about 15% of the CPU at peak times, and given the fact that having 500 players firing an arrow each second is a very very very unlikely scenario, I have absolutely no doubt in my mind that there will be no performance issues related to the missiles.

[Lunksnark]

We won't have ballistic weapons in EL. They can work in FPSes, but in EL the distance is very short, like 10 meters at most to the target. Which means that all the trajectory is linear. We also can't apply a formul based on speed because of the lag (a player might move by the time the arrow reaches them). Besides, for real life situation, an arrow would go 10 meters in less than 100 MS, so it can be approximated as instantaneous.

Bows, crossbows, slings, javelins are all ballistic weapons. It just so happens that at the ranges we are talking about they will have a notionally zero level trajectory and can be treated as such in the math. I used ballistic weapons as a term, not as an intention to shoot in arc'ed trajectories. As cool as that would be, like you say it just wouldn't have meaning for these ranges.

I should have made a point of saying that I did not intend the calculations to be factored into the server side computation, but was actually addressing some concerns raised earlier about how it would look on the client (I did say "on an unrelated note" but should have made it more clear).

You are correct for a server side calculation this should be treated as instantaneous. I have worked in an environment were proper balistic prediction calculations had to be made and it gets madly complicated very quickly!

 

Yes it will. A bad shooter (or bad bow, bad light, etc.) will have a higher offset, which means a higher angle, which in turn means that it will be very hard for a bad shooter to squeeze an arrow through a small opening if the distance is too big.

 

No, because there will be two rays for each shooting, one ray to determine if shooting is possible under the best case scenario (0 displacement), and another one for the actual ray, with the displacement.

Agreed that bad bows and bad light should affect the final outcome.

However you seem to be implying that the small opening is directly in line of the "best case" or the "displacement" ray, which will be statistically unlikely. I'm guessing seen as the best case ray is fixed, for simplicity it would probably have to be set from the central middle point of the source and target. It is therefore not the actual "best case" but in fact an arbitrary case which may or may not be valid and does not really take the environment into consideration. Consider, if you have a small opening on an object or a small route somewhere between source and target then you will need a great deal more rays heading out from the best case in order to "detect" where it actually is, if indeed it does exist.

 

Lets put this in the context of the second stick man drawing.

The best case A->B for a good and bad shooter is a fail. The actual ray with the displacement will also be a miss for the "good" archer, but will succeed for the "bad" archer.

 

Archer	 Best Case   Actual Case	Final Result
Good	   FAIL		FAIL		   0 = FAIL
Bad		FAIL		SUCCESS		0>N<1 (Partial Success?)

Of course we could say if the best case fails then don't bother with the actual case. But this misses the point of using such an expensive algorithm in the first place. Its aim is to work out if something is really possible in 3d space and to get the best possible to answer to the problem. If that has to be dumbed down to such an extent in order for it to work in this environment, why not use something much simpler (and therefore cheaper in processing terms) that is going to give equally valid answers to start with?

I have to admit that I just read your blog entry on this topic and I can see the reasoning and logic behind having a ray tracing algorithm in the server - for certain tasks. But, as cool as it is it doesn't necessarily make it applicable to all tasks.

 

No, actually, if we have this level of performance, we will be very safe, being able to fire ~500 arrows in 100 MS (2 rays for each arrow). Given the fact that curently the server uses about 15% of the CPU at peak times, and given the fact that having 500 players firing an arrow each second is a very very very unlikely scenario, I have absolutely no doubt in my mind that there will be no performance issues related to the missiles.

I'm still not convinced that you will only use two rays per arrow to get the system to work with the approach you are talking about. If you do need a more rays to do what you want to do this figure scales down quite rapidly.

[Entropy]

Consider, if you have a small opening on an object or a small route somewhere between source and target then you will need a great deal more rays heading out from the best case in order to "detect" where it actually is, if indeed it does exist.

Such scenarios are pretty unlikely, it would only happen with some fences, MAYBE. BTW, the ray will go to the chest, not to the belly, so you won't be able to hide behind small fences or bushes.

So this limits the special situations even more.

 

Of course we could say if the best case fails then don't bother with the actual case. But this misses the point of using such an expensive algorithm in the first place. Its aim is to work out if something is really possible in 3d space and to get the best possible to answer to the problem. If that has to be dumbed down to such an extent in order for it to work in this environment, why not use something much simpler (and therefore cheaper in processing terms) that is going to give equally valid answers to start with?

Ok, then propose a better solution that is at least as good as this one.

 

I'm still not convinced that you will only use two rays per arrow to get the system to work with the approach you are talking about. If you do need a more rays to do what you want to do this figure scales down quite rapidly.

 

FFS, it's just a game, it's not controling a nuclear reactor, or ray tracing application. 2 rays, 3 at the very most is all we need.

[Lunksnark]

Such scenarios are pretty unlikely, it would only happen with some fences, MAYBE. BTW, the ray will go to the chest, not to the belly, so you won't be able to hide behind small fences or bushes.

So this limits the special situations even more.

With trees, bushes and probably quite a few of the other objects as well this will be more likely than you think, especially factoring in the possible difference in heights between the source and target and the different orientation of the objects themselves.

 

FFS, it's just a game, it's not controling a nuclear reactor, or ray tracing application. 2 rays, 3 at the very most is all we need.

Hey calm down I'm the one who’s trying to avoid using a complex algorithm here!

 

Ok, then propose a better solution that is at least as good as this one.

There were a couple listed earlier in this thread that imo would do the job equally well and as a bonus should be much simpler to implement and cheaper on the cpu time. I am specifically thinking of the ones where you draw an anti aliased line between the source and target square and each intervening object has a specific opacity/ possibility of getting through value (and maybe even an obejects max height?). Then factor in values such as distance for each object, skill, weapon type, ambient light etc. The result determines a hit or miss and is factoring in the environment through which your firing giving a pretty good difficulty metric. Additionally if your using a cumulative value for each intervening object encountered you could even determine that when you reach a certain value this is where the arrow lands (ie its a miss) and optionally tell the client to put an arrow there (for prettiness or wow factor). I think its been explained pretty well earlier in the thread without me reiterating it again. However if you wanted I’m sure I could come up with a slightly more concrete plan.

 

Just remember, there are valid applications for using a ray tracing algorithm and if another algorithm was chosen for this specific task then it in no way undermines the good work that has already been done, and the validity of including both sets of functionality within the server.

[Entropy]

I am specifically thinking of the ones where you draw an anti aliased line between the source and target square and each intervening object has a specific opacity/ possibility of getting through value (and maybe even an obejects max height?). Then factor in values such as distance for each object, skill, weapon type, ambient light etc. The result determines a hit or miss and is factoring in the environment through which your firing giving a pretty good difficulty metric. Additionally if your using a cumulative value for each intervening object encountered you could even determine that when you reach a certain value this is where the arrow lands (ie its a miss) and optionally tell the client to put an arrow there (for prettiness or wow factor). I think its been explained pretty well earlier in the thread without me reiterating it again. However if you wanted I’m sure I could come up with a slightly more concrete plan.

 

So don't you have to do a collision detection with the object in order to see if it intersected it or not? How else would you detect that? Magic?

[Schmurk]

There were a couple listed earlier in this thread that imo would do the job equally well and as a bonus should be much simpler to implement and cheaper on the cpu time. I am specifically thinking of the ones where you draw an anti aliased line between the source and target square and each intervening object has a specific opacity/ possibility of getting through value (and maybe even an obejects max height?).

[...]

The most complex task in the actual algorithm is not computing the intersection between a line and the faces of an object. This part is the easiest in fact. Actually, the hardest part is building an efficient (in speed and memory) data structure that allow you to know the objects that cross a given tile. Then iterate on the tiles with a specific line drawing algorithm to detect the collisions with the objects.

 

So NO, other solutions will not be simpler. I had to say that.

 

Anyway, the algorithm that looks for an intersection between the line and the faces of an object can now easily be replaced by something using chance percentages as it has been proposed before in this thread. This will be maybe faster but now I've tested a lot of things and discover a lot of problems that can occur, I'm not sure that it will work fine according to the complexity of some objects and the many cases that have to be considered. In fact, there's a lot of chances that such a system could be more complex than the actual one...

[Lunksnark]

So don't you have to do a collision detection with the object in order to see if it intersected it or not? How else would you detect that? Magic?

 

*sigh*. No that is exactly what you are trying to avoid doing in the first place. To simplify, what you end up doing is a addition of the difficulty factor for each tile in an anti aliased line and offsetting that with other characteristics such as light, weapon, skill etc.. Pulling rabbits from hats is most assuredly not required.

 

The most complex task in the actual algorithm is not computing the intersection between a line and the faces of an object. This part is the easiest in fact. Actually, the hardest part is building an efficient (in speed and memory) data structure that allow you to know the objects that cross a given tile. Then iterate on the tiles with a specific line drawing algorithm to detect the collisions with the objects.

 

The map format is such that you are probably correct. Objects seemed stored in unordered lists and are not directly relatable from a given tile location which I guess is the key point here. Doing this lookup each iteration could well be expensive. If it is then this should be addressed and then there are ways of getting around it - see below.

 

Anyway, the algorithm that looks for an intersection between the line and the faces of an object can now easily be replaced by something using chance percentages as it has been proposed before in this thread. This will be maybe faster but now I've tested a lot of things and discover a lot of problems that can occur, I'm not sure that it will work fine according to the complexity of some objects and the many cases that have to be considered. In fact, there's a lot of chances that such a system could be more complex than the actual one...

 

So NO, other solutions will not be simpler. I had to say that.

 

The system proposed by both of us may still produce obscure artefacts when faced with a series of complex objects. This will occur with any approach (that is not super super complicated) especially when we have to take into account the basic assumptions that we already are. Bare in mind though that this is an MMORPG, people expect to be able to do epic stuff at high levels and this is what makes things memorable. Besides, everything will happen in the blink of an eye anyway. It's not as if they will be following the algorithm to the n'th degree. In fact it will be so fast they won't be able to.

 

The basis of what we've been talking about is utilising a difficulty value for a particular tile on a specific map. This will be achieved through using an already calculated difficulty matrix.

This way you do not have to do the expensive 3d object lookup for each tile and you also avoid doing the intersection algorithm. Leaving you with one main algorithm to contend with; generating the anti-aliased line and adding up the specific difficulty values, then applying other modifiers I.e. no complex lookups and no additional complex calculations.

This two dimensional difficulty matrix could be produced in a number of ways.

 

1. Real time

Good:

No changes to the map format, or no additional files required.

Bad:

Like you say with the map format as it stands the object lookup for a particular tile is probably expensive.

 

2. Pre-calculated by server at start-up

Bad:

Ties up the server at start-up working through task.

Limits what choices could be made for the difficulty algorithm due to start-up time constraints.

Good:

If a very simple algorithm is being used, it removes the need for an offline tool or maybe updates to the map format.

 

3. Pre-calculated off-line

Good:

Could use any number of approaches to generate the difficulty map, e.g. predefined/ set difficulty rates to each object, or even ray tracing from each square to each adjacent square.

It doesn't matter if it takes five minutes or an hour to do the calculation for each map. Its done offline and only needs re-doing when the map is updated. What comes out will always be a very simple two dimensional array.

Bad:

Have to write an off-line tool or update the map generator to do this for you.

[Schmurk]

There are 2 problems in your approch:

 

First problem: as you know, entropy wants to implement dynamic maps in the future so static informations in the tiles is not possible. When you will add or remove an object, you'll have to recompute the value of the tile according to all the objects that cross it. How to do this fast if you don't know for each tile the objects that cross it?

 

Second problem: according to what you are saying, all tiles will have a difficulty depending on the objects around it. So for you, in these 2 situations, the thrower will have the same chance to hit his target?

 

Ok, you'll say that then you have to consider the heights of the thrower and the target. NP, so how do you handle the following situations then?

 

To treat that sort of situations, you'll be obliged to know what kind of objects are in the tile and you'll also have to affect a difficulty level for each existing object by hand! It will be a hard work...

 

Anyway, I'm not saying that the actual solution is the best but I'm still septic about how to handle that simpler...

[Lunksnark]

First problem: as you know, entropy wants to implement dynamic maps in the future so static informations in the tiles is not possible. When you will add or remove an object, you'll have to recompute the value of the tile according to all the objects that cross it. How to do this fast if you don't know for each tile the objects that cross it?

At the point where you are adding an object to a specific tile you do know its parameters because it will be part of an object tool kit. Keep the algorithm to generate difficulty simple and this issue goes away.

 

Second problem: according to what you are saying, all tiles will have a difficulty depending on the objects around it. So for you, in these 2 situations, the thrower will have the same chance to hit his target?

Ok, you'll say that then you have to consider the heights of the thrower and the target.

As you say if you also maintained some height information for the tiles difficulty you could ignore the wall for range2.jpg. You know the difference between the respective heights of the source and target and could add a simple comparison for the specified tile to this difference.

 

so how do you handle the following situations then?

For the tree example if you maintained a height you would still have an obstruction in the way that is true (Trees do tend to be a taller than the possible difference in heights between source and target). Bear in mind though the assumptions we are making just to get to this point. e.g that the source and target players could be anywhere if their respective tiles. Would it not be fair to say that the chance of shooting around a solid trunk and the chance of shooting through a set of tree limbs could be validly classified with the same difficulty?

 

To treat that sort of situations, you'll be obliged to know what kind of objects are in the tile and you'll also have to affect a difficulty level for each existing object by hand! It will be a hard work...

Yes some effort up front will have to be applied to the tool kit of objects already available in the game. This will be a one off hit though and not done in real time.

 

I just thought of another situation based on your drawing above. I dont know if it could ever happen based on the macro scales we are talking about, but consider:

 

Option 1 would be to ignore it. At the distances we are talking about, getting a significant amount of terrain in the way is unlikely, and even if you do could be explained away in RP terms as someone arc'ing the shot slightly.

 

Option 2 would be to deal with it and this could be solved because we would know the height of the ground at that point the the height diff between source and target as discussed before. If the estimated difference for that tile turns out to be below ground level then set the difficulty to the maximum and it becomes an automatic fail.

[Schmurk]

Ok, so for you the following shot is completly prohibited, right?

 

As you can see, you can shoot under walkable tiles in this example.

The two examples I gave you are basic examples but there are so much complicated places out there where I'm almost sure that a simple method like the one you're talking about won't work.

 

TBH, in this last example, I made a supposition about height tiles in my code and it didn't work so I have to correct it...

[Lunksnark]

As you can see, you can shoot under walkable tiles in this example.

The two examples I gave you are basic examples but there are so much complicated places out there where I'm almost sure that a simple method like the one you're talking about won't work.

Firing only two rays from one point to the next could just as easily hit any one of the obstructions shown on the diagram as with the simple difficulty methodology. Only if you were are iring many rays from multiple points within the source bounding box to multiple points within the target box could you guarantee to get an actual metric of whether this shot would be possible or not. The difficulty metric in this instance would be a percentage of how many of the the rays could hit the target out of the many that were fired. But as has already been said firing a great many rays for every single shot would be a bad move from a server performance perspective.

 

The simpler difficulty calculation would still return a value, it just might be that that value would be very hard to achieve without some sort of epic level archer. It certainly is an interesting example and one that can be overcome. Id forgotten that the "real" ground level does not necessarily equate to the height map for every single instance and I guess that's the crux of the problem. Your saying there seem to be valid routes "underneath" the existing height map. Well it must be possible to find these cases and put them into a slightly more extended difficulty/ height matrix. I can think of a couple of ways of doing this, but right now its home time for me and I'm going to head off. I will readdress this later this evening or if I don't have time tonight, tomorrow morning.

 

TBH, in this last example, I made a supposition about height tiles in my code and it didn't work whistle.gif so I have to correct it... tongue.gif

BTW, what was the supposition you made?

 

Wow, thinking about this is so much more fun than doing real work

Edited January 26, 2007 by Lunksnark

[Schmurk]

Firing only two rays from one point to the next could just as easily hit any one of the obstructions shown on the diagram as with the simple difficulty methodology. Only if you were in fact firing many rays from multiple points within the source bounding box to multiple points within the target box could you ever guarantee to get an actual metric of whether this shot would be possible or not. The difficulty metric in this instance would be a percentage of how many of the the rays could hit out of the many that were fired. But as has already been said firing a great many rays for every single shot would be a bad move from a server performance perspective.

I agree that only a small amount of rays have to be fired or the server will suffer. Actually, I don't know how entropy wants to compute the difficulty but I think there can be many ways to avoid shooting several rays. At least, I think that the skill of the archer may be compared with the a/d of the target...

 

The simpler difficulty calculation would still return a value, it just might be that that value would be very hard to achieve without some sort of epic level archer.

It certainly is an interesting example though Id forgotten that the "real" ground level does not necessarily equate to the height map every single time... Hmm, it must be be possible to work out the difference in these cases right?

In this case and other similar cases, the only solution I see with a simple value system will be to store several difficulties per height so it's quite equal to storing ID of the several objects... BTW, in the actual system, you can handle collision tiles that cover more than 1 height tile so you can reduce memory usage and the performance doesn't suffer at all. With a value system, I think that you don't have the choice and you must store at least one value per height tile.

 

BTW, what was the supposition you made?

The same as yours

If a ray passes under a height tile, there's a collision. Now, I have to test for a real intersection point between a square and a ray.

 

Wow, thinking about this is so much more fun than doing real work

LOL

Same here, my day of work was not very productive...