Full Game Replay?

[Taki]

Hello.

As i mentioned in the CMX1 Engine it would be cool to have an Option to play an Save the Complete Replay of a game you played? That would be an awesome Film to watch.

I know it was a Problem to do with the TUrn Based we go thing. But in Realtime it should be no Problem to get a Review of that without using Fraps or similar? Or am i wrong?

[Steiner14]

Hopefully it is in. Could be one of the surprises, they are keeping back until the official release date.

[Schrullenhaft]

Unfortunately I don't believe that a 'full game replay' is in. In fact I'd guess that it won't make it in at all for CMSF and any of its modules. There might be an attempt at full game replay for the WW2-Normandy CMx2 game, but even then this appears to be a feature that is hard to program, even with the Real-Time engine of CMx2.

[Taki]

Oh Hi Schrullenhaft. You are the one that did that Pavlovs House mission to CMBB? Im right playing it at the Moment. Its Fun

[YankeeDog]

Just out of curiousity, does anyone with knowledge appropriate know how games like the venerable XWing series of Space "Space Flight Sim" games do it?

This (IMHO) excellent 1990s series had full-game replay, where you could re watch your fights, changing camera angle, replay speed, etc.

I'll take your word for it that it's hard to program. . . just curious as to exactly *how* hard it is, and why.

Cheers,

YD

[Battlefront.com]

There is no full game replay for RealTime or WeGo. There are two reasons for this. The first is that in RT the hit to the disk to track would hit the framerate too much so we didn't even try it. The second reason, and this applies to both, is the size of the data that needs to be stored. We estimated that a single game "replay" could be several hundred MB in size. The problem with this, from our end, is how to stream that much data smoothly. Someday we hope to dedicate the time to figuring it out, but with all the other things we had to do for CM:SF... we just didn't have the time to play around with it.

Most flight sims, and even vehicle sims, have a sort of "black box" recorder. The reason is they aer dealing with a LOT less data. Especiall flight sims since the majority of stuff is happening in the air. Deformable terrain, LOS, LOF, etc. chew up a lot of resources. Then consider that in a flight or tank sim you don't have several hundred individual entities using all these "expensive" components.

Steve

[Sergei]

CMx2 is a bit different to X-Wing series. Lasers flying in straight line are a bit less memory consuming than bullets that have individual flight paths modelled, even after ricochets. Then there's individual spotting, each man's position, stance, facing, action etc. at each moment to track. Just one minute's worth of replay can get very big with not a particularly large scenario. If a full replay file would grow to over half a gigabyte then there's not much point for Charles to spend his time on it - everybody's got their pet features but most of people have no knowledge about game development.

Maybe all wish lists can be fulfilled once DoD buys the game for $100 bazillion so BFC can afford to clone Charles' brain. Coding is many times quicker with a dual cortex.

Aw, Steve got to it first!

[Kineas]

I don't want to argue or something I simply just don't understand why the deterministic-engine approach would not work for CM.

You can compute everything in realtime, obviously you can compute everything in realtime during replay-time, user inputs taken from a file not from the keyboard/mouse. Replay file size is small.

I'm a firm believer of this technology so I'd really like to see where does it fail for an RTS game.

[Battlefront.com]

Too many random factors to do that. Every shot fired, every stimuli of a unit, every secondary effect from a hit, etc. must be stored. It has to be that way, zero way around it. We tried a deterministic approach with CMBO's early TCP/IP code and it failed miserably because no two CPUs process data exactly the same way. If you played two identical systems (and I mean identical) it for sure would work, but when you used two different ones all bets were off. More often than not it lead to divergence right away.

Steve

[moneymaxx]

Originally posted by Kineas:

... why the deterministic-engine approach would not work for CM.

I think the problem is that the CMSF-engine isn't deterministic but relies heavily on probabilities (e.g. spotting).

Even though I'am not a programmer I'd think that the outcome of spotting for example is determined by generating random numbers several times a second for each unit. E.g. if a friendly unit has a x percent chance of spotting an enemy, that could mean that it spots that enemy in the first few seconds of the game, not at all or after 5 minutes.

