Knighttron. Анимация персонажей

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

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

В любой современной игре, где игрок может находить какую-либо экипировку и применять её на себя — это обязательно должно сказываться на внешнем виде персонажа. И тут вряд ли для кого-то будет открытием, что в этом случае персонажи должны быть разделены на отдельные части, например: голова, туловище, руки, ноги, и чтобы что-то надеть или снять, необходимо просто менять отдельные части тела на заранее заготовленные графические объекты, соответствующие той или иной вещи или части тела. Все как всегда просто!

Хитрость номер один

На первый взгляд, я выбрал простейший вид top-down (сверху-вниз). Если смотреть на классические игры с таким видом, то можно увидеть, что в этом виде используется обычно как минимум 4 вида направления движения: вверх, вправо, вниз, влево. Соответственно для каждого направления должна быть и своя анимация: движение, атака, ожидание и т.п. Хорошо, что анимацию влево и вправо можно посчитать за одну, так как мы можем нарисовать, например, движение персонажа только вправо, а для движения влево, отражать зеркально анимацию перемещения вправо и так для всех анимаций.

Классическая анимация

Так следовало бы сделать и мне.

Но вот виды анимаций «вверх» и «вниз» все сильно усложняют. Поэтому я решил отказаться от отдельных анимаций для видов «вверх» и «вниз».

Отказ от направлений вверх и вниз

Но я отказываюсь от направлений «вверх» и «вниз», чем существенно упрощаю себе работу.

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

Отказ от видов «сзади» и «спереди» позволил мне не только сэкономить время на анимациях, но и решил кучу проблем с экипировкой персонажей. Представляете, что получилось если бы я делал честные виды — это не только для каждого врага куча работы над анимациями, но и для каждого ракурса нужно было бы рисовать свой вид экипировки, будь то щит, меч, шлем и тому подобное.

Правда, когда я решил отказаться от дополнительных видов, я еще не очень представлял себе, как это смотря своими большими честными глазами на игрока, персонаж побежит попой вперед!? :)

Составная анимация

Возвращаясь к теме анимаций: если вы наблюдаете за моей деятельностью, то наверное знаете, что я не работаю с классическим DisplayList во Flash и все то безобразие, которе мне удается устраивать в своих играх получается сделать достаточно быстрым только благодаря своим наработкам в виде Anthill Framework. Или проще говоря: до сих пор у меня не было наработок по кукольным анимациям, все что бегает и шевелится в моих играх — это заранее сделанный пререндер и, как правило, после пререндера ничего нельзя менять во внешнем виде персонажей. Конечно, мне довелось делать составных персонажей в Zombotron и чуть более проработанного главного героя в Fire Catcher. Но все это были быстрые решения, сляпанные как попало на коленке. Поэтому необходимо было тщательно проработать эту тему.

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

Из чего состоит герой

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

Далее, на этапе инициализации ресурсов игры простой код перебирает содержимое клипа анимации персонажа и для каждого кадра анимации считывается вся необходимая информация о положении частей тела и записываются в массив. Чтобы сократить количество информации об анимации и в будущем исключить дополнительную нагрузку на рендер при трансформации частей тела (сжатие, искажения и т.п.), я учитываю только простые данные такие как положение частей тела по x, y и angle.

В итоге класс анимации персонажа содержит в себе следующие данные для каждого кадра анимации:

Frame 1: 
    head(x:-8.7, y:-48.0, a:0);
    body(x:1, y:-23, a:8);
    handLeft(...);
    handRight(...);
    ...
Frame 2:
    head(x:-7.2, y:-47.0, a:1);
    body(x:1, y:-21.4, a:9);
    handLeft(...);
    handRight(...);
    ...

Далее остается только создать персонажа, назначить ему анимации и добавить части тела, например, так:

var hero:MyHero = new MyHero();
hero.addAnimation("walk", "HeroWalk_mc");
hero.addAnimation("stand", "HeroStand_mc");

