Войти
Инди-ЮнитиФорум

Мастер класс по хорошему коду в юнити (17 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 116 17 18 1928 Следующая »
#240
2:10, 30 янв. 2021

Alprog
> Ой, а в чём проблема?
приличные люди вроде делают это через инъекции, а не залезая своими потными лапами в чужие библиотеки, и решая очередную проблему
> в случае конфликтов смогу легко отследить все свои изменения и поправить всё за
> полчаса
слишком радостно у тебя как то ... давай проверим ...

я вот взял MessagePack.Unity.2.2.85.unitypackage - вкинька мне туда все свои изменения

время пошло ...


#241
2:16, 30 янв. 2021

tac
> именно, про это и говорю. Приличные люди пользуются FormerlySerializedAs или obsolete.
Некомпетентность продолжает лезить из всех щелей. FormerlySerializedAs решает проблему переименования поля, а не изменения типа. В моей системе сериализации при простом переименовании вообще ничего не надо делать. Ты просто берёшь, переименовываешь поле, и всё чудесным образом работает. Не надо дополнительно указывать, как было раньше. Магия? А вот так. Пересмотри презентацию, если до сих пор не понимаешь, как это работает.

Повторяю, что в докладе речь не про переименование поля, а про изменение типа. Никакой FormerlySerializedAs тебе в этом случае не поможет. Объясняю: мы рассматриваем ситуацию, когда у тебя раньше в поле записывалось имя персонажа "Jack", "Nick", "Marina". А после обновления ты решил хранить не имена а id персонажей: 7, 13, 142. Моя система сериализации позволяет обработать двумя строчками. Добавляешь новое int-поле, а старое делаешь не полем, а свойством, которое делает конвертацию. Всё! Вуаля, мы поменяли формат сейвов, но совместимость сохранилась. Никакой FormerlySerializedAs или obsolete не поможет тебе обработать такую ситуацию.

> С if где проверяется версия и то будет получше, чем
> запретить просто менять тип свойству при разработке
Ещё раз: у меня можно менять тип. А вот у тебя нет. Ты, похоже, даже не знаешь для чего нужен FormerlySerializedAs, зато умничаешь, как не в себя.

#242
(Правка: 2:50) 2:28, 30 янв. 2021

Alprog
снова бредишь ...

было
class D {string a;}

стало
class D {int a;}

Если не надо поддерживать старые версии сейвов, на этом все изменения заканчиваются (и это вполне себе часто при разработке, задумываться имеет смысл только после выпуска). Ты в ответе предложил делать так (причем всегда)

class D
{
string a;
int b
{
    get { return Convert(a) ;}
    set { a = Convert2(value); }
}
}

и написать эти две функции конвертера. Так?

upd. выше ты пишешь, что старое поле станет свойством (у меня наоборот). Но тогда оно будет с другим именем:

class D
{
string b; // old
{
    get { return Convert(a) ;}
    set { a = Convert2(value); }
}
int a;
}

так что ли? ты уверен что твой сериализатор не навернется? если не так напиши кодом, ты похоже не улавливаешь проблем, а умозрительно не видишь ... бум тыкать носом

#243
(Правка: 2:45) 2:44, 30 янв. 2021

Alprog
> Как БД бы мне помогла клонировать объекты в памяти?

давай начнем с другого, нахрена ты клонируешь объекты в юнити? Instantinate юзать не пробовал?

как минимум все твои навороты с StaticKey сразу отпадают, словил? или разжевывать опять?

#244
(Правка: 3:11) 3:02, 30 янв. 2021

Alprog
> 2. Как БД помогла бы при слиянии изменений из двух разных версий игры
> (допустим, изменения на ПК выборочно перенести на консоли, при этом с условием,
> что одни и те же поля менялись в обоих версиях). Упс? Представляешь,
> сериализация данных позволяет и это решать.
я не очень понял что ты хочешь ... пиши уж тогда  с примером ... разжую

Но все что тебе надо знать сейчас, Для сериализации ты выбираешь ключи - это не что иное как первичные ключи в таблице, таблица = класс, поля = колонки (правда, надо еще 3 НФ поддерживать, но хватит с тебя пока новшеств)

все преобразования решаются select ами/ update / insert и их комбинациями ... не очень сложно, а? может пора выучить, и не изобретать велосипеды?

Ты же приплел уже кодогенерацию (бинарные ключи, для юзабилити стал использовать :) молодец), и все потому что нет понимания как использовать БД ... ну стыдно за тебя

