Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Разработка браузерной mmmorpg
Форумы портала PHP.SU » » Обучение на основе реальных проектов » Разработка браузерной mmmorpg

Страниц (2): [1] 2 »
 

1. Zuldek - 22 Февраля, 2012 - 10:29:36 - перейти к сообщению
Что здесь?

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

Что получится на выходе:

realtime mmorpg.
Речь о пошаговой картиночно-текстовой игре уже не идет.


Условия участия:

Приглашаются все желающие без ограничений.

Процесс разработки и инструментарий:

Спойлер (Отобразить)

(Добавление)
Краткое описание процесса геймплея и управления игрой.
Спойлер (Отобразить)

(Добавление)
Процесс разработки предлагаю условно разбить на следующие этапы.

Спойлер (Отобразить)


upd. Если тема не по адресу, - извиняюсь и прошу перенести в соответствующий раздел.
2. EuGen - 22 Февраля, 2012 - 10:42:03 - перейти к сообщению
Интересно, почему тематика всегда направлена в эту сторону.
Пожелаю удачи. Может, потом сравним функционал - правда, то объявление, что было дано мной, уже удалено и проект пока "on hold" в силу возникших ограничений по времени. Но, может, у Вас выйдет быстрее.
3. Panoptik - 22 Февраля, 2012 - 10:46:54 - перейти к сообщению
Сорри за скепсис, но не так давно тут начинался подобный проект и пока он в стадии глубокого застоя...
это всё интересно. но даже такая маленькая затея стоит больших усилий и покладаться на добровольцев-энтузиастов - значит ничего не добиться.

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

вот это плохо. к добру не приведет. если появится доброволец - он обязан взять на себя ответственность за выполнение и сделать это. иначе вас ждет провал...

я конечно может и не останусь в стороне если всё таки вот это ваше начало сдвинется с мертвой точки

ну и пожелаю удачи
4. Zuldek - 22 Февраля, 2012 - 10:54:39 - перейти к сообщению
Логика работы приложения

Построение игрового мира
Спойлер (Отобразить)
5. Zuldek - 29 Февраля, 2012 - 14:04:46 - перейти к сообщению
Как обычно, рад любым советам, комментариям или замечаниям.
upd. пост прошу не удалять: будет заполнен следующим логическим блоком.
6. Zuldek - 01 Марта, 2012 - 09:47:22 - перейти к сообщению
Логика работы real-time движка игры

Спойлер (Отобразить)


Для начала все. Мы описали теоретическую логику реализации "жизни" в мире игры, указав две возможные реализации "перемещения" персонажа по миру. Прошу комментировать, оценивать, уточнять и предлагать оптимальные варианты.
7. Zuldek - 02 Марта, 2012 - 07:59:17 - перейти к сообщению
Монстры и неигровые персонажи, изменение взаимодействия клиента и сервера

Ниже постараюсь обдумать и описать логику программирования монстров и неигровых персонажей. Как обычно, буду рад видеть мнения, советы и рекомендации.
Рассмотрев логику перемещения игроков в риал-тайм мире игры, переходим к остальной части его "населения", - монстрам и нипам.
Задачи:
1. Населить мир игры реалистичными не игровыми персонажами. Под последними будем понимать все спрайты, управляемые не игроками, а логикой приложения, далее, для удобства, буду называть их, собирательно, монстрами или объектами.
2. Монстры должны быть "живыми": подвижными, желательно умными, то есть с изменяемым в зависимости от игровых условий поведением.
3. Помимо объектов, которые можно уничтожать, должны быть объекты с которыми можно взаимодействовать: вступать в диалог, обмениваться инвентарем.
4. Помимо задачи установки фиксированного местоположения монстра в локации, девелоперы должны иметь возможность задавать пути перемещения монстров и их характеристики.

