https://gitlab.synchro.net/main/sbbs/-/issues/1040#note_8051
One interesting question is how to do the delays... my initial thought was to have a set amount of time that each message will take, so if you set it to one hour, it wouldn't be processed by the other end until an hour has elapsed, so an attack packet followed by an attack result packet would take two hours.
Where this gets interesting is in the packet processing... with it running whenever someone logs into a door and when new packets are received, this means that attacking/spying on a system that doesn't have active players would take *much* longer since the packet would be initially ignored, then only processed during nightly maintenance... so it would take up to 25 hours when set to a one hour delay.
The more boring option is to have the entire delay applied to the result packet, which would effectively make the turnaround a fixed period.
A third option would be to have a "distance" component... where travel time to/from a village is based on some variable, the BBS ID perhaps (so villages are a fixed travel time from each other), or how much a village has been upgraded (representing better roads/infrastructure).
With the BBS ID style, it's likely desirable to have the villages "wrap around" so the highest BBS ID is one distance away from the lowest BBS ID... that means when a village is added, the distance between existing villages will change, but at least it prevents the first few BBSs from having an inherent advantage by being further away.
A final option would be an actual "real" map, and have travel time based on that... possibly with some kind of ability to build roads and such (that would increase production, but make it easier to attack a village). This is likely "too hard" for what I want to do right now though.
--- SBBSecho 3.34-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)