I'm just throwing this out there, but I think it would be totally awesome if it were possible to record objects.
Basically, using something like a Record() proc on a mob begins a recording from that mobs' perspective: mob.sight is taken into account, as are other variables. world.view is taken into account, or you can specify your own view.
The StopRecord() will stop recording. Doing this will produce a /movie object. This object can then be played back on a map element of sufficient size.
It would become possible to make a camera object in a game which records the immediate area. It would record the coming and going of people, as well as messages directed to it (via cameraObject << "blah"). Even sounds could be recorded.
This would all be saved in an internal format, both to make things easier as well as to speed things up. Once a recording is stopped, the /movie datum can be stored in a list that governs the camera "memory".
Later, a player can retrieve a /movie datum from the memory, which can then be displayed using movie.Playback(client, mapid, outputid, sounds). This causes the recording to be played back to client, it will be displayed on the map element with the id mapid and any messages sent to it will be output to outputid. In addition, any sound objects that were directed to the object will be played to the object, transforming the values of the sound according to a /sound datum specified in the sounds parameter.
A camera object could be one of many uses for this system. You could make an introduction movie and play it back when a player logs in for the first time, instead of having to do everything through code.
Internally the /movie datum would contain a set of instructions. It could send these instructions to the client, which can reproduce them. The advantage of this is that when you playback a movie, the client can do it by itself and won't need to contact the server for everything.
Procs:
movie(mob, view = world.view, flags)
This proc, when given a mob, will start to record that mob until the proc is called again. The view parameter can be used to determine the radius around the mob to record. (Messages and sounds sent to the mob will always be recorded though, regardless of the view set here.)
It takes the following flags:
RECORD_MAP: Records changes in the map. If this is not set, it will not store a visual recording of the map, but it will keep track of messages and sounds sent to it.
RECORD_INPUT: Records all text-based input sent to it.
RECORD_SOUNDS: Records all /sound datums sent to it.
Returns 1 if the movie is being recorded, 0 upon error, and a /movie datum if it is called twice.
Movie datum procs:
movie.playback(client, mapid, outputid, soundtemplate)
This plays the movie back to the specified client. Instructions on what happens and when it happens are sent to the client, which then plays it back using the specified mapid and outputid. The soundtemplate is a /sound datum containing pre-defined variables: these will override any sounds played and possibly be transformed with another sound. (i.e. so you can specify your own environment and echo)
Returns 1 upon success, 0 if it failed.
movie.pause(client)
Causes a movie that is playing to be pause.d
movie.resume(client)
Resumes a paused movie.
movie.exportToAVI(file)
This might be an interesting feature: it allows one to export a movie to an .avi file for external use. This can probably only save the map and the sounds played.
movie.exportToBMF(file)
Exports the movie as a BYOND Movie File. The resulting file contains the instructions used to create the movie, so it can be imported later.
movie.import(file)
Allows one to import a BMF file. The resources that were used in the creation of the original movie will be required by the game. It can potentially be used to make a player for a specific game that revolves around these things.
ID:260843
 Dec 5 2009, 11:09 am
