About 'Running Manual Tests'!

Unity Courses Talk
, ,
#1

In this video (objectives)…

  1. Use our isRunning state
  2. Log out what we're queueing
  3. Check pathfinding across whole grid.

After watching (learning outcomes)…

Use systematic manual testing to help write software.

(Unique Video Reference: 15_RR_CU2)

We would love to know…

  • What you found good about this lecture?
  • What we could do better?

Remember that you can reply to this topic, or create a new topic. The easiest way to create a new topic is to follow the link in Resources. That way the topic will…

  • Be in the correct forum (for the course).
  • Be in the right sub-forum (for the section)
  • Have the correct lecture tag.

Enjoy your stay in our thriving community!

#2

I would argue that the IsExplored flag should not be on the Waypoint. IsExplored is really only for the PathFinder. I think a much better way would be to add a dictionary of explored waypoints to PathFinder and add Waypoints to it as you go, and then do a ContainsKey against it to decide if the Waypoint has been explored already. This keeps the pathfinding in the PathFinder class and out of the Waypoint class.

#3

This also worked well when doing the breadcrumbs. I was able to use this dictionary to record the waypoint I came from to reconstruct the path:

Dictionary<Waypoint, Waypoint> _path = new Dictionary<Waypoint, Waypoint>();

… enqueing blocks… we no longer need to check the queue since we check _path instead

if (!_path.ContainsKey(dest)) // || _queue.Contains(dest))
{
    print("Visiting " + dest.GridPosition + " from " + pos.GridPosition);
    dest.SetTopColor(Color.gray);
    _path[dest] = pos; 
    _queue.Enqueue(dest);
}

… reconstruct the path …

Waypoint w = EndBlock;
while (w != StartBlock)
{
    print(w);
    w = _path[w];
}

This kept path finding completely in the PathFinder. No mods to Waypoint needed.
Maybe this would be more confusing, but it avoid using anything you haven’t already covered and it does a better job of separating concerns. :slight_smile:

#4

Small comment on the original code in the lecture - maybe it gets fixed later, not sure yet.

I don’t like the try/catch around the entirety of QueueNewNeighbours as it was only intended to catch a failure of grid[]. This can cause problems for students who make a logical error in QueueNewNeighbours and end up ignoring an exception they weren’t expecting.

One way to fix this is to specifically catch the KeyNotFound exception.

try
{
    neighbour = grid[neighbourCoordinates];
}
catch (KeyNotFoundException) { }

Unfortunately C# doesn’t support a try-catch-else like Python does, so an alternative might be:

Waypoint neighbour;
try
{
    neighbour = grid[neighbourCoordinates];
}
catch { }

if (neighbour)
{
    QueueNewNeighbours(neighbour);
}

Or just move the try/catch into QueueNewNeighbours since the Indexer is there anyway.

Privacy & Terms