Skip navigation

Tag Archives: python

Here is a new version of Kleptos, sans one debilitating typo.

Advertisements

It’s ready: the first draft of Kleptos.

After trying to wrangle github for a while and failing, I decided to just host it at mediafire. The link is here.

You will need Python 2.7+ in order to run it. If you are using a terminal, open the terminal in the unzipped folder and run the main file, kleptos.py. If you are using IDLE or something similar, just make sure that it can find the kleptos.py file – kleptos.py knows where to find everyone else.

I have not tested it on anything but Linux – though it should work on Windows. Please comment if you’re having a problem.

So assuming it works for you, tell me what you think. If you are a code reader, let me know – though keep in mind that this is my rough draft, and I’ll be reading and editing (and adding better comments) over the course of this next week. Suggestions will be welcome.

Even if I accomplish nothing more, it feels great to be able to move forward. It will be good to get back on track with my curriculum, though working on this project has been educational like cramming keywords into my brain could never be. Coding is art as much as science, and practice is worth its weight in gold. Enjoy, everyone!

I’m not totally finished, but I feel a big relief: I have finished all of my planned features and actions for the game. Tomorrow will be testing, debugging, refining and commenting, and I will conclude by uploading it all onto github.

I won’t be 100% finished – I’m going to print out all the code on Monday and edit it like a manuscript. So next week I’ll be reviewing it piece by piece. Your comments and criticism would be most welcome at that point, too – keeping in mind that this is more of a prototype and exercise than an actual, complete game.

That’ll be it for now. I’ll be back tomorrow hopefully with a finished draft!

Well, I admit I was envisioning today’s post being written while sending off yesterday’s. It was inevitable: I have spent all morning tweaking the game engine further.

After around 30 minutes of planning the flow of the game, I realized that the engine, while finished, was simply not flexible enough to make even the 1/10th interesting game I was planning. You would have been only interacting with doors and objects in your inventory that open the doors (keys, prybars, etc.). I did not expect the game to be complicated, but that is too lame.

So, last night, I began by making objects more complicated: you can turn them on or off. And, because my engine previously allowed only one game-altering action per command, this morning I decided to upgrade it, so now you can make an infinite amount of changes per action.

Here’s an example.

Using my engine, the game designer (who is also me for this game) writes out all the possible commands combined with a string of text describing the results and code that tells the program how the action affects the game – all written in a specially dedicated text file according to special formatting determined by the coder (me again) in the definition Library class.

In the first area, the thief needs to place coins in the outstretched hand of a duplicitous slave in order to get into the house (this is the second thing you do, and it is explained in the intro, so this is not a spoiler). Before this morning, the entry in the design document looked like this:


pay hand
You spit out the coins, wipe them on your exomis, and give them to the outstretched hand. The hand disappears, and the door creaks open slowly.|unlockRoom01#


(Yes, people in ancient Greece kept coins in their mouths. An exomis is a male toga-like garment. I am an ancient history nerd – so sue me.)

So the Library knows how to read this and chop it up nice and good for the main program, which would know how to run it. “unlockRoom01#” means the player now can enter the appropriate command (“enter house”) to go to the next room – whose reference code happens to be “01.” All done, right?

Wrong! There are three big problems with this version:

  1. You still have the coins after making the transaction.
  2. You can still do things to the door which you shouldn’t be able to.
  3. The hand is still hanging in the air. That’s just weird.


So I needed to allow multiple results to a single action. This did not prove too difficult, though it took a little bit of tweaking (especially with Mr. Library).

The result is now this:


pay hand
You spit out the coins, wipe them on your exomis, and give them to the outstretched hand. The hand disappears, and the door creaks open slowly.
unlockRoom01# loseItem00# deactivateObject00# deactivateObject01#
#This is a blank line in the actual document


So, as you can see, there are two large changes: actions are on a separate line now, and there can be multiple actions per command (separated by a space). A small change is the empty line at the end, which I added to make the document more readable. So now, when you type “pay hand,” you not only unlock the next room, you lose your coins, and the hand and the door are no longer usable objects.

The perfectionist in me laments that it would be better if the door were not “removed” from the field of play. I might tweak that, but it’s finally entering the territory where it’s an acceptable omission. I need to take time into consideration. We’ll see where I end up next…

