Regarding the Bastogne “replay” videos, Madrebel asked:
ah so you’ll never likely allow access to the game DB. what about a slave sql db with a read socket open to something like wiretap?
We’re not likely going to provide external access to the data, but we have – of course – been throwing ideas around for how we might make it useful in-game. I think it would be really bad juju if I picked any particular idea as an example because right now it is just a debug tool.
One of the reasons for making the Bastogne videos was “to see what we can see”. It actually kicked off an interesting discussion point when I coaxed Rafter into putting it on the big screen at the close of an unrelated meeting last week.
What we all noticed was that … the videos weren’t very interesting. Having four completely independent views was 4x as dull.
Gnpatton was a good example – all it did was leave him with more questions (I might actually make ya a little video, gnp ;) Drave asked if Ramp got a kill and why I didn’t show the guy. We asked the same question :)
You also have to watch really intently to tell that the videos are actually related. There are a few points where you will see explosions going off in sync. If you watch the really-hi-res version, and pay really close attention to the tags you might be able to see further evidence of synchronization but … geez, man.
For something like this to produce interesting videos, it’s going to need a director, something that can identify points of interest ahead of time. Sounds to me like a heck of a fun challenge… What sucks is its exactly the kind of thing I’m sure several of our community would love to be involved in :(
The way the replay system works is actually kinda simple and kinda neat. The “cell” hosts (the processes that deal with ‘avatar’ data, that is – your movement through the 3d world) have to share data between each other. They spit this data out on a network backbone and the remote cells use it to present your movements etc to other players so that the distribution is transparent.
For recording, I just stuff these packets into a database with some timestamp and other basic information.
Playback is a matter of reloading these and popping them back onto the network like we were the originator (in some cases, I have to modify the data — e.g. rename players or change some of their “session” data so as not to conflict with currently-active players, but that’s by the by).
At the moment, I have both the recording and playback code inside the standard “cell host” process, controlled by chat/irc commands. But I could just as easily relocate it to a separate process and run it on a dedicated box and perform on-the-fly analysis.
There’s a second alternative though. Part of this tool is a little external app, called “playback”, which extracts the raw data from the database and allows me to inspect it (uhm, feature creep, it also provides mechanisms for converting recordings between incompatible formats if the protocol changes).
Storing the data in a database is just ever-so-slightly stupid (oh, the indexes)! The recording tool can also dump data directly to a file (producing about a 20-40% reduction in storage requirements).
A more practical approach to leveraging these capabilities in any kind of user-friendly format is likely going to be continuous to-disk recording. I’m undecided right now as to whether I should have one process snarfing all the data off the wire and recording it directly to a single file, or if I should have each cell quietly use a background thread to write its data stream to a separate file and recombine the files later on.
If I rotate these files every 15 minutes or so, there only reason not to keep continually recording is … disk space. An average 6 week campaign is going to need around 1Tb of disk storage.
That’s a wee bit much. But, we can reduce it significantly if we come back to our “director” concept.
The recording contains everything everyone is doing. “dinker” flying out to the alps and “ouwd” gone AFK in his Daimler at Calais while the fight has moved to Luxembourg. Those guys just sitting there is contributing (albeit minutely) to the data stream.
There are currently three types of data record in the stream: “Intro”, “Update” and “Outro” (well, actually they’re “1stTime”, “Update” and “Removal” but you don’t want to know that do you? ;-p)
So I probably need to add a “POI” record which specifies some place someone wants observed. That someone could be me setting a 3d/visual “break point”, a GM wanting something looked at by a dev. Engage warm-fuzzy-future-ideas-mode: It could be a player-annotated event to allow us to provide players/squads with a “greatest moments” tool.
But it doesn’t have to be a human-generated item. It could easily be the system wanting to preserve a record of the activities of a player it kicked & banned.
Or … it could be injected by the post-processing tool…
That leaves the big question: How do I decide what’s worth watching. By ‘watching’ I mean ‘spectating’, say for a video – not as a GM or dev.
I think I’m gonna start with a heat map of some kind; starting with something like the “deathmaps” grid on WireTap: lots of deaths = start looking here.
From there it’s a matter of coming up with good weights for various kinds of activity and back-tracking the components of that action.
It’s probably going to make for a very long-term project. Already my mind is itching to go off thinking about things like “well, this vehicle takes tons and tons of hits – so he might be worth watching, but wait, he gets finished by a bomber, so we need to wind back and track the incoming bomber so that a smart filming-client knows to follow the bomb that hits him” etc.
I really wish there was a way I could open this up so that the small few of you who are salivating at the prospect of fiddling with something like this could participate…