Как создаются MMOG

[[Smarik]]

Здравствуйте, давно хочу создать свою MMO игру, в качестве платформы будет выступать мобильные устройства, но, я думаю не стоит акцентировать на этом внимание, т.к. различия от разработки MMO на любую другую платформу не существенные. Уже создано большинство условия для начала работы, останавливает только одно: не хотим повторять чужих ошибок, из-за которых в итоге бросают проекты. Я тут подготовил несколько вопросов интересующих меня, так же интересны советы и подсказки как все правильнее реализовать.
Начну с жанра и основных действий игры, возможно, это имеет значение…
Это будет космический action без элементов RPG в двухмерном мире вид сверху. В течении игры вы зарабатываете деньги и воюете с другими игроками 1 на 1 победитель получает опять же деньги которые может тратить на ремонт и апгрейд корабля (броня, оружие, скорость) вот и все. Игрушка банальная, но с ростом опыта будем стараться улучшать проект (если он конечно не загнется этапе альфа версии, а то и раньше).
И так вопросы:
- Как лучше реализовать мир? Предположительно это будет три массива:
Первый массив карта, каждая ячейка будет иметь значение 0 или 1 (0 – пусто, 1 – кто-то тут стоит).
Второй массив - это массив игроков (если в первом массиве элемент равен 1 ищем во втором массиве кто это).
Третий массив или нет, это будет запись хм…что то я запутался… каждый игрок имеет n-ое количество денег, какой то апгрейд, куда эту информацию пихать чтобы можно было получить информацию исходя из элемента второго массива?
Существуют вопросы касающиеся работы с сетью, я думаю тут нужен протокол TCP т.к. PVP пошаговое, большой скорости вроде как не требуется, но какие данные нужно посылать? Нужно передавать каждый раз первый массив когда он изменяется? Тогда эту часть придется реализовывать через UDP и это вообще правильный метод? Не зашкалит ли трафик через час игры за десятки мб? Не умрет ли телефон от таких активных действий?
А как получать данные в клиент? Надо каждые 100м.с. скачивать данные с сервера? Мне кажется это смешным и мало похожим на правду.
Хранение данных.
Данные о игроках хранить в SQL сервере? Я не знаю этого языка, учить не очень охото…какие есть альтернативы желательно реализовывающиеся через delphi?
Ну ладно с технической стороной вопроса вроде покончено, далее буду пополнять список вопросов, надеюсь вам будет не сложно на них отвечать. Я понимаю что психологов тут нет или мало, но уверен многие работали в команде, возможно даже через интернет… как лучше организовать график работы чтобы не испытывать усталость и не чувствовать себя кому то обязанным. Прошу не советовать работать когда хочется, т.к. у меня есть желание работать пока я не приступаю к работе.

[Beermonza]

О графике работ

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

MMO (отношения клиента и сервера)

СЕРВЕР - вот он центр игры, все происходит в нем. Клиентское приложение не должно ничего вычислять и присваивать все это выполняет сервер, от регистрации клиента до полного сопровождения по игре. Клиентское приложение лишь рисует то, что ему "показывает" сервер не более того. Конечно есть вспомогательные структуры, но по большей части это динамические списки - наборы записей особого, созданного самостоятельно, типа. Судя по вашей задумке у вас есть лишь один двумерный массив - это карта с клеточками, в клеточках - индексы - указатели на записи в списках планет, кораблей, станций, что там еще? ...если в клетке ничего нет, то там ничего нет ) ...0 или если тип массива строковый для сложных индексов, то там просто '' - пустота, это вы и проверяете. Плавно подходим к системе хранения.

Хранение данных

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

Игровой протокол

Главнейшая задача - минимизировать траф, для этого нужно разработать систему команд, да как можно компактнее представленных. Работать вам с последовательностью байт (0 - 255), где есть заголовок, размер, тело, всевозможные параметры:

1-й байт - код команды
2-й байт - длина тела команды
3-й - N-й - блок данных

Вот пример команды на перемещение с сервера клиенту:

(код, размер, X, Y, >X, >Y)
33 6 146 26 34 36

А выглядит это все в потоке вот так:

! ’ $

