Keyboard Philosopher

In PyBlosxom, blog entries are stored in regular files rather than in a database. This means that I can write my entries in emacs (hurrah). PyBlosxom can handle posts in any format it has a parser for.

The simplest parser removes the metadata from the beginning of the file and passes the remainder of the file directly to the output webpage. Ergo, in the most simple format, the entries should be written in html (with a basic text header). More complicated parsers could be used for formats like xml or wiki markup. PyBlosxom uses a file’s file extension to determine what format the entry file is in.

For some unusual reason PyBlosxom associates the simple pass-through parser with .txt files (wouldn’t it make more sense to use .html?). In any case, I decided that I wanted to add my own file extension, .blog, so that I could easily distinguish my blog posts from other text files and html files on my system and so that my editor could treat the files specially.

The first step was to make PyBlosxom recognize the files as entries which it knows how to parse (anything PyBlosxom doesn’t have a parser for will simply be ignored).

On line 79 in pyblosxom.py, is a block of code which I modified as follows:

# entryparser callback is run here first to allow other plugins
# register what file extensions can be used
data['extensions'] = tools.run_callback(”entryparser”,
                {’txt’: blosxom_entry_parser, ‘blog’: blosxom_entry_parser},
                mappingfunc=lambda x,y:y,
                defaultfunc=lambda x:x)

This is sufficient to make PyBlosxom treat .blog files just like .txt files.

The next step was to make the files easier for me to write. First off, emacs should open the files in html-mode. Adding the following bit of code to my .emacs file accomplishes this task:

(add-to-list 'auto-mode-alist '("\\.blog\\'" . html-mode))

The next step requires a tiny bit of background information on the format of PyBlosxom entries. The basic format of a PyBlosxom entry looks like this:

Title Of Entry
#metadata-1 value-1
#metadata-2 value-2
(...)
#metadata-N value-N

Post line 1.
Post line 2.
(...)
Post line N.

Note: the blank line is not required, but it makes the file more (human-) readable.

I always use the same two metadata lines: #postdate (from my metadate.py), and tags (from Joe Topjian’s tags.py). Because of this there are a few lines which are similar across all of my blog posts. Why not have my editor enter these automagically, including entering the current #postdate (in the format YYYY-MM-DD HH:MM)? How convenient that emacs provides a mechanism just for this purpose: skeletons.

I wrote the following code and added it to my .emacs file:

(define-skeleton blog-entry-skeleton
  "Inserts a PyBlosxom-style blog entry skeleton into the current buffer.
This only makes sense for empty buffers."
  "Title: "
  str | "Untitled Entry" \n
  "#postdate " (insert-date-and-time) \n
  "#tags " ("Enter a tag: " str ",") '(delete-backward-char 1) \n \n
  "<p>" _ "</p>")

When executed, this skeleton prompts the user for a title (if the user simply presses RET it defaults to Untitled Entry), repeatedly prompts the user for tags (keywords) (until the user simply presses RET), enters the current #postdate automatically, and the leaves the cursor inside a new <p>.

The final touch is to make the skeleton automatically execute when a new .blog file is created:

(eval-after-load "autoinsert"
  '(add-to-list 'auto-insert-alist '("\\.blog\\'" . blog-entry-skeleton)))

It’s like magic!

You guys remember the Tamagotchi (たまごっち), right? The Tamagotchi was a virtual pet you could feed, clean-up after, play with, etc. It sounds kind of lame, but the cool part is that the Tamagotchi has a persistent idea of state. It’s never really off, it “lives”, even when you are not playing with it. And it has some simple evolutionary capabilities.

This has really been interesting me for a while. I’m convinced something (the primary thing?) which really makes games fun is their ability to show us something new. We don’t want to feel like we are playing something deterministic, where we press a button, the game displays the built-in response back to us and that-is-that. There’s nothing like that “Woah! I didn’t know it could do that!” feeling. That’s what I play games for.

Most simply, games have a story, or levels, or something else that we haven’t forseen that we get to enjoy because it is new. But to me, the holy grail is games which make themselves. When the content of the game goes beyond what the designer had forseen, then we really have something.

In talks in Game Development class last semester, we had a discussion about the possibility of developing true (strong) AI. Someone claimed that real AI was a pipe dream because we cannot create anything greater than ourselves. My contention is not just that we can, but that I (like many others) already have.

For instance, my Game Focus Generator. Sure, I have preloaded the program with words and formulas to develop phrases, but the truth of the matter is that the output of that program contains things I would never have thought up. I used my abilities to develop something that reached beyond what I could/would have done on my own. For the people who know my personal programming projects of the past few years, you will notice that many of them serve this same goal. My genetic creature population sim (aka “flamesex”) is designed around this principle—I want to come back to it later and be surprised by the output. My graphical hacks, like my “growth” app, are in hopes of making some kind of image that I would never have thought of.

Anyway, this is something that really fascinates me.

I would love to make a state-full game which I could run on my pc, which I could play at will, and be surprised by.

But it has to be fun. The Tamagotchi is cool because it can surprise you to some degree, but it really can’t do enough to be all that staggering. It really needs to evolve more. The flipside of that is that you need for the player to still feel that they have some control—not just have it evolving out of control—otherwise they wont play. But if the game requires too much control, then it will be a pain because you have to be there messing with it all the time, and anything that forces you out of your normal life to maintain it is just a pain, and not a game. In general, the program needs to be stable. But it’s hard to make a stable game because risk is one of the things that makes games fun.

“The Sims” captures some of the basic elements, but for one the game was not intended to be played—or rather, not played—as I propose. Also, there is a limited amount of content. Nethack actually captures a lot of the things I like about gaming, partially by (psuedo-)evolving (random generation/placement of dungeons, stats, objects and enemies), and partially by its sheer complexity. Nethack has so much fabulous content that is not documented that you can discover. The game just sets forth a world, teaches you the basic rules, and lets you loose in an alien world. But there are actually things about the world to discover (I’m talking capabilities of the world, not story or locations), unlike most games.

Magic: the Gathering is also one of my favorite games of all time. Why? Because the game gives you a world—the cards—and says “go play it in”. You can combine cards in ways that no one ever thought of—including the game designers (might this be the same reason I am in love with emacs?). There are always, always, new things that you can discover (new card combos and such), and the things you discover make a serious difference in game. It’s like the card game Fluxx, but you actually have some control over the power(/madness).

This is my dream (or my goal, if you prefer). Now all I have to do is create it. Hmmm…