Skip navigation

Tag Archives: kleptos

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.