28 Dec, 2011, JohnnyStarr wrote in the 1st comment:
Votes: 0
While developing my project Roma (a ROM web based OLC) I am at a crossroad. For so many years I have wanted to run a traditional ROM and have tons of awesome areas already written. My import routine is about wrapped up and I am ready to dump the data in Roma's database.

While designing the Room building section, I decided to have it presented in a terminal screen fashion for added testing purposes. The more and more I tinkered with it, the more I realized how much it resembled an actual MUD.

As I continued to explore this path, I started to brush up a bit more on AJAX. Writing a quick input / output mock-up was easy as pie.

Obviously, there is a lot to consider here. A conventional MUD server has a lot more than typing commands and traversing data records. And that is what I hope becomes the bulk of this discussion.



There are two main concerns when considering the proposal of a web based MUD.

1) Events. How exactly would real-time (or seemingly real-time events occur?)

2) Communication. I am aware that AJAX can use a shared XML file to sort of hack a chat feature. I also know about HTML-5 web-sockets. I would like to explore the latter.

Any thoughts? I know Runter has something similar going on.
28 Dec, 2011, Runter wrote in the 2nd comment:
Votes: 0
The simple answer is that you have to use a "push" technology. http://en.wikipedia.org/wiki/Push_techno...

This is different from the typical model because usually you must initiate a request from the server to get something back. Two web servers can communicate with each other by using various requests, assuming the client implemented at least a post route to receive data. This isn't possible in using browsers, and even if it were..not recommended.

You mentioned websockets, which is the ideal solution, but it's still young. So the best answer is going to be web sockets with systematic fallbacks to worse technology until one is supported by the client. You can either have the headache of doing this yourself, or you can find a library that does it for you. Like this: http://socket.io/
29 Dec, 2011, plamzi wrote in the 3rd comment:
Votes: 0
Speaking of fallbacks, there's always the option to keep your server as is, and use Flash for communication. It's nearly omnipresent on desktops. For mobile platforms, it seems like we'd have to wait a bit longer for a new standard.
29 Dec, 2011, JohnnyStarr wrote in the 4th comment:
Votes: 0
As far as linear game logic, here's what I have so far:

1) user sends "west" command

2) the command is parsed by client-side scripts

3) the "west" command is processed locally
a) AJAX is utilized to handle movement routine on server

4) PHP movement routine is processed:
a) retrives database record of destination room and contents
b) encode the room and containing objects into a json string
c) send the json string to client

5) de-serialize json string into json object.
a) Display room and contents.

Of course, it may be desirable to use an XML cache instead of tapping into
SQL, but that is another story. The point here, is that the more that
can be done on the client-side the better. This way the app is more
scalable.

The challenge that I'm facing though is what to do with mutable objects.
JSON makes it easy to modify and update. But I'm not sure how the object
state could be shared.

If I move my player to the "cafe" and buy a drink, how will the other customers
know about it? If I set my cup on the table, can another player pick it up?

Even if the player's environment is updated on the database - bandwidth issues aside -
there are still real-time holes in this theory.
29 Dec, 2011, plamzi wrote in the 5th comment:
Votes: 0
JohnnyStarr said:
As far as linear game logic, here's what I have so far:

1) user sends "west" command

2) the command is parsed by client-side scripts

3) the "west" command is processed locally
a) AJAX is utilized to handle movement routine on server

4) PHP movement routine is processed:
a) retrives database record of destination room and contents
b) encode the room and containing objects into a json string
c) send the json string to client

5) de-serialize json string into json object.
a) Display room and contents.



Even if the player's environment is updated on the database - bandwidth issues aside - there are still real-time holes in this theory.


I think you need to give Runter's wiki link another read. The hole in your theory has to do precisely with lack of a push method:

6) show any other players already in the room that the player has walked in.
Because you can't push that event to them, you will need to set the client to pool for changes repeatedly. In the best case, this means permanently poor responsiveness with annoyingly varying delays (depending on how long after my last pull a fellow player walks in the room). It will also eat up your server bandwidth like crazy, even if you just send empty responses when nothing has changed.