hero.addPart("head", "DefHeroHead_mc»);
hero.addPart("body", "DefHeroBody_mc»);

Где, в первых строках мы устанавливаем для героя доступные анимации, а в следующих строках создаем части тела. Если при создании части вторым аргументом указать другое имя клипа, то можно будет легко подменить стандартную голову героя на что-либо еще, например на голову другого персонажа или вообще на тыкву!

Главный герой с головой зайца

Главный герой с головой зайца надетой как шлем.

Далее, по ходу существования персонажа в игре, части тела легко можно подменять на что-нибудь еще, используя следующий код:

hero.setPart("weapon", "GreatSword_mc");
hero.setPart("head", "PumpkinHelmet_mc");

Согласно идеи Anthill Game Framework — все части тел для персонажей, включая экипировку, заранее рендерятся в битмапы и лежат где-то в памяти. А из клипов с анимациями заранее построены массивы координат и тоже лежат где-то в памяти. Таким образом, в самом коде используются только текстовые имена клипов типа «HeroWalk_mc», чтобы как-то идентифицировать заранее кэшированные данные — это позволяет мне понимать, с чем я имею дело.

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

Скелеты в разной экипировке

Так выглядит один и тот же враг «скелет» в разной экипировке.

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

Уже жду не дождусь, когда добавлю в игру какого-нибудь оборотня, чтобы подобрать выпавшую с него голову и надеть на героя! Или Пирата — у него с руки можно будет снять крюк! :)

Хитрость номер два

Вторая хитрость заключается в экипировке и вещах. Тут пришлось хорошенько думать и оптимизировать работу заранее, чтобы потом не вляпаться в проблемы. Оптимизация заключается в том, что вещь или элемент экипировки должны быть простыми в создании. Основная идея заключается в том, что вещь должна иметь фактически одну иконку на все! То есть, если я нарисовал ножик, то он должен в таком виде отображаться в инвентаре, в том же виде экипироваться на героя, и в таком же виде выпадать на игровое поле — это ключевые условия, чтобы не состариться пока работаешь над контентом для игры, рисуя для каждой вещи кучу иконок. Как раз, благодаря этой самой идее в игре получился такой не привычный инвентарь, в котором каждая вещь имеет произвольный размер и занимает разное количество клеточек. От части, по этой же причине вещи перекрывают друг-друга в инвентаре: мне показалось проблематичным маштабировать каждую вещь под определенное количество клеток.

Инвентарь

Вещи имеют произвольный размер, а сетка лишь помогает выравнивать вещи внутри окна и показывает возможность перемещения вещей.

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

Хитрость номер три

Далее, используя всю эту систему я хотел очень круто схитрить, сделав только по одному виду анимации для всех видов врагов и игровых персонажей — ведь анимация почти «скелетная»! Меняй части тела и получай новых персонажей. Но уже при попытке использовать анимацию главного героя для скелета вылезли некоторые нестыковки — я конечно их быстро поправил, изменив внешний вид Скелета. Но все это вело к тому, что все персонажи должны быть слишком стандартизированы и от этого они могут потерять свою уникальность и узнаваемость. Поэтому данная хитрость работала далеко не всегда и не для всех персонажей и врагов.

Агент тайной полиции

Агент тайной полиции. Данный персонаж радикально отличается от главного героя, таким образом анимации главного героя не подойдут для него как есть.

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

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

Другие записи из этой серии

  1. С чего все начиналось
  2. Ландшафтные приключения
  3. Анимация персонажей
  4. Поиск пути
  5. Физика в Knighttron
  6. Продолжение следует...

 


Индикаторы: Уроки, Разное
Постоянная ссылка

 

 

У меня на такой "хитрости" вся работа построена, правда, у меня не смена клипов головы реализована, а смена кадров внутри головы на нужный с нужной картинкой, но я отдаю себе отчёт в том, как удобней кастомеру, и в следующий раз буду делать смену клипами.

Murlyka
20 Августа 2015
— 00:02
#

Будете ли вы выкладывать ваши новые дополнения для Anthill в вики движка или на гитхаб?

Георгий
20 Августа 2015
— 01:49
#

Извините за нестранный вопрос, а на каком cms работает ваш блог?

Anon
20 Августа 2015
— 01:51
#

Хз, такой растянутый пост об очевидном.

С анимацией вообще костыль. Есть Spine или DragonBones бесплатный. С очевидными преимуществами и экономией кучи времени.

Haas
20 Августа 2015
— 09:03
#

@Murlyka, с кадрами не очень удобно работать, я считаю что смена клипов (спрайтов) намного универсальнее чем кадры — проще контролировать вещи: добавлять новые, удалять старые и т.п.

У меня есть вещи которые могут менять внешний вид сразу для нескольких частей тела, например, броня: меняет внешний вид тела и правого и левого рукавов. Бывает и такая броня которая может менять только внешний вид тела и левого рукава. Как в этом случае быть с кадрами?

Вот скриншот редактора вещей. Как видно в окне по середине, я просто указываю часть тела и имя клипа который заменит часть тела своим представлением. Справа в список всех клипов доступных для использования. То есть проще говоря, получается большой такой универсальный конструктор вещей.

Ant.Karlov
20 Августа 2015
— 10:02
#

@Георгий,

> Будете ли вы выкладывать ваши новые дополнения для Anthill в вики движка или на гитхаб?

Да, буду, необходимо только некоторые вещи поправить, улучшить и т.п. — это все в отношении анимаций. А все остальные улучшения для Anthill которые необходимо было сделать по ходу разработки этой игры, уже доступны на GitHub в nightly ветке.

Ant.Karlov
20 Августа 2015
— 10:05
#

@Anon,

> на каком cms работает ваш блог?

Своя самописная CMS — писал давно когда еще занимался разработкой сайтов :)

