Сетевые игры

(Играем и обсуждаем игры)

Модератор: Buxyr

Аватара пользователя
Buxyr

Коммандо Активист Друг форума Кот Леопольд
Рейнджер
Сообщения: 451
Рег. Вс май 02, 2010 10:07 am
Награды: 4
Репутация: 429
Вклад в проект: 27
Откуда: --
Поблагодарили: 6 раз

Сетевые игры

Сообщение Buxyr » Пт июн 18, 2010 1:08 pm

РЕШЕНИЕ ПРОБЛЕМ ПРИ РЕАЛИЗАЦИИ
СЕГОДНЯ КАЖДАЯ УВАЖАЮЩАЯ СЕБЯ ИГРА ОБЯЗАНА ПОДДЕРЖИВАТЬ МУЛЬТИПЛЕЕР — РЕЖИМ, ПРЕДНАЗНАЧЕННЫЙ ДЛЯ НЕСКОЛЬКИХ ИГРОКОВ, СВЯЗАННЫХ ЛОКАЛЬНОЙ СЕТЬЮ, МОДЕМОМ ИЛИ ИНТЕРНЕТОМ. НА ПЕРВЫЙ ВЗГЛЯД, ПРОСТАЯ ОБЯЗАННОСТЬ, НО ПОПЫТКА ПРАКТИЧЕСКОЙ РЕАЛИЗАЦИИ ОТКРЫВАЕТ ЦЕЛЫЙ ВОРОХ ПРОБЛЕМ, КОТОРЫЕ ИНОГДА ТРЕБУЮТ НЕОБЫЧНЫХ РЕШЕНИЙ

Когда игровые миры соприкасаются
Прежде чем погружаться в тонкости межсетевого взаимодействия, вспомним старые игры. В пошаговых стратегиях участники обычно управляли игрой по очереди. В играх реального времени такой подход был уже неприемлем и приходилось делить одну клавиатуру на двоих (хорошо если под руку попадался джойстик).

Идея: чтобы организовать сетевую игру, достаточно загнать весь ввод-вывод в магистральный кабель, реализовав удаленный монитор и клавиатуру (джойстик/мышь). Получится точно так же, как и раньше, только намного круче. С клавиатурой все просто, но чтобы осуществить передачу видеоизображения в реальном времени, даже если применить компрессию, понадобится локальная сеть или, по меньшей мере, DSL.

Игра для двух игроков
Рассмотрим простейший случай — игру для двоих игроков. Один компьютер будет «ведомым», второй — «ведущим». Ведущий компьютер обсчитывает игровое пространство, управляет движением монстров (если они есть), обрабатывает столкновения и т.д. Для синхронизации игровых миров все события игрового пространства (перемещение объектов, взрывы мин, полеты торпед) передаются ведомому компьютеру, который отображает события на экране и отмечает их на своей карте. При этом неявно предполагается, что обе карты (ведомого и ведущего компьютеров) абсолютно идентичны. Если же в игровом пространстве присутствуют случайные элементы (например аптечки, расставленные в разных местах), они должны быть переданы ведомому компьютеру, что достаточно сделать всего один раз — перед началом игры. При желании можно даже передать всю карту целиком (нужно учитывать, что ведущий компьютер может использовать дополнительные или «самопальные» миссии, которых нет у ведомого). Ведомый компьютер, в свою очередь, управляет локальным игроком, отслеживая нажатия клавиш и отправляя эту информацию ведущему.

Из локальной сети в интернет
Кажется, что все просто и никаких граблей здесь нет. В локальной сети — может быть, но передача данных через интернет сопряжена с периодичными задержками. Если не предпринять дополнительных мер, монстры будут двигаться как припадочные. Как же быть? А что если передавать не сами перемещения, а их предполагаемый сценарий? Обычно движение монстров подчиняется набору шаблонов, и компьютеру достаточно передать что-то типа «Двигайся от меня и до обеда/упора», «Атакуй по сценарию D» или «Уклоняйся по сценарию A». Количество передаваемой информации резко сокращается, и для обеспечения синхронизации становится достаточно периодически (скажем раз в секунду) передавать «квитки», сигнализирующие о пересечении объектом некоторой клетки игрового поля. Очевидно, что такой протокол передачи устойчив даже к длительным задержкам, что немаловажно при работе на сильно загруженных каналах.

