Заказал код по С# и Unity у 3 Сеньоров-Помидоров (Senior C# + Unity)

В следующем видосе пригласи хауди хо 🤣🤣🤣

Ээ

Иван а вы можете со мной связаться

Что за программа?

Президент компании ИТ 🦊 лиса

Никогда не понимал смысла начинать приватные поля с андерскора.

dictionary там из-за того что изначально возможно не известно какие айди ресурсов могут быть, это пока там enum оно все предиктивно, ты не можешь быть уверен, что resourceId попадет в линейный массив. А под капотом hash map и так массивы. Но я из Java тут пришел, возможно в C# не так, и вообще я бекендер :D

Ну и при добавлении ресурса, надо не только enum изменить, а еще не забыть залинковать иконку

Третий неизвестный из 3х синьоров это хауди хо

Инфоцыган преисполнился в программировании, но потерялся на уроках пунктуации на русском языке

Кстати тоже видео делаю обучающие, но чисто для новичков ибо с каждым видео вижу что в предедущем можно улучшить)))

Я конечно не профи, выпустил 2 игры в ГП и 2 на мёртвом флеше, но вопрос такой : зачем так, когда можно гораздо проще или я не догнал, да смотрится прикольно, но... , нужно показывать что за приложение они сделали на экране/видео хоть понятие будет о чем речь то идёт, а то такое чувство, что пен...н взлам...т, а на деле что есть, показываете. А так видео интересные, много узнал нового. Спасибо.

Ctri+H
recieve -> receive

Ох у вас там адок в юнити. Enum ключ к словарю, айдишнк через enum. Угораете или что там?

Роман, в гонке за деньгами, ты теряешь лицо! Надеюсь, ты успеешь заработать столько, что бы откупиться от вопроса к самому себе, "а не паразит ли я и мошенник". Жаль, что из программиста ты превратился в ебоивого комерса(

Круто что есть ссылка на github

> Полезно вам будет подчерпнуть многие подходы ;)
"Почерпнуть" же! (да, я грамма-наци)

Очень приятный голос, но неприятное произношение английских терминов)) "Аймедж" вместо "Имидж", "дикшонЭри" вместо "дИкшенери". Мешает сконцентрироваться)

Сеньеры пффф. Я вот император c#. Просто вписываю в любой код своё имя и он работает идеально.

Вот послушал несколько видео. Чувствую, что по сути всё красиво в голове, но само донесение русским языком как типичный говнокод: мешанина русских и плохо произнесённых английских слов. Куча «вот», «ну и», «а», «э» и мешанина вьюшек аймэдж, прикидывание, допрокидывание...

А есть видео с разбором работы с namespaces?

Ну да, эррэй для енамов

enum SomeEnum {
Val1 = 1
Val2 = 2
Val3 = 4
Val4 = 8
Val5 = Val1 | Val2 | Val3 | Val4 | Val5
}

Ждем полную версию!

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

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

Доброго. А если я хочу заниматься автоматизацией некоторых рутинных действий в играх. Мне какую среду разработки надо учить? Ну к примеру рыбалкоботы в альбион онлайн и тд? Подкажи плез. Играть уже надоело. Хочется чем-то интересным заняться.

Это видео только путает новичков. Уже не первый раз прихожу к выводу, что сеньорство раскрывается только тогда, когда сложность требований, объемы кода, большая команда и тонкости технологий выходят на первый план. Подобные попытки в маленькой песочнице без 100500 уточнений всегда выглядят глупо и только портят репутацию программиста. Когда пишешь код для себя, а не для других (библиотеки), то многие зависимости можно делать очень просто, потому что всегда в любой момент можно переписать и перекомпилить обычными средствами рефакторинга VS. Опытный программист в начале проекта может с десяток раз код и архитектуру переписать как только хоть немного нарушается баланс требования/простота. В вашем случае понятие "как правильно" слишком размыто, а оно должно постоянно уточняться и в коде и в голове по ходу создания проекта.Так как выдается фиксированное ТЗ, то под него можно придумать тысячи реализаций с использованием (или отсутствием) любых шаблонов и принципов. И все они формально подойдут под ТЗ. Автору же просто понравилось то, что ему ближе по духу. К сожалению, советы в данном видео вредные и могут вам помешать в развитии вас, как программиста. Учить людей надо не "как правильно", а постоянно думать в ходе работы над проектом. То есть всему процессу в целом. Тогда и вопросов (почему так вышло?) будет меньше и качество результата выше.

Респект автору! Хоть и не моя сфера программирования, но такие обзорные нужны

