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

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

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

Страницы: 115 16 17 1828 Следующая »
#225
(Правка: 23:37) 23:27, 29 янв. 2021

Salamandr
> Я смотрел видео по сериализации в вашем проекте.
дай хоть ссылку, посмотрю ... а то текстом он вразумительно так и не рассказал

Salamandr
> Была проблема, вы еë решили.
проблема в его голове :)


#226
23:40, 29 янв. 2021

tac
Нет у него проблем, ну точнее они совсем на другом уровне. У него есть проект и игроки, не ради ли этого мы все тут сидим?)
В конце там видео есть https://gamedev.ru/job/forum/?id=254756

#227
(Правка: 23:55) 23:45, 29 янв. 2021

tac
> Такую же хрень развел в своем проекте с сериализацией
Мой подход к сериализации позволяет успешно ежедневно работать с данными паре десятков человек на протяжении уже более трёх лет и до сих пор ничего не развалилось, а только развивается. Дизайнеры даже говорят, что наш инструментарий по работе с данными самый топовый из всех, что они использовали (а они работали в Larian, например).

> еще пытался людям пудрить голову ...
Да, я даже делал доклад о своём решении в Минске на конференции DevGAMM и открыл исходники старой версии сериализации. И знаю, как минимум, одного человека, который стал использовать моё решение в своём проекте. Хотя в выступлении я говорил, что слишком заточен под нужды конкретного проекта, и перенимать 1-в-1 не стоит.

> Просто не выучил, что такое БД, и туда же - сериализация мать всего ...
Могу только повторить то же, что говорил 3 года назад: ни одна уважающая себя студия не использует БД для контроля версий сцен и ресурсов. Для этого есть сериализация и VCS. Ты пустозвон, который не нюхал реальной разработки и понятия не имеешь, о чём говоришь.

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

> элементарно не парится тем, что тебе не нужно и просто не править одновременно.
У нас в студии 30 человек и несколько веток (текущая версия игры на проде, следующая консольная версия, две консольные ветки и, разумеется, десятки веток с фичами, которые ожидают ревью и интеграции). Надо быть невероятно наивным, чтобы думать, что твои подходы с локом файлов кода — это работает хоть где-нибудь, кроме команд из трёх бомжей с улицы, возомнивших себя архитекторами. Вот скажи честно, ты в git'е сможешь хотя бы элементарно два файла смержить?

#228
23:46, 29 янв. 2021

Salamandr
> В конце там видео ест
Ну всё, щас мне прилетят дизлайки и негативные комментарии от эксперта, лол.

#229
(Правка: 23:53) 23:50, 29 янв. 2021

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

Alprog
> с умными людьми
смешно ) лан, завтра посмотрю чего ты там на гавнокодил

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

#230
23:52, 29 янв. 2021

Salamandr
> Я смотрел видео по сериализации в вашем проекте.
Там, к сожалению, по техническим причинам, отсутствует первая половина доклада, где я говорю о мотивации и работе с данными. Доклад сразу с середины начинается.

> На одно знакомство с сериализацией уйдет не один месяц, а это без взрыва мозга
> скорее всего не пройдёт.
Ну, я написал это всё быстрее, чем за месяц, на знакомство столько времени уж тем более не надо. Но да, у нас порог входа в проект большой. И "юнити-программистов", которые только и могут, что в стандарные функции, мы не берём. Одного случайно взяли, но он сам убежал через пару дней, когда понял, что инфа из видеотуториалов по юнити ему тут не пригодится и придётся заново познавать удивительный мир программирования :)

> Просто хотел пожелать удачи в проекте.
Большое спасибо.

> Не стоит спорить, это пустая трата времени для вас обоих.
Да я больше рофлю с tac'а. Это же реально весьма уникальный шут.

#231
(Правка: 0:23) 0:10, 30 янв. 2021

Salamandr
> В конце там видео есть https://gamedev.ru/job/forum/?id=254756
Посмотрел, я думал что-то серьезное ... ну мелкая поделка ... вопрос нахрена у меня остался ...

это все исходники засраны аттрибутами StaticKey/RuntimeKey ? Ну, здорово конечно, супер идея :)

Интерфейс к этой шняге лепили еще DataExplorer с нуля писали?

Что все таки сделали "распределенную" сериализацию? Я же указывал на то, что без этого у вас совсем будет грустно ... Была бы БД - не нужно было бы ) а так просто изобрели свою БД, и костылями решали проблемы ..

Alprog
> отсутствует первая половина доклада, где я говорю о мотивации и работе с
> данными
ну залил бы, может там хоть ответ будет

жду исходников ..

#232
(Правка: 0:23) 0:22, 30 янв. 2021