С игроками дела обстоят значительно сложнее. Допустим, два горячих мудреца стоят супротив друг друга и каждый пускает по торпеде. Если информация о перемещении одного из игроков хоть чуть-чуть запоздает, очень может случиться так, что с точки зрения ведомого компьютера торпеда пройдет мимо, а ведущий увидит, как противника разорвало в клочья. Первое, что приходит на ум, — осуществлять перемещение только после подтверждения. Игрок нажимает на стрелку, компьютер А (неважно, ведущий или ведомый) отправляет уведомление компьютеру B (первая стадия), компьютер B обновляет свое игровое пространство и посылает подтверждение компьютеру А (вторая стадия), компьютер А принимает его и перемещает игрока (третья стадия). Только в жизни... Игрок давит на клавишу, а фигурка на экране остается неподвижной (задержка передачи данных по сети). Что делает игрок? Давит на клавишу еще и еще! Если же случится задержка на третьей стадии, в игровых мирах вновь произойдет рассинхронизация и дело закончится лесом. Следовательно, возникает необходимость четвертой стадии, которая обеспечила бы дополнительный уровень подтверждений, но… Как же тогда все будет тормозить!

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

Зная направление и скорость движения игрока/монстра/торпеды, удаленный компьютер может с высокой степенью достоверности рассчитать, произойдет ли столкновение на данном временном участке. Даже самый прыткий игрок не может менять направление своего движения несколько раз в секунду, поэтому достаточно подтверждать лишь изменение направления. Конечно, если возникнет задержка в сети, фигурка на экране отреагирует на действие игрока не сразу, но, во всяком случае, она не будет тупо стоять, а продолжит движение. Если перевести в субъективное восприятие, в этом случае поведение компьютера покажется человеку более реалистичным.

Борьба с жульничеством
Еще одна серьезная проблема — читерство. Ведущий компьютер может мухлевать как угодно — код и данные игрового процесса находятся в полном ведении игрока. Что ему стоит, слегка повозившись с отладчиком, приобрести божественное здоровье или нескончаемые патроны? Некоторые программисты просто отмахиваются от этой проблемы, делая вид, что ее не существует: «Ты либо доверяешь ведущему компьютеру, либо нет».

На самом деле решение лежит на поверхности! Пусть ведомый и ведущий компьютеры периодически меняются ролями — на программном уровне реализуется достаточно просто и надежно защищает от взлома. Конечно, хакер может исправить свой экземпляр программы так, чтобы пули не кончались, но подобный трюк сработает только тогда, когда его компьютер станет ведущим. Даже такой «половинчатый хак» дает огромное преимущество в игре, однако оба игрока находятся в равных условиях и «хакерствовать» может каждый. Уже нет компьютера, владелец которого приравнивается к Богу...

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

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

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

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

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

Динамическое балансирование нагрузки
Выбираешь самый быстрый компьютер с мощным процессором (выбираешь, естественно, автоматически — по скорости передачи данных и времени отклика на ping), подключаешь к нему чуть-чуть менее быстрые компьютеры, которые будут нести на своих плечах еще менее быстрые и т.д. Теперь тормозные компьютеры оказываются задвинутыми в самый зад, а весь трафик ложится на плечи узлов, висящих на быстрых каналах. Эта схема не является заданной раз и навсегда, она может (и должна) динамически обновляться. Главное — выбрать протокол обмена так, чтобы равномерно распределить трафик на все узлы.

Чтобы игроки (их количество в этой схеме измеряется десятками) не толпились на крошечном пятачке, необходимо создать достаточно большое игровое пространство, которое не сможет обсчитать никакой отдельно взятый Pentium. Значит, потребуется распределенная система, нарезающая «объекты» игрового мира на куски и раскидывающая их по наименее загруженным машинам.

