... probably the first. Don't think golems are strong enough it's going to really break anything.
Second would be more ideal from a least-impact point of view, though, definitely.
Yeah, I've just about talked myself into going with the second option. (Turns out it's actually easier, even; the first option would require me to arrange to recompute the golem's global speed every time the player's global speed changed.)
Maybe do that, and then add some kind of check where if the golem isn't within a certain radius (keyed to the golem's leash distance?) of the player for more than a few turns, it teleports the golem to you? Kinda' like thought forms.
I dunno, the goal here isn't really to actually prevent the golem from getting too far away from the player; it's just to keep their speeds matched up, so that the golem doesn't get left behind when auto-exploring or running down a long corridor. There's always Invoke Golem for emergencies.
Just nix the effect if enemies are visible, extend the yank-back effect timer if the golem's been controlled recently, tried to attack something, stuff like that, so the effect wouldn't be screwing with golem micromanagement. Would think that would catch most edge cases without too much extra trouble.(scratches head)
…well, I suppose from a non
-coding perspective, that could be viewed as "least-impact".