[Raesanos]

Recently, in Armageddon, I've been making more pages use dynamic content on our website. The key target of course is constantly changing information that is listed in many places.

For example, each staff member is shown their responsibilities with a link to update them via an HTML form. Many pages on the site list contact information and the information is far more accurate with less work to maintain when people can update their own responsibilities in one place.

What other successes have people had with doing this kind of thing? What other information do people think is beneficial to have dynamically generated? What about failures, is there anything that just didn't work out?

[Kinnith]

[Angie]

On Midnight Sun, we generate quite a lot of the webpage content dynamically. The most obvious are the who list, fingering players, toplists and help files. A lot of people use the webpage to read the ingame message boards and their mudmail, although the boards system is a bit outdated. Some ingame resources, such as books of player lore, the newbie book or the newspaper are accessible through the web as well, the questbook reflects which quests the player has solved and which not (if they're logged into the webpage). Things like the list of areas are generated dynamically too.

On the immortal side, we have a web interface that lets us control and manipulate bug/typo/idea reports, and an older interface for pruning error logs, which are both nice additions. The coding documentation on the page is dynamic as well...

Can't say we would have run into anything that doesn't work - as long as it works in game, it works for the webpage as well, but of course Armageddon as an RPI mud may have different policy and criteria as to what is desirable.

[Brody]

At our site, we do a lot of dynamically generated content using PostNuke/PHP. It's been a big help.

[Traithe]

Yeah, same with us; nearly every page on our website at SoI has some sort of dynamic, php/mysql-generated content on it.

Particularly lifesaving are the and the - I can't even begin to imagine trying to do both by hand.

On my next project I'm going to try moving a step up to RPC, which will allow the webpage to query the gameserver itself and obtain all sorts of information - not just the stuff that's actually been written to the database. So, we'll be able to query and integrate just about any in-game information needed, in theory.

[Traithe]

Oh, incidentally, something else that I should probably mention; my main goal with the SoI website was to ensure that the game could be run by people without any clue how to update webpages without the site itself suffering any detrimental effect.

So, the staff-list on the site auto-updates, the weekly newsletter that's sent out automatically is also added to the site's public newsletter archive, staff members can add/delete/modify downloadable files in our file vault via an application in the staff portal area, etc., etc.

It's a huge burden off my shoulders, since all the time I previously spent managing the website way back when we used a static one can be spent elsewhere now - the time investment is a little steeper up front to get everything working to that degree, but it was definitely worth it.

If you have any questions or would like more specific information on how it works, feel free to drop me a PM or an email.

[Raesanos]

It sounds like a lot of people have done similar things to what we have done, such as letting players see data that you'd traditionally get in game (such as helpfiles) and allow staff to manage game data through their browser.

I think what specifically got me thinking, and subsequently posting this thread, was the notion of managing data that isn't drawn from the game itself. My staff responsibility list above was an example of what I mean; this data is not used by the MUD itself but makes sense to centralize from a web design standpoint. Another thing I'd like to do like this is our list of players who volunteered to be a resource for newer players.

Traithe said was that their website's staff list auto-updates, and I'm assuming that means from game data. Interestingly, I made a system that works the other way: the in-game staff list auto-updates from a database that is managed via the website. I could see advantages either way, which way makes sense probably depends on how the particular MUD is set up, but its interesting to see a different approach.

[Netwyrm]

My site is wholly generated with PHP and MySQL. The site itself has been updateable through a web editing system I wrote long ago, along with a fairly standard array of support template files for styling, graphics, etc.

It's very simple, with a one-to-one relationship between editor and subject and a menu to tie them all together, but I've done a lot of writing, typo fixes, etc. from just about anywhere through it.

One of my peeves is I just hate trying to keep long lists of things in sync yet continually have created long lists of things that must be kept in sync... like monsters and abilities and so on, and have to represent them in different environments.

The most interesting thing is I am working on is to expose the statistics for say, monsters, both to the game engine and to the website, so when I update the stats on the website, the game receives the new information, and when I update the stats in the game data, the website picks the change up...

I'm not quite live with my latest game rewrite/disaster yet, but changing over from the endless static text files I had in previous versions of my engine to represent states to using a database has had such convergent applications pop up. I'm looking forward to discovering more.

I cannot really communicate just how long I dithered with one type of storage for the game server and another for the website, until I finally broke down and put in the skull sweat needed to figure out how to get my game server to talk to the same databases my website was working.

I highly support your hypothesis, Raesanos, that central stores of information are much better than disparate ones when you want to use the same data twice in an application. After that, you can expose it to staff, or players, or use it in the game. It's advantageous.