#245
3:07, 30 янв. 2021
mklink ".\src\MessagePack.UnityClient\Assets\Scripts\MessagePack\Attributes.cs" "..\..\..\..\MessagePack\Attributes.cs"
mklink ".\src\MessagePack.UnityClient\Assets\Scripts\MessagePack\FloatBits.cs" "..\..\..\..\MessagePack\FloatBits.cs"
mklink ".\src\MessagePack.UnityClient\Assets\Scripts\MessagePack\IFormatterResolver.cs" "..\..\..\..\MessagePack\IFormatterResolver.cs"
mklink ".\src\MessagePack.UnityClient\Assets\Scripts\MessagePack\IMessagePackSerializationCallbackReceiver.cs" "..\..\..\..\MessagePack\IMessagePackSerializationCallbackReceiver.cs"

и вот такую хрень поддерживать тоже удобно :) ты в здравом рассудке, так переписывать чужие пакеты? Ну сделай хоть по человечески :)

#246
(Правка: 5:43) 3:23, 30 янв. 2021

tac
> приличные люди вроде делают это через инъекции
В том-то и дело, что только "вроде". Весь опенсорс мир, который на форках держится — это всё для тебя, неприличные люди, видимо. Зато ты у нас самый умный, пришёл учить нас советами, тёмных людишек, которые не знают как программировать.

> я вот взял MessagePack.Unity.2.2.85.unitypackage
> - вкинька мне туда все свои изменения
Чтобы ты потом скачал *.zip-файл через браузер из репозитория и у тебя всё заработало локально?
Нет, давай-ка ты через git скачаешь нужную версию. Ты ведь это умел делать, ещё когда я под стол пешком ходил. Кстати, напомни мне, в каком году это было? Потому что когда я под стол пешком ходил, никакого git'а ещё не было. Даже svn не было.

Но чисто для справки: там 24 изменения в 4 файлах. Откуда я знаю? Потому что у меня есть система контроля версий и я могу посмотреть все изменения. В основном там изменения по типу добавления новых кастомных значений в enum или добавления switch-блоков для них. Скорее всего даже без конфликтов пройдёт обновление. Просто небольшое расширение возможностей текстовой сериализации, которое добавляет форматирование, поддержку комментариев и не-строковых ключей в массивах.

> время пошло ...
Щас, разбежался ради тебя. Засекать время будешь, когда ответишь на вопросы про БД.


> и написать эти две функции конвертера. Так?
Зачем две функции конвертера? Ты новые сейвы в старые что ли собрался превращать? Одной функции достаточно.

> ты уверен что твой сериализатор не навернется?
Уверен. Это работает на реальном проекте. Применялось неоднократно.

> Ты в ответе предложил делать так (причем всегда)
Кто тебе сказал, что всегда? Даже на видео, отвечая на этот вопрос, я предлагаю два варинта решения: конвертер или фукнция миграции сейвов. Если ситуация настолько простая, как в примере, и мы её в любом случае решаем за O(n), то этого решения хватит за глаза. Если там какой-то сложносочинённых граф с повторением элеметнов с тяжёлой конвертацией, но который можно решить, к примеру, за логарифмическую сложность, то, конечно, лучше написать кастомную миграцию. Другой вопрос, насколько часто нужно такое сложное решение, если у нас просто поменялся тип?

> Если не надо поддерживать старые версии сейвов, на этом все изменения заканчиваются
> (и это вполне себе часто при разработке, задумываться имеет смысл только после выпуска).
Хо-хо-хо! Ну что я и говорил:

наверняка даже не закладываешь такую возможность в свою супер-архитектуру

Во-первых, наша игра уже больше года в раннем доступе. Мы ломаем совместимость раз в квартал, когда выпускаем сюжетное обновление, но между большими версиями есть минорные патчи, и в них совместимость сейвов всегда работает.

