PHP, MySQL/PostgreSQL, Apache/Nginx, HTML5, JQuery.
Серверная часть должна выдерживать одновременную игру 5000 игроков.
Система должна получится легко расширяемой для дальнейшего развития при желании и улучшении с применением, например, Flash-графики и 3d-контента.
Изначально же все будет реализовано максимально просто, а графика будет статична с минимальным количеством визуальных эффектов.
Предлагаю максимально строго придерживаться MVC-модели разработки приложения.
Уровень доступа к данным предлагаю реализовывать на основе PDO, это значительно упростит перенос приложения на PostgreSQL или другие субд если возникнет в этом необходимость.
Документация:
Раз будем создавать простую но расширяемую платформу, - сразу позаботимся об обеспечении её переносимости и документированности.
Первое время разработка будет вестись прямо на форуме, без применения SVN, сред разработки и баг-трекеров, поскольку далеко не у всех начинающих разработчиков есть опыт работы с ними. К тому же на начальном этапе разработки в них нет такой большой необходимости.
Любой создаваемый класс и объект должен быть документирован. За стандарт составления документации предлагаю принять phpdocumentor. У кого нет опыта работы с ним - почитайте мануалы, начав с википедии, либо посмотрите как будут писать документацию другие.
Вот в принципе и все для начала. Местами требования и установки расплывчатые, но все охватить в одном посте не получится и нет смысла пытаться.
Никаких временных рамок сроков и распределения обязанностей не устанавливается. Любой может заглянуть в тему и внести при желании посильный вклад в учебную разработку советом или рабочим кодом.
(Добавление) Краткое описание процесса геймплея и управления игрой.
Обозначим простую тему и жанр игры. Пусть это будет (определится опросом) mmorpg.
В нашей простой игре будет всего две противостоящих расы: ___ и ____, как ни странно, два пола персонажей.
Идем по пути краткого обзора того, как будет видеть игровой процесс игрок.
Фаза вступления в игру
1. Пользователь регистрируется, указывая свой email, ник, выбирает рассу и пол персонажа.
2. После подтверждения регистрации он попадает в стартовую игровую локацию.
Игровой мир: локации.
Определимся, что на начальном этапе у нас будет всего 7 игровых локаций. 3 для каждой рассы и 1 с возможностью межрассового pvp. Локация представляет собой 2D плоскость, изображение с размешенными на нем элементами с которыми игрок может взаимодействовать: нипы, здания, вражеские юниты (не игроки).
В каждой локации игрок в верхней части интерфейса будет видеть карту локации, в нижней - чат со списком всех игроков находящихся в этой локации.
Перемещаться по локациям игрок может посредством мини-карты, которая будет содержать список и порядок всех существующих локаций мира. Визуальную часть переходов пока не оговариваем.
3 типа локаций:
1. Разрешено пвп (можно вызывать игроков свой расы на дуэль).
2. Запрещено пвп
3. Разрешено нападение на игроков не своей расы.
Взаимодействие с не игровыми персонажами:
Нип это элемент или персонаж с которым может взаимодействовать игрок.
Не игрового персонажа можно добавлять через систему управления. Базовые параметры добавления:
1. Имя
2. Изображение
3. локация
4. координаты на локации
5. активен/нет.
6. тексты диалогов.
7. действия в ответ на действия игрока: текстовый ответ, передача предмета, нападение.
8. предметы
9+ Все параметры, как у игрока, за исключением динамических.
Виды взаимодействия с нипом:
1. диалог
2. бой
3. передача предмета
Взаимодействие с другими игроками:
С игроками можно вступить во взаимодействие только через его ник в чате локации.
2 вида взаимодействия: обмен инвентарем и дуэль. Отправку приватного сообщения в чате для удобства не будем считать взаимодействием с игроком
Описание логики боя:
В случае вступления игрока в бой с противником игроком или монстром загружается 2D-изображение с фоном локации боя (сразу ставим галочку, что у нас теперь есть 3 изображения для локации:1. на мини-карте, 2. большая карта локации, 3. фоновая подложка для дуэли) и статичными картинками противников.
Если бой ведут игроки, то они поочередно наносят удары друг другу, выбирая "удар" из списка доступных.
Если бой ведется с монстром, то приложение делает ходы за монстра.
Каждый ход подсчитываем здоровье бойцов, если у кого-то 0, заканчиваем бой, увеличиваем опыт победителя на N единиц.
Победа:
После смерти противника игроку открывается окошко с доступным инвентарем поверженного (ставим галочку - у каждого монстра и нипа должен быть список предметов "лута"), персонажу прибавляется N опыта (ниже - характеристики персонажа).
Поражение:
Поверженный игрок теряет (пока упростим задачу) часть инвентаря и отправляется в начальную локацию на N минут.
Характеристики персонажа:
В нашем приложении их набор будет минимальным.
1. Здоровье
2. Сила (усиливает удар на значении силы)
3. Броня (ослабляет удар на значение брони)
4. доступные удары (упрощенно скажем что просто наност разный урон)
5. Шанс критического удара (шанс на то, что урон от удара будет удвоен)
6. Уровень (Упростим задачу: по достижении каждого уровня увеличиваем каждую характеристику персонажа на N);
7. Опыт (Текущее количество опыта. По достижении опыта определенного для N уровня, поднимаем уровень персонажа на 1).
Предметы:
Любые предметы будут иметь простейшие характеристики:
1. +N к любым характеристикам персонажа.
2. Многоразовость. Если 0, то доступен в использовании, как удар. После использования удаляем его у игрока.
Управление игрой:
Пока просто перечислю функции
1. Добавление локации.
2. Добавление нипа.
2.1 Добавление текстов
2.2 Добавление предметов
3. Удаление персонажа
4. Бан персонажа с сохранением в базе.
5. Молчанка в чате.
6. Убийство игрока
7. Передача 4, 5, 6 полномочий конкретным игровым аккаунтам.
Для начала с геймплея хватит.
Не уточнено ещё многое, но для написания каркаса приложения этого хватит. Добавляйте свои предложения не усложняющие реализацию. Позже допишу необходимые и заслужившие поддержку в этот пост.
(Добавление) Процесс разработки предлагаю условно разбить на следующие этапы.
1.Вносим поправки-пожелания в "регламент" разработки выше.
2.Лаконично обсуждаем и вносим предложения в "описание геймплея", своего рода диз-док нашей простой игры. В сторону его усложнения двигаться не будем, поскольку цели у нас учебные.
Начинаем проектирование с разработки бд и уровня доступа к данным.
Повторно оговоримся, что мы не используем встроенные функции php для работы с субд, а используем PDO. Для доступа к данным в выигрышных ситуациях пишем и используем хранимые процедуры.
upd. Если тема не по адресу, - извиняюсь и прошу перенести в соответствующий раздел.
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
Интересно, почему тематика всегда направлена в эту сторону.
Пожелаю удачи. Может, потом сравним функционал - правда, то объявление, что было дано мной, уже удалено и проект пока "on hold" в силу возникших ограничений по времени. Но, может, у Вас выйдет быстрее.
-----
Panoptik
Отправлено: 22 Февраля, 2012 - 10:46:54
Постоянный участник
Покинул форум
Сообщений всего: 2493
Дата рег-ции: Нояб. 2011 Откуда: Одесса, Украина
Помог: 131 раз(а)
Сорри за скепсис, но не так давно тут начинался подобный проект и пока он в стадии глубокого застоя...
это всё интересно. но даже такая маленькая затея стоит больших усилий и покладаться на добровольцев-энтузиастов - значит ничего не добиться.
если вы настроены это делать - советую начинать самому, а желающие может и появятся
Zuldek пишет:
Никаких временных рамок сроков и распределения обязанностей не устанавливается.
вот это плохо. к добру не приведет. если появится доброволец - он обязан взять на себя ответственность за выполнение и сделать это. иначе вас ждет провал...
я конечно может и не останусь в стороне если всё таки вот это ваше начало сдвинется с мертвой точки
ну и пожелаю удачи
-----
Zuldek
Отправлено: 22 Февраля, 2012 - 10:54:39
Постоянный участник
Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010
По наступлению логического завершения, информация в посте, как и заголовки, будет структурирована и приведена в финальный вид.
Думаю так правильнее озаглавить данный пост. Поскольку тут будет довольно много информации относящейся как к структурной, так и к логической части приложения и технологиям которые предполагается использовать.
Ранее упоминалось что в начальной версии ммо будет реализован без упора на графическую часть и без использования flash, в дальнейшем, при готовой основе эту оболочку нарастить будет не сложно. Потому ограничиваемся JS+AJAX.
Было упомянуто что мир будет реализован в виде двумерных игровых локаций. Внимательно рассмотрев то что представляют собой некоторые подобные "игры" в которых реализм отодвинут уж совсем на задворки стало очень тоскливо: по миру персонажи визуально не перемещаются, игрок тыкает мышью по игровым локациям, которые являются сплошной картинкой, а единственно где игрок видит своего персонажа - бои, выглядят скучно и не интересно, поскольку представляют собой стоящие друг напротив друга дергающиеся flash-фигурки и улетающие цифры с затраченными очками силы и здоровья.
Это никуда не годится. Пусть игра будет простая, но персонаж в ней все-таки будет подвижен, будет бегать и перемещаться по локации, "видя" и взаимодействия с другими персонажами и нпс.
Это смелое решение накладывает на нас следующий большой блок работ. Если в случае с предложенным ранее вариантом, можно было просто отрисовать локации в Coral, задать jsom координаты "активных ссылок" на них и расположить поверх слои с интерактивными нпс и проч., то в случае с полноценным двухмерным миром игры работы будет на порядок больше. А именно, - в числе прочего, необходимо будет писать редактор мира, через который дизайнер сможет создавать игровые локации в которых и будет кипеть жизнь.
Путем многочасовых раздумий и рисования карандашом, представляю логику построения редактора двухмерного игрового мира для mmo.
Все оказалось не таким страшным, как представлялось ранее:
В основе визуальной части мира будет лежать база текстур (вода, суша, земля,..) и спрайтов (объекты, деревья, колодцы и проч.) доступных с интерфейса редактора.
Вторая базовая составляющая, - это сама локация, в данном случае, - четко ограниченный двухмерный блок (<div> в реализации редактора), имеющий четко определенное количество минимальных вложенных в него "точек" на карте в виде квадратных блоков. То есть получается своеобразная сетка координат, состоящая из ячеек, которые мы, как не сложно догадаться, "населяем" текстурами и спрайтами.
Хотя мир у нас будет двухмерный, некоторую реализацию трёхмерности нам в него ввести придется, если не в эстетичных, то в технических целях.
Карта будет трех-слойной. 1 Слой - "Земля". На нем будут размещены все спрайты и текстуры, раскрашивающие мир. 2 слой - "жилой". На нем не будет размещено ровным счетом ничего. Это будет технический слой, разграничивающий в системе координат "жилые области" от нежилых. Думаю не сложно догадаться, что в нем мы укажем области по которым смогут перемещаться игроки, (суша) а по которым не смогут (вода, скалы, и проч.). 3 слой оставим про запас. Пусть это будет "небо". На нем будем размещать некоторые "летающие" спрайты, а, возможно и игроков. Он будет охватывать всю локацию без ограниченных областей.
Вот собственно и все. Теперь перечислим базовые функции, который должен иметь редактор игровых локаций (пока только касательно отрисовки и формирования карты).
1. Блок с картой. Изначально пустая размеченная область фиксированного размера.
2. Интерфейсный блок со спрайтами,
3. Интерфейсный блок с текстурами,
4. Кнопка (или список, вид реализации пока не важна) для выбора слоя карты с которым работает дизайнер.
Возможности:
1. Перетаскивания элементов библиотек текстур и спрайтов на карту локации. Выделение областей на карте, содержащих неограниченное количество минимальных единиц площади (для заполнение текстурами больших областей).
2. Помимо ручного перетаскивания спрайтов на карту по 1, предусмотрим возможность выделения целой области локации и простановки опций автоматической расстановки спрайтов (растений, луж и т.п.). Дизайнер нам скажет за это спасибо.
3. Разумеется, возможность сохранения локации (о связях с другими локациями мира пока не думаем).
И что же мы получим на выходе. А на выходе карта локации сохраняется в самом обычном массиве, ключами в котором служат номера минимальных блоков на карте, а значениями, как не трудно догадаться, - помещенные в них текстуры и спрайты.
Пока не думаем о том, как оптимизировать решение: ведь на карте несколько слоев, а одна и та же текстура может охватывать большую площадь локации. Главное, что мы заложили теоретическую основу и стало понятно в общих чертах как будет будет организован игровой мир.
И так, разобравшись в общих чертах с созданием локаций, начнем расписывать главное: саму логику real-time mmorpg. Главное отличие этого типа игры заключается в том, что персонажи взаимодействуют "в живую" и игра не подобна шахматам, когда вы сделали ход и ожидаете хода соперника и только после него вы сможете продолжить игру. Соответственно, в массовых боевках с участием 10+ игроков вы можете ждать своего хода по пол-часа. Что это означает для разработчика с технической точки зрения и как обеспечить такую функциональность приложения?
Начнем рассматривать организацию "риалтайма" по модели MVC, начав с уровня данных.
На стороне данных, как мы решили у нас будет быстрая СУБД, поддерживающая индексы, временные таблицы и хранимые процедуры - PostrgreSQL/Mysql.
Учитывая наши цели, спроэцируем их на уровень данных, чтобы стали понятны задачи решаемые бд.
Мы имеем 2000 игроков онлайн. Для уровня данных это как минимум означает 2 вещи: большое количество операций (в основном - запись, удаление, апдейт) и большое количество соединений с бд. Учитывая этим моменты, примем решение о том, что при заходе в игру, она будет поддерживать постоянное соединение с сервером. Это дает серьезную нагрузку на сервер субд, но иное решение для риал-тайм игры будет стоить дороже.
Второй важный момент, - нам будет необходима очень большая скорость операций с таблицами бд. На этапе проектирования базы, мы максимально тщательно протестируем скорость чтобы спрогнозировать возможность поддержки нужного числа операций, структура будет максимально оптимизирована под большего число записей, удалений, апдейтов, для быстрого доступа к данным в таблицах будем использовать числовые индексы.
Для выполнения стандартных операций взаимодействия с бд, напишем хранимые процедуры, которые в нашем случае значительно ускорят все операции.
С теорий уровня данных вроде всё ясно.
Подумаем теперь, как с ним будет взаимодействовать приложение. Опишем взаимодействие в виде отдельных операций приложения с самого начала игры (опишу несколько фривольно, дабы было проще понять самому и разъяснить читающим сами принципы работы приложения. Так что пока - без уровня представления>логика>уровень данных...).
0. Игрок заходит в игру: обратились к бд, проверили логин, пароль, если совпали, отдали из бд локацию и координаты персонажа.
1. Передаем карту локации в клиент. Отображаем персонажа на карте... и сразу стоп! У нас мморпг, к тому же риал-тайм. Стало быть нам нужно отобразить и "двигать" всех персонажей вех игроков, находящихся в локации. Стало быть игра должна опрашивать сервер и выдавать координаты всех персонажей в локации скажем каждые 500 мс. (больше - уже не риалтайм).
Задачи - извлечь максимально быстро координаты персонажей, отдать максимально быстро, отобразить максимально быстро и не загнуться при обновлении каждые 500 мс.
Варианты решения задачи:
а). Данные храним в базе, все операции производятся уровнем логики и уровнем данных на стороне сервера. В браузер отдаем массив координат персонажей.
При заходе в игру и каждые 500 мс. аяксом активируем процедуру извлекающую данные по id локации, содержащие координаты всех персонажей в локации в виде массива. Уровень представления расставляет все фигурки по заданным координатам (анимацию пока не трогаем, поговорим о ней позже). + Не зависим от клиента, точно передадим ему данные. - Всю работу делает сервер бд.
б). Данные хранятся на сервере в виде XML-файлов. Мы также можем хранить данные о местоположении персонажей игроков в виде XML. Тут реализаций может быть масса. И мы передоверим часть работы компьютеру игрока. Мы можем хранить в бд лишь данные о конечной локации персонажа при выходе из игры. После захода в игру, берем с бд всего лишь локацию, и в соответствии с ней забираем аяксом нужный XML-файл. В нем, как не трудно догадаться, хранятся постоянно обновляемый список всех персонажей в локации и их координаты. JSом разбираем файл, отображаем персонажей на карте, проделывая процедуру регулярно. Возможно потом нам удастся оптимизировать и ускорить эти операции на стороне клиента через применения workers, webstorage/websql. + Весьма очевиден: мы не нагружаем бд, постоянно спрашивая "где я?" и "кто рядом?", ей и так придется работать на полную катушку, занимаясь другими вещами. - Тоже очевиден: мы, при всех усилиях ничего не знаем о компьютере клиента и передоверие этой части работы браузеру может сильно тормозить игру (особенно если игроков в локации много и файлик будет большем). В случае с "тормозами" при первом методе, игра будет одинаково медленно идти у всех игроков, а, в случае с независимым парсингом XML на стороне клиента, тормоза будут у каждого разные. - Ещё один минус. Если местоположение игрока определяется jsом, то, фактически браузер может передать xml любого содержания. И нужно будет проверять его средствами сервер на то, "не шагнул ли персонаж слишком далеко, или туда, куда нельзя". В случае с хранением координат в бд такого можно не делать. Процедура проверки будет в 2 этапа:
1. Сверяем координаты куда шагнул игрок с разрешенными на карте (карта лежит в бд).
2. Сверяем файл присланный клиентом с файлом-старой копии, хранящийся на сервере, на предмет того не затронуты ли ходом координаты других игроков. Также смотрим не шагнул ли игрок дальше, чем ему разрешено.
Тут буду рад выслушать комментарии, советы и любые идеи. Пока лично я считаю, что придется тестировать оба метода.
2. Допустим, зашел игрок в мир. Показали ему всех игроков в локации. Что дальше?
Дальше игрок нажимает кнопку чтобы передвинуть персонажа. JS смотрит в какую точку хочет переместиться персонаж:
Карты у нас хранятся на сервере. Когда персонаж входит в игру, мы передаем клиенту массив координат и сами текстуры и спрайты. Кэшированием картинок занимается уже сам браузер. (Подумать над тем? позволяют-ли нам существующие технологии при использовании JS хранить локации на стороне клиента! Почитать в сторону indexdb, webstorage, управления кэшированием).
Логика получает координаты куда хочет переместится персонаж, спрашивает у бд, можно-ли переместить туда персонажа (нет ли там непроходимого спрайта, или другого игрока)... . Стоп. А нужно-ли нам это действие? Нет, не нужно. Ведь мы получили карту локации при заходе в игру, мы получаем каждые 500мс. координаты всех персонажей в локации. Значит, -
а) смотрим можем ли переместить персонажа в заданную точку локации (нет-ли непроходимых текстур-спрайтов).
б) делаем стандартный запрос к бд или xml-файла у веб-сервера, после чего сверяем нет ли в точке, куда мы ходим другого персонажа (если есть, ... то подумаем потом что делать, если есть. Пока будем считать, что если есть - выводим меседж, что ход невозможен.)
в) Если "пусть свободен" - переставляем туда нашего персонажа: перезаписываем в бд новые координаты либо перезаписываем в xml файл строку с новыми координатами, после чего отправляем этот файл на сервер.
Для начала все. Мы описали теоретическую логику реализации "жизни" в мире игры, указав две возможные реализации "перемещения" персонажа по миру. Прошу комментировать, оценивать, уточнять и предлагать оптимальные варианты.
Покинул форум
Сообщений всего: 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, записываем координаты и характеристики персонажа в бд, закрываем сессию.
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Я однозначно остаюсь с EuGen'ом.
Кстати я начал пилить тестовый клиентский скрипт.
За основу взят голый JSON.
Никакой статичной хтмл-разметки, карту строит js на лету.
-----
Zuldek
Отправлено: 02 Марта, 2012 - 14:54:20
Постоянный участник
Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010
Помог: 50 раз(а)
DeepVarvar пишет:
Я однозначно остаюсь с EuGen'ом.
Кстати я начал пилить тестовый клиентский скрипт.
За основу взят голый JSON.
Никакой статичной хтмл-разметки, карту строит js на лету.
Это замечательно. Какую цель преследовал пост?
Panoptik
Отправлено: 02 Марта, 2012 - 15:02:12
Постоянный участник
Покинул форум
Сообщений всего: 2493
Дата рег-ции: Нояб. 2011 Откуда: Одесса, Украина
Помог: 131 раз(а)
у оффтопа нет цели. вы лучше не отвлекайтесь. продолжайте. интересно созерцать. а критика пока неуместна
-----
DelphinPRO
Отправлено: 02 Марта, 2012 - 15:08:20
Активный участник
Покинул форум
Сообщений всего: 7190
Дата рег-ции: Февр. 2012
Помог: 353 раз(а)
Ждем первых исходников Потом и критика будет, и возможно кто-то подтянется.
(Добавление)
Zuldek пишет:
Первое время разработка будет вестись прямо на форуме, без применения SVN, сред разработки и баг-трекеров, поскольку далеко не у всех начинающих разработчиков есть опыт работы с ними
Спорная позиция. Если проект твердо решено довести до логического завершения, лучше сразу заюзать svn. Тот же GIT не очень сложен в освоении, плюс репо на гитхабе, - там исходники удобно просматривать тем кто просто будет следит за разработкой.
-----
Zuldek
Отправлено: 02 Марта, 2012 - 15:20:38
Постоянный участник
Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010
Помог: 50 раз(а)
Пока разбираемся с логикой работы и архитектурой всего приложения. Разумеется, что когда работа выйдет за рамки написания базовых классов уровня бд, логики и визуала, все будет на gite.
Acmodeu
Отправлено: 04 Июля, 2012 - 21:26:22
Новичок
Покинул форум
Сообщений всего: 1
Дата рег-ции: Июль 2012
Помог: 0 раз(а)
Привет всем, очень увлекательный пост =) Уроки или же совместное написание браузерной игры с нуля.. Очень бы хотелось поучаствовать в данном эксперименте.. Ну и как всегда, все начинается с базы.. наверно с первой таблицы users )) Нужно определить какие ячейки нужны нашему персонажу - с выдуманным ником Davakin И написать авторизацию =))) Жду актива... И конечно же Zuldek
Zuldek
Отправлено: 10 Июля, 2012 - 12:27:10
Постоянный участник
Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010
Помог: 50 раз(а)
Хобби не заброшено.
Изучая клиентскую сторону разработки, наткнулся на интереснейший доклад
Мастлук всем кто интересуется вопросами разработки браузерных игр и любых приложений на HTML5 CSS3 JS (поможет выбрать сторону силы). Доклад на английском.
Покинул форум
Сообщений всего: 1
Дата рег-ции: Сент. 2012 Откуда: Россия, Москва
Помог: 0 раз(а)
Приветствую всех обитателей форума!
phpdocumentor поставил, с топиком ознакомился
Довольно масштабные мысли, я, к сожалению, не знаю всех тонкостей на столько, чтобы как-то однозначно и правильно комментировать все вышеизложенные мысли.
Единственный вопрос:
Цитата:
мы каждые 500 мс должны передать клиенту следующие данные:
1. Местоположение всех персонажей на карте
2. Местоположение всех монстров на карте
Может, лучше сделать некую "область видимости" персонажа? в зависимости от которой будут подгружаться те или иные объекты? Зачем нам знать кто сейчас бегает в другом конце карты, если мы туда не пойдем? Маршрут мобов можно задать заранее рандомно в некотором определенном радиусе и пересылать изначально только жив моб или нет. А при приближении персонажа к определенной точке, подгружать конкретные маршруты.
Может как-то можно структурировать всю накопленную информацию путем изменения 1го топика?
*ушел изучать доклад на английском, а также вопросы, связанные с шаблонами проектирования, PDO, MVC и все окололежащее*
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
Главная
Помощь
Поиск
Пользователи
Форумы портала PHP.SU » PHP » Уроки php » Обучение на основе реальных проектов
Описание: коллективный учебный проект.
(о связях с другими локациями мира пока не думаем).
. И так. Персонаж зашел в локацию. Нам нужно отдать ему координаты и действия всех объектов, которые "живы". Это понятно и не обсуждается. В дальнейшем же, Нам нет смысла в каждом ответе и запросе записывать все данные в один большой xml-файл: он может получится гигантских размеров. Поэтому, в определенном каталоге для сервера для данной локации, мы будем хранить отдельные события в локации также в формате xml. При запросе каждые 500 мс, сервер отдаст сформированный xml файл со всеми новыми события, действиями и объектами. То есть теперь мы будем спрашивать у сервера "что изменилось?" и он отдаст только новые события. То есть мы сделаем большой шаг в сторону оптимизации и уменьшения глюков, передавая с сервера только новые события. Клиент же вообще будет передавать на сервер только действия игрока, а не писать на сервер целый файл со всеми координатами, действиями и свойствами всех объектов. Если игрок стоит на месте, или на монстра никто не нападал, то клиент не перешлет серверу ничего, он лишь спросит: есть ли новые события. Сервер отдаст сформированный xml который будет содержать только изменившиеся координаты других персонажей (если не было других событий). Каждые 500 мс. на сервере будет выполнятся скрипт, собирающий все пришедшие событие в единый файл изменений, который и будет раздаваться всем клиентам. Просто, изящно и рационально и без дерганий БД. 
. Поставим в уме галочку, чтобы во время реализации уровня бд оптимизировали этот момент, получив быстрый доступ к массиву координат каждой локации по которому может бегать персонаж.
И написать авторизацию =))) Жду актива... И конечно же Zuldek
