I've cleared a major hurdle in development as of this week! The new movement system is now in place, which dynamically sets valid directions from each point on the game board. That means I can use events in the game to trigger changes to the maze – for ex. when you run into Dark PacMan, I may have maze tiles disappear, and make the open space navigable for you (PacMan) AND the ghosts.

Originally, all movement nodes had to be set manually, in the game inspector in Unity, which not only was tedious, it was also static. So if I wanted to make a different maze, I'd have to manually input all the nodes again. And to have any kind of open space, it would mean 4 neighbors per node, across hundreds of nodes, just to see if I liked the layout or not. Now I can design on the fly more easily. But more importantly, the game will have a new element when you play it.

Here's a rough breakdown of the process:

1. Set possible directions – this is hard-coded to the vector values of Up, Down, Left, Right. The only possible directions in this game.
2. Get possible neighbors – now, based on those 4 directions, we look in each dir & check for a node 1 unit away. If there is one, it's a possible neighbor. However, if the node is disabled for movement, it won't count. The fact that we may or may not get a "hit" on each element of the array (which is a size of 4) means there are potentially null values in the array. Which is why we need another step to set the actual neighbors.
3. Set neighbors – take each valid neighbor from the prev array, and put them in a new array of the appropriate size.
4. Set valid directions – looking at each neighbor, get the direction it faces. This becomes an array also, and ultimately controls whether PacMan or any other moving character can go a certain direction.

So there's quite a bit that goes into simple things like player movment, as I've learned! I know Unity has plenty of built-in or example movement systems available, but I wanted to gain the experience of designing one, and not just that, but one that's custom-built for this game.

There were also some exceptions I made for special movement cases. Portals are not neighbors, but we have to treat them that way in order for the portal translation to work. So portals are ignored in the script, except for step 4, and I still manually link them together. Then there are ghost houses, which are 3 units away instead of 1, and in that special case I wrote the script to check again 3 units away for a neighbor. It might not be the cleanest code in this case, but it takes care of the job.