сетевые игры

КРИС КАСПЕРСКИ АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #064, стр. 064-062-3

Три и более игроков

Играть вдвоем довольно скучно, в какой-то момент возникает желание привлечь третьего. А где трое, там и пятеро. И тут всплывают свои проблемы... Ведущий компьютер может обслуживать множество ведомых игроков, количество которых (в теории) ограничивается пропускной способностью канала и мощностью процессора. Найти мощный процессор — не проблема. Если учесть то, что передаются не сами перемещения, а изменения направления, с лихвой хватит и хлипкого модемного канала. Камень преткновения в другом: что произойдет, если ведущий компьютер внезапно отвалится (разорвется соединение или владелец просто устанет и пойдет спать). В ситуации с двумя игроками никакой проблемы не возникнет, так как если один из игроков «исчезает», другой автоматически переходит в режим одиночной игры. С тремя игроками такая стратегия уже не срабатывает, и получается, что один отдувается за всех! А оно ему надо?

Кто-то наверняка предложит установить выделенный сервер, но тогда тройка-пятерка игроков натолкнется на решение, требующее расточительства. Так пусть все игроки устанавливают соединение не только с ведущим компьютером, но и друг с другом! Пусть по очереди становятся то ведомыми, то ведущими. В результате, если ведущий компьютер исчезнет, он просто-напросто будет выброшен из очереди и ничего катастрофического не произойдет.

Как вариант, можно совсем отказаться от концепции «ведомого» и «ведущего». Каждый компьютер управляет движением «своего» игрока и «своих» монстров, рассылая информацию о перемещении всем остальным. Такая схема существенно упрощает проектирование и реализацию игры, снимая множество проблем.

Самоорганизующиеся системы с большим количеством игроков

Описанная схема для трех-пяти игроков имеет два серьезных недостатка. Если игроков очень много, объем трафика увеличивается настолько, что перестает вмещаться в любые каналы и появляются дикие тормоза, особенно в тот момент, когда игроки сходятся в смертельном поединке. Правило «семеро одного не ждут» тут не срабатывает и динамика игры определяется самым медленным компьютером в сети — все остальные терпеливо ждут, пока придет подтверждение. Приходится усложнять протокол и запрашивать подтверждение только у того, «против кого дружим». Допустим, игрок А пускает в игрока Б торпеду, а игрок С за этим внимательно наблюдает — интересно же :). Так вот чтобы не допустить рассинхронизации, компьютеры А и Б вынуждены обмениваться подтверждениями, в то время как компьютер С может и отдохнуть.

Проблема множественности соединений снимается, если создан своеобразный «поезд». Вместо того чтобы рассылать данные всем узлам, компьютер А посылает их компьютеру B. «В» посылает их (вместе со своими перемещениями) компьютеру С и т.д. Естественно, чтобы восстановить цепочку в случае «падения» одного из узлов, компьютер А должен знать адреса компьютеров С и D, чтобы при необходимости установить соединение с ними. На самом деле структура сети не обязательно должна быть линейной (это худший вариант). Наиболее типичный случай из жизни: компьютеры А и C находятся в локальной сети, а компьютер B — где-то далеко в интернете. За каким чертом мы будем гонять трафик через B, когда логичнее соединить компьютеры так: B=> A=> C? Сделать «так» действительно возможно!