Quick update: I finally finished the game engine for Kleptos! Celebration!

I’m now going to be putting together the flow of the actual game (events, puzzles, items, etc.). It’s going to be ridiculously simple compared to the effort that went into making the game work – I have about a dozen really easy puzzles planned. Naturally, I will continue to tweak the engine as I begin the content phase.

Although Kleptos is not going to be very much, in the end, I will have had practice building a framework that I could either immediately apply to more complicated games (say, a fuller Kleptos where this is only the first level) or further refine as a learn how to apply it to other genres – other text-based games (such as roguelikes) or even graphics-based games.

I’m sure that existing engines/libraries, such as pygame and flixel, can do a lot more: I’m not celebrating having inventing the wheel. But it’s good to know I can work through problems like this. Who knows? Maybe I might be able to contribute something to the game development world in the future.

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:


dagger
stab slice dice
key
lock unlock
lamp
light throw
rock
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.

So here is where I begin to report the little lessons I learn while studying to be a programmer.

This first post is not so fresh in my mind – I’m describing something I worked on roughly a month ago as an exercise in Zelle’s book. But my notes are pretty clear.

The project was pretty simple: choose a card game, design a program in python for playing it, use a simple gui (I used a modification of Tkinter supplied by Zelle), include a splash screen. It was an extensive practice in object-oriented design – so the point was to make good use of classes. (For those who don’t know, OOD is essentially writing chunks of code that can be recalled by a name so you can play around with sticking big chunks of code together like legos instead of writing line after line of the same little details over and over.)

And I did make good use of classes. With one big mistake.

So for those familiar with Blackjack, you have a few actions you can choose from each turn. Mostly, that’s going to be hitting (getting a new card) or standing (ending your turn). Most of blackjack consists of these two things. Because most of the game is these two things, I wrote the program around them. I thought about the other options for only a second. I only thought about doubling down, which is a special kind of hitting and standing that effects your wager, and nothing else. So, no problem.

Except there’s this other important aspect of the game: splitting. I thought I could just “cram it in” like doubling down. No need to spend too much time figuring it out.

This was the mistake. You see, splitting requires you to play with two hands (at least four cards). I had enough forsight to leave enough room in the gui for two hands. So that worked out. There is a minor problem there, because sometimes you can split a split hand (depending on house rules), which means I would need to set up for three hands. I decided it was not worth thinking about. This was just an exercise in a textbook, it needed to be very good, with a lot of effort put in, but not perfect. I decided this house would allow only one split. Fine.

The problem was in coding. It became a nightmare, figuring out how to redesign the program to get input from the user when it was a split. I won’t go into the details. I will say that I spent about 8 hours working on this, and at least 4 of them were trying to get splits to work.

What was the problem? I discounted splits because they are not normal. They occur maybe 5% of the time, at most. I made the mistake of thinking that, since this happened 5% of the time, it warranted 5% of my attention. It warranted more, and it got its attention with a vengeance.

How could I have done better? Spent time mapping out options and observing patterns. I thought that, since I understand blackjack pretty well, and I even coded a primitive version of the same thing a few weeks prior, I could just breeze through. What I didn’t realize was how object oriented programming requires you to step up your planning efforts. You need to spend the time figuring out just what is an object – just what are the essential components of the program – and exactly how everything fits together.

If I had planned this game out, taken the time to map everything in a flow chart or something similar, I would have realized that it would have been easier to make a “normal” hand a simpler version of a “split” hand than it was to make a “split” hand a more complicated version of a “normal” hand. I should have expanded my definition of what a hand is to include a split hand. What I was doing was kind of looking at a split hand as an afterthought – a particular tweaking of a normal hand – and therefore not worth thinking about too much until I got to it.

A more general definition of a hand, based on a more careful perspective, would have allowed me to include the shared characteristics of both normal and split hands, saving me the step of redesigning everything towards the end of the process and making the whole process faster and easier.

You’re probably detecting a kind of moral lesson out of this. And I think there definitely is one. In any situation, it’s better to accept all cases and account for them – whether its at home, in politics, in your day to day affairs of life – than it is to marginalize. If you want to see beauty and some kind of order in your life, you have to make sure you are making relevant distinctions. If not, you risk either rejecting something valuable or neglecting something significant.

