Game Development Reference
In-Depth Information
er to make sure that the new tower will not make the path unsolvable. If the path
would become unsolvable, the build request is denied and the game shows an ap-
propriate error message to the player. If the path is solved, the game builds the
tower and sets the global path to the new path. Figure 14.3 shows a location where
tower placement would be denied because it fully blocks the path.
Figure 14.3 The game won't allow building a tower on the selected tile (out-
lined in white) because it blocks the path.
If the tower location is valid, the global path will change. But this new tower will
potentially invalidate the path of any enemy that's active at the time. In order to
fix this issue, the ComputeAStar function can also be called on an individual
enemy. So when the global path changes due to a new tower, any active enemies
will recompute their new best path. It is possible that some enemies might end up
fully blocked by the tower being built, but that won't trivialize the entire game, so
the system doesn't worry about it. It turns out it's actually possible to get the game
into an unwinnable state if you box in an enemy so that it's only in range of snare
towers and can never die, but you really have to try to cause this bug to occur.
If you look at ComputeAStar closely, you'll notice that it actually searches for
the path from the goal node to the start node. That's because if the path were com-
puted the other way, the result would be a linked list of nodes from the end goal
Search WWH ::




Custom Search