I have a real-time web-based automap currently set to pool for changes every 0.6 seconds. The experience is bearable only because latency is not that important for a location map. Also, I host it on my home server so I don't pay for bandwidth. You can take a look at the automap's responsiveness in the Bedlam web app and compare it side by side with the responsiveness of the main telnet input (via Flash).
29 Dec, 2011, Runter wrote in the 6th comment:
Votes: 0
The other solution is designing the game such that you don't need to know things immediately. Like, information isn't updated about who is in the room until you look again. Each round of combat is initiated by the player. Things like this. This is common in web based games that have a hybrid single player experience. Maybe with the only interactions with other players being chatting/trading items. The more advanced the game, the more you're going to need to use a push technology to get real time interactions. I think you can get by just using websockets and flash websockets as a fall back. Those two cases cover a vast majority of users.
29 Dec, 2011, JohnnyStarr wrote in the 7th comment:
Votes: 0
@Runter

I think you are right. Perhaps expecting the game to behave exactly like a MUD
is too tall an order at first.

As far as "pushing", and polling for events:

Without doing research, I assessed a solution on my own. The idea was to have a
session variable (PHP array) that kept track of events. The client would have a
timer that polled the server via AJAX once a second. The event array would be sent
to the client and handled accordingly. Obviously, the event array would be cleared
for the next queue.

Plamzi sort of addressed my concerns about bandwidth. But my hosting through fatcow
has unlimited bandwidth, so I dunno if it's that big of an issue.

Do websockets use TCP/IP or HTTP?
29 Dec, 2011, Runter wrote in the 8th comment:
Votes: 0
Yeah, you should consider long polling. It's far more reasonable for not wasting resources. http://en.wikipedia.org/wiki/Long_pollin...

websockets use something similar to http to handshake, but it's a TCP connection on a separate port. It's analogous to what muds normally do wrt connections.
29 Dec, 2011, JohnnyStarr wrote in the 9th comment:
Votes: 0
Simple seeming enough. It looks like you could do something like:

for ($c=1; $c>10; $c++) {
if ($_SESSION['events']) {
echo (json_encode($events));
$_SESSION['events'] = null;
} else sleep (1);
}


In this case, the persistent connection lasts up to 10 seconds at a time.
I wonder how many users the server could handle at a time though.

I don't anticipate having more than 10 players at a time, but who knows?
Web based mudding just might exceed our expectations.
29 Dec, 2011, Runter wrote in the 10th comment:
Votes: 0
Yeah, if you're not having that many users at a time, you can almost do anything you want without concern for efficiency or scaling issues.
29 Dec, 2011, JohnnyStarr wrote in the 11th comment:
Votes: 0
Does anyone know what kind of limitations this might have?

300 players?

3,000?

3,000,000?

I would like to think several hundred.
29 Dec, 2011, Runter wrote in the 12th comment:
Votes: 0
It's not really a question of how many the pattern will allow you to have. It's a question of how much will it cost you to run when you have 3000 players. The bandwidth costs will just be much higher if you're polling. Linear, but much higher. So multiple times the cost of hosting if you're paying for bandwidth, or have limits on your hosting.

Furthermore, the client hitting your server with http requests every second is unneccary processing for your webserver to have to process the request and send back content basically saying "nope, don't have anything for you."

So the statistic most web servers deal in is request per second. If you're using ajax you're dealing with the same statistic so it may be easy for you to find out how many requests per second you can do with a dedicated server right now. In my experience, 5kc barrier is hard to break without superior hardware configurations and load balancing with most web servers. So consider 5000 requests per second. If you polled every player 1 request a second that's 5000. So 3000-5000 may be a good estimate if you're polling before you even take into account other processing you may need on your dedicated middle-of-the-line box. 3,000,000 would be out of the question without a different hardware configuration and a fortune to spend on servers.

Assuming everyone is using a websocket, that will change dramatically. Because you just wouldn't have to do as much work to get bytes of data from player to server and server to player. Meaning more players for less resources.
30 Dec, 2011, JohnnyStarr wrote in the 13th comment:
Votes: 0
So,
Socket.io is an extension of Node.js right?

In theory, I can run my web application on my web server. And run a Socket.io server on a server that runs Node.js, and my webpage would use javascript to access my Socket.io server?

Am I understanding correctly? In other words, I cannot host the Socket.io server a webserver because it's a telnet application right? I have FatCow and they don't offer SSH, so I'm assuming it wouldn't be able to.
30 Dec, 2011, Runter wrote in the 14th comment:
Votes: 0
Socket.io is a protocol that will attempt to use a variety of underlying transport technologies (starting with the best, going to the worst) until one works.

https://github.com/LearnBoost/socket.io-...

Quote
xhr-polling
xhr-multipart
htmlfile
websocket
flashsocket
jsonp-polling


That's a list of the technologies it attempts to use to transport the data.
0.0/14