Ответ 1
Заполняя контекст из вашего предыдущего вопроса, я понимаю, что вы отправляете позиции весла и шара от каждого клиента к другому. Однако, пока клиенты согласны с тем, где весла находятся в каждый момент времени, движение шара полностью определяется (исключая ошибки округления), и вы должны экспериментировать с нулевым забиванием мяча. Каждый клиент должен сохранять собственное внутреннее состояние с положением и скоростью лопастей и мяча. Псевдокод будет похож на следующее:
// input thread
if input changed,
alter paddle speed and/or direction
send timestamped message to inform my opponent of paddle change
// incoming network thread
if paddle packet received
alter opponent paddle speed and/or direction at time it was sent
fix any errors in previously extrapolated paddle position <--- Easy
if ball-packet received
fix any errors in ball position and speed <--- Tricky
// update entities thread
for each entity (my paddle, opponent paddle, the ball)
compute updated entity position, adjusted by time-since-last-update
if ball reached my end, send ball-packet to other side
draw updated entity
Это предполагает, что обмениваются два типа пакетов:
- Пакеты paddle являются временными позициями + скоростями весла и отправляются всякий раз, когда клиент изменяет скорость своего собственного весла.
- шаровые пакеты представляют собой временные отметки + скорости мяча и отправляются всякий раз, когда мяч достигает клиентской (локальной) стороны, независимо от того, отскакивает ли она от весла или нет.
Псевдокод выполняет экстраполяцию ( "предполагайте, что все продолжает двигаться как обычно" ) для всех неизвестных в потоке объектов обновлений. Единственный момент, когда возникают проблемы, отмечен стрелками <---
.
Вы можете легко исправить положения весла, деформируя их на свое новое место, возможно, интерполируя движение за короткий период, чтобы сделать его менее резким.
Корректировка шаровых позиций легко, если оба клиента более или менее согласны (и затем вы можете снова выполнить интерполяционный трюк, чтобы сгладить его дальше). Тем не менее, один клиент может видеть близость, а другой - ближний удар. В этом случае, поскольку вы используете одноранговую модель, мы позволяем локальному клиенту совершать вызов и объяснять, что произошло с противником (в другом дизайне у вас будет центральный сервер, принимающий такие решения; это хорошо, чтобы избежать обмана). Вы не можете избежать уродливого прыжка там, если оба клиента не согласны - но, надеюсь, это должно быть относительно редко и коротко, если оно не совпадает с пингом пика.