New Zombotron. Неделя #6
Настало время реализации спец-эффектов в игре и перед мной встал очередной вопрос: как воспроизводить покадровую анимацию в Unity.
Под покадровой анимацией я подразумеваю анимацию, которая состоит из заранее нарисованных изображений.
Если собрать кадры в последовательность и отображать каждый следующий кадр с небольшим интервалом, то получится анимация. Собственно это самая обычная анимация, которая используется повсеместно.
Не смотря на то, что я выбрал Spine с программной анимацией, от покадровой анимации отказаться полностью нет возможности. Почему — спросите вы? Все очень просто, для каждого вида анимации есть свои плюсы и минусы:
Программная анимация хороша тем, что для её хранения не требуется много памяти и можно программно изменять непосредственно саму анимацию или отдельные части персонажа. Но для воспроизведения такой анимации требуется больше процессорного времени, чем для покадровой анимации — положение и трансформации каждой части такой анимации высчитываются на ходу между ключевыми кадрами.
Покадровая анимация хороша тем, что работает быстро, и можно не задумываясь рисовать совершенно невероятные анимации. Но, как правило, все упирается в размер атласа/памяти, которые будут использованы для хранения каждого кадра, и такую анимацию нельзя будет изменить программно.
Как итог, мы видим, что каждый тип анимации решает определенные задачи и ставит определенные ограничения, поэтому не может идти и речи о том, чтобы использовать только один тип анимации. Конечно, есть такие игры, где можно обойтись только программной или только покадровой анимацией. Но Зомботрон в число таких игр не входит. Поэтому придется использовать оба типа анимации, чтобы получить нужный результат.
? так, если с программной анимацией в Unity для меня все понятно — я просто использую Spine, то с покадровой анимацией возникают вопросы.
Покадровые анимации в Spine
Как это обычно бывает, даже самые замечательные инструменты не лишены недостатков. В Spine есть куча преимуществ, но и без недостатка не обошлось: невозможность создания покадровых анимаций. Хотя, покадровую анимацию в Spine сделать конечно же можно: для этого нужно просто импортировать заранее нарисованные изображения и произвести все необходимые манипуляции с ними, чтобы они превратились в живую последовательность. Только вот процесс создания таковых анимаций получается весьма трудоемким:
- Отрисовка анимации во Flash (или в другом графическом редакторе).
- Экспорт эффекта в покадровую раскадровку.
- ?мпорт кадров в Spine и настройка анимации.
- Экспорт анимации из Spine.
- ?мпорт и настройка анимации в Unity.
В целом не так много манипуляций, но есть еще один маленький недостаток: Spine не умеет так красиво паковать атласы как это делает Texture Packer, речь тут идет о полигональной упаковке изображений, так что, если даже и использовать Spine для покадровых анимаций, то такие анимации будут занимать в разы больше места в атласах, чем те же самые анимации, упакованные в атласы при помощи Texture Packer. В общем, как не крути, а использование Spine исключительно для покадровых анимаций больше напоминает: «забивание гвоздей микроскопом» и тут очевидно, что нужно использовать другой подход.
Покадровая анимация в Unity
Уже все, кто хоть как-то сталкивался с разработкой в Unity, давно знают, что там есть куча замечательных инструментов для работы с 2D. В том числе и Animator для создания и контроля этих самых анимаций. Только вот уже после нескольких экспериментов с Animator стало понятно, что эта штука безусловно крута и интересна — почти такой же Timeline как во Flash с возможностью жонглировать игровыми объектами, как душе угодно. Но опять же — стандартный Animator в Unity не лишен недостатков и выглядит как очередной микроскоп, которым необходимо забить пару гвоздей. Чтобы не быть голословным, расскажу пару неприятных моментов:
- Animator мне показался не стабильным, так как за несколько месяцев работы с Unity, редактор крэшился несколько раз исключительно во время работы с Animator.
- В Animator имели место быть неприятные артефакты (баги?), когда в момент завершения проигрывания анимации, проигрывание останавливалось на предпоследнем ключевом кадре, а не на последнем как это ожидалось — я получал на экране застывшую анимацию, которая портила все впечатление. Происходило это потому, что игровой объект состоит из нескольких частей-эффектов и не все части еще закончили свою работу. В общем, приходилось делать дополнительные пустые кадры в конце анимации — это не критично конечно, но осадочек остался.
- При создании каждой анимации в Animator автоматически создается дополнительный файл данных, что-то вроде контроллера анимаций — не критично, но в итоге получается слишком много лишних файлов. Возможно контроллер анимаций можно удалить — но я не помню пробовал ли я это делать.
- Поскольку Animator сам по себе очень наворочен и имеет много интересных возможностей, то для работы с ним требуется некоторый навык. Работа с Animator мне напомнила работу с макросами в каком-нибудь MS World, когда записывается набор действий пользователя — так и норовят записаться в тайм-лайн какие-то лишние действия, например передвижения какого-нибудь объекта, который я успел подвинуть или повернуть, забыв отключить кнопку Rec, ну и все в таком духе.
В итоге, провозившись несколько дней с Animator, я понял простую суть — вся работа Animator (в моем случае) заключается в том, что в некий Sprite Renderer подставляются Sprite Region из заданного материала. То есть, говоря программерским языком: Animator с заданным интервалом подменяет регионы для Sprite из указанного атласа и за счет этого получается анимация! ? тут я осознал, что самый простой и доступный способ реализовать анимации в Unity — это написать свой простой класс, делающий тоже самое, но проще, а главное надежнее!
AntActor в Unity
Вы будете смеятся, но, поняв сию простую суть, я просто взял и переписал 1 в 1 свой класс AntActor.as из Anthill под Unity, который имеет точно такой же функционал, как и на Flash.
Сейчас я не буду рассказывать как устроен AntActor для реализации покадровых анимаций в Unity. Я просто поделюсь скриптом и расскажу как им пользоваться.
Скачиваем скрипт по ссылке выше и закидываем в папку Scripts вашего проекта. Поскольку скрипт является наследником MonoBehaviour, то его можно прицепить к любому игровому объекту, имеющему компонент Sprite Renderer (этот компонент имеют все простые 2D спрайты).
После того, как скрипт успешно добавлен к объекту, мы должны немного настроить его, а именно: указать Initial Animation — это имя анимации, которая будет запущена по умолчанию. А потом добавить все необходимые анимации. Для этого разворачиваем пункт Animations в поле Size указываем кол-во анимаций, после чего настраиваем каждую из них, как на анимированной картинке выше.
После того, как все анимации добавлены, можно протестировать работу скрипта. Так же для настроек доступны еще три дополнительных параметра:
- Time Sсale — скорость проигрывания анимации, чем больше значение, тем быстрее анимация проигрывается. Чтобы замедлить анимацию в два раза, нужно задать time scale = 0.5. Так же у актера есть скрытый параметр Animation Speed с «магическим числом» — но я не советую его изменять.
- Reverse — позволяет воспроизводить анимацию в обратном направлении.
- Loop — определяет будет анимация проигрываться постоянно или только один раз.
Конечно же есть и другие полезные свойства и методы для работы с анимацией, которые не доступны через инспектор. Дополнительно я подготовил небольшой тестовый проект, в котором тестировал работу AntActor — скачать и ознакомиться можно по ссылке:
? последний шаг: не забудьте задать для Sprite Renderer материал и текущий кадр (регион из атласа) по умолчанию, чтобы объект (анимация) были видны в редакторе в режиме редактирования, как на картинке ниже.
Если у вас будут какие-либо замечания или пожелания в отношении данного скрипта — буду рад вашим комментариям!
Единственный недостаток у данного скрипта на текущий момент: это необходимость установки каждого отдельного кадра вручную, как на картинке-примере выше. Я пока не придумал как этот момент можно оптимизировать. Во всяком случае, при работе со стандартным Animator приходится выполнять точно такую же процедуру.
Заключение
На поиск оптимального пути для работы с покадровыми анимациями понадобилось чуть больше времени, чем одна неделя — все эти эксперименты и тесты в фоновом режиме тянулись на протяжении месяца. Вначале пробовал один вариант, потом второй — каждый раз все приходилось перелопачивать и перенастраивать, потом смотреть как это работает и делать какие-то выводы.
Попутно с поиском оптимального решения для воспроизведения анимаций разбирался еще и со стандартной системой частиц. К сожалению, не могу пока сказать, что я удовлетворен стандартной системой частиц в полной мере, да и изучить её пока полностью тоже не удалось, поэтому пока ничего не буду рассказывать об этом. Скажу лишь одно: стандартная система частиц выглядит слишком стандартно и в некоторых случаях хотелось бы чуть больше возможностей, чем есть по умолчанию, так что уже появляются мысли о том, чтобы создать свою систему частиц, которая будет решать необходимые мне задачи или дополнять уже существующую. Но это пока не самая приоритетная задача, поэтому к решению этого вопроса я вернусь позже.
На текущий момент готово небольшое видео, которое демонстрирует часть уже проделанной работы, а именно стрельбу и некоторые эффекты.
[Апрель 16]
Проект продвинулся намного дальше, чем я успеваю отписываться об этом, и сейчас я раздумываю о чем же мне написать дальше: об освещении, о мучениях с рэгдоллами или о наработках для ??, к реализации которого я уже приступил...!?
Как бы там ни было, я очень надеюсь, что следующую запись я успею подготовить в течении предстоящих праздников, чтобы хоть как-то нагнать свое отставание.
А пока всех поздравляю с праздниками и желаю замечательных весенних выходных! Ура! :)
UPD [от 27.03.2017]: AntActor обновлен! В обновлении исправлена ошибка с пропуском первого кадра при повторных циклах анимации, а так же добавлены некоторые другие улучшения. Пример использования AntActor так же был обновлен.
Угу, замочком, который сверху инспектора.
Впечетляющее видео! Столько эффектов и это ведь только начало, так ведь?
P.S С прошедшими праздниками!
...о чем же мне написать дальше: об освещении, о мучениях с рэгдоллами или о наработках для ??, к реализации которого я уже приступил...!?
О освещении. Очень интересно.
Все выглядит отменно! Успехов Антон!
Напиши про всё! Твои статьи читать одно удовольствие, а еще большее удовольствие примеры которые ты выкладываешь ;)
Вот только не понятно зачем в примере ZombieMat прикреплен в SpriteRener material зомби префаб? Наверное у тебя Антон уже реализовано выковыривание из такого материала спрайтов?
Что-то я ляпнул, просто не понял почему текстура отображается в материале а информации что это за текстура нет.
Там "как во флеше" сделал. Тут "не так, как думал" :) ?ными словами проект на Unity требует все равно напильник и кнопки "сделать хорошо" в нем не оказалось :) О чем я писал еще год назад :)
Это говорит о том, что человек развивается и умеет пилить всё что надо под себя! Если бы Антон велосипед делал, то зомботрона мы бы в книжках только увидели бы!
Это как с авто, кто-то сел и стоит в пробках. А кто-то ставит катки побольше, резину поменьше, движок может еще расточит да и подвеску всю перетрясёт, но кузов он не отливал, да и детали у станка не вытачивал.
Ееееееееееееее,новое видео от Антонааааа
А мне интересно, будет ли реализована "разрываемость" ботов? По мне, этой детали как раз не хватало в ближнем бою. Например, возможность смахнуть голову кувалдой, или отрубить руку ножом. Где бы это не было, всегда выглядит замечательно !
Про освещение хочется статью.
Ты должен уделать Intrusion 2!
Никому он ничего не должен, это разные игры.
Да освещение очень, особонно ощущение 3д изображенное 2д средствами,
?нверсная кинематика, да эт круто, помню как-то к AntHill прикрутил spine (в черновом варианте) исходники сбрасывал, но тогда чего-то не прижилась и не пошла тема.
Чтоб уделать Intrusion 2, надо инверсную кинематику использовать не только в анимации, но и в геймплее.
Антон, приседание героя умиляет.
Делай больше возможностей для героя)
Кто-То-Там. Да будет прікольно
Здорово!
видео понятно показывает прогресс разработки и хотелось бы скорее увидеть какие будут враги.
Всё это выглядит довольно занятно :)
@samana,
> Если заблокировать инспектор, то можно выделить сколько нужно спрайтов в окне проекта и перетащить их на поле size массива одним махом!
Работает отлично! Огромное спасибо за эту подсказку! :)
@TheRabbitFlash,
> Там "как во флеше" сделал. Тут "не так, как думал" :) ?ными словами проект на Unity требует все равно напильник и кнопки "сделать хорошо" в нем не оказалось :)
Да, Flash конечно же оставил свои отпечатки к рабочему подходу в некоторых вопросах. Но мне нравится что Unity изначально заточен на расширение возможностей за счет потребностей разработчика. Нужен новый функционал в редакторе? Пожалуйста! Можно легко и просто добавлять то что нужно. На это же намекает и стор с доп.ресурсами — это удобно. А во Flash поди попробуй расширь IDE!
Но, я все же за то, что Unity и Flash сравнивать просто не корректно из-за множества причин. Даже не смотря на то, что изначально у них были общие черты.
@Кто-То-Там,
> А мне интересно, будет ли реализована "разрываемость" ботов?
Вообще заранее я об этом не думал даже как-то. Но, вроде как данная фича уже имеется в игре — когда работал над рэгдоллами, настраивал так чтобы от определенных нагрузок определенные части тела отрывались. Так что от критических попаданий уже сейчас отрывает руки, ноги и даже пополам разрывает. Может быть в будущих видео вы сможете это увидеть :)
@Elmigo,
> ?нверсная кинематика, да эт круто, помню как-то к AntHill прикрутил spine (в черновом варианте) исходники сбрасывал, но тогда чего-то не прижилась и не пошла тема.
А чего не прижилась эта тема? :)
@Кто я, @Vik и @Vacsa, Лично у меня нет цели кого-либо "уделать". Я просто делаю новую игру со своими подходами и представлениями о том как это должно быть. Никогда не считал другие игры, даже в схожих жанрах, конкурентами или что-то вроде этого.
Существует понятие "вкуса" как для кино, музыки так и для игр. Если человеку нравится что-то одно, то не факт, что ему понравится аналогичный другой продукт и причин для этого может быть много! Таким образом, если пытаться конкурировать с другим продуктом (будь то кино, музыка или игра), велик риск, что автор будет пытаться перестроится на другую аудиторию и если это у него получится, то вероятно он потеряет свою аудиторию если таковая у него уже есть :)
В общем, я не буду пытаться конкурировать, я попробую сделать более интересную игру на базе своих предыдущих.
@игрок,
> видео понятно показывает прогресс разработки и хотелось бы скорее увидеть какие будут враги.
Первые записи будут охватывать много технических вопросов, но чем дальше в разработку, тем больше будет погружение в игру и рассказ непосредственно об игровых фичах, монстрах и геймплее в целом.
@Ant.Karlov
>А чего не прижилась эта тема? :)
свой проект заглох, тебя фишка на тот момент не заинтересовала, а сейчас тем более актуальность потеряла, ну как-то так :)
зачем у тебя номер кадра float, ты же не меняешь его значение на полкадра, из-за этого тебе приходится вызывать странный метод округления. используй int
@Вадим,
int + speed:
frame += 0.2 //frame 0
frame += 0.2 //frame 0
frame += 0.2 //frame 0
frame += 0.2 //frame 0
frame += 0.2 //frame 0
float + speed:
frame += 0.2 //frame 0.2 (0)
frame += 0.2 //frame 0.4 (0)
frame += 0.2 //frame 0.6 (0)
frame += 0.2 //frame 0.8 (0)
frame += 0.2 //frame 1 (1)
Сечешь о чём я?:)
@Rasp, ага это понятно, но я все-таки склоняюсь к тому что мухи должны быть отдельно от котлет.
- выставлять _timeToFrame на смене кадра
- уменьшать его на deltatime в апдейте
- при достижении 0 менять кадр и опять выставлять _timeToFrame
за счет того что пропадет куча работы с флоатами и приведение типов - код проще станет и работать будет быстрее.
Спасибо за блог!!
Давай дальше про освещение! =)
Вадим,
Ок. А откуда брать дефолтное _timeToFrame?)
Плюс ко всему в твоей реализации будет проблема с погрешностью. _timeToFrame будет уходить всегда в минус, но этот остаток ты игнорируешь. Поэтому кадры будут переключаться неравномерно. Особенно будет заметно на высокой скорости, где остаток в минусе будет значителен.
@Вадим и @Rasp, я думаю что в случае реализации с отдельной временной шкалой можно считать время так:
frameTime += animSpeed * timeScale * deltaTime;
if (frameTime >= 1)
{
frameTime -= 1;
currentFrame++;
// переключаем кадр
}
Но в целом, я не вижу большой необходимости в разделении времени и кадров так как это немного усложняет понимание процесса работы. В анимациях обычно временем считается именно кадры. Хотя, если я не ошибаюсь, то в Spine как раз нет понятия кадров — только время анимации! :)
Ant.Karlov,
тоже ошибка.
Когда frameTime будет выходить за единицу, то начнёт игнорироваться скорость.
Например при увеличении скорости или большом deltaTime (после фриза):
frameTime = 3.5; //логично переключить на ~3 кадра
if (frameTime >=1)
{
frameTime -=1;
currentFrame++; //переключили только на один кадр
}
Если же высчитывать разницу кадров:
frameTime / 1(время одного кадра) = 3.5 кадра разницы.
? тут снова возвращаются дробные числа, которые необходимо округлять.
@Rasp,
> Когда frameTime будет выходить за единицу, то начнёт игнорироваться скорость.
Да, точно! Я не подумал об этом. Тогда надежнее будет получать текущий кадр исходя из текущего времени анимации как это и делается изначально.
Антон, обнови пожалуйста раздел "Вдохновение" с ссылками внизу страницы. Сейчас большая часть этих блогов мертва или не обновлялась более двух лет.
@Вдохновение, да, спасибо за напоминание. Убрал блоги которые не открывались (недоступны более), а те которые не обновляются — зачем же их убирать? Там по прежнему есть интересная информация, хоть и старая :)
Rasp, тогда можно делать
while(frameTime>=1)
{
frameTime--;
currentFrame++;
}
Другое дело, что сейчас в коде от Антона все работает намного проще
Мини-баг на сайте: пропала картинка для тега зомботрона. По адресу http://www.ant-karlov.ru/images/tag14.png сейчас пусто, а на главной куча крестиков, мол изображение не удалось загрузить.
@приветкакдела,
Ну вроде будет работать, но я бы за такое по рукам бил:) В цикле считать фрейм... Прилетит туда большой frameTime и давай его гонять ради операций + - :) ? так все анимации на сцене. Да и еще условия на диапазон и reverse туда нужно будет запихнуть...
Тот же самый велосипед? В разрезе анимации и математики кадров - подсчёт точного значения и округления для последующего использования - более правильное. Т.к. это число с плавающей точкой может быть использовано и для других необходимых расчётов.
Ну а вообще это задачи ради задач:) Да и округление float это простейшая операция, по сравнению с тем, что происходит у Юнити в main цикле. Думаю не стоит фокусироваться на этом.
Что насчëт озвучки в игре? Будут озвучивать персонажей или все диалоги будут в субтитрах как в прошлых частях?
@dinoZ, пока озвучки персонажей не планируется. То есть, если быть честным, то бюджет на разработку слишком скудный чтобы заморачиваться озвучкой персонажей :) Поэтому в основном будут кат сценки на движке с текстовыми диалогами. В лучшем случае будет какое-то подобие разговоров (условная болтовня) для героев. Но про озвучку пока рано что-то конкретное говорить, так как только-только серьезно начинаю подходить к этому вопросу.
@Brrrrrr, иконки для тэга зомботрон никогда не было. Но надо будет её добавить! Спасибо за внимательность! :)
Сделаете как в fire catcher?
Как всегда отлично) Следующий пост напиши про освещение.
Добавь в Skype water_bound на пару слов.
@dinoZ,
> Сделаете как в fire catcher?
Что именно вы хотите как в Fire Catcher? :)
Фразы гг как fire cather. Я имел ввиду, когда он умирал или пытался открыть запертые двери, то выговаривал определенные фразы, можно попробовать так сделать и в зомботроне.
Хотя не знаю... Боюсь атмосфера с прошлых частей пропадет.
@Ant.Karlov, в Knighttron умиляла эта фишка. Кстати, с кровью будет как обычно, или будет стоять предупреждение , или там, её включать надо будет?
На мелких это не очень хорошо воздействует.
Я понимаю что ничего не понимаю.
Привет)
А куда метишь выпускать игру, в стим?
? еще вопрос технического плана, я в юнити только с 3д работал, а как там с 2д обстоят дела с разрешениями, допустим если игру запустить на 1024*768 и 1600х900 - в чем будет разница? Хотя разрешение это скорее к мобильным девайсам вопрос, ибо скоро собираюсь на юнити под мобилки что-то поделать в 2д.
@dinoZ, по озвучке пока ничего не могу точно сказать, так как только сейчас начинаем работу над звуком. ? по ходу того как все будет понятно в плане озвучки, я напишу дополнительно.
> Хотя не знаю... Боюсь атмосфера с прошлых частей пропадет.
Я думаю что атмосфера не может пропасть, она может только изменится, в лучшую или не очень сторону. Но я постараюсь сделать все так чтобы новая игра стала в разы лучше.
@Кто-То-Там,
> Кстати, с кровью будет как обычно, или будет стоять предупреждение , или там, её включать надо будет?
Да, будет с кровью. Будет два вида крови: красная и зеленая. Переключатель крови будет в настройках.
@Вайктор,
> А куда метишь выпускать игру, в стим?
Да, с новой игрой планируем выходить в Steam.
> ? еще вопрос технического плана, я в юнити только с 3д работал, а как там с 2д обстоят дела с разрешениями, допустим если игру запустить на 1024*768 и 1600х900 - в чем будет разница?
Разница будет такая же как и в 3D. В большом разрешении картинка будет увеличена без потери качества изображения. Главное спрайты/текстуры для 2D изначально делать в большем размере чтобы при увеличении разрешения картинка не мылилась (рисовать в HD качестве).
Я вот пробную игру делал, ну там в 2д интерфейс был и вот я тоже думаю дай сразу буду делать все в максимальном разрешении, ну так и сделал в итоге, но не порадовало то что когда шибко высокого разрешения картинка уменьшается до минимальных разрешенй - она искажается (не помню уже как именно, но вроде четкость теряется), то есть заметная разница если бы я сделал уменьшение картинки в фотошопе например, нежели юнити отображает большую картинку в малом разрешении, надеюсь понятно изъяснил :)
Мой другэла говорит что сейчас 2Д игры менее актуальны, мол 3Д игры лучше, в них больше людей играют, больше возможностей...как мне ему доказать, что 2Д игры тоже годны? прост такими фразами он меня демотивирует.
25 Мая 2016
— 20:43
#
@Вайктор
Гугли "mipmap"
ну блин.....зачем удалили.....
О! А Замути своё Марио! Будет прикольно погамать.
Здравствуйте Антон! Свет офигенный. Очень интересно, как он у вас устроен. Смотрю и понять не могу :) Местами выглядит как 2д меш, местами как юнитевский свет, а то, как по полу под углом идет свет вообще на 3д похоже.
>@Вайктор
>Гугли "mipmap"
Это насколько я понял надо создавать и запихивать несколько уже разрешений картинок, Антон же выше говорил нессколько о ином, мол сделать самое большое разрешение и готово, дальше уже юнити позаботится обо всем, но на деле не совсем так) ?ли может я неправильно понял Антона и "мимпам" он также будет использовать?
@Вайктор
Mimap-ы генерируются автотматически. Нужно поставить соответствующий флаг при импорте текстур.
@анонимщмк, комментарий был от подставного имени, поэтому пришлось удалить чтобы не разжигать тут.. :)
@Vorren, на самом деле это 2д свет, в следующих записях я расскажу о том как я начал работу со светом и как пришел к такому решению. Спасибо!
@Вайктор,
>Гугли "mipmap"
> Это насколько я понял надо создавать и запихивать несколько уже разрешений картинок...
Mipmap — это автоматическое создание текстур в разных разрешениях. Но, к сожалению, сейчас я не могу точно сказать как они используются в Unity. ?з моих прошлых знаний по 3D (до работы с Flash) MipMap использовался для объектов находящихся на разном удалении от камеры. То есть, чем ближе объект к камере — для него используется текстура высокого разрешения, чем дальше от камеры — более низкого разрешения. Такой подход делается в первую очередь чтобы увеличить производительность за счет увеличения скорости отрисовки объектов. Во многих играх есть возможность настроить MipMap вручную задав текстуры низкого качества для ближнего плана чтобы увеличить производительность игры.
Где-то ранее в комментариях проскакивала мысль о том что MipMap текстуры так же используются для получения четкости, но тут я не могу опровергнуть или подтвердить сей факт. Так как MipMap в любом случае повышают четкость изображения за счет получения текстур в нужных размерах (меньше скейла на лету — меньше артефактов и пикселей)...
Как MipMap могут работать для 2D и работают ли они вообще — я пока не могу сказать. Поэтому в своем проекте генерацию MipMap я просто отключил. Возможно позже, если у меня появится возможность потестировать проект на более высоких разрешениях — тогда можно будет сказать что-то более конкретно по этому поводу.
Но, если следовать начальной логике использования MipMap, то скорее всего для 2D они не работают если камера двигается только в двух плоскостях.
Антон, вы правы про мипмапы - в 2д, если нет масштабирования, они ничего не делают, а память занимают. Для пиксельарта они тоже, кстати, не нужны ибо режим фильтрации текстуры без сглаживания решает для нас все проблемы
Я проходил вторые Зомботроны чисто с холодным оружием. Так вот, меня интересует такой вопрос: будет ли уделено больше внимания всяким там ножам, киркам и т.д., или же они так и останутся оружием, на если мало боеприпасов? Просто мне нравится ходить без пистолетов/автоматов: так приходит ощущение настоящей победы, ведь ты только что зарубил превосходящего тебя врага, пусть и умер несколько раз. Но только с ножами, лопатами ходить надоедает, радиус атаки всё тот же. Было бы круто, если бы были добавлены всякие копья, палицы, двуручи какие-нибудь, и всё это с разной досягаемостью. Типа обычным ножом ты можешь бить врага только если он вплотную к тебе, но бьёшь бысто, а с каким-нибудь цваем ты держишься на безопасном расстоянии, но бьёшь значительно медленнее. Будет ли такое реализовано? Не лишайте меня надежды.
да ладно тебе....я же маты со звездочками писал:-)
Что с mipmaps творится можно посмотреть включив во вьюпорте mipmaps вместо shaded. Графика которая имеет излишнее разрешение подкрашивается красным, недостаточное синим, если всё хорошо, то не подсвечивается.
Очередной вопрос. Биороботов мы снова встретим? Они всегда были самой большой загадкой в серии , а так же самыми умными, мощными и жестокими персонажами(после главного героя 2 части конечно же). Всегда их любил за холодный рассчёт роботов, силу зомби, элитное вооружение и стайность пауков. А ну да, ещё тактичность человека.
Так же с них всё началось.
Задрал наверное уже своими детско-фанатичными вопросами ;P
Любитель Мечей, а бензу не хочешь? Только чтобы топливо расходовалось конечно!
Кто-То-Там, нет, мне надо холодное. Бензопила - это не круто, топор - вот что круто!
@Любитель мечей,
> Так вот, меня интересует такой вопрос: будет ли уделено больше внимания всяким там ножам, киркам и т.д., или же они так и останутся оружием, на если мало боеприпасов?
Да, в новой игре я хочу уделить большее внимание оружию, характеристикам персонажа, а так же возможности прокачивать своего героя. Таким образом будет больше разновидностей как огнестрельного так и холодного оружия. Буквально через 1-2 месяца, я надеюсь, что речь в постах как раз пойдет об игровых моментах, а не о технических тонкостях в разработки в которые я пока закопался с головой.
В общем, в новой игре хочется сделать огромное разнообразие оружия и экипировки которую можно будет надевать на игрока. В плане прокачки героя, инвентаря и экипировки — игра станет чуть больше похожей на Knighttron. Но, конечно же все не будет выглядеть один в один как было в Knighttron, только концепция.
Вообще, в новом Zombotron я хочу чуть больше приблизиться к концепции RPG, совместив все это с ураганным экшеном. В планах сделать не линейный мир с линейной историей, но помимо основного сюжета добавить какие-то необязательные локации и квесты выполнение и исследование которых принесет не только дополнительное развлечение, но и уникальные вещи для героя с прокачкой.
В общем, идей сейчас много, а как это все срастется по мере разработки — это мы все увидем чуть позже :)
@AlexKLS,
> Что с mipmaps творится можно посмотреть включив во вьюпорте mipmaps вместо shaded.
Спасибо за подсказку! Это отличный инструмент и повод проверить что с ними творится в 2D режиме. :)
@Кто-То-Там,
> Биороботов мы снова встретим?
Обязательно! Они чуть ли не основа всей вселенной Зомботрон! В новой игре будет несколько их разновидностей с разными способностями. А так же будут и просто совсем новые виды врагов.
@Кто-То-Там,
> Любитель Мечей, а бензу не хочешь?
В Z: Time Machine была машина-пила! :)
Машина -Пила то была, а родной древо(зомбо)резки не было . Стоит добавить(с топливом, и как бы не прекращаемыми ударами)
Хотелось бы увидеть на персонаже не только более-менее современную экипировку, но и самодельные варианты защиты. Это же касается и оружия. Например топор, сделанный из трубы и дисковой пилы, связанных вместе, думаю это было бы круто!
А будут ли в игре метательные оружия? Метательные копье, топор, нож?
@Никита,
>Хотелось бы увидеть на персонаже не только более-менее современную экипировку, но и самодельные варианты защиты.
Да, в новой игре ожидается не более 200 вещей для персонажа и не только. Так что есть высокая вероятность того, что можно будет сделать и низкокачественное оружие в виде топоров из смотанных труб и т.п.
Про метательное оружие мне пока сложно сказать. На текущем этапе были запланированы только гранаты и ножи (гранаты липучки), возможно топорики или бутылки еще какие. А вот копий точно не будет.
@Кто-То-Там,
> Стоит добавить(с топливом, и как бы не прекращаемыми ударами)
Хорошо. Я подумаю об этом! :)
Антон, да, с копьями я загнул)
@Ant.Karlov
>Убрал блоги которые не открывались
Зря убрали на самом деле. Эти блоги все еще есть в интернет-архиве, кому надо - мог бы смотреть их там. А теперь получается, что к ним никак не попасть.
@Ant.Karlov
>оружие в виде топоров
Не понимаю, как это можно сделать в Spine. Когда уже есть скелет для двуручного огнестрела в руках (с костью для оружия и ik-ограничениями). Делать новый скелет/проект для одноручного? Хитро настроить вложенность костей и аккуратно анимировать как есть? Расскажите!
@Аноним,
> Зря убрали на самом деле. Эти блоги все еще есть в интернет-архиве, кому надо - мог бы смотреть их там.
Не уверен что большинство умеет пользоваться интернет архивом. А ссылки ведущие на недоступные сайты — это всегда немного не приятно.
>Не понимаю, как это можно сделать в Spine. Когда уже есть скелет для двуручного огнестрела в руках (с костью для оружия и ik-ограничениями). Делать новый скелет/проект для одноручного?
Что-то однозначно по этому поводу мне пока сложно ответить. Но учитывая то что я написал в этой записи, становится очевидно что для разного типа оружия будут отдельные анимации. По скольку анимации тела теперь уже отделены от анимации ног, то получается что для каждого типа/вида оружия верхняя часть тела героя будет отдельно анимирована.
Спасибо за статью! Очень интересно наблюдать за разработкой!
>> Единственный недостаток : это необходимость установки каждого отдельного кадра вручную
Если заблокировать инспектор, то можно выделить сколько нужно спрайтов в окне проекта и перетащить их на поле size массива одним махом!
7 Мая 2016
— 19:13
#