The Bresenham algorithm is fundamentally aesthetic in nature and doesn't help you find the shortest way between points in any meaningful way. Sure, it might look better if creatures moved in what looks like straight lines towards their goal in open areas, but it has no effect on the cost of the path, and it is more expensive in implementation than just "if x < targetx && y < targety then up-right" (since Bresenham would require storing extra values and performing computations slightly more complex than the above, each step).
I know that it was created for shading but actually it can help you to find the shortest path between two points since in nature the shortest path between 2 nonmoving points is a straight line. Our points would be the access and exit points of a TCZ - given that said TCZ is rectangular.
You might now answer that In tile based games the a straight line isnt the shortest path,thanks to the "New york" Problem, but toady iirc circumvents the "New york" Problem by having diagonally movement being less expensiv then pure vertical and horizontal movement.
Secondly the the dwarfes iirc already remember their paths so they dont have to calculate them in every turn/frame. The Bresenham can return the tiles of the path while your way ignores that posibility.
And now comparing your method with my method.
your variant: (a made it a bit more pseucode like)
x, xtarget, y ytarget // get the coords of dorf and dorfs target
xst, yst // x and y steps
if x = targetx
then
xst = x;
else
if x < targetx
then
xst = x+1;
else
xst = x-1;
if y = targety
then
yst = y;
else
if y < targety
then
yst = y+1;
else
yst = y-1;
store (xst, yst)
the problem with your code is that it works fine in a "New york" world but its rather hard to incooporate a non "New york" world where a straight line is the better movement. It works also nice for moving targets actually.
In the worst case you compare 4 times 2 variables and you have 2 additions per iteration.
my variant:
get xa, ya // get start coordinate
get xe, ye // get end coordinate
d = 2×Δy – Δx // Δy = ye - ya ; Δx = xe - ye
ΔO = 2×Δy
ΔNO = 2×(Δy − Δx)
y = ya
store tile (xa, ya)
for every x of xa+1 till xe
if d ≤ 0
then
d = d + ΔO
else
d = d + ΔNO
y = y + 1
store tile(x, y)
The worst case here are 10 calculations for initialisation and , per iteration, 2 times comparing variables and 2 calculations. The bresenham would also work fine with DFs non "New york" world. The contra is that it doesnt work for moving targets.
if we say that calculations and comparings are each 1 clockcicle your code is better on the first 4 steps the dwarf does while in the 5th they reach an equilibrium and in the 6th the abused Bresenham gets better.
But actually i am not very far in this stuff yet since i do normaly other stuff.