Archive for January, 2010|Monthly archive page
I came across http://narrativedesigners.net/, which is a newish forum/wiki/resource for people working in narrative design. Seems to be mostly people in the AAA industry, and perhaps those from art and academia as well. It’s always struck me that these folks work in something of a walled garden so it’s nice to see a public-facing community site take form.
Amid a little Inform 7 drama lately on RAIF I started to wonder how much of the conversation there actually is taken up by Inform 7. For those among my vast readership not familiar with RAIF, it’s the Usenet group for talk about writing interactive fiction.
There seem to be hints that Inform 7 may create its own forum for discussion, so I also wondered about the effect on RAIF of moving I7 discussion somewhere else.
I just browsed through the last month of topics (basically December) and categorized them as follows: Inform 7, TADS, design talk, meta (talk about RAIF), interpreters, community (competitions and the like), calls for game testers, and the convenient other. The results:
According to Google Groups stats there were 784 posts in December 2009 (I’m guessing many of these are spam). Was December an anomalous month in terms of number of posts? In general, no. Here’s the table:
The high count in November may have been from IFComp.
As soon as I get my horde of winged monkeys to tabulate all of 2009, I’ll report back.
Anyway, it’s always been obvious that many of the RAIF posts were on I7, but I never realized just how much. It’s not really a huge percentage in terms of the whole newsgroup, but it dwarfs each other category individually.
I wish there were some more numbers available, like how many active posters there are…a man can only dream I guess.
Recently I started reading about livecoding. I was aware of it in the context of music performance, but in regard to games it might be more accurate to call it code reloading or simply interactive programming, but of course ‘livecoding’ is more catchy. Regardless of what you call it, it’s a lot of fun, and if you like programming as an iterative process as I do, it’s just fantastic.
A few years ago there were a few articles about livecoding and Python, which you can track down through this post by Richard Tew. He’s the author of the livecoding module which I’ve started to use with pyglet.
The basic idea is that you can modify a game’s code as the game is running; this isn’t any different than what you can do with many game development frameworks and some mud servers (mush softcode allows this, for example, and I believe LPMud has this as well), but the livecoding module lets you do it simply with your text editor of choice. Some IF language development environments like the Inform 7 IDE and TAD 3’s Workbench have a similar function with their skein and replay features, but livecoding is much more immediate and in the flow of the game itself.
The livecoding module achieves this by managing which files are to be tracked for changes, and then executing a file’s contents over again when you change it. As the programmer you need to structure your program so that you’re cognizant of what is in the global scope, as executing that code again will clash with the previous version (for example, you don’t want to re-execute a file that instantiates the pyglet window, unless you delete that window from the global scope). You also want to manage how instances of a class know about changes to their class; the module won’t automatically update old instances, but you can reassign the class to the instance to get the new changes (this at least is what I’m doing currently — I’m still learning how this works).
Here’s a simple example — get the livecoding module and put it in a new directory. Then create a code directory within that new directory. In my code directory I put two files, an initialization.py and a classes.py. Here’s initialization:
import pyglet window = pyglet.window.Window(width=640, height=480, visible=True, caption='livecoding')
Remember that the important thing is to separate things in the global scope from the things you’ll change, to avoid clashes with the running game when you change things. Now in classes.py I put this:
import pyglet class Hero(pyglet.sprite.Sprite): def __init__(self): pattern = pyglet.image.SolidColorImagePattern(color=(255, 255, 255, 255)) solid = pattern.create_image(200, 100) image = solid.get_texture() super(Hero, self).__init__(solid) def set_pos(self): self.x = 400 self.y = 200
In the main directory you’ll have a script to run the game, which I just called run.py.
import pyglet from livecoding import reloader cr = reloader.CodeReloader() cr.AddDirectory("server", "code") import server hero = server.Hero() @server.window.event def on_draw(): hero.__class__ = server.Hero hero.set_pos() server.window.clear() hero.draw() if __name__ == '__main__': pyglet.app.run()
The reloader keeps track of changes to any file in the code directory (of course, you can call the code directory anything you want). This replaces the normal Python import statement for those files. It’s similar in a way to pyglet’s method of managing data files.
You see that the game creates the hero object, and in this hackish example I reset the class of the hero on every frame. That’s to account for the possibility of changes to the Hero class (in classes.py). What you do then is execute run.py, and while the pyglet window is sitting there, change the set_pos method of Hero in classes.py. Then mouse over the pyglet window or alt-tab to it, and see the changes!
In a less trivial example you could move the class reset to an update function called on a pyglet timer. That then opens up, fairly transparently, making changes to the game process and data as you’re playing the game.
The only sticking point so far is managing the structure of the program to avoid any weird errors in the global scope. Also from reading some of those other posts I linked above it seems like I might run into more problems with things like animation as I go forward — but we’ll see what happens!