The function depthFirstSearch in the file search.py suggests that you execute a few print statements to understand the world you are searching. When you run them you will get the following

print("Start:", problem.getStartState())  # => Start: (5, 5)
print("Is the start a goal?", problem.isGoalState(problem.getStartState())) # => Is the start a goal? False
print("Start's successors:", problem.getSuccessors(problem.getStartState())) # => Start's successors: [((5, 4), 'South', 1), ((4, 5), 'West', 1)]

The start state looks like this. As you can see, Pacman starts in position (5, 5); the goal is in position (0, 0), which is not the same as the start position; and Start's possible successors are South by one unit to (5, 4) and West by one unit to (4, 5). (See message below about the apparent interchanging of West and East.)

You can see the definition of the TinyMaze in the layouts directory. It is defined with alpha characters:

%%%%%%%
%    P%
% %%% %
%  %  %
%%   %%
%. %%%%
%%%%%%%

P is the start position;

. is the goal position;

% are walls

This information should help you get started writing your search functions. Post additional questions here on the Forum.

I believe, its because the board is created on the 2D plane with x and y coordinates that we are used to, positive y being North(up), negative y being South(down), positive x being East(right), and negative x being West(left) from a 3rd person pov. In tinyMazeSearch(problem) it just an example hard coded traversal for the tiny maze like the one you posted earlier, so to reach the goal the pacman only needs to go 

[s, s, w, s, w, w, s, w]

or i.e 

[down, down, left, down, left, left, down, left]

If you want the display to remain on the screen longer, insert 

input('Press "Enter" to continue.')

in game.py before 

self.display.finish()

on line 729.

Since the Project 1 assignment is fairly long, let's split it up over two weeks. The first week will be questions 1 - 4. The second week will be questions 5 - 8. We'll drop the assignment that requires that you read and explain the A* code.

Question 3 poses an interesting challenge.

The search agents themselves compute the cost of going east or west. You don't have to worry about that. But you do have to decide how to include that information in a priority.

One option is to add the new cost to the length of the current path. (That's what I did at first.) The problem with that is that the length of the path dominates, and one gets a BFS solution.

An alternative is to us the cost of the current step (computed by the agent and given to you) as the priority. But that generates something like a greedy search.

I eventually decided to use a tuple ( succ_cost, len(new_path) ) as a priority. This is very much like using the successor's cost as a priority, but if two costs are the same, it favors shorter paths. If you use this strategy, please be prepared to explain why it does what it does.