Skip navigation

Category Archives: Tech

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

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!

I managed to finish everything I set out to do today with Python, even if it might have dipped into more of my time for other things than I would have wished. So it goes.

A lot of this extra time was spent in the debugging phase of today’s work. In particular, I was having trouble getting the game to restart. There were a few minor issues with it that I cleared up easily, but I got seriously stuck on resetting the player’s starting inventory. Copying some code I’ve seen in other programs, I decided to use global variables at the top of the file containing my “runner” (driver) class to initialize some of the game’s starting values, including inventory. It looks like this:


STARTING_INVENTORY = ["dagger", "coins"]


This seems to be an artifact of C++’s “#define” statements, but I suppose it works just fine in Python. I think the idea is to make these variables exceptionally readable and easy to locate so they can be changed conveniently.

The problem I ran into was that, when resetting the game after getting rid of the coins, reassigning this value to the runner object’s self.inventory attribute was only giving the player the dagger. It took me the longest time to figure out what was going on.

After maybe 20 minutes, I finally remembered that I had encountered this problem in the past, but had carelessly forgotten about it: lists are not copied when reassigned. When you make a list and continue using it, one list is created and will be passed along to variable after variable.

So, when I was assigning STARTING_INVENTORY to self.inventory at the beginning, then clipping “coins” off of self.inventory, I was actually clipping coins off of the original list assigned to STARTING_INVENTORY. When I was passing STARTING_INVENTORY back into self.inventory, I was passing back that same, clipped list that was already assigned to self.inventory. In other words, I was not actually resetting the inventory and therefore cheating the player out of his or her hard-earned coins.

What this has taught me (or retaught me) is that lists are more concrete than abstract; the changes you make to them last longer; they are mortal. Of course you can copy them (which was my eventual solution), but it’s something you have to specify; it is not native to the nature of the list to be copied and disseminated; it wants to remain unique.

But enough anthropomorphism of data structures.

I have written out all the traps and dead ends for the game, and tomorrow I make some finishing, aesthetic touches. The traps are really not intricate and the dead-ends are far from thorough. I have realized that 99% of the actions in adventure games are dead ends. It would take a very long time for me to map every mundane, pointless action in detail, so I will leave it as it is. Considering that in the example I’m supposed to follow there are maybe three possible choices, I have gone far past the call of duty.

Ah… that’s refreshing. I was out of town for a few days, but now I’m back, and I’m more motivated than ever to get Kleptos reasonably finished by the end of the week. Yesterday I did a basic map of the game, but as I finish it, I’m mostly going to be improvising and changing as I go along.

So here’s the plan:

Wednesday: Create a winning path through the game. That is, add the inventory items, objects and switches that will get to the win screen.

Complete! Yep, I already did this. It took a little wrangling. There was a bit of a mix up in terms of confusing inventory items and objects that appear in rooms that took a bit of tracking, but it was easy to fix, and things are running again. I did notice a few other major bugs, but I’m stopping for the day, and I’ll leave those for tomorrow.

Thursday: First, work through the bugs found on Wednesday. Second, do a little bit of proofreading and tightening of descriptions. Third, create traps and dead ends for the player. This will involve tweaking an attribute called “visibility” – the player’s hit points. The idea is that the more mistakes the thief makes, the more likely he is going to be caught. A visibility of 100% means a game over. This means that you will most likely have to play the game several times to get it all right.

I swear I did not come up with this as a cheap trick to lengthen play time, though that’s ultimately what it’s going to amount to. I’m comfortable about that, granted my goal now is completion, not perfection. The original idea was this: as visibility increased, it would limit your options in the game. There would be this middle-ground point where if your visibility was above 100%, you would still be playing, but your goal would be fighting guards and running away, rather than completing your goal. But… that was too complicated, so I shrunk it to a mere “hitpoint” attribute. Next time.

Friday: Create final touches. This means: creating a splash screen, an ending for a winning scenario, beefing up the help file. I might possibly working on a couple items of polish I have in mind, but these are not essential. Proofread and bug test as needed.

Saturday: Test, test, test, finish. I am going to work very hard to curb featurecreep, so that Saturday can be devoted to testing and tweaking. My work will not be finished at this point (in fact, the next lesson in LPTHW is to review the code for your game), but I will be putting it up on github for all to see the first version. Celebrate!

So that’s the plan. I’ll be updating daily as I go along, to share the process. Stay tuned.

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…

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.