Самое важное, о чем нельзя забывать, - реализация риал-тайм мморпг, предполагает перемещение и взаимодействие с объектами в реальном времени синхронно у всех игроков, находящихся в одной локации. Это значит, что если, например, один персонаж вступил в бой или "увидел" перемещение монстра в точку Б из точки А, то тоже самое должен "увидеть" другой игрок, находящийся в той же локации. Иными словами, - принцип такой же, как в случае с перемещениями персонажей игроков, описанными в предыдущей статье.
Как, мы помним, существует 2 варианта взаимодействия с монстром: нападение и диалог.
Из них всем игрокам локации мы должны показать только бой с монстром.

Учитывая эти обстоятельства, вносим важные изменения в описанную ранее логику "жизни" в игровом мире:
1. Каждые 500 мс, мы должны спрашивать у сервера помимо координат игроков, координаты всех монстров в локации.
2. Самое важное и сложное: помимо координат монстров, мы должны будем брать с сервера, как минимум, ещё 3 параметра (реально их будет гораздо больше):
а). уровень жизни всех объектов
б). уровень "маны" объектов
в). события всех объектов.
С первыми двумя параметрами, думаю все понятно ибо это простые изменяемые числовые параметры. О третьем параметре поговорим подробно.
Нам нужно получать действия персонажей и монстров для того, чтобы адекватно отобразить их в игровом клиенте: в зависимости от них показать нужную анимацию, показать или удалить объекты на локации.
Какие события (те которые должны показываться всем клиентам) могут происходить с объектами в игровом мире:
1. Появление. Пример: появление монстра в локации через некоторое время после его убийства.
2. Перемещение
3. Атака. Атака монстра игроком либо наоборот, - атака игрока монстром.
4. Убийство персонажа или монстра.
5. Исчезновение игрока при выходе из игры, трупа монстра, любого другого объекта при его уничтожении (добыты ягоды - убираем куст).
6. Добыча ресурсов персонажем. Нужно для того, чтобы показывать другим игрокам что персонаж не просто замер у реки, а ловит рыбу, - показываем анимацию добычи ресурсов.

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

1. Местоположение всех персонажей на карте
2. Местоположение всех монстров на карте (Ниже подумаем, сможем ли мы не спрашивать этот параметр у сервера и брать его целиком или частично со стороны клиента, прописав маршруты заранее).
3. Действия всех объектов локации (также подумаем, сможем ли мы отдать выбор действия монстра на сторону клиента, хотя бы частично).
4. Жизненные параметры всех объектов локации ("жизни", "мана")
5. Идентификатор объекта, ник и уровень персонажа. Разумеется нам нужно будет знать о каком типе объекта идет речь. (Нужно подумать стоит ли и можно ли какую то часть этих данных хранить на стороне клиента не забирая все данные с сервера).

Теперь подумаем о тех пунктах где поставили пометки к размышлению. Нам нужно, чтобы как можно больше данных хранилось на стороне клиента (загружалось разом разом при заходе в игру или при заходе в локацию) и как можно меньше данных запрашивалось у сервера. Вместе с тем нам не нужно, чтобы хранящиеся в браузере данные в случае их подмены могли влиять на ход игры: ключевые параметры должны быть сверены с хранящимися на сервере.
2. Местоположение всех монстров на карте. Да, мы можем не спрашивать каждые 500мс. сервер о том где находится монстр. При заходе в локацию, мы будем получать 1 раз координаты, действия и события всех объектов локации. После чего, мы будем запрашивать их только в случае наступления события нападения монстра на игрока или наоборот. После этого мы будем запрашивать координаты показатели только того объекта, который напал или на который напали.
Это обстоятельство накладывает на клиент ещё один груз. В него будут передаваться (при заходе в игру) библиотеки, управляющие перемещением всех неигровых объектов мира, чтобы js сам рассчитывал их перемещение, и отображал в соответствующем месте.
+ плюс в таком подходе это оптимизация запросов к серверу: нам не придется каждый раз запрашивать координаты всех объектов локации. Однако есть одно НО. В случае организации хранения этих данных в бд, это реализуется относительно просто. В случае же использования для этих целей ресурсов веб-сервера и хранения данных в виде xml-файлов, каким образом это организовать мне пока не ясно... .

