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 Марта]


Индикаторы: Zombotron3
Постоянная ссылка

 

 

Комментарий!

Комментатор
6 Апреля 2016
— 23:44
#

Хорошо, что дело движется)

GreenFest
7 Апреля 2016
— 08:38
#

Крутота :). А когда нибудь можно будет посмотреть Cucumber?

WeslomPo
7 Апреля 2016
— 10:32
#

Тоже когда начал изучать Юнити не мог отделаться от чувства дежавю. Ведь начинал я с Macromedia Flash Professional, а там скриптики в кадрах и на объектах пишутся). А тут 2016 год а всё тоже самое почти) + Всё равно мне нужно было использовать тайловый редактор карт.
В итоге, решил что Юнька для моей 2д игры - затея тухлая, тем более что игра не очень масштабная, и сейчас пишу игру на Старлинге.

Кстати, Антон, как тебе физика что встроена в Юнити? По мне так лучше уж бокс2д, а ещё лучше нейп.

Danilos
7 Апреля 2016
— 11:19
#

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

Латентный Суперразработчик
8 Апреля 2016
— 01:10
#

@ant.karlov You still do not have an exact date of when the game will be released?

alonso ovalle
8 Апреля 2016
— 23:37
#

Здравствуйте Антон, заметил в анимации выше, вы соединяете спрайты на глаз, выберете тексту зажмите кнопку v выберите угол у спрайта который хотите соединить и перетаскивайте спрайт к другому спрайту. Надеюсь был полезен )

Неважно
9 Апреля 2016
— 04:21
#

Кстати, Антон, а ты не думал попросить Александра записать для своего проекта звуки окружающей среды? По моему, это то чего Zombotron-у очень сильно не хватает.

Marauder
9 Апреля 2016
— 05:07
#

Антон, ты садист! Столько слов про ентити, а статей по этой теме так и не выложил!

Ко-ко-ко!
9 Апреля 2016
— 08:54
#

@Неважно спасибо за tip!)

TheShpufa
9 Апреля 2016
— 11:48
#

не хочу показаться глупым, но что такое игровой движок?

игрок
9 Апреля 2016
— 11:50
#

Антон, можешь поделиться своим скриптом для z-ордеринга?

d-kay
9 Апреля 2016
— 12:12
#

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

Кто-то-там
9 Апреля 2016
— 13:18
#

@WeslomPo, когда я немного наберусь опыта с C# и сделаю третью версию Cucumber переписав его раз 5 — тогда можно будет, да! :)

Ant.Karlov
9 Апреля 2016
— 14:22
#

@Danilos,

> Всё равно мне нужно было использовать тайловый редактор карт.

Мне кажется, что реализовать в Unity тайловый редактор — это просто. Но если не хочется заморачиваться, то конечно лучше взять новое решение. В ближайших обновлениях Unity обещают встроенные 2д тайловый редактор (где-то видел видео-презентацию с весьма интересным набором плюшек для 2D в будущих версиях Unity).

> Кстати, Антон, как тебе физика что встроена в Юнити? По мне так лучше уж бокс2д, а ещё лучше нейп.

Если честно, то физика как физика — ничего особенного. Удобно настраивать её сразу в редакторе Unity. В остальном же на Box2D похоже. Конечно Box2D роднее и ближе, т.к. столько лет только с ним и работал. Но прям каких-то особенных ощущений по этому поводу пока нет. Все точно так же приходится твикать и настраивать, чтобы физика работала как мне нравится :)

Ant.Karlov
9 Апреля 2016
— 14:27
#

@Латентный Суперразработчик,

> Только это все же фреймворк, а не движок.

Да, вы правы. Спасибо что поправили! :)

Ant.Karlov
9 Апреля 2016
— 14:28
#

@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! :)

Ant.Karlov
9 Апреля 2016
— 14:31
#

@Неважно, спасибо за хинт, обязательно попробую в деле! Правда в моем случае спрайты идут немного в нахлест, так как графика нарисована немного в изометрической проекции.

Ant.Karlov
9 Апреля 2016
— 14:34
#

@Marauder,

> Кстати, Антон, а ты не думал попросить Александра записать для своего проекта звуки окружающей среды?

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

Ant.Karlov
9 Апреля 2016
— 14:36
#

@Ко-ко-ко!

> Столько слов про ентити, а статей по этой теме так и не выложил!

Еще не закончил их. Это действительно большой и сложный материал который весьма не просто донести простым языком. Выложу когда все статьи из серии будут готовы. В общем, работаю над этим ;)

