Possible addon with new Unity engine?

[Lancefighter]

Or, only support replays for major releases? with a giant 'I TOLD YOU THIS WOULD BE A BAD IDEA' if someone complains that it doesnt work in pre-release
(and generally ignore version complaints)

[Diazo]

Ummm.

That still ignores the fact that the data for the replay itself is not saved currently.

In fact, at the endgame with thousand of ships flying around from both sides, I could see a (decently compressed) video actually being smaller in file size then the same replay would be.

Take a single ship that gets built, in the first seconds of it's life you have ship ID#, ship type/mark, built time, built co-ords (including starsystem), move to co-ords (with starsystem), move speed to cover modifiers. I don't know how AI's co-ordinate system actually works, but even estimating low on the data use I see 42 bytes of data for a ship as soon as it's built, assuming no overhead at all. That's not counting what it does over it's lifespan.

25 bytes doesn't sound big, but that only goes into 1 megabyte 25 thousand times. In my current game at the 12:17:00 game time mark, I'm guesstimating about 105 thousand ships built between me and the AI.

That's 4 megabytes of data to record only the ship being built and it's starting move order in my current game, and I consider my current game close enough to average for this.

Keep in mind I guessed low on the data use, in reality it's probably over 5 megs, if not hitting 6 megs to record this data.

I also ignored data compression, but that would be another layer of complexity for X or keith to program, and increase a replay's save and load times.

Ya, video recording is the way to go. A lot less hassle and you can break it out and send over just that one interesting battle rather then a giant replay file.

And it will take some experimenting to get the video record settings for the replays, but once those are found and posted, it will not be a big deal to setup really.


 

Look at what you made me do, you made me do math!  

D.

[Lancefighter]

apparently not big on the whole 'commands' thing.

