14 Apr, 2011, Runter wrote in the 1st comment:
Votes: 0
HaikuMud has been a concept that's went through evolution over the last 6 months. I've restarted the project at least 4 times and refined the direction I've went with it. It's unrelated to CoralMud. I'm proud to say I'm really happy with the initial results of its latest reincarnation.

HaikuMud aims to be a framework that's fit for building Mud-like games. It makes no assumptions about legacy or even the existence of other muds/games before it. It leverages HTML/Javascript for the client. The mud server/backend is in Ruby. Sinatra (not rails) is used for the web server. There's no flash and no java. The technology used for the connection is web-sockets (supported by all major clients currently) and it falls back to flash-sockets (which are very widely supported as well.) This server has no plans to support TCP out of the box. The project is based around the idea of full integration between the web server (serving the html/js client and web site, as well as the connection stream) and the backend game server.

All this may sound very similar to Twisol's project in many ways. And it is very similar with regard to the client technology. We're actually good friends, and we bounce ideas back and forth every day, and he's had heavy influence in this project.

Here's a screen (that's a normal mud scrolling region, connected to just like you'd connect to any mud). The difference is it's pushing data instead of pure text down the pipe. But it's coming straight from a web socket session.


Here's the github site where the code is/will be hosted. It's open source and available under the MIT license.
HaikuMud

And here's some answers to a few questions I've already had come up:

So why no legacy? And what advantages would you have in using a html/javascript client solely?

To address the no legacy angle. It's because there's plenty of mud servers that support legacy. You can connect with just about any tcp client and you're ready to go. I wanted to do something different. Basically, this is an attempt to make a framework for people who want a client that's required to play their game. There's power in that. With html/js (using jquery, jqueryui or your favorite library) you'll be able to do impressive things that are only minimally possible in clients such as mushclient or cmud, even with addons. That could be drag and drop interfaces, inline graphics, animations, resource selectors, upload forms (players can host their own avatars), and it's really limitless.

Is this just a web page?

No, it's not. The web sockets are for real time data transferring both ways. You could make a clone of any traditional mud using the same technology if you really wanted to. Currently the html client and the server communicate with json packets. So it's as much of a web site as mushclient with graphical components would be.

Do I have to use a specific client?

Yes and no. You have to use a web browser(or custom client that can render HTML) that fully supports the technology being leveraged. That being said, all of the major ones do, and you get even more consistent and better support from device based browsers like phones. So no mushclient or telnet connections accepted– Unless you really want to, but that destroyed the power of being able to transfer html/js to the client. Out of the box it won't even be supported. This project is really fit for someone interested in making their own client and experience necessarily.

Could I install an existing mud server for the backend?

With heavy modification, yes. Specifically it has to implement web sockets. There's libraries out there for it, and implementation isn't impossible, but that's the key. The web server doesn't have to be fully integrated with the game, but I think it's useful. It lets you manage the user account from the web site painlessly, as well as other niceties.

Love to hear more questions/comments. I expect to finish a lot of work on this project over the next few weeks. Also, I'm looking for a temporary home for the proof until the 26th (at which point it'll have a permanent home online.)
14 Apr, 2011, Twisol wrote in the 2nd comment:
Votes: 0
Runter said:
The technology used for the connection is web-sockets (supported by all major clients currently)

Just to add some hard evidence (if you accept Wikipedia as such):

14 Apr, 2011, Cratylus wrote in the 3rd comment:
Votes: 0
i has the same desktop background lol
15 Apr, 2011, Chris Bailey wrote in the 4th comment:
Votes: 0
Dang, well I guess I'll drop my project and start working with yours. :P
15 Apr, 2011, plamzi wrote in the 5th comment:
Votes: 0
Good work, Runter. I'm sure websocket is the way of the future. But, am I accurate in stating that currently only WebKit browsers (Safari, Chrome) have full websocket support that is also enabled OOB?

This page seems to say so: http://en.wikipedia.org/wiki/Comparison_...
15 Apr, 2011, Runter wrote in the 6th comment:
Votes: 0
plamzi said:
Good work, Runter. I'm sure websocket is the way of the future. But, am I accurate in stating that currently only WebKit browsers (Safari, Chrome) have full websocket support that is also enabled OOB?

This page seems to say so: http://en.wikipedia.org/wiki/Comparison_...


I think that's true. There was a security issue a few months back and a lot of them had it disabled by default until the issue was solved. Some say this was hasty though, since the security flaw still exists in flash and java sockets (which are enabled in the browsers.) I expect that it'll be enabled against before the end of the year by default. I think Google acted the most responsible of the group by not having a kneejerk reaction there. I'm not sure about I.E. and what hoops you jump through to get them working. Ultimately if web sockets don't work the fallback is probably going to remain flash sockets. Most users have flash installed.

edit: Fixed for Twisol. He claims I use too many spaces after periods.
15 Apr, 2011, Chris Bailey wrote in the 7th comment:
Votes: 0
You do have a pretty solid space after your punctiation marks. Looks like a tab!
15 Apr, 2011, Igabod wrote in the 8th comment:
Votes: 0
Way back in 8th grade when I took keyboarding class they taught us to put two spaces at the end of every sentence. I never understood why, and had great difficulty hitting the space bar twice. I tended to get lower grades because of that.
15 Apr, 2011, Tijer wrote in the 9th comment:
Votes: 0
Quote
Way back in 8th grade when I took keyboarding class they taught us to put two spaces at the end of every sentence. I never understood why, and had great difficulty hitting the space bar twice. I tended to get lower grades because of that.