Во-вторых, игра рано или поздно выйдет в релиз. И в моей архитектуре с совместимостью сейвов не будет никаких проблем после релиза, а ты в момент релиза только начинаешь об этом "задумываться". А, ну да: у тебя же наверняка не было никогда релизов сложнее какого-нибудь тетриса.

В-третьих, эту же фичу можно использовать не только для сейвов, но и для других данных, которые сохраняются в том же формате. Например, перки или диалоги. Зачем останавливать работу всей студии, если слегка изменился формат данных? Поменял тип — и всё у всех загрузится. Если кто-то успел в другой ветке насоздавать диалогов в старом формате, то после обновления проекта, его старые диалоги обновятся в новый формат. Легко и бесшовно. Безо всяких локов файла.


> давай начнем с другого, нахрена ты клонируешь
> объекты в юнити? Instantinate юзать не пробовал?
Может хватит уже обсираться? Что, по-твоему, делает функция Instantinate, если не клонирование?
Открой документацию и смотри:
desctiption | Мастер класс по хорошему коду в юнити

> как минимум все твои навороты с StaticKey сразу отпадают, словил? или разжевывать опять?
Разжуй, потому что похоже, что это ты не словил для чего нужен StaticKey. Этот ключ позволяет указать, что один и тот же файл будет сохраняться по частям в разные места, причём в зависимости от режима сериализатора можно управлять этим процессом. Каким образом Instantinate в этом поможет, если он всегда работает с одним объектом на входе и с одним объектом на выходе?

#247
(Правка: 3:47) 3:46, 30 янв. 2021

tac
> я не очень понял что ты хочешь ... пиши уж тогда  с примером ... разжую
Вот схема коммитов типичного рабочего дня у нас в конторе:
commits | Мастер класс по хорошему коду в юнити

Горизонтальные линии — это разные ветки. В каждой ветке работают разные люди и меняют самые разные данные. В моём случае они меняют сериализованные данные в файлах. В твоём случае, видимо, меняют разные значения в базе данных (ну или какой у тебя там аналог). Причём принципиально важно, что каждый сотрудник работает со своей локальной версией базы данных, потому что если такая орава работает одновременно над одной копией базы данных, то неизбежно разные изменения будут мешать друг другу. Поэтому у каждого своя копия.

Вертикальные линии — это мержи. Это моменты, когда мы соединяем изменения разных веток. Какие-то изменения просто изменяют значения у контретного объекта в базе данных. Какие-то изменения переименовывают поле в коде. Какие-то — меняют тип. Большинство из этих вертикальных слияний не требуют никакого вмешательства и происходят полностью автоматически. Ты просто нажимаешь, слить изменения и всё у всех работает. Если два человека поменяли одно и то же значение одного и того же объекта, то в момент слияния выскочит окошко и предложит выбрать, какое из двух изменений выбрать. Выбирать можно как на уровне всего файла, так и на уровне каждого конкретного изменения.

Ну и теперь вопрос: если объекты хранятся не в сериализованном виде, а в виде таблиц базы данных, то как ты сливаешь данные? С помощью update / insert и их комбинациями? каждый раз? По несколько десятков раз в день? А геймдизайнер, который работает в редакторе и знать не знает о том, как файлы устроены внутри, тоже делает update и insert, когда ему надо просто обновить стоимость грибов на уровне? А что он делает, если другой геймдизайнер, так совпало, в версии для консолей тоже менял стоимость грибов, но на другие? Как написать селект, если конфликт произошёл с 50 грибами? Причём, мы хотим глазами посмотреть изменения, и решить по каждому отдельно?

> и все потому что нет понимания как использовать БД ... ну стыдно за тебя
Я прекрасно знаю, что такое БД, как с ними работать, и — самое важно, чего у тебя нет — я знаю, когда они нужны и для чего применяются. Они активно используются в играх с сервером, например. Но использовать БД для хранения ресурсов во время распределённой разработки — это чушь и нонсенс. Для этого есть сериализация. И так поступают все студии. И CD Project Red, и Rockstar, и Naughty Dog, и все остальные. Ты же, по своей темноте, считаешь, что БД нужно натягивать всегда и везде, даже когда оно соврешенно не подходит.

