Other ways to make ex45 engine and map classes more efficient?

Python
#1

I want to know how we can make the classes in ex45 of LPTHW responsible for creating and initializing the game’s scenes in different ways.Can we make the classes smaller or more simple?Because I find it hard to understand the structure used in the book.Here are the 2 classes I am talking about:

class Engine(object):
    def __init__(self,scene_map):
        self.scene_map=scene_map
    def play(self):
        current_scene=self.scene_map.opening_scene()

        while True:
            print "\n-------"
            next_scene_name=current_scene.enter()
            current_scene=self.scene_map.next_scene(next_scene_name)

And:

class Map(object):
    scenes={'central_corridor':CentralCorridor(),
            'laser_weapon_armoury':LaserWeaponArmoury(),
            'the_bridge':TheBridge(),
            'escape_pod':EscapePod(),
            'death':Death()
            }
    def __init__(self,start_scene):
        self.start_scene=start_scene
    def next_scene(self,scene_name):
        return Map.scenes.get(scene_name)
    def opening_scene(self):
        return self.next_scene(self.start_scene)

a_map=Map('laser_weapon_armoury')
a_game=Engine(a_map)
a_game.play()
#2

I made this mistake but I want to know how to fix it.When I copy pasted this code, the code lost its original indentation.How can I copy/paste without losing indentation?Sorry, if this causes any major inconvenience.

#3

Not a problem, I fixed the indentation for you. Just indent 4 spaces and it’ll treat it like a code block or “literal block”.

Now, to answer your question, if you are looking at this code and asking how you can simplify it so that you don’t have to understand it, then that’s not really going to work. In fact, that’s how people get into deep trouble when they’re trying to refactor or fix code. First you have to try to understand it and then you can attempt to simplify it.

Here’s how you should break this down so you can understand it:

  1. List out all the things you don’t understand in this code. You can do each line, or symbols, each thing you don’t understand in a list.
  2. Go to the list of characters I have in the book (I forget which exercise) and match them with any that you have on your list. So, for example, if you don’t know what { and } do then rememorize those.
  3. Then, for each line where you have no idea what’s going on, the problem is going to be that you’re attempting to stare at the code and figure it out. This doesn’t work at your level so you have to print out variables to find out what’s going on. It’s all about the variables and code paths.
  4. Before this line you don’t understand, print out every variable with a debug print like:
    print(">>> before current_scene enter: next_scene_name=", next_scene_name)
  5. Then run it and see if that explains what’s going on. If not then start “branching out”, meaning you start printing other variables involved (current_scene), and new places (top of the while loop, bottom of the while loop).
  6. Keep running it and taking notes and study how the variables change. It’s always the variables and how they change as the code flows that tells you what’s going on.
  7. Then if you still can’t figure it out, it’s time to branch out further by going into functions that are being called and the variables going in and coming out of those. In this case, you then put a print(">>>") at the top of scene_map.next_scene, and at the bottom right before the return, tracing what goes in and what comes out. Then you repeat this whole process for that one function and any lines you don’t understand in there.

The moto is “print print print!” You can’t understand what’s going on by just staring at the code. I can’t even do that. I always print things out to figure out what’s wrong if I don’t quickly see an obvious reason. Since you’re just starting out, you don’t have the training that shows you obvious errors. Technically everything you see will seem like an error since you aren’t trained yet. That means you have to immediately jump to printing variables out until you’ve done so much debug printing that you begin to think the way a computer does.

The other thing to keep in mind is that many times people see a problem on one line and then focus entirely on that one line. That’s why I tell you to branch out if you don’t see it on the one line you’re working on. Many times a problem may appear on one line, but it’s cause is from several other lines in another function or module.

1 Like
#4

Thanks,I’ll try that. But by the way,when you indented the code, did you just add four space at the beginning before “class” and then the rest got indented itself??Or am I supposed to indent the whole thing line by line cause that is going to become tedious.

#5

I add 4 spaces to the front of every line. If you hit the … on the post you can select Edit and see the raw post to figure it out. An alternative is to just put it in github’s gist https://gist.github.com/

1 Like