FALOSOPHY
Я тут разговорился сам с собой и мой диалог поддержал Hanabishi, но чем дальше я думал и говорил, тем больше мне пекло от очевидности и несправделивости.
Собственно, это некая заметка из будущего если можно так выразиться, но учитывая что игровой рынок, с точки зрения "процесса самовоспроизведения", упускает важную вещь - игры привязывают игроков к своим движкам, а отдельные игровые движки ограничивают или порогом входа или возможностями(речь о конструкторах 2Д игр), то вполне логично вытекает вывод, что у рынка образуется пустующая ниша, которая ждет чего-то, что будет напоминать симбиоз редактора WE и Construct 2.
Просто не понятно, почему до сих пор не появился редактор с возможностью использовать 3D, как это делает редактор WC3, и с тем же принципом работы, который заложен в Construct2 - когда на сцену можно добавить объект какого-либо заложенного типа (спрайт, звук, интерфейс, управление, скрипт и т.д.) и настроить ему поведения и свойства этого поведения. а потом с помощью визуального редактора описать взаимодействия? Никакого жанрового ограничения, максимальная доступность к изменениям, сложность которых будет зависеть напрямую от глубины (допустим движок поддерживает одни шейдеры, а девелоперу нужны другие - пожалуйста, покупай про-версию, и пиши свои шейдеры).
Упреждая кукареки на тему того что это нерентабельно, я лишь скажу, что первый вариант своего конструктора Scirra выпустила в 2007 году, и на данный момент делает 3 версию движка, а известный всем WC3 жив, исходя из масштабов патчей, которые внезапно вылезли, спустя 15 лет во многом благодаря огромным возможностям его редактора.
В общем, если ищете способ обеспечить себе и своим детям хорошую жизнь - этот способ один из верных вариантов.
prog:
prog:
prog:
Ред. prog
Я согласен, что здесь возникает проблема - если модели людей анимировать плюсминус можно под одну гребенку, то вот с чем то 6-руким и треххвостым уже будут проблемы. С другой стороны - это решается коммьюнити.
prog:
Это не взлетело вот поэтому. Потому что это была игра для создания игры. И рынок хавал это как сандбокс игру-адвенчуру. А не как движок.
Ред. prog
Но.
давай посмотрим как это уже сделано у кого либо.
Мы знаем что у вара анимы зашиты в модель и привязаны к некой жанровости и ею же ограничены. Если мы хотим чтобы у юнита появилась новая анимация - мы редактируем целую модель. Это решение неплохо для ртс, но в жанре РПГ такое решение будет ограничивать. возникает @.
Возьмем юнити - там мы используем модель с готовыми анимациям, однако возможностей уже гораздо больше, так как можно прикрутить физику к объекту и в целом играть со скелетной анимацией. Однако кастомизировать это тоже не просто.
Упрощенный вариант - 2д конструкторы типа гейммейкера и С2 - там ты просто рисуешь условную гифку для спрайта.
Во всех примерах общее одно - инструмент работы с анимациями должен быть, но он не укладывается в волшебную кнопку "сделать круто"
и тут вопрос лишь в том, как ограничить это, чтобы оставить наибольшее поле для удобства и простоты использования?
Вероятно, наиболее разумным вариантом в данном случае было бы использование уже моделей с уже имеющимися анимациями, с возможностью их дополнения новыми.
Ред. uranus
и он нафиг никому не нужен, но все.Исходя из требований поведения - распределяем. (набор аним же для юнита отличается в шутере и в ртс, не так ли?)
Все осталось - добавляем как доп анимации, которые будут проигрываться на манер stand-1/2/3 в варе.
Ред. prog
Мы можем добавить в нее объект-пустышку (представь фиолетово-черный варовский кубик в черном пространстве).
Для начала придаем объекту форму - условно говоря превращаем "ничто" в модель - загружаем внешний какой то файл.
Затем мы должны определить роль этого объекта в этом мире - что это будет. Допустим мы делаем ртс, и это у нас юнит. Ок. Тогда мы должны дать ему поведение RTS, которая даст этому объекту все необходимые базовые свойства объекта из жанра RTS. Среди которых будут анимации естественно.
Поведение знает некие обязательные требования жанра RTS - юнит должен ходить, стоять, атаковать, применять некую способность и умирать. Это базовый минимум объекта с поведением RTS - и этим функциям нужно назначить анимации. В модели мы распознали анимации ходьбы, атаки, стояния, каста, смерти, а также анимацию ожидания. Мы распределяем имеющиеся анимации по требованиям поведенич RTS, а для оставшейся анимации создаем к примеру "пустое" требование, чтобы в дальнейшем к нему обращаться из скриптов, или же заносим в качестве второй анимации к анимации стояния. Получается что мы распределили требуемые поведением анимы, а одному требованию назначали 2 анимации, которые будут проигрываться в случайном порядке или поочередно.
Ред. prog
Тут фишка просто в том, чтобы сделать базовую логику, которая без вмешательства в код будет работать как в простом RTS. В случае надобности мы легко наследуем нужный класс, делаем нужные манипуляции в коде и просто подменяем.
Объект, который мы вытаскиваем на сцену - не обяательно должен быть использован на этой сцене, но он может быть использован игрой. Нам ничего не мешает например скрыть этот объект, или задать его как мастер-объект, который не будет при инициализации находиться на сцене, но система будет знать об этом объекте и при необходимости сможет создать его инстанс
Даже анриловские блюпринты в этом плане и то удобней - они хотябы лежат в ассетах, именованы и их можно искать/фильтровать. Правда редактирование всеравно сродни порнографии если свойства кажого типа юнитов внутри отдельного блюпринта задаются.
Ред. prog