Cost-Benefit Analysis

Hello all, and thanks for continuing to follow my coding journey.

Today I’m here to report to you what I’ve learned while attempting to complete ex43.py from Zed Shaw’s ‘Learn Python the Hard Way’.

Zed recommended researching the different components of the code before beginning to write it, and so you can find my initial research notes here.

While completing my research I ended up following a nested dictionary model for the mapping of the text-based game. Unfortunately by doing so, I invested a lot of time into a mapping model that was incompatible with the original assignment from the book, which was attempting to stress the use of classes/inheritance in the context of a text-based adventure.

Thus I’ve decided to stop my work on this assignment, but to share with you my main takeaways in the process of trying to write the code, as I see this as a more productive use of time. Here is my scratch code for ex43.py.

(1) In Zed’s skeleton code, his Engine function was used to move the character from one scene to the next. This is a useful theoretical model, and something I will try to implement in further programs.

(2) When designing a text-based adventure using individual scenes as sub-classes and having a parent class that is a general Scene, you don’t need to have the prompt function asking the player what to do in the Engine Class. Instead you should provide prompts within each scene that are specific to that scene. Since most of the information I was attempting to extract from my prompt function in the Engine class was based on character information (i.e. location, items etc.) I probably should have just included the ability to call the Character class within each of the scenes.

(3) To create an interactive map, instead of using classes you can also use a nested dictionary! This is what I ended up using, and why it became too complicated to write the code in a format that also implemented classes for scenes. Here is the video that taught me how to use a nested dictionary for a map. In my Character class, since I knew I wanted the player to start at ‘b2’, I set the default Character attribute location to ‘b2’. I then set up a function within the Character class (char move), that prompts the user for the direction they want to move. This response is stored in an assignment, and leads to an If/then statement. Then another assignment is set up, that references the nested dictionary like so:

destination = zone_map[self.location] [UP]

where zone_map is the dictionary, self.location is the Character attribute which translates into a key within the dictionary, and [UP] is one of the keys within the nested portion of the dictionary that returns its value, in this case ‘a2’.

In a separate function I then redefined the Character’s location attribute as ‘destination’, and returned to the Engine class. Now the player is technically in a different location, yay!

(4) Another thing I learned in attempting this assignment, was the use of a while loop to only accept valid responses. I think this makes the game play a lot better for the user, because previously I was including multiple choice options for each user input. To accomplish this format, you need to provide all of the acceptable responses in a list before the while loop, and follow the loop with another assignment prompt. This should be below the initial assignment prompt, and following the while loop should be a list of if then statements that provide the functionality for when a correct response is given.

(5) Something I picked up from Zork, was the use of an instruction function/method, which provides the user with all of the accepted commands. This once again, allows the game play to continue without explicitly prompting the user for specific options.

(6) As you can see at the top of my scratch code, I did find an example for an Item class that could be combined with an inventory attribute in the character class to provide an inventory for our player. Something I learned was setting the self.inventory attribute equal to {} for the Character class allows you to continually fill up the characters inventory throughout the game play.

(7) Coming into this project I was confused about when to include attributes within the __init__() method of classes, and when to simply list them below the method’s signature (e.g. def __init__(self): self.name = name … self.hp = hp). From what I understand, you only need to include the arguments within the init parentheses if when you instantiate the class you want for those attributes to be specified. Otherwise if you want them to be affiliated to the class, you can simply include them after the init signature.

(8) Within the __init__() constructor, I found that non-default arguments must precede default arguments (e.g. __init__(self, name, hp=10) is correct however __init__(self, hp=10, name) is not).

(9) Using other people’s code as a basis for a particular functionality in your code is very useful HOWEVER, it is much easier to edit/manipulate code that you created from scratch as you understand every component. It’s best to take as little as possible from others and then use it to complete code that you have already worked on.

(10) super(Subclass, self).__init__() is really python 2 syntax (which can be used in python 3), however I found it easier and more useful to implement super().__init(), which is the updated python 3 syntax for the same functionality.

Thanks for reading!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s