HTML5 Phaser ECMAScript 6

Часть 26: Закончена игровая сцена изучения слов

Мне очень хотелось показать вам полнофункциональную модель игровой сцены. С одной стороны, я сдержал слово и все, что у меня было запланировано я успел сделать. Но с другой стороны, я мог еще закончить сцену с результатами урока, у меня даже были целые сутки на это НО…

Вчера с утра начал по немного разгружать TODO лист других проектов. Планировал потратить на это не больше нескольких часов, но работа настолько затянула что за весь рабочий день (почти 12 часов) сделал только два перерыва на обед и ужин с просмотром фильма (приятно и полезно, смотрю Lost в оригинале). Даже статистика показала офигенный для меня результат 8 часов работы с продуктивностью 81%.

продуктивность одного рабочего дня

Игровую сцену мне удалось сделать без особых сложностей. В прошлом посте я писал, что данные должны должны храниться непосредственно в объектах сцены, а не в массивах, по этому несколько часов у меня ушло на очистку кода. Можете оценить результат. Количество слов в уроке я урезаю до 7, что бы ускорить тестирование:

Самое просто и в тоже время сложное это resize игры под размер экрана. Документация заведомо молчит и нет ни одного примера на официальном сайте. Может это совпадение, но в разделе магазина, есть маленькая книжечка которая очень быстро все разъясняет. Я не стал экономить и купил ее. Как оказалось, в моем варианте не хватало двух строк кода. Я обязательно в одном из последующих постов подробно расскажу вам, как это делается и поделюсь несколькими возможными примерами.

Один день я потратил на изучения способов создания аудио спраитов. Для этого есть утилита, но запускать ее в командной строке с списком файлом (в мое случае 1000) как-то не по профессионально. Позже я нашел готовый плагин, но он формировал пути в конечном json файле не совсем верно. По этому я его переписал. но впустую. Дело в том, что Phaser при считывании аудио спраита, игнорирует эти параметры json файла =) Об аудио спраитах можно написать отдельный пост, думаю тема актуальная не только для Phaser.

Имея аудио спраит, проигрывать нужное мне слово оказалось очень просто. Достаточно воспользоваться методом audioSprite.play(file_name). Но обратите внимание, используя аудио в игре, надо следить не за событием когда все ресурсы подгружены, а когда аудио декодировалось (на мобильном это может занять время).

Создание новых элементов интерфейса меня уже забавляет. К примеру, кнопку в правом нижнем углу «песочные часы», я сделал за 10-15 минут. Самым сложным оказалось привыкнуть к позиционировании элементов. Непривычно то, что при добавлении спраита в виде child-а уже существующему спраиту, координаты надо указывать относительно его левого верхнего угла, а вот при добавлении в группу, относительно координат самой сцены.

set icon_key(value) {
  var bounds = this.getLocalBounds();
  this.icon_sprite = new Phaser.Sprite(this.game, bounds.centerX, bounds.centerY, value, 0);
  this.icon_sprite.anchor.setTo(0.5);
  this.addChild(this.icon_sprite);
}

В данном случае this это «TimerButton extends Phaser.Sprite».

На этом мне придеться закончить. Как видите вас еще ожидает три интересных и полезных поста: как создавать атлас изображений, аудио спраиты и как реализовать resize под мобильные устройства. Кстати, в старых моделях android у Phaser и в целом у всех HTML5 игр серьезный визуальный глюк, позже я расскажу о нем и о решении.

