25 Feb, 2013, Sorressean wrote in the 1st comment:
Votes: 0
hello all:
A couple of the muds I've played were really heavy on statistics, both for the players and the admins. I really like this idea because it gives people an idea of what's going on. I'd also like to expose clans, help files/etc to the website.
The way I'm thinking currently, I could either embed a web server within the mud, or I could make it external.
Each has it's pros and cons.
Embedding would allow me to just get data from the mud without any extra stuff, but I've seen web requests bring a mud down or slowing it down a lot. It's not multithreaded. With the level of locking I'd have to put into multithreading it might slow things down a lot more.
Alternatively I could expose some mechenism and either use php with nginx or node.js, but I'm not really sure how to expose the data I want. Most of my stuff is serialized through xml. Any information or tips would be helpful.
Thanks,
25 Feb, 2013, Markov_AU wrote in the 2nd comment:
Votes: 0
On AU we dump our data out for the web, though if we actually used an external DB on the back end instead of flat files it would have been simpler to just access the DB for things like helps/etc via perl or PHP.
25 Feb, 2013, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
[quote=[url=/index.php?a=topic&t=4192&p=65275#p65275]Sorressean[/url] I've seen web requests bring a mud down or slowing it down a lot.[/quote]

Is it relevant to have real time data ?
If so use a database or dump the values regulary somwhere so your game is not affected by the queries.
If not just create the page yourself from time to time, it reduces the kind of stats you show, but you control when it happens, so avoiding any potential lag.
25 Feb, 2013, Vigud wrote in the 4th comment:
Votes: 0
Quote
Embedding would allow me to just get data from the mud without any extra stuff, but I've seen web requests bring a mud down or slowing it down a lot.
Maybe make a heavy duty HTTP server act as a proxy and, on the mud server side, throttle requests per second?
25 Feb, 2013, salindor wrote in the 5th comment:
Votes: 0
You could always use perl to parse your data files–after all that was its original purpose. Though I kind of feel bad making the suggestion sense I don't like perl and can't really write more than 2 lines myself.

Salindor
26 Feb, 2013, Arithorn wrote in the 6th comment:
Votes: 0
For what it's worth, I'd figure out the end result first.

You mention statstics - are they to be live? Calculated/updated each time I hit refresh or are they going to be updated in a specific time interval?
Helpfiles - do you want to edit/add as well as display?
Player messages? Channel conversations? etc. etc.

All this will affect the "best" way to achieve the result you're after.
26 Feb, 2013, Nathan wrote in the 7th comment:
Votes: 0
Arithorn said:
For what it's worth, I'd figure out the end result first. …


Seems like sound advice. Scheduled updates seem a lot safer than refresh on demand, since someone could easily sort of "DDOS" you with update requests if they had unlimited ability to demand a refresh of the data. Start with read-only data. I think a database backend shared between the site and game or an external "API" of sorts makes the most sense for a data heavy environment. If all you have is simple data, then a built-in webserver makes more sense on the practicality end.
:
26 Feb, 2013, Kline wrote in the 8th comment:
Votes: 0
Sounds like the perfect use case for migrating to a common DB backend that can be accessed and modified from various sources. Implementing a HTTP service into the MUD, although having been done before, seems like "square peg, round hole" when there are more elegant solutions without the added complexity and security issues you would then have to deal with.

Also, a shared DB would let you decouple the web hosting from the game hosting. You'd be free to run your web frontend on a large shared hosting company while you keep the game on a separate VPS/other server. Then you also eliminate any concerns of DDOS/bandwidth overages due to web traffic if you host your game with minimal resources (free host, small VPS, etc).
27 Feb, 2013, Tyche wrote in the 9th comment:
Votes: 0
There is certainly something seriously flawed in an embedded web server that brings a mud to a crawl.
27 Feb, 2013, KaVir wrote in the 10th comment:
Votes: 0
Tyche said:
There is certainly something seriously flawed in an embedded web server that brings a mud to a crawl.

Agreed. In my opinion, that's the sort of thing that really should be multithreaded. In GW2 the embedded webserver has its own thread.

Rarva.Riendf said:
Is it relevant to have real time data ?

Probably not just for stats, but the advantage of an embedded web server (or a shared database, as you mentioned) rather than a timed data dump is that data can be sent both ways, which is necessary if you want to allow players to log in to their mud account via the website. Once you do that, you can offer all sorts of functionality via the website that's tied to the mud character - forums, polls, chat, private messages, auctions, building and equipment management tools, etc.

Another option would be to embed the web server into a separate program, which then connects to the mud like a bot, using some means (such as MSDP) to obtain data directly. Something like that would have the advantage of not requiring any changes to the mud itself (other than adding the necessary protocol support if it's not there already), and it could even be hosted on a separate site from the mud if you wished.
27 Feb, 2013, Rarva.Riendf wrote in the 11th comment:
Votes: 0
Kavir: yeah my question was more to make him state what he really want to do or intend to do in the future. Defining the problem clearly is way more than half of the solution.
27 Feb, 2013, Nathan wrote in the 12th comment:
Votes: 0
KaVir said:
Tyche said:
There is certainly something seriously flawed in an embedded web server that brings a mud to a crawl.

Agreed. In my opinion, that's the sort of thing that really should be multithreaded. In GW2 the embedded webserver has its own thread.

Rarva.Riendf said:
Is it relevant to have real time data ?

Probably not just for stats, but the advantage of an embedded web server (or a shared database, as you mentioned) rather than a timed data dump is that data can be sent both ways, which is necessary if you want to allow players to log in to their mud account via the website. Once you do that, you can offer all sorts of functionality via the website that's tied to the mud character - forums, polls, chat, private messages, auctions, building and equipment management tools, etc.

Another option would be to embed the web server into a separate program, which then connects to the mud like a bot, using some means (such as MSDP) to obtain data directly. Something like that would have the advantage of not requiring any changes to the mud itself (other than adding the necessary protocol support if it's not there already), and it could even be hosted on a separate site from the mud if you wished.


What's the difference in operation, in your mind, between a shared database and an embedded webserver? I suppose the shared db has to implement authentication for itself, if it's done that way?
28 Feb, 2013, KaVir wrote in the 13th comment:
Votes: 0
Nathan said:
What's the difference in operation, in your mind, between a shared database and an embedded webserver?

There would obviously be differences in their implementation, but you should be able to achieve the same results with either approach.

Personally I have very little skill at web programming, so it makes things easier for me if I can do the bulk of the work in C++ and then use the website as little more than an interface. I've also used the same approach for a combat simulator for the Savage Worlds tabletop roleplaying game. It even allows me to post direct links to real-time comparisons like this.
02 Mar, 2013, salindor wrote in the 14th comment:
Votes: 0
Tyche said:
There is certainly something seriously flawed in an embedded web server that brings a mud to a crawl.


That is completely depending on the implemention of the webserver. I have implemented embedded webservers in soft real-time designs for an embedded processor.


KaVir said:
Agreed. In my opinion, that's the sort of thing that really should be multithreaded.

I am not so sure about that. I mean on one hand you can take advantage of having multiple CPU's running concurrently, and today where every computer seems to have 8 cores, that seems very wise.

However, then you have to start worrying about context switching and protection of variables. If your querying a database backend, then it doesn't matter. However, if your just querying your local variables it could potentially be problematic. I guess on the other hand if all you are doing is reading the game state but not allowing any pushes, then even if there is a concurrency bug it doesn't matter as a simple refresh will fix any issue that may have come up.
03 Mar, 2013, Tyche wrote in the 15th comment:
Votes: 0
salindor said:
Tyche said:
There is certainly something seriously flawed in an embedded web server that brings a mud to a crawl.


That is completely depending on the implemention of the webserver.

Obviously.
The same would be true of a mud where players issuing commands brings it to a crawl.
I know ColdCore implements both a mud and web service not subject to these problems.

salindor said:
However, then you have to start worrying about context switching and protection of variables. If your querying a database backend, then it doesn't matter. However, if your just querying your local variables it could potentially be problematic. I guess on the other hand if all you are doing is reading the game state but not allowing any pushes, then even if there is a concurrency bug it doesn't matter as a simple refresh will fix any issue that may have come up.


Yeah…something as simple as iterating through a who list needs to be protected, because functions that modify the list (players login and logout) in the main thread may cause race conditions as pointer modifications aren't atomic.
04 Mar, 2013, quixadhal wrote in the 16th comment:
Votes: 0
Isn't the usual way to handle this, without multithreading, to set up an alarm timer on the parts of your main loop which might cause trouble? That way, if the web server routines hang, the alarm handler will let you decide to kill them off, or do something else to truncate the operations so the rest of the game doesn't lag.

If you, somehow, get a lot of traffic, you might also want to ensure you limit the number of connections you handle per loop iteration.
19 Mar, 2013, Sorressean wrote in the 17th comment:
Votes: 0
hello all:
Thanks for all the feedback; it seems I left this thread to long.
Basically here are my thoughts:

-multithreading the mud:
This leads to a lot of issues. My game is really modular, so being able to embed the web server lets the modules register handles to the web server so it can do what it wants to with requests. The web server at this point just becomes an interface. Something like: web->RegisterHandler("help", boost::bind(&HelpManager::WebHelp, this, _1); where the request gets passed in would be awesome. Then everything just deals with the web API and that's got that solved. I could even use a quick html builder I could build to make generation of pages super easy.
The issue comes in at concurrency; I host on a linode, so the multithreading wouldn't be an issue on the hardware. Where it would be an issue is with the mud. As already mentioned, someone may be editing or deleting a help entry as someone opens up the page, which could obviously cause trouble. making the server multithreaded would be a problem because there is so much lock acquisition that would have to happen. For example when a player moves to a room, you have to acquire the lock on the contents, move the player if it can be moved, then acquire a lock on the new location's contents to put the player back in. I foresee a lot of stuff actually hanging waiting for locks, especially with combat.

-A centralized database:
This seems like another idea, but it brings a whole new level of complexity to the mix. I actually have to define tables, then somehow update these tables with new content. It would actually require that I roll out help files to a database which I'm not to big on.

-An API:
I really like this idea, so any suggestions and ideas would be awesome. If I could use a server like nginx to serve up the data and some sort of API to get the data from the mud, I could potentially cache requests for a speed increase. This could be done at the API level on the mud server, or via a reverse-proxy over nginx.

To answer a few questions, I had origenally decided that just serving up static pages would be nice; I can update the stats every once in a while (every 5 minutes or so?) on the mud and send them out, though allowing people to edit stuff on the server would be incredibly nice too, which would add a lot of complexity to the mix. I currently store my data in xml files, for a couple of reasons. I was able to quickly serialize and deserialize data into actual game objects which was incredibly useful. Also I have a component system for objects that would be extremely difficult to model in a mysql table. For example, builders get a basic bare object they can do what they want with. When they create a virtual object, it has the bare minimum for what would be needed; a name, a description, a location and contents as well as a uuid. If they wish to add features to this object, they do it through adding components. So, for example if they wanted a backpack you could wear they would add the container component which gives them container-like functionality, as well as the worn object which specifies where the object can be worn/etc. Given this, unless someone has a really good idea for how to handle this in a database, I'd like to stick with flat files.

Again, thanks for the information/advice.
19 Mar, 2013, Idealiad wrote in the 18th comment:
Votes: 0
Could you have a data table for each component with the key being the object's uuid? Then the object has a list of components and that's what you use to build your query.
19 Mar, 2013, quixadhal wrote in the 19th comment:
Votes: 0
Moving help pages to a database is pretty common and one of the FEW things you can do without a major impact on the game system. How many times do you envision more than one builder/dev editing the same help entry at the same time?

As to the "somehow update tables" part… Stop thinking of a database as some afterthought to be updated. Start thinking of it AS your filesystem. Once you push your data into it, you can and should edit it directly, never having to touch flat files again.

My suggestion remains building a database access script and having your MUD talk to that script via a socket. There's no need to add all the complexity of a C or C++ database API, and the annoyances that will come if you change databases, or if the database is updated and you lose compatibility. Make a simple and clean API for your MUD to interact with the script, and let the script do the lifting.

For a help system, it could be as simple as "GET helppage" or "PUT helppage content-string".

An added bonus of putting help pages in a database is you can easily write a web page to access the content. A tiny PHP script, and now all your help files are browseable online with the exact same content they have in-game.

I find many people do LOTS of extra work to code everything in C++, because they're too snooty to accept that scripting languages are simply easier to work with for small, simple tasks. You aren't building World of Warcraft with millions of uesrs.. you're building a MUD. If you ever get 200 players, you're a HUGE success, and I can't imagine any scripting language not being able to keep up with that level of traffic, even if you put your entire game in the database.
19 Mar, 2013, Sorressean wrote in the 20th comment:
Votes: 0
I totally understand that. I've explained why I actualy can't use a databvase.
Someone's random one-off "just store components in a table" doesn't work all that well; each component would get it's own table and ID. So you could do an association of objects to components (objid, componentid), but you have no way of knowing which ID you're actually using.

I like the API idea, but it's something that would be incredibly slow to use for updating and retrieving data for the mud. It would honestly be easier to handle sql stuff on the c++ side rather than going to a script that would actually do the same.
0.0/30