How to record the screen in games?
Author
Which api can handle screen recording and then saving it to a file type like .avi/.mpg?
Some graphics API's (I believe SFML is one of them) implemented a way to save a screenshot to an image file, and if not you should probably be able to figure out somehow how to do it yourself.
If you just capture the screen (or any part of it you want) every frame or like once every 20 seconds, you just have to find a way to produce a video file out of the images.
If you just capture the screen (or any part of it you want) every frame or like once every 20 seconds, you just have to find a way to produce a video file out of the images.
You can capture the screen buffer every four frames if your game is running at 60fps, creating a movie file of 15fps. This will balance the load performance-wise a little better. The specifics need to be clarified though, like:
1. What platform are you using?
2. In your code, have you fixed the frame rate to 60fps?
Once you get your head around those two you can work out from there how to reliably capture the screen buffer.
1. What platform are you using?
2. In your code, have you fixed the frame rate to 60fps?
Once you get your head around those two you can work out from there how to reliably capture the screen buffer.
Author
Basically what i want todo is let players record there game if they see someone cheating then send the video to the server admin thats online to review the video and ban the cheater all this built in to the game engine so no manually emailing the video and waiting days to get reviewed , it would be reviewed instantly...
Basically what i want todo is let players record there game if they see someone cheating then send the video to the server admin thats online to review the video and ban the cheater all this built in to the game engine so no manually emailing the video and waiting days to get reviewed , it would be reviewed instantly...
in that case I would record gamestate instead of video (In games this is often called a demo). Much less data and the reviewer can change camera perspective, etc.
EDIT: While thinking about that, the server already has all that data. You just need to stream the network traffic to disk (simply speaking) and give the reviewer an option to play back, rewind, move the camera, change speed, and so on,
There is a rule in multiplayer design: never assume any data from clients is good; and assume all players cheat. So, having a player send a video of what is occuring can lead to you banning players who never cheated because the cheater is the player who is sending you the video as evidence.
If you want to attempt to catch players who cheat through an in-game option, then have an option for players to "Tell" on someone. For example, Player A sees player B cheating. Player A opens a dialog that allows him or her to send info to the server about the specifics. This could be as simple as letting the player select the player who is cheating and enterting a time when the event occured.
Then, when you recieve this information you have an ability to play back what happened at a specific time interval to see if cheating actually occured. The information for the play back is taken from the SERVER, not the client. The only information taken from the client is: Who, What, Where, When. Then, its up to you (The Admin) to investigate whether the cheating actually took place. If players abuse this method, then you can ban them instead. So, players would not have incentive to constantly tell on other players because their fear of getting banned for false information.
If you want to attempt to catch players who cheat through an in-game option, then have an option for players to "Tell" on someone. For example, Player A sees player B cheating. Player A opens a dialog that allows him or her to send info to the server about the specifics. This could be as simple as letting the player select the player who is cheating and enterting a time when the event occured.
Then, when you recieve this information you have an ability to play back what happened at a specific time interval to see if cheating actually occured. The information for the play back is taken from the SERVER, not the client. The only information taken from the client is: Who, What, Where, When. Then, its up to you (The Admin) to investigate whether the cheating actually took place. If players abuse this method, then you can ban them instead. So, players would not have incentive to constantly tell on other players because their fear of getting banned for false information.
Indeed, a cheater would be able to send you a fake video of his gameplay. Depending on the engine's architecture, that could be very easy or hard to do for the cheater.
Anyway, the bandwidth & size implications of it are too high, while there are much better options:
1. Recording the input for replay. Requires a deterministic game. This is how RTS usually work (see 1.500 archers, it's old but still very valid).
Pros: Bandwidth consumption is extremely low. Very resilient to cheaters (no God mode, no moon jumps, no infinite ammo), but allow some kind of cheats to be easier to perform (i.e. seeing through walls in a shooter, or a getting 'GPS' with everyone's location). Data can be obtained from clients & server. All clients must match with server's.
Cons: Maintaining determinism can be painful if the engine wasn't designed & tested from day one.
2. Record the graphic state. Records the Graphic objects and their transforms (i.e. vertices & matrices). Bandwidth consumption is higher. State is obtained from server (can't trust the client)
Pros: Easier to maintain.
Cons: Needs advanced Graphic API knowledge
3. Statistical analysis. Use mean, mode, standard deviation to analyze a game session from the server's data. Data such as death rates, kill rates, hit accuracy, session time, average health, maximum jump heights, time taken to beat a level, etc; can be used to red flag users. Method 1 or 2 is still needed to analyze those sessions to see if he's actually cheating (unless it's obvious, i.e. you can't beat a racing game in 1 second). Alternatively, the moderator can join an existing session (or start a new one with the alleged cheater) and personally monitor if he tries to cheat again.
Pros: Stat. analysis can be very accurate in detecting cheaters and the easiest to implement in terms of coding.
Cons: Implementation must be done well (attending quite a few Statistic classes will help). False positive will arise.
Cheers
Dark Sylinc
Anyway, the bandwidth & size implications of it are too high, while there are much better options:
1. Recording the input for replay. Requires a deterministic game. This is how RTS usually work (see 1.500 archers, it's old but still very valid).
Pros: Bandwidth consumption is extremely low. Very resilient to cheaters (no God mode, no moon jumps, no infinite ammo), but allow some kind of cheats to be easier to perform (i.e. seeing through walls in a shooter, or a getting 'GPS' with everyone's location). Data can be obtained from clients & server. All clients must match with server's.
Cons: Maintaining determinism can be painful if the engine wasn't designed & tested from day one.
2. Record the graphic state. Records the Graphic objects and their transforms (i.e. vertices & matrices). Bandwidth consumption is higher. State is obtained from server (can't trust the client)
Pros: Easier to maintain.
Cons: Needs advanced Graphic API knowledge
3. Statistical analysis. Use mean, mode, standard deviation to analyze a game session from the server's data. Data such as death rates, kill rates, hit accuracy, session time, average health, maximum jump heights, time taken to beat a level, etc; can be used to red flag users. Method 1 or 2 is still needed to analyze those sessions to see if he's actually cheating (unless it's obvious, i.e. you can't beat a racing game in 1 second). Alternatively, the moderator can join an existing session (or start a new one with the alleged cheater) and personally monitor if he tries to cheat again.
Pros: Stat. analysis can be very accurate in detecting cheaters and the easiest to implement in terms of coding.
Cons: Implementation must be done well (attending quite a few Statistic classes will help). False positive will arise.
Cheers
Dark Sylinc
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement