2. И будете читать переписку ребёнка, красть мою кредитку, показывать нежелательную рекламу на всех сайтах, а если и не будете, где гарантия что ваш сертификат не утащат с вашей стороны. Не-не-не.
Без сериализации редактор просто невозможен. Нужно как-то хранить данные, загружать, обновлять. Хранить дамп памяти? Так разработка на ПК/Мак а работать будет на андроид/айос.
В документации подробно описано как это повлияло на SetDiry.
Во первых, конечно же, как вы заметили, получить доступ к переменной если она приватная — не получится (через Reflections можно).
Во вторых, например, у вас есть скачиваемый AssetBundle со ScriptableObject. в первой версии этого объекта были поля А и Б. Во второй добавились еще В и Г. Третья версия предложила именовать поле А как Я (при этом не забыв указать параметр FormerlySerializedAs), а тип Б поменяла с int на float. Если бы мы представляли это не текстом, а классом, то все наши приложения падали при десериализации отличной версии от той что содержат в скомпилированном виде.
В общем стоит просто понять что все MonoBehaviour и ScriptableObject хранятся в десериализованном виде, грубо говоря в виде текста, и по большому счёту SerializedObject создано чтобы их связывать между собой. А тексту свойственно сохранять всё так как задумал разработчик когда-то. Больше плюсов, чем просто ошибка с именем переменной. Можно построить редактор который учитывает такие вещи.
Вообще, ИМХО дико неудобно получилось с этими SerializedProperty/SerializedObject работать >____<.
От EditorUtility.SetDirty отказались из-за не очевидного поведения, когда редактируется несколько сцен одновременно то в старой реализации постоянно выскакивало сообщение «Хотите сохранить сцену?», теперь изменения просто игнорируются если саму сцену не сохранить перед переходом\выходом. В мануале подробно об этом написано, в каких случаях это работает а в каких нет. Для ScriptableObject — ничего не изменилось, и для него можно спокойно использовать EditorUtility.SetDirty.
OnInsectorGUI/OnSceneGUI вызывается каждый раз когда проводишь мышкой над параметрами, handles, кликаешь по инспектору и т.д. Т.е. довольно часто, сомневаюсь что в этот момент происходит сериализация/десериализация, но полная перерисовка — конечно происходит. На этом видео отрисовки видно что здесь не 60 кадров а гораздо меньше (около 20, окошко справа).
SerializedObject, Undo.RecordObject, etc — это конечно здорово, но муторно — когда пишешь какое-то быстрое решение, то лучше взять технический долг, а потом его компенсировать, когда будет готовое представление того как всё должно работать.
Вообще метод не об этом, и он костыльный, конечно (EditorUtility.SetDirty(target); — вызывается чтобы принудительно вызвать перерисовку а не для сохранения). Но пока другого не придумал и не нашел. Если есть, об этом, было бы интересно почитать.
Вот указанный в статье метод как раз вам и нужен был, чтобы события отлавливать. Потому что OnScene (по ощущениям) вызывается по несколько раз за кадр, на каждое событие. А чтобы в редакторе было нечто подобное Update, нужно подписаться на события вот так:
// .. Editor class
// Built-in method
public void OnEnable() {
SceneView.onSceneGUIDelegate = scene.UpdateScene; // Точно не помню что это за переменная, но у меня в этом методе вся отрисовка сцены написана
EditorApplication.update = Redraw; // Вот это событие вызывается около 20 раз в секунду
}
// Your methods
public void UpdateScene(SceneView sceneView) {}
public void Redraw() {
// Принудительно вызовет методы OnInspectorGUI
EditorUtility.SetDirty(target);
Repaint();
}
А вот если нужно, например, при удержании какой-то клавиши, выполнять какие-то изменения на сцене, и желательно прямо во время update — то тут подойдёт описанный в статье способ. Например, когда хочется собственный handles написать.
Какая-то пустая и не очень интересная статья. Три с половиной метода которые можно в документации легко найти. Ни картинок, ничего. Не поймёшь о чем речь, если не в курсе. Картинок бы, пример по реальнее. Про CustomEditor — забыли рассказать, зачем он, как его использовать, про OnInspectorGUI — ни слова, про ярчайший пример Handles — тоже ни слова.
Вот, например, редактор mesh-а внутри unity3d написанный с нуля при помощи описанных в статье техник а также небольшой магии OnInspectorGUI и Handles.
Вообще подход неправильный, движок подобных игр не должен зависеть от внешнего вида.
Мне нравится подход Inkle, когда движок может запускаться где угодно. 80 days из статьи например на Unity написана, кросплатформенна и всё такое.
Сам движок Ink — можно запустить в принципе везде где есть C# (mono, etc, unity3d). Я бы выбрал именно этот язык для написания игры.
Дополнительное рекламное пространство — на самом деле это даже хорошо. Не нравится реклама — не качайте — игра не для вас. Значит разработчики сами себе злые буратины.
Если так хочется скриншоты с девайсов, то вам в Windows Store где нужно делать скрины только с устройства, и не дай бог из фотошопа что нибудь загрузить — не выйдет. Это реально неудобно.
Вообще подход описанный в статье, с настолько неэффективным использованием пространства на скриншотах, конечно же, удручает.
Работа хороша, но это просто ещё один мессенджер с мейнстримовым интерфейсом. Надёргали фишек, склеили вместе, ничего нового, ничего запоминающегося.
Критика:
Кнопка звонков посередине чата это ужасно. Чат это чат. Звонки это звонки. Сколько будет случайных звонков сделано, сколько людей уйдёт так и не поняв как написать сообщение. Тем более что кнопка звонков продублирована сверху.
А если провернуть чат чуть вверх, при этом конечно-же уберётся клавиатура, нужно будте опять тянуться в левый нижний угол, что не очень удобно когда ты правша, и совсем не удобно когда ты левша. Лучше добавить кнопку видео звонка один раз, при открытии чата, над кнопкой чата по середине. После начала чата спрятать, и показывать только если уж очень сильно тянут вверх.
Нет функций «отошёл», «не в сети» и т.д.
Смайлики, стикеры и т.д. в 3 клика — это не смешно.
Пробовали посмотреть скриншоты своего приложения на устройстве с маленьким экраном? — маленькие фотографии лиц в верхней панели — неразличабельны.
Сохранение момента — кнопка снизу — как кнопка позвонить/завершить вызов и т.д. на айфонах, я думал это звонки.
Я понял, но примеры шибко академические и с упором на единообразие, поэтому в комментариях зациклились на кошках. Я же говорю о том, что любая комбинация любых данных может служить контейнером сообщения. Не нужно искать какие-то картинки создающие определённый хэш, достаточно любого файла. Т.е. я пытаюсь расширить ваши примеры.
Не нужно переделывать предложение чтобы там был смысл. Например текстовой документ с ссылками, вырезанными цитатами, словарными словами, пустыми строками, паролями и прочими списками покупок — могут служить контейнером — да смысл есть, но такой список можно подготовить алгоритмически, например на основе существующих списков. Вы, кстати, сами зациклились на кошках и утверждаете что алгоритм медленный, я думаю, что можно подготовить огромную базу различных файлов из которых потом можно создавать сообщение не вызывающего особого подозрения и это не обязательно будут фотографии кошек, и необязательно это будут только фотографии.
А почему обязательно использовать изображения и только изображения.
Любая папка или архив, с любыми файлами отсортированными в алфавитном или любом другом порядке известному отправителю и получателю. Например «Новая папка (5)» в которой лежат вперемешку отпускные фотографии, какие-то текста статьи, ярлыки, архивы и т.д. Сортируем по какому-то параметру (алфавит, размер, дата создания/изменения и т.д.) вычисляем некий хеш (md5, sha и т.д.) берем какие-то символы из хеша (1 и 3, первый и последний, первые два, последние 4 и т.д., абсолютно любые по алгоритму известному и отправителю и получателю), затем компонуем из этого например байты в шестнадцатеричной системе счисления и вуаля, наша криптоконтейер, который можно расшифровать.
Стоит заметить что по поводу того что у вас в пункте минусов ActionScript написана явная неточность. ActionScript3 чуть ли не легче чем остальные приведённые в списке технологии легче и проще компилируются под мобильные устройства, включая iOS(не имея при этом Mac). Ну и количество игр написаных на нём при этом работающих на телефонах, я думаю даже больше чем на AndEngine, просто потому что разработчиков игр на AS3 больше.
Так же, справедливо будет отметить что Unity неплохо работает с 2D играми, даже в стандартной поставке без дорогостоящих плагинов, при этом думать о том что работаешь с 3D приходится не так уж и часто. Настоящим же минусом у него является то что при запуске, в бесплатной версии будет появляться логотип движка, и чтобы его убрать нужно заплатить круглую сумму, а также платность некоторых плагинов облегчающих разработку.
Напрашивается вывод на то, что вы пытаетесь оправдать собственный выбор, а не на объективную оценку возможностей движков представленных в списке.
AV1025 — на этом построен целый паттерн разработки, успешно функционирующий во множестве современных игр. Component Based подход же. Компоненты не должны содержать методов и какой либо логики, обработка данных происходит в специальной системе которая её и реализует.
AV1200 — есть вещи, где бросая исключения налево и направо можно превратить код в огромную проверку этих самых исключений во множестве мест, когда как можно их все заменить одним статусным сообщением. Например ошибку ввода пользователем неправильных или нежелательных данных, которую тут же и вернуть пользователю по стеку. Может я конечно не прав, но я вообще не очень люблю исключения бросать и обрабатывать, мне эта система кажется плохо продуманной и чуждой.
Ну и еще не согласен с AV1540, AV1575 и частично AV1130, а также форматированием пробелами, скобками на следующей строке и т.д. (фломастеры)
Меня больше напрягла ситуация, когда я купил телевизор, включил в розетку, запустил, а меня заставили принять некое лицензионное соглашение, сразу после чего начали показывать рекламу в специальном большом окошке в главном меню телевизора, и за это удовольствие я заплатил 36т.р.
Смарт ТВ это большая бутафория, на данный момент. Пользоваться не удобно, показывают рекламу когда захотят и еще жутко тормозит. В итоге использую телевизор как монитор.
В документации подробно описано как это повлияло на SetDiry.
Во вторых, например, у вас есть скачиваемый AssetBundle со ScriptableObject. в первой версии этого объекта были поля А и Б. Во второй добавились еще В и Г. Третья версия предложила именовать поле А как Я (при этом не забыв указать параметр FormerlySerializedAs), а тип Б поменяла с int на float. Если бы мы представляли это не текстом, а классом, то все наши приложения падали при десериализации отличной версии от той что содержат в скомпилированном виде.
В общем стоит просто понять что все MonoBehaviour и ScriptableObject хранятся в десериализованном виде, грубо говоря в виде текста, и по большому счёту SerializedObject создано чтобы их связывать между собой. А тексту свойственно сохранять всё так как задумал разработчик когда-то. Больше плюсов, чем просто ошибка с именем переменной. Можно построить редактор который учитывает такие вещи.
Вообще, ИМХО дико неудобно получилось с этими SerializedProperty/SerializedObject работать >____<.
От EditorUtility.SetDirty отказались из-за не очевидного поведения, когда редактируется несколько сцен одновременно то в старой реализации постоянно выскакивало сообщение «Хотите сохранить сцену?», теперь изменения просто игнорируются если саму сцену не сохранить перед переходом\выходом. В мануале подробно об этом написано, в каких случаях это работает а в каких нет. Для ScriptableObject — ничего не изменилось, и для него можно спокойно использовать EditorUtility.SetDirty.
видео отрисовки видно что здесь не 60 кадров а гораздо меньше (около 20, окошко справа).
SerializedObject, Undo.RecordObject, etc — это конечно здорово, но муторно — когда пишешь какое-то быстрое решение, то лучше взять технический долг, а потом его компенсировать, когда будет готовое представление того как всё должно работать.
Вообще метод не об этом, и он костыльный, конечно (EditorUtility.SetDirty(target); — вызывается чтобы принудительно вызвать перерисовку а не для сохранения). Но пока другого не придумал и не нашел. Если есть, об этом, было бы интересно почитать.
И тогда появится подобие Update, примерно 20FPS
А вот если нужно, например, при удержании какой-то клавиши, выполнять какие-то изменения на сцене, и желательно прямо во время update — то тут подойдёт описанный в статье способ. Например, когда хочется собственный handles написать.
Вот, например, редактор mesh-а внутри unity3d написанный с нуля при помощи описанных в статье техник а также небольшой магии OnInspectorGUI и Handles.
Мне нравится подход Inkle, когда движок может запускаться где угодно. 80 days из статьи например на Unity написана, кросплатформенна и всё такое.
Сам движок Ink — можно запустить в принципе везде где есть C# (mono, etc, unity3d). Я бы выбрал именно этот язык для написания игры.
Если так хочется скриншоты с девайсов, то вам в Windows Store где нужно делать скрины только с устройства, и не дай бог из фотошопа что нибудь загрузить — не выйдет. Это реально неудобно.
Вообще подход описанный в статье, с настолько неэффективным использованием пространства на скриншотах, конечно же, удручает.
Критика:
Кнопка звонков посередине чата это ужасно. Чат это чат. Звонки это звонки. Сколько будет случайных звонков сделано, сколько людей уйдёт так и не поняв как написать сообщение. Тем более что кнопка звонков продублирована сверху.
А если провернуть чат чуть вверх, при этом конечно-же уберётся клавиатура, нужно будте опять тянуться в левый нижний угол, что не очень удобно когда ты правша, и совсем не удобно когда ты левша. Лучше добавить кнопку видео звонка один раз, при открытии чата, над кнопкой чата по середине. После начала чата спрятать, и показывать только если уж очень сильно тянут вверх.
Нет функций «отошёл», «не в сети» и т.д.
Смайлики, стикеры и т.д. в 3 клика — это не смешно.
Пробовали посмотреть скриншоты своего приложения на устройстве с маленьким экраном? — маленькие фотографии лиц в верхней панели — неразличабельны.
Сохранение момента — кнопка снизу — как кнопка позвонить/завершить вызов и т.д. на айфонах, я думал это звонки.
Не нужно переделывать предложение чтобы там был смысл. Например текстовой документ с ссылками, вырезанными цитатами, словарными словами, пустыми строками, паролями и прочими списками покупок — могут служить контейнером — да смысл есть, но такой список можно подготовить алгоритмически, например на основе существующих списков. Вы, кстати, сами зациклились на кошках и утверждаете что алгоритм медленный, я думаю, что можно подготовить огромную базу различных файлов из которых потом можно создавать сообщение не вызывающего особого подозрения и это не обязательно будут фотографии кошек, и необязательно это будут только фотографии.
Любая папка или архив, с любыми файлами отсортированными в алфавитном или любом другом порядке известному отправителю и получателю. Например «Новая папка (5)» в которой лежат вперемешку отпускные фотографии, какие-то текста статьи, ярлыки, архивы и т.д. Сортируем по какому-то параметру (алфавит, размер, дата создания/изменения и т.д.) вычисляем некий хеш (md5, sha и т.д.) берем какие-то символы из хеша (1 и 3, первый и последний, первые два, последние 4 и т.д., абсолютно любые по алгоритму известному и отправителю и получателю), затем компонуем из этого например байты в шестнадцатеричной системе счисления и вуаля, наша криптоконтейер, который можно расшифровать.
Похоже на идеальную систему.
Так же, справедливо будет отметить что Unity неплохо работает с 2D играми, даже в стандартной поставке без дорогостоящих плагинов, при этом думать о том что работаешь с 3D приходится не так уж и часто. Настоящим же минусом у него является то что при запуске, в бесплатной версии будет появляться логотип движка, и чтобы его убрать нужно заплатить круглую сумму, а также платность некоторых плагинов облегчающих разработку.
Напрашивается вывод на то, что вы пытаетесь оправдать собственный выбор, а не на объективную оценку возможностей движков представленных в списке.
AV1200 — есть вещи, где бросая исключения налево и направо можно превратить код в огромную проверку этих самых исключений во множестве мест, когда как можно их все заменить одним статусным сообщением. Например ошибку ввода пользователем неправильных или нежелательных данных, которую тут же и вернуть пользователю по стеку. Может я конечно не прав, но я вообще не очень люблю исключения бросать и обрабатывать, мне эта система кажется плохо продуманной и чуждой.
Ну и еще не согласен с AV1540, AV1575 и частично AV1130, а также форматированием пробелами, скобками на следующей строке и т.д. (фломастеры)
Смарт ТВ это большая бутафория, на данный момент. Пользоваться не удобно, показывают рекламу когда захотят и еще жутко тормозит. В итоге использую телевизор как монитор.