Пока разбираемся с логикой работы и архитектурой всего приложения. Разумеется, что когда работа выйдет за рамки написания базовых классов уровня бд, логики и визуала, все будет на gite.
Я однозначно остаюсь с EuGen'ом.
Кстати я начал пилить тестовый клиентский скрипт.
За основу взят голый JSON.
Никакой статичной хтмл-разметки, карту строит js на лету.
Монстры и неигровые персонажи, изменение взаимодействия клиента и сервера
Ниже постараюсь обдумать и описать логику программирования монстров и неигровых персонажей. Как обычно, буду рад видеть мнения, советы и рекомендации.
Рассмотрев логику перемещения игроков в риал-тайм мире игры, переходим к остальной части его "населения", - монстрам и нипам. Задачи:
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, записываем координаты и характеристики персонажа в бд, закрываем сессию.
сложно правильно представить всю структуру приложения не видя её, поэтому, если не используйте системы типа netbeans, сделайте поиск grepom всех файлов от корневого каталога сайта содержащих текст per_page. Для начала потребуются они.
Не видя исходников это сделать сложно. Браузер тут не причем. Разве что в зависимости от настроек куков в браузере у вас в переменную $per_page пишется не нужное или не пишется.
Читайте о методах передачи данных GET и POST и смотрите примеры работы с ними. У вас каша в голове. Вы передаете данные одним методом, а в принимающем сценарии ищите полученные параметры в массиве совершенно другого метода.
В приведенном вами примере
из скрипта 1.php передастся скрипту 2.php методом GET переменная $id. она не будет равна нулю, если $row['id'] определена и не равна нулю.
Скрипт 2.php примет $id и запишет её в такую же переменную $id=$_GET['id'].
Затем он выведет и отправит пустую форму скрипту 3.php, при щелчке на кнопку "ок".
В этом же скрипте, при клике на ссылку <a href=3.php?id='.$id.'> скрипт передаст 3.php $id методом GET. Зачем при этом нужна форма, и кнопка её отправки включена в ссылку - не понятно.
Скрипт 3 ведет себя также, как 2.php, только данные он отправит в скрипт 1.php.
пропишите директиву RewriteBase в htaccess. / и убедитесь, что он в корне домена. И лучше ещё файл полностью покажите, потому что иначе долго можно играть в экстрасенсов.
if (isset($_GET['id'])){
echo 'GET_id = '.$id=$_GET['id'];
echo 'GET_other = '.$other=$_GET['other'];
echo '<hr>';
}
$q1="select * from forum where other='$id'";
Понятно, что зависит ширина пробела от размера шрифта и гарнитуры, но шрифт-то один для всех, значит и ширина пробела должна быть одинаковой
Почему вы так думаете? Я разработчик браузера. Я хочу чтобы ширина пробела между символами в тексте была такой-то, ширина пробела-символа html была такой-то. А ещё я хочу чтобы в настройках пользователь мог менять ширину отступа между словами, строками, да и сами шрифты. Что мне помешает так сделать? Для задач фиксированного отступа от элементов структуры HTML существуют такие параметры как margin, четко описанные в стандарте HTML. Пробелы же не используются для разметки страниц и их по-разному отображают не только браузеры но и разные операционные системы (особенно системные шрифты). Что мне помешает залить в мою сборку ОС файл шрифта Verdana, который будет на самом деле перерисованным мной Arialом?
вчера ему было не все равно. а сегодня все равно. как так может быть? он же не девушка
Экстрасенсы в отпуске.
Не можете понять почему не работает без отладчика - выведите в браузер значения всех переменных прежде чем они задействуются в любых операциях. Либо все исходники целиком в студию.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 2118
. Поставим в уме галочку, чтобы во время реализации уровня бд оптимизировали этот момент, получив быстрый доступ к массиву координат каждой локации по которому может бегать персонаж.
