I’ve wrapped up work on some other projects (The Borderlands and Apollo Zero) and I’m back at the keyboard. When we last left off, I’d just finished putting together a small level based on the Hirst Arts gothic dungeon. It was good to get some hands-on (even if they were virtual hands) experience building a dungeon based on practical models. However, as often happens, I ran into some issues with my implementation and took a different approach.

On Prototypes
Everyone certainly has their own approach to prototyping, but for me—in the early stages—it’s involves a great deal of create, tweak, and restart. At each stage, I start anew. Borrowing pieces of code that worked, but willing to toss away whole pieces that don’t quite fit the bill. Such was the case for this stage of the prototype. read more

Pathfinding is finally working on the map. After spending some time with a recursive function that just didn’t want to return, I have a functioning shortest-path algorithm implemented. Surprising, I had the most difficulty with moving the miniature off the grid. You’ll notice in the video that not only is it successfully finding its way around the hole in the floor, but you can also drag the miniature over the hole and it solves the path as soon as it’s on the other side.

I’ve spent some time considering different methods of movement, in particular, setting waypoints and evaluating movement at the end of the turn. After picking up and moving the mini around the map countless times, I’m currently inclined to not do waypoints. Picking up the mini and setting it down until all the moves are expended feels the most natural to me, the most like moving a real miniature. If the player really has made a mistake and needs to reset the move, the GM could undo the action and allow the player to redo some or all of the move. read more

I picked up some VFX work, so I’ve been away from the project for a few days. Now I’m back and working on movement again. I’ve made quite a few changes behind the scenes and added some features up front.

On the back-end, the grid and movement have been completely abstracted to separate classes with support for arbitrary grid size and distance. I’ve also added a main game loop rather than lazily attaching the logic to the camera which is what I had done. read more

I 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?

It was suggested that I try picking up the miniature to move it (Thanks, Jim). I liked the idea of a more natural feel. I’m trying to keep this as tactile as possible.

I’ve made some modifications to the movement code and now we have a lift and carry interface. It does feel better, especially with the static camera.

Unity Lift Movement from C. Lewis Pinder on Vimeo.

There are few things left to do for this style of movement:

1. Move the camera as the miniature nears the edge of the screen.
2. Switch out some of the hard-coded values for a more programmatic approach.
3. Add terrain with height. This will certainly require some extra work, e.g, stairs and slopes.