...всего 6 байт! но вы уже знаете где был объект и куда он должен переместиться. Аналогично создаются все команды, скурпулезно состыковываются, отбрасывается все лишнее. Каждый запрос имеет свой ответ, и притом только строго утвержденный. Таким образом вы легко выйдете на траф 10Кбайт/час, ну, с сообщениями и текстами будет больше, но никак не за 1Мбайт/ч, а существенно меньше.

Дело не простое, будет потрачено много времени, если это вас не пугает, тогда вперед и удачи.

[pu4koff]

Сообщение от [Smarik]

Как лучше реализовать мир?

Тут смотря какой размер мира и предположительное число игроков онлайн. Если там 10 планет и 5 игроков будет играть одновременно, то может проще хранить список/массив планет и игроков и смотреть какую ячейку они занимают. Так же если размер мира будет 1000х1000, то у Вас уж слишком большой массив будет. Да и космос скорее пуст, чем полон и наверно 80% массива вашего будет в нулях. Ну и опять же хранение мира на серваке и на клиенте могут кардинально отличаться. Ведь задачи у них различные и способы кодирования информации зависят от целей её использования)

Сообщение от [Smarik]

Существуют вопросы касающиеся работы с сетью, я думаю тут нужен протокол TCP т.к. PVP пошаговое, большой скорости вроде как не требуется, но какие данные нужно посылать?

Важную информацию нужно отправлять по TCP, а какую-то промежуточную можно на UDP. Передавать нужно наверное только действия игрока, т.е. клиент должен отправлять, что я перешел в клетку 5:5, или я стреляю в игрока такого-то. Допустим игрок перемещается из точки А в точку В. Потеря какой-то промежуточной точки С не критична, поэтому перемещение можно отпрвлять по UDP протоколу, а уже переход в конечную точку я думаю важен и его лучше по TCP отправить. Так же, если мир большой, то не нужно будет отправлять клиенту о том, что другой игрок на другом конце галактики переместился влево на клетку. Его всёравно нам не видно и безразлично что там с ним происходит.

Сообщение от [Smarik]

А как получать данные в клиент? Надо каждые 100м.с. скачивать данные с сервера? Мне кажется это смешным и мало похожим на правду.

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

Сообщение от [Smarik]

Хранение данных.
Данные о игроках хранить в SQL сервере? Я не знаю этого языка, учить не очень охото…какие есть альтернативы желательно реализовывающиеся через delphi?

ну язык не самый сложный и выучить что-то новое никогда не вредно Но вообще зависит от объема информации. Может там структурированный файл лучше подойдёт, чем база MS SQL, т.к. там надо то о 10 игроках хранить инфу и использование этой СУБД - это как из пушки по воробьям Хотя есть и менее "серьезные" СУБД, Firebird какой-нибудь или MySQL и еще вагон и маленькая тележка. Выбор зависит от объемов)

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

[[Smarik]]

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

[Beermonza]

Сообщение от [Smarik]

Ну чтож, вроде все понял, кроме раздела игровой протокол в посте Beermonza, ...

Естественно, сразу уловить суть тяжело. Игровой протокол - одна из сложнейших частей MMO, рутина в общем. Смысл в том чтобы передавать клиентам только фактическое изменение мира (карты). Опять же, коснемся примера перемещения корабля в космосе на некотором участке. Вы спрашивали: "если передавать массив карты и все что в ней находится клиенту это будет сильно кушать траф?" ...если правильно передал вашу мысль, ... да это действительно нерационально. Практика сводится к тому, что вам нужны координаты где был кораблик и куда клиент хочет его передвинуть. В двумерном пространстве есть координаты X и Y, так вот, сервер сам знает где был ваш кораблик (где вы его оставили в прошлый раз, ...записано) а от клиента сервер ждет координаты куда "тыкнул" на карте пользователь, а для того чтобы сервер мог корректировать ваше положение нужно отослать серверу координаты обеих точек, где кораблик был и куда пользователь хочет его передвинуть. Итого у нас 4 цифры, если мы будем работать в сети, то нужно воспользоваться массивом типа Byte, значит нужно слать массив длиной 4 в котором есть все необходимое для передвижения кораблика. И у сервера и у клиента есть алгоритм, который плавно двигает кораблик, зная начальную и конечную точку, ...и сервер и клиент выполняют их параллельно у себя, а затем если клиент случайно разошелся с сервером, то сервер пошлет правильные координаты место положения, также командой в виде массива байт.
Второе. Просто так команду отправлять нельзя, она должна содержать заголовок, который показывает что это за команда, ...ведь в протоколе будут сотни типов команд, и каждую нужно использовать правильно. Поэтому в команду вводят еще один байт в самом начале. Если такая команда придет на сервер, то сначала считается первый байт массива, определится тип команды, например это была цифра 33, которая означает "команда перемещения", значит сервер четко "знает", что остальные байты это координаты где был объект и куда нужно его переместить. Вот для наглядности:

