LPMuds.net: A word from Lars

Link: A word from Lars

LPMud (and corresponding the MudOS fork of it) is still a remarkable achievement. It is a virtual machine with a scripting language, code reloading, versioned instances of objects and provides an environment for a game to be developed in.

However, the way LPMud was licensed (covered in passing here) meant that commercial use of the driver was a violation. This didn't stop a furor over MUDs that used it commercially. There was various talk over the years about finding all the contributors and relicensing it, but one problem I recall was that no-one was in contact with Lars Pensjö, the author and namesake.

So, it was interesting to see the above linked post by Lars, and to hear his take on LPmud. This doesn't in anyway affect the licensing situation, I seem to recall other contributors, and perhaps a lack of record of who exactly contributed also stood in the way.

PyCon: CCP tools and tips presentation online

Did my presentation today. Although I had practiced the actual speaking part twice, I hadn't practiced running the EVE applications (our systems testing tool and our content development tool). Initially, I had planned to go into some implementation detail, but with only 25 minutes and wanting to give as broad an overview into our use of Python as possible, this wasn't possible.

A technical problem which got in the way was the inability to get what was on my screen output to the projector. Back when I had a Dell, the switch button worked and took care of this. On the work VAIO, it was not happening. Kristjan, who did the other CCP presentation, which followed mine, also had the same problem with his VAIO.

I hope that someone got some value out of it. It was somewhat reassuring to get people coming up after the talk, despite the lack of question time, to ask about various aspects. Someone even managed to check out the open source project I linked to - which was good, but they also pointed out its lack of documentation. I concentrated on getting the code working ready for my presentation and was relieved to get that much done.

The slides are also now uploaded to the conference website.

PyCon presentation progress report

I previously posted about my PyCon presentation in the post "Making games in Python - Tools and techniques at CCP". This one is a report on the progress in writing it.

A rough draft of my presentation was finished last week but I still needed to edit it and concentrate down all the details. In order to encourage myself to finish it, I scheduled a practice presentation for my coworkers next week. However, two are going to be at GDC, so I did a unprepared really rough preview presentation for them.

While to some degree the presentation was a little confused because of its unedited state, it was definitely worthwhile to get an early chance to do it.

• It was way too long for the 25 minutes which I have alloted.
• The implementation details are too confusing and time consuming.
• Less text and more pictures.
• Possibilities for more and clearer explanation highlighted.

The new open source implementation of the namespacing and code reloading is getting there. It should be ready to offer as a hand-wavey method of covering the implementation related aspects, given the lack of time to do so in the presentation.

PyCon 2009: Making games in Python - Tools and techniques at CCP

I will be presenting "Making games in Python - Tools and techniques at CCP" at PyCon this year.

It'll cover a lot of the development techniques we've implemented support for in Python:

• Our use of code reloading.
• Our use of unit testing.
• Our functional/systems testing tools.
• Our use of wxPython to create authoring tools.
• And it will of course touch on Stackless.

It was originally planned for my manager, Mark Kalmes, and I to co-present. But he's dropped out of the conference, so I'll be doing the whole thing.

PyCon 2009: CCP related talk proposed

I submitted a talk proposal for PyCon 2009. It's title is "Making games in Python - Tools and techniques at CCP". It's intended to cover all the ways we have customised our framework in order to make working with it more productive, and easier. From the unique ways in which we do our unit testing, to how we use code reloading and more.

Here's hoping it gets accepted! :)

Stackless Python MUD framework

I've uploaded my Stackless Python based MUD framework to Google's project hosting:

http://code.google.com/p/sorrows-mudlib/

When I was at university and for a few years afterwards, I joined in the effort to work on an LP MUD based on the MudOS driver. As most of the potential of an 'in-development' MUD is defined by the game systems which have been implemented, and I did most of the programming, I eventually inherited control of the MUD.

After a period of time, I became frustrated by the closed environment MudOS provides and the idea of a straightforward scripting language became appealing. So I rewrote the basic elements of the mudlib in Python. There are only a few toy game related elements present in the code.

Over time I developed a few other projects and they have come to be integrated into this framework as I found the time:

• Code reloading: As MUD code is changed and the files saved to disk, the game framework detects this and reloads the contents of the files.
• Stackless-compatible socket module: Asynchronous networking support is hidden away behind the standard socket interface through the use of Stackless Python channels preventing them from influencing framework structure in custom ways.

It also has support for connecting to the Intermud 3 MUD network. Although this isn't 100% working at the moment going into an infinite loop when receiving the initialisation updates from the Intermud router.

Anyway, a friend expressed an interest in possibly using it as the basis for his own MUD experiments so I figured I might as well throw the code out there.

Live coding / code reloading for Python

Several months ago there was a spate of interest in live coding with Python. Those who experimented with it reasonably took the approach of continually calling the reload method. However this only worked when code was implemented in a stateless way and how to code within this limitation was covered in detail in the blog posts about it.

I commented on one of the later posts (although my link placement was a little mixed-up) gathering together enough information needed which happened to be publically available and could be used to write the support needed for live coding without the mentioned limitation. To recap that information:

• Detection of changed files:
  - Cross-platform.
  - Windows.
• Updating class instances on reload.
  

But the general interest in this sort of thing died down and no-one stepped forward to do the work needed. I certainly was not going to do it, as while in theory it would work, it wasn't the approach I would take anyway. Tracking instances so that they can be individually updated seems like much more work than should be required.

A more usable solution would be to update the class itself which would transparently make the changes available to all instances. Though actually implementing this is not as straightforward as one might hope. For instance how functions from classes even unbound are indirectly linked to the class they came from is one of the little hidden surprises of how Python is implemented.

And this "more usable solution" is what I have released, combined with the code from the links above to handle the detection of file changes:

Live coding v 1.0

However there was a design decision made which need to be taken into account. Namely that this is only made possible by using a custom importing solution. All the code which is have automatic code reloading has to be under this solution. Why it was used I will cover after I show how to add a directory containing Python scripts to be made available

This will add a directory of code as importable modules:

import livecoding
cm = livecoding.CodeManager()
cm.AddDirectory("c:\app\server", "applib")

Let's say that 'c:\app' contains the following directories and files:

server\services\networking.py
server\objects\session.py

Where 'networking.py' specifies the class NetworkService and 'session.py' specifies the class Session. Under the algorithm used to map directory contents to an importable namespace, NetworkService would be placed as applib.services.NetworkService and Session would be placed as applib.objects.Session.

So these classes could be imported in the normal manner:

from applib.services import NetworkService
from applib.objects import Session

So why use the custom importing solution? Well, it makes updating loaded code with changes easier because as the library controls the importing it knows what to update and how. But why not look into getting a similar system working with the standard module system? Not interested, sorry. My fellow author and I have worked a lot with custom importing systems and found them to be much easier to work with than the standard module system. And over time we have come to prefer the system which this library implements.

I also cobbled together another library filechanges which comes as part of the download or can also be obtained from the SVN archive. This is just a collection of the file change detection code found in the links I originally gathered above. The livecoding library can be told to use this to provide built in file change detection.

import livecoding
cm = livecoding.CodeManager(detectChanges=True)
cm.AddDirectory("c:\app\server", "applib")

Which completes the collection of functionality which makes up the v1.0 release of this library. However there is still work remaining to do. There is the incomplete override feature, clean up needed regarding custom methods of handling the file update events and more methods of file change detection other than the only one which currently works (the cross-platform one).