Съел шоколадку и стало ясно Улыбка . И так. Персонаж зашел в локацию. Нам нужно отдать ему координаты и действия всех объектов, которые "живы". Это понятно и не обсуждается. В дальнейшем же, Нам нет смысла в каждом ответе и запросе записывать все данные в один большой xml-файл: он может получится гигантских размеров. Поэтому, в определенном каталоге для сервера для данной локации, мы будем хранить отдельные события в локации также в формате xml. При запросе каждые 500 мс, сервер отдаст сформированный xml файл со всеми новыми события, действиями и объектами. То есть теперь мы будем спрашивать у сервера "что изменилось?" и он отдаст только новые события. То есть мы сделаем большой шаг в сторону оптимизации и уменьшения глюков, передавая с сервера только новые события. Клиент же вообще будет передавать на сервер только действия игрока, а не писать на сервер целый файл со всеми координатами, действиями и свойствами всех объектов. Если игрок стоит на месте, или на монстра никто не нападал, то клиент не перешлет серверу ничего, он лишь спросит: есть ли новые события. Сервер отдаст сформированный xml который будет содержать только изменившиеся координаты других персонажей (если не было других событий). Каждые 500 мс. на сервере будет выполнятся скрипт, собирающий все пришедшие событие в единый файл изменений, который и будет раздаваться всем клиентам. Просто, изящно и рационально и без дерганий БД.
Логика работы этого принципа при использовании субд будет по почти аналогична, с той лишь разницей что события будут хранится в единой таблице изменений на локации. Что из этих двух решений будет работать быстрее, учитывая что субд будет решать кучу других задач ещё предстоит выяснить.

И так, подытожив пост, распишем ещё раз кратко порядок работы приложения:

1. Игрок залогинился: авторизуем через бд, забираем с бд координаты локации, забираем с бд характеристики персонажа (о том как они там оказались, - позже).
2. Забираем с БД локацию без объектов: как помните, - передаем в клиент массив с текстурами, и монстрами.
3. Забираем большой XML-файл с текущим положением дел в локации: с этим ясно. Каждые 500 мс. серверный скрипт будет формировать файл новых событий и формировать новый большой файл с данными по всем объектам локации. Вновь приходящим в локацию, сервер отдаст большой файл, а тем кто уже в ней - "маленький" файл новых событий.
4. Отдаем и забираем xml-запросы событий. Клиент передает свои события, - забирает чужие события и события со своим персонажем после обработки всех событий уровнем логики.
Тут притормозим. Мы уже договорились о том, что просто принять события от клиента мы не можем: нам их нужно как-то проверить.
Следовательно, перед принятием и записью пакета от клиента в единый файл событий, мы и проведем эти проверки. Что проверим:
а). Куда переместился персонаж:
1. Посмотрим по карте в бд можно ли сделать ход в указанные координаты (без постоянной сверки с бд, думаю никак Огорчение. Поставим в уме галочку, чтобы во время реализации уровня бд оптимизировали этот момент, получив быстрый доступ к массиву координат каждой локации по которому может бегать персонаж.
2. Посмотрим по текущему "xml-файлу жизни" локации можно ли сделать ход в указанную точку (не наступим ли на другого персонажа). Если наступаем на монстра - приравнивеам ход к атаке, записав соответствующее событие в файл. Ставим в уме жирную галочку напротив критичной важности скорости выполнения этих операций.
б). Какое действие персонажа пришло от клиента: Проверяем возможно ли действие с пришедшим от клиента id объекта по бд либо xml-файлу (смотря на чем остановимся).
5. При выходе из игры. Отправляем событие исчезновения персонажа, записываем событие в xml, записываем координаты и характеристики персонажа в бд, закрываем сессию.
8. DeepVarvar - 02 Марта, 2012 - 09:12:37 - перейти к сообщению

