Initial implementation of the Player class

This includes some exposition on the game design and compartmentalisation.

1 files changed, 70 insertions, 0 deletions

diff --git a/maze.py b/maze.py
new file mode 100644
index 0000000..380ed9c
--- /dev/null
+++ b/maze.py
@@ -0,0 +1,70 @@
+#!/usr/bin/python
+# coding=utf-8
+"""A simple command-line maze game.
+
+This game is designed as a tutorial of how to break a problem down into
+components and tackle each individually. The game itself is pretty boring and
+lacks a nice interface.
+
+In the game, there is a single player stuck in a randomly-generated maze. The
+player only knows their name, current location, and the paths available to them
+from their current location. The graph is represented as a network of links
+between nodes, stored as a dictionary mapping a node to a list of nodes it's
+linked to. Every link is directional but the graph is symmetric. Cycles and
+reflexive links are permitted. All nodes are addressed as a tuple giving their
+X and Y position on an integer grid of given size where (0, 0) is the start
+node and (size, size) is the finish node. This is a standard way to represent
+a graph in a program.
+
+The first task is to decide how to split the problem up into classes. One
+approach is to have four classes:
+ - Player, representing the player
+ - Maze, storing the maze
+ - Node, representing a single node in the maze
+ - MazeGame, encapsulating the game as a whole
+However, having a class to represent each Node is wasteful. Each node has to
+store a pair of coordinates, and there are no methods which need to be executed
+on a node. Therefore, it would save memory to implement nodes as tuples.
+
+Hence, the following classes are needed:
+ - Player
+ - Maze
+ - MazeGame
+
+We can start by implementing Player, since it's the easiest class. It needs to
+store the player's name and current location, and needs to allow the location
+to be updated.
+
+Note that the Player code doesn't check whether the player's location is a
+valid node in the maze; to do so would break the compartmentalisation between
+Maze and Player. It is better for this validation to be done in MazeGame, which
+controls both the Maze and the Player.
+"""
+
+
+class Player(object):
+    """A player in the game.
+
+    This stores the player's current location as an (X, Y) coordinate tuple,
+    and also the player's name. The player's name cannot be changed after
+    construction.
+    """
+    def __init__(self, name):
+        self._name = name
+        self._location = (0, 0)
+
+    def get_location(self):
+        """Get the player's current location."""
+        return self._location
+
+    def set_location(self, location):
+        """Set the player's current location."""
+        self._location = location
+
+    location = property(get_location, set_location)
+
+    def get_name(self):
+        """Get the player's name."""
+        return self._name
+
+    name = property(get_name)