Replay system?
banny
Join Date: 2009-09-05 Member: 68703Members
Join Date: 2009-09-05 Member: 68703Members
HI evryone, I'm just asked myself if a replay system is on the way, cause i'm planning to comment the first team match of ns2 when they came out(in french), i think we have time and team match will not happen before all the basics are in the game, like the building and all the classes.
But i'm really worried if ns2 doen't get a replay system that will be a hudge mistake.
So I wana know if you plan it, cause the game is clearly oriented e-sport, and if yes if it's a unknow world priority or if it gonna be realease later when the game came out .
But i'm really worried if ns2 doen't get a replay system that will be a hudge mistake.
So I wana know if you plan it, cause the game is clearly oriented e-sport, and if yes if it's a unknow world priority or if it gonna be realease later when the game came out .
Comments
and the potential of fun and entertainement is big. No replay for commentator until the game realease is sick.
but i know UE are small team and they work against the time, but i say it again, with all the chamber, onos who blow dors, jet pack,blink fade and all the stuff NS2 have hudge theatral potentiel.
e-sport + fun to see = epic win.
I would agree this is a key feature to this becoming an e-sport
But until they have the time FRAPS will be good enough.
It could be enhanced by having multiple spectators.
They are still optimizing how game events get transmitted and consumed by the server and client.
A recording playback feature would have to change each time that changed drastically.
A potential problem would be that the networking is based on a need-to-know basis (You only receive updates about entities that can be seen or heard from where you are standing from the server... thats why you see things popping up as commander on a laggy server if you quickly go somewhere else on the map). That means that a client-side replay-system could only allow to replay from 1st person, not to fly around the map as spectator. The only way to do that would be to install the replay-system server-side, so admins could start the recording and would later need to download the replay-file from the server.
edit: Or the server could keep around a list of players (likely admins) that are allowed to record the whole world state and would sent them everything after recording was started. Not sure if admins would actually install that because it would probably significantly increase the upload for the recording player --> might cause lag. Maybe if the limit of players is really due to server performance and the server has unused bandwidth.
there has already been 2 match, and 1 mix match.
For moviemaking(which I've done alot) and commentating, this is really needed.
Massive spectator abilities, like HLTV.
The replay file should be accessable to everyone.
For the moviemaking side I would like to see the following be able to be done with the replay file:
- Free look. With camera path settings, like 3Dsmax etc.
- First person view of all players, even commanders(with their mouse movement).
- Different effects, such as wireframe, transparent walls, green screen(selectable if you want players/enviorment/buildings to be green). The more of these types of effects we can make with the replay, the easier it will be to make great movies.
- Rendering uncompressed .avi files directly from the tool would be great. (Compared to rendering pictures in the HL1 engine which needs conversion to a .avi, this is far superior)
- Easy Enabling/Disabling all HUD(except kills/deaths), but we already have a console command for that as far as I recall. Maybe make it so you can choose which of them you want enabled/disabled.
I know this is not a very high priority, but please try get it in before you release v1.0. That would make it alot more e-sport friendly. And make me a happy moviemaker! =)
People must see and be interest to the game before the release cause after people think (if i din't know this game then it's release ... that mean this game isn't great).
So I realy think people must know the game before it's realese and commentating replay of team give to the game a "pro aspect" .
It's like litle brother want what the older brother get. if the older brother buy a ps3 he's litle brother will want a ps3 too.
This is the same for the game if people see good player play to a game they want to try it too.
e-sport is not just a "professional side of a game" it's a dream maker who wich make people the need to play at the same game.
a replay system at the release is from my point of view too late
btw i wish you GL for your project wulf 21
but at the release it will be too late, so for me as soon as the onos/ha/jps will be release that will be the right time to think about it. But release is definitly to late.
It's not something they should work on ASAP, but definitly before they release v1.0, to show their support to the e-sport of NS. That will bring them many goodies in return. Such as better fragmovies/commentarys on youtube etc. Which attracts new customers. Gamers love when developers does this, and makes the value of the game much higher.
<!--quoteo(post=1849744:date=Jun 3 2011, 06:44 AM:name=wulf 21)--><div class='quotetop'>QUOTE (wulf 21 @ Jun 3 2011, 06:44 AM) <a href="index.php?act=findpost&pid=1849744"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm actually playing around with creating my own replay system. I already came so far that I can save a table into a file that can contain variables of all types which are allowed to be network-variables. My personal next milestone would be to be able to save and load the whole state of the world, then I'll try to put multiple states in a file.
A potential problem would be that the networking is based on a need-to-know basis (You only receive updates about entities that can be seen or heard from where you are standing from the server... thats why you see things popping up as commander on a laggy server if you quickly go somewhere else on the map). That means that a client-side replay-system could only allow to replay from 1st person, not to fly around the map as spectator. The only way to do that would be to install the replay-system server-side, so admins could start the recording and would later need to download the replay-file from the server.
edit: Or the server could keep around a list of players (likely admins) that are allowed to record the whole world state and would sent them everything after recording was started. Not sure if admins would actually install that because it would probably significantly increase the upload for the recording player --> might cause lag. Maybe if the limit of players is really due to server performance and the server has unused bandwidth.<!--QuoteEnd--></div><!--QuoteEEnd-->
I've always thought the best way to accomplish this is to have the server record every match, but only store something like 10 matches at any one time. Match recording could then be downloaded after the fact (either in-game or via an external website).
This, pretty much, in combination with what wulf already pointed out.
The server's game-state would be dumped to a file every n milliseconds (decreased interval for an increased accuracy, but at the cost of disk-space and server-performance). At a later stage this file could be downloaded and played back on a listen-server, and hopefully the client's prediction-system will smooth out the gap between the intervals (game-state snapshots).
In france we have too commentator who comment together and are the equivalent to husky and hd starcraft.
those guys make me buy sc2 ... A community is half of the succes of a game if you develop a hudge curiosity with e-sport match commentating replay before the release, you will easily increase you're potentiel buyer WITHOUT any marketing.
A release is a important moment it's the moment or the fan buy the game , and we got a effect "snow ball" (don't know if this expression exist in english), more fan you have before the release more buyer you will have. in some way it's like a buzz.
So the best plan possible is the starcraft way, get a hudge community before the release, and at the release momment this community atract people who don't know the game.
A good release need teasing before, best EVER made teasing system is community.
For finish my argument i will say than NS2 have a lot of time before him so don't panic. I know a replay system now is too early but like 4-5 month before the release is the good time.
Btw some easy thing to do is to get a litle minimap, first person,frag,and name of player wich we aim as a spectator and that will be enought until a true replay system.
Create executable program (recorder), which can connect into server and record all thinks what happens on server.
I mean all user inputs of clients, join into game, left the game, player's keyboard inputs, marine/egg spawning, global events, etc...
Record just all inputs, NOT THE STATE OF THE WORLD!
.. because one of main prerequisite is, that the game is exact. Once the same inputs is filled to the server, the server will create the same world state in any time.
The recording can be delayed / buffered, with low priority .. as it's only record and not to affect server tick rate too much :)
-----------------------------------------------------------------------------
Then modify server to accept recorded file as inputs from clients (instead of network from clients).
... also allow only "spectators" to join ( to allow view the game by regular clients).
here is my 2¢
I still think a regular game-state dump is the best way to go, for it doesn't get corrupted between builds (that easily), can be played back on listen-servers without effort, and contains everybody's perspective. It's single biggest drawback would be the performance-hit.
Create executable program (recorder), which can connect into server and record all thinks what happens on server.
I mean all user inputs of clients, join into game, left the game, player's keyboard inputs, marine/egg spawning, global events, etc...
Record just all inputs, NOT THE STATE OF THE WORLD!<!--QuoteEnd--></div><!--QuoteEEnd-->
Unfortunately this sort of thing is actually a lot harder than it sounds. Currently FPS in general are not set up to make it easy to do. This technique is called "Lock Step Networking" and it requires the game to be <b>perfectly</b> deterministic. Even a slight difference in any given frame will snow ball and make the replay completely incorrect later in time after the error is made. I imagine many game variables are floating point, and floating point math is difficult to guarantee execution will generate exactly the same result across all architectures and hardware configs, etc. You don't notice the differences now, because the game always references the server's state of the world as correct, so any differences in state are just over written.
Well, actually I have to admit that a computer doesn't create real random numbers but pseudo-random numbers which are created by an algorithm that makes them look like random. If you initialize the algorithm with the same starting value, you can recreate the same sequence of "random" numbers. NS2 makes use of that by a function called "NetworkRandom()". (can't look into code now, someone correct me if not spelled right). It initializes the algorithm with the same value at server and client and if it is now called exactly the same number of times both on server and all clients, it will produce the same "random" values on server and client.
But still, only saving the player input wouldn't work, you would need additional information.
Well, since this post became more frequented lately I may update you on my progress. I'm almost finished being able to save and load a single world state. The last 2 weeks I fixed a ton of bugs in my code. Figuring out the causes of bugs is actually the hard thing to do, writing the basic code was the easy part XD.
As an example: NS2 stores a lot of times. Since there is no function to set the current game time I have to calculate the time difference between save time and load time and add this to EVERY time value. Fortunately nearly all time variables contain "time" or "Time" in the name so my code can identify them automatically by searching their names for these strings. Unfortunately, there are some variables not containing them but representing times as well (like "animationStart" or "activityEnd"). And there are variables that contain "Time" but should NOT have the difference added cause they don't represent absolute game times but are time differences themselves. And there are special cases when the time difference should not be added, in particular if the time when the rifle started firing contains a zero, that means that the rifle is not firing. Adding the difference here makes the game think that it is firing.
If not done correctly, this causes a lot of bugs that don't seem to be related to that at the first look. E.g I had a bug when after loading I was far over or under the map but slowly getting closer to the map. After some hours of searching I finally figured out that this was related to the code that is smoothing out the view height when going stairs up or down, so it doesn't feel wobbly. Normally the time when you last stepped over a stair would be in the past, so the game interpolates between the last height and the current height. If due to not adding the time difference after loading the time you last stepped over a stair is in the future, the game will set the view the opposite way.
Actually I solved most bugs now, I'm still working on some glitches that happen if you are a commander while saving, e.g. you currently can't build stuff directly after loading in commander mode because your previous selection became invalid. You have to select something first.
As for demos and the system staying valid between builds: I'm writing the plug-in to be as general as possible, maybe it would even be possible to merge it into the code of some other mod. But I ended up putting a lot of NS2-specific stuff in there like techtrees, team resources e.t.c. Additionally every variable that is not a network variable (exists only on the server) but still needs to be saved (like the id of infestation attached to alien structures or the loadout a player had before becoming a commander) needs a special treatment, too, that making a client-side first-person-only version of the replay system more unlikely, because I would have to reconstruct, plainly guess or ignore what is not transmitted to the client. I can do it that way that if these things are simply no longer present (or not present in the mod), it would do no harm, but I would have to rewrite parts if new things that need a special treatment are put in the game (like new alien structures).
It is however more likely that old demos refuse to work correctly with newer builds. The devs would simply need to put a new and important variable in the game and you will probably end up having a nil-value Lua error in your console because that variable is not present in your demo.
As for getting from saving single world states to actually recording and playing back demos, there are still some hurdles to take. For example a saved world state currently has a size of around 200KB. Now imagine a 30 minutes game with average 10 fps (taking server tickrate going down into account) and you would end up having a ridiculous 350 MB demo. But that is due to the fact that I wrote basic system for saving variables in that way to make it as simple as possible. I'm confident that I can optimize it to only saving as many bits as necessary (for example writing a 1 byte unsigned integer (char) for enumerations instead of an 8 byte double precision floating point number) and leaving out unnecessary data (e.g. table indices that are only counting from 1 to table length), which would cut the file size down to about 10% of what it is now. Additionally I expect that less than 10% of the variables are changing between 2 world states, so I could scrimp a lot of file size by only saving the differences between the world states. Combining both I would get a reasonable size of like 3 MB.
That said, maybe I'll post the save/load code when it's done because guys trying to write a singleplayer mod might be interested in it.
I'm not sure what your question is aiming for.
If it's "why can't you do a client-side all-seeing replay system?": Even a spectator is only getting updates about what he currently can see or hear from its position. That's why an all-seeing replay-system that allows to roam around freely must be created server-side, or the server needs a send-everything-to-recording-client mod.
If it's "why do you need data that is existing server-side only?": I need some of the data that is existing server-side only because at replay time I'm trying to write the data to an actual local server, so it can smooth out the missing frames between 2 saved states with the actual game code (if it has the CPU power of course). With only client-side data I would have to create a whole fake server from scratch that would send the recorded data to the local client. I'd imagine that being more difficult than using the existing server code.
I'm not saying that record system will store only player inputs! I'm saying about inputs, that includes global events (like hydra spike random delay calculation result :) ) .. the replay recorder will store also all these random numbers, and replaying of game will don't generate another random number, but get it from file and system will be deterministic.
And also when you will record game on build i.e. 185 :) .. the replay will works well only on build 185. on next build you need record another game.
If it's "why can't you do a client-side all-seeing replay system?": Even a spectator is only getting updates about what he currently can see or hear from its position. That's why an all-seeing replay-system that allows to roam around freely must be created server-side, or the server needs a send-everything-to-recording-client mod.
If it's "why do you need data that is existing server-side only?": I need some of the data that is existing server-side only because at replay time I'm trying to write the data to an actual local server, so it can smooth out the missing frames between 2 saved states with the actual game code (if it has the CPU power of course). With only client-side data I would have to create a whole fake server from scratch that would send the recorded data to the local client. I'd imagine that being more difficult than using the existing server code.<!--QuoteEnd--></div><!--QuoteEEnd-->
You say even a spectator is only getting updates about what he can currently see. Now throw in a spectator that can see (and hear) everything. What would the server send to that spectator. Store that into a file and you're halfway done.
I actually wonder if this is what happens when you fly outside of the map with the current spectator. If I'm looking down at the map from above as a spectator outside of the map, am I rendering/getting updates from all parts of the map (which would explain why my framerate tanks when I do this)?
On this screenshot you can't see the hive in alien start:
<img src="http://i.imgur.com/vZjqu.jpg" border="0" class="linked-image" />
fly a little closer and you can see it:
<img src="http://i.imgur.com/Rvm5L.jpg" border="0" class="linked-image" />
(if you wonder about the odd resolution: screenshots taken in windowed mode)
Well, the server has the authority about what is sent to whom, so an all-seeing spectator class would have to exist on the server, too. If I would have to mod the server anyway if I would try a client-side all-seeing replay system, instead of introducing an all-seeing spectator I could mod it that way: client tells server that he is recording --> server sends everything to client. It wouldn't really matter if the client would spectate or actually play.
But then again, the system determining what is sent to whom is there for a reason: To limit the network traffic to what is actually necessary. I'm pretty sure server admins wouldn't like that just anyone could record everything, that way increasing the traffic. So I would need to put in an option to limit that to specific players and we would probably end up only admins and people trusted by admins being allowed to record everything. But if an admin would need to be present to record everything anyway, I don't see why to bother about creating a client-side all-seeing replay everything system at all. In the end the admin could simply tell the server to record, then download the replay from the server. So if I do a client-side version of the replay system it will allow to play back from the clients first person view only.
it would definitely make sense to create an "all-seeing spectator class". HLTV was quite popular, and everything you do now (saving world states to create a "5?" minute buffer
as delay) aims for such a tool. it would be really nice to have some piece of software that acts like hltv but for ns2, and the best thing is to create
an all-seeing-client who can record and host delayed spectating to a bigger amount of clients (which would not cause more network traffic to the actual game server).
i liked this system in half life, and if ns2 wants to be a competitive game, we would need something like that.
the game server (maybe i expressed it unclear before). all what this third party tool has to do then is to buffer the information (= delay to prevent abuse) it gets and
send it to multiple other clients (without even knowing that this data is about a game called ns2)
all i wanted to say is: if you manage to identify all relevant data (without too much overhead), then the step from recording a match to replaying it to
creating a HLTV kindof application is not too far ahead. but as written somewhere before, the identification of all the necessary information is not very easy,
at least you cannot be sure that your code will always work, regardless of future game patches :(