tac
> ну тогда, у меня о тебе такое впечатление и появилось, поэтому и предложил ...
Ты предложил это потому, что ты сам используешь это в своих проектах и больше ничего не умеешь. Что на вопрос про git-то не отвечаешь? Скажи честно, ты ведь даже не умеешь им пользоваться, да? Скорее всего, ни гитом, ни меркуриалом, ни перфорсом ты не пользовался. Максимум SVN. И скорее всего не представляешь, как два файла смёрджить. Без этих навыков даже джунов сейчас не всегда набирают, а ты у нас профессионал индустрии, штаны на лямках.

> ну давай ссылку, поржем вместе ... найду, где ты обсрался
Да пожалуйста: https://github.com/Alprog/DarkContract
Только что ты там собрался комментировать? У тебя же даже не хватит компетенции понять, что этот код делает и для чего используется. Ты вон до сих пор, три года спустя, удивляешься, что сериализация используется не только для хранения, но и для клонирования объектов. С нетерпением жду гениальных советов от человека, который не понимает, что комментирует.

> Посмотрел, я думал что-то серьезное ... ну мелкая поделка
Это ты Encased RPG назвал мелкой поделкой? :D

+ Показать

А покажи тогда, что для тебя не мелкая поделка? Maze Survival что ли большой проект по сравнению с Encased? Аха-ха-ха.

> > с умными людьми
> смешно )
Не смешно то, что у тебя проекты и познания уровня второкурсника, амбиции школьника, но всё это в теле взрослого программиста с 23+ годами опыта по твоим словам. Тебе уже по статусу положено уметь программировать, а ты всё ещё на БД молишься и отрицаешь мировой опыт настоящих студий.

#233
0:30, 30 янв. 2021

Alprog

это я назвал мелкой поделкой, так и быть посмотрю на днях ...
изображение_2021-01-29_232854 | Мастер класс по хорошему коду в юнити

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

#234
(Правка: 0:51) 0:38, 30 янв. 2021

и тебе сразу задали вопрос, где сразу поплыл - там же один из первых сразу косяк - "Мы поля только добавляем и удаляем - не изменяем" - класс :)

"когда не мерджится страдаем" (с) - и ты там что-то вякаешь про гит? может научить тебя все таки :)

Alprog
> сериализация в моём проекте используется и для хранения сцен (юнитёвая), и для
> хранения и контроля наших данных (моя кастомная), и для сейвов, и для
> клонирования объектов в памяти (юнитёвая для клонирования юнитёвых объектов и
> моя кастомная для клонирования наших объектов)
а в ролике говоришь на последнем вопросе совсем не так, и в каком месте ты гонишь?

#235
1:15, 30 янв. 2021

Alprog
MessagePack можно брать оригинальный, или тот который в репозитории, вы его меняли?

#236
(Правка: 1:26) 1:23, 30 янв. 2021

tac
> ну залил бы, может там хоть ответ будет
Не я же снимал видео, а организатор конференции.
Я могу только слайды начальные показать, но там не будет комментариев, так что толку от них мало.

> это все исходники засраны аттрибутами StaticKey/RuntimeKey ?
> Ну, здорово конечно, супер идея :)
Скажи, а все студии, которые засирают код подобными штуками, некомпетентны по-твоему?
Это не моя идея, это вполне стандартная практика. Критикуя это решение ты критикуешь не только меня, но и тысячи других студий, включая, наверняка, и авторов твоих любимых тайтлов.

> Что все таки сделали "распределенную" сериализацию?
Что, значит, всё-таки? Изначально в первом же посте про сериализацию, ещё до того, как ты пришёл "умничать" про БД, уже было чёрным по белому написано:

есть возможность сериализовать данные в разные файлы с перекрёстными ссылками друг на друга через guid'ы объектов

> Я же указывал на то, что без этого у вас совсем будет грустно
Не ври, врунишка. Слово "распред" ты ни разу не сказал ни в одной, ни в другой теме.
Да и как ты мог мне указывать на отсутствие чего-то, что было изначально? Врунишка и фантазёр.

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

> "Мы поля только добавляем и удаляем - не изменяем" - класс :)
Ты чем слушал? Речь идёт не про значение поля, а про его тип. Если поле было типа string, а потом стало типа int, то мы это поле заменяем на проперти, которое в момент присвоения конвертирует тип. И старые сейвы продолжают работать, несмотря на то, что в них записаны данные другого типа. А при следующем сохранении уже запишутся данные в новом формате. Всего две строчки, а это позволяет сделать совместимыми сейвы в разных форматах. В твоих играх сейвы от разных версий игры, я уверен, в принципе не будут подходить друг к другу. Ты у нас такой крутой архитектор, что наверняка даже не закладываешь такую возможность в свою супер-архитектуру. Ну или это гениальное решение, вроде кучи if-ов.

