New Zombotron. Неделя #4
На этой неделе мне наконец предстояло собрать первый небольшой тестовый уровень и приступить непосредственно к разработке игрового движка.
Про подготовку графических ресурсов для игры я написал немного в прошлой записи, и та неделя была как раз отправной точкой к цели создать первый тестовый уровень.
Первый уровень для тестов
Собрать тестовый уровень не составило большого труда, ведь, основываясь на опыте создания уровней для предыдущих частей Зомботрона, я уже примерно знал, как выстроить игровую иерархию.
Но тут меня поджидала одна небольшая проблемка: по умолчанию все игровые (визуальные) объекты имеют совершенно одинаковый слой и индекс сортировки (глубину), что говорит лишь об одном: совершенно непонятно какой объект выше, а какой объект ниже. Конечно, нет никакого труда задавать каждому новому объекту свой слой и индекс глубины, но а если объектов много и добавляются они на сцену хаотично?
Сразу скажу, что мне в целом нравился подход к сортировке объектов в глубину во Flash IDE: какой объект был последний добавлен, тот и выше (ближе к камере), а значит перекрывает все остальные объекты. А если нужно поменять его глубину, то мы можем изменять его глубину используя следующие пункты из контекстного меню.
В общем, не долго думая, я решил, что мне просто нужно расширить редактор Unity и добавить похожий функционал для выравнивания объектов по глубине в Unity.
Покопавшись немного в документации, я достаточно быстро реализовал то, что нужно и получил меню как на картинке в Unity редакторе. Правда я так и не понял, почему горячие клавиши отображаются неправильно, но зато работают они именно так, как я настроил — как во Flash IDE.
Поработав с этим функционалом, стало быстро понятно, что он все равно не решает всех моих задач и по прежнему есть некоторые неудобства. Неудобства возникли конечно, же в основном из-за того, что я добавил в игру немного изометрии, причем не только для пола, но и для всех объектов. Поэтому они должны теперь находиться в строгой последовательности по глубине, чтобы корректно перекрывать друг-друга. В старых играх необходимости в этом не было, так как уровень был в целом плоский, и если какие-то объекты перекрывали друг друга, то это не создавало визуальных проблем.
В итоге, я решил, что следует написать еще один небольшой скрипт сортировки, который будет привязываться к каждому слою и сортировать все вложенные объекты, согласно своим настройкам.
Алгоритм сортировки очень простой. Sort Kind — определяет по каким осям сортировать Vertical (Y), Horizontal (X) или Both (X и Y), Sort Order — порядок сортировки. Sorting Layer — это стандартный сортировочный слой, который будет применен ко всем вложенным объектам. Ну и действия, применить изменения или сбросить их.
В общем, хоть и потратил на всю эту суету почти целый рабочий день, зато результатом остался очень доволен. Теперь можно накидать на условный слой различных объектов, выставить их как нужно и всего-лишь одним кликом привести весь визуальный беспорядок в нужный порядок. А где автоматическая сортировка отработала неправильно (сортируются только по осям, а размеры объектов не учитываются) — там можно уже ручками быстро подправить, используя предыдущий скрипт.
?гровой движок
Первый уровень собран, персонаж криво-косо, но бегает, теперь самое время приступить непосредственно к организации игрового движка.
Скажу честно: подход, который предлагает Unity для создания игр, а именно прикрепление скриптов с игровой логикой к отдельными игровым объектами — это очень плохой путь! Этот подход очень хорошо работает для каких-то маленьких проектов и для обучения, но когда речь заходит о сложной игре — все это в итоге может привести к ужасному результату, где один невинный баг может убить игру, и сыскать его будет не просто. К тому же мне уже довелось сделать две игры с использованием компонентной архитектуры и я остался очень доволен результатом — что касается игровой логики, то работает все более, чем безупречно. Так же,очень легко добавлять какой-то новый функционал или удалять старый, потому что все очень аккуратно разделено. А стандартный подход Unity — это равносильно коду в кадрах (как во Flash).
В общем, передо мной встала задача найти хороший компонентный движок, который должен стать надежным сердцем игры. ? тут мне конечно же подкинули весьма раскрученный Entitas, а второй Unity-Ash — я уже сам нашел в надежде, что это порт оригинального движка.
Entitas
Впечатлившись крутым видео-обзором Entitas, я решил попробовать его в первую очередь. В обзоре все очень круто и судя по всему — это именно то, что мне нужно! Я радостно скачал библиотеку и пару демок, но почему-то у меня не заработало все с первого раза и пришлось лазить по исходникам движка и исправлять некоторые ошибки (дописывать не существующие методы) — возможно, что моя версия Unity просто устарела. Но, когда у меня наконец все заработало, счастья моему не было предела! Все круто отображается, можно посмотреть кучу отладочной информации, пощупать компоненты объектов и изменять им значения на лету во время выполнения программы — ощущения как-будто после деревянной машинки мне дали настоящий космический корабль!
Далее я потратил пол дня, чтобы разобраться, как он устроен и как я могу его использовать. Не буду вдаваться в подробности, но изначально конечно любой компонентный движок взрывает мозг тем, что с наскоку совершенно не понятно, как оно работает — словно магия какая-то. В Entitas было много загадок для меня ровно до тех пор пока я не понял, что часть файлов необходимых для работы, он генерирует автоматически. ? когда я наконец залез в эти файлы, все встало на свои места. Это конечно прикольно, что классы-ноды создаются автоматом, но не всегда удобно после изменения пары свойств в компонентах генерировать все ноды снова. Ну ладно. Оставался последний вопрос: как конструировать объекты из компонентов и сохранять их префабами, чтобы потом собирать из этих объектов, например, игровые уровни?!
Ребята, вот тут меня ждало эпическое разочарование! Я вначале не поверил своим глазам и даже пошел к мудрецу Гуглу за ответом. Но в итоге все совершенно очевидно: с Entitas в Unity никак не создать GameObject с компонентами и не сохранить префабом. То есть Entitas решает какие-то крутые задачи легко и просто, но при этом Unity вместе со своим редактором, как хрустальная карета превращается в тыкву! Нет, Unity используется конечно для компиляции и визаулизации всего, что творится в Entitas, но сам редактор при этом становится не нужен на этапе разработки. То есть, выходит так, что для Entitas мне как бы нужно писать свой редактор объектов (или конструировать их в коде), а так же писать свой редактор уровней. Да ладно!? O_o
В общем, космический корабль полетел в корзину. А я, уже не питая особых надежд, начал смотреть Unity-Ash.
Unity-Ash
Не смотря на то, что скачанный Unity-Ash не оказался портом Ash, а каким-то другим движком вдохновленным идеей Ash (что-то вроде моей упрощенной поделки, которую я сделал для Anthill на базе Ash) — он меня сразу приятно удивил и подал надежду.
Конечно же в случае с этим движком, прежде чем разбираться как он работает, я начал смотреть имеет ли он нужный мне функционал. ?… О, святые хомяки! Это то, что нужно! Оказалось, что в этом движке компоненты реализованы так, как я себе и представлял изначально: мы создаем GameObject и привязываем к нему свои скрипты-дата-компоненты сохраняем как префабы, а потом спокойненько работаем с этими объектами и их компонентами через системы. Хоть это и не такой космический корабль как Entitas, но идея верная, соответствует идеологии Unity и позволяет работать с редактором.
Но все же проблема одна нашлась: Unity-Ash хоть и позволяет конструировать объекты из компонентов в Unity редакторе, но при этом сцену игнорирует. То есть, если я создам разные префабы с нужными компонентами и потом их красиво расставлю на сцене, то движок о них никогда не узнает. Заглянув в исходники, стало очевидно, что объекты со сцены нужно просто ручками добавить в движок, но когда я попытался это сделать — высыпалась куча ошибок, которые как бы намекали мне, что автор явно не предполагал использования такого подхода. Что делать?!
Мне повезло, я уже имел опыт переписывания Ash под свои нужды и в целом знаю, как он устроен и как работает, и все те отличия, что меня поджидали в C# версии — это другой подход и стандарты самого языка. В общем, на следующий день, засучив рукава я взялся переписывать Unity-Ash с целью реализовать: наличие объектов префабов с компонентами, которые могут быть расставлены как угодно на сцене, и чтобы при запуске приложения они все подцеплялись и корректно обрабатывались движком. ? так, через пару дней появился новый и очень маленький движок «Cucumber» основанный на идеи Ash :D
Cucumber!?
Нуу… не муравейником же мне называть свой очередной велосипед, верно? Долго над названием не думал, просто нужно было быстро-что-то сообразить, ну и когда размышлял об архитектуре Ash движка, мне почему-то огурец привиделся с его упорядоченными косточками. А еще я люблю огурцы!
Забегая вперед скажу сразу, что не знаю, что будет с этой поделкой и буду ли я его выкладывать в общей доступ. Реализация на текущем этапе очень сырая, следует еще пересмотреть многие вещи в архитектуре и подойти к процессу оптимизации кода более внимательно. Но все же, кроме базовой компонентной архитектуры я еще реализовал систему для пула объектов и спортировал свой любимый AntMath.as :)
В общем, хочу я этого или нет, а велосипед так или иначе рождается. Но все же, в первую очередь я сосредоточен именно на игре и не занимаюсь проработкой движка, да и в C# я все еще новичок, хотя с каждой неделей чувствую себя все увереннее в нем.
Планы на следующую неделю
Ну что-ж, хоть работы за эту неделю и было проделано много и разной, но в плане скриншотов мне особо похвастаться нечем. Но зато, наконец-то многие базовые вопросы решены, и теперь самое время переходить к первым строкам кода именно для игрового движка. Да, ранее я уже показывал гифки с перемещением героя — но это всего-лишь пара скриптов, где один скрипт отвечает за управление, а другой за анимации персонажа. А надо создавать настоящий игровой мир, где все будет правильно взаимодействовать друг с другом.
(Так выглядит собранный уровень в игре: кликните для полного масштаба)
? так, планы на следующую неделю: переписать весь код под компонентную архитектуру, добавить звуки, реализовать стрельбу и начать разбираться с эффектами.
PS: Признаюсь, тему про освещение в игре я немного упустил по той причине, что с освещением я начал играться с самого начала и много экспериментировал с этим. В итоге работа над светом постепенно проходила в течении всех этих недель и все еще не является законченной не смотря на то, что уже есть красивые скриншоты. Про свет в игре я расскажу в будущих записях.
[26 Марта]
Хорошо, что дело движется)
Крутота :). А когда нибудь можно будет посмотреть Cucumber?
Тоже когда начал изучать Юнити не мог отделаться от чувства дежавю. Ведь начинал я с Macromedia Flash Professional, а там скриптики в кадрах и на объектах пишутся). А тут 2016 год а всё тоже самое почти) + Всё равно мне нужно было использовать тайловый редактор карт.
В итоге, решил что Юнька для моей 2д игры - затея тухлая, тем более что игра не очень масштабная, и сейчас пишу игру на Старлинге.
Кстати, Антон, как тебе физика что встроена в Юнити? По мне так лучше уж бокс2д, а ещё лучше нейп.
Только это все же фреймворк, а не движок. Движок в широком смысле это по прежнему Юнити, и всю кухню делает он - весь игровой цикл, с физикой, событиями, отрисовкой графики, звуками и всем остальным. А эти фреймворки и будущий огурец лишь организуют сущности в пулы и контроллеры, управляемые из кода.
@ant.karlov You still do not have an exact date of when the game will be released?
Здравствуйте Антон, заметил в анимации выше, вы соединяете спрайты на глаз, выберете тексту зажмите кнопку v выберите угол у спрайта который хотите соединить и перетаскивайте спрайт к другому спрайту. Надеюсь был полезен )
Кстати, Антон, а ты не думал попросить Александра записать для своего проекта звуки окружающей среды? По моему, это то чего Zombotron-у очень сильно не хватает.
Антон, ты садист! Столько слов про ентити, а статей по этой теме так и не выложил!
@Неважно спасибо за tip!)
не хочу показаться глупым, но что такое игровой движок?
Антон, можешь поделиться своим скриптом для z-ордеринга?
Я недавно перепрошёл все старые части и знаете? Серьёзно не хватало фоновой анимации(там бабочки летают, или зомби кого хавают, а может пауки бегают) . На фон в битве мало кто обращает внимание, но в начале, когда заварушка ещё далека даже от разогрева, смотреть было бы приятно.
@WeslomPo, когда я немного наберусь опыта с C# и сделаю третью версию Cucumber переписав его раз 5 — тогда можно будет, да! :)
@Danilos,
> Всё равно мне нужно было использовать тайловый редактор карт.
Мне кажется, что реализовать в Unity тайловый редактор — это просто. Но если не хочется заморачиваться, то конечно лучше взять новое решение. В ближайших обновлениях Unity обещают встроенные 2д тайловый редактор (где-то видел видео-презентацию с весьма интересным набором плюшек для 2D в будущих версиях Unity).
> Кстати, Антон, как тебе физика что встроена в Юнити? По мне так лучше уж бокс2д, а ещё лучше нейп.
Если честно, то физика как физика — ничего особенного. Удобно настраивать её сразу в редакторе Unity. В остальном же на Box2D похоже. Конечно Box2D роднее и ближе, т.к. столько лет только с ним и работал. Но прям каких-то особенных ощущений по этому поводу пока нет. Все точно так же приходится твикать и настраивать, чтобы физика работала как мне нравится :)
@Латентный Суперразработчик,
> Только это все же фреймворк, а не движок.
Да, вы правы. Спасибо что поправили! :)
@alonso ovalle,
> You still do not have an exact date of when the game will be released?
Not yet. Sorry.
When I will know about release date I`ll let you know! :)
@Неважно, спасибо за хинт, обязательно попробую в деле! Правда в моем случае спрайты идут немного в нахлест, так как графика нарисована немного в изометрической проекции.
@Marauder,
> Кстати, Антон, а ты не думал попросить Александра записать для своего проекта звуки окружающей среды?
Мы такие вещи еще толком не обсуждали. Но факт, что в новой игре звук будет в разы богаче за счет большего количества вариаций, а так же звучание звуков будет зависеть от окружения — все это будет благодаря убранным рамкам в виде ограничения размеров на проект, а так же широким возможностям работы со звуком в Unity.
@Ко-ко-ко!
> Столько слов про ентити, а статей по этой теме так и не выложил!
Еще не закончил их. Это действительно большой и сложный материал который весьма не просто донести простым языком. Выложу когда все статьи из серии будут готовы. В общем, работаю над этим ;)
@игрок,
> не хочу показаться глупым, но что такое игровой движок?
?гровой движок — это та часть кода в программе которая отвечает в основном за игровую логику, правила и т.п. То есть, это фактически игровой код который оживляет игру и делает её уникальной — это сердце каждой игры.
@Кто-то-там,
> Серьёзно не хватало фоновой анимации(там бабочки летают, или зомби кого хавают, а может пауки бегают)
Да, в целом согласен. Порой даже просто небольшой анимации окружения не хватало, в виде покачивания травы или что-то вроде этого. Но все это было невозможно сделать из-за ограничений которые накладывались Flash платформой. В новой игре планирую больше внимания уделить подобным деталям.
А когда примерно выйдет игра?
> Кстати, Антон, как тебе физика что встроена в Юнити? По мне так лучше уж бокс2д, а ещё лучше нейп.
Лол, а ничего, что 2д физика в Юнити основана на бокс2д?
Антон, как всегда - интереснейшая статья, спасибо! Подскажи пожалуйста (возможно я где-то невнимательно прочёл): выше есть скриншот с объектами сцены и там, среди прочего, есть объект с именем Render, какова его роль?
@Ant.Karlov
Не надо простым языком про ентити. Есть вероятность не вместить важную информацию в такой формат. Лучше уж по хардкору, техническим языком. =)
PS Дневники это тоже хорошо, очень интересно читать. Было бы здорово если бы в заключтельной статье было личное мнение о них. Помогают они разработке или скорее мешают?
@Сергей,
> А когда примерно выйдет игра?
Не знаю. Пока еще ранняя стадия разработки. Следите за обновлениями! :)
@Ололош,
> Лол, а ничего, что 2д физика в Юнити основана на бокс2д?
Кстати, я тоже об этом слышал, но мне показалось что это слухи. Вроде как Box2D уже устоявшийся движок с определенным функционалом, а в Unity от версии к версии в 2D физике еще что-то меняется.
@Владимир,
> объект с именем Render, какова его роль?
Это что-то вроде папки для объектов которые отвечают или влияют на Render картинки. Пока там только одна основная камера (Main Camera). Позже, возможно, появится еще одна камера для GUI и может быть еще какие-то вещи.
@Denis,
> Было бы здорово если бы в заключтельной статье было личное мнение о них. Помогают они разработке или скорее мешают?
На основе многолетнего опыта ведения блога, могу сказать, что ведение дневника (блога) мешает только тем, что порой отнимает чуть больше времени чем ожидаешь. А в остальном только польза:
1. Само-контроль (отчетность).
2. Общение, получение советов и критики.
3. Мотивация (иногда демотивация).
4. Привлечения внимания к игре на раннем этапе разработки, как следствие организация сообщества вокруг игры и т.п.
Самое сложное — это начать вести дневник и сделать это привычкой. Мне пока сложно дается и я не укладываюсь в еженедельный график из-за того, что технология новая и почти 50% времени пока тратится на изучение непосредственно технологии, а не на работу над контентом. Поэтому писать получается не так много как хотелось бы и не так интересно (информация в основном техническая мало имеющая отношения непосредственно к игре).
Но, вообще, я думаю, что польза от ведения дневника разработки строго индивидуальна — нужно пробовать! :)
Что скажешь по поводу havok?
мне кажется зомботрон будет лучшей флеш-игрой 2016 года
Еееееееееееее!!!!!я оставил свой первый коммент на этом сайте ееееее
@Gamaz
> Что скажешь по поводу havok?
Ничего не могу сказать. Никогда не пробовал :) Знаю только, что это аппаратная физика и раньше нужно было отдельную карту под это дело, но потом чип для расчета Havok физики стали встраивать прямо в видео карты. Но, поскольку к этому времени я уже перешел на Mac — я перестал следить за этой темой и сейчас мало чего знаю (может даже где-то ошибся в тексте выше).
@поклонник,
> мне кажется зомботрон будет лучшей флеш-игрой 2016 года
Новая игра разрабатывается уже на Unity и на выходе должна получится полноценная игра устанавливаемая на компьютер. Веб версии не будет.
Замечательно игра внешне выглядит. Тоже перешел на юнити, и удивился,что со слои/порядок, нельзя менять, как в флеше. Можешь показать код скрипта по работе с порядком спрайтов? Мне нужно только клавишами менять слой вручную. Ранее не писал скрипты для редактора Юнити.
Где найти музыку из ваших игр?зашел на сайт Александра Ахуры-там ничего нет:(
Захожу с телефона если что
re Info: Можешь показать код скрипта по работе с порядком спрайтов? Мне нужно только клавишами менять слой вручную. Ранее не писал скрипты для редактора Юнити.
Да, возможно Антон с радостью поделится с вами своим кодом, но меня возмутила ваша просьба. Почему кто-то должен вам выдавать свои наработки? Да, код того, что вы просите не сложный и в нём нет какого-то секрета, но может есть смысл попробовать самому написать его, хотя бы попытаться? Не?
@Info, хорошо, подготовлю скрипт для публикации.
@dinoZ,
> Где найти музыку из ваших игр?
Музыку можно найти на zombotron.com, так же не так давно выкладывали саунтрэк из FireCatcher как есть в FB.
@dinoZ
Насчет музыки отвечу от первоисточника так сказать )
Во флеш играх из-за ограничений объема приходится умеренно использовать музыку, так как веса она прибавляет порядочно.
Достигается эта умеренность либо малым количеством треков, либо короткой длительностью их.
В процессе игры это может не замечаться ибо внимание отвлекает множество других факторов. Но по отдельности 30 секунд музыки годится только для портфолио, а не для комфортного прослушивания.
The Planet Zombotron не совсем саундтрек. Это компиляция из материалов по первой и второй части, причем некоторые не были использованы в игре, а кое-что дописано позже.
Что касается саундтрека из других игр. Опыт с публикацией саундтрека Fire Catcher я считаю неудачным. Потому что там как раз та особенность, о которой я писал выше (флеш игра, ограничения по длительности).
В итоге. Саундтреки из флеш игр я буду выкладывать только частично, для портфолио, как ознакомительный вариант. А что касается нового зомботрона, то об этом еще совсем рано говорить.
спасибо за ответ:-)
>>но меня возмутила ваша просьба. Почему кто-то >>должен вам выдавать свои наработки?
>>но может есть смысл попробовать самому >>написать его, хотя бы попытаться? Не?
Сейчас такое время, что нужно быстрее делать проекты, пока их покупают и мировая экономика еще жива, поэтому стараюсь не терять время на допилку юнити или покупаю ассеты или беру код с инета/знакомых/сообществ и пр.
Более того, вы видимо не программист, потому как сообщество программистов, на форуме/чате и пр спокойно делятся наработками, а уж по запросу и подавно. Я всегда делился своим кодом без проблем, по тому или иному функционалу/вопросу, т.к. отдельный функционал это не свой движок в целом, который и кормит.
Если у автора имеются какие-то свои планы или интересы, то автор просто скажет, по таким то причинам нет возможности поделиться кодом.
>>написать его, хотя бы попытаться? Не?
- Поэтому да, даже пробовать пытаться сейчас не буду, т.к. в данный момент не критично, но хотелось в будущем иметь такой функционал, если в будущем будет время, то напишу сам, там ничего сложного.
К слову, поэтому русских и имеют все и их ресурсы, потому как сейчас русские (сам русский) - это поколение РАЗОБЩЕННЫХ дегенератов. Много веков вас учат, учат, а вы все уроки не внимаете. Пора уже умнеть.
>>@Info, хорошо, подготовлю скрипт для публикации.
Возможно, лучше тогда оформить свой код и выложить его платным в юнити ассет сторе, т.к. функционал вполне может быть востребованным, в таком случае делиться им не стоит, во всяком случае полным функционалом. По опыту покупая ассеты/плагины в ассет сторе к юнити, самые стоящие, не игрушки имеют корни, когда разработчику самому чего то не хватало, он реализовал для себя и это вылилось в коммерческий продукт.
Кстати, когда начинал работать с юнити, до меня долго не могло дойти, как с юинити вообще можно работать без стороннего платного плагина Prefab Evolution. Саму проблему, которую великолепно решает данный плагин описал Джонни-К в своей статье про юнити: http://eugenekuzmin.ru/2015/01/06/4821/ Раздел в статье: Префабы
Экономит просто уйму времени.
Антон, обрати на эту проблему свое внимание:
А по поводу работы со спрайтами (Sprite) в юнити, то если не использовать плагины (по своим причинам) NGUI, 2D Toolkit, то по функционалу крайне не хватает: 1. Перемещение спрайта попиксельно стрелками на клавиатуре 2. Попиксельных и пообъектных привязок при перемещении (как это сделано для UI функционала). 3. В некоторых моментах недостатки с групповой работой спрайтов. 4.Ну и вышеприведенная работа со слоями. Т.е. все эти пункты приближают работу со спрайтом в юнити к работе в FlashIDE, Фотошопу.
Поэтому, когда будет время, это все-равно придется самому делать для следующих проектов, чтобы комфортно было работать, также, как в FlashIDE.
@info,
> Возможно, лучше тогда оформить свой код и выложить его платным в юнити ассет сторе
Там слишком простой скрипт и код, а интереса и времени заморачиваться с Asset Store у меня сейчас нет. Если по ходу разработки игры получится какой-то интересный инструментарий для работы с 2D, то да — тогда можно будет подумать о том, чтобы сделать из него какой-то бесплатный или платный ассет для стора.
> Prefab Evolution
У меня пока нет необходимости вкладывать префабы друг в друга, но на будущее сохранил ссылку, вдруг пригодится. Спасибо!
А вообще, стараюсь по меньше заглядывать в Asset Store, причины описал в одной из прошлых записях.
> 1. Перемещение спрайта попиксельно стрелками на клавиатуре
В Unity сферическая велечина изменения (как и во всех аппаратных движках), по умолчанию расстояние в 1.0 в Unity равняется 100pix и тут в целом нет особой сложности в реализации попиксельного перемещения. Для некоторых игр точное (попиксельное) перемещение критично, но в моем случае с этим нет проблем так как все спрайты произвольной формы и хорошо стыкуются на глаз.
С остальными пунктами в целом согласен.
>>по умолчанию расстояние в 1.0 в Unity >>равняется 100pix
- да, но я настроил камеру и пр, так, чтобы 1 unit = 1 px, удобно и перемещать и задавать размеры, можно посмотреть тут https://habrahabr.ru/post/122197/ , как настроить камеру, единственное + еще в текстурном атласе в поле Pixels Per Unit надо выставить 1.
В моем случае работать на глаз не очень удобно, тем более без привязок, но применился, проект доделываю, поэтому допилю так.
Здравствуйте, Антон. Вопрос не касается темы поста, но я подумал что задать его сдесь будет лучше, чем засорять вам почту.
Вопрос такой - не замечали ли вы каких-либо странностей в работе полей scale в Spine? Ну или просто какие-либо отличия в поведении этих полей, от полей rotate и translate?
Не подумайте что я совсем ламерюга - я работал со Spine примерно пол года, и все было нормально, но вот сейчас, после длительного перерыва, скачав обновленную версию, сижу и просто не могу присвоить этим полям конкретные значения - их значения меняются просто рандомно, а изменение значения колесиком мыши вообще не работает.
Я прочитал в блоге Spine, что они ввели какой-то новый Skewing scale в версии 3, но так и не понял - это поведение естественное следствие из этой фичи, или баг, вызванный ее кривой реализацией.
В общем сижу и плачу. Думаю писать гневное письмо в esotericsoftware, но прежде, хочу узнать мнение других пользователей Spine об этом :)
Ну а по теме, как начинающий инди разработчик, пытающийся сделать свою первую игру (почти такую же, по сути :)), могу лишь сказать что сру кирпичами от зависти к тому как лихо вы решаете возникающие проблемы и технического и графического характера.
Тем не менее, спасибо вам за этот блог - всегда с интересом читаю все ваши статьи, и это, пожалуй, единственное что меня еще мотивирует не бросить все нафиг :)
Это будет лучше чем все игры вместе взятые
@Андрей,
> Это будет лучше чем все игры вместе взятые
Да ты прав
не могу понять а почему не воспользоваться шкалой Z для перемещения ближе-дальше от камеры???
@Luminous,
> почему не воспользоваться шкалой Z для перемещения ближе-дальше от камеры???
Потому что это не удобно. Если есть специальные поля задающие сортировку — значит их и нужно использовать. Координата Z имеет наиболее низкий приоритет перед слоями и индексом сортировки. К тому же задавая сортировку по координате Z объекты реально меняют свое место положение что может выйти боком если захочется сделать динамическое приближение камеры.
?грал в ваши игры с 8 лет жду продолжение с нетерпением.
@Никита, это здорово! Спасибо! :)
Комментарий!
6 Апреля 2016
— 23:44
#