Добавлен , опубликован
Я тут разговорился сам с собой и мой диалог поддержал Hanabishi, но чем дальше я думал и говорил, тем больше мне пекло от очевидности и несправделивости.
Собственно, это некая заметка из будущего если можно так выразиться, но учитывая что игровой рынок, с точки зрения "процесса самовоспроизведения", упускает важную вещь - игры привязывают игроков к своим движкам, а отдельные игровые движки ограничивают или порогом входа или возможностями(речь о конструкторах 2Д игр), то вполне логично вытекает вывод, что у рынка образуется пустующая ниша, которая ждет чего-то, что будет напоминать симбиоз редактора WE и Construct 2.
Просто не понятно, почему до сих пор не появился редактор с возможностью использовать 3D, как это делает редактор WC3, и с тем же принципом работы, который заложен в Construct2 - когда на сцену можно добавить объект какого-либо заложенного типа (спрайт, звук, интерфейс, управление, скрипт и т.д.) и настроить ему поведения и свойства этого поведения. а потом с помощью визуального редактора описать взаимодействия? Никакого жанрового ограничения, максимальная доступность к изменениям, сложность которых будет зависеть напрямую от глубины (допустим движок поддерживает одни шейдеры, а девелоперу нужны другие - пожалуйста, покупай про-версию, и пиши свои шейдеры).
Упреждая кукареки на тему того что это нерентабельно, я лишь скажу, что первый вариант своего конструктора Scirra выпустила в 2007 году, и на данный момент делает 3 версию движка, а известный всем WC3 жив, исходя из масштабов патчей, которые внезапно вылезли, спустя 15 лет во многом благодаря огромным возможностям его редактора.
В общем, если ищете способ обеспечить себе и своим детям хорошую жизнь - этот способ один из верных вариантов.
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
24
6 лет назад
0
Fakov, мне кажется ты опять упускаешь из вида важную деталь - кто и как должен определять какая анимация должна воспроизводиться в каждый конкретный момент времени? В варе все просто - у юнита есть стандартный набор состояний, согласно которым движок дергает анимации, но этот набор состояний у вара специфичен для RTS и весьма ограничен, даже с учетом возможности влиять на анимации тегами.
0
8
6 лет назад
Отредактирован uranus
0
Лень читать комменты, но разве редактор карт в SC2 не самый продвинутый на данный момент? Да, порог вхождения многократно выше и он нафиг никому не нужен, но все.
0
24
6 лет назад
0
Лень читать комменты
Видимо, лень тебе читать не только комменты, но и сам пост, иначе ты бы понимал почему SC2 не подходит под запросы автора.
0
32
6 лет назад
0
кто и как должен определять какая анимация должна воспроизводиться в каждый конкретный момент времени?
Считываем набор анимаций.
Исходя из требований поведения - распределяем. (набор аним же для юнита отличается в шутере и в ртс, не так ли?)
Все осталось - добавляем как доп анимации, которые будут проигрываться на манер stand-1/2/3 в варе.
0
24
6 лет назад
Отредактирован prog
0
Fakov, расскажи подробней о "распределении" и "требованиях поведения" и как это решает проблему сложности использования аналогичных механизмов в юнити и анриле.
0
32
6 лет назад
0
prog:
Fakov, расскажи подробней о "распределении" и "требованиях поведения" и как это решает проблему сложности использования аналогичных механизмов в юнити и анриле.
Ну смотри. У нас есть некий мир - глобальная пустота.
Мы можем добавить в нее объект-пустышку (представь фиолетово-черный варовский кубик в черном пространстве).
Для начала придаем объекту форму - условно говоря превращаем "ничто" в модель - загружаем внешний какой то файл.
Затем мы должны определить роль этого объекта в этом мире - что это будет. Допустим мы делаем ртс, и это у нас юнит. Ок. Тогда мы должны дать ему поведение RTS, которая даст этому объекту все необходимые базовые свойства объекта из жанра RTS. Среди которых будут анимации естественно.
Поведение знает некие обязательные требования жанра RTS - юнит должен ходить, стоять, атаковать, применять некую способность и умирать. Это базовый минимум объекта с поведением RTS - и этим функциям нужно назначить анимации. В модели мы распознали анимации ходьбы, атаки, стояния, каста, смерти, а также анимацию ожидания. Мы распределяем имеющиеся анимации по требованиям поведенич RTS, а для оставшейся анимации создаем к примеру "пустое" требование, чтобы в дальнейшем к нему обращаться из скриптов, или же заносим в качестве второй анимации к анимации стояния. Получается что мы распределили требуемые поведением анимы, а одному требованию назначали 2 анимации, которые будут проигрываться в случайном порядке или поочередно.
0
24
6 лет назад
Отредактирован prog
0
Fakov, погоди, если это ртс, то мы не можем каждого юнита таскать на сцену чтобы задать его поведение и характеристики - это порнография какая-то получится, а не разработка. Саму суть идеи я понял, но эта операция ну никак не может быть привязана к работе с объектом на сцене, если "движок" рассчитан на что-то сложнее пакмана или арканоида.
0
15
6 лет назад
0
А разве не будет идеальным решением в этом случае написание того же плагина под UE4, который позволяет реализовать взаимодействие с любым обьектом на сцене, благо анрил не ограничивает такое. Таким образом ставя плагин нам подгружаются нужные базовые класы, по типу тех же юнитов, абилок, итемов и т.д., сами же сущности можно редактировать прямо на сцене через созданный UI для этого, как уже реализованы те же плагины для создания и удобного редактирования мешей и сплайнов на сцене.
Тут фишка просто в том, чтобы сделать базовую логику, которая без вмешательства в код будет работать как в простом RTS. В случае надобности мы легко наследуем нужный класс, делаем нужные манипуляции в коде и просто подменяем.
0
32
6 лет назад
0
prog:
Fakov, погоди, если это ртс, то мы не можем каждого юнита таскать на сцену чтобы задать его поведение и характеристики - это порнография какая-то получится, а не разработка. Саму суть идеи я понял, но эта операция ну никак не может быть привязана к работе с объектом на сцене, если "движок" рассчитан на что-то сложнее пакмана или арканоида.
почему????
0
24
6 лет назад
0
Fakov, в ртс одни юниты могут создавать других в рантайме, в том числе таких которых изначально не было на сцене, причем желательно чтобы однотипные юниты созданые разными способами получались одинаковыми - прототипы должны храниться отдельно от сцены, причем желательно в удобном для просмотра и редактирования виде. И это я еще молчу про оптимизацию.
0
32
6 лет назад
0
prog:
Fakov, в ртс одни юниты могут создавать других в рантайме, в том числе таких которых изначально не было на сцене, причем желательно чтобы однотипные юниты созданые разными способами получались одинаковыми - прототипы должны храниться отдельно от сцены, причем желательно в удобном для просмотра и редактирования виде. И это я еще молчу про оптимизацию.
Отлично, это условие жанра просто должно учитываться поведением объекта.
Объект, который мы вытаскиваем на сцену - не обяательно должен быть использован на этой сцене, но он может быть использован игрой. Нам ничего не мешает например скрыть этот объект, или задать его как мастер-объект, который не будет при инициализации находиться на сцене, но система будет знать об этом объекте и при необходимости сможет создать его инстанс
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.