Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > разработка игр, графический дизайн и моделирование > Gamedev - cоздание игр: Unity, OpenGL, DirectX
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 02.04.2011, 00:01   #1
L_M
Форумчанин Подтвердите свой е-майл
 
Регистрация: 25.02.2008
Сообщений: 289
По умолчанию Сетевые игры - обмен информацией

Доброго времени суток. У меня возникла не оригинальная идея сделать сетевую игру. Только вот не знаю, как организовать общение клиент-сервер? Например есть несколько параметров, допустим "уровень жизни" и "видимая область". В видимой области могут появляться и пропадать игроки, ну и уровень жизни надо сверять с сервером.
1) Надо ли объединять эти запросы в некоторую единую структуру?
2) Если есть автообновление по таймеру например раз в 2 секунды, а пользователь переместился или совершил другое действие, требующее нового запроса, отправлять ли запрос или его откладывать, чтобы был 1 пакет исходящих данных и один входящих в каждый тик таймера?
Упс...
L_M вне форума Ответить с цитированием
Старый 02.04.2011, 00:06   #2
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию

Клиент должен запрашивать свое действие у сервера, а сервер проверять и пересылать ему разрешение и всем обновление параметров, кто может видеть конкретного клиента. Никакого обновления по таймеру, только когда в этом есть необходимость. Необходимость это: запрос клиента, действие ИИ-игрока, смена параметров карты.
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Старый 02.04.2011, 13:11   #3
L_M
Форумчанин Подтвердите свой е-майл
 
Регистрация: 25.02.2008
Сообщений: 289
По умолчанию

Цитата:
Сообщение от Beermonza Посмотреть сообщение
Клиент должен запрашивать свое действие у сервера, а сервер проверять и пересылать ему разрешение и всем обновление параметров, кто может видеть конкретного клиента. Никакого обновления по таймеру, только когда в этом есть необходимость. Необходимость это: запрос клиента, действие ИИ-игрока, смена параметров карты.
Интересно... то есть имея 10 бегающих в видимой области игроков необходимо при каждом их шаге пересылать информацию от всех ко всем непрерывно? Или все-таки собирать информацию и отдавать всем через промежутки времени?
Упс...
L_M вне форума Ответить с цитированием
Старый 02.04.2011, 15:47   #4
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию

Цитата:
Сообщение от L_M Посмотреть сообщение
Интересно... то есть имея 10 бегающих в видимой области игроков необходимо при каждом их шаге пересылать информацию от всех ко всем непрерывно? Или все-таки собирать информацию и отдавать всем через промежутки времени?
Нет, не при каждом. Допустим это RPG. Запрос клиента имеет вид: "хочу в эту точку". Сервер принимает запрос, проверяет, если все с клиентом правильно, отсылает всем и клиенту в том числе команду: "клиент номер X стоит тут, идет сюда". Т.е. сервер один раз принял запрос и разослал команду тем кто видит этого клиента и ему самому. В промежутке между стартом и финишем клиента, сервер ничего не принимает от клиента и не отправляет, если от этого клиента не поступит другой запрос. У всех остальных клиентов этот будет топать из одной точки в другую без вмешательства сервера по своему внутреннему таймеру.

Допустим это Action. Здесь существует система предугадывания, которая определяет положение объектов и синхронизирует их поведение по таймеру сервера. В ней есть стробирующие пакеты, которые в себе содержат поправки, которые клиент должен применить к своему таймеру и параметрам окружения. Если персонаж клиента бежит вперед, сначала посылается конанда: "нажал вперед", ...сервер отошлет всем: "клиент номер X двигается вперед". С периодичностью всем будут приходить пакеты поправок положения всех персонажей в зоне действия. Персонаж клиента будет у всех бежать пока не будет отпущена клавиша "вперед", ...от клиента в этом случае снова пойдет запрос: "отпустил клавишу вперед". Сервер остановит персонажа, и отошлет всем, что персонаж клиента стоит на месте. Мы часто видим в сетевых Action как некоторые персонажи ускоряются или замедляются, перемещаются рваными траекториями, исчезают/появляются - это все система предугадывания и дискретной поправки клиентских приложений с сервера.
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Старый 02.04.2011, 23:05   #5
L_M
Форумчанин Подтвердите свой е-майл
 
Регистрация: 25.02.2008
Сообщений: 289
По умолчанию