> "когда не мерджится страдаем" (с)
А ничего, что в 99.9% процентов случаев всё мержится? У нас ежедневно происходит мержи сотен, а то и тысяч файлов. И только иногда, в исключительных случаях, происходит нештатная ситуация, которая требует ручного вмешательства. Напомни мне, как ты мержишь файлы? А, ну да. Ты вообще не мержишь. У тебя же нет веток и нельзя одновременно работать над одним файлом. Даже над файлом кода. Это же так удобно и профессионально, ага.

> и ты там что-то вякаешь про гит? может научить тебя все таки :)
Да, смею говорить про гит и другие системы контроля версий (пластик, меркуриал, свн).
А вот ты почему-то избегаешь ответа на прямой вопрос. Задаю третий раз: ты хоть в одной системе контроля версий за свою жизнь мержил два файла? Ты вообще представляешь, как этот процесс выглядит? Это не сложный вопрос. Любой нормальный человек, кто не с улицы пришёл, давно бы хмыкнул и сказал, что конечно, в чём вообще вопрос. Но ты, похоже, вообще никогда этого не делал. Правда в том, что ты никогда не работал в профессиональных командах и понятия не имеешь, как там устроены процессы. Всё, что ты можешь — это проецировать свой опыт недопроектов на всю индустрию под видом гуру.

> MessagePack можно брать оригинальный, или
> тот который в репозитории, вы его меняли?
Меняли. В инструкции написано:

Clone repo and a submodule. Be sure that symlinks are enabled

Сабмодуль ссылается на правильный модифицированный MessagePack.
Я полагаю, не надо объяснять, как пользоваться сабмодулями человеку, который только что собирался учить меня git, верно?

> а в ролике говоришь на последнем вопросе совсем не так
Я говорю в ролике абсолютно то же самое. Где в этих цитатах хоть какое-то противоречие?

сериализация в моём проекте используется и для хранения сцен (юнитёвая),
и для хранения и контроля наших данных (моя кастомная)
Ресурсы (меши, анимации т.п.) нативные в юнити - ими занимается Unity.
Данные, которые отвечают за логику игры - они в нашем формате.

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

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

Alprog
> Меняли
и после этого ты хочешь выглядеть адекватным?

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

#238
(Правка: 2:05) 2:03, 30 янв. 2021

tac
> > Меняли
> и после этого ты хочешь выглядеть адекватным?
Ой, а в чём проблема? Кисонька боится менять чужие библиотеки, потому что после этого не сможет их обновлять? Ой, мамочки! Ну да, это действительно страшная проблема, когда у тебя нет системы контроля версий, а ты меняешь файлы напрямую, лоча файлы. Я бы тоже расстроился, если бы мне пришлось обновлять стороннюю библиотеку в такой гавнобазе. Там же потом не отличить свои изменения от чужих. Но если у тебя есть система контроля версий, то проблема исчезает. Знаешь, что такое форк? На этом весь мир опенсорса держится. Вон там, в репозитории по ссылке, лежит форк MessagePack'а. И если я захочу обновить версию, то я просто подтяну все изменения, и в случае конфликтов смогу легко отследить все свои изменения и поправить всё за полчаса. Такие вот чудеса.

> > избегаешь ответа на прямой вопрос
> ты смешен, делал когда ты под стол пешком ходил )
Ну хорошо, так уж и быть, поверим тебе в этот раз. Мы охотно верим, даже несмотря на то, что для тебя форк библиотеки является чем-то неадекватным; и даже не смотря, на то, что ты уже наврал один раз про то, что говорил мне о распределённой сериализации. Поверим.

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

Очень интересно послушать ответы от того, кто "не смешён" со своей БД.

#239
(Правка: 2:06) 2:04, 30 янв. 2021

Alprog
> Ты чем слушал? Речь идёт не про значение поля, а про его тип. Если поле было
> типа string, а потом стало типа int, то мы это поле заменяем на проперти,
> которое в момент присвоения конвертирует тип. И старые сейвы продолжают
> работать, несмотря на то, что в них записаны данные другого типа. А при
> следующем сохранении уже запишутся данные в новом формате. Всего две строчки, а
> это позволяет сделать совместимыми сейвы в разных форматах. В твоих играх сейвы
> от разных версий игры, я уверен, в принципе не будут подходить друг к другу.

именно, про это и говорю. Приличные люди пользуются FormerlySerializedAs или obsolete. Но тебе надо изобрести велосипед.

> Ну или это гениальное решение, вроде кучи if-ов.
С if где проверяется версия и то будет получше, чем запретить просто менять тип свойству при разработке ... и каждый раз вводить новое

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

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