#248
(Правка: 5:26) 5:15, 30 янв. 2021

tac
> время пошло ...
Из интереса всё-таки попробовал обновить версию message-pack, хотя нам это и не требуется.
Минут 40-50 ушло на то, чтобы установить гит, вспомнить, как там работать из консоли с симлинками, куда прописывать мерж тул и вот это всё, потому что последние три года мы пользуемся PlasticSCM и требуется время, чтобы переключить мозг (опенсорс версию мы делали специально для доклада, она немного отличается от версии в самом проекте).

Ну и потом, собственно, ушло минут 20, чтобы разобраться с изменениями:

С 1.7.3.1 до 1.7.3.7 обновляется безо всяких конфликтов вообще.

С 1.7.3 до 1.8 обновляется с одним единственным конфликтом, который на самом деле не конфликт, а просто рядом стоящие изменения. Фиксится тремя кликами.

Ну а с 1.7 до 2.0 и выше обновится уже не смог. Там действительно масштабные изменения всей библиотеки произошли. Но там скорее всего не обновится за полчаса, даже если бы мы никак не модифицировали MessagePack (на то это и 2.0, что совместимость теряется), так что это не считается.

#249
(Правка: 9:36) 9:07, 30 янв. 2021

Alprog
> Может хватит уже обсираться? Что, по-твоему, делает функция Instantinate, если
> не клонирование?
мы это уже обсуждали тогда несколько лет назад, ты так и не понял ... хорош ссылаться на Юнити, я тебя спрашиваю, зачем ты гавновелосипед придумал со своей сериализацией, а не используешь из коробки уж тогда ..

Alprog
> Если два человека поменяли одно и то же значение одного и того же объекта, то в
> момент слияния выскочит окошко и предложит выбрать, какое из двух изменений
> выбрать. Выбирать можно как на уровне всего файла, так и на уровне каждого
> конкретного изменения.
ой, просветил как работает разрешение конфликтов, во, молодец ... а теперь, представь, что базы данных изменяются sql скриптами, и опс - все ровно тоже самое в контроле версий баз данных ...

Alprog
> Скажи, а все студии, которые засирают код подобными штуками, некомпетентны
> по-твоему?
> Это не моя идея, это вполне стандартная практика. Критикуя это решение ты
> критикуешь не только меня, но и тысячи других студий, включая, наверняка, и
> авторов твоих любимых тайтлов.
опять прячешься за других. Но почему то только сериализация доводит до абсурда использование атрибутов, очевидно это кривое решение. И так да, тем более если ты используешь гавно лабы типа твоего MessagePack, ODIN - который я видел в другом проекте и с чего начал тему, и так да - твой первый слайд - где все варианты этого гавна собраны вместе - все это можно выбросить, и особенно велосипеды на них, поэтому если я и буду разбирать то более серьезные варианты сериализации, а не сделанные на коленке, например, от микрософта .. .

Alprog
> БД нужно натягивать всегда и везде, даже когда оно соврешенно не подходит
не приписывай мне глупостей, будешь умнее выглядеть ...


Alprog
> так что это не считается
скучно девочки (с)

:) Мне с тобой стало скучно, представление я о твоем уровне получил ... может позже расскажу, а как надо делать ... для других, у тебя я думаю спесь не слетит еще долго ...

#250
(Правка: 10:01) 9:39, 30 янв. 2021

))
На этих конвертациях завязаны квесты.
Представь что в БД есть поля имя персонажа (varchar, text), раньше хранилось как строка.
Если я правильно понял из презентации код AIProg позволяет это поле превратить в int простым изменением типа прямо в коде.
То есть ты изменяешь лишь тип, а сериализация индексирует все имена и дает им уникальные id.
То есть каждому имени теперь соответствует число. И в момент загрузки уровня с квестами, он автоматически конвертирует строку в число. Благодаря этому все состояния пройденных квестов или квестов которые проходим не падают от того что стало по другому (то есть та самая совместимость). И уже после, в новое сохранения пойдет новый формат. Вуаля.
Даже не важно как это сделано, у тебя tac есть решение лучше?
Вся суть вычислительных мощностей сейчас работает на разработчика. То есть уже не важно количество строк кода. Главная задача именно в гибкости решения. Чтобы в итоге минимальными нажатиями в коде, получить желаемое.
Я в (детстве) такие вещи делал на PHP с БД в joomla, это уже позже появились схемы мангуста умеющие то же самое. Только там не было особой совместимости (бд сама решала эти проблемы) и индесации там тоже не было. За то в любой момент можно было дополнять или менять свойства таблицы прямо на живых данных.