Ant.Karlov
20 Августа 2015
— 10:06
#

@Haas,

> Хз, такой растянутый пост об очевидном.

Спрашивали детали о разработке игры, вот я и пишу как есть. То что многие вещи могут быть для большинства читателей очевидными — это нормально.

> С анимацией вообще костыль. Есть Spine или DragonBones бесплатный. С очевидными преимуществами и экономией кучи времени.

На создание необходимых классов для своих составных анимаций я потратил 2 дня. Благо свой редактор анимаций мне писать не пришлось. А Spine платный, да и зачем мне Spine если я привык использовать Flash IDE? В любом случае, не думаю что мне потребовалось бы меньше времени чтобы подключить какой-нибудь DragonBones к Anthill.

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

Ant.Karlov
20 Августа 2015
— 10:14
#

>На создание необходимых классов для своих составных анимаций я потратил 2 дня.

Ну да, а потом еще и редактор вещей?)

>Но суть тут в другом: бесплатный DragonBones универсальная штука которая считывает все данные от трансформациях частей тела

И в чём проблема? У тебя такие же трансформации x,y, угол, масштаба, скейла, только нет. В DB есть кеширование трансформ.
При чём тут прораммный рендер? Всё также двигаются битмапки как и везде. Там и прикручивать нечего.

Мне в принципе без разницы кто и что использует, просто не люблю костыли

Hass
20 Августа 2015
— 11:39
#

@Hass,

> Ну да, а потом еще и редактор вещей?)

Редактор вещей не имеет отношения к составным анимациям — это редактор БД где хранится информация о том какая вещь какие модификации применяет на героя, включая изменение внешнего вида. Не более того.

> И в чём проблема? У тебя такие же трансформации x,y, угол, масштаба, скейла, только нет.

В моем случае используется только x, y и angle для части тела. Остальные трансформации дают лишнюю нагрузку на программный рендер (в случае с аппаратным рендером такие вещи как скэйл, угол, матрица трансформаций — ложатся на плечи видео процессора, а с программным рендером даже поворот спрайта дает ощутимую нагрузку, не говоря уже об остальных модификаторах). Так вот DragonBones вероятно заточен под аппаратные движки.

> Мне в принципе без разницы кто и что использует, просто не люблю костыли

В моем случае, создание класса для проигрывания составных анимаций не является костылем — это просто расширение возможностей Anthill. В противном случае весь Anthill можно считать здоровенным костылем! :)

Ant.Karlov
20 Августа 2015
— 13:00
#

Я тоже считаю, что в таком большом проекте (притом изначально ориентированном на эксклюзив, а не виральную версию!) надо было сразу переходить на Starling и Dragon Bones. Так и на Юнити было бы потом легче перейти, и во флешке было бы 60FPS, и не было бы описанной проблемы с масштабированием в инвентаре, ведь скейлинг, поворот, скос и даже колортрансформ становится бесплатным.

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

Эта статья Антона мне напомнила статью с Хабра: http://habrahabr.ru/post/142126/

VVVVVV
20 Августа 2015
— 15:00
#

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

samana
20 Августа 2015
— 17:24
#

Низкий поклон!
Меня так зацепили эти непонятные наборы букв и цифр на картинках может и мне разработкой заняться,а то только в Scratch и Visual Basic умею кое как работать.А интересно вообще? Просто Visual Basic я забросил скучно до ужаса хотя наверное нужно просто разобраться получше.Ещё планирую в Python поработать, надеюсь интересно будет.Просто понятно что результат будет крутой если постараться,но в процессе похоже можно умереть от скуки или нет?

SQUASH
20 Августа 2015
— 18:21
#

