No. Generate neighbors from coordinates when needed. The graph is implicit in the movement rule. A graph model and a stored adjacency list are not the same thing.

def neighbors(row, col, rows, cols):
    for dr, dc in [(1, 0), (-1, 0), (0, 1), (0, -1)]:
        nr, nc = row + dr, col + dc
        if 0 <= nr < rows and 0 <= nc < cols:
            yield nr, nc

assert set(neighbors(0, 0, 2, 3)) == {(1, 0), (0, 1)}

Before choosing a traversal, answer three modeling questions. What information makes a vertex distinct? Are moves one-way or two-way? Do edges have equal cost, varying cost, or no relevant cost?

A finite undirected tree is connected and has no cycles, hence a unique simple path between any pair of vertices. General graphs can have cycles, disconnected pieces, and several paths to one vertex. Those differences change visitation rules.

For an adjacency-list graph, storing all vertices and edges costs O(V+E) space. A four-neighbor grid has at most four outgoing moves per square, so enumerating its full adjacency also has linear size in the number of cells. An implicit graph avoids prebuilding edges; it does not eliminate the work of searching reachable states.

Recognition signal: if you can describe a legal “next situation,” a graph model may exist even when the problem never says “graph.” This does not mean BFS is automatically appropriate; the answer’s objective and move costs still matter.

Analogy limit: a vertex is not always a physical place. Merging all fuel levels at one location can create a graph that solves the wrong problem.

Not generally. Which doors have locked changes legal future moves. You may need additional state, potentially a much larger set of situations than physical rooms.