Создаем многопользовательскую браузерную игру. Часть первая. Клиент-серверная архитектура


Оглавление (нажмите, чтобы открыть):

Player.IO. Сетевые архитектуры

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

Под сетевой архитектурой подразумевается способ подключения и общения клиентов (компьютеров игроков) между собой в многопользовательских играх. Как правило, для игр используется два способа подключения это: Peer-To-Peer и Client-Server.

Peer-To-Peer архитектура

Под Peer-To-Peer (P2P) архитектурой подразумевается, что каждый из компьютеров подключается в общую сеть, и каждый компьютер имеет контроль над данными игры. Так же в такой архитектуре может присутствовать и сервер, но тут он используется только как посредник для передачи данных.

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

Давайте рассмотрим пример: два игрока играют в пошаговую игру, где каждый из них должен нападать на другого в свою очередь. Пусть первый игрок будет у нас хакером. Наступает ход первого игрока, он должен нанести некий произвольный урон второму игроку. То есть, на клиенте первого игрока вычисляется какой-то случайный урон, который отправляется второму игроку. Но поскольку это происходит локально, на машине хакера, то фактически он обладает этими данными и может подменить их. И, опа! Второй игрок получает 9999 урона и проигрывает. Хакер писается от счастья!

Первое, что приходит в голову — это проверить получаемые данные на их корректность, и как минимум, следует проверить выход значений за пределы допустимого диапазона, и в случае выхода — проигнорировать их. Но давайте представим, что настал ход второго игрока и он пытается атаковать хакера, который решил злоупотребить правилом проверки данных и настроил свой клиент таким образом, что теперь отвергает все атаки второго игрока. Хакер становится непобедимым и сокрушает всех своих врагов. И тут к нам приходит понимание того, что ни один клиент не должен нести отвественности за данные, иначе сложно быть уверенными в том, что данные достоверные.

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

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

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

Помните, в самом начале я писал о том, что вы можете использовать и Player.IO для создания многопользовательских игр с использованием подключения по P2P? Так вот, достаточно просто указать «Bounce» при подключении или создании игровой комнаты, и тогда все сообщения, отправляемые вами на сервер будут просто пересланы другим подключенным клиентам:

Двухуровневая система

Возвращаясь к вопросу безопасности, если мы не можем доверять нашим клиентам, то кому же мы можем тогда доверять? Конечно, серверу! Если у вас есть сервер, на котором принимаются все решения на основе данных от клиентов, то можно сказать, что вы отняли у хакеров основные возможности для самореализации. И это подводит нас к двухуровневой архитекутре, где сервер — это больше, чем просто почтальен. Он выполняет игровую логику и рассчитывает всю важную информацию. С таким подходом у нас получается уже две программы и код в двух местах. Давайте посмотрим, как это будет выглядеть:

Обратите внимание, только сервер и пользователь важны для правильной работы нашей игры, и это дает интересные последствия.

Наш клиент зажат между пользователем и сервером, на котором в действительности происходит игра, и пользователем, который активирует какие-либо действия. Клиент-же в данном случае используется только для одной цели: обеспечивает связь между игроком и сервером. То есть наша флеш игра не более, чем средство для получения и отправления информации на сервер.

Таким образом клиент имеет две задачи:

  1. Ввод данных: отправка необходимой информации на сервер, чтобы игра протекала так, как того желает игрок.
  2. Вывод данных: получение информации об игре с сервера, чтобы показать игроку, что происходит, и чтобы можно было продолжать играть.

Возможно вам показалось это сложным, но на самом деле все проще, чем кажется. Если смотреть с точки программы клиента, то нам фактически ничего не нужно делать ровно до тех пор, пока сервер не сообщит об этом. Иначе мы просто отправляем действия игрока на сервер, когда тот нажимает какие-либо кнопки.

Client-Server архитектура

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

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

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


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

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

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

Теперь давайте еще раз вернемся к примеру с шашками и рассмотрим его с использованием клиент-серверной архитектурой.

Игрок хочет выполнить ход от A2 до C4. Как и прежде он должен отправить следующее сообщение серверу, чтобы сообщить о своих действиях:

Отправить сообщение о ходе игрока — это все, что мы должны сделать. Больше ничего не нужно делать, пока не получим от сервера сообщение о том, что ход выполнен.

Получив сообщение от клиента на севере, мы убедились, что ход игрока допустим и соотвествует правилам игры, и только тогда осуществляем перемещение фишки, отправляя всем игрокам сообщение о выполненом ходе, в том числе и для игрока, который выполнил ход. Сообщение о выполненом ходе всем игрокам можно отправить такой строкой:

