16
\$\begingroup\$

I plan on creating my own kill cam system for a sandbox tool set. After thinking about the mechanics of the kill cam itself, however, I'm quite lost. I'm trying to recreate the ones commonly seen in call of duty games that show, from the view of the killer, the actual killing scene.

My Thoughts:

-I can't just keep in memory when people kill others because I wouldn't know when to start the 'recording process'. There is on way for me to accurately determine when somebody is 'about' to kill someone.

-My only real idea so far is to have a complete duplicate of everything loaded off to the side copying all the movement from the original world but with a 10 second delay. That way, all the kill cams would be 10 seconds long and the persons camera would just be moved to the second world of their killer.

My Questions:

Is there already an accepted way to do this? Does anybody have any good ideas for something like this? Thanks if you can!

\$\endgroup\$

6 Answers 6

Reset to default
11
\$\begingroup\$

Store the last few seconds of movement data of relevant dynamic objects.

This data should be complete enough that it can be used to reconstruct a killcam scene if necessary, but incomplete enough that you can afford retrieving and storing at short enough intervals.

Examples of things you may want to track:

  • Which way a visible player is moving/looking
  • Whether killer is zoomed in on gun scope

Things you probably want to optimise out:

  • Data about players whom the killer cannot see
  • Anyone's actual screen output
\$\endgroup\$
4
  • \$\begingroup\$ There is a big problem in your answer, normally you can't predict anyone's death, and you also can't predict who is going to get the next kill. so with optimizing out data about some players you might end up loosing the ability to replay some kills. \$\endgroup\$
    – Ali1S232
    Commented Nov 27, 2011 at 22:04
  • 2
    \$\begingroup\$ @Gajet I think in this case, he means to cull all relevant objects and only store data for those afterwards. In other words, you'd already want to have some kind of storing/updating mechanism to keep track the positions of everything and their entities, but to a limited time. Say, you just want the last 10 seconds for a kill cam. You'd just need a data structure large enough to store the last 10 seconds and anything older than that gets replaced at the end, such as in a double ended queue. \$\endgroup\$
    – ChrisC
    Commented Nov 27, 2011 at 22:46
  • \$\begingroup\$ Just confirming that Ricer's answer is what I meant. Indeed: When you can't predict the future, prepare for it instead. :) \$\endgroup\$
    – Anko
    Commented Nov 28, 2011 at 16:26
  • 1
    \$\begingroup\$ It's important to mention that realtime online games never show players what actually happened; the game is always making guesses about what the truth might be, but due to latencies and other network issues, games won't find out what the "objective truth" was until much later -- if at all. So if you don't have "kill cam" data available to be able to re-create someone else's viewpoint, you totally shouldn't feel bad for making up plausible kill cam data in those situations where you need it. \$\endgroup\$
    – Trevor Powell
    Commented Nov 29, 2011 at 9:19
0
\$\begingroup\$

No idea how this is normally implemented, but you could have each bullet save a clip from the time it is fired, to when it hits a target. If the shooting is done just with a hitscan, you can compute whether or not to generate the kill cam footage in the same cycle when you perform the hitscan.

\$\endgroup\$
0
\$\begingroup\$

You can save an object's transform every couple seconds or so. Do this for all applicable dynamic objects. Stagger the saving such that each frame you are only saving a couple matrices. save as far back in time as you like.

During replay, You actually use these transforms in a rendering engine to animate through a scene, interpolating between transforms by time for each frame as necessary.

It is not an exact duplicate but very very close & it allows you to give the player the option of camera control during replay so they can choose where to view the scene from.

\$\endgroup\$
2
  • \$\begingroup\$ there is one problem with storing only transform matrices, not saving anything else! for example if you only save transform matrices for players, animations may go wrong you won't be able to see how much damage enemy took before killing you and when did he fire his gun. there a long list of details you miss using your method that you can easily think about them. \$\endgroup\$
    – Ali1S232
    Commented Nov 27, 2011 at 22:15
  • \$\begingroup\$ Please re-read, You save transforms for all appropriate dynamic objects, not just matrices for players. It is also easy enough to save health or hit-point data and other items as well too. The point is, saving too much data consumes game time resources, (bad). You save as little as you can get away with and let your rendering engine do as much of the heavy lifting by interpolation during replay as possible. It is a compromise but what isn't? \$\endgroup\$
    – Steve H
    Commented Nov 28, 2011 at 2:00
0
\$\begingroup\$

you can implement some replay feature in your game. using replay function, killcam is just a replay being played from some specific gametime, and from some player's point of veiw. later you can save replays and let others review games after they're finished.

also your idea to run a same game with inputs by 10sec delay is a good approach if your game doesn't consume high computational power.

\$\endgroup\$
0
\$\begingroup\$

How about this...

Only record when there is a possibility of killing.

Think about it from an AIM-BOT's perspective. It will only aim/fire when killing is a possibility. So you should only record when an enemy is within killable/visible range.

\$\endgroup\$
1
  • \$\begingroup\$ What about in situations involving shooting through an object? Ray casting so much will surely be more CPU intensive than some of the other ideas stated. Good idea though, I could consider that as part of a solution. \$\endgroup\$
    – Freesnöw
    Commented Nov 28, 2011 at 0:11
0
\$\begingroup\$

Set a radius around the player and if another player enters the radius then it starts screen recording for both people. You then wait to see if anyone is killed. If so then you find the killer and take their recording and rewind the amount of time elapsed since the kill plus the length you want the video to be and rewind and play it for the one who was killed. If nobody is killed and nobody else is in the radius around the character then delete or stop the recording. If the killer is zoomed in on a scope then cast a ray to where he is aiming and create another trigger radius. If someone is in it then it records the screen of whoever is in the radius where the aiming character is aiming and of the character aiming. If someone dies by the character aiming then you take the time elapsed since the kill plus the length you want the kill cam to be and you rewind and play this for the one who was killed. If they zoom out then stop the recording. This is a concept so i havent tried it.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .