Time Compression

[Heretic]

As I understand it, that's just the nature of time compression. At no compression, you have tiny slices of time between each event check. As you get more and more compression, your time slices become much larger, so you can be moving hundreds of feet between event checks at high levels. I wouldn't think SH5 could do anything about that.

[ichso]

But there could be explicit workarounds for some situations. Like in said plane spotting scenario, it could force the plane into a position from where it is supposed to be spotted first.
But this approach wouldn't be useful for all kinds of situations. You can't just handle ships that way, at least not in vicinity of land.

[Jimbuna]

Originally Posted by onelifecrisis

I'm guessing TC will work exactly as it did in 3 and 4. I can't see any reason why they'd change it. But AFAIK no information has been given on that subject.

I'm hoping so

[Frederf]

Originally Posted by Heretic

As I understand it, that's just the nature of time compression. At no compression, you have tiny slices of time between each event check. As you get more and more compression, your time slices become much larger, so you can be moving hundreds of feet between event checks at high levels. I wouldn't think SH5 could do anything about that.

Here's a clever way around this. Say at 1024x you are getting an event check every 10 minutes. Let's call the event right before the plane is spotted 12:00 and the one right after 12:10. The plane would have been spotted at 1x at 12:04.

Clearly with a normal scheme the plane would be 6 minutes later into it's attack run when detected at 12:10 (instead of 12:04). To fix this the game remembers the 12:00 state until after the 12:10 state is formed. In the instance that the 12:10 spots a plane, the game rolls back to the 12:00 state and proceeds forward again at a lesser TC (maybe 128x?). Every time this process is done, TC is reduced until within some tolerance (+/- 10 seconds?) it finally says "close enough" and let's the event happen.

The result is the player comes out of 1024x to 1x TC exactly at 12:04 which is exactly when it would have (+/- the tolerance) as if the player had been at 1x the whole time.

[THE_MASK]

I think they said they had something up there sleeves about sleeping and time compression . The problem i had with sh4 time compression was that any time the TC drops you know that there is enemy there . Also why carnt TC drop when your hydrophone operator just faintly hears a sound .

[JScones]

My guess is they'll tie at least some element of TC to the requirement to take the Commander off to bed.

Would you like to sleep for 6 hours?
-Yes
-No
-Never mind

Fable II uses this approach and you use "sleep" to progress time as long as you like so to sync up to future events/tasks that you need to undertake.

With SH5 now a glorified RPG, it would seem reasonable to take a similar approach.

[Highbury]

Originally Posted by JScones

My guess is they'll tie at least some element of TC to the requirement to take the Commander off to bed.

Fable II uses this approach and you use "sleep" to progress time as long as you like so to sync up to future events/tasks that you need to undertake.

With SH5 now a glorified RPG, it would seem reasonable to take a similar approach.

It does seem plausible, but with Fable II time never runs at 1 = 1. You would have to have skewed time like that in SHV for it to work. Otherwise we would have a Capt. that sleeps alot, or 8+ hours of gameplay between time compressions.

Some sort of TC while the Capt. is awake will have to be implemented if we still have 1 = 1 time.... which I sure the hell hope we do!

[Frederf]

I think time compression deserves an in-depth review from a wide-angle academic eye when it comes to the Silent Hunter series. There are a lot of ways to selectively compress time between events and the method used in previous titles is only one of those methods.

Ideally the time compression method used should allow a U-boat sortie to be accomplished in a reasonable amount of time while not giving away information that shouldn't be available to the player, lessening the sensation of game time passing, removing normal judgment and control opportunities from the player, etc.

Along such lines I have thought of a system of "standing orders" and "alerts."

Example: Captain wishes to take periodic dives for hydrophone sweeps every two hours while on a surface patrol.

Problem: Manually controlling this activity requires tedious TC manipulation along with constant repetitive orders.

Solution: "Standing orders" can be programmed and commanded by the player-captain to have the crew do this repetitive action automatically. This allows the captain to run a high TC while still allowing his wishes to be carried out.

[Platapus]

Originally Posted by onelifecrisis

I'm guessing TC will work exactly as it did in 3 and 4.

I would hope it would work a lot better than TC in 3 &4. The current TC sucks. I lose more subs to TC than to DC.