|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
17.02.2013, 01:26 | #111 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
15.02.13 – День 215
Перепросчитал модель крысы. Так как у крысы всего 4 действия (бег, атака, получение урона и смерть) это заняло мало времени. |
17.02.2013, 01:27 | #112 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
16.02.13 – День 216
Собрал спрайт анимации крысы. |
21.02.2013, 01:58 | #113 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
20.02.13 – День 217
Просчитал анимацию робота Instructor. Получил на выходе 114 изображений – немногим меньше чем обычно. Это вызвано тем, что анимация у него более упрощённая. Ошибка просчёта, с которой я столкнулся ранее, была вызвана неправильно ставшими пакетами обновления системы. Из-за этой ошибки пришлось переустанавливать всю систему. |
23.02.2013, 01:28 | #114 |
Инженер ИС
Старожил
Регистрация: 13.12.2006
Сообщений: 2,671
|
А вот у этого робота "Instructor" на правой конечности знакомая вещица - типа наконечника палицы, ...ностальгические воспоминания об игре на 8-битной приставке "Чип и Дейл 2", финальный поединок с робо-котом, с вот таким шариком тоже на правой руке, и который он пуляет
Руководитель проекта MMO 2D RPG: Настоящее имя Денис Стрижак (10.05.1981-6.02.2019) Мир духу его
|
23.02.2013, 02:18 | #115 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
21.02.13 – День 218
Подготовил спрайт анимации робота Instructor. Анимация получилась, откровенно говоря, паршивая – робот бегает по полю боя как в ластах; ноги при стрельбе перемещаются; удар кулаком выглядит непонятно. Буду переделывать. |
23.02.2013, 02:21 | #116 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
22.02.13 – День 219
Подготовил изображения мастерской с роботом Instructor и крысой. Эти изображения необходимы для внутреннего использования – игроки вряд ли их увидят. Удалил из проекта устаревшую PHP-функцию ereg_replace. Также я добавил подсветку в строку отладки. Об этом я хочу рассказать подробнее, так как это может пригодиться PHP-программистам. Возможно, Вы заметили, что на некоторых изображениях из игры в левом нижнем углу находится небольшая строка «Страница сгенерирована за …. секунд». Это очень удобный способ профилирования работы проекта. Если я вижу в этой строке большие цифры или подпись есть ошибки, то я могу оперативно исправить обнаруженный недочёт скриптов. Для подсчёта времени выполнения скриптов я использую следующие две функции: PHP код:
PHP код:
Отдельно стоит объяснить момент с временем выполнения скриптов и скоростью работы проекта в целом. Если упрощённо говорить, то общая скорость проекта (средняя скорость отображения страницы) складывается из скорости передачи данных и скорости генерации ответа сервера. Скорость передачи сейчас практически равна скорости установки соединения. Поэтому можно смело сказать, что передача данных обычными http-запросами рано или поздно вымрет, и будет заменена web-socet-ами, где скорость соединения практически моментальная. Скорость генерации ответа сервера зависит в свою очередь от скорости обработки данных PHP-скриптом, скорости извлечения данных из базы, из фалов или из кэша. Как обычно, самыми тяжёлыми процедурами является установка соединения с базой и кэшем. При помощи unix-сокетов и кеширования в файлы можно уменьшить время этих процедур, но не более. То есть время этих процедур будет минимальным временем генерации ответа сервера и практически постоянным. Остальное время генерации ответа – это обработка данных интерпретатором PHP. В итоге получим простую формулу: Время отображения страницы = время соединения с сервером + (время извлечения данных из БД или кэша + время работы скрипта PHP)*количество запросов. Эта формула грубо упрощена, но даёт достаточно приближенный к реальности ответ. Теперь прикинем цифры. Для стандартного http-запроса среднее время соединения – 2 секунды. Среднее время извлечения данных из БД или кэша без сокетов – 0.003 секунды, с сокетами – 0.001 секунда и менее. Желательное время отображения страницы – 4 секунды. Путём нехитрых математических исчислений получаем другую формулу: (0.003 + время работы скрипта PHP)*(количество запросов за 4 сек.) = 2 сек. Количество запросов в секунду = 0.5 сек./ (0.003 + время работы скрипта PHP) Мы получили формулу зависимости количества запросов в секунду, которое может нормально обслужить сервер от времени работы скрипта. Зная среднее время выполнения скриптов можно узнать приемлемую нагрузку на сервер. |
23.02.2013, 02:21 | #117 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
22.02.13 – День 219. Продолжение
В моём случае среднее время работы скрипта вместе со временем обращения к базе примерно равно 0.02 секунды. Соответственно количество запросов в секунду для нормальной работы сервера равно 0.5/0.02 = 25. Для локального сервера на windows это даже не плохой вариант. В моей игре игрок делает запрос раз в 3 секунды, соответственно, сейчас комфортно одновременно могут участвовать 75 человек. На нормальном Unix-сервере можно спокойно достигнуть результата в 2 раза лучше. Конечно, расчёты приблизительны, но дают представление о реальных возможностях проекта. |
24.02.2013, 18:15 | #118 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
23.02.13 – День 220
Правил и отлаживал программный код режима тренировки. Встретил много проблем с просчётом поведения бота. Просчёт поведения бота происходит сразу же после просчёта хода предыдущего игрока. Это необходимо так как PHP - интерпретируемый ЯП (что в данном случае очень не удобно). Пользователю необходимо вернуть ответ, а после этого скрипт останавливается. Можно, конечно, использовать отложенный запуск скрипта, но это вызовет проблему конкурентной обработки, что ещё хуже. И так у нас действия бота просчитываются сразу после действий игрока в одном скрипте. Этого можно достичь только с помощью рекурсии, что очень сильно усложняет отладку. |
03.03.2013, 14:51 | #119 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
24.02.13 – День 221
Исправил все ошибки и зависания режима тренировки – теперь скрипты работают стабильно без зависаний (по крайне мере ошибок больше я не нашел). Конечно, анимационный движок требует проработки и организации нормальной очереди. «Научил» бота находить игрока и приближаться к нему с целью нанести удар. Почистил стили от устаревших конструкций наподобие префиксов и вызова css3pie. Проклянул Хром за его недоразвитость. |
03.03.2013, 14:52 | #120 |
Старожил
Регистрация: 19.04.2010
Сообщений: 2,702
|
02.03.13 – День 222
Произвёл большой рефракторинг кода. Во-первых, я удалил все упоминания коэффициентов урона и брони. Дело в том, что в самом начале я планировал создать простую игру с 4 уровнями развития игрока, в последствие от этого отказался. Эти 4 уровня были заложены в первоначальный код в виде коэффициентов брони и урона. Во-вторых, объединил на клиенте переменные ожидания хода, проигрывания анимации и запрета перехода хода в общий параметр control. По мере написания кода приходится вводить новые переменные для выполнения ряда функций. Очень часто эти функции смежные и мы получаем «мешанину» из одинаковых переменных. Если кода не много, то отслеживать такие зависимости легко. Но в моём случае модуль ведения боя разросся до 900 строк и разобраться в нём было не так просто. В-третьих, я выделил отдельную функцию построения пути перемещения. Ранее она была частью функции отображения возможного пути и перемещения игрока. В-четвёртых, я исправил функцию проигрывания ходов. Теперь благодаря callback-ам выполнение ходов выстраивается в очередь и анимация боя происходит именно так как надо у всех игроков. Пара слов об организации анимации действий игроков на поле боя. В браузерных играх используют 3 модели организации действий игроков: - Расчёт анимации действия и изменения параметров производиться на клиенте, а на сервер передаются только результаты. Такая модель потребляет меньше всего ресурсов, имеет простую реализацию, но является самой небезопасной, т.к. возможен взлом. - Пошаговое проигрывание анимации и изменение параметров согласно данным пришедшем с сервера. Это самая распространённая модель - она надёжна, нет проблем синхронизации, проста в реализации, но в то же время очень ресурсоёмка, т.к. запросов гораздо больше. - Поочередное проигрывание анимации и изменение параметров согласно массиву данных, пришедшему с сервера. В отличие от предыдущей модели обмен данными с сервером производиться не в случае отдельных событий, а «пачками» по несколько действий. Данная схема организации надёжна, не имеет проблем с синхронизацией, менее ресурсоёмкая, но более сложна в реализации, т.к. требуется механизм управления очередью. Как Вы могли догадаться, я избрал третью модель. Управлением очереди у меня занимается рекурсивная функция PlayTurn. При поступлении массива данных, она выполняет первую анимацию из массива, по окончании анимации рекурсивно вызывает саму себя для выполнения следующей анимации. Так рекурсивным вызовом она выполняет всю поступившую с сервера очередь. Так как функция анимации действия игрока представляет собой замыкание (иначе никак, т.к. требуется время на проигрывание анимации), организация очереди из этих замыканий является непростой задачей. Замыкание «живёт своей жизнью», запустив функцию-замыкание JS-интерпретатор переходит к следующей строке, не дожидаясь окончания выполнения функции. Поэтому для организации очереди, необходимо использовать callback-и функций-замыканий. Callback – действие выполняемое после выполнения функции. Возможность callback-ов задаётся «вручную» в коде функций. В итоге получается довольно сложная система из рекурсивных функций и замыканий. |
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Электронный дневник на Joomla | sashmedv | WordPress и другие CMS | 6 | 26.01.2012 12:53 |
Что нужно знать для разработчика игр. | 13th | Свободное общение | 38 | 14.01.2012 17:32 |
Дневник изучения С++ | Arcanis | Общие вопросы C/C++ | 2 | 26.05.2011 12:09 |
Дневник в Delphi | TaYgA | Помощь студентам | 18 | 12.10.2009 17:56 |