Использованная ранее схема «каждый компьютер обрабатывает своих монстров» уже не котируется, так как когда некоторый объект (монстр или игрок) попадет в поле зрения «чужого» объекта (монстра или другого игрока), для синхронизации игровых миров требуется задействовать механизм подтверждений, а эти тормоза вполне терпимы в случае трех-пяти игроков, но неприемлемы в мире, где их десятки. Допустим, ты модернизируешь протокол обмена и решил, что пусть каждый компьютер обрабатывает только тех монстров, которые находятся в его игровом пространстве (то есть если монстр уходит из «своего» игрового пространства, его обработка передается другому компьютеру). Все будет работать замечательно до тех пор, пока все монстры не соберутся в пространстве одного игрока, и тогда его компьютер конкретно ляжет, будучи не в состоянии обрабатывать эту армию в реальном времени. Так что без распределенной системы с автоматическим балансированием нагрузки никуда! К сожалению, подобные системы очень сложны в реализации и отладке, в общем случае они не оправдывают себя и оказывается выгоднее установить выделенный сервер.

Выделенный сервер
Выделенный сервер — фактически тот же самый ведущий компьютер, только без заморочек. В отличие от обыкновенного компьютера, сервер не отваливается внезапно, чем сразу же снимает целый комплекс проблем. Задача синхронизации в подобной централизованной структуре решается сама собой, поскольку клиент отображает на экране только то, что сказал ему сервер, а уж игровой мир сервера всегда поддерживается в синхронном состоянии с самим собой.

Есть и недостатки. Поддержка постоянно работающего сервера — удовольствие не из дешевых. Обычного хостинга за $8 в год с Perl, PHP и MySQL тут явно недостаточно. Потребуется прямой доступ к машине с возможностью выполнять двоичные файлы, написанные под XP (или что у тебя там), и очень мощный процессор, способный поддерживать огромный игровой мир в подвижном состоянии. Вопросы финансов.

Что самое неприятное, подобная «принудительная самосинхронизация» означает, что клиенты лишаются какой бы то ни было самостоятельности и вынуждены передавать все свои передвижения на сервер, ожидая подтверждения. Даже если игрок решил заняться онанизмом в тихом дальнем углу, он все равно будет двигаться рывками и слегка притормаживать!

Плюс игроки (живые люди, а не фигурки) находятся в полной зависимости от сервера, компании-разработчика и своего провайдера. Уже нельзя собраться в куче и поиграть по локалке. Нужно обязательно выходить в интернет или… устанавливать свой собственный сервер. Только как его установишь, если в открытом доступе его нет?

Очень остро встает и проблема читерства. Чем больше игроков, тем выше вероятность обмана. И хотя код, управляющий игровым пространством, находится на сервере, непосредственно залезть в который никак нельзя, хакеры могут повесить бот, то есть написать скрипт, управляющий движением игрока и с нечеловеческой меткостью и быстротой мочащий все, что попадается на глаза. Увы, защититься от этого никак нельзя! Единственное, что остается, — распознавать обманщиков по слишком большому количеству трупов, оставленных в единицу времени, и ставить им бан. Однако всегда найдется игрок, который поднимет вселенский визг, возмущаясь, «за что» его «так»?! Он же играл по всем правилам, а меткость и реакция, как известно — не порок.

В принципе, обработку игровых миров можно поручить и клиентам, а сервер будет только коммутировать потоки данных и распределять нагрузку по узлам. Короче говоря, приходим к той же самой самоорганизующейся системе, но только с центральным сервером, что снимает требование к вычислительной мощности сервера и отменяет принудительную синхронизацию, однако вызывает много путаницы с «отрубавшимися» клиентами, а серверу приходится постоянно перепроверять, был ли обработан данный блок игрового пространства. При огромном множестве клиентов это нереально, поэтому на практике часто используются гибридные схемы. Весь игровой мир хранится на сервере, но максимум перемещений обрабатывается локально: схватка двух игроков неизбежно происходит через сервер, а разборки игрока с монстром может обработать и сам клиент, доложив серверу конечный результат (кто кого порешил). Естественно, в этом случае со стороны клиента возможно наглое читерство...

От централизованного сервера не так уж и много пользы. Не стоит думать, что наличие сервера решит все проблемы. Проблем будет ненамного меньше, чем в самоорганизующейся распределенной системе, и это при всех недостатках, присущих серверу!

