1. Случайних данных не потребуется. Скорострельность и координаты пушек известны. ramdom seed тоже синхронизован. Так что, зная момент начала и окончания стрельбы можно однознчно восстановить очередь. Все-таки я зашлю этот драфт.
2. А без рывков сделать и не получится. Если, конечно клиент не будет ждать от сервера подтверждения, что его руль направления, таки, повернулся.

Собственно, драфт.
1. Все объекты, все расчеты дублируются на сервере (С) и всех клиентах (К).
Траффик- важнее.
2. На С (и на К) подаются все события (поворот элеронов, стрельба) в виде:
{событие, время события}. События объединяются в пакеты, так чтобы событие
1, наступившее в момент Т1 пришло раньше события 2, наступившего в момент Т2 тогда и только тогда, когда Т1 меньше (предшествует) Т2. Предполагаем, что способ формирования пакетов событий- оптимальный (максимум информации/минимальный
размер).
3. Некоторые события инициируются (генерииуются) на сервере, некоторые-
на клиенте, в зависимости от области ответственности. Клиент генерирует
события касающиеся поведения собственного крафта и отданных под его
ответственность ИИ объектов (для прикола, каждому клиенту можно дать "под
опеку" несколько зениток, чтобы разгрузить сервер).
4. Область ответственности С- это ИИ обьекты и критические события (появление/
удаление объектов и коллизии). А такжа рассылка полученных от К событий
другим К.
5. Как только К или С получает событие (или сам генерирует его), он
производит соответствующие модификации в своем пространстве.
6. Т.к. события приходят с запозданием, К и С приходится делать грубые правки
в своем пространстве объектов (например, когда К узнает, что такой-то крафт
выравнял элероны Хмс назад, и перестал делать бочку он перерассчитывает
положение этого крафта и крафт рывоком прыгает в это положение). Но, т.к.
пилот имеет право менять только вторую производную, то очень уж резких
рывков не должно быть. Для сглаживания этих скачков К может применять
интерполяцию или даже экстраполяцию с учетом пинга, но можно позволять
клиенту выбирать самому: хочет ли он видеть рывки или предпочитает видеть
почти всегда недостоверную информацию .
7. Тот факт, что К1 прекратил огонь, К2 узнает тоже с запазданием в Хмс. Он
может убрать лишние снаряды, которые успел наплодить за эти Хмс, а может и
не убирать, чтобы они не исчезали "неожиданно". Ничего страшного, кроме
лишних нервов у жертвы (К2) это не вызовет, т.к. повреждения все равно
будут рассчитаны согласно только подтверженным сервером попаданиям.
8. Все коллизии рассчитываются сервером с запаздыванием, по времени последнего
пакета от участников. Например:
Сервер обработал все события вплоть до момента Т0.
В момент времени Т(на С) (Т больше Т0) К1(стрелок) сообщает, что в момент времени
Т1 (Т больше Т1 больше Т0) он прекратил стрельбу. Таким образом, С вычислит, сколько
снарядов (какой именно и когда) было выпущено крафтом К1 в промежутке
(Т0;Т1), как и положение крафта К1 на интервале (Т0;Т1).
К2 (жертва) в момент Т2 (Т2 больше Т1 больше Т0) присылает на сервер некое событие (хоть
idle - пустое). Следовательно, С знает (может рассчитать) достоверно
положение крафта К2 в любой момент времени на интервале (Т0;Т2).
Теперь С может просчитать коллизии для крафта К2 произошедшие в промежутке
(Т0;Т1), как и для крафта К1, произошедшие в том же промежутке.
Если других крафтов нет, то теперь просчитаны все события вплоть до Т1.
Для полученных коллизий, С рассчитывает дэмэдж и рассылает события всем К.
9. Т.к. клиенты могут рассчитать коллизии самостоятельно, то они могут и сами
нарисовать взрыв, который будет не более чем субъективной индикацией
попадания.