instant replays
Blitz3D Forums/Blitz3D Programming/instant replays
| ||
| Is there any way to code replays. I would like to be able to play back the all the action that took place in the last 10 seconds or so in a game. |
| ||
| Yes there is. - If you want to make rendered replays (recording what the camera sees), it's very easy. Just keep storing the last 10 seconds of backbuffer rendered images and then replay this footage - you limit your viewable angles to as many cameras as you record, and you won't be able to change replay speed up\down or zoom in\out. - If you want real-time replays (like most games do it), which allow you to zoom in\out, play at different speeds and any camera angle you want, you'll have to record game state. There are several ways to do this, and the most optimized ones are incredibly difficult (using only actions and recalculating states based on time, with physics and interpolation). So I suggest you simply store the last 10 seconds of game state as data: - Transformation data: position, rotation and scale. - Animation data: sequence and animation time. - Brush data: FXs, alpha and shininess (ignore the ones you won't use.) - Texture data: position, rotation and scale. The above is the typical amount of properties you need to record for every object in the scene - every particle, every sprite, character etc. - at every game frame. It's almost like recording an animation, except that the game engine would still be calculating collisions and other game events as if they were new (this saves you having to record them as well). You can use Banks for this, to keep data size small - Banks allow you to use Byte and Short data types for data you know will always be small (such as animation sequence index and animation time), instead of using costly Int arrays. If you're worried about memory usage, it's the amount of objects in the scene that influence it, since the replay size is fixed. Each time you record more than 10 seconds, just free\overwrite the memory used by the oldest frames. This method is still difficult, so start small and work your way up. Last edited 2012 |
| ||
| My try at this : Here : http://blitzbasic.com/codearcs/codearcs.php?code=2944 A really simple example, only the X,Y,Z and Pitch,Yaw,Roll are recorded/played. |
| ||
| Both the above techniques are valid, and ultimately decidfe whether you wish to: 1) Record the actual screen display (GraphicsWidth * GraphicsHeight * 4 Bytes per Frame) 2) Record the transformations and states of gameplay objects (#Objects * #States * n Bytes) The deciding factors are the speed of recording, wher this may slowdown the standard gameplay by too much, and the memory used in doing so. These arte quivalently similar, since the speed will be dependant on the memory space too. How your game engine is structured can help a lot too. If, for example, certain objects follow defined patterns, react to other circumstances, or follow pathfinding routines, then perhaps only their initial states may be required, since the paths may be calculated bythe engine itself as in standard gameplay. This means that a greatly reduced number of objects that require to be recorded (i.e. maybe even just the player object) |
| ||
| I prefer to use a method of recording entity parameters (x/y/z etc) than recording the screen picture since that way you can (in 3d) view the replay from different angles. If you just record screen grabs then you cannot view the action from different angles... |
| ||
| Thanks a lot everyone for your suggestions and quick response. I was really leaning towards real time replays where you can zoom in and out, and play from any camera angle. I will experiment with most of your suggestions, and thanks again. |
| ||
| Regarding what I said about collisions. I changed my mind. Since transformation data and animation data will already be recorded, collisions will be there implicitly, recorded as movement\absence of movement - there is no need to keep collisions still active when the replay is showing. Nothing will change visually for the player anyway. If you keep collisions active, the floating point precision of the transformation data you record will make room for innacuracies that can even change the outcome of the recorded match (i.e: a near miss can become a hit in a fighting game). This last point brings to attention that you will need to record important game events such as hits (if we're talking about a fighting game, for instance), so you have absolute precision when reproducing these events. In short: - When playing the replay, turn off collisions. They were already registered with transformations, and if kept active they can influence the outcome. - Record important game events such as hits (for fighting games), kicks and passes etc. (for soccer games) and others such that the outcome of the replay is secured to be the same as that of the actual match. - Record who's the victor; don't use replay data to reprocess this. Last edited 2012 |
| ||
| d. post. Last edited 2012 |
   |