That means that with the same user input the outcome varies, or in other words recalculating doesn't work.

Therefore you would have to create a log file during game play, something like this: unit 1 at timestamp 1000 moves from 12,125 to 12,127, unit 1 at timepstamp 1001 shoots at ..... Obviously that would create a huge amount of information since you'd have to track not only units but all things that can be seen, even the gear on the vehicles that can be shot of (sandbag 135 hit at timestamp 1243, flying in direction x,y,z at a speed of .......).

Just for the records: I started writing before Steve posted

[Panzerfest]

I was just thinking in lieu of a full playback feature the ability to 'rewind' maybe a minute of RT action would be useful and give a classic CM 'WeGo' feel to RT CMSF.

I found in CMx1 that sometimes I'd miss an important piece of action and be left wondering what popped my king tiger!

Although a full playback feature would be really cool, this would be a good trade off and give a better overview of the action when things get really hectic.

[MrSpkr]

Originally posted by Panzerfest:

I was just thinking in lieu of a full playback feature the ability to 'rewind' maybe a minute of RT action would be useful and give a classic CM 'WeGo' feel to RT CMSF.

I found in CMx1 that sometimes I'd miss an important piece of action and be left wondering what popped my king tiger!

Although a full playback feature would be really cool, this would be a good trade off and give a better overview of the action when things get really hectic.

What a great idea! And to think you came up with it only eight days prior to the release.

No worries, though. I'm sure nobody would mind Steve and company delaying the release an additional six months while they investigate your wonderful idea.

Steve

[Kineas]

