PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


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

> Описание: коллективный учебный проект.
Zuldek
Отправлено: 22 Февраля, 2012 - 10:29:36
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Что здесь?

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

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

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


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

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

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

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

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

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

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


upd. Если тема не по адресу, - извиняюсь и прошу перенести в соответствующий раздел.

(Отредактировано автором: 29 Февраля, 2012 - 14:14:27)

 
 Top
EuGen Администратор
Отправлено: 22 Февраля, 2012 - 10:42:03
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




Интересно, почему тематика всегда направлена в эту сторону.
Пожелаю удачи. Может, потом сравним функционал - правда, то объявление, что было дано мной, уже удалено и проект пока "on hold" в силу возникших ограничений по времени. Но, может, у Вас выйдет быстрее.


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
Panoptik
Отправлено: 22 Февраля, 2012 - 10:46:54
Post Id



Постоянный участник


Покинул форум
Сообщений всего: 2497
Дата рег-ции: Нояб. 2011  
Откуда: Одесса, Украина


Помог: 131 раз(а)




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

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

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

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

ну и пожелаю удачи


-----
Just do it
 
 Top
Zuldek
Отправлено: 22 Февраля, 2012 - 10:54:39
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Логика работы приложения

Построение игрового мира
Спойлер (Отобразить)

(Отредактировано автором: 29 Февраля, 2012 - 14:10:16)

 
 Top
Zuldek
Отправлено: 29 Февраля, 2012 - 14:04:46
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Как обычно, рад любым советам, комментариям или замечаниям.
upd. пост прошу не удалять: будет заполнен следующим логическим блоком.
 
 Top
Zuldek
Отправлено: 01 Марта, 2012 - 09:47:22
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Логика работы real-time движка игры

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


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

(Отредактировано автором: 02 Марта, 2012 - 10:10:03)

 
 Top
Zuldek
Отправлено: 02 Марта, 2012 - 07:59:17
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Монстры и неигровые персонажи, изменение взаимодействия клиента и сервера

Ниже постараюсь обдумать и описать логику программирования монстров и неигровых персонажей. Как обычно, буду рад видеть мнения, советы и рекомендации.
Рассмотрев логику перемещения игроков в риал-тайм мире игры, переходим к остальной части его "населения", - монстрам и нипам.
Задачи:
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, записываем координаты и характеристики персонажа в бд, закрываем сессию.

(Отредактировано автором: 02 Марта, 2012 - 10:26:41)

 
 Top
DeepVarvar Супермодератор
Отправлено: 02 Марта, 2012 - 09:12:37
Post Id



Активный участник


Покинул форум
Сообщений всего: 10376
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)





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


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




DeepVarvar пишет:

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

Это замечательно. Какую цель преследовал пост?
 
 Top
Panoptik
Отправлено: 02 Марта, 2012 - 15:02:12
Post Id



Постоянный участник


Покинул форум
Сообщений всего: 2497
Дата рег-ции: Нояб. 2011  
Откуда: Одесса, Украина


Помог: 131 раз(а)




у оффтопа нет цели. вы лучше не отвлекайтесь. продолжайте. интересно созерцать. а критика пока неуместна


-----
Just do it
 
 Top
DelphinPRO
Отправлено: 02 Марта, 2012 - 15:08:20
Post Id



Активный участник


Покинул форум
Сообщений всего: 7190
Дата рег-ции: Февр. 2012  


Помог: 353 раз(а)





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

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

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


-----
Чем больше узнаю, тем больше я не знаю.
 
 Top
Zuldek
Отправлено: 02 Марта, 2012 - 15:20:38
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Пока разбираемся с логикой работы и архитектурой всего приложения. Разумеется, что когда работа выйдет за рамки написания базовых классов уровня бд, логики и визуала, все будет на gite.
 
 Top
Acmodeu
Отправлено: 04 Июля, 2012 - 21:26:22
Post Id


Новичок


Покинул форум
Сообщений всего: 1
Дата рег-ции: Июль 2012  


Помог: 0 раз(а)




Привет всем, очень увлекательный пост =) Уроки или же совместное написание браузерной игры с нуля.. Очень бы хотелось поучаствовать в данном эксперименте.. Ну и как всегда, все начинается с базы.. наверно с первой таблицы users )) Нужно определить какие ячейки нужны нашему персонажу - с выдуманным ником Davakin Ха-ха И написать авторизацию =))) Жду актива... И конечно же Zuldek
 
 Top
Zuldek
Отправлено: 10 Июля, 2012 - 12:27:10
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Хобби не заброшено.
Изучая клиентскую сторону разработки,
наткнулся на интереснейший доклад
Мастлук всем кто интересуется вопросами разработки браузерных игр и любых приложений на HTML5 CSS3 JS (поможет выбрать сторону силы). Доклад на английском.

(Отредактировано автором: 10 Июля, 2012 - 12:34:56)

 
 Top
feuille morte
Отправлено: 26 Сентября, 2012 - 01:19:56
Post Id



Новичок


Покинул форум
Сообщений всего: 1
Дата рег-ции: Сент. 2012  
Откуда: Россия, Москва


Помог: 0 раз(а)




Приветствую всех обитателей форума!

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

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

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

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


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

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

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

(Отредактировано автором: 26 Сентября, 2012 - 01:20:43)



-----
Мечтайте больше! У кого-нибудь ваша заветная мечта обязательно сбудется!!!
 
 Top
Страниц (2): [1] 2 »
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Обучение на основе реальных проектов »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB