From aecad441a0066765bb3e8bb90bf18a01c9b24559 Mon Sep 17 00:00:00 2001 From: Philip Withnall Date: Mon, 26 Aug 2013 18:16:15 +0000 Subject: Initial implementation of the Player class This includes some exposition on the game design and compartmentalisation. --- 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) -- cgit v0.9.1