playsh: slashdot readers (and Wired News readers) will be wanting a bit of context. You'll want to know:
- What playsh is
- What the current state of playsh is
- What the roadmap is
- Why even do this
For a summary of what the playsh code does (including some vaguely technical details), read about what playsh is.
The current state: playsh is so totally a prototype right now. It's a buggy bundle of Python code that, by default, opens interfaces to your computer and makes it insecure. Players can interfere with each other's objects. And so on. This is a proper prototype - one to test the interaction design and the concept - rather than the "we only call it beta to cut down on support costs" kind of prototype. The code was good enough for me to get to a rough demo, and includes a ton of bugs where verbs got broken while I was hacking on the plane (notably: dig). It was also good enough for me to figure out what I did and didn't like about the way verbs bind to objects.
(Why have a prototype like this? It's because I find it easier to figure things out with my fingers, by typing and using code, than in my head. With playsh, where it's an objective that multiple layers are equivalent, it's necessary to rush ahead to the high-level verb layer even before everything else is stable.)
What's the roadmap? There are a couple more things I want to try out on the current codebase, particularly getting rid of the hierarchy of actualizers (that's the way verbs get bound to the properties that lie at the heart of objects) and replacing them with some flatter system. I also want to have a pluggable way of adding new ID types, so that new objects (like rooms and exits) can be generated on-the-fly, without actually creating them. That's the short-term.
In the longer-term, I want to break playsh up into a more solid server (to hold the properties) and per-player clients (to actually run the Python code). This should increase security between players. Ideally, for performance, I want to take some lessons from the functional programming road and apply them here (geographically local namespaces, perhaps).
Of course, why does playsh even exist? This is what Ben Cerveny and I went into at the ETech session on playsh. I'll just speak briefly for myself here. I gave a talk about the future of programming last year, and I wanted to put some of the ideas (about what objects are) into practice. I wanted to have a bash at something that Matt Jones called blog-o, a next generation language, allowing people to combine communication, media and automation in unlimited ways, but that easy to get into and understand like Basic or Logo
. I wanted to show that that the server and client of the www shouldn't be as coupled as the Ajax-world wants them to be, and take advantage of the best bits of the semantic web. I wanted to build on a couple of things that our brain does really well - geography and narrative - that are sidelined in our current "direct manipulation" paradigm (distance and locality are really powerful metaphors to build representations of knowledge and social structure on. Note that people have PhDs in geography, but not in picking shit up). I wanted something that was social from the ground up, as much as View Source is part of the browser, but also let people see the world in their own way, and experiment and share these different ways. MOOs fit the bill in so many ways.
But mostly I wanted to build something absurd that would, as I say in this essay on modernity and protest, make people look at the status quo a little differently.
Crikey, that got a bit heavy there, sorry about that. I use playsh personally and will keep developing it. Watch if you like, join in if you fancy. The playsh project on sourceforge has the code.
playsh: slashdot readers (and Wired News readers) will be wanting a bit of context. You'll want to know:
For a summary of what the playsh code does (including some vaguely technical details), read about what playsh is.
The current state: playsh is so totally a prototype right now. It's a buggy bundle of Python code that, by default, opens interfaces to your computer and makes it insecure. Players can interfere with each other's objects. And so on. This is a proper prototype - one to test the interaction design and the concept - rather than the "we only call it beta to cut down on support costs" kind of prototype. The code was good enough for me to get to a rough demo, and includes a ton of bugs where verbs got broken while I was hacking on the plane (notably: dig). It was also good enough for me to figure out what I did and didn't like about the way verbs bind to objects.
(Why have a prototype like this? It's because I find it easier to figure things out with my fingers, by typing and using code, than in my head. With playsh, where it's an objective that multiple layers are equivalent, it's necessary to rush ahead to the high-level verb layer even before everything else is stable.)
What's the roadmap? There are a couple more things I want to try out on the current codebase, particularly getting rid of the hierarchy of actualizers (that's the way verbs get bound to the properties that lie at the heart of objects) and replacing them with some flatter system. I also want to have a pluggable way of adding new ID types, so that new objects (like rooms and exits) can be generated on-the-fly, without actually creating them. That's the short-term.
In the longer-term, I want to break playsh up into a more solid server (to hold the properties) and per-player clients (to actually run the Python code). This should increase security between players. Ideally, for performance, I want to take some lessons from the functional programming road and apply them here (geographically local namespaces, perhaps).
Of course, why does playsh even exist? This is what Ben Cerveny and I went into at the ETech session on playsh. I'll just speak briefly for myself here. I gave a talk about the future of programming last year, and I wanted to put some of the ideas (about what objects are) into practice. I wanted to have a bash at something that Matt Jones called blog-o, . I wanted to show that that the server and client of the www shouldn't be as coupled as the Ajax-world wants them to be, and take advantage of the best bits of the semantic web. I wanted to build on a couple of things that our brain does really well - geography and narrative - that are sidelined in our current "direct manipulation" paradigm (distance and locality are really powerful metaphors to build representations of knowledge and social structure on. Note that people have PhDs in geography, but not in picking shit up). I wanted something that was social from the ground up, as much as View Source is part of the browser, but also let people see the world in their own way, and experiment and share these different ways. MOOs fit the bill in so many ways.
But mostly I wanted to build something absurd that would, as I say in this essay on modernity and protest, make people look at the status quo a little differently.
Crikey, that got a bit heavy there, sorry about that. I use playsh personally and will keep developing it. Watch if you like, join in if you fancy. The playsh project on sourceforge has the code.