[Raewyn]

Dear TMS members,

Given today's current technology, would it be within tangible reach to create an in-game logging system that could record essentially everything that is sent through the main program? Player actions, game states, objects, mobiles, gold -- enough information so that if needed, an administrator could set the time and place and be able to "replay" exactly what happened and when, being able to move and view events as a separated third-party.

By all purposes, one could "travel back in time" and determine how a bug was exploited, why the government collapsed, or even just follow up on a major player event. Someone could go back to obtain as close to historical accuracy as possible.

Though the applications for it may be slim, could it be done? It would not just read plain text scrolling, but the actual commands that were executed and when. Essentially, all it would need to record is the state of the game and what was going on at the time. How much space would the stuff take up say, over the course of 5 years running 24-7?

[Kinnith]

Well, it is quite possible, infact some MU*'s have a limited logging system in place, Logging the last number of commands before a crash, and any command flagged as to be logged.

The Main problem with this, as I can see, would be space, from the buildup of all the actions of each player.

I had a player "logged" which shows each command, including anything past said command; Ie. "kill <name> blah blah blah"

Within three days of this, I had a startup log (where it stores the startup data, errors, bugs, ect) that was about 14 Megabytes. It does include some other data's, but mainly the file was around 12 Megabytes of just that players command input.

Now recording say, the room desc', any other players in room, color codes, and any of the data sent to the player, would build up a very, very large file.

It could very well be done, and while it could be a great idea, unless very limited to how much data is to be stored; as the last hour of game play before a crash, you could run out of space before you know it.

I hope this helps in general, overall, while it gives no real insight to do it, just my thoughts, and exp. with my code and log files.

[the_logos]

Logging all commands isn't a big deal. Just use a rotating 30 day (or whatever) logging system. On the day changeover, the oldest file gets deleted and a new one gets created. Simple enough.

Trouble is, for what you're talking about it's not just recording the commands and when. It's recording every change of state in the game, and THAT is a way bigger deal.

--matt

[Ashon]

Sure, it's possible. Is it worthwhile? Probably not. I'm not sure why you would want to log game states. You could plug in some code in Send_To_Player and Send_To_Room, that write to a log (how ever you want to do the logs). That should capture just about everything that you'd need to know.

I imagine that trying to tack a system like this into a system not intended to support it, is going to be a pain in the arse. So you really should think about it. If you're worried about dup bugs. Do a check on a players pfile when they do save (compare the old pfile vs the player current stats) if the gold has doubled in a certain amount of time, then backup the pfile first, save the new one, flag the player and log them. Which would be a lot easier then anything else.

[noodles]

I think that if you had sufficient disk space for immediate needs, then this would be very doable - specifically for a text based game with a reasonable amount of players.  As for a 5 year period, I think thats veering into the pointless in worrying about.  Hard drive space is quickly becoming cheaper and cheaper for larger and larger amounts of space.  Where a year ago I would have bought a 120 GB drive where I needed one, now I am finding myself buying 200 GB drives.

You could easily reduce the disk space needs by having a binary marshalling format for logged game data.  And then theres actual compression on top of that.  But I have what I consider to be a reasonable suspicion that the majority of the data would be socialisation by the players, unrelated to the playing back of events that happened in the past.  Perhaps it might even pollute the playing back of events.  Unless you had one of those weird roleplaying games where you could enforce players entering in character communications and actions in a specific way where out of character ones could be filtered out and discarded - but I was always an preferer of LP type muds.

As for determining how a bug was exploited, I think that this while a nice brute force approach, is somewhat futile.  Better would be to have decent heuristics for viewing persisted state.  If you can run code to find anomalous state for or action by a character, then you can either be alerted to it, or can log (perhaps only related) actions by that character and cascade the logging to characters related to the instigator.

However, I must disclaim this with the statement that it has been several years since I have run a mud with active players, let alone logged into a mud.  Although I doubt things have changed significantly, I feel obliged to state this.

[Ashon]

Noodles,

Here's the issue that I see, you are either doing disk writes so frequently, or you are storing so much information in memory that this seems like a patently bad idea.

Of course, this isn't an issue if you are running a small game. But it would take some sort of fluke to cause some major problems. I think selective storage of information. Identifying progmattically which things need to be stored. And only storing that information.

[KaVir]

I think I'd tend to agree with you, although the idea has some interesting potential.  In particular, Raewyn's comment about being able to travel back in time brings to mind a related idea I've been toying with.

I was recently talking with one of my staff about how best to implement weather, and one of the options discussed was generating it based on the system clock.  Not only would this save having to store any information, but it would also allow players to accurately predict the weather.

Extending this idea further, I realised it also meant that players could go back in time to witness freak storms or unusually powerful weather.  You could even have the sort of supernatural weather events you sometimes see in movies, with a 'freak time storm' starting up that allowed you to move backwards to the previous such event for the duration of the storm.

If this idea were extended beyond weather, and utilised for everything (from mobs to combat) then you could shift back and forth through time, witnessing the same events repeat themselves in exactly the same way each time - at least, unless you interferred, in which case the entire outcome of the event could change.  This would allow for some very cool "Butterfly Effect"-like quests, whereby players could change the past in order to have some affect in the current time period.  Alternatively you might prefer to avoid paradoxes by having people move back to an alternative timeline, or only allow them to travel to the future.

For combat, it would also allow for some interesting 'sixth sense' capabilities, allowing players to predict the outcome of a certain combat move, or even an entire fight - rather like the mage in Robert Weinberg's Horizon War trilogy, who spent years studying himself fighting against a particularly deadly warrior in the future, memorising every slight move and constantly tweaking the outcome, so that when he finally fought her he was able to respond perfectly to her every attack.

Obviously this doesn't help much from an OOC perspective (catching bugs and the like), but it could provide some excellent IC opportunities for players.

[Ashon]

Wow! Now, that would be an awesome concept. *drools*

[Ashon]

With Molly O'Hara's Roleplay Experiment writeup going on over at TMC, it makes me wonder, to what extent can one log the roleplaying in a game.

Say by flagging yourself as an RP'er, you generate a log accessible to you and the administration, that logs, the location, the other actors involved in the scene, any local communication; whispers, says, emotes. It also needs to log any actions that are performed. It wouldn't log any global communications, It would also be great if it didn't log any incidentals like globalemotes from bored Immorts, or reset emotes.

I wonder how difficult it would be to take the raw log, and then turn it into a mini-story. For instance for each location, it would log the time, and it would present it as a third person story, injecting descriptions of the room changing, etc... *ponders*

[Keriwena]

It happens that Shae, creator of SimpleMU also runs Maddock Mux. SimpleMU's logging feature is designed to 'comment out' anything between matching #'s, and the Maddock code puts those before and after the WHO screen, helps, channels, etc. This greatly helps in making readable logs, as you can see here:



Scroll down and click on a few to see what can be done.

Molly, take note - the style of roleplay is influenced by the logging, and several mannerisms have developed over the years that help the logs read more like a novel. For some folks, there's way too much introspection and OOC commenting, but the net result (pardon the pun) reads well. That is to say, as you continue to post logs, I think you'll find that act alone improves the roleplay.

PS: Building on Maddock started in '94 (it was originally the Western themed 1/4 of Guardians Mux (Which makes me wonder if Guardians inspired D4?)), might have opened early '95. Some of those characters have been played continuously for almost ten years!