Разработка сетевых игр — захватывающее занятие, а сам игровой процесс отрывает хвост с головой — это тебе не с тупым компьютером сражаться, который только и умеет, что посылать монстров по прямой. Тут сталкивается живой интеллект реальных игроков, от которых можно ожидать любых хитростей и тактических маневров! Естественно, в процессе написания необходимо тестировать игру, то есть, проще говоря, играть в нее. По сети.

Некоторые спорят, обязательно ли закладывать сетевые возможности на самой ранней стадии разработки программы или можно добавить их позднее. Однозначного ответа никто не дает. С одной стороны, в правильно спроектированной программе мультиплеер можно добавить когда угодно и с минимальными переделками кода. Однако где ты видел правильно спроектированные программы? Так что чем раньше возьмешься за поддержку сети, тем лучше

TCP, UDP или IP?
КАКОЙ ПРОТОКОЛ ВЫБРАТЬ? ОЧЕНЬ МНОГИЕ РАЗРАБОТЧИКИ ВЫБИРАЮТ TCP, ПОТОМУ ЧТО ОН САМОСТОЯТЕЛЬНО ЗАБОТИТСЯ О ПОДДЕРЖКЕ НАДЕЖНОГО СОЕДИНЕНИЯ, ГАРАНТИРУЕТ ДОСТАВКУ ДАННЫХ И Т.Д. ВСЕ ЭТО ТАК, НО ВЫБОР TCP БУДЕТ-ТАКИ ФАТАЛЬНОЙ ОШИБКОЙ И КОЛОССАЛЬНЫМ ТЕХНИЧЕСКИМ ПРОСЧЕТОМ. ВСЕ ДЕЛО В ТОМ, ЧТО TCP ОРИЕНТИРОВАН НА ПОСТОЯННОЕ ПОДДЕРЖАНИЕ СОЕДИНЕНИЯ И НЕПРЕРЫВНУЮ ПЕРЕДАЧУ ДАННЫХ. С НИМ ТЕСНО СВЯЗАНО МЕРЗКОЕ ПОНЯТИЕ «МЕДЛЕННОГО СТАРТА» (ПОДРОБНОСТИ МОЖНО ПРОЧИТАТЬ В ЛЮБОЙ КНИЖКЕ ПО TCP/IP). КРОХОТНЫЕ ПАКЕТЫ ОТПРАВЛЯТЬ КРАЙНЕ НЕРЕНТАБЕЛЬНО, ПО РЯДУ ПРИЧИН ОНИ ДОХОДЯТ С БОЛЬШИМИ ЗАДЕРЖКАМИ, А ДЛЯ СИНХРОНИЗАЦИИ ИГРОВЫХ МИРОВ ЭТО БОЛЕЕ ЧЕМ АКТУАЛЬНО!

ПРОТОКОЛ UDP ДОСТАВЛЯЕТ ПАКЕТЫ НАМНОГО БЫСТРЕЕ, НО НЕ ГАРАНТИРУЕТ УСПЕШНОСТИ ДОСТАВКИ. МОЖНО И НУЖНО, КОНЕЧНО, ОРГАНИЗОВАТЬ СОБСТВЕННУЮ СЛУЖБУ ПОДТВЕРЖДЕНИЙ, ТОЛЬКО ЭТО НИЧЕГО НЕ МЕНЯЕТ. ТЫ ПОСЛАЛ ПАКЕТ, А В ОТВЕТ ВМЕСТО ПОДТВЕРЖДЕНИЯ — ТИШИНА. ПОВТОРИТЬ ПЕРЕДАЧУ ИЛИ ПОДОЖДАТЬ ЕЩЕ? А ЕСЛИ ЖДАТЬ, ТО СКОЛЬКО? А МОЖЕТ, СТОИТ ПРОДУБЛИРОВАТЬ ПОСЫЛКУ ПО TCP? УВЫ, ЧУДЕС НЕ БЫВАЕТ, И САМ TCP ДЕЙСТВУЕТ ТОЧНО ТАК ЖЕ, КАК И МЫ — ПОДТВЕРЖДАЕТ ПРИЕМКУ ИЛИ ПОВТОРЯЕТ ПЕРЕСЫЛКУ ПО ТАЙМ-АУТУ. ОДНАКО ЧАСТО «ШТОРМ» UDP-ПАКЕТОВ ВСЕ-ТАКИ ПРЕДПОЧТИТЕЛЬНЕЕ, В ТО ЖЕ ВРЕМЯ ОН ОСУЩЕСТВИМ ТОЛЬКО ЕСЛИ ПРОПУСКНАЯ СПОСОБНОСТЬ КАНАЛА С ЛИХВОЙ ПОКРЫВАЕТ ПОТРЕБНОСТИ В ТРАФИКЕ, ИНАЧЕ СЛУЧИТСЯ СПЛОШНОЙ ЗАТОР. ПЛЮС МОЖНО ВВЕСТИ БИТ СРОЧНОСТИ, НО БОЛЬШИНСТВО ПРОВАЙДЕРОВ НАГЛО ИГНОРИРУЕТ ЕГО, И ОН НЕ СИЛЬНО ВЛИЯЕТ НА СКОРОСТЬ ОБМЕНА ДАННЫХ.

