Движок 3D игор

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


Views: 2 460

prog #1 - 3 years ago 2
Голосов: +2 / -0
Максимальная доступность к изменениям и простота освоения и использования вещи практически не совместимые. Тот же WC3 очень сильно ограничивает пользователей в возможностях, за счет чего и становится возможной та самая ламповость и простота. Например, сетевой код полностью скрыт от пользователя и оптимизирован под RTS с фиксированным кол-вом игроков, без малейшего шанса как-то на это повлиять, в то время как под разные задачи должны применяться разные алгоритмы сетевого взаимодействия. Или вот более наглядный пример: модели в варе это монолитные сущности, с вшитыми анимациями, текстурами и свойствами материала, в то время как в современных движках модель отделена от анимаций и при совместимости скелетов одну анимацию можно использовать на любой модели без редактирования модели, также от модели отделены и материалы с текстурами - к любой модели при желании можно применить любой материал. Не менее показательно использование анимаций в WC3 - определенные действия всегда вызывают определенные анимации, без вменяемой возможности на это повлиять, в то время как движок позволяет определить любому объекту любой набор анимаций, условий их воспроизведения и генерируемых при этом событий, но ценой необходимости разбираться как вся эта система анимаций работает и необходимости настраивать анимации каждому объекту по отдельности.
Fakov #2 - 3 years ago 0
Голосов: +0 / -0
Максимальная доступность к изменениям и простота освоения и использования вещи практически не совместимые.
Генри Форд так же думал, при этом он не был первым кто делал машины, но он стал первым, кто избавился от того, что мешает сделать машины массовым продуктом. Эпл тоже была не первой, кто предпринял попытку создания цифрового магазина музыки, однако она сделала это избавившись от недостатков остальных, и добавив недостающих удобств, создав новую ценность.
Тот же WC3 очень сильно ограничивает пользователей в возможностях, за счет чего и становится возможной та самая ламповость и простота.
Ламповость тут не причем ,а простота - это результат грамотной структуры редактора.
prog:
Например, сетевой код полностью скрыт от пользователя и оптимизирован под RTS с фиксированным кол-вом игроков, без малейшего шанса как-то на это повлиять, в то время как под разные задачи должны применяться разные алгоритмы сетевого взаимодействия.
Я вижу в этом "ассетное" коммерческое решение - хочешь чтобы у тебя была онлайн-ртс - пожалуйста, 99$ и скрипт под ртс весь твой. Хочешь новый NFS - пожалуйста, 99$ и скрипт для мультиплеерных гонок твой - только настрой UI и определи константы.
prog:
Или вот более наглядный пример: модели в варе это монолитные сущности, с вшитыми анимациями, текстурами и свойствами материала, в то время как в современных движках модель отделена от анимаций и при совместимости скелетов одну анимацию можно использовать на любой модели без редактирования модели, также от модели отделены и материалы с текстурами - к любой модели при желании можно применить любой материал.
Вот это отличный минус в пользу предложенного движка, и тем не менее я задамся вопросом необходимости ИЛИ вопросом "что плохого в цельной сущности"? Да, модель с готовыми анимациями и текстурами в какой-то степени это ограничение, но использование любого популярного формата моделей сведет на нет проблемы с моделлингом, как это в конце концов произошло с варом, создав 9000 ед. контента. да-да, я в курсе, что у вара изза игры огромное коммьюнити, и тем не менее.
prog:
Не менее показательно использование анимаций в WC3 - определенные действия всегда вызывают определенные анимации, без вменяемой возможности на это повлиять, в то время как движок позволяет определить любому объекту любой набор анимаций, условий их воспроизведения и генерируемых при этом событий, но ценой необходимости разбираться как вся эта система анимаций работает и необходимости настраивать анимации каждому объекту по отдельности.
А теперь представь, что у тебя есть движок где ты можешь сделать вот это описанное без специальных навыков в программировании?
prog #3 - 3 years ago (изм. ) 0
Голосов: +0 / -0
А теперь представь, что у тебя есть движок где ты можешь сделать вот это описанное без специальных навыков в программировании?
Что в UnrealEngine 4 что в старкрафте 2 это делается без навыков программирования, в визуальных редакторах, проблема в том, что нужно понимать что ты делаеш чтобы ими пользоваться, недостаточно обеспечить наличие модели с правильно именоваными анимациями.
"что плохого в цельной сущности"
Представь что модель является коммерческим ассетом без исходников, редактировать который ты не можеш согласно лицензии, а тебе нужен другой набор анимаций или материалов - при монолитной структуре модели для этого нужно обращаться к автору модели или нарушать лицензию, а при модульной структуре никто не мешает использовать эту модель с другими анимациями и материалами.
Fakov #4 - 3 years ago 0
Голосов: +0 / -0
prog:
А теперь представь, что у тебя есть движок где ты можешь сделать вот это описанное без специальных навыков в программировании?
Что в UnrealEngine 4 что в старкрафте 2 это делается без навыков программирования, в визуальных редакторах, проблема в том, что нужно понимать что ты делаеш чтобы ими пользоваться, недостаточно обеспечить наличие модели с правильно именоваными анимациями.
однако. В том же варе этого достаточно, а все остальное наращивается кастомно от необходимости.
Я согласен, что здесь возникает проблема - если модели людей анимировать плюсминус можно под одну гребенку, то вот с чем то 6-руким и треххвостым уже будут проблемы. С другой стороны - это решается коммьюнити.
prog:
Представь что модель является коммерческим ассетом без исходников, редактировать который ты не можеш согласно лицензии, а тебе нужен другой набор анимаций или материалов - при монолитной структуре модели для этого нужно обращаться к автору модели или нарушать лицензию, а при модульной структуре никто не мешает использовать эту модель с другими анимациями и материалами.
я понимаю о чем ты. Я поэтому и говорю - модели людей под разные жанры плюс минус можно свести в пару-тройку наборов скелетной анимации, и просто подключать эти наборы к файлам моделей. Ну и вопрос лицензирования это вообще пара строк в соглашении с магазином, в котором реализуются эти модели.
Uber #5 - 3 years ago 0
Голосов: +0 / -0
у рынка образуется пустующая ниша, которая ждет чего-то, что будет напоминать симбиоз редактора WE и Construct 2.
Это напоминает прожект спарк от мелкомягких, который не взлетел. Может, он не взлетел из-за банальной корпоративной дурости, или просто оказался мало кому интересен, в вопрос не вникал.
Fakov #6 - 3 years ago 0
Голосов: +0 / -0
Uber:
у рынка образуется пустующая ниша, которая ждет чего-то, что будет напоминать симбиоз редактора WE и Construct 2.
Это напоминает прожект спарк от мелкомягких, который не взлетел. Может, он не взлетел из-за банальной корпоративной дурости, или просто оказался мало кому интересен, в вопрос не вникал.
...the difference between Project Spark and LittleBigPlanet or Minecraft is the core ability to customize the game down to the minutiae of the in-game object actions...
Это не взлетело вот поэтому. Потому что это была игра для создания игры. И рынок хавал это как сандбокс игру-адвенчуру. А не как движок.
prog #7 - 3 years ago (изм. ) 0
Голосов: +0 / -0
Fakov, я немного о другом - не важно с моделью в комплекте идут анимации или к скелету подходят анимации взятые из базовой комплектации движка, сложность в другом - научить объект правильно воспроизводить эти анимации в зависимости от своего состояния. Даже если запилить пресет который будет уметь переключать анимации стандартных состояний на подобии того как это делает вар, ему всеравно нужно будет где-то указывать какие анимации соответствуют какому состоянию, как минимум для каждой модели, а лучше с возможностью переопределения для каждого типа юнитов. Поскольку анимация не является неотъемлемой частью модели, а лежит где-то отдельно, то по стандартному имени как в варе её достать уже не получится. И уже на этом этапе простота использования начинает сыпаться - пользователь должен будет понимать где и почему он должен перечислить все используемые моделью анимации и еще и разместить эти анимации в правильные слоты - birth в birth, stand в stand. Для поставляемых вместе с анимациями моделей эту проблему можно частично решить, но тут зарыта новая собака - рано или поздно понадобится поддержка более чем одного стандартного пресета (анимационный пресет от RTS не очень подходит для какого-нибудь шутера от первого лица) и опять пользователю нужно будет понимать происходящее чтобы делать осмысленный выбор там где невозможна автоматизация. И таких собак, одна за другой, огромное количество, в какую часть движка ни ткни. Всем нужно будет найти какое-то решение или безжалостно резать функциональность и настраиваемость.
Я же не с потолка это все пишу - я давно всерьез рассматриваю возможность реализации подобного проекта на основе UnrealEngine4 с релизом либо в стиме либо в анриловском маркете, либо и там и там с разным функционалом. Но во-первых я еще не нашел даже теоретического решения всем проблемам которые успел обнаружить, а во-вторых сейчас в разработке более интересные мне проекты, а этот ведется только в форме документации.
Fakov #8 - 3 years ago 0
Голосов: +0 / -0
И уже на этом этапе простота использования начинает сыпаться - пользователь должен будет понимать где и почему он должен перечислить все используемые моделью анимации и еще и разместить эти анимации в правильные слоты - birth в birth, stand в stand. Для поставляемых вместе с анимациями моделей эту проблему можно частично решить, но тут зарыта новая собака - рано или поздно понадобится поддержка более чем одного стандартного пресета (анимационный пресет от RTS не очень подходит для какого-нибудь шутера от первого лица) и опять пользователю нужно будет понимать происходящее чтобы делать осмысленный выбор там где невозможна автоматизация.
согласен, понимаю, представляю.
Но.
давай посмотрим как это уже сделано у кого либо.
Мы знаем что у вара анимы зашиты в модель и привязаны к некой жанровости и ею же ограничены. Если мы хотим чтобы у юнита появилась новая анимация - мы редактируем целую модель. Это решение неплохо для ртс, но в жанре РПГ такое решение будет ограничивать. возникает @.
Возьмем юнити - там мы используем модель с готовыми анимациям, однако возможностей уже гораздо больше, так как можно прикрутить физику к объекту и в целом играть со скелетной анимацией. Однако кастомизировать это тоже не просто.
Упрощенный вариант - 2д конструкторы типа гейммейкера и С2 - там ты просто рисуешь условную гифку для спрайта.
Во всех примерах общее одно - инструмент работы с анимациями должен быть, но он не укладывается в волшебную кнопку "сделать круто"
и тут вопрос лишь в том, как ограничить это, чтобы оставить наибольшее поле для удобства и простоты использования?
Вероятно, наиболее разумным вариантом в данном случае было бы использование уже моделей с уже имеющимися анимациями, с возможностью их дополнения новыми.
prog #9 - 3 years ago 0
Голосов: +0 / -0
Fakov, мне кажется ты опять упускаешь из вида важную деталь - кто и как должен определять какая анимация должна воспроизводиться в каждый конкретный момент времени? В варе все просто - у юнита есть стандартный набор состояний, согласно которым движок дергает анимации, но этот набор состояний у вара специфичен для RTS и весьма ограничен, даже с учетом возможности влиять на анимации тегами.
uranus #10 - 3 years ago (изм. ) 0
Голосов: +0 / -0
Лень читать комменты, но разве редактор карт в SC2 не самый продвинутый на данный момент? Да, порог вхождения многократно выше и он нафиг никому не нужен, но все.
prog #11 - 3 years ago 0
Голосов: +0 / -0
Лень читать комменты
Видимо, лень тебе читать не только комменты, но и сам пост, иначе ты бы понимал почему SC2 не подходит под запросы автора.
Fakov #12 - 3 years ago 0
Голосов: +0 / -0
кто и как должен определять какая анимация должна воспроизводиться в каждый конкретный момент времени?
Считываем набор анимаций.
Исходя из требований поведения - распределяем. (набор аним же для юнита отличается в шутере и в ртс, не так ли?)
Все осталось - добавляем как доп анимации, которые будут проигрываться на манер stand-1/2/3 в варе.
prog #13 - 3 years ago (изм. ) 0
Голосов: +0 / -0
Fakov, расскажи подробней о "распределении" и "требованиях поведения" и как это решает проблему сложности использования аналогичных механизмов в юнити и анриле.
Fakov #14 - 3 years ago 0
Голосов: +0 / -0
prog:
Fakov, расскажи подробней о "распределении" и "требованиях поведения" и как это решает проблему сложности использования аналогичных механизмов в юнити и анриле.
Ну смотри. У нас есть некий мир - глобальная пустота.
Мы можем добавить в нее объект-пустышку (представь фиолетово-черный варовский кубик в черном пространстве).
Для начала придаем объекту форму - условно говоря превращаем "ничто" в модель - загружаем внешний какой то файл.
Затем мы должны определить роль этого объекта в этом мире - что это будет. Допустим мы делаем ртс, и это у нас юнит. Ок. Тогда мы должны дать ему поведение RTS, которая даст этому объекту все необходимые базовые свойства объекта из жанра RTS. Среди которых будут анимации естественно.
Поведение знает некие обязательные требования жанра RTS - юнит должен ходить, стоять, атаковать, применять некую способность и умирать. Это базовый минимум объекта с поведением RTS - и этим функциям нужно назначить анимации. В модели мы распознали анимации ходьбы, атаки, стояния, каста, смерти, а также анимацию ожидания. Мы распределяем имеющиеся анимации по требованиям поведенич RTS, а для оставшейся анимации создаем к примеру "пустое" требование, чтобы в дальнейшем к нему обращаться из скриптов, или же заносим в качестве второй анимации к анимации стояния. Получается что мы распределили требуемые поведением анимы, а одному требованию назначали 2 анимации, которые будут проигрываться в случайном порядке или поочередно.
prog #15 - 3 years ago (изм. ) 0
Голосов: +0 / -0
Fakov, погоди, если это ртс, то мы не можем каждого юнита таскать на сцену чтобы задать его поведение и характеристики - это порнография какая-то получится, а не разработка. Саму суть идеи я понял, но эта операция ну никак не может быть привязана к работе с объектом на сцене, если "движок" рассчитан на что-то сложнее пакмана или арканоида.
exAres #16 - 3 years ago -2
Голосов: +0 / -2
А разве не будет идеальным решением в этом случае написание того же плагина под UE4, который позволяет реализовать взаимодействие с любым обьектом на сцене, благо анрил не ограничивает такое. Таким образом ставя плагин нам подгружаются нужные базовые класы, по типу тех же юнитов, абилок, итемов и т.д., сами же сущности можно редактировать прямо на сцене через созданный UI для этого, как уже реализованы те же плагины для создания и удобного редактирования мешей и сплайнов на сцене.
Тут фишка просто в том, чтобы сделать базовую логику, которая без вмешательства в код будет работать как в простом RTS. В случае надобности мы легко наследуем нужный класс, делаем нужные манипуляции в коде и просто подменяем.
Fakov #17 - 3 years ago 0
Голосов: +0 / -0
prog:
Fakov, погоди, если это ртс, то мы не можем каждого юнита таскать на сцену чтобы задать его поведение и характеристики - это порнография какая-то получится, а не разработка. Саму суть идеи я понял, но эта операция ну никак не может быть привязана к работе с объектом на сцене, если "движок" рассчитан на что-то сложнее пакмана или арканоида.
почему????
prog #18 - 3 years ago 0
Голосов: +0 / -0
Fakov, в ртс одни юниты могут создавать других в рантайме, в том числе таких которых изначально не было на сцене, причем желательно чтобы однотипные юниты созданые разными способами получались одинаковыми - прототипы должны храниться отдельно от сцены, причем желательно в удобном для просмотра и редактирования виде. И это я еще молчу про оптимизацию.
Fakov #19 - 3 years ago 0
Голосов: +0 / -0
prog:
Fakov, в ртс одни юниты могут создавать других в рантайме, в том числе таких которых изначально не было на сцене, причем желательно чтобы однотипные юниты созданые разными способами получались одинаковыми - прототипы должны храниться отдельно от сцены, причем желательно в удобном для просмотра и редактирования виде. И это я еще молчу про оптимизацию.
Отлично, это условие жанра просто должно учитываться поведением объекта.
Объект, который мы вытаскиваем на сцену - не обяательно должен быть использован на этой сцене, но он может быть использован игрой. Нам ничего не мешает например скрыть этот объект, или задать его как мастер-объект, который не будет при инициализации находиться на сцене, но система будет знать об этом объекте и при необходимости сможет создать его инстанс
prog #20 - 3 years ago 0
Голосов: +0 / -0
Fakov, т.е. ты предлагаешь держать все типы юнитов на сцене и при необходимости редактирования искать их там-же на сцене? И удивляешся почему я называю это порнографией?
Даже анриловские блюпринты в этом плане и то удобней - они хотябы лежат в ассетах, именованы и их можно искать/фильтровать. Правда редактирование всеравно сродни порнографии если свойства кажого типа юнитов внутри отдельного блюпринта задаются.
Fakov #21 - 3 years ago 0
Голосов: +0 / -0
prog:
Fakov, т.е. ты предлагаешь держать все типы юнитов на сцене и при необходимости редактирования искать их там-же на сцене? И удивляешся почему я называю это порнографией?
Даже анриловские блюпринты в этом плане и то удобней - они хотябы лежат в ассетах, именованы и их можно искать/фильтровать. Правда редактирование всеравно сродни порнографии если свойства кажого типа юнитов внутри отдельного блюпринта задаются.
Не совсем на сцене. Допустим мы создаем мастер-юнит. Для шутера, гонки или ртс. Наполняем его характеристиками, свойствами. И он становится неким ресурсом игры, к которому игра может уже обращаться в динамике. Мы можем создать инстанс перенеся объект на сцену, а можем в процессе игры. Но в папке ресурсов игры появится 1 объект, который можно использовать.
prog #22 - 3 years ago (изм. ) 0
Голосов: +0 / -0
Fakov, вот так это уже больше похоже на юзабельную систему. И заодно почему-то очень похоже на то как в анриле идет работа с блюпринтами типа Actor.
Вот только это удобно на этапе прототипирования, когда типов юнитов не слишком много и нет необходимости массово менять их свойства - а дальше опять начинается порнография. Когда, допустим, есть сотня типов юнитов и каждому нужно поменять что-то в свойствах.
Fakov #23 - 3 years ago 0
Голосов: +0 / -0
)) в этом плане очень грамотно реализовала Scirra в своем конструкторе. У тебя есть папка со всеми объектами игры. Если ты выбираешь объект кликом на него в папке - и меняешь какое то его свойство - то изменение применяется глобально ко всем уже занесенным на сцены объектам этого типа, ко всем его инстансам. Если же ты выбираешь объект на сцене, один какой то инстанс, и меняешь его свойства - то только этот инстанс обретает заданные тобой новые свойства. Таким образом - на сцене могут быть два инстанса одного объекта с разной скоростью движения одного поведения, назначенного этому объекту.
exAres #24 - 3 years ago -2
Голосов: +0 / -2
Fakov:
)) в этом плане очень грамотно реализовала Scirra в своем конструкторе. У тебя есть папка со всеми объектами игры. Если ты выбираешь объект кликом на него в папке - и меняешь какое то его свойство - то изменение применяется глобально ко всем уже занесенным на сцены объектам этого типа, ко всем его инстансам. Если же ты выбираешь объект на сцене, один какой то инстанс, и меняешь его свойства - то только этот инстанс обретает заданные тобой новые свойства. Таким образом - на сцене могут быть два инстанса одного объекта с разной скоростью движения одного поведения, назначенного этому объекту.
Как и в UE4
Fakov #25 - 3 years ago 0
Голосов: +0 / -0
exAres:
Как и в UE4
однако ue не дает возможности пилить свою ртс?
exAres #26 - 3 years ago -2
Голосов: +0 / -2
Fakov:
однако ue не дает возможности пилить свою ртс?
Там даже примеры есть. Т.е. анрил как более сложный инструмент вполне позволяет реализовать внутри него плагин позволяющий наделять любой обьект любыми свойствами. То что они "из коробки" без особых возможностей - это да, но сама машина считающая физику, анимации, свет и т.д. и т.п. вполне себе готова к использованию и расширению.
prog #27 - 3 years ago 0
Голосов: +0 / -0
Fakov, где-то я это уже видел. А, ну да, все в тех-же анриловских блюпринтах - инстансам на сцене можно задавать значения переменных отличные от стартовых. Вот только это не спасает от порнографии, наоборот только усугубляет её.
Представь ситуацию, у тебя выходит патч, в котором тебе нужно уменьшить максимальный запас здоровья всем юнитам попадающим под определенные условия, например всем эльфам, всей технике и всем на кого действует улучшение "острые мечи". И ты начинаеш лихорадочно перебирать ассеты своих юнитов и менять их свойства.
И представь еще одну ситуацию - у тебя на сцене стоит пехотинец с нестандартным максимумом здоровья. Ты меняеш значение максимума здоровья в прототипе. Что должно случиться с здоровьем этого нестандартного пехотинца на сцене? Откат до нового стандартного значения и потеря нестандартного? Игнорирование стандартного поскольку задано нестандартное? Что если на этого пехотинца должно распространяться изменение из предыдущего примера, но с учетом того что у него должен быть повышеный запас здоровья относительно стандартного, выбирать каждого такого пехотинца и вручную менять ему нестандартное значение на правильное?
Fakov #28 - 3 years ago 0
Голосов: +0 / -0
И представь еще одну ситуацию - у тебя на сцене стоит пехотинец с нестандартным максимумом здоровья. Ты меняеш значение максимума здоровья в прототипе. Что должно случиться с здоровьем этого нестандартного пехотинца на сцене?
  • Применить изменения ко всем объектам этого типа?
  • Применить изменения ко всем объектам этого типа с такими же параметрами?
  • Применить изменения ко всем объектам этого типа не с такими же параметрами?