See, programming has a lot to teach. More to come.

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.

(Note: this review refers to the Second Edition of the book.)

Last July I decided to study computing in earnest, and I wanted to find a good textbook to serve as a good, solid introduction to the fundamentals of the science. But I wanted to also learn some practical skills while learning more abstract concepts. Google searches on the subject led me to the blog Programming Zen, whose author wrote an article about how to get into computing. He said that beginners should make their entry with the Python language, and that John Zelle’s book, Python Programming: An Introduction to Computer Science, was the best way to start.

I looked it up on amazon, read reader reviews, looked at a few pages and, after careful deliberation, decided it was a good choice. So I ordered it and began working through it. I’ve just finished it now, having taken a large, nearly two-month break in the middle. Accounting for that, I completed the text and its exercises in about 10 weeks, with considerable time spent (often more than 4 hours per day).

I’ve put a lot of time and effort into working through the course of the book, and so I have a lot of strong feelings about the book. There is a lot that is, frankly, quite brilliant and well done. Some things not so much, but, even then, there are some qualifications. In the end, I’d say it’s a wonderful production. It feels strange saying that, after all the frustration I’ve experienced at the hands of the text, but, a few days past it, I can really see how valuable it was. It really shines in comparison to other textbooks that I have gotten know since finishing Zelle’s.

But let’s get into the details, shall we?

1. The Name

Let’s get this out of the way. The name is problematic. Zelle states clearly in his introduction that this is not a book about Python; rather, it’s an introduction to basic concepts in computing, serving as an introductory course to computer science – using Python as an excellent way to start. Zelle is essentially using the fluidity of Python as a playground or laboratory for the archetypal, essential elements of programming he really wants to teach. In the process, you do learn a bit about Python. Enough to make significantly complicated, useful programs, in fact. But that’s almost a side effect of the actual stated goal of the book, which is to impart a deeper understanding of computing concepts. In the end, this focus on core programming concepts makes the book actually very helpful in learning how to program in all languages, including Python. Just in an immediate, “master this in 3 days” kind of way. But that’s not a very valuable way to learn anything anyway.

So I’m left calling the name problematic, instead of outright misleading. Also, you’ll notice that the blog post that led me to the book insisted this was a good way to learn Python, and I’m not criticising that statement, either. It’s a little bit of a gray area: I can see some people saying that, no, this book does not in fact teach Python. And they would be right from a technical standpoint. I happen to be someone who values core concepts and looks at them as an essential part to studying anything I truly wish to understand, so I tend to look at what Zelle is doing here as learning how to program. It’s not quite as direct as other methods, but I think it goes far deeper.

2. Structure and Topics

The thirteen chapters of the book essentially divide into three sections. The first 8 chapters, plus chapter 11, are about basic elements of computer programming: expressions, variables, functions, arrays, strings and string methods, loops and the like. Chapters 9, 10 and 12 focus on design, starting with simple simulations and moving to more complex programs and introducing object oriented design. Chapter 13 is about Algorithm Design, including recursion, and, as such, is the only chapter exclusively devoted to concepts of computer science. Sure, the rest of the book is tempered by a perspective of computer science, but the last chapter is the only one featuring any CS “meat.”

This also presents a problem in defining the scope of the book. When talking about the name, I pointed out how this is supposed to be a book about computer science that uses Python programming as a method to that end. Really, the book is getting you up to speed on programming as an art and science, rather than discussing computer science directly. That doesn’t disqualify it as a computer science textbook, but it makes the focus of the book seem even less clear.

This seems to open up another gray area, as the title did. Is a book really about computer science if it spends most of its text discussing the art of computer programming? Barely. But does spending so much time on design make it a good introduction to the science? There is no better way to introduce a science than
to lead your student to direct experience in the environment that the science works with. As I will explain in the next section, this book will provide you with hundreds of hours worth of practice experience. Practical experience is really the best route to understanding, that is, a full grasp of the concept, as opposed to knowledge.