Ant.Karlov
9 Апреля 2016
— 14:38
#

@игрок,

> не хочу показаться глупым, но что такое игровой движок?

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

Ant.Karlov
9 Апреля 2016
— 15:56
#

@Кто-то-там,

> Серьёзно не хватало фоновой анимации(там бабочки летают, или зомби кого хавают, а может пауки бегают)

Да, в целом согласен. Порой даже просто небольшой анимации окружения не хватало, в виде покачивания травы или что-то вроде этого. Но все это было невозможно сделать из-за ограничений которые накладывались Flash платформой. В новой игре планирую больше внимания уделить подобным деталям.

Ant.Karlov
9 Апреля 2016
— 15:59
#

А когда примерно выйдет игра?

Сергей
10 Апреля 2016
— 12:31
#

> Кстати, Антон, как тебе физика что встроена в Юнити? По мне так лучше уж бокс2д, а ещё лучше нейп.

Лол, а ничего, что 2д физика в Юнити основана на бокс2д?

Ололош
10 Апреля 2016
— 18:09
#

Антон, как всегда - интереснейшая статья, спасибо! Подскажи пожалуйста (возможно я где-то невнимательно прочёл): выше есть скриншот с объектами сцены и там, среди прочего, есть объект с именем Render, какова его роль?

Владимир
10 Апреля 2016
— 19:13
#

@Ant.Karlov

Не надо простым языком про ентити. Есть вероятность не вместить важную информацию в такой формат. Лучше уж по хардкору, техническим языком. =)

PS Дневники это тоже хорошо, очень интересно читать. Было бы здорово если бы в заключтельной статье было личное мнение о них. Помогают они разработке или скорее мешают?

Denis
11 Апреля 2016
— 07:12
#

@Сергей,

> А когда примерно выйдет игра?

Не знаю. Пока еще ранняя стадия разработки. Следите за обновлениями! :)

Ant.Karlov
11 Апреля 2016
— 10:46
#

@Ололош,

> Лол, а ничего, что 2д физика в Юнити основана на бокс2д?

Кстати, я тоже об этом слышал, но мне показалось что это слухи. Вроде как Box2D уже устоявшийся движок с определенным функционалом, а в Unity от версии к версии в 2D физике еще что-то меняется.

Ant.Karlov
11 Апреля 2016
— 10:50
#

@Владимир,

> объект с именем Render, какова его роль?

Это что-то вроде папки для объектов которые отвечают или влияют на Render картинки. Пока там только одна основная камера (Main Camera). Позже, возможно, появится еще одна камера для GUI и может быть еще какие-то вещи.

Ant.Karlov
11 Апреля 2016
— 10:54
#

@Denis,

> Было бы здорово если бы в заключтельной статье было личное мнение о них. Помогают они разработке или скорее мешают?

На основе многолетнего опыта ведения блога, могу сказать, что ведение дневника (блога) мешает только тем, что порой отнимает чуть больше времени чем ожидаешь. А в остальном только польза:

1. Само-контроль (отчетность).
2. Общение, получение советов и критики.
3. Мотивация (иногда демотивация).
4. Привлечения внимания к игре на раннем этапе разработки, как следствие организация сообщества вокруг игры и т.п.

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

Но, вообще, я думаю, что польза от ведения дневника разработки строго индивидуальна — нужно пробовать! :)

Ant.Karlov
11 Апреля 2016
— 11:10
#

Что скажешь по поводу havok?

Gamaz
11 Апреля 2016
— 17:06
#

мне кажется зомботрон будет лучшей флеш-игрой 2016 года

поклонник
11 Апреля 2016
— 21:46
#

Еееееееееееее!!!!!я оставил свой первый коммент на этом сайте ееееее

dinoZ
11 Апреля 2016
— 23:31
#

@Gamaz

> Что скажешь по поводу havok?

Ничего не могу сказать. Никогда не пробовал :) Знаю только, что это аппаратная физика и раньше нужно было отдельную карту под это дело, но потом чип для расчета Havok физики стали встраивать прямо в видео карты. Но, поскольку к этому времени я уже перешел на Mac — я перестал следить за этой темой и сейчас мало чего знаю (может даже где-то ошибся в тексте выше).

Ant.Karlov
12 Апреля 2016
— 14:03
#

@поклонник,

> мне кажется зомботрон будет лучшей флеш-игрой 2016 года

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