Здравствуйте, Антон!

Очень заинтересовал меня ваш движок Anthill - безумно простой в пользовании даже без полностью заполненной вики. За что вам большое спасибо, быть может, именно на вашем фреймворке буду работать над своим проектом.
Будете ли вы когда-нибудь адаптировать Anthill под Starling? Либо же прикручивать аппаратное ускорение, для хорошей производительности на мобильных телефонах и планшетах?

Сникерс
20 Августа 2015
— 22:14
#

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

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

Перекрашивание происходит с помощью штатного класса ColorTransform.

Как лучше хранить эти все значения?
1. Сделать на каждый цвет/форму свой кадр и затем растеризировать?
2. Сделать на каждый цвет/форму свой мувиклип и затем растеризировать?
3. Или можно как-то перекрасить скин ГГ уже после его растеризации?

Просто если первые два случая... Это мне надо, как вы сказали, состариться =) Ведь в целом около 2000 разных скинов можно сделать, если учитывать все-все настройки.
Или что вы можете посоветовать в этом случае?

Заранее огромное спасибо!

Георгий
21 Августа 2015
— 00:39
#

@Ant.Karlov с кадрами там весело:) Есть клип под названием hero_base, и в нём просто статичный персонаж, с раскиданным по слоям клипами частей тела. Каждая часть тела part это клип, внутри которого есть мувиклип part_container, в свойствах которого выставлен тип graphic.

Таким образом, меняя в свойствах part_container номер кадра, он меняется во всех клипах hero_animation. То же и с цветом, например волос. Проблема в том, что (а) приходится придерживаться универсальности (парные конечности — один и тот же клип, всегда), (б)много трудностей с поиском нужного кадра, для комбинированного сета.

Могу для теста скинуть kit как раз свой, чтобы запутаться окончательно с моих объяснений — http://murlyka.com/kit

В любом случае, я буду переделывать под систему похожую с твоей — каждой отдельной шмотке свой mc_ (привет, DB-стайл).

Кстати, мой скриншот окна интерфейса переодевалок (который нарисован, но не работает) — https://www.dropbox.com/s/p3r3b0cpmhsnc3s/2015-08-21_16h49_17.png?dl=0

Murlyka
21 Августа 2015
— 09:51
#

Спасибо, Антон, за пост)
Ждем больше новых статей! Интересно так же зачем нужна эта Entity Architecture, может тоже хотяб чуть чуть затронешь эту тему.

GreenFest
21 Августа 2015
— 20:06
#

GreenFest - про Entity можно почитать в замечательной книжке http://gameprogrammingpatterns.com/
Там и про другие паттерны проектирования можно прочитать.

WeslomPo
21 Августа 2015
— 20:12
#

@WeslomPo, Спасибо, как нибудь надо почитать) Но мне именно интересно с точки зрения Антона, просто он в предрелизном посте написал "осознал, что если бы я не осуществил этот переход и не потратил на него несколько месяцев — я бы не закончил эту игру никогда!"
Вот мне и интересно, что такого в этом подходе, что кардинально изменило разработку =)

P.S. Только у меня не с первого раза капча работает? Может я конечно слепой, но почти всегда с первого раза ошибаюсь о_О

GreenFest
21 Августа 2015
— 22:12
#

@VVVVVV,

> Я тоже считаю, что в таком большом проекте (притом изначально ориентированном на эксклюзив, а не виральную версию!) надо было сразу переходить на Starling и Dragon Bones.

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

А так я бы с радостью уже давно бы перешел на аппаратное ускорение. Но вот как-то все не получается :)

Ant.Karlov
22 Августа 2015
— 09:56
#

@SQUASH,

> Просто Visual Basic я забросил скучно до ужаса хотя наверное нужно просто разобраться получше.

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

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

Попробуйте найти интересный для себя проект.

Ant.Karlov
22 Августа 2015
— 10:01
#

@Сникерс,

> Будете ли вы когда-нибудь адаптировать Anthill под Starling? Либо же прикручивать аппаратное ускорение, для хорошей производительности на мобильных телефонах и планшетах?

Как раз в ближайшее время решится этот вопрос. Думаем на тему того чтобы переписать Anthill под аппаратный рендер (возможно с использованием Starling или Genome2D), но спонсоры/издатели настойчиво уговаривают переходить на Unity.

Ant.Karlov
22 Августа 2015
— 10:03
#

@Георгий,