#251
10:05, 30 янв. 2021

tac
> я тебя спрашиваю, зачем ты гавновелосипед придумал со своей
> сериализацией, а не используешь из коробки уж тогда ..
Задом не виляй. Ты меня не это спросил. Ты дословно меня спросил, зачем я клонирую объекты в юнити и предложил вместо этого их клонировать:

нахрена ты клонируешь объекты в юнити? Instantinate юзать не пробовал?

> а теперь, представь, что базы данных изменяются sql скриптами, и
> опс - все ровно тоже самое в контроле версий баз данных
Покажи, как это работает. Запиши видео, например. Я хочу увидеть твои чудо скрипты, которые позволяют мержить изменения значений с разных веток. Ты пустозвон, нет у тебя никаких скриптов и никогда не было. Твои навыки программирования и понимания процессов остановились где-то на уровне 2002-2003 годов. Ты до сих пор в 2021 году работаешь в одной единственной ветке и строго по очереди над каждым файлом.

> Мне с тобой стало скучно
Тебе не скучно стало, ты обосрался по всем пунктам разговора и не знаешь больше, что сказать.
Давай подытожим:

Я:
Сказал, что могу обновить версию за полчаса и сделал это примерно за 20 минут с версии 1.7.3 до 1.8.
Но я не уточнил, что речь идёт о минорных версиях, что вообще-то логично в мире опенсорс, так как мажорные версии на то и мажорные, что они теряют совместимость и перестают работать со старым кодом после обновления. Но так уж и быть, раз я не уточнил, то засчитаем мне обосрамс.

Но в то же время ты:
1. Наврал, что в прошлый раз указывал мне на отсутствие распределённой сериализации, и не смог это подтвердить. Обосрамс раз.
2. Рассказал, что при изменении типа может помочь FormerlySerializedAs. А он вообще не для этого. Обосрамс два.
3. Спросил, нахрена я клонирую объекты и предложил вместо этого использовать функцию, которая клонирует объекты. Три.
4. Говорил, что БД эквивалентно сериализации по функционалу, но не смог объяснить, как с помощью БД клонировать объект в рантайме.
5. Говорил, что БД эквивалентно сериализации по функционалу, но не смог показать (и не покажешь), как решать конфликты при одновременной работе с БД.
6. Обещал сказать, что у меня плохо с архитектурой, но так и не смог показать, чего я не могу сделать сериализацией, что сможет БД.
7. Наехал на практику форков библиотекой, которая является стандартной практикой в опенсорс. Обосрамс семь.
8. Говорил, что пользовался VCS, когда я под стол пешком ходил, и порывался поучить меня гиту, но сам даже не в состоянии клонировать проект с сабмодулем. Обосрамс восемь.
9. В принципе упорно гонишь на подходы, которые в индустрии являются стандартной практикой у лучших в мире студий. Это я про сериализацию вместо БД из 2003 года. Девять.

Ну и хватит, пожалуй.

