[prg] механизм взаимодействия участников групповых интернет-игр?
Здравствуйте, уважаемые!
Видел и слышал несколько примеров функционирования игр через интернет, в которых
принимает участие несколько человек. К примеру проект ontoys. А может ли мне
кто-нибудь объяснить, каким образом взаимодействуют между собой участники?
1. Как может быть реализован механизм оповещения клиентских приложений о том,
что, к примеру, один из участников сделал ход или другой участник хочет присоединиться
к игре и так далее)?
2. Что обеспечивает в этом механизме целостность данных? Может быть на сервере
создается таблица (или несколько таблиц) куда заносятся происходящие события
и клиентские приложения с определенной периодичностью делают запрос к этой базе
данных?
p.s. Хотелось бы услышать краткое описание схемы взаимодействия и варианты реально
используемых языков для создания такого рода игр или ссылки на материалы, где
об этом можно почитать. Буду рад любой помощи.
Телепрограмма федеральных и кабельных каналов на неделю:
http://www.blindcompass.ru/tv.php
Грызунов Александр. Самара.
Приветствую всех.
Не совсем понятно, какой уровень вас интересует: сетевой или прикладной.
На сетевом уровне взаимодействие осуществляется через сети tcp/ip.
На прикладном -- программы-клиенты на машинах участников либо поддерживают постоянное
соединение с программой-сервером, либо соединяются с ней по мере необходимости
(аналогично тому, как это делают браузеры).
Есть еще вариант p2p, когда каждый игрок поочередно (или постоянно) соединяется
с каждым игроком (а выделенного сервера в рамках прикладного уровня при этом
нет).
Есть две схемы хранения информации: распределенная и централизованная.
В зависимости от решаемой задачи вы должны выбрать подходящую.
Некоторые считают, что есть комбинированный вариант, но нередко комбинирование
связано с тем, что любая крупная задача может распадаться на более мелкие подзадачи
и для каждой из них порой приходится выбирать свою схему хранения информации.
Допустим, вы выбрали централизованный вариант и информация о состоянии игры хранится
на сервере.
Тогда игроки (клиенты) устанавливают соединение с сервером (полагаем, что это
постоянное tcp-соединение) и посылают на сервер информацию о действиях игрока
и принимают информацию об изменениях игрового пространства (состояния игры).
Как происходит добавления игрока и как происходит обмен данными, вам станет очевидно,
если вы разберетесь, например, с программированием интернет сокетов (на любом
доступном вам языке, в т.ч. и скриптовом).
То. как конкретно на прикладном уровне происходит обмен информацией между клиентом
и сервером, зависит от самой игры (ее вида, жанра и т.п.).
Если соединение постоянное, то и клиент, и сервер могут посылать данные в любой
момент времени, поэтому
1. клиент может отослать информацию сразу, как только игрок проявил какую-либо
активность (нажал клавишу, ввел команду, щелкнул мышью и т.п.);
2. сервер может отсылать информацию сразу, как только состояние игры изменилось.
Клиент отсылает свою информацию только серверу.
Сервер отсылает свою информацию всем клиентам.
Разумеется, прием информации у клиента и сервера происходит в отдельном потоке
(потоках), чтобы не блокировать выполнение других задач.
Дальше уже идут вопросы оптимизации трафика, так как сеть пока еще самый медленный
компонент сетевой игры (исключая игрока) и от того, насколько хорошо организован
обмен информацией, сильно зависит и общая динамика игрового процесса.
Разумеется, в так называемых "пошаговых" играх это менее актуально, чем в так
называемых играх "реального времени".
Кроме того, возникают еще вопросы безопасности как то: фальсификация данных,
нецелевое использование информации клиентом для получения игровых преимуществ.
Допустим, у вас сервер передает клиентам первый раз местоположение всех объектов
игры, а затем только изменение их позиций и состояния.
Особо продвинутый игрок принимает информацию от сервера своим клиентом, который,
кроме всего прочего, в специальном окошке рисует расположение всех игровых объектов,
в том чсле и тех, которых этот игрок по вашему замыслу видеть не должен (и в
обычном клиенте он их не увидит).
Еще такой "специализированный" клиент может корректировать пприцеливание, так
как ему известны точные координаты вражеского объекта... и так далее...
Иными словами, как видите, обмен информацией в сетевых играх подразумевает решение
тех же вопросов, что и обмен информацией в обычных сетевых приложениях.
базе
В централизованной системе сервер хранит информацию о состоянии игры.
Как вы реализуете хранилище -- это ваше дело (можете использовать существующую
СУБД, можете написать собственный вариант и т.д.).
Если у вас соединение постоянное, то вы в клиенте держите поток (thread), ожидающий
информации от сервера, Когда такая информация появляется, поток ее обрабатывает
(например, тем или иным образом передает ее потоку, отвечающему за отрисовку
игрового пространства) и снова ожидает информации от сервера.
Если соединение не является постоянным, то есть клиент всякий раз устанавливает
tcp-соединение с сервером, то нужно предусмотреть меры синхронизации (хотя и
при постоянном соединении они тоже нужны). Каждое новое состояние игры может
получать свой номер.
Клиент, обращаясь к серверу за информацией, передает номер последнего полученного
им состояния, а сервер, соответственно, либо передает ему новое состояние (если
таковое появилось), либо подтверждает актуальность текущего состояния.
В этой схеме инициатор соединения и инициатор первой передачи информации всегда
является клиент и сервер сам не может инициировать первую передачу информации,
т.к. не может сам инициировать соединение с клиентом.
Однако это как раз то поведение, которое мы получаем, если реализуем сетевую
игру на основе http-протокола и/или связки браузер + http-сервер.
Кратко описать это весьма затруднительно и любое краткое описание будет страдать
неполнотой.
По большому счету, игры во многом схожи с неигровыми приложениями, поэтому базовые
основы написание сетевых приложений остаются базовыми и для написания сетевых
игр.
Клиент-серверная архитектура тоже универсальное понятие и ее концепции не зависят
от того, какое конкретно приложение вы разрабатываете.
Любой язык, поддерживающуй работу с сетевыми интерфейсами или хотя бы с сетевыми
протоколами (в т.ч. и скриптовые).
Вы взяли слишком широкое понятие "многопользовательская сетевая игра", поэтому
более конкретный выбор средств разработки и реализации зависит от типа игры,
платформы и т.п.
Слово "многопользовательская" означает лишь то, что ваша игровая система должна
распознавать действия разных игроков, а состояние игры включать в себя информацию
о разных игровых персонажах, управляемых от внешних источников событий (пользовательский
ввод на машинах игроков).
Слово "сетевая" означает лишь, что данные о пользовательском вводе могут поступать
не только от клавиатуры и мыши , присоединённых к данному компьютеру, но и из
сети, а устройством отображения игровой картины может быть не только дисплей
(аудиосистема), подключенный к данному компьютеру, но и сеть (точнее, некий игровой
терминал, подключенный через сеть).
Как вы реализуете эти абстракции -- это поле для вашего творчества (и самообразования).
Выше я рассказал лишь об одном из вариантов (да и то не полностью).
Так называемыые "скриптовые" языки типа php, python, perl и т.п. весьма удобны
для написания прототипа игры, отладки протокола обмена данными и т.п. Затем,
если производительности получившихся клиента и сервера не хватает, можно что-то
переписать на C/C++, Delphi/Pascal и т.п.
Успехов. Анатолий.