U-TRIGGERS
Что ж, я почти закончил редактор.
Однако с релизом всё-таки немного обождем, ибо жду от заказчика средств за проект, который включает так же и вот этот инструмент.
Последняя новость как я понял не слишком обрадовала наше сообщество - было много замечаний, которые я в той или иной мере услышал и постарался переделать так, чтобы было хоть чуть-чуть удобнее.
Последняя новость как я понял не слишком обрадовала наше сообщество - было много замечаний, которые я в той или иной мере услышал и постарался переделать так, чтобы было хоть чуть-чуть удобнее.
В общем контролы на данный момент выглядят вот так:
Сверху вниз:
- для типа bool
- для типа int
- для типа void
Как можете заметить:
- кнопки сместились вниз и отображаются только при наведении на элемент (многократное замечание)
- появилась подсказка по наведению на элемент (замечание Кет)
- cами элементы более не расширяются по высоте тем ужасным способом, как это было вначале, если "вложений" слишком много (многократное замечание)
- теперь нет лишних скобок внутри простой арифметики, архитектура арифметики "спрятана" (замечание Doc)
- так же элементы теперь подстраиваются под размер своего содержимого (замечание ScorpioT1000)
Какие планы есть?
- Добавить переменные - руки пока не дотянулись
- Добавить генерацию из строки - замечание prog
- Скорей всего нижнюю полоску и подсказку нужно сделать выпрыгивающими, не занимающими доп место. Однако тут есть свои нюансы у юньки, что нельзя делать окна поверх без фокуса :(
В чем 1%?
Осталось доделать внешний вид под контекстные действия - условия там, циклы и прочую мурню.
Осталось доделать внешний вид под контекстные действия - условия там, циклы и прочую мурню.
Что еще вообще было сделано за последнее время?
explicit это явное приведение типов, пример на 2 скрине сверху - надпись "дробь" у основного поля типа int
Приведения типов позволяет по быстрому добавлять функции смежных типов.
- целиком было переписано отображение ГУИ. Собственно контролы теперь полностью попиксельно отрисовываются, потому весь "процесс" легко проконтролировать.
- были написаны дополнительные "sub-наработки". Некоторые наработки я представил в сыром виде на этом сайте, надо бы обновить (такие как попап и сериализаторы, например).
- Добавлено приведение типов двумя способами - implicit и explicit
explicit это явное приведение типов, пример на 2 скрине сверху - надпись "дробь" у основного поля типа int
Приведения типов позволяет по быстрому добавлять функции смежных типов.
- Собственно изменен подход к арифметике
- Изменен подход к действиям. Теперь действия вообще умная вещь, и остаются компактными несмотря на все невзгоды.
Ладно, что-то я записался. Уже лень даже дальше строчить - хотя рассказать то вроде и есть чего. Однако, достаточно и того, что вы посмотрите скриншотики разработки и дадите очередную порцию дельных советов - как вам оформление теперь, чего бы еще эдакого хотелось увидеть в тулсе.
Дабы избежать снова вопроса зачем этот редактор - он позволяет визуально вычислять любые значения и запускать сценарии из действий в игре.
Ред. Devion
Вообще хотел бы в библиотеку "кишки" запаковать, а скрипты которые могут понадобиться просто связать с ней и оставить открытыми. Всё-то там вряд ли пригодится. На крайняк под рефлектором посмотрят, если руки дорастают в эти кишки лезть - это не составит проблемы.
Опять же как распространять буду - надо подумать. Ибо это не тупо "опен сорс разработка", собираюсь на ассет сторе ее продавать. Но для юзеров с хгма навскидку за так отдать. Тут опять же главное, чтобы на шар не слили :)
Надо под примерчики пару классов оставить, чтобы сильно не парился народ за вопросы аля "как добавить редактор для своего типа".
А в целом ты прав, торчащие файлики погоды не делают. Тем более что они в таком случае каждый раз рекомпилятся зачем-то.
Ред. Clamp
Ред. alexprey
Плюс обязательно добавлять надпись строка? Думаю если просто добавить кавычки, будет понятно что это текст
А надпись "строка" - на выражении типа object.
Есть еще вариант для "дробь" например просто добавлять букву "f" в конце.
Опять же я хз что будет если я начну делать все implicit'ом, не начнет ли логика путаться. Плюс формально любой тип можно привести например к строке, абсолютно любой кроме void. Это породит очень сильно разросшиеся менюшки, ибо там будут отображаться методы для вообще всех типов.
Но честно говоря тоже смущает, нельзя это так оставлять.
Ред. alexprey
Ред. Devion
Ядро игры на таком не напишешь. Это просто редактор существующей логики.
Мб я что-то неправильно объясняю, но слышу такие заявления уже третий раз здесь
Это не редактор, который напишет за тебя скрипт. Это способ подтягивать и обрабатывать любые функции из проекта удобно со стороны геймдизайна, без постоянного кодинга. И это хороший потенциал для создания сценариев, ибо редактор "понимает" действия во времени - может подождать выполнение скрипта, может оборвать такие действия и так далее.
Но чтобы что-то через него запустить это что-то нужно сначала написать. Как с варкрафтом - вот есть ядро игры, оно написано на ЯП, а есть редактор триггеров, который некоторые операции полученного движка может вызывать и создать из них сценарий, аля
В том же ВЕ часто было проще записать формулу при помощи строки с кастом кодом, чем выбирать мастером 10+ переменных и функций.
Вот это было бы хорошее, годное дело.
Харгард:
Очень уж удобно в них разносить код в отдельные файлы и папки и размещать коменты.
Вот только, повторюсь, для серьезных вычислений ими пользоваться накладно.
Ну если вы брезгуете за скорость - значит не моя целевая аудитория.
Для серьезных вычислений конечно редактор лучше не использовать. Но организовать вызов "серьезный вычислений" - почему бы нет. Один call проблем не сделает все же, разве что для параноика.
Широкие возможности тут опять же не для того делаются, чтобы можно было писать полноценные скрипты, а только потому что "всякие бывают случаи, может пригодиться".
Я просто скажу так, ну сделаем мы скажем массив с отсылкой на кастомный код, да? Ну вот приспичило нам описать новую ситуацию - в итоге нужно под новым индексом добавить запись, в самой игре этот индекс указывать в качестве "ссылки". Когда приспичит снова туда заглянуть, придется бегать по массиву искать что же вы туда положили. Не практично. А самый большой минус в том, что массив однажды подгружается весь. Не всегда это нужно. Ну и массивом расписать можно тоже не любую ситуацию. Скажем чтобы алгоритм во времени расписать придется делать отсылку на запуск каких-то дополнительных скриптов, которые будут нагружать игровую сборку. Пока таких скриптов с десяток это конечно не проблема, но с ростом их количества скажем до 1000 скорость каждого вашего ребилда вырастет настолько, что вы будете успевать поесть за это время. Не знаю, что тут может быть прикольного и сомневаюсь, что это победа.
Опять же есть разные типажи игр. Некоторым играм кастомные сценарии просто не нужны. Аркады какие-нибудь, гонки, арены, мультиплей стратегии - там это нафиг не сдалось, вполне реально все реализовать в коде. А скажем РПГ, квесты - вот там это уже необходимо. Но опять же, у вас может быть на это свое мнение.
ScorpioT1000: Ну, лично я собираюсь продавать только на ассет сторе, потому если захочет куда-то еще втюхать - не проблема, а если процентом от навара будет делиться так вообще замечательно. Главное только чтобы на шару не оказалось слишком уж быстро, задаром.
Харгард:
Теперь подсказка и кнопки не занимают доп места для рисования и появляются только если контрол был выбран, в остальных случаях просто сворачиваются. Так что +50 к компактности.