Random number generation is not a problem, because rnd generators are inherently deterministic (strange, isn't it?). You need one for the determ. part, and other(s) for the effects.

Floating-point calculations can be a problem, because there's no standard which prescribes identical results on the bit pattern level for numerical operations, so the results can diverge.

[undead reindeer cavalry]

Originally posted by Battlefront.com:

Too many random factors to do that. Every shot fired, every stimuli of a unit, every secondary effect from a hit, etc. must be stored. It has to be that way, zero way around it. We tried a deterministic approach with CMBO's early TCP/IP code and it failed miserably because no two CPUs process data exactly the same way. If you played two identical systems (and I mean identical) it for sure would work, but when you used two different ones all bets were off. More often than not it lead to divergence right away.

there are algorithms that produce reprudicble random numbers no matter what the system. i think "Mersenne Twister" is the most commonly used algorithm for such tasks. there are numerous free implementations around the net.

[Kineas]

Every random number generator is deterministic. They produce a sequence of 'random' numbers. The same sequence from the same starting point always.

The Mersenne Twister is suited for scientific applications, games can use simpler (and a lot faster) ones.

[Steiner14]

Originally posted by Kineas:

Every random number generator is deterministic.

But by far not deterministic enough for game-replay.

Think of the tremendously complex and non-deterministic cache, the register contents, the differing clock and clock-drifts and last but not least, the highly non-deterministic scheduler with non-deterministic c-tasks, sempaphores and so on. Simply impossible.

It's difficult enough to build a deterministic hard-realtime system.

[Kineas]

I don't get this, a random number generator just produces a sequence of integers.

Computer games have been built in significant numbers using the deterministic approach (Starcraft, XWing, Age Of Empires etc).

Floating point calculations and multithreading complicates the issue, but multithreading just enters the scene now.

Originally posted by Steiner14:

</font><blockquote>quote:</font><hr />Originally posted by Kineas:

Every random number generator is deterministic.

But by far not deterministic enough for game-replay.

Think of the tremendously complex and non-deterministic cache, the register contents, the differing clock and clock-drifts and last but not least, the highly non-deterministic scheduler with non-deterministic c-tasks, sempaphores and so on. Simply impossible.

It's difficult enough to build a deterministic hard-realtime system. </font>

[Matchstick]

There are hardware random number generators that use physical properties like thermal noise to generate numbers in a non-deterministic manner.

Apparently the Commodore C64 and the VIA C3 processors include built-in hardware random number generators though I'm not sure whether these would actually be non-deterministic.

http://en.wikipedia.org/wiki/Hardware_random_number_generator

[Steiner14]

Originally posted by Kineas:

I don't get this, a random number generator just produces a sequence of integers.

Given the random generator alone would be the problem, it already depends totally on the random-function that is used, which (nondeterministic) factors are used for the calculation and for what the calculation is needed.

And don't forget, that CMx2 is a highly time-dependent application. So a lot of calculations are definately based on some kind of internal time and since it was not developed as a hard-realtime application and is not running in a realtime-environment on a realtime OS, things are just not that deterministic as you think.

You can start two identical Windows computers with identical software and there comes the point, where one clock is one microtick faster than on the other computer that causes a macrotick and from that point on, they develop completely differently and after a certain amount of time they have completely different internal states. Multitasking and multithreading systems are highly nondeterministic.

[dan/california]

This is one of those bits of technology that is MUCH more complicated than is usually realized. Its like cell phones, everybody has one and thinks they know how it works. But at the actual hardware-firmware level it is phenomenally complicated. Then you start talking about packet switching routers and start to really lose your mind.

I pre-ordered this game in large part because I think Steve, Charles ,and company know what they are doing. If they say it is bloody hard to do and will eat your entire hard drives memory I believe them.

[David Chapuis]

Originally posted by Sergei:

Then there's individual spotting, [/QB]

1:1 spotting? I remember reading CMSF was not doing that. Did that change?

[Sergei]

Originally posted by David Chapuis:

</font><blockquote>quote:</font><hr />Originally posted by Sergei:

Then there's individual spotting,

1:1 spotting? I remember reading CMSF was not doing that. Did that change? </font>

[MHertogh]

Originally posted by Battlefront.com:

Too many random factors to do that. Every shot fired, every stimuli of a unit, every secondary effect from a hit, etc. must be stored. It has to be that way, zero way around it. We tried a deterministic approach with CMBO's early TCP/IP code and it failed miserably because no two CPUs process data exactly the same way. If you played two identical systems (and I mean identical) it for sure would work, but when you used two different ones all bets were off. More often than not it lead to divergence right away.

Steve

I cry Shinanigins!

If you have multiplayer WeGo you just need to stich together all of the turns. Or are you saying E-mail WeGo does not work either.

In WeGo you either have one CPU crunch the numbers and send the result to the other (meaning you can store the result) or you have both machines crunching the numbers at the same time (which I beleave or Original games do) which means that the two machines do process the data the same way.

Also in RT If one machine acts as the host then the data they are spewing is not going to be over 400kbps which can pretty easily be streamed to hard drive as it is streaming it to the net which little slowdown on most modern machines.

Now I can beleave that you guys just did not want to put forth the engineering effort to make it work, and if you did I am sure this game would be shipping a month or two later than now but please don't say it is impossible or there is only one way to do something.

MHertogh

p.s. I love you guys but I still have to call shinanigans when I see it.

[MHertogh]

Originally posted by Steiner14:

</font><blockquote>quote:</font><hr />Originally posted by Kineas:

Every random number generator is deterministic.

But by far not deterministic enough for game-replay.

Think of the tremendously complex and non-deterministic cache, the register contents, the differing clock and clock-drifts and last but not least, the highly non-deterministic scheduler with non-deterministic c-tasks, sempaphores and so on. Simply impossible.

It's difficult enough to build a deterministic hard-realtime system. </font>

[Sergei]

Originally posted by MHertogh:

I cry Shinanigins!

If you have multiplayer WeGo you just need to stich together all of the turns. Or are you saying E-mail WeGo does not work either.

Err...

There is no full game replay for RealTime or WeGo. There are two reasons for this. The first is that in RT the hit to the disk to track would hit the framerate too much so we didn't even try it. The second reason, and this applies to both, is the size of the data that needs to be stored. We estimated that a single game "replay" could be several hundred MB in size. The problem with this, from our end, is how to stream that much data smoothly. Someday we hope to dedicate the time to figuring it out, but with all the other things we had to do for CM:SF... we just didn't have the time to play around with it.