|
|
Forum_account wrote:
You just need to know at what times the players hit each button. Every time a player presses a key, make a record of the event (the key pressed and the current time). Since the events happen in order, your list of events will automatically be in order. Assuming the initial conditions aren't too hard to save/restore, playing back the movie can be surprisingly simple. So? There's still a network delay involved which will slow down the playback for anyone involved. In addition, I can't access messages and sounds directly output to mobs. Functionality as I've written in this thread is required to be able to make an efficient recording system in the game, which is why I request it. | |
Android Data wrote:
So? There's still a network delay involved which will slow down the playback for anyone involved. In addition, I can't access messages and sounds directly output to mobs. Functionality as I've written in this thread is required to be able to make an efficient recording system in the game, which is why I request it. You can access any messages and sounds output to players by routing all those messages and sounds through wrapper functions. So, call displayMessage(oview(), "BUTTS") instead of just oview() << "BUTTS". As for lag, the network delay will not slow down the playback, it will simply, you know, delay it slightly. It may also cause it to be slightly less smooth as a result of variations of your ping, but that's a minor issue. | |
Garthor wrote:
You can access any messages and sounds output to players by routing all those messages and sounds through wrapper functions. So, call displayMessage(oview(), "BUTTS") instead of just oview() << "BUTTS". Yes. Yes, I can do this. But even then... As for lag, the network delay will not slow down the playback, it will simply, you know, delay it slightly. It may also cause it to be slightly less smooth as a result of variations of your ping, but that's a minor issue. ...the network delay involved will mess with the playback, especially if the servers' CPU is busy doing other things. The CPU of the server shouldn't be the one involved with playing back a movie; this should be the job of the client. The idea as proposed is to have the client handle the grunt work and to make an easy way for older games to adapt. Although I use wrappers like you suggest, I'm not keen on recording myself as this will waste valuable CPU time of which there is little in this particular game. I'd really like to see a hard-coded method to do it since it'll be able to jot down instructions in shorthand which the client can then interpret through a single download, as opposed to the laggy method of sending everything to the clients at a timed interval. | |
I could imagine a frame by frame, but that would hit with lag.
Save a screen shot per interval (second, tick, etc.) then save it to a list and have all 'frames' own an ID number and then give the list it's own ID within run time, and when they wish to replay it back, display the screen shots within the browser or on the map. | |
Dark Vendetta wrote:
I could imagine a frame by frame, but that would hit with lag. I do think frame-by-frame recording lags, yeah. By now I half expected to see some form of client-side processing, where we can make special .dm files to be sent to the client for execution. Unfortunately, this seems not to be so easy to do. If such a thing were in, then I would indeed write a library on recording. Save a screen shot per interval (second, tick, etc.) then save it to a list and have all 'frames' own an ID number and then give the list it's own ID within run time, and when they wish to replay it back, display the screen shots within the browser or on the map. Which would cause even more lag, and I'd have to find a spot to save the screenshots. I really hope client-side processing is #1 on the to-do list. | |
Android Data wrote:
I'm not keen on recording myself as this will waste valuable CPU time You're already using CPU time to process all of the events that happen. To record them you just need to keep a log of events as they happen. The overhead for this is very minor. I wouldn't expect this to be implemented in BYOND because, based on your specific needs, you can highly optimize movie recording. Earlier I mentioned Starcraft. To record a game you only need to remember what commands were issued and when (and the initial state of the random number generator). With this you can use the game's unit AI to play back a recorded game. Your game may have lots of complicated actions, but if the actions are reproducible from a smaller set of events you can really cut out a lot of complexity. I'd really like to see a hard-coded method to do it since it'll be able to jot down instructions in shorthand which the client can then interpret through a single download, as opposed to the laggy method of sending everything to the clients at a timed interval. This laggy method of sending data to clients at timed intervals is how BYOND games work (it's how most online games work). What is the difference between sending updated mob locations as players are moving live or as part of a movie's playback? The movies should not be any more laggy than the game itself. | |
Android Data wrote:
By now I half expected to see some form of client-side processing, where we can make special .dm files to be sent to the client for execution. Client-side processing is something we'd definitely like, but there has never been any clear way to make it possible. That's not to say it will never be done, but the technical hurdles are fairly high and we've chosen to address bigger concerns first. The technical hurdles to recording a "movie" are also significant. Simply recording a player's map and sounds would be relatively easy since you can tap into existing system resources to do that. (Please note the word "relatively" though; screen-to-video apps are somewhat technically advanced.) But recording an arbitrary mob is a completely different concern. You would basically need a fake client to do it, and even then you would need some way to account for output such as sounds being sent to that mob, which instead of having just one possible client could have many. And what about routines where output is sent directly to a client, or an /image is added to client.images? What about client.screen? I really hope client-side processing is #1 on the to-do list. Unfortunately it has never jumped very high on the list due to the lack of an implementation plan and the significant time investment that would be involved in adding such a feature. Lummox JR | |
Lummox JR wrote:
Unfortunately it has never jumped very high on the list due to the lack of an implementation plan and the significant time investment that would be involved in adding such a feature. Is there anything I could do to help with the creation of an implementation plan? | |
Android Data wrote:
Lummox JR wrote: Nothing comes to mind. It's really a complex problem, is the thing. Some of the questions that come up are: 1) What would the client-side code calculate and how would that impact the client's experience? 2) Would some of the calculations be stand-ins for data expected to come later from the server (such as pixel offsets for smooth movement), that would have to be synced up? 3) How would the server send the right data to the client, or know what it needed to send, and how could the amount of network traffic for this be minimized? 4) Would the client ever need to send data back to the server for any reason? It's difficult coming up with answers to those questions, and those are just off the top of my head. Whenever I've contemplated this before I've gotten lost in the logistics of it. Ironically I'm pretty sure I was the one who first suggested the idea, so this has been on my mind a while, but I find myself in Dan's position now and the problem is a lot thornier from the inside. Lummox JR | |
Lummox JR wrote:
1) What would the client-side code calculate and how would that impact the client's experience? It should be possible for developers to send code to the clients. Developers should be able to make a specialized form of .dm file which is sent to the client upon login. This may contain procs that are called by the server which performs actions on the client-side, or overrides to procs made for the purposes of stand-ins. Every aspect – or mostly anyway – of the DM language should be available client-side. This should be possible because the Dreamseeker program is already capable of acting as a server. There are a few things that should be removed, some for the sake of security and some because they don’t really belong. These things include: • The entire world datum should be read-only and set to whichever values the server has, with the exception of the world.hub_password value (which should remain null for safety reasons). • The client should obviously not act as a server. Procs bound to world should not be executed, such as world.OpenPort(). • The procs fcopy(), fcopy_rsc(), fdel() and shell() should definitely be blocked. • The only /client object in existence should be that of the local client. • Only objects visible by the client should be accessible. No other objects are normally accessible to the client. There should be a method in the server to send an object to the client however, so that the client may freely request it. • The client form of DM is separately parsed. Procs, verbs and vars only exist on the client, and the client has no access or knowledge to any of these operating on the server apart from default values sent by the server. The client can only access client vars/procs and the server can only access server vars/procs. • The call() proc is used to call procs on the client or the server. On the server end, this can be as simple as call(client, “ProcName”)(args). Object references may too be used, so long as they are a global variable on the client-side. This is done with call(client, “Object.ProcName”)(args). • Return values of the remote call() are sent back to where they came from. 2) Would some of the calculations be stand-ins for data expected to come later from the server (such as pixel offsets for smooth movement), that would have to be synced up? Indeed. • Modifying the variables on any atom within the clients’ view should modify this atom immediately, until the server decides to send an update. • It should be possible to override the above behavior. The atom.client_updates variable (defaults to 0) exists on both the client and the server. If set to 1 on the server side and to 1 on the client side, the client will ignore server updates for any variables changed by the client. 3) How would the server send the right data to the client, or know what it needed to send, and how could the amount of network traffic for this be minimized? I don’t know exactly what is meant by this. If it refers to the above (when to update stuff), the server should stop sending updates if both the client and the server have their atom.client_updates variable set to 1; the server should be informed of the clients’ variable change and stop sending updates. Network traffic as it is can be minimized. The only thing that has to be sent is the code, which should come in pre-compiled form. The client just has to open the file and interpret the code within. At this point the server and the client only need to communicate if the atom.client_updates variable is modified for any atom, or if the call() proc is used. 4) Would the client ever need to send data back to the server for any reason? Yes. When the server calls a proc on the client, the return value should be sent back to the server. The same goes vice-versa. The client should also have the ability to execute procs on the server, albeit in a limited fashion. This allows developers to add in their own routines which are called internally, not relying on verbs or byond:// links, both which can easily be faked by even the dumbest cheaters. • The client call() is similar and uses the syntax call(world, “ProcName”)(args). Specifying call(world, “client.ProcName”)(args) will allow the client to call procs on their own /client object on the server-side. • Naturally the server rejects every proc that the client tries to call and returns null if anything. Procs marked with “set rpc=1” (or something like that) can be called remotely by ANY client. If the rpc parameter is set, the first argument of that proc will be the client that initiated the request. | |
Android Data wrote:
Lummox JR wrote: That doesn't actually answer the question at hand: What should the client-side code calculate and what should be done with it? It's all well and good to crunch numbers, but it's what's done with them that matters. As an example, right now we have hard-coded client-side processing of several kinds, the most obvious being the "gliding" that occurs when an atom moves from one tile to the next. Every aspect – or mostly anyway – of the DM language should be available client-side. This should be possible because the Dreamseeker program is already capable of acting as a server. In theory yes; in practice less so. DS can act as both a server and a client, but the code implicitly assumes only one server--that is, only one entity running procs. If you were hosting in DS, the bytecode interpreter would have to be altered somewhat to handle the distinction of whether it was working with a server-side or client-side proc. But again, this leaves hanging the fundamental question: if we have this power, what do we do with it? 2) Would some of the calculations be stand-ins for data expected to come later from the server (such as pixel offsets for smooth movement), that would have to be synced up? What happens if the server sends no update because none is needed? How long should the client wait before syncing to the last known server value? • It should be possible to override the above behavior. The atom.client_updates variable (defaults to 0) exists on both the client and the server. If set to 1 on the server side and to 1 on the client side, the client will ignore server updates for any variables changed by the client. That seems less useful to me, but I guess it brings us back to quesiton #1. 3) How would the server send the right data to the client, or know what it needed to send, and how could the amount of network traffic for this be minimized? Putting aside the client_updates business, about the same level of communication would still be needed for the server to keep the client informed of what's going on, and that wouldn't change. What would change would be that any data needed by a client proc would have to be supplied by the server. About the only decent way to handle that is to have the server send the needed info in advance and have the client cache that, only sending further updates in the event of a change the client has not been made aware of. If that seems impractical (as it should), also keep in mind the server would have to anticipate the proc's needs, which is a significant compilation challenge. The alternative is having two-way communication in which the client stops every time it encounters something new and asks, "Hey, what's that?", which is basically untenable. 4) Would the client ever need to send data back to the server for any reason? If cheaters can fake a verb, they can fake an allowed client-to-server proc call. It would also be possible to modify the return value from a client-side proc. I'm not convinced there's much value in getting returns from client-side procs except in terms of something like interface management, but I could be wrong on that. But still, all of this is moot unless the #1 issue is addressed. Most of what you've brought up are implementation details. With this kind of thing a lot of the implementation is either obvious or highly complex. The real question is what to do, not so much how. Lummox JR | |
Lummox JR wrote:
That doesn't actually answer the question at hand: What should the client-side code calculate and what should be done with it? It's all well and good to crunch numbers, but it's what's done with them that matters. That should be mostly up to the developer... As an example, right now we have hard-coded client-side processing of several kinds, the most obvious being the "gliding" that occurs when an atom moves from one tile to the next. ...but it should be possible to override actions like these with a client-side proc. From there on a developer can alter the pixel_* variables to make the sliding happen by itself. In theory yes; in practice less so. DS can act as both a server and a client, but the code implicitly assumes only one server--that is, only one entity running procs. If you were hosting in DS, the bytecode interpreter would have to be altered somewhat to handle the distinction of whether it was working with a server-side or client-side proc. Personally I don't even see the need for hosting in Seeker anymore now that Daemon has a fancy interface. I suppose one way to solve this issue would be to create two separate threads: one running the server-side, and one running the client-side. When hosting in Seeker the server-side would just be invisible, unlike hosting in Daemon where you can control the server. But again, this leaves hanging the fundamental question: if we have this power, what do we do with it? That's up to the developer. I think it's best to first implement this, and then see what people would like to do with it. At least then the change would be much simpler than to work out everything beforehand (you're probably not going to be able to catch everything). If the server can order the client to issue a proc, there are any number of actions the client could do at this point. The developer may choose to create a "record" proc that causes the client to playback a movie in an empty map element akin to what I suggested earlier at full speed. I see that there would have to be a distinction between a client verb and a server verb. One of the things that comes to mind is that the developer may wish to make i.e. a button on the interface that mutes sound by calling a verb client-side. • Modifying the variables on any atom within the clients’ view should modify this atom immediately, until the server decides to send an update. The client doesn't need to wait. If the developer requires the original value, they can make a local variable or a client-side-only variable and store the old value in there. • It should be possible to override the above behavior. The atom.client_updates variable (defaults to 0) exists on both the client and the server. If set to 1 on the server side and to 1 on the client side, the client will ignore server updates for any variables changed by the client. The client_updates variable would cause the server to stop sending updates for a particular variable, even if it has changed. Although if this sort of change could be catched, I suppose it wouldn't be that useful. Putting aside the client_updates business, about the same level of communication would still be needed for the server to keep the client informed of what's going on, and that wouldn't change. What would change would be that any data needed by a client proc would have to be supplied by the server. Apart from proc arguments, I don't see how the server should get involved. The client should already receive copies of every atom the player can see, and this can be manipulated as such. For things that can't be seen, they could be included as arguments in the proc. I think I already suggested that the server should be able to send objects to the client which are not within view through a proc. About the only decent way to handle that is to have the server send the needed info in advance and have the client cache that, only sending further updates in the event of a change the client has not been made aware of. What would need to be changed is that the client would have to be aware of every variable it should on every atom in sight at the very least, as well as every atom in client.screen and every image in client.images. It may be beneficial to make a distinction in variables in the sense of a public vs. private variable: public variables are sent to the client, private variables aren't. By default all variables apart from some of the default ones (like name, icon, icon_state, dir, etc.) are private, so the client has no access to them. If that seems impractical (as it should), also keep in mind the server would have to anticipate the proc's needs, which is a significant compilation challenge. The server shouldn't try to anticipate the needs of a client-side proc; us developers should specify what the client needs beforehand. Developers have to tell the system what to do; it doesn't need to anticipate anything except prepare a few objects for us so we don't need to mess with that too much. The alternative is having two-way communication in which the client stops every time it encounters something new and asks, "Hey, what's that?", which is basically untenable. That shouldn't happen. Instead the client should just return null on everything it can't find. If the object hasn't been sent beforehand by the developer, it can't be accessed. If cheaters can fake a verb, they can fake an allowed client-to-server proc call. It would also be possible to modify the return value from a client-side proc. Correct, except what I meant by that sentence is that not every cheater knows how to mess with the networking at such a level that they can reproduce such calls or mess with return variables. But cheaters will definitely mess with the system if everything is built up out of verbs and Topic() calls. The motto here is to do what you always should do: verify that the stuff the client is sending you is accurate. The remote proc call functionality can be very helpful, but it can indeed break a game if the developer doesn't bother to include a few sanity checks. I'm not convinced there's much value in getting returns from client-side procs except in terms of something like interface management, but I could be wrong on that. But still, all of this is moot unless the #1 issue is addressed. There may be all sorts of advantages; we both can't tell, since we both have no idea what someone might try to do with it. But it would be very helpful if the server or client would actually get a return value instead of being left without an answer. If the server gets a call back from the client, it could mean "hey, I'm finished!" or "nope, I can't do it because <insert reason here>". Oh! How about a list of sounds that the client is currently playing? The server could talk to the client and call a proc. This proc would return the current % of volume or the state of the sound, or even the whole /sound datum if that's supported! | |
Lummox JR wrote:
1) What would the client-side code calculate and how would that impact the client's experience? Clients could perform any operations that a server could. However, any and all packets from the server supercede anything the client does: any changes done client-side must be assumed to be temporary unless they are performed on a unique client-side object (speaking of which: you would need to reserve a chunk of object identifiers for client-side use to prevent confusion regarding re-use), in which case they can be assumed to be permanent as the server would not even be aware of them. Attempts to modify any objects which are not in the client's memory (not in view, for example) should simply result in nothing happening. 2) Would some of the calculations be stand-ins for data expected to come later from the server (such as pixel offsets for smooth movement), that would have to be synced up? No synchronization is needed: the server doesn't give half a crap what you're doing on your client. "Synchronization" is assumed from the network protocol already used and if it is lost due to a poor choice by the programmer (like moving a mob halfway across the map client-side) then they're just going to have to deal with that. 3) How would the server send the right data to the client, or know what it needed to send, and how could the amount of network traffic for this be minimized? Procs defined as client-side (perhaps with a "set client-side" setting) would be executed client-side. If they belong to a client type, then they would exist server-side as a simple function that sends a message to a client. Otherwise, they would not be compiled server-side at all (possibly an option to have procs be both client-side and server-side, though I can't think of the benefit off-hand). Any additional data would have to be sent as an argument to a client-side proc. To clarify, because I think that's a mess: procs defined as client-side would all be compiled into separate bytecode sent to the clients, and ignored by the server executable with the exception of any procs belonging to a client type, which would be compiled into a function that would simply send a "run this proc with these arguments" message to a client. 4) Would the client ever need to send data back to the server for any reason? The return values for client-side client functions could be used for this purpose, with a null value being ignored. There is no reason to overcomplicate things. I mean, you could also argue for a client-side packet_received() proc which would by default parse the data and perform any operations and which you could override in order to perform your own interpretations on it, like interpolating mob positions and whatnot, which would require that you delay the actual effect of the packet for a period of time. But that probably wouldn't be worth the effort. What I described, however, is conceptually straightforward (though it is likely much more difficult than it sounds to actually implement) but is sufficient for some of the most obvious examples of client-side effects, namely intensive icon manipulation and graphical glitz. <edit>Oh, forgot to mention client-side variables. You could declare a variable as client-side (mob/var/clientside/dumbness = 0) and then the server doesn't care about it but the client would. No synchronization whatsoever. Bam. | |
Android Data wrote:
I'd really like to see a hard-coded method to do it since it'll be able to jot down instructions in shorthand which the client can then interpret through a single download, as opposed to the laggy method of sending everything to the clients at a timed interval. This is wrong. There would be no difference in the amount of network traffic between the two examples. In one, you are sending a list of variable changes. In the other, you are sending variable changes as they occur. There may be miniscule savings if you create an algorithm to represent things (like, say, stepping left and right forever rather than sending each of those steps), however this is beyond the concept of a movie and is getting solely into client-side functions and therefore is wholly unrelated to your original request. | |
I'm with you on this. It's easy enough to say, "The developer should be able to designate what should be run client-side," but what code even qualifies for this? If you change any non-local variables, the server is going to need to know. And then, once you've found the small subset of code that does qualify, would there actually be any value to reworking the communication system to handle differently a minority of procs which probably have negligible server impact?
There is at least one part of it all that I think could be done client-side though. All clients maintain a resource cache which includes the dynamic icons they're using. Icon procs tend to be on the slow end of the proc spectrum; this is probably at least partially due to the server->client communications that happen. Currently: If Player X has icon I in his cache, and I is modified, then X will download the new I1. X will have to have downloaded I and I1. If Player X does not have icon I in his cache when I is modified, X will not need I1 either. Ideally: If Player X has icon I in his cache, and I is modified, the only new information that X needs is that which would allow X to generate I1 from I; that is, it is sufficient to tell X to set a pixel in I or to resize it. If X does not have I, it follows that I1 is not needed either, and therefore the inability to generate I1 is irrelevant. In both latter cases where X did not have I, X would simply download I1 in place of I later if he should encounter the need for it. | |
Garthor wrote:
This is wrong. There would be no difference in the amount of network traffic between the two examples. In one, you are sending a list of variable changes. In the other, you are sending variable changes as they occur. There could be differences: in one instance, everything is sent as a single download and the client can play it back from the instructions. In the other, every single instruction (including icon operations!) is sent to the client on a need-to-know basis. If there is a lot of network traffic, the former will take a little longer but then play seamlessly afterward, but the latter will play laggy and the client will feel it. There may be miniscule savings if you create an algorithm to represent things (like, say, stepping left and right forever rather than sending each of those steps), however this is beyond the concept of a movie and is getting solely into client-side functions and therefore is wholly unrelated to your original request. But there is a point in that: with client-side processing, the server could use shorthand like that to describe instructions to the client. | |
Movies are handy for many reasons. You might want to record gameplay and play it back during the game. Or, you might want to record gameplay and post the video on YouTube. If you want to create a video file I recommend CamStudio (http://camstudio.org/). It's the only program of its kind that I've used, but it was free, simple, and worked fine.
If you want to record gameplay segments and play them back in-game, you might be surprised at how easy this is to implement.
To be able to play back a segment of gameplay, you just have to know the initial conditions (the state of all objects when you press "record") and all of the events that happen (mob movements, actions, etc.). Given this information you can recreate the camera's view and objects that perform the same actions of the recorded mobs.
Think of a simple example:
You create a game where players play musical instruments. Obviously the instruments would be simple. Suppose each instrument is represented as four buttons. With several players pressing some combination of buttons at different times you can get some fairly complex sounds. However, to let players record songs and play them back you don't need to capture the audio and save it as an .mp3 file (or some other format).
You just need to know at what times the players hit each button. Every time a player presses a key, make a record of the event (the key pressed and the current time). Since the events happen in order, your list of events will automatically be in order. Assuming the initial conditions aren't too hard to save/restore, playing back the movie can be surprisingly simple.
As another example, think of how Starcraft (or a similar game) lets you save a game to view as a replay. It's not a huge .avi file, it just remembers when all orders were given. To play it back, it plays a game but uses the replay file as input instead of user input.