Waypoint movement with die rollI spent the morning re-factoring much of the movement code into a separate class, all the while giving some more thought on the final method for moving the miniature. I’ve been considering setting waypoints: picking up the miniature, moving it a distance, set it down, and then pick it up to move in another direction. This will let me keep the metaphor of lifting the miniature.

Then it occurred to me, what about traps? Let’s say there is a classic 10′ pit trap in the floor. We certainly need to make sure that the player is intending on crossing over that space and, of course, if the trap is sprung, the rest of the move is rendered moot. Traps aren’t the only thing we need to account for. Any number of different checks might need to be resolved before the planned movement can be executed. For example, a Rogue may attempt to move to a wall and then scale it. Or a Warrior might charge through a door, hoping to break it open.

Time for some Photoshop prototyping. The current method I’m considering is using arrows to indicate the movement between waypoints and a die-roll icon whenever a check is required. (The icon, of course, wouldn’t be displayed on the player’s map for hidden checks like traps). Once the move is committed, we evaluate it along the path. The waypoint methodology shouldn’t be too intrusive, I suspect that most practical movement will be in a straight or nearly straight path.

We’ll see how this survives contact with implementation. Anything else I’m overlooking?


2 Comments » for More on Moving
  1. PinderNET says:

    I like way points.

    This c/would allow for planning and then execution of simultaneous actions by multiple people without revealing the intent of each to the other.

  2. carl says:

    I’m definitely leaning towards waypoints. Simultaneous action opens up a whole different set of issues: “That’s my square!” “No, that’s my square!” and “The door was open before!”

Leave a Reply