@plamzi, the basic idea is something I've been kicking around for a while (see https://docs.google.com/document/d/1TS-m... ), sans the commercial part though I don't have a problem with that. However I seem to remember someone doing this exact thing (for graphical muds) but I don't remember it really taking off…does anyone remember the name of that project?
I read through the doc and I think what you're outlining is a storage (and parser, but not sure how that will work) API that multiple independent and potentially very different servers can use to access certain shared features. What I outlined is basically an SDK.
I see what you mean, but if there's a standard networking component everyone uses is it much different than a packaged SDK?
I think they're quite different.
An API is an interface that opens up a service to third parties. Usually, it not only comes with documentation on what calls the API supports but also with examples in multiple popular languages on how to integrate it easily. Usually, an API doesn't care what software is used to connect to it, only that the rules/policies of interfacing are being followed.
An SDK is a set of tools and libraries that facilitates the creation of software for a certain platform. It may support multiple languages and multiple platforms. It may be mostly or entirely in the cloud, although the typical examples we all know of are desktop apps. It's a sandboxed environment in which developers plug in their logic and their assets to create their unique software.
@plamzi, the basic idea is something I've been kicking around for a while (see https://docs.google.com/document/d/1TS-m... ), sans the commercial part though I don't have a problem with that. However I seem to remember someone doing this exact thing (for graphical muds) but I don't remember it really taking off…does anyone remember the name of that project?
I think it was called Ultimud. I could only find this review. I was reading your ideas. I thought it odd the parser would/could be decoupled. In a lot of muds, command parsing is highly coupled to the context of the environment.
However I seem to remember someone doing this exact thing (for graphical muds) but I don't remember it really taking off…does anyone remember the name of that project?
If the goal is to make it easier for more people to make quality MUDs then I think an integrated development and hosting solution with built in monetization would be better. Something like a MUD version of StoryNexus with a single engine, client portal and common virtual currency.
@Tyche, looking back on that document I see I wrote, "This example is so simple that it ignores a large class of mud commands, where the command needs knowledge of the world model. Well just note this for future discussion". I think that's called a punt ;).
edit: I think the StoryNexus platform is cool and Failbetter is a great company. The gameplay there feels less compelling though, it would be nice to have something more mud-like.
I think the StoryNexus platform is cool and Failbetter is a great company. The gameplay there feels less compelling though, it would be nice to have something more mud-like.
It would be great if a MUD-influenced team could beat companies like Failbetter to the punch with an HTML5 platform for developing richer games with real-time components. But the odds are against that happening. Normally, we would look to Iron Realms and Simutronics to lead the way, but they both seem welded to the terminal window. And most MUD devs I've discussed this with think of the scrolling text window as the only way to deliver a MUD-like world. Scrolling text as the main UI element has always been a tough sell, and it's only gotten tougher. Combine that with a general scorn for graphics among MUD devs, and I'm afraid the verdict is that the future will resemble the past.
P. S. Most of what I've done this past 3-4 years has been to try to package the MUD experience (which we all know is great) in forms that are more palatable to general audiences. If I were to work on a MUD SDK, I would want to not only lower the entry bar (which is already pretty low), but also to enable folks to deliver something that can actually get players, and even generate revenue, in 2013. I imagine this something to look like a browser-based game on steroids, with a live socket connection delivering dynamic refreshes to different page elements, all of which would have a mix of static graphics and text in them, not just text.
Seriously though, I know where you're coming from plamzi and can imagine the kind of game it would look like (something like a cross between a PBBG and a tactics RPG?). But, and I know this has been done to death here, at that point it doesn't really play like a 'text mud' anymore. There's a good argument that the mechanicswouldn't change. But I think people don't give enough weight to the importance of the presentation layer (the text). A game is notjust mechanics IMO. The presentation is critical to achieving a particular 'feel'.
Don't get me wrong, I play all kinds of games and would certainly try a game like you talk about. But if my interest on this particular forum is text muds, that's the kind of game I'm going to aim for here.
I read through the doc and I think what you're outlining is a storage (and parser, but not sure how that will work) API that multiple independent and potentially very different servers can use to access certain shared features. What I outlined is basically an SDK.