код тип команды
33 - перемещение
44 - атака
55 - информация
66 - сообщение

Вот так в коде:

// приняли буфер buf

// определяем тип команды и применяем
case buf[0] of
// перемещение ------------------------------------
  33: begin
         X:=buf[1];  // где был кораблик
         Y:=buf[2];
         NewX:=buf[3];  // куда должен переместиться
         NewY:=buf[4];
       end;
// атака -------------------------------------------
  44: begin
         AttackX:=buf[1];  // в какую точку стрелять
         AttackY:=buf[2];
       end;
// информация -------------------------------------
  55: // тут процедура применения значений массива
       // может это Label в которых меняются параметры корабля
       // повреждение, шит, пушка, ее заряды, и мн. др.
// сообщение
  66: // тут процедура трансформации последовательности байт
       // с строку символов, ...это будет что-то типа чата.
end;

Вот, собственно, сущность игрового протокола на прием.

Сообщение от [Smarik]

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

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

[[Smarik]]

Спасибо, пока вопросов не осталось, в будущем, возможно тут появятся новые вопрсы

[ROD]

ЧТо касается других миров, (вселенных), то можно поступить так (сразу говорю, далее следует мнение напрофесионала):

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

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

Где каждая из букв обозначает какой либо объект.

При поаадании в другой мир, допустим он будет
XZZA
AZZZ
CCZA

Клиенту можно сказать, что бы он забыл все объекты и переслать заново все объекты, но уже другова мира, либо сказать, что
в месте 1-2 (первая строка 2-й столбец) исчз объект X и возник объект Z

аналогично с другими изменениями.

Первый вариант будет кушать больше трафика, второй будет сильнее нагружать сервер.

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

ТОгда тебе придется передавать только перемещающиеся объекты.

P.S.

Прочитал еще раз.. по моему малость ахинея, ну да ладно.

[Beermonza]

В любом случае, подгрузка с сервера осуществляется локациями, большими или экранными. Но, помимо самой структуры локации, как карты, существует обязательный элемент синхронизации клиента и сервера. В этом случае сервер должен следить за всеми перемещениями каждого игрока в данной локации и посылать ему обновленные данные игрового пространства на радиус обзора или чуть больше. Как видно, при локациях бОльших одного экрана, весь смысл в передаче всей локации и объектов на ней теряется, как и вообще сама сущность "перехода" на другую локацию для клиента. Он вовсе не ощущает на себе никакого перехода, просто принимает окружение, какое оно бы не было, просто показывая игроку в виде текста что он в другом мире в данный момент. Так что для клиента нужен двумерный массив и открытый канал, всегда принимать данные и использовать их он будет в этом массиве.
Если мир не слишком динамический, то можно себе позволить загрузку локации со статичными объектами, которые не поменяют своего места и не изменятся не при каких условиях. Тогда можно подгружать карту со статикой, а окружение высылать в виде списка, каждый раз обновляя его по мере надобности.
Теперь на счет этой меры надобности. Клиента мы не трогаем, он тут не причем. Что должен увидеть у себя игрок зависит от сервера. Для этого нужно держать в ОЗУ все карты мира/миров и игроков что на них находятся. Если на каких-то локациях не зафиксировано ни одного игрока, то такие локации пропускаются, за исключением того, если мир сильно динамический. При проверке очередного игрока на конкретной локации сервер должен определять его радиус обзора, и формировать окружение в команде, которую должен отправлять всем кто может видеть данного игрока. Если в радиусе обзора никого нет, то сервер отправит изменение только этому игроку. Ни в коем случае не нужно передавать массив карты клетка за клеткой с местоположением самого игрока, ...только то, что изменилось.