еперь я хочу записать какую-то формулу. Что быстрее - записать её просто текстом, или прощелкивать всякие пунктики в визуальном редакторе просто чтобы сложить-поделить несколько чисел/переменных?
Конечно круто и я тебя во многом понимаю, например, по части текста. По мне тоже текстом удобнее. Но пунктики исключают человеческий фактор ошибки, в первую очередь. Для дизайнеров, которые не всегда имеют навыки программирования и понимание даже элементарного синтаксиса это может быть слишком сложно - написать выражение без ошибок.
Вторым фактором замечу, отличие от программиста - дизайнер вполне вероятно не углубляется в тонкости кода, ему нужны лишь те функции, которые лично для него, как для дизайнера имеют смысл. Это не тоже самое что и все функции, как это удобно было бы программисту.
По этим двум факторам доминирующей и является визуальная оболочка.
То что ты можешь увидеть на скриншоте - очень и очень простой пример. Нам обоим известно, что в выражениях используются часто поля и методы, названия которых в таком случае пришлось бы знать наизусть.
Вдовесок я намеренно иду в сторону гуи который "укладывается в одно окно", чтобы не пришлось как раньше, в варкрафте, вбивать сложные формулы долго путешествуя по менюшкам. Сейчас это проще, хоть и не так просто как хотелось бы.
Вкупе с тем что уже сейчас есть копирование и перетаскивание элементов - изменение формулы происходит легче. Ну и впоследствии я сделаю таки арифметический парсинг, чтобы можно было из строки сделать быстро формулу. Сейчас просто и без него работы много, более актуальной.
А вообще если бы гуи мог полноценно заменить код, он бы давно его заменил.
iZucken, это редактор сценариев.
Нужен чтобы... исполнять сценарии?
В любом редакторе юзаются выражения, ну вот эти формулы. Ну и никто не мешает их юзать отдельно от "сценариев", чтобы просто получить какое-то значение.
Ну собственно годен он там где вместо кода дешевле забить "действия" или "формулу". Плюс перекидывает часть геймдизайна с программиста на собственно дизайнера.
Вот и весь смысл. Не юзать код там, где удобней юзать что-то другое. Например для квестов выполнять действия или для редактора диалогов настроить условие появления ветки.
почему поля фиксированной ширины? сделай зависимость от количества символов
в дефолте если задавать элементу минимальный размер то он делает черти что. А если просто сузить элемент то при 0 символов он слишком сильно стягивается, что особенно заметно на строковых полях.
чтобы нормально отображались элементы при текущем инструменте придется вручную попиксельно посчитать и расставить размеры. Этим как раз сейчас и занимаюсь.
Mihahail, неа. Она описывает те классы, которые помечены атрибутом Serializable и некоторые другие. Такие классы неплохо и сами сериализуются (нативно сама юнити тоже их умеет хранить).
Если кратко сериализация Unity умеет сохранять:
классы с атрибутом Serializable, с потерей ссылки при ребилде (будут вести себя как структуры, типа это значения, и плодить экземпляры)
классы, наследуемые от Object, с сохранением ссылочности
массивы, списки
стандартные типы int, float, string, bool и так далее
Ну вот тип выше, статья, касается всего кроме наследников Object. Просто преобразует их в byte[] и радуется.
А сериализаторы юзаются для классов, которые не подходят под эти параметры и обнуляются при ребилде
Среди таких - MethodInfo, Type и прочие.
Потому что по сути они отражают объекты, существующие в этой сессии сборки. При ребилде такие могут быть скажем удалены или еще чего-нибудь.
Соответственно бинарная сериализация тоже на такие объекты не действует. Она их просто не упакует, выпадет с еррором, ибо они не описаны для таких операций.
Но у таких объектов обычно есть способ их поднятуть.
Скажем,
Type подтягивается через Type.GetType(x)
MethodInfo через type.GetMethodInfo(параметры);
Соответственно если сохранять эти данные, с помощью которых можно извлечь текущую версию объекта, то можно и описать их сериализацию.
Далее такие красоты как кеширование делают свое дело.
Соответственно на примере выше ты можешь заметить например, что для извлечения метода например нужно сохранить тип, который тоже не сериализуем. Соответственно это говорит о том что сериализаторы связаны друг с другом тесно.
И в итоге:
Сериализатор сериализуем, сериализует свои поля
Сериализатор имеет методы для сохранения и загрузки нужных нам данных
Они кешируются и обрабатываются при первом вызове.
Для лямбда выражений нужно такие вещи сделать для каждого наследующего от класса Expression и всех вспомогательных классов, которые сохраняются в этих выражениях и имеют такие же проблемы.
Вот и весь профит.
Кстати на byte[] тоже строится один сериализатор - для типа object. Unity в дефолте не умеет обрабатывать этот тип, но мы можем самостоятельно конвертить данные в byte[] и если эти данные можно бинарно хранить, они соответственно будут там храниться. Ну и вкупе с сериализатором UnityEngine.Object они представляют "любой сериализуемый тип Unity".
Сами сериализаторы так же реализуются через атрибут, либо наследником от ScriptableObject.
Даже хз куда еще проще. Мы просто раскладываем несериализуемые объекты на части, которые можем сериализовать, а потом достаем новый экземпляр объекта при перезапуске сборки.
Mihahail, функтор состоит из 85 подвидов выражений, каждое из которых имеет собственные подвиды. И каждый случай надо разобрать и закрепить/создать под него сериализатор. Потому так долго и пишется сериализация.
Странный Парень, а то что я 3 года сплошь и рядом с лайаутами работаю это фигня конечно. Твой дружок несомненно баста. И я на язычок уж слишком резвый.
1 пункт от alexprey: 1.1 (ненормативная лексика) Повнимательнее пожалуйста, прям сердцу больно выдавать варн
Doc, вообще то гуи юнити устроен как раз на Layout слышу звон не знаю где он
Речь шла об отсутствии конкретики в гуи, четко выверенных команд, отображения объекта независимо от его позиции линейно и обработке действий. Я уверен, что ты понятия не имеешь о "прогонах" в юнити, которые как раз происходят из-за Layout, чем это плохо, но тем не менее сидишь и выпендриваешься за то какой Layout офигительный подход.
Вот простейший пример кода с лайаутом, который не будет работать:
var isFocusContext = rect.Contains(Event.current.mousePosition);
if (isFocusContext)
{
if (gui.button(new GUIContent(ICONS.popup), "control-button"))
{
}
}
Что мы сделали? Просто узнали входит ли мышь в ректангл и по условию отобразили элемент. Почему так? Потому что Layout делает дополнительный прогон, в котором условие выполняется как false, а затем происходит еще один прогон Repaint'ом, на котором условие выполняется как true. Несовпадение количества отображаемых элементов приводит к ошибке. В силу того что код прогонов выполняет одни и те же функции я не могу создать переменную фокуса после очередного перерасчета ректангла, чтобы такой ошибки не было, ибо переменная нужна мне раньше.
Doc, завали RSQR, гуй то будет, никуда не денется. Но подход в юнити когда придумывали гуй выбрали откровенно дерьмовый и не продуманный. О чем и речь.
Да и подход хтмл/ксс я имею ввиду даже не саму эту парадигму аля "теги", а именно содержимое. А в ксс очень хорошо продуманы свойства. Не так как в юнити, где одних команд для ширины штук 5-10, и все могут дать похожий эффект. Команд для изменения цвета не меньше 20.
alexprey, так кнопочки к этим попапам и ведут. Просто если делать кнопку, то блин, приходится перекрывать скобку. А если смещать элементы ради кнопки, то вообще не тру выглядит (
Когда элемент например полностью не влезает и отображается скролл, то скролл начинает прыгать. Ну короче херовая вышла индейка )
alexprey, нажимаешь среднюю кнопку мыши, открывается попап-меню
Там куча разделов, пунктов
Но если коротко то выглядит меню вот так, например для числа:
значение
сложение
вычитание
умножение
деление
поля и методы
секции, например, Математика
варианты методов, например Min()
И еще если данные - массив, можно открыть другой попап, в котором есть добавление, свап и удаление элементов. Но старый попап тоже доступен (вдруг массив вычисляется из метода)
В общем упростил вид до такого. Доделаю действия и буду публиковать.
Правда я сначала повесил меню на правую кнопку. Как оказалось она занята контекстным меню у некоторых элементов. Потому сейчас юзается средняя кнопка мыши для изменения значения. Имхо не очень очевидно, если есть предложения - слушаю
Кстати для дебага строк на нуль можно добавить вот такой метод:
public static TInput Throw<TInput>(this TInput source, params string[] nullExceptionTexts)
where TInput : class
{
if (source == null)
throw new NullReferenceException(nullExceptionTexts != null
? string.Join(Environment.NewLine, nullExceptionTexts)
: string.Format("Source of type {0} can not be null", typeof (TInput)));
return source;
}
То есть throw фактически выдаст исключение если появится нуль, при том не нужно разбивать всё на несколько строк + можно закинуть кастомные данные для фаст дебага.
я от этого наоборот бегал, а ты мне снова это суешь. :) Увы, полноценная реализация деревьев в юнити имеет очень сложную логику и не сохраняет многие важные для деревьев вещи. + много места это занимает, что гораздо проблематичней. А у меня можно прятать методы и значения под "попапы", раскрывая новые ветки всплывающими окошками. Это быстро и удобно. Плюс я юзаю стандартные элементы юнити для ввода разных значений. Скажем те же геймобжекты в таком дереве забивать одним способом, а числа другим => дерево изуродуется. У меня скажем в редакторе возможны выражения аля "картинка1 + картинка2", при том наглядно. Например для скрещивания предметов такое бывает нужным. Фактически редакторы "значений" имеют свободный формат. В дерево же такие вещи не закинешь.
Потому что угодно, но деревьев точно не будет.
Doc, ну так это само собой разумеется, со временем арифметика устаканится визуально, просто сейчас есть задачи покритичней (работать с этим можно, значит уже менее критично). Вместо чисел там могут быть методы, потому парадигма такая с разделениями вполне себе оправдана. Сейчас вот такие "арифметические действия" - на самом деле тоже методы с массивом в параметрах, а сепаратор это один из способ представить массив в этой системе, посему по факту тут это методы. И я их уже чутка ужал тем что на именно этих методах нет названий и дополнительной "вкладки", которая на самом деле должна быть. Архитектура останется прежней, но визуально поправлю и возьму на заметку.
prog, я хочу так переменные кстати выделять. Тобиш вводишь название переменной буквой в поле, ниже появляется эта переменная к вводу. Так что тут недалеко в принципе до этого. Но опять же - на сейчас не критично.
первым делом хочу закончить сейчас сами действия, а не выражения в них.
Там очень непростая волокита, аля действий во времени, ожидания и прочей фигни. Собственно на это ставку и делаю к выходу первой версии.
Вот тут так же хотел - по наведению выдавать подсказку, если она есть.
И еще хотел к скорому времени сделать "автокалькуляцию". Когда забиваешь методы и прямо в редакторе можешь посчитать результат, чтобы в игре не делать лишние действия. Иногда методы должны вернуть что-то реалтаймовое, иногда можно и "запечь".
В общем учту замечания, буду к следующему месяцу делать уже под другой скин
Ну, тогда буду думать. Скорее всего придется опять переделывать под ноль, ибо быстрофиксы хорошего эффекта не дают.
Но это будет уже второй задачей, сначала все таки доведу это до полностью рабочего состояния, а уже потом задумаюсь за внешний вид.
Быстрофиксы вот такие. Имхо по уродски:
Большие знаки и скобки
+ одинаковой высоты
+ без кнопок
Можно сделать в принципе как предлагал в комментариях - монотонно с подсветкой блоков под наведением. И сделать какое-нибудь "появление кнопок" у выбранного блока. Тогда будет уже менее громоздко. GeneralElConsul, в триггерах варкрафта - нужно открывать 20 окошек чтобы исправить какое-то значение. А тут все сразу. Может я чуток и ошибся с выбором оформления, но это дело наживное. Уж точно могу сказать что так редактировать значения куда проще. GeneralElConsul:
А в Визуал Студио, например, элементов хоть и меньше
А что не нравится? Может что предложишь или хотя бы аргументируешь?
На мой взгляд опрятно - макет не перекошен, элементов вынесено минимум.
В общем напиши что не так, я постараюсь доработать или переобдумать
Могу предложить еще вот такой вариант сделать.
Соответственно кнопочные действия спрятать под правую кнопку мыши. При наведении подсвечивать фон выбранного блока. При удерживании шифта перетаскивание блока.
GeneralElConsul, я юзаю. Просто новости насколько я понимаю это обычные ресурсы с заранее закрепленным тегом "новости". Это удобно для дальнейшей фильтрации ресурсов.
В конце увидел кое-что дико смешное. Я про то что ассасинс крид юнити на самом деле никоим образом не связана с движком Unity. Просто совпадение, что используется тоже самое слово.
В целом же блин, я поражаюсь этой игре. Она просто титанически сложная по своей натуре. Отображение огромных городов до мелочей, с кучей народа на улице и абсолютно уникальной по своей структуре боевкой и системой передвижения. Это дико сложно. И вот когда я смотрю на ассасин крид мне становится очень жалко, что другие лидеры игростроя не блещут такими гениальными играми а плодят какой-то бред в виде очередной стандартной мморпг.
alexprey, я его и кеширую. Я вообще всегда кеширую данные, доставаемые иначе чем индексно из массива. Но первое обращение происходит очень долго. Даже кешируя это выглядит не красиво, ибо на 4 секунды все подвисает.
В общем цель - помеченные атрибутом методы использовать в определенном месте. Это пожалуй всё. Методы могут находиться в пределах любой сборки любого класса.
Если еще точнее - для редактора сценариев в атрибуте помечаю сепаратор и название. А дальше подтягиваю эти данные где мне нужно. Атрибуты самый удобный способ пометить такие вещи. Отдельный класс не подходит, ибо пакую в отдельную сборку свой плагин, а это все будет ущербно выглядеть.
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
Вторым фактором замечу, отличие от программиста - дизайнер вполне вероятно не углубляется в тонкости кода, ему нужны лишь те функции, которые лично для него, как для дизайнера имеют смысл. Это не тоже самое что и все функции, как это удобно было бы программисту.
По этим двум факторам доминирующей и является визуальная оболочка.
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
Нужен чтобы... исполнять сценарии?
В любом редакторе юзаются выражения, ну вот эти формулы. Ну и никто не мешает их юзать отдельно от "сценариев", чтобы просто получить какое-то значение.
Ну собственно годен он там где вместо кода дешевле забить "действия" или "формулу". Плюс перекидывает часть геймдизайна с программиста на собственно дизайнера.
Вот и весь смысл. Не юзать код там, где удобней юзать что-то другое. Например для квестов выполнять действия или для редактора диалогов настроить условие появления ветки.
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
чтобы нормально отображались элементы при текущем инструменте придется вручную попиксельно посчитать и расставить размеры. Этим как раз сейчас и занимаюсь.
Ред. Devion
» Самый важный блог / Функторы сами себя не сериализуют
Если кратко сериализация Unity умеет сохранять:
Среди таких - MethodInfo, Type и прочие.
Потому что по сути они отражают объекты, существующие в этой сессии сборки. При ребилде такие могут быть скажем удалены или еще чего-нибудь.
Соответственно бинарная сериализация тоже на такие объекты не действует. Она их просто не упакует, выпадет с еррором, ибо они не описаны для таких операций.
Но у таких объектов обычно есть способ их поднятуть.
Скажем,
Type подтягивается через Type.GetType(x)
MethodInfo через type.GetMethodInfo(параметры);
Соответственно если сохранять эти данные, с помощью которых можно извлечь текущую версию объекта, то можно и описать их сериализацию.
Далее такие красоты как кеширование делают свое дело.
Ред. Devion
» Самый важный блог / Функторы сами себя не сериализуют
Ред. alexprey
» cssGUI / Фигня выходит
Ред. Devion
» cssGUI / Фигня выходит
Речь шла об отсутствии конкретики в гуи, четко выверенных команд, отображения объекта независимо от его позиции линейно и обработке действий. Я уверен, что ты понятия не имеешь о "прогонах" в юнити, которые как раз происходят из-за Layout, чем это плохо, но тем не менее сидишь и выпендриваешься за то какой Layout офигительный подход.
Ред. Devion
» cssGUI / Фигня выходит
RSQR, гуй то будет, никуда не денется. Но подход в юнити когда придумывали гуй выбрали откровенно дерьмовый и не продуманный. О чем и речь.
Да и подход хтмл/ксс я имею ввиду даже не саму эту парадигму аля "теги", а именно содержимое. А в ксс очень хорошо продуманы свойства. Не так как в юнити, где одних команд для ширины штук 5-10, и все могут дать похожий эффект. Команд для изменения цвета не меньше 20.
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
Когда элемент например полностью не влезает и отображается скролл, то скролл начинает прыгать. Ну короче херовая вышла индейка )
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
Там куча разделов, пунктов
» Unity - Triggers Editor / Новости с моего фронта
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
» Программирование / Монада MayBe
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
Потому что угодно, но деревьев точно не будет.
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
Там очень непростая волокита, аля действий во времени, ожидания и прочей фигни. Собственно на это ставку и делаю к выходу первой версии.
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
Но это будет уже второй задачей, сначала все таки доведу это до полностью рабочего состояния, а уже потом задумаюсь за внешний вид.
Быстрофиксы вот такие. Имхо по уродски:
GeneralElConsul, в триггерах варкрафта - нужно открывать 20 окошек чтобы исправить какое-то значение. А тут все сразу. Может я чуток и ошибся с выбором оформления, но это дело наживное. Уж точно могу сказать что так редактировать значения куда проще.
GeneralElConsul:
Ред. Devion
» Unity - Triggers Editor / Новости с моего фронта
На мой взгляд опрятно - макет не перекошен, элементов вынесено минимум.
В общем напиши что не так, я постараюсь доработать или переобдумать
Могу предложить еще вот такой вариант сделать.
» Блог им. AlexPrey'я / XGM Update Log
Ред. Devion
» Игровые обзоры / [Видео] Геймплей Assassin's Creed Unity
» Программирование / [C#] Обращение к аттрибутам
» Программирование / [C#] Обращение к аттрибутам
Если еще точнее - для редактора сценариев в атрибуте помечаю сепаратор и название. А дальше подтягиваю эти данные где мне нужно. Атрибуты самый удобный способ пометить такие вещи. Отдельный класс не подходит, ибо пакую в отдельную сборку свой плагин, а это все будет ущербно выглядеть.