Cheb's Home Page

Повернуться лицом к этой теме меня заставили печальные последствия попытки сыграть в Quake III через Интернет: благо, я теперь подключён по кабелю, и игольное ушко модемной линии навсегда отошло в прошлое... Нет, сама игра шла отлично, и меситься с живыми людьми вместо ботов было довольно увлекательно, но вот в конце месяца, после подсчёта трафика...
Я, конечно, подозревал, что поток информации довольно увесистый, но целых полсотни баксов за несколько дней невинного развлечения - это, извините, уже чересчур!

Клиент-клиент или клиент-сервер

    Как раньше работал мультиплеер (начиная с Дедушки Doom'а, и кончая Дюк Нюкемом)?..
    Все компьютеры, установив связь, одновременно загружали игровой уровень, ждали, пока загрузится самый медленный, и начинали сеанс одновременной игры, обмениваясь только информацией управления от игроков (типа нажатых клавиш, и дельта-смещения мыши). При этом ядро игры было построено на целочисленной арифметике, благодаря чему, при воздействии одинаковых команд управления телами игроков, игровой мир на всех машинах функционировал абсолютно идентично.
    Это и была архитектура клиент-клиент. Её огромным преимуществом перед современной клиент-серверной являлся многократно меньший поток информации через сеть: ведь, например, при наличии двух игроков передавалась информация только об одном объекте, а не как в современных играх: о втором игроке, толпе монстров, летящих снарядах, положении лифтов, и даже брызг крови...
    К сожалению, недостатки её были тоже очень существенными (оставим пока в стороне дискуссию о преимуществах арифметики с плавающей запятой): Во-первых, все игроки должны были одновременно входить на уровень, присоединиться к мочиловке в разгаре игры было невозможно.
Во-вторых, если передача потока команд каким-либо образом нарушалась, то компьютеры выходили из синхронизации, и игра на этом заканчивалась.
    В-третьих, игровой мир не мог продвинуться к следующему шагу состояния, не получив информацию управления от всех участников, и с увеличением числа оных, действие шло всё более дёргано и замедленно: ибо сетей без задержек не бывает.

Моё предложение: так вдохнём же в покойника новую жизнь!

Да... возвращаясь к тому, что писал в предисловии: пусть квакой балуются капиталисты (или те счастливцы, кто имеет много соседей-игрунов в одной локальной сети)
Мои же пламенные слова - для тех, кто хочет писать игры для обычных, не обременённых лишними деньгами и счастьем, людей.
Итак, с чего начнём?...
А). Будем строить ядро игры исключительно на целочисленной арифметике с фиксированной запятой - не слишком удобно, не слишком быстро, но да ведь физика всё равно занимает куда меньшую долю процессорных потуг, чем графика.
Б). Добавим поддержку доморощенных сетей типа трёх компьютеров, соединённых через COM-порты, из которых один связан с четвёртым и пятым по модему или через Интернет - ибо у нас на Руси и не такое бывает.
В). Вернёмся-таки к архитектуре клиент-клиент, но с существенными дополнениями (см. ниже). При этом ничто не помешает одному из компьютеров быть "сервером" - но только в том смысле, что он будет дирижировать всем процессом, а отнюдь не держать физику мира единолично и кормить клиентов с ложечки информацией о состоянии видимых данным игроком объектов, как делают современные серверы.

Как:

А). Добавим возможность работы с опережением - т. е., не получив очередную порцию информации об оппонентах, клиент не стоит. Он сначала запоминает состояние игрового мира, а затем просчитывает следующий шаг, исходя из предсказанных значений тех самых отсутствующих данных. Через несколько шагов, когда запоздавший пакет информации, всё же, приходит, клиент загружает сохранённое состояние игрового мира (всего!) и просчитывает все те же шаги заново "задним числом".
Результат?... Заметно растёт нагрузка на всех клиентов, если хотя бы у одного из них плохая связь (но это уже вопрос об эффективности вычислений физики мира), но катастрофически падает объём передаваемой информации, экономя деньги пользователя, или просто позволяя сыграть, наконец, по дерьмовой линии связи.
Какие минусы?.. Писать программу становится гораздо труднее.
Плюсы? (кроме экономии канала связи) - не очевидны, но, тем не менее, велики. Ибо этот метод позволяет использовать в игре объекты с очень сложными алгоритмами поведения, которые невозможно прогнозировать и интерполировать в традиционной схеме "клиент-сервер".
Б). Добавим возможность присоединяться в середине игры. Спросите - как?.. Нет ничего проще!
Допустим, к сети присоединился новый клиент. Псевдосервер даёт распоряжение клиенту, имеющему наилучшую (или наидешёвейшую) связь с новоприсоединившимся, передать тому полное состояние игрового мира на момент присоединения (т.е. обо всех объектах, начиная от игроков, и кончая летящими от монстров клочьями шкуры). Информация эта может быть довольно объёмистой, канал отвратным, и передача займёт, допустим, минуту. То есть, информация состояния окажется устаревшей вусмерть. Что дальше?..
А дальше, товарищи программисты, такой трюк: тот компьютер, что передаёт "новичку" состояние мира, одновременно с началом передачи начинает запоминать команды управления игроков в каждом шаге физического мира, и передаёт эту информацию во вторую очередь, сразу после "моментального снимка" мира. Новоприсоединившийся клиент, используя её, начинает "догонять" остальных, просчитывая шаги состояния непрерывным потоком. Сколько времени это займёт - зависит от резерва канала связи и быстроты конкретного компьютера.
Когда новый клиент "догонит" остальных, он сообщает псевдосерверу, что готов включиться в игру, и псевдосервер командует всем клиентам создать нового игрока.
Всё. Мы получили возможность присоединения к середине игры. Правда, не мгновенную, как в архитектуре клиент-сервер, но тут уж, как говорится, "бесплатного сыра не бывает". То есть, бывает, конечно, но сами знаете, где.

Народ! Товарищи!! Люди!!! Не ленитесь, критикуйте, отзывайтесь! Ибо в споре рождается истина...