Skip navigation

Tag Archives: learn python the hard way

Ok, so I’m still working out the engine for Kleptos, my text adventure project, but I am almost finished. This means that the rest of it is going to go very quickly, and I could be finished relatively soon. I’m going out of town Friday through Sunday, so I miss out on a fair amount of time I could be coding, so I expect to be done sometime next week. Exciting.

So my content management system is pretty much finished. It basically runs like this: when the game opens, an object I called the Library reads a bunch of files in a directory system I created for the project. The files make up all of the content of the game (as opposed to its structure), from the introduction and back story, to the description of each room of the house that appear at the top of the screen, to lists of possible commands.

The files are read into the Library one of 4 ways, based on how I want the game to handle it:

  1. as a big old chunk of text
  2. as a list
  3. as a dictionary, with every other line being a key and and a string as an item
  4. as above, but the items are all lists containing strings

So, for example, a list of items in the game would look like this in the text file:

stab slice dice
lock unlock
light throw
drop throw

and would look like this, once Library has read it:

{"dagger":["stab","slice","dice}, "key":["lock","unlock"], "lamp":["light","throw"], "rock":["drop","throw"]}

From that point, it is a simple matter for the program to add and subtract words from the player’s vocabulary, depending on what his or her inventory contains at the moment. (E.g., you can only “stab” when you have the dagger.)

I was considering explaining some other aspects of the game, but it would take too long, and I’d like to wait until it’s all finished. I’ll say for right now that most of the game’s functionality is wrapped up in this system, where all the content is mapped out in text files, rather than in the code itself. I like the idea of keeping the two processes – composing the game and coding the game – separate. They are intertwined but nonetheless distinct.

I’m going make a point of posting more updates than usual as I get closer to my goal. I’d like to get some good practice in explaining what I’m doing – I can get tongue- (and finger-) tied trying to make it even barely comprehensible to other people, sometimes.

Happy coding, everyone!

I’ve been taking quite a long time to work on my current exercise in Learn Python the Hard Way – the assignment was to make a game in a week, and now it’s well over two weeks.

There are two perfectly good excuses and one somewhat dumb but awesome excuse.

The perfectly good excuse is that I’ve been feeling behind in my community college C++ class, so I decided to step up the amount of time I spend on it. It has paid off, as this evening I was confident enough to turn in a project a week early – there was simply nothing I could add to it (or take away, as Saint-Exupéry would say).

The second perfectly good excuse is that I am going to job interviews.

So, therefore, I am not behind on my Python project, because I am lazy.

I could be behind on it, however, because I’m trying to do too much – and that is the somewhat dumb but awesome reason: I am trying to do a lot in my life, including a lot with this program. I am not writing out the project according to Zed A. Shaw’s example – I’m designing a full-on Interactive Fiction Engine – or at least the rudiments of one. I have a full structure, that is. I don’t know if it would be portable for other OSes or helpful for other coders – but – the point is – I am making a fairly complicated game from scratch. Go me!

So while I did very little last week, I’ve been making a point of getting an hour in every day this week – beginning before dawn. Tomorrow I have a little extra time in the morning, so I will be doubling that.

So this game consists of two big chunks to design: the game engine (how it all works) and the game flow (how the story / objects / actions all fit together). I’ve designed it so they’re pretty distinct components, and I am almost finished with the engine (I can feel it!). So hopefully next week I will just be working on game flow and a few extra tweaks to make the game the beautiful thing I would like it to be (with such amazing features as an ascii art skull for the death screen).

I will probably have a little bit to say once the project is done, but, for the most part, this process is not opening up any existential quandaries in my mind: it’s coming together nicely, if a bit slowly for the reasons above.

Coding is fun.

I want to begin recording my thoughts and misadventures as I go about teaching myself how to program. I would like to share my curriculum of self-study, once it’s finished. Every day, it seems, I’m getting more and more ideas about what to put into it to make it function. It’s a lot. I’m going to divide my time between general programming languages, web development, math pertinent to the topic (especially algorithm design), operating systems (mostly Linux), network and server administration and finally – which is an entire subject unto itself – electronics and basics of computer engineering. This is, perhaps, a lifetime curriculum. Maybe it will take multiple lifetimes. We’ll see.

But right now, going at my steady tortoise-pace (which I hope will help me across the finish line) I’m studying two languages: Python and C++. I probably won’t be talking about C++ for a while, because I’m studying it as part of a college course which is going relatively slow for me.

My main text right now is Zed A. Shaw’s book, Learn Python the Hard Way.  From one perspective, beginning this book after finishing Zelle’s Python Programming was a step backward. I’ve been reading lessons about many of the things I’ve learned before – all the basic stuff, like printing, loops, decision structures and classes. There are a few functions and concepts that Shaw introduces that simply don’t appear in Zelle’s book, such as argument variables. If that were the only advantage, it would not have been a good use of my type. I’m finding it invaluable, though, for two important reasons:

1. Zelle’s book uses Python 3, Shaw uses Python 2. The two are different enough for starting over to be helpful for me to learn the differences.

2. Shaw is an outstanding teacher. Sure, he has a different aim than Zelle – Zelle is an academic who is committed to developing a very thorough, solid introduction to the concepts of computer science, where Zed is trying to provide a quick, practical guide to the realities of programming.

But it’s more than that. Shaw has helped me learn how to learn. And this is coming from somebody who dropped out of high school and attended a bizarre liberal arts college because he cynically believed (and still tends to believe) that nobody knows how to teach anything. Zed helps me in two ways.

First is the way the book is structured and the scope of the exercises, divided between daily lessons and week-long “missions” (my term, not his), where he asks you to devote yourself, single-mindedly to one purpose, whether its to design a program, memorize symbols or expressions, or spend time exploring the internet to read code. Everything weaves together nicely; he obviously took care to decide what is important to simply practice, what is important to simply gloss over and what is necessary to etch into your skull with a diamond pen.

This leads into the second great thing about the book: Shaw’s tone, his comments, his attitude. Though a bit cynical (I can often feel a restrained anger toward the missteps of his predecessors and peers), it is infinitely helpful. In the process of steering the reader away from unhelpful trends out there in the forum of computer science, he provides an example to the reader of how to be wary and circumspect about the different opinions out there – an attitude that will help anyone to be more focused, to be more skilled, to be excellent. As an illustration, in Exercise 34, he warns readers not to bother reading about Edsger Dijkstra’s opinions on cardinality – essentially saying that this topic is not worth the time of a beginning programmer (also, that Dijkstra’s opinion is not worth very much, but I have no way of judging that). Not that I was about to go out and read anything by Dijkstra, but it’s good to hear from an instructor what is worth my time for now and what isn’t.

In the end, I like this book, because I feel confident that I am being guided toward proficiency. None of the particular points and warnings are, if taken generally, anything new to me (how to be circumspect, how to avoid pointless arguments, how to memorize a list of symbols), but this book fits them all together in a beautiful whole.

I’m just over halfway finished, currently working on a week-long mission project. The assignment was to write a simple text adventure. For some reason, I’ve decided to go overboard: I’ve created a function that has the text print across the screen, character-by-character instead of string by string; and I’ve added a whole slew of Nintendo-era sound effects to a graphics-less game. Perhaps this game will become the subject of a future article on “feature-creep,” but, for the time being, I’m having fun.

As a final note, Shaw has created a site called Learn Code the Hard Way, as a follow up to the success of the Python book. As far as I know, only the Python and Ruby versions are complete; he’s working on a handful more and is now offering online courses. I’m curious to see how his teaching endeavors will develop. But, for the time being, back to the Python mines.