EVE General Discussion

First off, no, the biggest hurdle here wouldn't actually be legacy code it would be capturing everything the client would need for playback (new code), writing everything out in a format that's usable (new code), and writing the huge mess of code that would allow it to be played back (tons of new code).

This isn't even as simple as just feeding data into the client because the client expects to be playing a game, and if it doesn't get certain responses it will assume a disconnect has happened and shut off.

I also personally suspect that the server avoids sending a lot more extraneous data than you think, with the end result being a lot of kinda jerky ships if they were way off away from your camera/ship/something at the time of 'recording'. The general counter argument at this point is "but it's better than nothing!" to which I respond, 'yes, but once CCP has released something they have to support it and field complaints about how bad things look and why the thing should be improved' and "It's better than nothing" flies about as well as a brick sandwich when a dev says it.

The Alliance Tournament replayer is based off of server logs and is, if I had to guess, literally a stripped down 'camera-client' being fed server replay data, not anything that a player could use because the server has all the answers and can use them to calculate game state.

This topic comes up now and then. As it turns out, it's incredibly difficult to retrofit onto a system that was designed without such recording in mind.


Yes, there was an experimental API for providing live access to what happened on-grid for each match in the AT. My understanding (which is somewhat shaky) is that it relied heavily on the tournament tools that we use internally for setting up and administering each match to generate and publish the data.

As has been pointed out here, such a system would have to record the game state server-side to be able to provide a complete picture of what was going on in a replay, and that would be a huge problem to solve.

I don't expect to see anything like that added to Eve, although I admit that being able to step through a replay of arbitrary in-game events would possibly be the coolest feature ever, if it were possible.

Edit: A feature like that would also raise all kinds of horrible game design problems related to leaking intel after an engagement. I'll leave that analysis to those who think deeply about such matters for a living. I do not.

They'll get to it after Captain's Quarters.

Oh bloody hell CCP Killjoy Darwin! Can you not once come here and say "Sure, I can do that!". That would be really nice.

I agree, it would be a lot more fun to talk about what we are doing. All in good time. :)

Alright, I will wait. But it'd better be something fun. If it's just the next jump fatigue, I will not strike out the nickname next time.

PS. I am still mad because of the high res textures. So this is strike two.

I'd just like a dscan.me killmail grabbed centered on the victims location.

If that's "too much effort" time for fresh faces at CCP.
Hint: should be super simple and no additional computation required

Instead, give us a way to snapshot the client's view of game state and load it in the client. You must have this capability for dev.

This way players can maintain opsec over who shares the snapshot.
A file would be fine, dragging links in the client would be better.
Killing the player session when you open a snapshot would be fine.

As a start, see if you can implement taking a snapshot and viewing it, without any loading capability, at server shutdown.
Many's the time I have turned on my client in the morning to see the shutdown message and no way to see the most recent state of chat windows.

Wouldn't it be a matter of tapping into the graphics output of the client rather than the gamestate?

All those bits need to be rendered somehow, so the information is getting to the client directly at *some* point. The GPU pretty much has all the information people are asking for, unless somehow some of the rendering is done server-side (which would be horribly inefficient and hilarious).

This also feeds into the UI rendering (for overview data etc to extrapolate information which may not be rendered directly, such as ship models at long ranges).

What about the in-house cinematic tool CCP uses? It can't have been developed in complete isolation of the client itself?

If even that is not directly possible, will it be done in the inevitable upcoming engine revamp? :)

CCP Darwin, that actually sounds pretty good. Mostly because as opposed to a video recording, the camera drones can be manipulated, I assume, during the playback of such a battle recording, allowing for unique, multiple perspectives to be edited together. Another possibility is that the battle info can be recorded at minimal graphics settings for performance, then played back on a machine capable of rendering at max settings.

I also assume the data stream from the server to the client (plus any relevant input to the client from the player) is significantly less data than a 2560x1440@60fps stream, so that I would be able to record many hours of play without worrying about disk space...

(Obviously I have no idea just how much data is or is not sent to the client. )