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.
New up front features:
- The speed of movement is used to seed the grid with possible destinations.
- Only passable squares are included as destinations.
- The “walking cost” to each square is calculated from the starting point and displayed on screen.
This sets us up for the next feature: setting waypoints. Knowing the cost of moving to each square on the grid let’s us backtrack to the starting point while navigating around obstacles.
I did discover some no-so-great “features” of Unity. All the classes in Unity are derived from the MonoBehavior class. These classes can not be instantiated with a new statement, but instead must added as components. It’s a little cumbersome, but not fatal.
Unfortunately, I needed to write a few enumerators for things like the grid squares. This could probably have been done by adding components, but that would have been convoluted at best. Changing the enumerated classes to structs worked like a charm and is likely a more efficient method.
I also had the chance to work with some UI text for the first time, which will be particularly useful very soon.
unity-movement-count from C. Lewis Pinder on Vimeo.