6 thoughts on “Часть 26: Закончена игровая сцена изучения слов

  1. Круто получается, у меня настолько продуктивные дни были только когда я движок упрямо пилил вместо того, чтобы спать идти )

    Сам я эту неделю совсем пропустил.
    Отпускная неделя получилась, наверное уже созрел вернуться обратно к работе.

  2. Спасибо, похвала от такого опытного гейм мейкера это что-то! На счет продуктивности — вот как раз после этого дня, меня офлаин наказал и выбил на 3 дня в чистую. Так обидно было… вместо 9, закончил все к 15 числу.

    Элспер, мне сложно представить сколько у тебя там кода для анимации хомяка =) У меня тут простые окошки и передача некоторых данных, а у тебя хомяк находит склад, берет нужный товар, идет к столу (все кратчайшим путем), тут анимация как он садиться за него, потом работает и относит все назад на склад. Ты как логически такой сложный код разбиваешь? Что-то вроде way point-ов а пока хомяк двигается от одной к другому, у тебя включается определенная анимация?

  3. Ну не такой уж и опытный.
    И хомяки к тому же самая сложная игра. Сравнивать твою игру с хомяками не корректно.

    Всё что до хомяков тоже было простыми окошками, я обсуждая с женой их так и называю «интерфейсные игры» И твои «окошечки» выглядят не хуже тех игр, и однозначно лучше чем наша самая первая еще не мобильная игра. Проблема только в том, что это не совсем игра в чистом виде, но мы это уже обсудили 11 августа (я полистал комменты)

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

    Расчет пути имеет три варианта. Когда известен старт (место хомяка) и известен конец пути. — это один алгоритм.
    Когда известен старт но конечную точку надо найти. Это другой алгоритм.
    Ну и когда известно куда идти, но не известно кому идти. Это похоже на прошлый, но надо заложить возможность «перевернуть» построенный маршрут.

    В итоге просто идет обращение к функции построения пути. В параметрах помимо необходимых данных передается ключ, какой тип рассчета пути использовать. И на выходе хомяк и его точная позиция. Цель пути. И сам путь в виде массива последовательности шагов и действий (прямо, направо, взять предмет и т.д..)
    Далее отдельный независимый код обрабатывает действия каждого хомяка, изымая из массива (точнее используется массив массивов, верхний массив это сами хомяки, внутренний массив — действия конкретного хомяка) элемент каждые XXX миллисекунд и применяя его действие на соответствующего хомяка.

    В итоге код хоть и сложный. Но разделенный на подзадачи. И вся сложность ложится на реализацию конкретных подзадач, оставляя простой, и как следствие, понятной, саму суть — главную логику.

  4. Хомяки должны получится очень интересными, как с дизайнерской перспективы, так и геймплея (я люблю стратегии и логические головоломки). У меня самого проблемы с дизайнером. Точней тот, который рисовал красиво, занят… другая настоящий художник, но не умеет рисовать в векторе, а с кем я сейчас работают — у нее проблемы с цветами =) Я пока не заморачиваюсь, но игру однозначно отдам на графический тюнинг. Может потом кого посоветуешь.

    Мне очень хочется самому сделать что-то анимированное, но помню ты писал, что начиная с сложных игр, вы автоматом забиваете на проект. Пока у меня в планах либо кликер (хотя я в них не разбираюсь), либо очень старая головоломка (генератор карт и прототип я уже написал, но там надо много времени уделить самому вливанию игрока в процесс, что бы он понял что да как…). С головоломкой я сомневаюсь, что будет доход… другой контингент юзеров. Те кто умеют думать логически, на рекламу кликать не будут =) Или я ошибаюсь Элспер?

    Мне понравилось твой подход к решению задачи перемещения хомяка. Фактически функция генерирует инструкции в зависимости от задачи, а хомяк просто следует этим инструкциям последовательно. Надо будет запомнить… возможно пригодится. Очень давно думал сделать военную стратегию, но думаю тут очень много теории надо разбирать, особенно для интересного AI. А ты не думал или все планах?

    п.с. Сегодня закончил чистить код, осталась только главная сцена меню. Переделал некоторые компоненты, теперь они все наследуют один, в котором реализовано 90% всего кода, который идентичен для всех этих кнопок, счетчиков и т.д. Я только сейчас понял, что именно так и надо писать (надо будет не забыть в следующем посте об этом написать). Несколько часов ушло на отладку ошибок… не стоит писать игру с прямым обращением к графике, а потом менять на спраиты. С виду незначительное изменение кода, а на практике приходится много чего менять. Мне еще повезло, что я приспособил для интерфейса Tiled, без него было бы совсем сложно.

  5. «начиная с сложных игр, вы автоматом забиваете на проект.»
    Поясню, беря первой игрой сложную, вы во время ее разработки настолько сильно обучитесь, что начальное состояние игры станет несоответствовать вашему новому уровню навыка и игру придется переделывать иначе она просто начнет тормозить развитие навыков разработчика.
    Поэтому лучше сделать первый блин, заранее понимая что он будет комком, но он БУДЕТ СУЩЕСТВОВАТЬ. Пусть немного страшненький, но свой родной ))

    К слову и тебя тянет на переделки. Как минимум, насколько я помню, это не первая итерация игры, и вот тут «но игру однозначно отдам на графический тюнинг. »

    «Пока у меня в планах либо кликер (хотя я в них не разбираюсь)»
    Лучше конечно делать то, что сам хочешь играть, ну или как минимум понимаешь, в чем удовольствие игрока, поэтому если браться за кликер, то надо будет все же в несколько игр поиграть, а лучше вообще позависать, чтобы прочувствовать как и чем они держат игрока ))
    Еще кликер не сводится к собственно кликеру. Этот жанр связан с Idle. И лично я именно на idle делаю упор.

    Чтобы кликали на саму рекламу — об этом пусть рекламодатель парится.
    Разработчику игры нужно придумать (или найти) потребность, для удовлетворения которой игрок будет готов потратить несколько секунд на рекламу.
    Главная проблема логической игры (как я это вижу) это ее длина. Айдл можно играть несколько месяцев. Логическая игра обычно на несколько часов. Соответственно доход с игрока в обоих случаях может отличаться заметно.

    Что касается стратегий, я люблю экономические, а не военные стратегии. И хомяки, как раз и есть реализация плана по разработке экономической стратегии.

    Я кстати тоже менял подход к отрисовке графики, но доделывал старую игру по старому подходу, а с новым подходом делал уже следующую )

  6. Очень интересный оборот. Я меньше всего рассчитывал, что проблема будет в несоответствии игры уровню разработчика. Но после твоего пояснения, приму к сведению. На счет изменений — все пред. версии я запустил, вот только результата от них ноль, из за ошибок в проектировании. Не был знаком с правилами проектирования игры. Прочитав твой прошлогодний марафон, увидел подтверждение своим догадкам, а также избежал новых ошибок =) Мысли конечно проскальзывают, но я строго настрого запретил себе, что-то добавлять или менять пока не получу конечный результат.

    Вот к примеру у меня проблема куда добавить «силу» и как оформить. А что бы не стоять на месте… положу новый счетчик куда-то и простую форму с кнопкой запуска. Главное ведь получить логику: сила списалась, монетки добавились, силу купили в магазине. А как все это будет оформлено, это пока не актуально (надо научиться так думать).

    Элспер, под idle ты имеешь в виду игра которая идет пока пользователя в нем нет? Например ферма или травиан. Моя логическая игра по стилю похожа на судоку или пасьянс. Я предполагаю, что игрок будет ее играть постоянно, что бы скоротать время (собрать достижения, попасть в топ и т.д.). Но я все же думаю это не тот контингент, который кликнет на рекламе (а мне же за клики платят или все же за показы?) По этому и хочу все же кликер — что бы наверняка понять, причина в жанре или маркетинге.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *