Skip navigation

Tag Archives: python kleptos game-design

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.