TCP ПО РЯДУ ПАРАМЕТРОВ ВСЕ-ТАКИ УДОБНЕЕ UDP. МОЖНО ИСПОЛЬЗОВАТЬ ГИБРИДНУЮ СХЕМУ, ПЕРЕДАВАЯ ПО TCP НЕСРОЧНЫЕ ДАННЫЕ, А ПО UDP — КРИТИЧЕСКУЮ ИНФОРМАЦИЮ О ПЕРЕМЕЩЕНИЯХ ОБЪЕКТОВ (ТИПА ТОРПЕДЫ).

В НЕКОТОРЫХ СЛУЧАЯХ ПРОТОКОЛ UDP НЕДОСТУПЕН, И ТОГДА ПРИХОДИТСЯ РАБОТАТЬ ТОЛЬКО ПО TCP ,ЧТО НЕ СЛИШКОМ УСЛОЖНЯЕТ ПРОГРАММУ: ОСНОВНАЯ ИНФОРМАЦИЯ ВСЕ РАВНО ПЕРЕДАЕТСЯ ПО TCP, И ЕСЛИ UDP ОТСУТСТВУЕТ, ЭТО ВСЕГО ЛИШЬ ЗАМЕДЛИТ СИНХРОНИЗАЦИЮ И ВЫЗОВЕТ НЕКОТОРЫЕ ТОРМОЗА, НО ИГРОВОЙ МИР НЕ РУХНЕТ, А ПРОГРАММИСТУ НЕ ПРИДЕТСЯ НИЧЕГО ПЕРЕПИСЫВАТЬ.

ЕЩЕ МЕНЬШИМ ОВЕРХИДОМ ОБЛАДАЕТ ПРОТОКОЛ IP, КОТОРЫЙ ИМЕЕТ СМЫСЛ ИСПОЛЬЗОВАТЬ В ТЕХ ИГРОВЫХ МИРАХ, КОТОРЫЕ РАССЧИТАНЫ НА БОЛЬШУЮ ТОЛПУ ИГРОКОВ, В ПРОТИВНОМ СЛУЧАЕ ВЫИГРЫШ НЕ БУДЕТ СТОИТЬ ПРИЛОЖЕННЫХ УСИЛИЙ, ТЕМ БОЛЕЕ ЧТО ЧЕРЕЗ IP УДАЕТСЯ РАБОТАТЬ ДАЛЕКО НЕ ВСЕГДА.

