Skip navigation

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, If you are using IDLE or something similar, just make sure that it can find the file – 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…

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:

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 am approaching the end of this book; the ideas are becoming more familiar and sticking in my mind.

I want to write about purification. Gandhi insists that Satyagrahis must be purified in order to do their work. I was confused and perhaps put-off by this phraseology at first. Purification is all too often a hidden form of self-abuse, a means of asserting a power structure and creating submission. Making weak people not know that they are weak by giving them a badge of honor for causing themselves pain in the name of a cause.

Based on his generally sound way of thinking in other matters, I was sure that this is not what Gandhi would allow to happen with his injunction on purification, so I was simply confused as to the meaning of the word as he used it.

I think I’ve got it now. He is being very practical. What he means by purification, in the context of Satyagraha, is the lack of any attachments or distractions that would prevent you from focusing on the task at hand. It’s that simple – though, of course, infinitely difficult. For example, Gandhi remarks that his appeal to the Viceroy of India was a lapse in faith during a particular period of fasting; he had grown minutely impatient with a fast he was undergoing and had convinced himself that an appeal to the Viceroy would bring about his cause. In reviewing this action, he decides that he should have just continued with the fast and not made any complaints.

As mystical and perhaps alien as fasting might appear to you, to Gandhi it was a very practical tool that required certain restrictions, and he realized that he broke one of them. His purification was the training that allowed him to be aware of these intricacies. Within his system of action, any lapse of awareness of these intricacies means failure. Hence, purification.

I trust this is beginning to make sense to my readers. It’s a confusing topic, but I like the idea behind this; I am happy to find a way of understanding a tradition that is murkily understood and being able to explain it in more concrete, practical tool. I think that was Gandhi’s genius – his ability to turn the abstract and vague into the real and incisive. I am convinced that this feat is not very well known among my peers, because they tend not to believe that anything garbed in exotic mysticism – something so much abused in our culture – can have any practical value.

As a final note, I am now on the look out for an objective biography or analysis of Gandhi’s work, so I can get a counter-perspective. A fierce critique would be great. However, so far the only criticism of Gandhi I have found has fallen into two categories:

  1. from Jews, who criticized his insistence on non-violence as a solution to the holocaust and
  2. ad hominem criticism that tries to prove he is not the saint everyone thinks he is.

Both of these have their value; they’re just not interesting to me at the moment. I want to read an objective study on the effectiveness and consequences of Satyagraha on the Indian Swaraj movement, maybe with a little biography. If anyone has any recommendations, please let me know.