Возвращаясь к клиенту: мы получаем сообщение от сервера в котором говорится, что мы должны переместить фишку из клетки (1,2) в клетку (3,4). К счастью, команду сервера мы должны выполнить обязательно, и так же будет каждый раз, когда какой-либо другой игрок сделает свой ход.

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

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

Архитектура клиент – сервер

Архитектура клиент – сервер (client-server architecture) – это концепция информационной сети, в которой основная часть ее ресурсов сосредоточена в серверах, обслуживающих своих клиентов. Рассматриваемая архитектура определяет два типа компонентов: серверы и клиенты.

Сервер — это объект, предоставляющий сервис другим объектам сети по их запросам. Сервис – это процесс обслуживания клиентов.

Рисунок Архитектура клиент – сервер

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

Сервисная функция в архитектуре клиент – сервер описывается комплексом прикладных программ, в соответствии с которым выполняются разнообразные прикладные процессы.

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

Мастер Йода рекомендует:  Тонкая облачная инфраструктура для ранних стартапов

Рисунок Модель клиент-сервер

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

В сетях с выделенным файловым сервером на выделенном автономном ПК устанавливается серверная сетевая операционная система. Этот ПК становится сервером. Программное обеспечение (ПО), установленное на рабочей станции, позволяет ей обмениваться данными с сервером. Наиболее распространенные сетевые операционная системы:

— NetWare фирмы Novel;

— Windows NT фирмы Microsoft;

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


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

В современной клиент – серверной архитектуре выделяется четыре группы объектов: клиенты, серверы, данные и сетевые службы. Клиенты располагаются в системах на рабочих местах пользователей. Данные в основном хранятся в серверах. Сетевые службы являются совместно используемыми серверами и данными. Кроме того службы управляют процедурами обработки данных.

Сети клиент – серверной архитектуры имеют следующие преимущества:

— позволяют организовывать сети с большим количеством рабочих станций;

— обеспечивают централизованное управление учетными записями пользователей, безопасностью и доступом, что упрощает сетевое администрирование;

— эффективный доступ к сетевым ресурсам;

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

Наряду с преимуществами сети клиент – серверной архитектуры имеют и ряд недостатков:

— неисправность сервера может сделать сеть неработоспособной, как минимум потерю сетевых ресурсов;

— требуют квалифицированного персонала для администрирования;

— имеют более высокую стоимость сетей и сетевого оборудования.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Как то на паре, один преподаватель сказал, когда лекция заканчивалась — это был конец пары: «Что-то тут концом пахнет». 8370 — | 8002 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Какую клиент-серверную архитектуру лучше использовать для многопользовательской игры

Здравствуйте. Более-менее подучил C#, есть небольшой опыт написания приложений WinForms и WPF.
Сейчас появилась идея реализации сетевой многопользовательской игры. Собственно, сам вопрос — насчет архитектуры игры.
Логика игры продумана, необходимые классы почти дописал. Хочу написать сервер, собственно — все действия будут происходить на сервере. Планирую использовать протокол TCP/IP для связи сервера с клиентами. Но, тут наткнулся на трехзвенную архитектуру, подумал — почему бы не организовать некоторую БД игроков, их статистика, рейтинг и т.п.

Так вот, сам вопрос — какую клиент-серверную архитектуру лучше использовать для этих целей — двухзвенную (клиенты и сервер приложения + на сервере организовать хранение данных об игроках) или трехзвенную (клиенты, сервер приложения и сервер БД)?

А так же не нашел внятных примеров трехзвенной архитектуры в приложениях, если у кого-то найдется — буду очень благодарен

18.09.2014, 18:37

Какую технологию лучше использовать (DirectX или OpenGL) для создания модели Земли
Добрый день, уважаемые форумчане, возник такой вопрос, нужно сделать 3D-модель земли. Какую.

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