HTTP рулез forever
ПРИ РАЗРАБОТКЕ СЕТЕВОЙ ИГРЫ СЛЕДУЕТ УЧИТЫВАТЬ, ЧТО ПРЯМОЙ ДОСТУП В ИНТЕРНЕТ ИМЕЕТСЯ ДАЛЕКО НЕ У ВСЕХ ПОЛЬЗОВАТЕЛЕЙ, А БРАНДМАУЭР И PROXY-СЕРВЕР — ВОВСЕ НЕ ПУСТЫЕ СЛОВА. ЗАЧЕМ ОТСЕКАТЬ ПОТЕНЦИАЛЬНЫХ КЛИЕНТОВ? НАУЧИ ПРОГРАММУ РАБОТАТЬ ПО HTTP И ПОДДЕРЖИВАТЬ ПРОКСИ — ПРЕДСТАВЛЯЕШЬ, СКОЛЬКО ЛЮДЕЙ СКАЖУТ ТЕБЕ СПАСИБО! ПРИ РАБОТЕ С ВЫДЕЛЕННЫМ ИГРОВЫМ СЕРВЕРОМ НИКАКИХ ПРОБЛЕМ НЕ ВОЗНИКАЕТ (КРОМЕ «МЕДЛЕННОЙ СИНХРОНИЗАЦИИ») — ТОЛЬКО ПОДДЕРЖИВАЕШЬ ПРОКСИ-ПРОТОКОЛ. РАДИ ПРИКОЛА МОЖНО ПРЕДУСМОТРЕТЬ СВЯЗЬ ПО ICMP. А ЧТО? ОЧЕНЬ ДАЖЕ НЕПЛОХОЙ СПОСОБ СВЯЗИ.

СИТУАЦИЯ ОСЛОЖНЯЕТСЯ, ЕСЛИ ОДИН ИЗ КЛИЕНТОВ СИДИТ ЗА БРАНДМАУЭРОМ ИЛИ ПРОКСИ, ДОПУСКАЮЩИМ ТОЛЬКО ИСХОДЯЩИЕ СОЕДИНЕНИЯ. ПОСКОЛЬКУ НА ЭТОМ НЕЗАВИДНОМ МЕСТЕ МОЖЕТ ОКАЗАТЬСЯ ЛЮБОЙ, ПРОГРАММА ДОЛЖНА ПРЕДУСМАТРИВАТЬ ДВА РЕЖИМА РАБОТЫ: 1) ПАССИВНЫЙ, В КОТОРОМ ОНА СЛУШАЕТ ПОРТ ОЖИДАНИЯ СОЕДИНЕНИЯ; 2) АКТИВНЫЙ, ПРИ КОТОРОМ ОНА САМА ЛОМИТСЯ НА УДАЛЕННЫЙ ПОРТ.

А ЕСЛИ ОБА ИГРОКА НАХОДЯТСЯ ЗА БРАНДМАУЭРОМ (ЕСТЕСТВЕННО, КАЖДЫЙ ЗА СВОИМ)? ПРОБИТЬ ТОННЕЛЬ ПРЯМОГО СОЕДИНЕНИЯ УЖЕ НЕ ПОЛУЧИТСЯ (РАЗВЕ ЧТО ЧЕРЕЗ ICMP ИЛИ NAT) И ПРИДЕТСЯ ПОДКЛЮЧАТЬСЯ К КОМУ-ТО ЕЩЕ. К ТОМУ, КТО НАХОДИТСЯ В ДИКОМ ИНТЕРНЕТЕ БЕЗО ВСЯКИХ ТАМ ПРОКСИ И БРАНДМАУЭРОВ. УСТАНАВЛИВАТЬ ЦЕНТРАЛИЗОВАННЫЙ СЕРВЕР СОВЕРШЕННО НЕОБЯЗАТЕЛЬНО! ДОСТАТОЧНО НАЙТИ ЕЩЕ ОДНОГО ИГРОКА И СОЕДИНИТЬСЯ ЧЕРЕЗ НЕГО. ЧЕМ ПОПУЛЯРНЕЕ БУДЕТ ИГРА, ТЕМ ПРОЩЕ ПОИСКИ...

Отзывы из форума


f1ex
Для меня любимой сетевой игрой остается Quake III. Дома постоянно играю с соседями в эту игру по локалке. Даже не могу оторваться от нее в свободное время — играю у себя на КПК, очень сильно привлекла динамика, геймплей... И, погрузившись в нее полностью, перестаешь обращать внимание на графику (сколько лет от создания прошло). А еще можно отыграться на друзьях!

McDaun
Doom 2 — сколько лет уже, а я все в него режусь.

CyberMind
StarCraft — стратегия всех времен и народов! Хотя выпущена она в далеком 98-м году, в нее и сейчас играет куча народа. StarCraft очень динамичен, и, на мой взгляд, до сих пор ни у кого еще не получилось его превзойти, хотя попыток создать похожую игру было огромное множество. В мультиплеер играть очень приятно и ненапряжно. Играю уже четыре года, и до сих пор он мне не надоедает! Наверное, из-за абсолютной непредсказуемости: сегодня я батя, завтра меня рвут.

Samid
Combats.ru! Особо часто в игры не играю, но если есть время, то только эта.

grokinn
ogame.ru — космическая стратегия, отличное соотношение экономики и файтинга, легка в освоении новичками онлайн-игр (кстати, для новичков там есть защита, на них нельзя нападать). Я, например, до этого никогда не играл во всякие Combats.ru (неинтересно было), а тут зацепило, уже несколько месяцев режусь. Кроме того, игра браузерная и без всякого flash, идет в реальном времени (игрок спит — ресурсы копятся). Особо много трафика не жрет, показывает небольшой рекламный баннер. В общем, меня прикололо.

Pupkin-Zade
Лучшая сетевая — BattleField 2. Оптимальное соотношение техники и людей, стратегии и тактики в современной войне. До этого был Join Operation, тоже неплохо. Ну и Counter-Strike на крайний случай.

gackt
Из стратегий — StarCraft. Это уже классика, в комментариях не нуждается. Из мморпг — Lineage2. Графика, геймплей, динамика (как для онлайновой игры) — все на высоте, особенно если играть на официальном сервере. WoW — тоже ничего, но художники прогнали, слишком детская получилась. Остальные фэнтезийные мморпг — просто жалкая попытка скопировать линейку :). А из тупых стрелялок — UT2004, графика хорошая :). Остальные не признаю вообще.

][eaL
Не знаю, почему, но мне никогда не нравились ролевые игры. Поэтому я предпочитаю всяким линейджам и WoW экшены типа КС (играл в нее два года, потом бросил), Бателфилд (взял вторую часть этой замечательной игры, попробую) и, естественно, третью Quake (в которую я играл по сети с самого момента ее выпуска, сейчас тоже надоело).

RUSSO_TURISTO
Почти полгода играл в отечественную мморпг «Сферу». Жестко затягивающая игрушка, как и любая онлайн. Но количество багов и недоработок настолько велико, что буквально видишь альтернативные пути развития персонажей и губится весь геймплей. На одном баге, дающем неограниченное количество игровых денег, некоторые игроки жили как на зарплате, обменивая потом игровые деньги на «ЯндексДеньги» другим игрокам, которые не юзают баги.

beloz
Wow одназначно рулит! Мне всегда нравилась серия WarCraft, а тут Blizard выпустил WoW. Я попробовал, и очень понравилось. Хотя графика в игре действительно какая-то детская немного... Играю сейчас только в нее, когда есть свободное время.

andrusha
А мне, кстати, в свое время нравилась игра крестики-нолики «пять в длину» :). Удобно было совмещать с работой, развивало мышление, плюс случайные знакомства с игроками, иногда действительно интересными..

questo
Рублюсь в wolfenstein enemy territory. Версия под *nix'ы была на каком-то DVD из «Хакера», тогда я на нее и подсел :).

ho@xer
Казаки! Первая часть и вторая. Просто помешан! С другом почти каждый день ночью сидим как ненормальные. Уже года два не переставая играю. Причем на компе нет других игр — одна эта!

KreezZiS
Любимые: WarCraft III TFT, QIII, CS. Но сейчас не играюсь, поднадоело это дело... А вообще некоторое время нравились «Казаки», StarCraft, UT2004, Heroyes M&M 4 и серия NFS.

SeRj
WarCraft III TFT. В отличие от стрелялок, можно поиграть по инету даже по модему, ибо в стартегиях пинг не так критичен как для Quake III или же КС. У этой игры весьма скромные системные требования, так что можно поиграть даже на слабеньких компах. В этой игре можно показывать неординарные тактики, именно поэтому она цепляет практически всех, кто хоть раз ее видел!

Sugar
А я последнее время завис в LineAge2 — вот это темная игрушка. Трафика почти не ест. Графика прекрасна. Рубил раньше в WoW, но слишком мультяшна. А линейка хороша. дистрибутив бесплатен, вход тоже. У меня там хорошая ботоармия :). Надо бы мобильное управление им сделать...


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


Искусство это жизнь

