Hi,
Try to think of a tile not as a distance, but a unit.
Bull. Thanks, but I know enough math to know of many measures of "distance". Such as next nearest neighbor or least deviation, etc. So what? Diablo represents a three dimensional space similar to the world we live in. And the *only* rational measure of distance in this world (or Diablo's) is the Euclidean norm. Not the taxi cab metric. That's a mistake that is pointed out to anyone taking intro calc when they get to line integrals.
But from a programming viewpoint, it doesn't really make sense to account for this distance.
Oh, really? The "distance" they keep track of is
WrongDistance = (deltaX + deltaY).
An adequate representation of Euclidean distance is
RightDistanceSquared = (deltaX * deltaX + deltaY * deltaY)
(since most things *should* drop off as R^2). And given the power of processors even when D1 came out, taking the square root of RightDistanceSquared would not have been a burdensome load on the FPU.
If you still think that's too much of a computative load, there's always table look up. Since the distances involved are in the range from 0 to 25 tiles in each direction, a simple two dimensional array of real distance could have been set up. All it needs is 625 values (about 2.5 k of storage), and there isn't even the overhead of a function call.
So, no. It is not hard to implement, it is not computationally intensive. Buzzard just doesn't have any real programmers (or designers). Just a bunch of kids messing with crayons and computers. They are very talented kids, sure. But they are too arrogant to get someone on board who has a clue.
--Pete
Try to think of a tile not as a distance, but a unit.
Bull. Thanks, but I know enough math to know of many measures of "distance". Such as next nearest neighbor or least deviation, etc. So what? Diablo represents a three dimensional space similar to the world we live in. And the *only* rational measure of distance in this world (or Diablo's) is the Euclidean norm. Not the taxi cab metric. That's a mistake that is pointed out to anyone taking intro calc when they get to line integrals.
But from a programming viewpoint, it doesn't really make sense to account for this distance.
Oh, really? The "distance" they keep track of is
WrongDistance = (deltaX + deltaY).
An adequate representation of Euclidean distance is
RightDistanceSquared = (deltaX * deltaX + deltaY * deltaY)
(since most things *should* drop off as R^2). And given the power of processors even when D1 came out, taking the square root of RightDistanceSquared would not have been a burdensome load on the FPU.
If you still think that's too much of a computative load, there's always table look up. Since the distances involved are in the range from 0 to 25 tiles in each direction, a simple two dimensional array of real distance could have been set up. All it needs is 625 values (about 2.5 k of storage), and there isn't even the overhead of a function call.
So, no. It is not hard to implement, it is not computationally intensive. Buzzard just doesn't have any real programmers (or designers). Just a bunch of kids messing with crayons and computers. They are very talented kids, sure. But they are too arrogant to get someone on board who has a clue.
--Pete
How big was the aquarium in Noah's ark?