Ant.Karlov
12 Апреля 2016
— 14:05
#

Замечательно игра внешне выглядит. Тоже перешел на юнити, и удивился,что со слои/порядок, нельзя менять, как в флеше. Можешь показать код скрипта по работе с порядком спрайтов? Мне нужно только клавишами менять слой вручную. Ранее не писал скрипты для редактора Юнити.

Info
12 Апреля 2016
— 15:41
#

Где найти музыку из ваших игр?зашел на сайт Александра Ахуры-там ничего нет:(

dinoZ
13 Апреля 2016
— 00:11
#

Захожу с телефона если что

dinoZ
13 Апреля 2016
— 00:13
#

re Info: Можешь показать код скрипта по работе с порядком спрайтов? Мне нужно только клавишами менять слой вручную. Ранее не писал скрипты для редактора Юнити.
Да, возможно Антон с радостью поделится с вами своим кодом, но меня возмутила ваша просьба. Почему кто-то должен вам выдавать свои наработки? Да, код того, что вы просите не сложный и в нём нет какого-то секрета, но может есть смысл попробовать самому написать его, хотя бы попытаться? Не?

Возмущённый читатель
13 Апреля 2016
— 12:18
#

@Info, хорошо, подготовлю скрипт для публикации.

Ant.Karlov
13 Апреля 2016
— 13:48
#

@dinoZ,

> Где найти музыку из ваших игр?

Музыку можно найти на zombotron.com, так же не так давно выкладывали саунтрэк из FireCatcher как есть в FB.

Ant.Karlov
13 Апреля 2016
— 13:51
#

@dinoZ
Насчет музыки отвечу от первоисточника так сказать )
Во флеш играх из-за ограничений объема приходится умеренно использовать музыку, так как веса она прибавляет порядочно.
Достигается эта умеренность либо малым количеством треков, либо короткой длительностью их.
В процессе игры это может не замечаться ибо внимание отвлекает множество других факторов. Но по отдельности 30 секунд музыки годится только для портфолио, а не для комфортного прослушивания.
The Planet Zombotron не совсем саундтрек. Это компиляция из материалов по первой и второй части, причем некоторые не были использованы в игре, а кое-что дописано позже.
Что касается саундтрека из других игр. Опыт с публикацией саундтрека Fire Catcher я считаю неудачным. Потому что там как раз та особенность, о которой я писал выше (флеш игра, ограничения по длительности).
В итоге. Саундтреки из флеш игр я буду выкладывать только частично, для портфолио, как ознакомительный вариант. А что касается нового зомботрона, то об этом еще совсем рано говорить.

Александр Ахура
13 Апреля 2016
— 17:13
#

спасибо за ответ:-)

dinoZ
13 Апреля 2016
— 21:50
#

>>но меня возмутила ваша просьба. Почему кто-то >>должен вам выдавать свои наработки?
>>но может есть смысл попробовать самому >>написать его, хотя бы попытаться? Не?

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

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

К слову, поэтому русских и имеют все и их ресурсы, потому как сейчас русские (сам русский) - это поколение РАЗОБЩЕННЫХ дегенератов. Много веков вас учат, учат, а вы все уроки не внимаете. Пора уже умнеть.

>>@Info, хорошо, подготовлю скрипт для публикации.
Возможно, лучше тогда оформить свой код и выложить его платным в юнити ассет сторе, т.к. функционал вполне может быть востребованным, в таком случае делиться им не стоит, во всяком случае полным функционалом. По опыту покупая ассеты/плагины в ассет сторе к юнити, самые стоящие, не игрушки имеют корни, когда разработчику самому чего то не хватало, он реализовал для себя и это вылилось в коммерческий продукт.

Info
14 Апреля 2016
— 05:07
#

Кстати, когда начинал работать с юнити, до меня долго не могло дойти, как с юинити вообще можно работать без стороннего платного плагина Prefab Evolution. Саму проблему, которую великолепно решает данный плагин описал Джонни-К в своей статье про юнити: http://eugenekuzmin.ru/2015/01/06/4821/ Раздел в статье: Префабы
Экономит просто уйму времени.
Антон, обрати на эту проблему свое внимание:

info
14 Апреля 2016
— 05:44
#