Аватара пользователя
margo17
Странник
Сообщения: 154
Рег. Ср ноя 26, 2014 12:16 pm
Репутация: 4
Поблагодарили: 4 раза

Сетевые игры

Сообщение margo17 » Чт фев 19, 2015 11:45 am

Я думаю, что каждый разработчик игр, в целях популяризации и привлечения к игре как можно большей целевой аудитории, просто обязан включить в разработку поддержание игры такие пункты как игра на двоих и более, сетевая игра и т.п.

Аватара пользователя
Роман Хромов
Скиталец
Сообщения: 118
Рег. Вт ноя 25, 2014 12:55 pm
Репутация: 0
Поблагодарили: 1 раз

Сетевые игры

Сообщение Роман Хромов » Пт фев 20, 2015 10:26 am

margo17 писал(а):Я думаю, что каждый разработчик игр, в целях популяризации и привлечения к игре как можно большей целевой аудитории, просто обязан включить в разработку поддержание игры такие пункты как игра на двоих и более, сетевая игра и т.п.

Согласен, если в самой игре есть пункты игра на двоих или сетевая игра, тогда понятное дело интерес к самой игре будет возрастать потому, что будет момент соревнования.

Аватара пользователя
Grigoriy-77
Скиталец
Сообщения: 125
Рег. Пт ноя 14, 2014 3:34 pm
Репутация: 1
Поблагодарили: 2 раза

Сетевые игры

Сообщение Grigoriy-77 » Сб фев 21, 2015 10:39 am

Играть вместе с друзьями всегда интересней. К тому же не один ИИ не сравнится с живым соперником. Главное чтобы сетевой режим был нормально сделан, без глюков и багов.

Аватара пользователя
sockiy80
Скиталец
Сообщения: 54
Рег. Пн май 11, 2015 7:52 am
Репутация: 0

Сетевые игры

Сообщение sockiy80 » Пт сен 04, 2015 6:02 pm

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

Аватара пользователя
Леонид_32
Пилигрим
Сообщения: 42
Рег. Пт май 01, 2015 6:12 pm
Репутация: 0

Сетевые игры

Сообщение Леонид_32 » Сб сен 05, 2015 4:39 am

Сегодняшний игровой мир трудно представить без сети и интернета. Если бы не развитие этого направления, то сомневаюсь в успешности и массовости игровой индустрии.
На пути к истине

Аватара пользователя
deniss
Скиталец
Сообщения: 93
Рег. Пт дек 19, 2014 11:52 am
Репутация: 0

Сетевые игры

Сообщение deniss » Чт окт 15, 2015 10:57 am

Играть по сетке или по интернету интересно, но есть такие случаи и такие игры, при которых и в которые лучше играть одному. Так меньше тролинга и хэчпека.

Аватара пользователя
vitalqqqq
Скиталец
Сообщения: 104
Рег. Вт ноя 25, 2014 5:04 pm
Репутация: 0

Сетевые игры

Сообщение vitalqqqq » Пт окт 16, 2015 10:11 am

Замечаю, что однопользовательские игры начинают пропадать с рынка и идет массовое наступление онлайн игр и это печально, не хочу играть с детьми, которые в первую минуту сливаются.

Аватара пользователя
avu
Странник
Сообщения: 171
Рег. Чт май 07, 2015 8:40 am
Репутация: 4
Поблагодарили: 3 раза

Сетевые игры

Сообщение avu » Сб окт 17, 2015 12:37 pm

Игры-онлайн - это настоящее и это ближайшее будущее. Тенденция бурного развития сетевых игр явно обозначилась, чего уже никак не избежать. Поэтому сегодня назрела та социальная ситуация, когда требуется резко усилить родительский контроль применительно к подросткам с неустойчивой психикой, которые "подсаживаются" на сетевые игрушки.

Аватара пользователя
-AnnA-
Пилигрим
Сообщения: 36
Рег. Пт май 08, 2015 8:33 am
Репутация: 0

Сетевые игры

Сообщение -AnnA- » Чт окт 22, 2015 9:27 pm

Конечно же, интерес к игре возрастает, когда есть реальный противник, с которым сражение приносит дополнительный адреналин и азарт, чего в обычных играх нет.


Вернуться в «Игромир»

 

 

cron