29 Nov, 2009, Idealiad wrote in the 1st comment:
Votes: 0
Well, that's a complicated title for a 'simple' question – what would be a best-of-class way to integrate mud management, meaning issue tracking, developer documentation, and so on, and community management, meaning forum/mud accounts, dev diary updates, and so forth.

On the surface those two things don't seem that related, but when you consider things like player bugs/feedback and player generated content, in my mind the relation becomes more clear.

I think there are two approaches:

1. Separation of concerns through intention: in other words, you get an issue tracker for your game, or use a bug command in-game, you get a forum or stick with game boards (or game boards are IC and forum boards are OOC), you get a blog, a wiki, etcetera (not that you need all of these things of course), and there is a well defined intention for how you use each of these tools. You only ever put diary posts on the blog, all bugs go in the issue tracker when there is no bug command in game, and so on. Probably the easier of the two approaches.

2. Separation of concerns through interface: here, each tool is just a view on the underlying data, so in theory there could be a forum thread that is automatically updated with each diary blog post, bugs put in the web issue tracker are accessible through the in-game issue interface, and so on.

Of course these two approaches are more like either ends of a spectrum. I've seen some stabs at this kind of integration; for example, there's been a lot of work with SQL and mush servers, there seems to be extensive work with CoffeeMUD on handling game data in the browser.

A corollary is that the more time you put into all this crap, the less time you're going to have for the game itself. Is the investment worth the reward? Who knows of some examples of this stuff out there?
29 Nov, 2009, Mudder wrote in the 2nd comment:
Votes: 0
Is it worth it?

Depends on how easy it would be for you to set all of this up vs. How much you'd use it/need it.

If this is just "pretty fluff" then it seems like a waste of time if it would take you more than 2 days. Though if this type of interface would be extremely convenient for you and assist productivity - It would surely be a good move.

Personally for me this would fall under "pretty fluff" category and I wouldn't get much practical use out of it. Only you are really able to answer whether or not this setup would be helpful for you.
29 Nov, 2009, Dean wrote in the 3rd comment:
Votes: 0
I think I'll echo what Mudder has said here.

I can only see value in spending any great amount of time on implementing some fancy feature for this sort of thing unless you are expecting a large volume of issue reporting.

I've gone the easy route and added a specific board to our forum for bugs/typos/other issues. It's reasonably easy to find and use, easy for staff to track and respond to and doubles as an archive as well. Still have the stock bug, typo and idea commands though.
29 Nov, 2009, David Haley wrote in the 4th comment:
Votes: 0
Aww, and this would have been a perfect opportunity for the 'Spawn' functionality. :wink:

The reason I said "I woke up to reality" in the thread that started this is not that this integration is too hard, but that I'm not sure the payoff is worth the cost – which is basically what Mudder said.

A few things are worth integration, like being able to associate in-game issue reporting with online browsing, I think. If you want to encourage players reporting bugs, you want to make it easy to do so, and besides it's often easier to refer directly to the room they're in, the NPCs they're looking at, etc. It should be relatively easy to generate an issue creation message for whatever issuer tracker you have from within the MUD; getting feedback in the other direction would be harder.

I started writing a basic in-game issue tracker and got a fair ways with it, but the problem there is that it has no web interface at all. But that's not necessarily a problem. The real problem is that it is not nearly as feature-mature (and bug tested etc.) as packages like Trac (to name just one).

Anyhow, the point here is that all this is a lot of work, for obviously some payoff but not necessarily that much.
29 Nov, 2009, KaVir wrote in the 5th comment:
Votes: 0
Mudder said:
Is it worth it?

Depends on how easy it would be for you to set all of this up vs. How much you'd use it/need it.

Agreed, but it could potentially be used a lot - once implemented the same system could be extended to a wide range of different things, many of which would be of direct benefit to players. You could even allow people to play the mud through your website in the same way as a browser game.
29 Nov, 2009, Tyche wrote in the 6th comment:
Votes: 0
Idealiad said:
Who knows of some examples of this stuff out there?


The ColdCore database running on ColdC server. The reference server used to run at http://ice.cold.org:1180, but it doesn't appear to respond.
Anyway there's a web server written in ColdC that's part of the core and has access to anything in the database.
This included objects and their globals, method code, issue/bug tracking messages, help files.
One could also walk through the realms and view rooms and VR images.
There was no source control in the ColdC server, because that was implemented as backup scripts external to the game.

TeensyWeb and TeensyMud can easily be integrated.
TeensyWeb integrates a subversion repository browser, a wiki and forum code.
You can also browse objects in the TeensyMud database.
29 Nov, 2009, Davion wrote in the 7th comment:
Votes: 0
Darien released an internal webserver for his RoM (although, deeply gouged) codebase.

http://www.mudbytes.net/index.php?a=file...
0.0/7