> 1. Сделать на каждый цвет/форму свой кадр и затем растеризировать?
2. Сделать на каждый цвет/форму свой мувиклип и затем растеризировать?
3. Или можно как-то перекрасить скин ГГ уже после его растеризации?


Лучше конечно третий вариант. Перекрасить уже кэшированную анимацию можно используя свойство color у AntActor, например:

actor.color = 0xFF0000;

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

Ant.Karlov
22 Августа 2015
— 10:09
#

@Murlyka,

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

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

Ant.Karlov
22 Августа 2015
— 10:14
#

@GreenFest, про Entity через несколько записей уже расскажу, как раз именно подробно о том почему это решение хорошо подошло к этому проекту, и почему оно может хорошо подойти и для многих других проектов.

Я капчей чаще всех пользуюсь — всегда с первого раза у меня проходит! :) Может в браузере дело? Какой у вас браузер? Я проверю.

Ant.Karlov
22 Августа 2015
— 10:17
#

@Ant.Karlov, Firefox, может я и правда слепой, или я робот :D
Но как то обидно что я ошибаюсь часто, 4 цифры ввести вроде должно быть просто, да и спорных вариантов в этой капче не бывает почти.

GreenFest
22 Августа 2015
— 11:57
#

Starling в последнее время практически догнал Genome2D по производительности, поэтому сегодня имеет смысл брать Старлинг - больше документации и меньше багов. Но в долгосрочном периоде всё равно придется переходить на Юнити, как ни крути. Ведь на консоли AIR не могёт.

VVVVVV
22 Августа 2015
— 14:43
#

Спасибо, Антон, за ответ насчет смены цвета. Да, анимации в этих клипах нет =)

А по поводу юнити - как по мне, игры на юнити штампуются сейчас тоннами, чуть ли не каждым школьником. Порог знаний - минимален.
А вот на флеше сейчас писать игры - это надо уметь, скажем так. Хоть и некоторые называют это все дело костылями, согласитесь - флеш по своему прекрасен.
И ведь графику все равно во флеше рисовать будете...

Георгий
22 Августа 2015
— 21:13
#

@Георгий,

> А по поводу юнити - как по мне, игры на юнити штампуются сейчас тоннами, чуть ли не каждым школьником. Порог знаний - минимален.
А вот на флеше сейчас писать игры - это надо уметь, скажем так.


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

Ant.Karlov
23 Августа 2015
— 10:47
#

@Ant.Karlov, знаешь почему я не хочу чтоб ты уходил с флеша?) Потому что тогда anthill умрет и не будет обновляться, а я не нем сейчас пишу..
А уж как бы я хотел, чтоб ты сделал в нем аппаратное ускорение)))

GreenFest
23 Августа 2015
— 12:43
#

Здравствуйте. У меня похожий вопрос, как у Георгия выше, но немного по другому...

Подскажите, пожалуйста, как можно сделать примерно такое в Anthill:
Имеется мувиклип "А" флешевый. В нем еще, допустим, 5 мувиклипов "Б". У каждого мувиклипов "Б" есть несколько кадров, кадрами которых нужно управлять автономно.
При этом, все мувиклипы "Б" внутри "А" - анимированы.

Что-то вроде "анимации внутри анимации". Если я растеризирую "А", то я уже не могу получить доступ к кадрам "Б".

Я пытался сделать анимацию внешнюю анимацию с помощью кода - что-то как-то это слишком муторно (кадров 50, на каждый кадр мне вручную прописывать позицию и угол?)

Надеюсь вы меня поняли о_о

Milka
23 Августа 2015
— 15:48
#