Same, but probably in 1991, still do it :)
15 Apr, 2011, kiasyn wrote in the 10th comment:
Votes: 0
Its funny you posted this. I had just got my basic prototype of basically this same thing up and running yesterday :)



Very similar to yours in a lot of ways, using json for packets (although mine doesnt dump them straight to scrollback, it parses them a bit to decide what to do with them)

the mapper is an HTML5 canvas. the health /energy bars are jquery progressbars :)
15 Apr, 2011, Chris Bailey wrote in the 11th comment:
Votes: 0
Mine isn't nearly as pretty as yours and Runters. :P
15 Apr, 2011, quixadhal wrote in the 12th comment:
Votes: 0
Great to see this Runter, maybe all my ranting about JSON wasn't in vain. *chuckle*

Oh, Igabod, you use two spaces after a sentence to provide a solid visual clue that it's the end of a thought. Using only one space makes it too easy to mistake a period for a comma, and thus not realizing it's a new sentence until you've read half of it. :)
15 Apr, 2011, Rarva.Riendf wrote in the 13th comment:
Votes: 0
I am curious about your automap: what happens when it is a maze with circular references and so on ?
15 Apr, 2011, Runter wrote in the 14th comment:
Votes: 0
@Kiasyn Looking good. From what I can see yours is definitely more polished than what I have going so far. I'll probably use canvas for mapper as well, but I haven't decided yet if that's better than just doing it through markup.

@Quix Thanks. Think I should implement the telnet protocol in my websocket server/client? :)

Rarva.Riendf said:
I am curious about your automap: what happens when it is a maze with circular references and so on ?


Even the worst mapper algorithm should be resilient to circular references…it just wouldn't display anything not logical in a logical way. At least, most that I've seen.
15 Apr, 2011, plamzi wrote in the 15th comment:
Votes: 0
Runter said:
Rarva.Riendf said:
I am curious about your automap: what happens when it is a maze with circular references and so on ?


Even the worst mapper algorithm should be resilient to circular references…it just wouldn't display anything not logical in a logical way. At least, most that I've seen.


Circular references can be skipped over without losing information, but what about situations where east-south is a different room than south-east? That's a very common scenario and so far the only automapper I've see that handles it is, ummm, mine.
15 Apr, 2011, Runter wrote in the 16th comment:
Votes: 0
plamzi said:
Runter said:
Rarva.Riendf said:
I am curious about your automap: what happens when it is a maze with circular references and so on ?


Even the worst mapper algorithm should be resilient to circular references…it just wouldn't display anything not logical in a logical way. At least, most that I've seen.


Circular references can be skipped over without losing information, but what about situations where east-south is a different room than south-east? That's a very common scenario and so far the only automapper I've see that handles it is, ummm, mine.


But south-east is a direction. "east-south" is not. :) So how in the world would an automapper know what to do with that, anyways?
15 Apr, 2011, David Haley wrote in the 17th comment:
Votes: 0
plamzi said:
Circular references can be skipped over without losing information, but what about situations where east-south is a different room than south-east? That's a very common scenario and so far the only automapper I've see that handles it is, ummm, mine.

If all you mean is that the exits aren't of the same "length", rather than there being some fundamental violation of geometry as one might find in mazes, then any number of graph layout programs can do this. I don't know if you were referring to just MUD-specific mapper programs, though.


EDIT: Re: Runter:
I think that he meant to go south then east vs. going east then south.
15 Apr, 2011, plamzi wrote in the 18th comment:
Votes: 0
David Haley said:
plamzi said:
I think that he meant to go south then east vs. going east then south.


Yes, I mean go south, then go east, vs. go east, then south. Every other automapper I've seen just ignores one of those rooms. In a totally "chessboard" world, that works, but mine is definitely not a chessboard one.
15 Apr, 2011, David Haley wrote in the 19th comment:
Votes: 0
I'm pretty sure that there's a mapper on Nick Gammon's forums somewhere that handles this correctly. It's actually not a super-hard problem, and there are far more difficult issues to cope with when building a mapper (in a usual MUD experience, at least, where you do not have access to things like your current room's unique ID). Twisol would know more about it, I think, since IIRC he was involved in the project one way or another.

(Too bad we don't have a ping/@mention feature to draw somebody's attention to a thread…)
16 Apr, 2011, plamzi wrote in the 20th comment:
Votes: 0
David Haley said:
I'm pretty sure that there's a mapper on Nick Gammon's forums somewhere that handles this correctly. It's actually not a super-hard problem,


I think I solved it for 2 rooms away but I couldn't even begin to imagine a useful spacial representation for 3 rooms away (e. g. s-e-e is different from e-e-s is different from e-s-e). Maybe it's not super-hard to draw, but it is hard to do it in limited space and in such a way that it would help the player more than confuse them. If you know of a mapper that can do that, I'd be curious to see how it's pulled it off.

David Haley said:
and there are far more difficult issues to cope with when building a mapper (in a usual MUD experience, at least, where you do not have access to things like your current room's unique ID).


I think Runter's project targets MUD devs and not people who want to develop a generic web-based client and won't have access to unique room ID's etc. I could be mistaken.
Random Picks
0.0/93