Many tech authors decide that the best way to teach everything is to, well, teach everything. Their books become massive, monolithic braindumps that provide thorough documentation on their subject, but very little in the way of imparting wisdom or understanding. Zelle excels in this latter method, making his book a true guidebook. A nice contrast from some of the other choices available.

3. Exercises

Wow. Massive. And subtly so: the actual quantity of exercises is not that incredible. But pay close attention (and you will, if you’re trying to go through all of them), and you’ll see that many of these projects are full-scale projects. The book was intended to be a classroom textbook, so perhaps the exercise sections were designed to be picked through by an instructor, shortening the time to complete them. I read this book for self-study, however, and I soon found that the 4 hours per day I had given myself for practicing Python was not enough to complete both the chapter reading and the exercises; then it became a matter of only getting a few exercises done per day; then it got to the point where I was taking multiple days to complete one project. Toward the end, I had entered into an Ahab-like state of obsession, putting all of myself into finishing all of the exercises and coming up with something good at the end. I finished, and it was a spectacular feeling.

Now, that’s just good education. When a teacher gets you to put so much effort into something that it becomes an intense point of focus like that, he’s really throwing you into the task. For a few days at the end, my life was coding. I got to feel what it was like to commit myself to coding. This also ending up being one of those experiences, where I gain insight into myself and how I do work.

Of course, I don’t think that this intense kind of experience was Zelle’s intention – at least not directly. What I credit him for is setting me, the reader, up with a swan dive into the material. This is an excellent balance and a good model for other textbook writers: though the pace of the text is slow, steady and thorough, the exercises can be fierce enough to really challenge you and get you to a high level of real understanding.

Here are some examples of exercises I liked: everything in chapter 4, which introduces graphical concepts at a relatively early stage for a textbook, having you design programs that draw faces and houses at the click of the mouse, for example; the decoding exercises from chapter 5; the bouncing ball animation from chapter 7 (exercise 17); the greyscale conversion (exercise 14) and photo negative (exercise 15) programs from chapter 8; most of chapters 9, 10 and 12 were fun. The end of chapter 12 is really a list of massive projects, where you’re asked to create games that simulate dice, card and board games. Chapter 13 had you working out some pretty funky algorithms, but, in the end, it was too short a treatment of the subject for your projects to get all that advanced. Though it is nice to come away with a script that solves the weekly jumble.

I’d also like to point out that all the exercises are fair. I’ve looked at a few tech texts so far that pull what I would consider a rookie mistake: carelessly creating exercise lists that, while they have to do with the topic at hand, rely on understanding concepts that weren’t directly discussed in the lesson. While this might seem like a small error – I find that for me, and other people I’ve observed, this can be a huge break in the “flow” of the text that throws off the learning experience. I’ll leave it at that, though, just to say that Zelle does not make this mistake.

I want to note that there was a single exercise I didn’t complete. This was chapter 12, exercise 6, which asks you to learn the rules of contract bridge and write a program that sets up the first hand. I’m sorry, I’m not going to spend my programming time learning how to play a game I have no interest in. I know, as a coder I might be tasked in dealing with things I’m not interested in. I’d be glad to. For money.

Not to end this section on a low note, but I must mention the “Review Questions” that come at the end of each chapter, before the exercises. The discussion questions were great – but I wish there had been a lot more of them and that they were more challenging. The true/false and multiple choice exercises were so short and easy they might just as well have not been included. Some drill-like exercises would have been nice in their stead.

4. Conclusion

This was a fantastic read. A true education in the subject, any gray areas its confusing title and structure might evoke for you are really insignificant compared to the insight into programming you are going to come away with. The text is 100% ideal for absolute beginners. I would call myself an advanced beginner – someone who programmed a lot as a kid, but who is just getting back to it after a decade or two – and the level of the text was still excellent for me. There was a lot of review, but it was very constructive – I feel I have a firm grasp on these concepts now. This book is not for more advanced programmers – but they’re not going to be reading any introductions to computer science any time soon. An intermediate programmer wouldn’t get anything out of the lessons earlier, but someone who is short of complete mastery of the subject, I think, will still be able to enjoy the exercises. The easy ones won’t take much time at all – but the later ones make a nice challenge.

This one is going to stay on my shelf a while – if not for myself, then to pass on to other beginners as a strongly recommended introduction.