Какую БД лучше использовать на сервере
Опробовал различные методы из ЭТОЙ темы. Добавление записей работает (только если заполнять все.


какую БД лучше использовать
Здравствуйте! В связи с небольшим объемом знаний прошу помочь ответом на вопрос. Необходимо создать.

Создаем многопользовательскую браузерную игру. Часть первая. Клиент-серверная архитектура

Сам я склоняюсь к С++ по той причине, что скорость исполнения у него наиболее высокая, не используя библиотеки, зависящие от платформы можно добиться практически полной кроссплатформенности. Но в С++ надо будет начинать всё с нижнего уровня(определение сокетов и т.д.). И мне подкинули идею о неком PHP демоне, что это такое я не разобрался пока что.

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

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

О модели взаимодействия клиент-сервер простыми словами. Архитектура «клиент-сервер» с примерами

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику Сервера и протоколы. В этой записи мы поговорим о том, как работают приложения и сайты в сети Интернет, да и вообще в любой компьютерной сети. В основе работы приложения лежит так называемая модель взаимодействия клиент-сервер, которая позволяет разделять функционал и вычислительную нагрузку между клиентскими приложениями (заказчиками услуг) и серверными приложениями (поставщиками услуг).

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

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

Концепция взаимодействия клиент-сервер

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

Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).

Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. Протоколов на самом деле очень много и каждый протокол позволяет оказывать ту или иную услугу. Например, при помощи HTTP протокола браузер отправляет специальное HTTP сообщение, в котором указано какую информацию и в каком виде он хочет получить от сервера, сервер, получив такое сообщение, отсылает браузеру в ответ похожее по структуре сообщение (или несколько сообщений), в котором содержится нужная информация, обычно это HTML документ.

Сообщения, которые посылают клиенты получили названия HTTP запросы. Запросы имеют специальные методы, которые говорят серверу о том, как обрабатывать сообщение. А сообщения, которые посылает сервер получили название HTTP ответы, они содержат помимо полезной информации еще и специальные коды состояния, которые позволяют браузеру узнать то, как сервер понял его запрос.

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

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

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

Простая схема взаимодействия клиент-сервер

Мы видим, что к одному серверу может обращаться сразу несколько клиентов (действительно, на одном сайте может находиться несколько посетителей). Также стоит заметить, что количество клиентов, которые могут одновременно взаимодействовать с сервером зависит от мощности сервера и от того, что хочет получить клиент от сервера.

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

Почему веб-мастеру нужно понимать модель взаимодействия клиент-сервер

Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?». Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.

Мы уже упоминали, что большая часть сетевых протоколов имеют архитектуру клиент-сервер. Например, веб-мастеру или веб-разработчику будут интересны протоколы седьмого и шестого уровня эталонной модели. Сетевым администраторам важно понимать, как происходит взаимодействие на уровнях с пятого по второй. Для инженеров связи наибольший интерес представляют протоколы с четвертого по первый уровень модели OSI.


Поэтому если вы действительно хотите быть профессионалом в сфере web, то сперва вам необходимо понимать, как происходит взаимодействии в сети (именно на седьмом уровне), а уже потом начинать изучать инструменты, которые позволят создавать сайты.

Архитектура «клиент-сервер»

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

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

Мастер Йода рекомендует:  Установка и регистрация в Skype быть на связи легко!

Двухуровневая модель взаимодействия клиент-сервер

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер). Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.

Многоуровневая архитектура взаимодействия клиент-сервер

Типичный пример трехуровневой модели клиент-сервер. Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных.

Если мы посмотрим на данную архитектуру с позиции сайта. То первый уровень можно считать браузером, с помощью которого посетитель заходит на сайт, второй уровень – это связка Apache + PHP, а третий уровень – это база данных. Если уж говорить совсем просто, то PHP больше ничего и не делает, кроме как, гоняет строки и базы данных на экран и обратно в базу данных.

Преимущества и недостатки архитектуры клиент-сервер

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

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

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

Какие архитектурные подходы выбрать для разработки клиент-серверной игры?

Доброго времени суток. Пытаюсь немного разобраться в реализации клиент-серверной архитектуры и возникло непонимание некоторых базовых вещей, хотелось бы спросить мнение более опытных разработчиков. Вылезать из хоть сколько-нибудь привычной колеи у меня получается с трудом, плохо представляю с чего начать.

Игровая модель
Близка к играм вроде Elite/Space Rangers/X. Есть условный двухмерный космос, в нем существуют и взаимодействуют объекты (звезды, планеты, корабли и т.д.). Реалтайм, но «медленный», по типу стратегий от Paradox.

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

Что пытаюсь получить

  1. На хосте крутится сервер, вероятно обычное самописное C# приложение. Сервер авторитарный, все игровое состояние находится и симулируется на нем.
  2. Подключенные Unity клиенты получают от сервера только доступную им (видимую сенсорами кораблей игрока, например) информацию об игровом мире и отрисовывают ее.

Для начала хочу сделать простое получение с сервера простейшего игрового мира (звезды/планеты) и их отрисовку клиентом.

