Пишем HTML5-игру за 20 минут, или введение в Phaser framework
Эта статья посвящена разработке стильных, модных и молодежных HTML5 приложений с помощью нового фреймворка Phaser. В ней описан процесс установки библиотеки и создание классической игры Pong.
Введение
Установка библиотеки и локального веб-сервера
Итак, начнем. Для запуска и тестирования приложений нам необходимо установить локальный веб-сервер. Все примеры из комплекта библиотеки используют PHP, поэтому и сервер нужен соответствующий. Я использовал MAMP для MacOS, для Windows подойдет отечественный Denwer или любой другой аналог.
После установки веб-сервера необходимо скачать последнюю версию Фазера c GitHub: https://github.com/photonstorm/phaser. В данный момент (13 октября 2013 года) рекомендую качать dev ветку, так как эта версия содержит в себе ряд очень полезных изменений по сравнению с основной, в том числе и больший объем документации. Для тех, кто не использует GitHub, доступна прямая ссылка на архив: https://github.com/photonstorm/phaser/archive/dev.zip.
Чтобы убедиться, что все настроено правильно, можно запустить небольшое приложение-пример Hello Phaser. Создайте папку hellophaser в директории вашего веб-сервера, предназначенной для сайтов, и скопируйте туда три файла из папки Docs/Hello Phaser:
Запустите свой любимый браузер и откройте URL со скопированными файлами (в моем случае http://localhost:8888/hellophaser/). Если все хорошо, вы увидите вращающийся симпатичный логотип, такой как на скриншоте ниже:
Разработка игры
Подготовка необходимых файлов
Теперь можно приступать к разработке нашей первой игры. Создайте для нее папку phaser-pong на вашем веб-сервере и скопируйте туда файл phaser.js из папки build с исходниками фреймворка. Также создайте в ней папку assets, где мы будем хранить все ресурсы, относящиеся к игре, и файл index.html (собственно, здесь и будет наша игра).
Скопируйте в папку assets изображения шарика, ракетки и фона. Можно взять следующие файлы (в качестве фона я взял звездное небо из примеров Фазера), а можно нарисовать что-то свое. Главное — это убедиться, что вы загружаете в игру нужные картинки с корректными именами и подходящими размерами. Также не стоит выбирать слишком большие изображения, с их отрисовкой могут возникнуть проблемы. Поэтому перед использованием фотографии своего кота уменьшите ее до, скажем, 480х640 (разрешение нашей игры), и все будет хорошо. 
В результате содержимое папки phaser-pong будет таким:
А в папке assets будет три картинки:
Создание главного объекта игры, загрузка ресурсов
Наконец-то все подготовительные этапы выполнены, и начинается собственно разработка. Откройте index.html и вставьте туда следующий код:
Откройте в браузере адрес новой игры (у меня это http://localhost:8888/phaser-pong/) и вы увидите ее окно с нарисованным фоном
Что же происходит в написанном коде? Вначале мы импортируем библиотеку. Потом создаем объект типа Game , задавая разрешение нашего приложения, в данном случае ширину 480 и высоту 640 пикселей. Phaser.AUTO означает, что тип рендера будет выбираться автоматически. При желании можно задать Canvas или WebGL. Четвертый параметр задает родительский DOM-объект для игры, его мы не указываем.
В пятом параметре перечислены основные функции игры. preload() содержит код для загрузки ресурсов, create() — инициализацию игры, а update() — команды, выполняемые при обновлении приложения. На настольном компьютере update() вызывается примерно 60 раз в секунду. Именно эта функция будет содержать в себе основную игровую логику.
В функции create() мы добавляем статический спрайт с фоном нашей игры. Спрайт заполняет пространство, указанное в первых четырех параметрах tileSprite .
Игровые объекты
Сейчас перейдем к самому интересному — наполним нашу игру логикой. После объявления переменной game и перед функцией preload() объявим объекты с ракетками игрока и компьютера, мячиком, а также укажем скорости их движения:
Для создания ракеток напишем функцию createBet(x, y) :
Метод создает спрайт с указанными координатами и добавляет его в игру. Поле anchor отвечает за точку отсчета координат спрайта, устанавливаем его по центру изображения ракетки. body содержит в себе элементы для работы с физикой. Здесь мы ограничиваем движение ракетки пределами игрового пространства, задаем силу «отскока» и указываем, что при столкновении с объектами ракетка не будет отлетать в сторону.
Добавим два вызова этой функции в create(), сразу после создания фона. Ракетки будут добавлены в игру после фонового изображения, поэтому мы будем их видеть на экране:
Аналогичным образом создадим шарик, дописав следующий код сразу после вызовов функции createBet() в create() :
В результате увидим, что в нашей игре появились две ракетки и мячик, пока неподвижные:
Логика
Картинка получилась симпатичной, но думаю, стоит ее слегка оживить.
Добавляем переменную, отвечающую за состояние шарика и функцию, которая будет его запускать:
Функция проверяет, что шарик еще не запущен, и в таком случае задает ему скорость с помощью поля velocity.
Вызов функции повесим на нажатие кнопки мышки, написав следующую строку в create():
Теперь клик мышкой запускает шарик, и он отскакивает от границ игры. Добавим движения и ракеткам, отредактировав функцию update() :
Ракетка игрока следует за указателем мыши, ракетка компьютера — за шариком. Для ракетки игрока мы также добавили ограничение на максимальное и минимальное значение координаты x , чтобы она не пыталась выскочить за пределы игрового поля.
Вся суть игры заключается в отбивании шарика ракетками, поэтому нужно организовать проверку столкновений шарика с ракетками. К счастью, в Фазере уже есть соответствующий функционал, поэтому нам достаточно его использовать.
Допишем следующие три строки в конец update() :
Метод collide проверяет столкновение двух объектов (первые два параметра) и вызывает указанную в третьем функцию для выполнения каких-либо действий над столкнувшимися спрайтами. Эта функция выглядит так:
При столкновении шарик меняет направление своего движения в зависимости от того, на какую часть ракетки попадает.
Осталось только добавить проверку на пропущенный гол. Если кто-то его пропустил, ставим шарик в изначальную позицию по центру поля.
checkGoal() вызывается постоянно, поэтому копируем ее в конец update() :
Все! Открываем браузер, наслаждаемся фантастическим и современным геймплеем нашей игры, радуемся жизни и свежеприобретенным навыками программирования.
Заключение
Естественно, игре не хватает еще многого, как минимум подсчета очков и определения победителей. Но мне кажется, что для введения в разработку с Phaser достаточно показанных вещей. Движок поддерживает много других классных функций, которые я собираюсь показать на примере новой игры, чуть более сложной и непосредственно относящейся к Хабру, чтобы было интереснее.
Стей тьюнед.
В ходе разработки я активно использовал код из примера breakout.php. Кроме этого примера, в папке с Фазером есть и другие игры, поэтому тем, кому не терпится использовать новый фреймворк, рекомендую в первую очередь посмотреть на содержимое папки examples.
Update от 20.10.2013: fessnecro добавил частицы при столкновении шарика с ракетками и новые уровни, за что ему спасибо. Эти изменения находятся в основном бренче. Оригинальная версия, описанная в статье, находится в ветке gh-pages.
Источник статьи: http://habr.com/ru/post/197416/
Как создать простую игру на HTML5 за 5.5 минут
Немного инфы по игрострою смотрите тут!
Дубликаты не найдены
добавь тег javascript ,в html не бывает переменных и функций
Я конечно понимаю, что это просто демонстрация для рядового юзера, но руки за такие имена переменных и структуру хочется
«Как написать игру на js и не подать виду.»
Там еще до игры пилить и пилить, счёт, уровни, скорость, бонусы всякие, рекорды.
ТС где мой заказ про ПХП с Джанго?? 🙂
Как мы разрабатывали части персонажа. Персонаж : правдоподобие против удобства управления
Разработчики находятся в достаточно трудной ситуации. С одной стороны начальство требует дойную корову, которая стабильно работает как автомат калащникова и приносит денежку. C другой стороны таких дойных коров уже изобретено достаточно и в целом все они похожи друг на друга с точки зрения наличия новых уникальных механик и их развития.
На первый взгляд все кажется просто. Вот, на самом деле, почему нельзя просто создать какую-то новую механику, даже много новых механик и улучшать их пока они не устроят? Если что, неудачные механики можно выкинуть 🙂
Разработка игры с новой механикой — это примерно то же самое как работа над открытием или даже процесс поиска клада. Отлично, если вы опытный кладоискатель. Такие кладоискатели знают, что клад вряд ли спрятан в песочнице на детской площадке и не будут его там искать, тратить на это время. Потому что в свое время они уже наступали на эти грабли и ничего там не нашли. То есть существуют механики, которые заведомо неудачны / непригодны для игр. Конечно, все можно адаптировать, видоизменить, подогнать. Но все же существуют вещи которые не следует делать.
Вот рассмотрим очень простой пример такой механики на мобильной игре.
Допустим у нас есть персонаж в мобильной игре и наша задача управлять им. Мы видим персонажа сверху (2D). Как бы в сделали его управление?
Это очень щепетильный вопрос. Управление — это задача задач, которую решают в процессе разработки.
(1) Если вы будете приказывать персонажу идти за пальцем, когда он опущен на экран, то ваша рука будет перекрывать экран и вы будете смотреть на свою руку;
(2) А если персонаж будет идти в противоположную о пальца сторону, то будет ли удобно такое интвертирование управления?
(3) Если персонаж будет идти в точку, которую вы кликнули, то сможет ли он увернуться от летящей ракеты? Не перекроется ли экран рукой, когда вы смените направляение движения персонажа? Это управление точно удобно?
(4) А если просто. Джойстик и все тут! Не перекроет ли джойстик экран? Сколько экранного пространства он занимает (допустимо ли это)? Удобен ли он? Функционален? Позволяет ли он погрузиться в атмосферу игры?
Кто-то скажет: вот вы написали столько всего, так и управления не сделаешь, если все плохои все «неочень». Сделаешь, как раз это частично задача дизайнера интерфейсов, частично дизайнера, отвечающего за управление. Но больше, конечно, задача дизайна управления.
Да, вот такими задачами и занимаются дизайнеры: сделай то, не знаю что, пойди туда, не знаю куда и чтобы все было круто и никак иначе.
Оптыный дизайнер (опытный кладоискатель) способен быстро оценить все «за» и «против» каждого из пунктов 4. Новичок же, очень вероятно, будет экспериментировать и постигать тайны управления с нуля 🙂
Надеюсь теперь стало очевидней, что разработка новой механики — это работа.
Это работа и она не всегда увенчивается успехом. Не всегда даже опытному дизайнеру удается создать новую механику. И это часто зависит не только от дизайнера, но и от команды, от возможностей платформы для которой все разрабатывается.
Дизайнер создает тех. задание, отдает ее на реализацию дизайнерам и программистам, через какое-то время получает результат. Если результат устраивает, то это успех. Если результат не устраивает, то процесс повторяется до того момента, пока инвестору все это не надоест или пока команда не замучается «пробовать». Да, людям не нравится работать, а потом выкидывать свою работу. Особенно, когда ты старательно работаешь и не один месяц. Да, ты получаешь зарплату, но где удовлетворение от проделанной работы? Так и свихнуться недолго, если каждый день все рабочее время выкапываешь, а потом закапываешь выкопанную яму.
Вот потому-то все и идут на ухищрения. Зачем пидумывать что-то новое, когда старое хорошо работает? Возможно нужно немного изменить старое и все будет хорошо?
То, что я написал, касается многих вещей. Не только core-механики. Другие вещи могут быть подвержены этому.
В процессе работы над персонажем всплыло множество моментов, которые требовали такой хорошей и основательной проработки как со стороны дизайнера-программиста, так и со стороны дизайнера по механикам.
В процессе разаработки, было принято решение показыват игроку тело персонажа, чтобы он мог видеть себя своими глазами. Почему нет? Это добавляет атмосферы, смотрится круто.
Мы все фанаты крутого графона и в 21-м веке неприемлимо, когда твоя голова, руки, ноги или пушка влазят в полы или стену или еще куда-то. Нужно было это учесть.
С другой стороны, если персонаж стоит одной ногой на выступе обрыва, то все его тело должно как-то отреагировать на то, что вторая нога в воздухе. А если центр тела персонажа смещен в сторону обрыва, то тут уж 100% нужно это как-то отобразить на персонаже.
Мы справились с этой задачей, сбоку это выглядит так (скрины специально не содержат текстур, дабы не наспойлерить):
По части влияния смещения тела на механику движения: удалось добиться стабильности и минимизировать влияние анимации ног на перемещение игрока.
Ноги опускаются процедурно. Пришлось водключить инверсную кинематику и совместить ее с процедурной анимацией движения всего персонажа. О том как мы анимировали персонажа можно ознакомиться здесь: Процедурная анимация движения персонажа
Получилось весьма недурно 🙂
C руками, как и со всем остальным, отдельная история. И она длинная.
Что требуется от рук? Чтобы они не пересекали стены, чтобы держали пушку. И чтобы это все выглядело нормально. Бывшый мой босс всегда ставил задачу примерно так. Он перечислял все требования до мельчайших и в конце добавлял: «И да, сделайте все это так, чтобы выглядело круто. Просто сделайте так, чтобы все было круто и не заставляйте меня говорить что получился отстой.»
Руки персонажа эволюционировали и прошли очень долгий путь развития. Сперва мы работали над встроенной в руку «спец.пушкой». Всячески безуспешно пытались совместить то, что совместить трудно, да и нужно ли совмещать: руку + пушку + возможность изменения рукой гравитационного поля. Вот пара каких-то ранних скетчей «спец.пушки»:
Источник статьи: http://pikabu.ru/story/kak_sozdat_prostuyu_igru_na_html5_za_55_minut_3899725