Truthfully, some of these updates were fixed in a ninja edit with version 1.0, but I'm super stoked to have solved my biggest issue (which I'll get to below), so I'm going to include all these updates here.

Firstly, levels were not restarting correctly after a Game Over state. Not just levels, but the number of pellets the player had consumed was not being reset to 0, along with each player score being maintained and carried over through Game Over to restarting. The levels and score were fixed simply by adding a few lines to the Start() function of the GameBoard class:

void Start()     
{         
    playerOneScore = 0;         
    playerTwoScore = 0;          
    playerOneLevel = 1;         
    playerTwoLevel = 1;
}

The GameMenu class (which is responsible for running the main menu screen) handles tracking the number of pellets each player consumed, so resetting this value was as simple as adding the following code to that Start() function:

private void Start()     
{         
    playerOnePelletsConsumed = 0;         
    playerOnePelletsConsumed = 0;          
    BlinkChevronOff();     
}

You'll note the addition of a BlinkChevronOff() function. This acts to initiate the two functions that will invoke each other in order to flash the selector icon on the main menu screen. This was done in a similar manner to the title of "Tone-tris". Interestingly, much of PacMan's code features IEnumerator methods to pace out certain sequences such as death and advancing levels after clearing the board. I wasn't able to come up with a quick sequence of IEnumerators that would flash the selector icon, but that's not to say it wouldn't be possible. More that I just don't know how. As such, I reused my previous method of using functions to invoke each other, as seen below:

void BlinkChevronOff()     
{         
    playerSelector.GetComponent<text>().enabled = false;         
    Invoke("BlinkChevronOn", chevronBlinkTime);     
}      
void BlinkChevronOn()     
{         
    playerSelector.GetComponent<text>().enabled = true;         
    Invoke("BlinkChevronOff", chevronBlinkTime);     
}

A funny thing happened while I was writing the above code. You'll see I've created a variable titled chevronBlinkTime to set the length of time before each function invokes the other. I created this variable, and made it public, in order to be able to manipulate it through Unity's inspector window. Primarily, this allowed me to adjust the value until I got the look I was going for. Secondarily, I discovered that setting the chevronBlinkTime to less than a tenth of second resulted in an effect that resembled a rolling shutter effect. It rather reminded of the classic arcade look. While it's not on my list of goals for this project, it might be fun to make every sprite onscreen flash absurdly fast in order to simulate the look of some of the classic machines.

Finally, my largest bug was PacMan's ability to enter the ghost house. This took a lot of consideration, bunches of extraneous coding, and was quickly revealed to be a simple fix. It seems likely that the player won't by default choose for PacMan to enter the ghost house, but I wanted to ensure that no matter what it would be an impossible request. To do so, I utilized the existing Move() method in the PacMan class. As part of this method, we check if PacMan has over shot his target node (pellet at an intersection). It is within this if statement that we can apply the portal functionality, as well as the majority of every other direction change request or movement. For a whole day I struggled with adding code that would prevent PacMan from being able to enter the ghost house. In the end, only a simple function was required:

void Move()     
{
    Node ghostHouseLeft = GameObject.Find("GhostHouseLeft").GetComponent<node>();         
    Node ghostHouseRight = GameObject.Find("GhostHouseRight").GetComponent<node>();
    if (OverShotTarget())         
    {
        if(moveToNode == ghostHouseLeft || moveToNode == ghostHouseRight)                 
        {
            moveToNode = currentNode;                 
        }
    }
}

By inserting the above, PacMan is no longer able to enter the ghost house. Simple, really. Just took forever to get there. There is one downside to this solution. PacMan's animation does not stop when he encounters the barrier of the ghost house. Normally, when PacMan reaches the end of a string of nodes (meaning a wall), his animation stops and he freezes in an idle state with a half-open mouth. Even when attempting to add a check to his animation state within the code above, or setting his direction to Vector2.zero, he refuses to halt animation. This is okay though, because (at least for now) the main issue has been addressed. I'm quite proud, to be honest.

These updates were a large finale for me regarding PacMan. While I still have a few details I'd like to address, they are mostly in relation to UI and quality of life. The core of the game is fully functioning, and for this I am satisfied. As such, while I want to return to PacMan to continue to tweak and improve, I will be moving on to another project. That doesn't mean I won't continue to be updating this project further, it just means (as with Tone-tris) that development isn't particularly active. I will come back and work on this game at future dates yet undetermined. The goal here is education, remember. So I will press forward to another project in hopes of learning more techniques; some of which I may be able to utilize when returning to Pac-Man. Still, I hope the above updates I have already added improve the overall quality of the game in your eyes, and everything works as smoothly as hoped.

Cheers,

-T