14 Apr, 2012, artreth wrote in the 1st comment:
Votes: 0
Hey all,
I'm working on a massively muddish websocket codebase.
I'm looking for other coders to help with it.
Please feel free to contact me.
Lots to work on.
http://code.google.com/p/mmud5/
14 Apr, 2012, Idealiad wrote in the 2nd comment:
Votes: 0
Nice idea. What's your vision for the project? What's the design? Do you have a demo server running?
15 Apr, 2012, artreth wrote in the 3rd comment:
Votes: 0
Thanks Idealiad,
I'd like to create a standard codebase for the next generation of MUDs.
Translating from the old model of scrolling text to working with the browser DOM, HTML content gets injected into the DOM by jQuery.. I'm still pondering using a webgl library to display non-interactive 3d as an option.
The client and server communicate with json encoded packets, and control messages to the client are encoded by <div class="message-to-client"></div>. So the idea is to have the client as a generic display system controlled by the server. I guess this will get fleshed out more when I get around to implementing a shop in the game.
Routing messages to the proper server with Redis is on the todo list.
Initially I was playing around with OpenLayers as a map system but that needs to get replaced by a custom map system using Canvas.
I'd like to let as much as possible to be controlled by the mouse. Context sensitive menu's popping up over characters and items. A basic autocomplete system is in there, comes in handy for some games where a player has a name like Vrizzixmuxiwrll.
OLC - users will have a filespace with a quota for media content. I'm thinking python code can be written by an area builder but it has to go through an authorization by an administrator before it goes live. The only way to "securely" execute python code is through PyPy Sandbox and I don't even want to attempt to rig something up through that, so a human is responsible for watching for bugs and security vulnerabilities in user submitted code.
I'll put a demo server up at mmud5.org when the code progresses a bit.
16 Apr, 2012, plamzi wrote in the 4th comment:
Votes: 0
If you're looking for ideas about a UI that lets people do most things w/o typing, and if you have an iDevice lying around, take a look at my Bedlam app (it's free). Even if you decide to borrow nothing from it, it would be helpful to check it out, I think. I don't know of any MUD client that requires less typing.
06 Aug, 2012, Gicker wrote in the 5th comment:
Votes: 0
Still looking for help on this? I may be interested, depending on what the license for the source code will end up being like.
08 Aug, 2012, donky wrote in the 6th comment:
Votes: 0
I think your approach to security is the only way to go. There may come a time when it is not overly cumbersome to take advantage of PyPy, but that time isn't now.

As someone who has considered other possible HTML5 MUD solutions, the thing which has gotten in the way of my adoption or even experimentation with them, has been niche choices in backend solutions. Only providing a node.js backend? Okay, good luck with that. Only providing a Django or Twisted-based backend? Ditto. My ideal HTML5 client-side framework would have a simple library on the backend for the sake of example, which at best uses a standard library not tied to any frameworks (greenlet included).

But it sounds like you're looking at providing a complete end-to-end framework, right?
08 Aug, 2012, Runter wrote in the 7th comment:
Votes: 0
I disagree quite a bit about the security thing. If he's thinking about having builders writing python code that has unrestricted power and scope…well, there's better solutions. The risk from a security perspective is far too great to have to scan over every single line of code builders write to script. A nefarious builder could write tricky code that may hide what the code actually does until ran. You should be able to safely sandbox code. If you can't have at least basic protections for your scripting environment you have major problems with your approach. This is no security at all. Under this scenario, I wouldn't want to even write scripts myself in game if I were the head administrator of the game, much less have only psuedo-trusted individuals submitting code that I have to carefully review.

Quote
Only providing a node.js backend? Okay, good luck with that. Only providing a Django or Twisted-based backend?


I don't know what this means. You want the HTML5 projects to implement their own webserver? If you write all the code yourself you're based on a specific technology. Just one that isn't very standard. Anyways, what's wrong with using node.js? It's not even a library. It's a technology. That would be similar to saying you don't like html5 projects that use python, or ruby, or any other specific technology because it's a niche solution.

The timid nature of the mud community in using libraries has held a lot of progress back. It's not like it's hard to install libraries in things like node.js or python or ruby. It's basically free maintenance wise through a manifest. You don't even have to vendor stuff.
10 Aug, 2012, donky wrote in the 8th comment:
Votes: 0
Runter said:
The timid nature of the mud community in using libraries has held a lot of progress back. It's not like it's hard to install libraries in things like node.js or python or ruby. It's basically free maintenance wise through a manifest. You don't even have to vendor stuff.
I think you're hand-waving away a lot of the realities. Nothing is free maintenance-wise, everything is a complication of sorts, and a greater complication potential waiting to happen. You can't say that there won't be problems with node.js on someone's platform, or particular setup. And the choice to use Python would make a huge difference, depending on who would like to adopt whatever it is. I work on MUD code because it interests me. I think everyone does. The choice of technology used, the combination of tools, frameworks and libraries.. it all contributes to the experience and whether someone are able to stay interested in their project over the longterm. All these things matter. HTML5 is a technology. node.js is a framework. One is the standard, the other is an implementational choice.

But hey, that's just my opinion man.
10 Aug, 2012, Alathon wrote in the 9th comment:
Votes: 0
donky said:
You can't say that there won't be problems with node.js on someone's platform, or particular setup. And the choice to use Python would make a huge difference, depending on who would like to adopt whatever it is.


The same goes for anything else, really. I've yet to ever see a framework that doesn't have problems on any setup anywhere. And even if you can cherry-pick the implementation you want to use for this particular framework, then you'll
just have to instead deal with a different class of problems; consistency between your implementation / choice of tools against the general framework. As it so happens, that class of problems is often (IMO) a lot harder and more time-consuming
to deal with. And as Runter's alluding to, I think, it also means that the framework in question puts a lot more requirements in the hands of the developer using it. Which is fine if thats your goal, but if its not then you're missing the mark entirely
by doing so.

You'll always be making choices that are inclusive or exclusive of certain groups of developers, and the (smart) choices you make ultimately depend on and fit your end-goals. By and large the goals often lead to a
less generalized approach being the right one; even if one of the consequences is only appealing to a subset of users. In this particular case, the technologies picked are well-supported across the
board. I don't personally like Python much, so its probably not for me (Although I do like node.js), but there are plenty of other developers out there who feel differently. Although it scares me to think that my builders
would be able to potentially sneak Python code past me, intentionally or not.
0.0/9