Как разработчик который пишет бекенды, где клиент-серверное взаимодействие на клиент-серверном взаимодействии, могу сказать, что эмуляция сети и сама сеть тут совсем такая себе. Во первых, любое действие с сеточкой занимает много времени, и по этому разные дяди типа вас любят либо лочить поток, либо отстреливать сайдэффектом, порой даже без коллбека. Но на самом деле, любая вот такая операция может возвращать результат - будь это () => Task, () => Future, () => ListenableFuture, IO, ZIO, так гораздо будет удобнее, чем делать лапшу из коллбеков, которые вызываются из ХЗ какого потока и исполняются на ХЗ каком потоке. Кроме этого, всякие делегаты-эвентики это слишком низкоуровневые реактивные штуки, уже изобретено 100500 более хороших абстракций по типу рефов, тех же тасков. Проблема в том, что у вас вместо кода одна большая индерекция, где какую либо связь проследить будет года через 2 весьма затруднительно, да и я не увидел вменяемого эррор-хендлинга, что у вас будет если у вас то сервер недоступен, то доступен, то пакет потерялся, то сервер 500 отдал, сверху на ваше решение это не накрутится. И не надо мне тут доказывать что "а как ты без эвентов уи напишешь" - напишешь и с удовольствием, и не только уи, и без лока потоков, и без прямого юза эвентов. Дальше, вы я смотрю завендорлочились на сериализацию юнитологов через анотации, это крайне хреновое решение, очень. Сериализацию можно сделать и без вендорлока, с тем же удобством и с ГОРАЗДО большим контролем.

Блин ,Ромыч,дай пример хорошего кода на игру...а то всё разбираешь да обсираешь));)

Очень плохой код.

Ага, ещё бы все люди говорящие «ИНДЕТИФИКАТОР» исчезли бы и не озвучивали видео, было бы просто прекрасно. Сори кровь из ушей прям хлещет 🤦‍♂️ не уже ли за всю свою жизнь не удосужился прочитать внимательно это слово, страшно на его собственный код смотреть в таком случае 🤷‍♂️

Кто создаёт ResourceViewPresenter? Есть подозрение, что ResourceViewPresenter - overengineering. Почему бы ResourceView самому не подписываться на изменение ресурсов? Тогда можно в любом месте повесить ResourceView, и его будет достаточно, чтобы показывать в realtime ресурсы. View это как бы и есть Presenter.

Всё что я увидел в этом видео - надрачивание на код хорошего знакомого, а не объективную аргументацию почему так сделано.
Какой enum? Про Open closed принцип слышали? Абстракция ужасная. К слову, я не понимаю каким образом enum вообще вписывается в ООП, но это отдельная тема.
Насчет "не пихать интерфейсы везде", а что лучше вбрасывать прямую зависимость? Интерфейсы можно и нужно "пихать" везде где есть связь между классами - избежите кучи проблем в будущем.

Я случайно попал на этот канал и я в шоке, что программист не знает английский от слова совсем)) Надеюсь хоть слово "exit" у него читается не как "эксайт"))

Кодо-дрочеры, не важно как вы пишите ваш код, всегда придет чел который назовет его говном и будет писать свои куски иначе, главное что бы код был простым, стабильным и быстрым (как по выполнению так и в разработке). Паттерны-гавняторны-жертвы моды, я видел проэкты в которых девы тупо избегали/боялись добавлять одну проперти в интерфейс так как это приводило к каскадному обновлению херовой тучи кода и репаблиша пакетов. Senior не тот кто пишет "красивый" код, а тот кто знает где, что и как адекватно юзать.

Когда будет ECS?

вложенные ифы, скобочки для одной строки, тело вместо "=>", дальше не смотрел

В целом идея обозревать код норм, но есть недочеты:
А они точно сеньоры, в том числе и ты?)
И лучше бы все это проверять на какой-то реальной игре(программе). А не на абстрактной ресурсы что-то там и тд, и смотрящим было бы легче понять сущности и тем кто делает, было бы понятнее ТЗ.
И слов много витиеватых, "линейного размещения" и прочих заумных терминов, добавленных для красоты (имхо)
И лучше рисовать хотя бы какие-то схемы зависимостей, когда о них говоришь (меньше болтовни больше визуальной информации и конкретики)
Ну и что енамы не лучшая идея для ресурсов и массивы уже сказали ранее.
Как то так на мой взгляд) Никого оскорбить не хочу, наоборот качественного контента на русском хочется. 2 года на Unity работаю, сам еще джун, так что с позиции джуна смотрю на все это, может я и не прав

меня одного названия классов напрягают? вот просто смотрю на код и имена классов вообще не отражают для чего они нужны, и почему нет интерфейсов для классов? как потом юнит тесты писать? и можно было бы и DI включить

Вы горе джуниоры после курсов, а не синьеры АХАХА ужас какой, не позорьтесь ))))

Я вообще угораю когда кодеры говорят что код не очень ахаха. сук, горе программисты АХАХАха

Русская студия...эх

Теперь надо потестить сеньоров-писунов-ТЗ

А чем вы все тут занимаетесь ? Понять никак не могу

ResourcesData: проще было добавить все известные ресурсы(раз уж enum используется) в _resources со значением 0, чтобы не плодить все эти TryGetValue. Ну и почему такой неконсистентный нейминг у методов - это тоже вопрос)

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

Все очень интересно, но ничего не понятно, когда я уже буду делать свои игры?)

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