Jump to content
  • Advertisement
Sign in to follow this  
CTar

Video format idea

This topic is 4840 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have this idea for a way to save videos recorded in-game, I don’t know if anyone have done something similar before, but I would like some criticism on the idea. Basically the idea is to instead of saving the video in a normal video format (.wmv, .avi etc.) you would save the objects of the game in a file and all their movements/animations. Imagine a file, split into three parts, the first part is a little header with information like recording time, username, system, resolution etc., this will not be very big and could be removed. The next (second) part is also a kind of header; it contains all the game objects used while recording, stuff like models, textures, animations etc. this could either be coded directly into the video file or the video file could have the resources filenames. If the video file will have the resources filenames it might need to make a copy of all resources since they might change after recording the video and then the video wouldn’t look as recorded. All resources in this part will get an ID assigned; this will most likely be a 2 byte (16 bit on most system) large. The third, and last part is the most important, it contains all information of what happens while recording the video. This part can be made in many ways, but the way I imagine it would be to have an ID for each instruction for example, 1 could mean “object created”, 2 could mean “object changes position” and 3 could mean “object destroyed”. Then if 1 was encountered it would know that the next 2 bytes is the ID the object should have, the 2 bytes after that is the ID of the resource the object use, one object might use more than one resource, but then a new instruction would be required to add the resource. Now that the info for the “object created” instruction is read it would look for another instruction. In the same way there will be a pre-determined amount of data after each instruction ID. This would probably mean the very short videos will be much larger than standard videos since a lot of space is used in the second part. For large videos this video format will maybe even save space. The reason I in some cases would consider this format superior to the normal video formats is that, especially for developers, it can be very helpful to maybe check out other places than you where (to for example look at the AI) and you would be able to convert it to a really high quality standard video format since we don’t need to do it in real-time. You are easily able to extract a very high-resolution screenshot of any part of the world. I also think this video format would have less affect on performance compared to other video formats, because it only needs to save an absolute position for what have moved ( part 1 and 2 of the file is only done once ). I also believe this format might make smaller video files when recording big videos and if the video is able to access the resources bundled with the game the video sizes could be very small. I also see a lot of bad things about this format; the biggest is that it doesn’t work properly when playing multiplayer. The reason it doesn’t work when playing multiplayer is that this format needs information for the whole “world”, but since the server doesn’t trust the client, the client only gets information about what happens right around it. One way to use the format in multiplayer is to only save the information you get, this would create a smaller file, but it would be impossible to look at another part of the world, this approach could also be used for single player, when you want a small file. Another bad thing about the format is that if data from the whole world is saved it could be used for stuff like map hack, wall hack, and probably other hacks too; this of course couldn’t be done in multiplayer since only the data the player can see is saved. The last bad thing I can see about this format is that you need a video player following with the game and therefore people without the game cant play the videos, this could be fixed by letting the player convert the video to other formats and adding the possibility to change the kind of video format saved to in-game. I know this was a little long, but I hope to get some criticism on the idea.

Share this post


Link to post
Share on other sites
Advertisement
The problem is that a format like this is only useful if you have the application installed, and at that point a good portion of the idea becomes moot. If the intent is to distribute for common usage then even more issues arise. Stuffing content into a file for public consumption outside of the game/app installation is just asking for trouble. Example: right now I don't have Half-Life 2 installed on this machine, but I can certainly watch in-game footage of it through traditional recorded means... this without risk to Valve for me ripping their content out.

Share this post


Link to post
Share on other sites
Quote:
Original post by Schmedly
The problem is that a format like this is only useful if you have the application installed, and at that point a good portion of the idea becomes moot. If the intent is to distribute for common usage then even more issues arise. Stuffing content into a file for public consumption outside of the game/app installation is just asking for trouble. Example: right now I don't have Half-Life 2 installed on this machine, but I can certainly watch in-game footage of it through traditional recorded means... this without risk to Valve for me ripping their content out.


You are right I didn't really think about protecting content, the only solution I could see for this is too just use identifiers somehow pointing to the content provided when the game was installed, this would make it harder to extract the content, but the problem with people not having the game wont be solved. Well I still think a format like this could be usefull for the developers of the game, bug maybe it's not a good idea to provide with the game.

Share this post


Link to post
Share on other sites
For our game we reused the game state serialization code made for networking and savegames to handle the replays.
It basically consisted of "keyframes", i.e. full game states, for every minute or so and in between only recorded the normal input for each player. This had the advantage of being able to seek within the file without rerunning a whole game up to that point.
It was also necessary because if a client got out of sync (by a bug in the game or a peer sending false information for example) the server could decide to resynchronize the player by sending a full state, which then also had to be saved in the replay.

Due to our networking model (don't ask) the replay system had access to information about all players anyway. As for playback we had a nice little 'mediaplayer' built into the game itself with the standard set of buttons and sliders.

Unfortunately this feature was finished too late to be of much use during the debugging process, it was a great help on the few bugs we tried it on however.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!