For instance: http://springrts.com/wiki/Spring_Replays
Spring generates a replay for EVERY SINGLE GAME played, and saves them automatically. On this computer, I have logged around 50-70 hours of springplaying on this computer. My replays folder is 107 megabytes. The average game seems to be around 50 minutes, taking up 1 meg. The largest game took 2.5 hours, for a whopping 5 megs size. (randomly extrapolating, I'm thinking no more than 20 megs for a 10 hour campaign..)
This includes the ENTIRE 8 player game, start to finish, every PLAYER ACTION.

Player builds this, its recorded, player gives this command, its recorded. Player gives that command, its recorded. That is all you need - if the engine is the same, then more or less every action taken will yield exactly the same results. Sure, you could video record the same game of spring, but you end up with a considerably larger file (a spring game of 30 minutes will be less than a meg of replay file. Can your video give that much compression?)

You neednt record every single item build, just that it was commanded to be built. You neednt record every ships commands, just that <this selection group> (often clicking on the planetary summary) was given this command..

Now, with ai wars fuzzy ai feature, it might get slightly more complicated, until you think about this - Multiplayer games are only a series of commands sent between players. Spring can run perfectly fine multiplayer games on dialup if you must (not that many recommend it) and I am sure Ai war is similar. The clients send sync messages back and forth, and the host oftens sends the entire save file to every player if there is a problem.


tl:dr - Replay data is commands, just like multiplayer games.

[keith.lamothe]

Actually the data storage size isn't the problem: we wouldn't be storing the replay, we'd be storing a saved game and all the commands that were executed during each cycle.  The commands would add a fair bit to the size, but not unmanageable so. What Lancefighter just said.

However, this is really just an academic discussion at this point:  Ain't gonna implement it, wouldn't be prudent.

[Diazo]

I still think my point stands.

The fact the ship is built has to be recorded somehow, the move command recorded somehow, etc.

The exact method would be something to be determined.


Regardless, it looks like you would just save a direct log of the commands executed per cycle somehow.

I play a single player game and I'll hit points where my Core-i7 slows down due to so much happening in a single cycle it can't execute on a real time basis.

I have no clue how much data that would actually be, but it has to be significant.

Regardless (again), this is all moot since there's no chance of this happening.

Really, a saved game works as a "replay" in almost all situations as it is.

D.

[Lancefighter]

I disagree there actually. Your game might slow down, not because many commands were given, but because your computer sucks 

Take this single command for instance - select all mobile military. Jump through wormhole.

It takes a very very limited amount of effort to do this (at worst, id say a bandbox selection would require 4 xy coordinates and that would require the most memory), and a single command given. Yet 2k ships just went through a wh to engage hostile forces.

the ship being built is a byproduct of the fact that a command was given to build said ship. The ship as an entity never exists, just that it was built, and what commands were given to it. Kinda mind boggling

However, yeah, what keith said :\

[keith.lamothe]

I still think my point stands.

The fact the ship is built has to be recorded somehow, the move command recorded somehow, etc.

The exact method would be something to be determined.

I'm really not trying to argue here, it's a very moot topic, but actually the method of storing and serializing those commands is already extremely well determined and worked out; it's the foundation of the game's network communications  So all the game would have to do is write those commands to disk after finishing with them (could be handled by another thread), and then all you'd need is the save file and the command log file.

I play a single player game and I'll hit points where my Core-i7 slows down due to so much happening in a single cycle it can't execute on a real time basis.

I have no clue how much data that would actually be, but it has to be significant.

99% (or more) of what's actually happening on your machine to slow it down is something other than the commands, it's the simulation itself.  All that processing is exactly what would happen during the replay, all over again.  It would literally be like you playing the same game over, issuing the exact same commands at exactly the same time, and the AI doing the same.  Only difference would be that you couldn't issue commands while watching your past self

Anyway, I need to stop spending time in this discussion, but I wanted to set that particular point straight.

[RCIX]

the ship being built is a byproduct of the fact that a command was given to build said ship. The ship as an entity never exists, just that it was built, and what commands were given to it. Kinda mind boggling

But the sheer quantity of commands issued over the course of even one play session makes this prohibitive.

[keith.lamothe]

the ship being built is a byproduct of the fact that a command was given to build said ship. The ship as an entity never exists, just that it was built, and what commands were given to it. Kinda mind boggling

But the sheer quantity of commands issued over the course of even one play session makes this prohibitive.

Well, if it had to actually save all the commands that a specific ship (we call them UnitCommands) ever had, then that would be worse, but actually it only has to track the GameCommands, which correspond roughly to a UI action by the player.  Granted, giving a move order to 1000 ships could be somewhere near 20 Kilobytes due to the string serialization of the numbers, but it's not going to challenge modern decent-capacity hard disks.

[Diazo]

I disagree there actually. Your game might slow down, not because many commands were given, but because your computer sucks 

Take this single command for instance - select all mobile military. Jump through wormhole.

It takes a very very limited amount of effort to do this (at worst, id say a bandbox selection would require 4 xy coordinates and that would require the most memory), and a single command given. Yet 2k ships just went through a wh to engage hostile forces.

the ship being built is a byproduct of the fact that a command was given to build said ship. The ship as an entity never exists, just that it was built, and what commands were given to it. Kinda mind boggling

However, yeah, what keith said :\

Okay, so AI war's code can guarantee that the same fleet ships can go through a wormhole and the random (or I assume random) moving of ships as they unstack from atop one another will always end up in the same place?

I can follow your logic in how the commands, not the results are saved, I'm just thinking there's too much randomness involved. Without being able to guarantee a battle will play out the same every time you'd need more then just the attack command saved to the replay.

Ultimately keith has said he knows how he'd do it and that he's not going to for various reasons so that's that.

D.

[RCIX]

Believe it or not, that's how most replay systems work. They make the game simulation deterministic, so that you can input the exact same commands and get the exact same result. It makes many things a pain to code, but ensures you can do things like multiplayer and replays.

[keith.lamothe]

Yea, if the simulation wasn't deterministic you'd get desyncs like crazy when playing multiplayer

[Diazo]

I suppose this is a UI thing maybe but I don't see AI war's system being that simple.

Not have seen the actual code, all I have to go off of is the UI and I'll use Supreme Commander in this example.

Take the move order on a fleet(or formation for SupCom). In Supreme Commander each unit gets it's own individual path and seperate destination based on their starting position that is shown when you check their path's.

In AI War, they have one common destination which upon reaching, then do a second (or more) move to unclump which is not an entered command. Now, from the what I'm hearing, this unclumping will always happen exactly the same way regardless of the computer the replay is being run on?

This is what I'm having trouble wrapping my head around, this unclumping is actually not random at all?

D.

[Lancefighter]

yo dazio, you never played spring did you...

the spring engine, if anything, is a more complex engine in terms of stuff happening - ai war is 'flat'... spring has a good deal more things to deal with, like semi-realistic phsyics.

Yet somehow, a game played will play twice exactly the same way, if the exact commands are given.. (for the record, spring 'mods' arent like patches... and well, theres no saving and loading either. Because that would require the entire simulation to be re-run from the beginning until that point. Hellooo huge load times!)

edit:
as for moving mass amounts of stuff, generally, it follows a very strict set of loose rules. I'm assuming each ship does nothing other than get the closest path away from the ship its intersecting with, ad infinium. Maybe.

[keith.lamothe]

To understand this, it helps to realize that the replay is basically exactly like being in a multiplayer game without the ability to issue any commands.  

When you're playing a multiplayer game and that group of ships starts hitting the destination and starts unclumping (actually there is a lot of pre-emptive unclumping via destination displacement, but anyway)  It is absolutely, critically necessary that your computer and every other computer in the mp game work with 100.00% identical destination points for every single one of those ships.  Any failure in that will eventually result in a desync (and require that the game be restarted from a save or abandoned).  And there's just no way we can serialize all those destination points across the network and you get any kind of reasonable gameplay speed.  So each computer must independently run the simulation, and get exactly the same results.  Thus the requirement for lockstep determinism.

But there is randomness.  How?  Remember that a cpu is incapable of generating purely random numbers (outside of externally caused hardware failures, and that's up to the randomness of said external causes), they're all psuedo-random based on initial seeds and a generation algorithm.  So we just make sure that all the machines in an mp game start from the same random seed, and call "Next" on that seed the exact same number of times for exactly the same reasons.  

Incidentally, this is one of the harder aspects of coding the game, though things are so rock-solid by now that all we have to do is follow some fairly intuitive programming rules and it's fine.