Собственно, вопросы:

  1. Эксперементировал с реализацией похожей механики в однопользовательском варианте, там все было довольно просто:
    • Любой сохраняемой сущности сопоставлен сериализуемый в JSON DTO (простое хранилище данных), включая корень игрового мира.
    • Эти сущности могут создать свой DTO из своих данных (и из вложенных в них сущностей), или восстановиться из него. Т.е. DTO является универсальным способом создания чего-либо или его сохранения/восстановления.
    • Сохранение/загрузка мира — просто создание/восстановление некоего WorldContext.

    Это неплохо работает, мир относительно легко сохранить/восстановить, но только одним куском.
    Если я правильно понимаю, для серверных приложений этот метод не используют, т.к. данные могут быть легко потеряны при сбое, а периодическое сохранение мира одним куском может вызвать зависания. Т.е. держать весь мир в RAM и периодически скидывать его в json будет плохим решением.


Прочитав статьи от mail.ru на эту тему, так и не осознал, что хранится в БД, а что — в RAM, и как это применить к моему случаю, как состояние игры «размазывается» между состоянием в памяти и базой данных. Например, если состояние структуры корабля сохранено в базе, должно ли оно существовать как объект в памяти или при необходимости доступа к нему оно читается из базы? Или обычно пишут какие-нибудь автоматические системы кеширования/сброса в БД?

Большая часть из этого, конечно, неактуальна для меня, но будет ли оправданным решением изначально делать всю симуляцию полностью в RAM и поддерживать БД в актуальном состоянии по ходу игры (т.е. постоянно записывать изменения, но не читать), а при необходимости потом организовать выгрузку из памяти тех или иных больших коллекций объектов? Или я вообще не в том направлении думаю?


Как, собственно, производить синхронизацию клиента и сервера? Даже простой мир на начальных стадиях разработки довольно быстро становится объемным по количеству разнородных сущностей/данных в них, особенно с появлением сложных объектов вроде кораблей, в то время как в туторах по какому-нибудь UNet обычно руками синхронизируют позицию игрока и пару параметров и на этом останавливаются. У меня получалось что-то наподобие вот такого save.json.

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

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

Насколько это плохая идея? Ведь в какой-нибудь EVE Online вряд ли возможно запускать симуляцию на клиенте, что в таком случае может приходить клиенту там?


На данный момент я не хочу использовать photon/аналоги и планирую ограничиться разве что какими-нибудь открытыми библиотеками. Насколько много я теряю от такого подхода и какие сетевые библиотеки могут быть полезны? Читал о вещах вроде SignalR, например. И может ли что-нибудь дать использование ASP.NET (возможно core) в качестве основы, или для таких целей его использование бессмысленно?

Понимаю, что на подобные вопросы нет и не может быть однозначного ответа, но был бы рад узнать по крайней мере степень глупости описанных мною решений. Искал информацию в тех же dev блогах EVE, но у них в основном про более «взрослые» вещи пишут. В каком направлении вы бы стали реализовывать описанную модель игры? Было бы интересно услышать.

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

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

Мне будет легко создавать файлы perl/php на сервере, которые контакты java/flash связывают, чтобы обновить позицию/действия игрока и т.д. Но я рассматриваю вопрос о том, должен ли я получить выделенный веб-узел, какую ОС использовать, какую базу данных и т.д. Кроме того, необходимо учитывать количество используемой полосы пропускания и масштабируемость.

Другим вариантом может быть использование облачной системы хостинга (в отличие от выделенного сервера), поэтому они позаботятся о добавлении дополнительных машин по мере роста игры. До тех пор, пока каждый сервер запускает основные файлы perl/php для обновления базы данных, он должен работать нормально.

Еще одним вариантом может быть использование механизма приложений Google.

Любые мысли о архитектуре сервера, выборе OS/базы данных и мой метод использования скриптов perl/php/python для программирования на стороне сервера является хорошим, будет оценен!

Вам нужно разъяснить больше об игре и больше думать об архитектуре, а не о конкретных деталях реализации.

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

Я настоятельно рекомендую заранее выяснить, будут ли размещены все игроки в одной игре на одном сервере (например, 1000 из 4 игроков по сравнению с 4 матчами по 1000 игроков в каждой). Если возможно, пойдите с первым и придерживайте всех, кто находится в одной игре под одним и тем же сервером. У вас будет достаточно сложное время для синхронизации нескольких клиентов с одним сервером, а не с несколькими серверами, против которых синхронизируются игроки. В противном случае определение последовательности является проблематичным.