Я однозначно остаюсь с EuGen'ом.
Кстати я начал пилить тестовый клиентский скрипт.
За основу взят голый JSON.
Никакой статичной хтмл-разметки, карту строит js на лету.
9. Zuldek - 02 Марта, 2012 - 14:54:20 - перейти к сообщению
DeepVarvar пишет:

Я однозначно остаюсь с EuGen'ом.
Кстати я начал пилить тестовый клиентский скрипт.
За основу взят голый JSON.
Никакой статичной хтмл-разметки, карту строит js на лету.

Это замечательно. Какую цель преследовал пост?
10. Panoptik - 02 Марта, 2012 - 15:02:12 - перейти к сообщению
у оффтопа нет цели. вы лучше не отвлекайтесь. продолжайте. интересно созерцать. а критика пока неуместна
11. DelphinPRO - 02 Марта, 2012 - 15:08:20 - перейти к сообщению

Ждем первых исходников Улыбка Потом и критика будет, и возможно кто-то подтянется.

(Добавление)
Zuldek пишет:
Первое время разработка будет вестись прямо на форуме, без применения SVN, сред разработки и баг-трекеров, поскольку далеко не у всех начинающих разработчиков есть опыт работы с ними

Спорная позиция. Если проект твердо решено довести до логического завершения, лучше сразу заюзать svn. Тот же GIT не очень сложен в освоении, плюс репо на гитхабе, - там исходники удобно просматривать тем кто просто будет следит за разработкой.
12. Zuldek - 02 Марта, 2012 - 15:20:38 - перейти к сообщению
Пока разбираемся с логикой работы и архитектурой всего приложения. Разумеется, что когда работа выйдет за рамки написания базовых классов уровня бд, логики и визуала, все будет на gite.
13. Acmodeu - 04 Июля, 2012 - 21:26:22 - перейти к сообщению
Привет всем, очень увлекательный пост =) Уроки или же совместное написание браузерной игры с нуля.. Очень бы хотелось поучаствовать в данном эксперименте.. Ну и как всегда, все начинается с базы.. наверно с первой таблицы users )) Нужно определить какие ячейки нужны нашему персонажу - с выдуманным ником Davakin Ха-ха И написать авторизацию =))) Жду актива... И конечно же Zuldek
14. Zuldek - 10 Июля, 2012 - 12:27:10 - перейти к сообщению
Хобби не заброшено.
Изучая клиентскую сторону разработки,
наткнулся на интереснейший доклад
Мастлук всем кто интересуется вопросами разработки браузерных игр и любых приложений на HTML5 CSS3 JS (поможет выбрать сторону силы). Доклад на английском.
15. feuille morte - 26 Сентября, 2012 - 01:19:56 - перейти к сообщению
Приветствую всех обитателей форума!

phpdocumentor поставил, с топиком ознакомился Улыбка

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

Единственный вопрос:

Цитата:
мы каждые 500 мс должны передать клиенту следующие данные:
1. Местоположение всех персонажей на карте
2. Местоположение всех монстров на карте


Может, лучше сделать некую "область видимости" персонажа? в зависимости от которой будут подгружаться те или иные объекты? Зачем нам знать кто сейчас бегает в другом конце карты, если мы туда не пойдем? Улыбка Маршрут мобов можно задать заранее рандомно в некотором определенном радиусе и пересылать изначально только жив моб или нет. А при приближении персонажа к определенной точке, подгружать конкретные маршруты.

Может как-то можно структурировать всю накопленную информацию путем изменения 1го топика?

*ушел изучать доклад на английском, а также вопросы, связанные с шаблонами проектирования, PDO, MVC и все окололежащее*

 

Powered by ExBB FM 1.0 RC1