Where have I been

It’s been a while since I posted up my progress to this blog, mostly for two reasons;

1. I started Learn JavaScript The Hard Way and made reasonable progress through the first 19 exercises. This sister course of Zed’s follows a similar format so it was easy to adjust to.

2. I spent way to long planning and implementing my game, which in retrospect was limiting my learning and not delivering anything new. I will return to the game in due course so I can get an online version up for closure.

In the meantime, I’ve progressed to Learn More Python The Hard Way instead. This book compliments the original text and actually prompts you to use your existing knowledge to produce useful little projects. Perhaps more importantly, it also offer insight into developer behaviours, avoiding typical blockers, overcoming procrastination and general good-coding advice and habits.

...

Continuing on from my Python testing part 1 post I’ve been adding basic functions to my game in a simplistic and iterative style.

My Player class has some functions to view health and view inventory. I’ve also added very simple take and drop functions that just append or remove items to the inventory list that starts off empty.

class Player(object):                                                           
    """ Class object for a player of the game."""                               
    def __init__(self, health=100, inventory=[]):                               
    """ Create a player with full health and empty inventory."""            
        self.health = health                                                    
        self.inventory = inventory

    def take(self, i):                                                          
    """Enables an item to be taken / added to

As someone who is a big fan of Behaviour Driven Development (BDD) and Test-Driven Development (TDD) for robust and context specific development, I really need to ensure I am comfortable with a python test framework that I can have in my tool belt.

I started using Nose and Unittest initially but for me, Pytest’s simplicity and syntax is preferable. Considering that Pytest can detect and execute tests from these other frameworks anyway, there is not much to lose by me choosing Pytest at this time.

Pytest is pretty straight forward; import it, create a test function, add an assert statement.

import pytest

def test_simple_operator():
    assert a < b

Then run pytest from the command line.

$ pytest

I want to get practicing at writing little tests, writing a little pseudo code, fleshing it out with real code, then repeating the process in a way that is similar to the ‘red, green...

Inheritance. The word alone fills me with expectation and a sense that I can benefit from the hard graft of others! There will be some price to pay, lets call it an inheritance tax, but once I’ve paid that inevitable price, I can reap the rewards of my forefathers.

I like the idea of inheritance, and creating base classes that siblings inherit from. It fits in with my view of the world that certain objects have certain properties, whether they are aware of them or use them, or not. I can see how the use of inheritance can keep the code-base DRY, and control or mandate a data contract.

Base class

So I have an animal. It’s a generic class that has the properties species and voice, as most animals can be described in these terms.

class Animal(object):                                                           
    def __init__(self, species, voice):

Whilst I work through the different game elements and features I want to implement, I though I’d revisit the game engine from LPTHW.

To be honest, I’ve struggled here a bit. The first time I implemented the game engine I didn’t really understand what was happening. But the code worked and I understood that I could create a scene (including some game text and actions) and provide the next scene in the enter function’s return statement. So for this implementation I wanted to be sure I actually understood the mechanics of the engine when it ran.

Zed has already explained that the engine class hierarchy is ‘Map’, ‘Engine’ and ‘Scene’, with a number of scenes listed based on the room type. Within these classes there will be a number of functions performing actions, such as opening_scene or next_scene, that navigated through the map.

Scenes

So when I break it down, I start with a base...

Remember those old green-screen terminals that print a character at a time? They are really retro, keep in with the theme of my game and they were certainly present in the movie my game is modelled on.

I wanted to emulate this character typing effect on the Terminal to differentiate normal game mode from the computer in the story and to add some atmosphere to the game.

Capturing the text input, creating a list of the characters (using list(arg)) and using a time method was fairly easy. I’ve come across datetime methods before so I was pretty confident Python would have an equivalent.

import time

def print_terminal(str):         
    char = list(str)                                                                                                                                        

    for item in char:

The final sections of the LPTHW book, is to make a text-based game, similar to Zork. There are iterations in this process, from making a simple working shell and adding automated tests locally, through to fleshing out the game and integrating the final solution into a web framework for deployment online.

The first time I attempted creating the game, I made several big mistakes that I aim to avoid this time:

• I spent too long thinking about the game contents rather than structure
• I created a decision flow that was too complicated
• I didn’t draw the map out or keep referencing to it
• I changed the game as I had new ideas but did not consider impacts
• I tried to refactor parts of the game and add to it at the same time
• I didn’t commit to source control anywhere near enough

As a result, I failed…badly. But fortunately, failure provides an opportunity to learn, so I am much better prepared...

This blog is primarily….for me. But I am happy to share it with you too.

In September 2017, I signed up to Zed Shaw’s Learn Code: Live course to progress my programming skill set.

This blog is a learning aid for me. It is to review progress, remind myself how far I have come when I get stuck and demotivated, and also a valuable mechanism for problem solving, as writing the problem down often helps focus the mind on a solution. (This is a valuable learning from Zed).

So what have a learned so far?

Well, quite a lot really. Too much to labour in this post, but by way of a summary, the following has taken place over the last 8 months:

• Started and been working through Learn Python The Hard Way (LPTHW) exercises and videos
• Learned about basics of Python 3.6 and differences with Python 2.7
• Learned about data structures, code formatting, control flow, reading and writing files...