Итог такой, что ты бесполезно просиживал годы, клепая какие-то проектики в унылом перифирийном программировании, скорее всего с парочкой таких же инвалидных программистов, которыми ты командовал. И почему-то думал, что растёшь от этого, как программист и архитектор. Ты никогда не участвовал в серьёзной коммерческой разработке с большим количеством человек (во всяком случае года так с 2006 точно), варясь исключительно в собственном окружении, а между тем вся индустрия развивалась, росла, становилась сложнее и продвинутее. Но всё это прошло мимо тебя. Ты до сих пор не знаешь ничего, кроме трёх нормальных форм баз данных со второго курса. Это для тебя верх архитектуры и процессов в команде.
Возможно, ты нашёл какое-то тёпленькое местечко. В госзаказах или при каком-нибудь университете. Возможно, ты там даже стал руководителем и тебе там неплохо платят. Может быть ты делаешь ревью каких-нибудь недобитых аспирантов или вроде того. Всё это сформировало у тебя мнение, что ты крутой архитектор, но это не так. Реальная рыночная стоимость тебе, как специалисту — ноль без палочки. Ты не устроишься ни в одну настоящую компанию по разработке игр. Тупо не пройдёшь собеседование даже на мидла. Чего уж говорить про сеньора или архитектора.

#252
(Правка: 10:27) 10:10, 30 янв. 2021

Alprog
> Ты меня не это спросил
https://gamedev.ru/projects/forum/?id=233738&page=9&m=4720779#m134

как и тут, где ты обсирался, я спрашиваю прямо, нахрена ты извращаешь понятие клонирования и делаешь это через сериализацию, и уж если это делаешь, то не используешь Instantiate ... а ты все бредишь и бредишь - сконцентрируйся, ответь хоть на один вопрос, а то много букв, но все мимо

ты там много напридумывал, что я тебе уже разжевывал, на сколько надо быть тупым или упертым, чтобы не понимать есть те же текстовые скрипты в БД, которые тот же текст для контроля версий ...

лан, ты и так много у меня времени отнял ... ты извращаешь мои слова, не слушаешь что тебе говорят, не понимаешь о чем с тобой говорят ...

Alprog
> ты бесполезно просиживал годы
не завидуй :) приличные люди не придумывают о других, переходя на личности ... ты не просто тупой в программировании, ты еще не приличный человек в этике

#253
(Правка: 10:34) 10:26, 30 янв. 2021

Salamandr
> Если я правильно понял из презентации код AIProg позволяет это поле превратить
> в int простым изменением типа прямо в коде.
> То есть ты изменяешь лишь тип, а сериализация индексирует все имена и дает им
> уникальные id.
думаю ты придумываешь, у него и близко этого нет ... но он же не в состоянии пример кода написать, когда я его спрашивал ..

AlProg
поправь, расставь свои атрибуты, люди не понимают, о чем ты бредишь

class D
{
string b; // old
{
    get { return Convert(a) ;}
    set { a = Convert2(value); }
}
int a;
}

ты запутался в своих показаниях, давай умник ... ты уже столько наговорил, я посмотрю как ты дашь свой код соответствующий своим словам ...

#254
(Правка: 10:35) 10:33, 30 янв. 2021

tac
> нахрена ты извращаешь понятие клонирования и делаешь это через сериализацию
Потому что стандартный метод Clone в C# делает тупое копирование полей managed объекта и этим процессом управлять нельзя. Если объект имеет сложную структуру перекрёстных ссылок, то такой объект будет скопирован неправильно. Если объект имеет связь с какими-то unmanaged ресурсам, то эти связи, опять же, будут скопированы некорректно.

Метод Instantinate в Unity делает клонирование префабов с помощью собственной юнити-сериализации. Именно поэтому клонирование происходит корректно. И для клонирования Unity-объектов, как я уже говорил выше в треде, я использую этой метод.

Но я также клонирую не только Unity-объекты, но и свои собственные объекты: логические сущности персонажей, предметов, оружия, способностей, перков, диалогов — всё это не является префабами, но я это тоже всё клонирую в реал-тайме. И для этого я использую свою собственную сериализацию. Это похоже на Instantinate, но работает не с префабами, а с моими объектами, и намного круче по возможностям, чем Instantinate. Потому что я могу создавать объекты не только из другого объекта (клонировать), но тем же самым механизмом сериализации я могу их создавать из файла или байтового массива. Более того, я могу создавать этой же функцией объекты сразу из нескольких файлов, объединяя статические данные объектов с той частью, которая пишется в сейв. И более того, всё это не гипотетические примеры, а реально используется на проекте.

Страницы: 116 17 18 1928 Следующая »
Инди-ЮнитиФорум

Тема закрыта.