А по поводу работы со спрайтами (Sprite) в юнити, то если не использовать плагины (по своим причинам) NGUI, 2D Toolkit, то по функционалу крайне не хватает: 1. Перемещение спрайта попиксельно стрелками на клавиатуре 2. Попиксельных и пообъектных привязок при перемещении (как это сделано для UI функционала). 3. В некоторых моментах недостатки с групповой работой спрайтов. 4.Ну и вышеприведенная работа со слоями. Т.е. все эти пункты приближают работу со спрайтом в юнити к работе в FlashIDE, Фотошопу.

info
14 Апреля 2016
— 05:52
#

Поэтому, когда будет время, это все-равно придется самому делать для следующих проектов, чтобы комфортно было работать, также, как в FlashIDE.

info
14 Апреля 2016
— 06:22
#

@info,

> Возможно, лучше тогда оформить свой код и выложить его платным в юнити ассет сторе

Там слишком простой скрипт и код, а интереса и времени заморачиваться с Asset Store у меня сейчас нет. Если по ходу разработки игры получится какой-то интересный инструментарий для работы с 2D, то да — тогда можно будет подумать о том, чтобы сделать из него какой-то бесплатный или платный ассет для стора.

> Prefab Evolution

У меня пока нет необходимости вкладывать префабы друг в друга, но на будущее сохранил ссылку, вдруг пригодится. Спасибо!

А вообще, стараюсь по меньше заглядывать в Asset Store, причины описал в одной из прошлых записях.

> 1. Перемещение спрайта попиксельно стрелками на клавиатуре

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

С остальными пунктами в целом согласен.

Ant.Karlov
14 Апреля 2016
— 10:29
#

>>по умолчанию расстояние в 1.0 в Unity >>равняется 100pix
- да, но я настроил камеру и пр, так, чтобы 1 unit = 1 px, удобно и перемещать и задавать размеры, можно посмотреть тут https://habrahabr.ru/post/122197/ , как настроить камеру, единственное + еще в текстурном атласе в поле Pixels Per Unit надо выставить 1.

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

info
14 Апреля 2016
— 10:52
#

Здравствуйте, Антон. Вопрос не касается темы поста, но я подумал что задать его сдесь будет лучше, чем засорять вам почту.

Вопрос такой - не замечали ли вы каких-либо странностей в работе полей scale в Spine? Ну или просто какие-либо отличия в поведении этих полей, от полей rotate и translate?

Не подумайте что я совсем ламерюга - я работал со Spine примерно пол года, и все было нормально, но вот сейчас, после длительного перерыва, скачав обновленную версию, сижу и просто не могу присвоить этим полям конкретные значения - их значения меняются просто рандомно, а изменение значения колесиком мыши вообще не работает.

Я прочитал в блоге Spine, что они ввели какой-то новый Skewing scale в версии 3, но так и не понял - это поведение естественное следствие из этой фичи, или баг, вызванный ее кривой реализацией.

В общем сижу и плачу. Думаю писать гневное письмо в esotericsoftware, но прежде, хочу узнать мнение других пользователей Spine об этом :)

Ну а по теме, как начинающий инди разработчик, пытающийся сделать свою первую игру (почти такую же, по сути :)), могу лишь сказать что сру кирпичами от зависти к тому как лихо вы решаете возникающие проблемы и технического и графического характера.

Тем не менее, спасибо вам за этот блог - всегда с интересом читаю все ваши статьи, и это, пожалуй, единственное что меня еще мотивирует не бросить все нафиг :)

Agman
15 Апреля 2016
— 15:58
#

Это будет лучше чем все игры вместе взятые

Андрей
17 Апреля 2016
— 00:28
#

@Андрей,

> Это будет лучше чем все игры вместе взятые


Да ты прав

фанат
17 Апреля 2016
— 10:48
#

не могу понять а почему не воспользоваться шкалой Z для перемещения ближе-дальше от камеры???

Luminous
18 Апреля 2016
— 11:28
#

@Luminous,

> почему не воспользоваться шкалой Z для перемещения ближе-дальше от камеры???

Потому что это не удобно. Если есть специальные поля задающие сортировку — значит их и нужно использовать. Координата Z имеет наиболее низкий приоритет перед слоями и индексом сортировки. К тому же задавая сортировку по координате Z объекты реально меняют свое место положение что может выйти боком если захочется сделать динамическое приближение камеры.

Ant.Karlov
20 Апреля 2016
— 10:03
#

Играл в ваши игры с 8 лет жду продолжение с нетерпением.

Никита
26 Апреля 2016
— 15:21
#

@Никита, это здорово! Спасибо! :)

Ant.Karlov
28 Апреля 2016
— 10:59
#