@Milka
Мне кажется варианта два:
1. делать так как в статье, считывая автоматически все перемещения и создавая AntActor`ы на каждый мувиклип "Б"
2. создавать экземпляр мувиклипа "А" программно, менять кадры мувиклипов "Б" и растеризировать.

.nodoxi
23 Августа 2015
— 20:37
#

А мне кажется аппаратное ускорение в AntHill и не нужно, движок и так очень производительный.

Вот, например, AntHill+Nape физика:
Crimsonwood - в свободное время понемногу пилю.

.nodoxi
23 Августа 2015
— 22:16
#

@.nodoxi

Спасибо =) Хоть и к нынешнему времени меня уже осенило, как это сделать. Зато убедился, что иначе на данный момент не сделать.
Пробовал оба способа, кстати.
Первый способ, который вы описали, мне как-то ближе, поэтому выбрал его.

Игрушка у вас, кстати, довольно-таки интересная, что-то засел, добавил в закладки 👍
Иногда замечаются фризы, когда слишком много врагов, но не критично. С гпу, думаю, их бы не было. И Аппаратное ускорение скорее актуально для мобильных устройств.

Milka
24 Августа 2015
— 00:04
#

@Milka,

> Имеется мувиклип "А" флешевый. В нем еще, допустим, 5 мувиклипов "Б". У каждого мувиклипов "Б" есть несколько кадров, кадрами которых нужно управлять автономно.
При этом, все мувиклипы "Б" внутри "А" - анимированы.


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

Ant.Karlov
24 Августа 2015
— 11:29
#

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

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

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

Сейчас, единственное что меня двигает на создание аппаратной поддержки в Anthill — это лень изучать другие движки, возможность писать на уже привычном языке (as3) и в привычном рабочем окружении :)

Ant.Karlov
24 Августа 2015
— 11:37
#

@Ant.Karlov,

Я думаю многим лень изучать другие языки и среды разработок. Поэтому мы все просим вас продолжать работу над Anthill :) Без вас существование Anthill не будет процветать.

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

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

Milka
24 Августа 2015
— 15:11
#

@Ant.Karlov
> но спонсоры/издатели настойчиво уговаривают переходить на Unity.

Можно подробнее пожалуйста?

Насколько мне известно Chrome полностью отказывается от какого то плагина на котором вэб плеер юнити работает. Как читал на форумах фгл, у некоторых спонсоров, игры после отключения, потеряли 50 процентов пользователей. Y8 games создали тему в начале года с призывом порты на WebGL делать из unity5, но не похоже что они их покупают. у WebGL порта проблемы с утечкой памяти и команда юнити с нетерпением ждёт когда майкрософт выпустит кроссбраузерный плагин assembly, чтобы все проблемы WebGL порта решить, но случится это, если верить роадмапу юнити, не раньше лета 2016. Вот и интересно почему спонсоры просят на юнити переходить? если из за мобилок то понятно) а так не очень понятно.

AlexKLS
25 Августа 2015
— 00:14
#

Как по мне, Unity актуален только с 3D графикой. Практически любые прихоти 2D графики вполне можно реализовать в AIR + Скворец, к примеру, ну или любой другой фреймворк с поддержку GPU. Надеюсь, Муравейник так же получит вышеупомянутое аппаратное ускорение.

Скорость Anthill местами практически сопоставима с фреймворками с графическим ускорением. Я даже боюсь представить, какого монстра вы соорудите, если прикрутите GPU... Ох, хотелось бы посмотреть на это, хотелось бы =) А на Unity всегда успеете перейти, если нужно будет.

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

wapif
25 Августа 2015
— 04:31
#

@.nodoxi, Вау! Шикарные наработки! Это может выльется в отличную игру.

@Ant.Karlov, Насчет Anthill, я думаю что он больше заточен под игры вид сбоку.. я вот сейчас делаю на нем rts, вид сверху, и естественно множество юнитов, которые постоянно вращаются. И разумеется это работает медленнее, чем если бы они только двигались) Да и выглядит это хуже, чем если бы всё было в векторе..
А так как я хотел бы выйти на мобилки, то очень надеюсь на "аппаратное У". Может я буду так долго пилить игру, что Вы уже реализуете его =))

GreenFest
25 Августа 2015
— 21:41
#

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

Ant.Karlov
1 Сентября 2015
— 10:22
#

@wapif, да, согласен с вами. Я тоже считаю что если уж и переходить на Unity, то для этого должен быть по настоящему серьезный повод. Например необходимость использовать 3d графику в играх, в остальном же цена перехода на новую технологию будет несравненно дороже и при этом возможности в плане 2D графики Unity предлагает все теже самые что и Starling + AIR.

Саму же популярность и модность Unity в расчет не берем! :)

Ant.Karlov
1 Сентября 2015
— 10:26
#

@GreenFest,

> и естественно множество юнитов, которые постоянно вращаются. И разумеется это работает медленнее, чем если бы они только двигались) Да и выглядит это хуже, чем если бы всё было в векторе..

Да, поворот картинок/спрайтов будет медленным. Но, если разворачиваемые объекты не имеют своих анимаций, то их развороты можно кэшировать (сделать анимацию поворота и потом переключать только кадры), тогда все будет работать быстрее. В любом случае аппаратное ускорение все эти проблемы решит.

Ant.Karlov
1 Сентября 2015
— 10:29
#