Comments 8
Интересно кто ЦА?
Прогерам это не сильно надо, их все в коде.
Если делать инструменты для геймдизов, то есть 1001 и одно шикарных решений (напр. Один).
То есть это только для тех кто собирается писать свой инструмент для написания инструментов, но тогда материала очень мало.
ОФФТОП: А вообще не знаю, мне кажеться что время писать и моделить все с нуля на Unity подходит к концу. Правило хорошего тона, брать готовые ассеты и на их основе уже делать проект/прототип.
Прогерам это не сильно надо, их все в коде.
Если делать инструменты для геймдизов, то есть 1001 и одно шикарных решений (напр. Один).
То есть это только для тех кто собирается писать свой инструмент для написания инструментов, но тогда материала очень мало.
ОФФТОП: А вообще не знаю, мне кажеться что время писать и моделить все с нуля на Unity подходит к концу. Правило хорошего тона, брать готовые ассеты и на их основе уже делать проект/прототип.
Позвольте с вами не согласиться.
У меня неоднократно возникала необходимость получить доступ к сериализованному объекту напрямую, а не через FindPropertyRelative (в основном причиной была необходимость доступа к методу). Обычный ответ на такой вопрос: пишите обёртку у класса, который будет содержать интересующее нас поле конкретно взятого класса. Это, в свою очередь, убивает возможность реюза сериализованного класса в других условиях. На том же стаковерфлоу можно найти достаточно постов с тем, что сериализованные классы плохо портируются в массивы\листы, и ответ на это всегда примерно один: пишите лист-обёртку.
Брать готовые ассеты — идея не всегда хорошая, чаще всего это максимально вредный совет. Платные ассеты — это кот в мешке, у которого неизвестно что в коде, неизвестно, насколько оно полезно вообще, и неизвестно, сколько времени ты это будешь чинить и подстраивать под свой проект, есть ненулевая вероятность, что написать то же самое самому будет быстрее. Бесплатные ассеты — это ну… бесплатные ассеты. Иногда же задача просто не решается имеющимися ассетами. Или тебе нужно каким-то образом упростить себе и сокомандникам (в первую очередь сокомандникам) задачу с оперативным изменением каких-либо ваших дженериков в сцене. Если вы думаете, что «прогерам это не сильно надо, у них всё в коде», вы серьёзно ошибаетесь.
Насчёт очень мало материала: не совсем понимаю, что именно вы имеете в виду? Статья посвящена одной конкретно взятой проблеме: как извлечь сериализованный объект из сериализованного свойства (а потенциально и все объекты по узлам сериализации, это несложно), и не впаяться в несколько подводных камней по дороге, после которых обычно люди идут на стаковерфлоу и получают «ну напиши обёртку в родительском классе», «ну напиши лист-обёртку» и сетования на то, что юнити плохо работает со вложенными свойствами. Вам необходимо что-то ещё вне обозначенной темы? Предлагайте, можем обсудить, если вам действительно это интересно.
У меня неоднократно возникала необходимость получить доступ к сериализованному объекту напрямую, а не через FindPropertyRelative (в основном причиной была необходимость доступа к методу). Обычный ответ на такой вопрос: пишите обёртку у класса, который будет содержать интересующее нас поле конкретно взятого класса. Это, в свою очередь, убивает возможность реюза сериализованного класса в других условиях. На том же стаковерфлоу можно найти достаточно постов с тем, что сериализованные классы плохо портируются в массивы\листы, и ответ на это всегда примерно один: пишите лист-обёртку.
Брать готовые ассеты — идея не всегда хорошая, чаще всего это максимально вредный совет. Платные ассеты — это кот в мешке, у которого неизвестно что в коде, неизвестно, насколько оно полезно вообще, и неизвестно, сколько времени ты это будешь чинить и подстраивать под свой проект, есть ненулевая вероятность, что написать то же самое самому будет быстрее. Бесплатные ассеты — это ну… бесплатные ассеты. Иногда же задача просто не решается имеющимися ассетами. Или тебе нужно каким-то образом упростить себе и сокомандникам (в первую очередь сокомандникам) задачу с оперативным изменением каких-либо ваших дженериков в сцене. Если вы думаете, что «прогерам это не сильно надо, у них всё в коде», вы серьёзно ошибаетесь.
Насчёт очень мало материала: не совсем понимаю, что именно вы имеете в виду? Статья посвящена одной конкретно взятой проблеме: как извлечь сериализованный объект из сериализованного свойства (а потенциально и все объекты по узлам сериализации, это несложно), и не впаяться в несколько подводных камней по дороге, после которых обычно люди идут на стаковерфлоу и получают «ну напиши обёртку в родительском классе», «ну напиши лист-обёртку» и сетования на то, что юнити плохо работает со вложенными свойствами. Вам необходимо что-то ещё вне обозначенной темы? Предлагайте, можем обсудить, если вам действительно это интересно.
Я просто пытаюсь сказать что сериализация и перерисовка инспектора (и прочих окон) Юнити уже избитая тема. Есть готовые хорошие решения.
Когда несколько лет назад «вкатывался» в Юнити тоже считал что надо знать основы, своё это надежнее и т.д. Когда вкатился понял что есть экономика из серии, взять 5 платных плагинов из которых 4 не подойдут, а 1 надо будет допилить. На его допилку, как и было сказано в вашей статье, конечно нужны какие никакие знания, но это всё равно будет быстрее чем писать всё с нуля.
Так вот к экономике 5 плагинов по 40$ в среднем, ну и на допилку максимум 3 дня. Писать тулзу с нуля это до 2 недель (подчеркиваю ДО, можно и за пол часа). По чаще всего пишут тулзу по потребности и пока ее делают дизайнеры сидят и неспешно ковыряют другие задачи палкой.
Это относиться ко многим вещам в Юнити, и интерфейс, и работа со звуком, и с погодой и навмешем… Все они в стандартном варианте часто не дают требуемых стандартов, все их можно имея время и мозги допилить до нужного уровня, НО это время. Либо обмазываемся плагинами, теряем деньги, экономим время… Если это не домашний хобби проект, то на практике чаще всего с коллегами склоняемся к первому варианту.
Повторю этот опыт пришел ко мне горьким опытом проваленных сроков.
Когда несколько лет назад «вкатывался» в Юнити тоже считал что надо знать основы, своё это надежнее и т.д. Когда вкатился понял что есть экономика из серии, взять 5 платных плагинов из которых 4 не подойдут, а 1 надо будет допилить. На его допилку, как и было сказано в вашей статье, конечно нужны какие никакие знания, но это всё равно будет быстрее чем писать всё с нуля.
Так вот к экономике 5 плагинов по 40$ в среднем, ну и на допилку максимум 3 дня. Писать тулзу с нуля это до 2 недель (подчеркиваю ДО, можно и за пол часа). По чаще всего пишут тулзу по потребности и пока ее делают дизайнеры сидят и неспешно ковыряют другие задачи палкой.
Это относиться ко многим вещам в Юнити, и интерфейс, и работа со звуком, и с погодой и навмешем… Все они в стандартном варианте часто не дают требуемых стандартов, все их можно имея время и мозги допилить до нужного уровня, НО это время. Либо обмазываемся плагинами, теряем деньги, экономим время… Если это не домашний хобби проект, то на практике чаще всего с коллегами склоняемся к первому варианту.
Повторю этот опыт пришел ко мне горьким опытом проваленных сроков.
Как бы знаете, я тоже тут далеко не первый год работаю под юнити и в команде, поэтому проблемы со сторонними ассетами, включая платные (и особенно платные), встречались мне неоднократно. Один такой ассет пришлось с нуля переписывать, и это заняло по факту больше времени, чем если бы всё то же самое писалось изначально с нуля. Я не против использования сторонних ассетов, если это решение надежное и подходит. Но чаще всего на моей практике это выливалось в перебор отвратительно написанных решений, которые даже в рамках своей же демки сыпали сотней исключений, использовали какой-нибудь геткомпонент в апдейте и подобные сомнительные вещи. Кроме того, что у них то и дело с обновлением версии юнити отваливается поддержка, я уже не говорю о таких случаях, когда необходимого готового решения просто нет нигде.
Что же до редактора. Знаете, мне бы хотелось, чтобы статья, подобная моей, попалась мне года два назад, когда ты заходишь с конкретным вопросом на все форумы, а тебе везде один ответ «ну сериализация в юнити фуфло, да, смирись». Наверняка это не только меня озадачивало и не только мне нужно (судя по количеству подобных вопросов).
В общем, что я хочу сказать. Иногда некоторые решения надо уметь делать ручками самому, а не полагаться на чужой ассет. Эта статья — на случай таких иногда. Поверьте, иногда очень не хватает подобного чужого опыта, потому что одни думают, что «зачем я буду писать, это никому не нужно», а другие «зачем я буду писать, это же всем очевидно». И тем не менее, когда-то несколько лет назад мне была необходима статья, которая сейчас меня бы даже не заинтересовала, как давно пройденный этап, выполняющийся уже на автопилоте.
Что же до редактора. Знаете, мне бы хотелось, чтобы статья, подобная моей, попалась мне года два назад, когда ты заходишь с конкретным вопросом на все форумы, а тебе везде один ответ «ну сериализация в юнити фуфло, да, смирись». Наверняка это не только меня озадачивало и не только мне нужно (судя по количеству подобных вопросов).
В общем, что я хочу сказать. Иногда некоторые решения надо уметь делать ручками самому, а не полагаться на чужой ассет. Эта статья — на случай таких иногда. Поверьте, иногда очень не хватает подобного чужого опыта, потому что одни думают, что «зачем я буду писать, это никому не нужно», а другие «зачем я буду писать, это же всем очевидно». И тем не менее, когда-то несколько лет назад мне была необходима статья, которая сейчас меня бы даже не заинтересовала, как давно пройденный этап, выполняющийся уже на автопилоте.
ну сериализация в юнити фуфло, да, смирись
Ну так правильно говорят ).
Юнити вообще славится тем, что на большом проекте плавно варят кашу из топора, под релиз переписывая всё с нуля. Да, временами легче вообще написать/взять готовый модуль и забить на пертурбации в релизах юнити. В частности сериализатор. Не обязательно из ассет стора даже, он та ещё помойка, согласен. Net Standard 2.0 ещё актуален, пока все не перешли на 2.1 можно спокойно подключать либы, даже нугет прикрутить при сноровке.
Нюгетовские пакеты, кстати, мне доводилось прикручивать. У меня в половине рабочих и домашних проектов был портирован MathNet.Numerics (который я и в не-юнитевских проектах использую). Правда, пришлось дождаться, пока юнити изволят добавить поддержку .NET 4.x (с 2.0 были траблы с этим пакетом). Но надо отметить, что не все нюгетовские пакеты уживаются с юнити.
Сериализация в юнити фуфло, но по факту проблема скорее в том, что рабочее решение (которое можно сделать ctrl+c ctrl+v и быстро допилить на коленке) ещё пойди найди. В конечном итоге было быстрее один раз потратить денек и разобраться в том, как работает сериализация, вынести в отдельный статик, который делает красиво и использовать дальше, чем для каждого нового класса писать костыли. Понятное дело, что когда сроки горят или вообще дедлайн был вчера, надо всё срочно и быстро, то все срочно и быстро хватают первое, что нагуглят. Например, первую попавшуюся статью на хабре :)
Сериализация в юнити фуфло, но по факту проблема скорее в том, что рабочее решение (которое можно сделать ctrl+c ctrl+v и быстро допилить на коленке) ещё пойди найди. В конечном итоге было быстрее один раз потратить денек и разобраться в том, как работает сериализация, вынести в отдельный статик, который делает красиво и использовать дальше, чем для каждого нового класса писать костыли. Понятное дело, что когда сроки горят или вообще дедлайн был вчера, надо всё срочно и быстро, то все срочно и быстро хватают первое, что нагуглят. Например, первую попавшуюся статью на хабре :)
Это решение для конкретно юнитевской сериализации полей в юнитевском же эдиторе, чтобы они адекватно отображались независимо от класса, к которому прицеплены. Т.е. это решение, ориентированное исключительно на упрощение работы с эдитором, когда по каким-то причинам надо писать большое количество GUI'шек в юнитевский инспектор, и было бы неплохо написать метод, который «делает красиво» независимо от того, какая у нас вложенность полей и прочий карнавал.
Понятное дело, что для кастомного сериализатора будет своя логика, да и цель у него очевидно другая.
Понятное дело, что для кастомного сериализатора будет своя логика, да и цель у него очевидно другая.
Sign up to leave a comment.
Unity Editor Adventures: Сериализованная Матрёшка