По возможности, каждый клиент связывается с сервером, а затем сервер распределяет обновления клиентам. Таким образом, у вас есть одно «официальное состояние», и вы можете выполнять различные разрешения конфликтов, фантомы и т.д. Peer to peer дает лучшую производительность в более быстрых играх (например, FPS), но вводит массу проблем.

Я не могу для жизни меня видеть какую-либо убедительную причину, чтобы сделать это, и perl или PHP. Ваша игра не основана на Интернете, зачем писать ее на веб-ориентированном языке? Используйте хороший старый J2EE для сервера и обменивайтесь данными со своими клиентами через XML и AJAX. Если возможно, запустите реальное приложение Java на клиентах, а не на сервлетах. После этого вы можете использовать JMS, который отнимает у вас огромную нагрузку, абстрагируя много деталей связи для вас.

Как реализовать многопользовательскую браузерную игру?

В частности, как реализовать многопользовательскую часть? Я тренировался с помощью шашек, чтобы использовать свои мышцы JS/PHP/AJAX, и он отлично работает для одного человека (или двух человек на одном компьютере). Но я немного запугана, когда дело доходит до того, что он работает между двумя людьми на двух разных компьютерах. У меня есть часть AJAX, и сервер принимает/отправляет ходы из/в браузер. Я просто не могу окунуться в то, что мне нужно сделать, чтобы включить второго игрока.


Нужен ли мне MySQL для чего-то простого? Могу ли я использовать некоторую комбинацию идентификаторов сеансов игроков, чтобы просто передавать ходы вперед и назад, а не хранить какую-либо информацию на стороне сервера? Как сеанс игры даже начинается между этими двумя независимыми объектами?

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

Изменить . Чтобы уточнить, определенно есть сервер (следовательно, ссылки на PHP/AJAX). Для меня это очевидно. «Перемещение», очевидно, потребует поездки от игрока A к серверу, а затем к игроку B. Это то, как я рисую пробел. Сказав это, как представляется, некоторые хорошие ответы ниже, и я буду исследовать каждую из них по очереди. Но не стесняйтесь добавлять возможные предложения/решения, поскольку я уже многому научился только из фундаментальных исследований в уже опубликованные ответы.

Клиент-серверная архитектура казуальных сетевых игр

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

Очевидно, что в онлайн-играх, помимо игрока, участвует ещё сервер. Сервер это такая шайтан-машинка, для настройки которой нужны деньги и квалифицированные специалисты, именно серверу мы будем доверять обработку игрового процесса. Игроку с сервером нужно как то обмениваться данными, давайте поговорим об этом.

Рассмотрим протокол P2P. Под Peer-To-Peer (P2P) архитектурой подразумевается, что каждый из компьютеров подключается к общей сети, и каждый компьютер имеет контроль над данными игры. Другими словами, P2P это полное отсутствие безопасности. Здесь возможна и подмена данных, и несогласованность между двумя пирами. Конечно, P2P не является мракобесьем, и эта технология имеет место быть в некоторых случаях, например для игры в крестики-нолики без сервера, но по факту, P2P годится только для игр с небольшой продолжительностью игровой сессии и небольшим количеством одновременно играющих игроков в одной сессии. Сразу сделаю поправку, что на территории РФ и постсоветского пространства у очень большого количества геймеров установлены всякие MonsterDebugger и прочие читерские программы для извлечения и подмены данных, и разработчику приходится организовывать дополнительные методы защиты. Но защитить то, что находится на компьютере пользователя, очень сложно. Как же быть?

Просто! Всю работу с компьютера игрока мы сбросим на сервер, именно он будет обрабатывать действия игроков и просто рассылать результаты своей работы, это и называется клиент-серверной архитектурой.

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

Но в таком случае появляется пинг. Пинг это время, которое тратит сообщение на путь от клиента к серверу и обратно. И по честному исправить ситуацию невозможно. Как результат, задержка добавляет игре дёрганности и прочих лагов. В быстрых играх, если игрок за 900мс пробежит 5 метров, то при лаге в 900мс игрок телепортируется на 5 метров. То же касается и эффектов. Если игрок наступил на мину и успел отбежать назад, но при лаге пинга эта информация не успеет обновиться, игрок будет отброшен взрывной волной совершенно не в ту сторону, в которую он рассчитывал. Думаю, проблема ясна. При этом latency 100мс это вполне ок и это могут заметить только профессиональные игроки, не казуальщики.

