[Fidd]

206. Thoughts on campaign mode time acceleration.

I've no idea what the current plans are for this, but I gather time-compression may come to pass in a similar fashion to how SH3 used to handle this. All time compression runs on the same basis, that you can accelerate time up until a period before something else happens. There are a number of events that could cause time acceleration to cease. After a conversation over the diesels with Hoagie on this topic, we established some possible principles which are I think worthwhile considering:

Events that should/could cause time compression to cease:
Aircraft in the area
Daily fuel tank needs to be refuelled from saddle tanks
Entering an area where within a period of time, a cvy can be heard on hydrophones
Entering an area where within a period of time, a cvy or other uboat may be seen
Receiving an encrypted message from BDU, containing updates on cvy position
Receiving a radio message from another boat to you
Receiving a radio message from another boat to all stations
A change in the weather, wind-speed, direction and sea-state.
Exhausting the battery to less than 2kah
Exhausting air to 70 kg/cm3
Coming within radar range of an escort or aircraft.
Proximity to land, or port.
Proximity to a mined area.
Arrival at a waypoint
Occurrence of a pre-set RL time. (eg the start of a routine play session)
Radar receiver (Naxos/Metox) going off.
The onset of dawn or dusk.
A particular pre-set Wolfpack time of day. (to avoid being presented with too many, or any, daylight attacks)

The first principle we think is important, is that there's a delay before whatever the cause of the time compression occurs, and the event arises. This would allow the captain to direct players to the bridge to watch, for example, for aircraft, rather than immediately knowing that aircraft are in visual range. This means that until the cause of a time compression cessation (TCC) there's uncertainty as to how to react. In other words because it could be any number of things, one of which is aircraft, immediately diving because of the immediate approach of aircraft is no longer beneficial. The TCC might be caused by a need to refill the daily tank, but then have an aircraft turn up 12 minutes later and CD when spotted. This would mean that merely because a TCC has occurred, you can neither infer, nor exclude, the arrival of a different or additional threats.

So by not having TCC occur at the instant something comes into range may help to improve game-play, as well as provide content in terms of determining WHY it is that a TCC has arisen, which may require a few minutes - 5-20? - to arise, or, may even arise because of more than 1 reason.

SH3 time compression would either reduce to 1:1, or, a multiplier according to the nature of the cause. I strongly advise that we do not emulate that, as it gives away too much about the cause of the TCC too quickly?

Consideration could be made, at a lobby level, to exclude some causes of TCC, and exclude some threats - eg aircraft, in order that current play styles - eg the Frost game - can be played as the usual 3 hour standalone game without being troubled by new threats - such as aircraft/mines/weather changes and so forth, so as not to alter the character of those games, should their players not wish to play the campaign game as such.

Thought should be given to "house-keeping tasks" that can provide content for ordinary crew - and captains, to lessen the incidence of prolonged periods of not much happening, and the character of a play session. Current examples of this are the general lack of "stuff to do" for the Dive Officer during parallel attacks, or the engine room crew when at a steady speed for prolonged periods. In other words, just because a TCC has occurred for one reason, does not mean, with a little imagination, that the bulk of the crew are idle for the interval in which TCC is occurring. It could be used for:

Recharging
Filling the daily tank
Loading torpedoes from underfloor stowage
Loading torpedoes from outside stowage (through the required loading hatch) to a tube or the internal under-floor stowage - thus creating a risk of being caught unable to dive if any aircraft arrives!
Navigation changes from BDU messages or those from another uboat(s).
Use of Enigma to encrypt/decrypt messages
Unloading/reloading torpedoes if space permits.
Keeping a visual watch/manning flak.


The aim of such tasks within the campaign game, being to offer the possibility of more varied gameplay, rather than the currently entirely predictable typical 3 hour game of 2 x parallel attacks, and 1 "inside" attack. In particular it should make discovering the convoy the effort of some period of time, possibly over more than 1 play session, involving much more content for the navigator and radio, whilst not precluding the current sorts of games. By not having the cause of a TCC being immediately obvious, it'll still require effort from the rest of the crew to cover the possibility of, for example an aircraft, or, a Hunter-killer group heaving over the horizon!

In effect, TCC's will allow the campaign game to be played on an ongoing basis, with periods of action or tasks to be done, without unGodly amounts of time being spent having your ears hammered by the noise of the diesels, or staring at un-moving gauges!

The next issue is how to handle a TCC when the players are unavailable to play, ie the boat is unmanned, but the cause of a TCC has arisen. The answer may be to have all games be paused at the close of play of a RLevening, with time-compression only being applied when those players launch their boat at the new play-start. As the convoy - and other items will have moved in relation to the position/course/speed etc the time-compression can THEN be applied. So all play sessions need to start at x1 time compression, to give time for the players to assess incoming or queued messages concerning cvy positions/headings/time of observation etc. Once they have adjusted their heading and other navigational or speed parameters, they can seek to compress time in transit until they catch up with the convoy's real time position.

Another wrinkle that will need to be addressed, is what happens if a boat were to submerge and/or stop ahead of the convoy, but so much RL time passes that the unmanned boat becomes detectable. To my mind, if an unmanned boat gets within a certain range of a cvy, it should be randomly placed astern, or the side of, said convoy at a range in order that it can persist within the gameworld but not be threatened, if that boat has long intervals between being manned - eg those who play once a RL week.

This also suggests that instead of having U96, 552, 307 etc, there will be the need, at campaign start, to assign a crew to a numbered u-boat, and then on a given play-session, players can elect to choose a uboat that their captain commenced, regardless of which boats the crew belong to. Only the captain would be tied to a specific boat. This might be necessary to allow different crews to form under a particular captain for a given play session as RL considerations and time-zones will not necessarily permit the same crew to play the same boat throughout the week.

There will also be a need for updates concerning a cvy's status at any given instant, so that as far as practicable, captains can avoid setting a long period of time compression, only to arrive near the convoy the following RL week, only to find the cvy has been entirely sunk already! This implies that may need to be more than 1 convoy being tracked within an area, so that captains can use time compression to approach the most pre-possessing cvy.

This is just the beginning of considering VERY complex game-mechanic, and I'm sure I've failed to consider some potential "gotchas" with time-compression, and how it bolts together with TCC and regular times of play etc. I'd really be interested to read comments from the devs, or players, who can foresee stuff I've missed or failed to address. I do not envy the devs making time compression work! How playable escorts fit into all this will also need to be addressed.