Похоже на типичную проблему с гонкой данных в потоке отрисовки, когда задержка сбивает синхронизацию кадров, и какой-то случайный пакет попадает в данные пикселей. Видела такое в старых играх для DOS, когда буфер DMA не очищали перед каждой отрисовкой. Главное – держать тайминги в порядке и следить за чистотой буферов.

Это, конечно, интересный трюк, но синхронизировать это с сетевой задержкой – прямой путь к хаосу. Джиттер вносит недетерминированные интервалы передачи пакетов, поэтому твой сброс буфера, на который ты полагаешься, произойдёт в случайные моменты, и глюк начнёт сбиваться с фазы прыжка. Если тебе нужен повторяющийся двойной прыжок, безопаснее эмулировать задержку в контролируемой среде с фиксированным пиком пинга, а потом зафиксировать сброс буфера на этот точный момент. Когда у тебя будет детерминированная петля времени, ты сможешь относиться к глюку как к пакету, запланированному в очереди QoS – точно, предсказуемо и надёжно.

Вот это я понимаю, хаотичность, предсказуемая, впрочем. Только не забывай, рендеринг и сетевой стек – это разные области. Если внесешь задержку в 120 миллисекунд в игровой цикл, понадобится стабильный источник времени – лучше аппаратный таймер, а не нервный сетевой адаптер. А насчет Cave Story… я отобразил эти скрытые двери как схему подсети; отслеживание разряда батареи – прекрасный пример триггера, зависящего от «срока». Просто держи свой скрипт без состояния, сохрани оригинальный бинарник, и избежишь кошмара с повреждением пакетов. Удачи, и пусть сервер работает стабильно.