Archive for the ‘livecoding’ Tag
The last few weeks have been one of those odd times where I don’t feel a really strong push in one direction. My usual way of doing things is to focus intensely on one thing for a shortish amount of time, and then move on to something else. Incidentally it’s been a long-term thing to try to stretch that focus out a bit so that I can work more consistently on larger projects. But anyway, I’ve felt becalmed lately, and this doesn’t happen that often, so it’s a strange sensation. Kind of puzzling, like — what’s going to happen next?
It’s an early Spring here. You’d think that would get the creative urge going; however it seems to be doing the opposite. On the other hand, I tend to do things backwards at first. Maybe then this is the natural state of affairs. It’s sort of making room for doing a lot of little things in a leisurely and lazy way.
Transplanted the tomatoes to four inch pots:
Found a cool Python editor — basically a livecoding editor — called Reinteract. Haven’t got it to work with pyglet yet, probably because pyglet’s event loop and the Reinteract GTK loop won’t play together nicely without some hacking. Someone on the Leo list clued me to Reinteract, so maybe someone on the list will run with a Leo to Reinteract bridge. It’s a pretty cool IDE, I recommend checking it out.
Starting to play around with an idea for an IF news service. I think as more and more people are blogging on IF, combined with the various forums and newsgroups, some way of feeding (and possibly filtering based on the recipient?) the flow of community information will become more valuable. I like Planet IF but it’s not really serving this purpose at the moment, and I’m not sure that it could; what I’d like is something that gathers all the disparate sources. And well, since I obsessively read everything anyway, why not put that to some good use. The first iteration was just me collecting links. I have some ideas on where to take that but nothing solid yet. I also have wanted to get more into web stuff so this would be a nice project for that.
Worked some more on mockups for a Python IF IDE in GIMP and Inkscape, and realized that’s harder than I thought it would be! I’d really like to work more on drawing to make this easier. As a result I’ve started to learn the Qt framework for GUIs, which is easier than I thought it would be. So there you have that.
While in the library today to pick up a book (and pay my overdue fines, again; I think I must support several librarian’s wages really) a book on display caught my eye, The Assault by Harry Mulisch. In the first part of the book a 13 year old boy witnesses a German collaborator gunned down by the resistance in front of his house, his brother disappears into the night with the collaborator’s gun, and the Germans arrest his family and destroy his house with grenades and flamethrowers. Then he spends the night in a jail cell with a beautiful wounded Communist terrorist, narrowly escapes death the next morning when an Allied fighter strafes his convoy en route to Amsterdam, and finally reaches safety in the arms of his uncle. Mulisch is a prominent Dutch author (who I had never heard of) and it shows, the writing is masterful even in translation, and shares a lot with two of my favorite writers, Saramago and Murakami, in the way their narrative voice exists on top, through, and under the work itself.
As usual I have a list of ideas a mile long. Something is brewing, I just don’t know what.
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!