Цитата:
Сообщение от Beermonza Посмотреть сообщение
Допустим это Action. Здесь существует система ... синхронизирует их поведение по таймеру сервера. В ней есть стробирующие пакеты, ... которые клиент должен применить к своему таймеру ... С периодичностью всем будут приходить пакеты ...
Ну вот же таймер Каждые n секунд сервер и клиент будут общаться. Я конечно рассматриваю случай относительно большой загруженности: если 100 человек видят друг друга и бегают/прыгают, какой смысл делать 100 рассылок от сервера в секунду, а не сделать по тику таймера(например 10 раз в секунду) клиента(или сервера, неважно) отсылку своих данных о состоянии с ответом сервера всей накопленной между тиками информацией? Вероятно надо было указать, что я рассматриваю вариант не просто сетевой, а браузерной игры - т.е. в простейшем случает это http запрос и сервер сам ничего отсылать не будет.

И кроме того, не только же движение должно быть - передавать надо огромное количество информации - например добавляем чат, добавляем торговлю(где-то на рынке/аукциона/лавке продается товар, если его купят, то у клиента должно увеличится количество денег), какие-нибудь заявки и прочее. Причем все одновременно происходит. Вот это вторая часть вопроса: должно ли все передаваться одной структурой или несколькими?
Упс...

Последний раз редактировалось L_M; 02.04.2011 в 23:13.
L_M вне форума Ответить с цитированием
Старый 03.04.2011, 20:18   #6
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию

L_M, поправлю тебя, вернее переработанную таким образом тобой мысль, ...сервер не будет общаться в обязательном порядке с клиентами через определенные промежутки времени, а будет с ними общаться только тогда, когда от клиентов поступают запросы, ...все остальное время сервер будет слать всем поправку, где кто находится и что делает, ...это не общение, а синхронизация, и ее интервал устанавливается в зависимости от динамики игры. Он (промежуток между пакетами синхронизации) может быть 1 секунда, может быть 0,1 секунда. Для браузерных игр лучше выбрать 1 секунду, или 0,5 секунды, ...игру придется пересмотреть, иначе стандартный язык запросов сдуется в режиме типичного LAN-Action.

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

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

Вторая - сервер игры. Здесь происходит обработка карт и состояния игровых объектов, все, что касается боя, обработки ИИ. Этот сервер получает клиентов от логин-сервера, работает на том же IP, но по другому порту.

Третья - чат сервер. Здесь происходит обмен сообщениями и вся торговля. Клиентов он получает от логин-сервера, имеет свой порт.

В результате клиент одновременно числится на 3-х серверах и не способен помешать играющим своим активным присутствием в чате или в торговле.
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его

Последний раз редактировалось Beermonza; 03.04.2011 в 20:21.
Beermonza вне форума Ответить с цитированием
Старый 05.04.2011, 17:36   #7
L_M
Форумчанин Подтвердите свой е-майл
 
Регистрация: 25.02.2008
Сообщений: 289
По умолчанию

Beermonza, можно поподробнее расписать? Пусть для начала это будет что-то пошаговое - то есть не совсем пошаговое, а просто не очень быстрое. Вот открыл человек игру, ввел логин, пароль, нажимает кнопку вход - 2 параметра уходят на сервер и в ответ приходит все необходимое: карта, характеристики и пр. Через секунду клиент отправляет запрос на сервер 'id=789', и сервер отвечает всеми изменениями, например {'123':{'move':'2|3'}, '324':{'mess':'Hello'}, '567':{'timeout':'1'}}. Игрок пишет в чат "привет", подбегает к npc и берет квест. Вторая секунда игры заканчивается, клиент посылает запрос 'id=789 goto=5|6 begin=765475 mess="Привет"' и в ответ получает новый пакет данных, сформированный на сервере запросами всех остальных игроков. Вот такое мое видение. И вопросы, возникающие при этом таковы: 1) правильна ли задержка отсылки данных? Если рассчитывать на 1 или 2 секунды - для человека это все-таки мало, а для сервера может стать значительной нагрузкой, поэтому я и хочу ее сделать - в моем примере пройдет не 3 запроса в секунду, а только один. 2) Если все-таки делать отправку запроса без задержки - шагнул - запрос, шагнул - запрос, то нужно ли в ответе посылать всю информацию сервера: кто что сделал. То есть если я делаю 3 шага за секунду, то 3 запроса на сервер за эту секунду будет, но кроме того клиент раз в секунду посылает запрс, что делали другие пользователи. Так вот информацию о действиях других игроков отдавать 3 раза(конечно не всю, а только новую) или же отдать 1 раз в секунду любому из запросов а на 2 других, даже если появилось что-то новое, молчать? Хочется, чтобы как можно меньше была нагрузка на сервер - т.е. меньше запросов и обработок.
Упс...

Последний раз редактировалось L_M; 05.04.2011 в 19:54.
L_M вне форума Ответить с цитированием
Старый 05.04.2011, 21:32   #8
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию

L_M, давай пока логику логин-сервера откинем (регистрация, вход) поскольку там свои хитрости и последовательность команд протокола, причем только строго установленная.

Для начала разберем сервер игры. Это не просто программа принимающая и отправляющая пакеты, а сама игра, ее логика, ее элементарный скелет, без графики. В программе есть перебор карт, перебор персонажей по картам. Чтобы работал ИИ и пользователи могли перемещаться нужно завести на сервере таймер, который будет обновлять игровой мир (загруженные карты) и контролировать пользователей, кто, где в текущий момент находится на картах и что делает. Выглядит вот так:

Карта 1
Пользователь 1
Пользователь 2
Пользователь 3
Карта 2
Пользователь 4
Пользователь 5
Карта 3
Пользователь 6
Пользователь 7
Пользователь 8

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

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

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

Ни в коем случае нельзя строить модель сервера, основанную на прямом диалоге клиента и сервера, т.е. клиент прислал запрос, сервер пробежался по картам, нашел пользователя, изменил параметры, просчитал битву конкретного пользователя, отослал всем кто видит, и так для каждого в момент поступления запроса. Это неправильно. Сервер должен просто зафиксировать желание клиента, выполнить просто как пометку "пользователь перемещается в направлении XY", отправить в ядро, и разослать конкретно в сокеты пользователей, что видят данного, и на этом диалог закончен. Ядро будет считать перемещение как положено и в нужный момент выполнять рассылку.

Пытаемся узнать кому нужно принимать пакет обновления. Допустим, клиент прислал пакет: "иду в точку XY" (RPG), или "нажал вперед" (Action). Каждый объект игры - набор записей. У каждого пользователя при входе на кару или на сегмент есть запись отвечающая за это. Чтобы найти пользователей для рассылки, нужно обратиться к записи кары (сегмента) у этого пользователя, ...это указатель на конкретную карту (сегмент) в загруженном списке. У пользователя есть записи на радиус обзора. Делаем условие: пробежка по пользователям карты (сегмента), попадающие в радиус обзора, ...каждому шлем по указанному у них сокету пакет: "персонаж N идет от X1Y1 в X2Y2" (RPG), или "персонаж N направление XY вперед" (Action).

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

Чат работает независимо от ядра, сообщения пересылаются по своим правилам. Торговля - передает изменения параметров в ядро после проверки (покупка предметов, запись в параметры конкретных пользователей).
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Старый 05.04.2011, 22:32   #9
L_M
Форумчанин Подтвердите свой е-майл
 
Регистрация: 25.02.2008
Сообщений: 289
По умолчанию

Что-то это слишком сложно. Может вернуться на шаг назад, допустим рассмотрим экономическую стратегию, где никто никуда не бегает: условно поле, кликнул - построил. И все. Никакого перемещения. Только загрузить список объектов. Даже в этом случае не стоит организовывать
Цитата:
модель сервера, основанную на прямом диалоге клиента и сервера
- запрос клиента - список построенных/сломанных зданий?
Упс...
L_M вне форума Ответить с цитированием
Старый 05.04.2011, 23:15   #10
Beermonza
Инженер ИС
Старожил
 
Аватар для Beermonza
 
Регистрация: 13.12.2006
Сообщений: 2,671
По умолчанию

Цитата:
Сообщение от L_M Посмотреть сообщение
Что-то это слишком сложно. Может вернуться на шаг назад, допустим рассмотрим экономическую стратегию, где никто никуда не бегает: условно поле, кликнул - построил. И все. Никакого перемещения. Только загрузить список объектов. Даже в этом случае не стоит организовывать - запрос клиента - список построенных/сломанных зданий?
Это еще легко описал, на примитивном уровне, ...все в сущности для реального проекта сложнее раз в сто.

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

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

Каким образом пользователи будут видеть развитие своих построек, если, допустим, никто не будет посылать запросы? ...никаким (!), нужно ядро, которое и есть игра, а клиент - средство отображения игрового пространства на удалении от сервера, ...вся жизнь проходит на сервере.
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
Beermonza вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Как организовать обмен информацией между программой и собственной службой (сервисом) pro2011 Win Api 8 20.01.2011 04:11
Обмен информацией W0LF Общие вопросы Delphi 2 01.01.2010 22:57
Помогите с информацией по теме для реферата. silence_master Свободное общение 1 14.12.2009 09:09
Обработка отметок с информацией о стиле абзаца andreyGO Microsoft Office Word 6 25.05.2009 11:21
Файл с информацией werser Общие вопросы Delphi 7 24.05.2008 20:55