Что если на этого пехотинца должно распространяться изменение из предыдущего примера, но с учетом того что у него должен быть повышеный запас здоровья относительно стандартного, выбирать каждого такого пехотинца и вручную менять ему нестандартное значение на правильное?
масса вариантов, но первое что приходит на ум, это модификаторы параметров объекта.
Если мы хотим одному инстансу дать иное от Мастер-объекта свойство - даем ему модификатор этого свойства. К примеру на сцене в шутере 102 коробки. выделяем из них 18, открываем настройки поведения "Разрушаемый объект", находим параметр "Запас жизни коробки" и добавляем к нему модификатор или модификаторы, которые будут распространены только на эти коробки.
Можно объявить коробки в группу.
Можно создать из них семью и на семью распространить поведение, или модификатор.
prog #29 - 3 years ago 0
Голосов: +0 / -0
Применить изменения ко всем объектам этого типа?
Применить изменения ко всем объектам этого типа с такими же параметрами?
Применить изменения ко всем объектам этого типа не с такими же параметрами?
  • потенциальная потеря данных со сцены
  • потенциальная необходимость идти и дополнительно вручную менять данные на сцене
  • аналогично первому
Я это к чему - сама возможность менять значения переменных у инстансов потенциально ведет к множеству проблем и должна использоваться максимально осторожно, вплоть до принудительного скрытия переменных от этой системы и обеспечения альтернативного способа добиться аналогичного результата.
модификаторы параметров объекта
осторожней, а то получится ск2 с его обилием сущностей и сравнимым с полноценным движком порогом вхождения
Fakov #30 - 3 years ago 0
Голосов: +0 / -0
осторожней, а то получится ск2 с его обилием сущностей и сравнимым с полноценным движком порогом вхождения
я об этом думал. Мне тоже не хтелось бы видеть редактор с множеством бесполезных сущностей, котороые проще было бы заменить кодом.
Нет. Нужно делать редактор, который позволил бы без особых трудностей создавать "ремейки" - то есть повторять механики известных игр. Это обеспечит основу, базис, которые уже потом можно было бы наращивать.
prog:
вплоть до принудительного скрытия переменных от этой системы и обеспечения альтернативного способа добиться аналогичного результата.
вполне решение. одно из.
exAres #31 - 3 years ago (изм. ) -2
Голосов: +0 / -2
Нужно делать редактор, который позволил бы без особых трудностей создавать "ремейки" - то есть повторять механики известных игр. Это обеспечит основу, базис, которые уже потом можно было бы наращивать.
Т.е. сделать даже хуже чем в СК2 ? В этом и фишка плагинов и т.п. расширений с маркетплейса, ибо если "сразу" дать возможность делать "что-либо" это просто дикая каша будет, т.е. в поисках нужного можно будет застрелиться. А если я захочу обьединить части нескольних жанров?(что, имхо, будет самым интересным в таком концепте). То это будет тот же мадженто для создания универсальных магазинов, где сама только "пустая" база весит несколько гигабайт.
GrYLLL #32 - 3 years ago 0
Голосов: +0 / -0
весит несколько гигабайт
Это код столько весит?
exAres #33 - 3 years ago (изм. ) -2
Голосов: +0 / -2
Бордер:
весит несколько гигабайт
Это код столько весит?
Нет, но оно ничего не меняет по-сути, просто выбрали хранение сценариев в базе. Там реализовано взаимодействие между компонентами. Т.е. вся структура "очень" гибкая, можно изменять все и вся, добавлять кучу свойств и прочего, на лету крепить плагины и менять весь сценарий формирования страниц и вообще сайта в зависимости от определенных условий.
Круто? Да.
Гибко? Да.
Сложно! Достаточно.
Медленно? Да песец просто... самые ценные спецы в мадженто не те, кто может что-то на нем сделать, а те, кто может заставить страницу грузиться быстрее десяти секунд.
GrYLLL #34 - 3 years ago 0
Голосов: +0 / -0
exAres, юнити 3д какое-то, только хуже
GeneralElConsul #35 - 2 years ago (изм. ) 0
Голосов: +0 / -0
Но есть же блипринты в UE или ассеты типа Playmayker в Unity. (хотя как по мне это дикость и обоснованно, если чел типо геймдиза не знакомый с программированием набрасывает прототип)
Все равно придется разбираться хотя-бы с основными сведениями как это все работает, не надо волшебную таблетку искать. Посмотри даже на Гуй в Варкрафте - он прост, но ограничен.