Решить проблему постановкой задачи программисту не получится, от пинга избавиться невозможно. Но можно создать иллюзию отсутствия таких задержек. Если игрок имеет хороший пинг, менее 20 мс, то игрока вполне можно обманывать. А именно, восстановить то, что должно быть на экране у второго игрока. Попросту угадать действия игрока, и использовать интерполяцию для сглаживания анимации. Есть много способов интерполяции, начиная с обычной линейной (плавное перемещение игрока из места, где он находится в место, где он должен быть), заканчивая интерполяций на основе кубических сплайнов, но всё это полумеры, так как время, которое тратится на передвижение игрока к нужной позиции, способно ввести в заблуждение других игроков. А ведь все проблемы, связанные с задержками, вызваны взаимодействием игроков друг с другом. На сервере есть самая актуальная информация и действии игроков, и пока сервер не скажем игровым клиентам об этих действиях, эти действия не произойдут. А предугадывание действия оставим для полёта взрывчатого снаряда, предугадывание годится только для вещей с линейным движением.

Будем ориентироваться исключительно на сервер, получать информацию о действиях игрока только с сервера, пока сервер не скажет — ничего не меняется. Но игрок будет точно недоволен несвоевременной реакцией игрового персонажа на нажатие клавиш. Игрок банально теряет контроль над своим героем. Что делать? Брать и физически насиловать дизайнеров и аниматоров, разумеется >: ). Пусть анимация содержит задержки, вроде торможения персонажа после бега, приседание перед прыжком, поворот оружия перед выстрелом, это позволит скрыть несовершенства клиент-серверной архитектуры. И, как очевидно, имеет смысл сделать игру чуть медленнее, чем мечтает арт-директор, это тоже поможет дать запас времени для обмена данными с сервером.

Из оптимизации есть кое что ещё: многопользовательские игры масштабируются по функции О(n^2), где n = 128, это игроки. Один из игроков сделал ход, соответственно, всем игрокам надо об этом сообщить, и для каждого игрока придётся создать подключение. Количество передаваемой информации, как вы видите, очень высоко, нагрузка на сеть растёт. Но ведь один игрок не может видеть сразу всех 128 игроков, ни при каких обстоятельствах. Тогда количество соединений можно оптимизировать. Если из этих 128 игроков половина в нашей команде, то количество информации об их действиях также можно оптимизировать. Ведь не факт, что они способны нанести нам урон или даже врезаться в нас по идеологии игры.

Вы уже знаете, что интерполяция с линейным сглаживанием весьма неоднозначное решение, и назвать хорошим его нельзя, а вот упомянутая интерполяция с использованием кубических сплайнов выглядит более интересно. Из школьного курса математики все помнят, что линейная функция может быть представлена уравнением с переменной первой степени, например x = 5*y. В кубической функции как минимум один член возводится в степень, x = 5*y ^2. Подробнее здесь.

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

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

Клиент-серверная архитектура: особенности взаимодействия

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

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

  • функции ввода и представления данных предназначены для взаимодействия пользователя с системой;
  • прикладные функции — для каждой предметной области имеется собственный набор;
  • функции управления ресурсами предназначены для управления файловой системой, различными базами данных и прочими компонентами.

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

Клиент-серверная архитектура наиболее часто используется для создания корпоративных баз данных, в которых информация не только хранится, но и периодически поддается обработке различными методами. Именно база данных является главным элементом любой корпоративной информационной системы, а на сервере располагается ядро этой базы. Так, на сервере происходят наиболее сложные операции, касающиеся ввода, хранения, обработки и модификации данных. Когда пользователь (клиент) обращается к базе данных (серверу), происходит обработка запроса: непосредственно обращение к базе данных и возврат ответа (результата обработки). Результат обработки – это сообщение сети об успешном проведении операции или ошибке. Серверные компьютеры могут обрабатывать одновременно обращение нескольких клиентов к одному и тому же файлу. Такая работа и передача данных по сети позволяет ускорить работу используемых приложений.

Данная архитектура используется для доступа к различным ресурсам с использованием сетевых технологий: Web-серверы, серверы приложений, серверы баз данных, почтовые серверы, файрволы, прокси-серверы. Разработка клиент-серверных приложений позволяет повысить безопасность, надежность и производительность используемых приложений и сети в целом. Наиболее часто клиент-серверные приложения используются для автоматизации бизнеса.

Мастер Йода рекомендует:  Самый милый пост в истории Tproger жизнь программиста в гифках с котиками
Добавить комментарий