Andrey C# Expert, по итогу на ~1400$ тестовое выполнено, только чуть защитить его на собеседовании? В принципе тестовое тянет на такую цену? За код спасибо. 5:20 согласен, не выглядит полезным. не нужно мокать все сервисы но в комментах уже обсудили 6:50 asset Provider. Лучше сразу исп generic, тип без cast 8:00 минусы сервис локатора. 8:10 антипаттерн 8:40 без PlayerPrefs = binaryFormatter 9:10 в этом месте binary formatter не нужен 9:30 лучше с async "using" declaration -> try-finaly -> dispose -> fileStream сам закроется IL 11:20 на асинхронный сложно исправлять. до самого ядра дописывать 15:30 вместо такого хардкода лучше SO 18:30 лишние слова. лучше вообще без exception 20:50 нужно разделение на save date и модель данных json, protobuf 24:20 временно увеличил severity подсказок, чтобы понять сколько всего в проекте небрежностей 25:20 предпочитает в средних и мелк проектах throw Exception вместо Debug.Log лучше в первые месяцы помучиться, но потом ядро будет стабильнее 25:40 "data?.Some()" = скрытие бага 26:20 Factory не нужно для каждого объекта, особенно если он создаётся 1 раз 28:00 реальный проект должен оплачиваться 28:20 отказали из-за незнания библиотеки. Согласен, жидкий ответ.
Спасибо за видео! Как по мне - это очень удачный формат видео. Я имею в виду код ревью + рефакторинг. Я считаю что у Вас отлично получается указывать на ошибки, комментировать и сразу же в коде рефакторить их. С нетерпением жду новых видосов и всего самого наилучшего! :)
@@gamedev_expert Подскажи где искать уроки, чтобы научиться во все эти сервисы и ДИ для юнити??? А то чет я прям офигел от всего, хотя в юнити уже кучу игр сделал, а про такое первый раз услышал
@@КатавыйОбзорщик самыц простой путь - работать в команде с другими программистами. Альтернатива - это изучать исходники других игр. Можно через декомпилятор, но и на гитхабе можно искать. Например ищешь использование VContainer languange:c# и увидишь как используют di в других unity играх
Большое спасибо за разбор! Приятно видеть фидбэк более опытных программистов. Кстати после собеседования написали, что как у них откроется вакансия на джуна, то напишут мне, но сообщений пока нет :)
Кстати спасибо за совет в конце видео, что не стоит делать такие тестовые задания бесплатно Самому лично приходилось делать такие тестовые задания, в итоге меня не взяли т.к. я не знал способов внедрения монетизации в игру, не знал Firebase, не знал как делать деплой через webgl на сайты yandex Я действительно их не знал, и подумал что их надо долго изучать, и в принципе не приводил агрументы что потрачу время на их изучение
Класс! Спасибо за видео. Иногда интересно посмотреть, что и как люди пишут. Но вот есть несколько нюансов, которые бросились в глаза. Хотел бы их поднять на обсуждение или просто обратить внимание. 0. Действительно, архитектура местами прям копирует K-Syndicate. Но вот там, где нужно писать самому - начинает просаживаться. Некоторые места, наоборот, опущены. В общем, интересный симбиоз. 1. "DI не используется" (c). На самом деле, используется. Здесь не используются DI-контейнеры (как, например, Zenject). Прокидывание зависимостей ручками - это т.н. "pure DI" (если вам нужны термины). Спор о том, что лучше "pure DI" или DI-контейнеры - вечен и идёт ещё от отцов-основателей техник DI в C# (например, того же Марка Симана, который пришёл к pure DI). Однако, однозначного мнения здесь нет. Главное понимать, зачем и почему ты используешь тот или иной подход. 2. "IRandomService - бесполезный" (с). Не совсем. Благодаря выносу абстракции с рандомом, ты получаешь дополнительный контроль над процессом и логикой рандомизации. Например, здесь, ты можешь подсунуть другую реализацию, которая всегда будет возвращаться одно и то же число. Это удобно для тестов (даже без учёта юнит-тестов и интеграционных). Кроме того, ты защищаешь свой рандом от сайд эффектов. UnityEngine.Random небезопасен из-за того, что сид может меняться в любой точке проекта из-за его статики. 3. По поводу повторяющийхся строк в описании исключений (таймкод 17:37). Есть ещё вариант просто-напросто сделать кастомное исключение и выбрасывать его, унаследовав от нужного. Тогда не было бы необходимости повторять строки.
Привет! спасибо за отзыв 1. я называл di в смысле dependency injection как автоматического внедрения зависимостей + постарался обратить внимание на минусы ручного. Хотя я легко могу путать термины. 2. 100% я даже сделал это с прокидыванием seed в конструктор System.Random, иии.. на монтаже вырезал, т.к. всё равно усомнился, что надо учить таким крайностям, всё же кол-во кода при таком подходе растёт быстро 3. Хороший вариант
Все по факту, код реально либо купил либо пизданул их слитый курс - так же юзаем его в компании, но по подходу разраба сразу видно, что взять-то взял, но нет понимания, как с этим обращаться
IRandomService, как и любой другой сервис, который оборачивает юнитишные статик филды всегда полезный, тк как минимум не тянет за собой этот статический мусор в бизнес логику, а использует интерфейсы как фасад. Это Леха из синдикатов не раз распинался и рассказывал
Изучив до идеала этот курс, который был создан на основании многолетнего опыта нескольких архитекторов (выше синьора), можно пролететь на синьора, но кроме сервисной модели придется на практике понять, чем композиция обходит наследование, и как это дело грамотно применять и делить во вьющий части
8:35 дак это и есть Чисты DI с внедрением через конструктор. Сам сервис локатор немного для другого в этой архитектуре должен быть использован. А DI-Контейнеры на то и нужны чтобы зависимости не прокидывать в глубь вручную. Тут сервис локатор заменяет контейнер. И есть мнение от авторов этой архитектуры что контейнер передавать в фабрику это позволительно, т.к. там идёт сборка объекта и это инфраструктурная часть кода (это уже мое мнение).
Посмотрел на одном дыхании. Хотелось бы модет где-то схемы архитектуры нарисованные, но если имеет смысл. А так очень понравилось, что и детали и глобально интересные вещи подмечаешь
Код неплохой, видно, что часть бережно перенесена с курса синдикатов, но это скорее плюс, чем минус, хотя то, что написано поверх него уже вызывает некоторые вопросы. Тут видна проблема многих разрабов, вкатывающихся в мидл-уровень, когда очень хочется все сразу максимально ручками написать без готовых решений и порой прям перебор с этим есть. Сам страдал таким несколько лет назад, благо, что в какой-то момент стал писать большой пет-проект и понял, насколько это самовтыкательство палок в колёса
Люди, помогите, пожалуйста как научится понимать как строить архитектуру приложения? Все говорят про k-syndicate, что это архитектура под копирку, но что здесь плохого, если эта архитектура удачная. У этих людей за плечами много опыта, уж явно они больше знают джунов. Читал книгу Роберта Найтстрома про геймдев паттерны, ведь по сути архитектура строится на паттернах, ну и конечно же прошёл курс от k-syndicate по архитектуре. Когда прохожу тестовые, то говорят проект не гибкий и не способен расширяться и не понимаю каким образом ещё более можно расширять проект. Посоветуйте книжки по архитектуру приложений, желательно на c# или другой похожий язык как c++ например. Если у вас есть другое мнение и архитектура игры и приложения это разные совершенно вещи, то скажите тогда как в таком случае действовать
Мне помог способ через декомпиляцию кода чужих игр. Те что написаны на юнити лет 5 назад под ПК - их dll можно обратно в код превратить и увидеть как организуют код те, кто доводят до релиза игры
мб уже и поздно, но отвечу сам сейчас заканчиваю прохождение курса от синдикатов и ничего плохого в нем нет. В курсе в некоторых местах по несколько раз (!) повторяется, что это делается для текущего тестового проекта и на продакшене такое лучше не делать. как пример - ручной DI. Но, как мы видим из данного ревью, не все слышат эти предупреждения ))
Делал подобное тестовое задание на джуна, тз очень схоже, как минимум начало и конец текста точь-в-точь одинаковы. То ли я неопытен и тз нормально составлять именно так, то ли это просто мошеннический шаблон)) Меня кстати не взяли, проигнорировали. А потом чат с работодателем и вовсе пропал...
На мой взгляд эксепшены нужно кидать только при возникновении нештатной ситуации. Отсутствие предмета в инвентаре это нормальный случай, будет логичней возвращать Null.
Талантище - сделать всё настолько запутанным... Похоже, что людям нужен константный уровень сложности - чем больше делает движок, облегчая разработку, тем хуже и запутанней код (чтобы компенсировать лёгкость). То, чему я бы не уделил и строчки, превращается в несколько классов в нескольких файлах на сотни строк
Андрей, добрый день. Не так давно выполнял тестовое задание для стажировки в компанию. По итогу мой вариант выполнения отклонили, не указав в фидбеке вообще никаких конкретных указаний почему мои решения посчитали не эффективными. Можно ли как-то связаться с вами для получения адекватного ревью задания?
Полезный видос как для новичка (который даже не собирается писать на юнити). Лучше учиться на чужих и реальных ошибках, понимаешь как лучше писать код, спасибо)
в корне не согласен. Данное видео может быть полезно людям, примерно на том же уровне развития и занимающихся тем же и в той-же сфере, что и автор (ну и автору кода), чисто посмотреть по приколу на расслабоне. Как прим. см. комментарий yummybunny7351, обсудить, поспорить, типа "а вот тут не согласен" и т.д. а все остальное - возгласы безумной толпы. Для новичка нужно прочитать какого нибудь Шилдта и Рихтера, написать хелло ворлд и приткнуться в коммерцию стажером и учиться решать поступающие задачи, учиться у более опытных инженеров по факту и набивать СВОИ шишки. Без проблемы нет решения. Не знаю еще ни одного инженера, который лежа на диване с ютубчиком стал хотя бы джуном. Так что полезность данного видео для новичка (еще и не собирающегося работать в игровой студии на юнити) такая же, как полезность репостов бизнес цитат во вконтакте для того, кто хочет стать бизнесменом. Но как диковинное развлечение, почему бы и нет.
Делал тестовой на джуна - ТЗ оформлено также - пуля в пулю. Даже версия Unity указана таже. Естественно, отказали. Либо это шаблон такой ТЗ либо просто компания нахаляву получает прототипы.
9:40 Ну насколько я понимаю он используется для сохранения данных в бинарном формате чтобы пользователь не мог отредактировать Это как бы прогресс игрока и так же защита данных от редактирования со стороны пользователя платформы, так что вполне оправдано его использование
Интересные видео,, с Вами можно как то связаться? Интересует клиент сервер на c# unity и в целом возможность переноса игры на движёк юнити или воссоздание и ли оно того?
Получается не разбор тестового, а скорее разбор архитектуры от K-Syndicate :) Ничего нового вообще не было добавлено. Я конечно сам ее юзаю в некотором варианте, но если бы делал тестовое, что наверное бы делал что-то свое. Ведь каждый джун уже пишет так, как конкурировать если все одинаково?)
Надо посмотреть что за KSyndicate, столько людей говорят о них, а я пропустил как-то. По поводу что-то своё - я согласен что надо экспериментировать и развивать архитектурные подходы
@@gamedev_expert у них курс в 2019-20г архитектуры в основном они просто показывают бутстрап/сервис локатор/стейт машину показывают ещё пару паттернов
Что-то есть в папке Resources? Fail ! Из всего делаем гребанные адрэсибэлс и ничего не засовываем в ресорсэс. Нах** столько классов и интерфейсов - элемент в grid layout - гребанный префаб с одним скриптом на нем и один скрипт с интерфейсом на все окно, еще файл другой на настройки и модели данных и не е**м никому мозги.
Без особых требований на не использование какого-то механизма, фейлить тестовое на субъективной оценке инструмента путь одиночки, а не командного игрока
Капец код перегружен. Если б от меня зависело решение брать или не брать, я б тоже не взял. На мой взгляд архитектура должна быть максимально простой, но при этом максимально удобной и функциональной. Иначе на реальном тяжёлом проекте, где постоянно с тебя трясут быстрее, офигеешь от собственного нагромождения сервисов
Привет, работу не ищешь случайно?) У нас создается новая команда под юнити и это первая юнити команда в компании(другие игры были под веб на typescript), пока еще вроде никого не нашли, удаленка, компания из США, но все в основном из стран снг, не гк, проекты которые мы делали довольно таки серьезные, все игры онлайн, ситибилдеры и шутер от первого лица, нфти, крипта и подобное
Привет! Спасибо за предложение, сейчас только бекенд пишу. Есть два друга, с которыми вместе работали раньше, их может заинтересовать, можешь отправить ссылку на вакансию dredstd@gmail.com
@@gamedev_expert наверно поэтому и отказали, думаю их уже все знают) Плюс это всего лишь один из вариантов архитектуры. я думаю с той стороны посмотрели на какую то непонятную хрень и забили просто, ожидали простой код для мобилочек а получили вот это все
@@UnityFAN_unity Автор канала похоже зря не показал текст тестового задания. Главным критерием оценки была архитектура проекта. По фидбеку сказали что моё тестовое сильное и из 10 выполнивших только 3 хорошо выполнили. Кстати я правда делал тестовое прямо после курса)
@@gamedev_expert Вроде ничего) Просто они вроде говорили, что на их уроке показываются внутренности DI, чтобы люди понимали как примерно работает тот же Zenject, и для чего это нужно. Другими словами, есть много готовых решений, чтобы не писать этот сервис локатор. Я сам относительно новичек, и ещё только учу и пытаюсь понять всю суть архитектуры и подобных моментов, и пока мне вот конкретно вот такая часть кода, которая была разобрана в этом видео, все ещё сложно даётся. Я уже начал что-то делать для себя в Unity, и сильно привык к монобехам, и [SerializeField] полям, в которые через инспектор легко всё перетягивается. И вот подобный код, где всё надо прокидывать через конструкторы или иногда даже паблик поля, мне выглядит очень неудобным..
@@BlackWindX Юнити молодцы и сделали удобный инспектор, он упрощает быстрое прототипирование. И до какого-то размера игры я тоже за то, чтобы просто прокинуть ссылки. А дальше легко проспать и инспектор станет приговором игре из-за запутанности и сложности внесения исправлений
@@gamedev_expert мне кажется плохо (плохо для соискателя) копировать популярную архитектуру, т.к. она уже всем намозолила глаза. Типа, вот, ещё один пришёл с копипастой от синдиката.
Привет, асинхронный метод превращается в стейт машину при компиляции в il код. Так что да, стейт машиной можно заменить асинхронный метод при желении. Если речь о стейт машине в загрузке, то у меня противоположное мнение
@@gamedev_expertПривет, да, речь о стейт-машине (на 11:36), а зачем ей быть асинхронной? Может дальше будет ответ - не досмотрел до конца, комментирую по ходу дела, пока мысль свежа. Другими словами, зачем методу Enter быть асинхронным и кто должен ожидать его заверешния? В момент вызова Enter включается в работу новый стейт и вся дальнейшая работа - это уже работа нового стейта, а предыдущий уже полностью свое отработал, поэтому он переключил и закончил на этом свою миссию. А так получается, что будет выплнен еще какой-то код из предыдущиего стейта после завершения Enter. Можно, конечно, применить логику, что Enter - это только пореходный момент в новый стейт, но даже в этом случае неясно, зачем предыдущему стейту что-то делать после того, как переход будет закончен. Сразу оговорюсь, что я не навязываю свое мнение, а дискутирую.
По поводу - не писать тип явно где только можно, как раз наоборот делаю - пишу везде, кроме каких-то очевидных ситуаций, как в случае с using, где все и так знают, что за тип будет образован. В других случаях, когда другой программист будет читать мой код (или я сам через какое-то время), то даже беглый взгляд на конструкцию `Dictionary images = GetImages()` сразу дает четкое представление о смысле строки, а учитывая, что в контексте будут и другие строки, намного быстрее складывается общий смысл происходящего, чем в случае с `var images = ...`, т.к. тип - это еще и семантика. Завтра кто-то решит отрефакторить код так, что теперь метод будет возвращать текстуры и это сразу отразится в явном типе. Да, это может потребовать в некоторых IDE вручную пройти и отредактировать тип во всех местах вызова метода, но если это укорит понимание фрагмента кода пускай даже на 10 секунд, то я считаю, что оно того стоит. В примере вроде этого ``` var total= GetTotalAmountOfSometing(); var completion = GetCompletionPercent(); var completedAmount = total / 100 * completion; ``` было бы в разы проще не допустить или найти потенциальную ошибку, будь типы указаны явно, поэтому численные типы тоже указываю.
У меня было похожее тз, такое описание, но зажание другое, нужно было целую игру сделать, я по глупости сделал, отправил и меня просто кинули, никакой обратной связи, не ведитесь на это
Я не могу понять что вы все прицепились к тестовому заданию? Оно супер элементарное учитывая что чел идёт на мидла. Само задание умещается на одной странице документа, где большую часть занимают расписанеые статы. А чел взял и буквально НАСРАЛ в код. Тебя просили срать? Такой сотрудник никому нахрен не всрался, по факту такие люди будут только мешать/спорить/тратить время впустую. Есть задача, она четко прописана - тебе надо её сделать. ВСЁ! Не сидеть придумывать кучу сервисов и всякой херни которые никогда не будут использованы и на которые ты потратишь в 200 раз больше времени чем должен был, и недайбох кому то другому кроме тебя придется это читать.
Andrey C# Expert, по итогу на ~1400$ тестовое выполнено, только чуть защитить его на собеседовании? В принципе тестовое тянет на такую цену?
За код спасибо.
5:20 согласен, не выглядит полезным. не нужно мокать все сервисы
но в комментах уже обсудили
6:50 asset Provider. Лучше сразу исп generic, тип без cast
8:00 минусы сервис локатора.
8:10 антипаттерн
8:40 без PlayerPrefs = binaryFormatter
9:10 в этом месте binary formatter не нужен
9:30 лучше с async
"using" declaration -> try-finaly -> dispose -> fileStream сам закроется
IL
11:20 на асинхронный сложно исправлять. до самого ядра дописывать
15:30 вместо такого хардкода лучше SO
18:30 лишние слова. лучше вообще без exception
20:50 нужно разделение на save date и модель данных
json, protobuf
24:20 временно увеличил severity подсказок, чтобы понять сколько всего в проекте небрежностей
25:20 предпочитает в средних и мелк проектах throw Exception вместо Debug.Log
лучше в первые месяцы помучиться, но потом ядро будет стабильнее
25:40 "data?.Some()" = скрытие бага
26:20 Factory не нужно для каждого объекта, особенно если он создаётся 1 раз
28:00 реальный проект должен оплачиваться
28:20 отказали из-за незнания библиотеки. Согласен, жидкий ответ.
Спасибо за тайм коды! Да вполне, крепким мидлам и 3000$ платят, тут уже не Джун точно
Только не останавливайся! Делай что делаешь. Очень полезно.
Спасибо за видео! Как по мне - это очень удачный формат видео. Я имею в виду код ревью + рефакторинг. Я считаю что у Вас отлично получается указывать на ошибки, комментировать и сразу же в коде рефакторить их. С нетерпением жду новых видосов и всего самого наилучшего! :)
Спасибо за отзыв, как только придумаю что-нибудь интересное)
@@gamedev_expert Подскажи где искать уроки, чтобы научиться во все эти сервисы и ДИ для юнити??? А то чет я прям офигел от всего, хотя в юнити уже кучу игр сделал, а про такое первый раз услышал
@@КатавыйОбзорщик самыц простой путь - работать в команде с другими программистами. Альтернатива - это изучать исходники других игр. Можно через декомпилятор, но и на гитхабе можно искать. Например ищешь использование VContainer languange:c# и увидишь как используют di в других unity играх
@@КатавыйОбзорщик Это в кратце называется паттернами, на ютубе есть канал Sergey Kazantsev, там и про DI и про все принципы солид
Большое спасибо за разбор! Приятно видеть фидбэк более опытных программистов. Кстати после собеседования написали, что как у них откроется вакансия на джуна, то напишут мне, но сообщений пока нет :)
Круто, рад что ты нашел разбор полезным)
Кстати спасибо за совет в конце видео, что не стоит делать такие тестовые задания бесплатно
Самому лично приходилось делать такие тестовые задания,
в итоге меня не взяли т.к. я не знал способов внедрения монетизации в игру, не знал Firebase, не знал как делать деплой через webgl на сайты yandex
Я действительно их не знал, и подумал что их надо долго изучать, и в принципе не приводил агрументы что потрачу время на их изучение
Класс! Спасибо за видео. Иногда интересно посмотреть, что и как люди пишут.
Но вот есть несколько нюансов, которые бросились в глаза. Хотел бы их поднять на обсуждение или просто обратить внимание.
0. Действительно, архитектура местами прям копирует K-Syndicate. Но вот там, где нужно писать самому - начинает просаживаться. Некоторые места, наоборот, опущены. В общем, интересный симбиоз.
1. "DI не используется" (c). На самом деле, используется. Здесь не используются DI-контейнеры (как, например, Zenject). Прокидывание зависимостей ручками - это т.н. "pure DI" (если вам нужны термины). Спор о том, что лучше "pure DI" или DI-контейнеры - вечен и идёт ещё от отцов-основателей техник DI в C# (например, того же Марка Симана, который пришёл к pure DI). Однако, однозначного мнения здесь нет. Главное понимать, зачем и почему ты используешь тот или иной подход.
2. "IRandomService - бесполезный" (с). Не совсем. Благодаря выносу абстракции с рандомом, ты получаешь дополнительный контроль над процессом и логикой рандомизации. Например, здесь, ты можешь подсунуть другую реализацию, которая всегда будет возвращаться одно и то же число. Это удобно для тестов (даже без учёта юнит-тестов и интеграционных). Кроме того, ты защищаешь свой рандом от сайд эффектов. UnityEngine.Random небезопасен из-за того, что сид может меняться в любой точке проекта из-за его статики.
3. По поводу повторяющийхся строк в описании исключений (таймкод 17:37). Есть ещё вариант просто-напросто сделать кастомное исключение и выбрасывать его, унаследовав от нужного. Тогда не было бы необходимости повторять строки.
Привет! спасибо за отзыв
1. я называл di в смысле dependency injection как автоматического внедрения зависимостей + постарался обратить внимание на минусы ручного. Хотя я легко могу путать термины.
2. 100% я даже сделал это с прокидыванием seed в конструктор System.Random, иии.. на монтаже вырезал, т.к. всё равно усомнился, что надо учить таким крайностям, всё же кол-во кода при таком подходе растёт быстро
3. Хороший вариант
Все по факту, код реально либо купил либо пизданул их слитый курс - так же юзаем его в компании, но по подходу разраба сразу видно, что взять-то взял, но нет понимания, как с этим обращаться
IRandomService, как и любой другой сервис, который оборачивает юнитишные статик филды всегда полезный, тк как минимум не тянет за собой этот статический мусор в бизнес логику, а использует интерфейсы как фасад.
Это Леха из синдикатов не раз распинался и рассказывал
Изучив до идеала этот курс, который был создан на основании многолетнего опыта нескольких архитекторов (выше синьора), можно пролететь на синьора, но кроме сервисной модели придется на практике понять, чем композиция обходит наследование, и как это дело грамотно применять и делить во вьющий части
@@petrow_ нет смысла оборачивать статику в сервисы. Нет ничего плохого в использовании статических утилити классов.
8:35 дак это и есть Чисты DI с внедрением через конструктор. Сам сервис локатор немного для другого в этой архитектуре должен быть использован. А DI-Контейнеры на то и нужны чтобы зависимости не прокидывать в глубь вручную. Тут сервис локатор заменяет контейнер. И есть мнение от авторов этой архитектуры что контейнер передавать в фабрику это позволительно, т.к. там идёт сборка объекта и это инфраструктурная часть кода (это уже мое мнение).
О, я кажется натыкался на это задание. Не стал делать, тк реально выглядит как реализация фич
Посмотрел на одном дыхании. Хотелось бы модет где-то схемы архитектуры нарисованные, но если имеет смысл. А так очень понравилось, что и детали и глобально интересные вещи подмечаешь
Я ниче не хочу сказать, но этот проект должен стоить больше 1400$ :)
Код неплохой, видно, что часть бережно перенесена с курса синдикатов, но это скорее плюс, чем минус, хотя то, что написано поверх него уже вызывает некоторые вопросы. Тут видна проблема многих разрабов, вкатывающихся в мидл-уровень, когда очень хочется все сразу максимально ручками написать без готовых решений и порой прям перебор с этим есть. Сам страдал таким несколько лет назад, благо, что в какой-то момент стал писать большой пет-проект и понял, насколько это самовтыкательство палок в колёса
Люди, помогите, пожалуйста как научится понимать как строить архитектуру приложения?
Все говорят про k-syndicate, что это архитектура под копирку, но что здесь плохого, если эта архитектура удачная. У этих людей за плечами много опыта, уж явно они больше знают джунов.
Читал книгу Роберта Найтстрома про геймдев паттерны, ведь по сути архитектура строится на паттернах, ну и конечно же прошёл курс от k-syndicate по архитектуре. Когда прохожу тестовые, то говорят проект не гибкий и не способен расширяться и не понимаю каким образом ещё более можно расширять проект.
Посоветуйте книжки по архитектуру приложений, желательно на c# или другой похожий язык как c++ например. Если у вас есть другое мнение и архитектура игры и приложения это разные совершенно вещи, то скажите тогда как в таком случае действовать
Мне помог способ через декомпиляцию кода чужих игр. Те что написаны на юнити лет 5 назад под ПК - их dll можно обратно в код превратить и увидеть как организуют код те, кто доводят до релиза игры
Спасибо! Попробую тоже так поделать
@@gamedev_expert
мб уже и поздно, но отвечу
сам сейчас заканчиваю прохождение курса от синдикатов и ничего плохого в нем нет. В курсе в некоторых местах по несколько раз (!) повторяется, что это делается для текущего тестового проекта и на продакшене такое лучше не делать. как пример - ручной DI. Но, как мы видим из данного ревью, не все слышат эти предупреждения ))
Делал подобное тестовое задание на джуна, тз очень схоже, как минимум начало и конец текста точь-в-точь одинаковы. То ли я неопытен и тз нормально составлять именно так, то ли это просто мошеннический шаблон)) Меня кстати не взяли, проигнорировали. А потом чат с работодателем и вовсе пропал...
Ничего все ошибаются, главное не делать это привычкой)
На мой взгляд эксепшены нужно кидать только при возникновении нештатной ситуации. Отсутствие предмета в инвентаре это нормальный случай, будет логичней возвращать Null.
Можно и так, пока в разборах не встречал использование nullable annotations, а жаль, очень крутой механизм
Пили еще код ревью, пжалста !!! Топ контент.
Талантище - сделать всё настолько запутанным... Похоже, что людям нужен константный уровень сложности - чем больше делает движок, облегчая разработку, тем хуже и запутанней код (чтобы компенсировать лёгкость). То, чему я бы не уделил и строчки, превращается в несколько классов в нескольких файлах на сотни строк
Драг-н-дроп и без фиксированных ячеек это уже nextgen inventory :)
Андрей, добрый день. Не так давно выполнял тестовое задание для стажировки в компанию. По итогу мой вариант выполнения отклонили, не указав в фидбеке вообще никаких конкретных указаний почему мои решения посчитали не эффективными. Можно ли как-то связаться с вами для получения адекватного ревью задания?
Привет, если не торопитесь и готовы к тому что это будет на видео, то присылайте dredstd@gmail.com
Полезный видос как для новичка (который даже не собирается писать на юнити). Лучше учиться на чужих и реальных ошибках, понимаешь как лучше писать код, спасибо)
в корне не согласен. Данное видео может быть полезно людям, примерно на том же уровне развития и занимающихся тем же и в той-же сфере, что и автор (ну и автору кода), чисто посмотреть по приколу на расслабоне. Как прим. см. комментарий yummybunny7351, обсудить, поспорить, типа "а вот тут не согласен" и т.д. а все остальное - возгласы безумной толпы. Для новичка нужно прочитать какого нибудь Шилдта и Рихтера, написать хелло ворлд и приткнуться в коммерцию стажером и учиться решать поступающие задачи, учиться у более опытных инженеров по факту и набивать СВОИ шишки. Без проблемы нет решения. Не знаю еще ни одного инженера, который лежа на диване с ютубчиком стал хотя бы джуном. Так что полезность данного видео для новичка (еще и не собирающегося работать в игровой студии на юнити) такая же, как полезность репостов бизнес цитат во вконтакте для того, кто хочет стать бизнесменом. Но как диковинное развлечение, почему бы и нет.
Делал тестовой на джуна - ТЗ оформлено также - пуля в пулю. Даже версия Unity указана таже. Естественно, отказали. Либо это шаблон такой ТЗ либо просто компания нахаляву получает прототипы.
Нормально выполненное задание для ТЗ. Не факт что автор сделает лучше. Открой любой пронект и можно сделать подобный ролик
9:40 Ну насколько я понимаю он используется для сохранения данных в бинарном формате чтобы пользователь не мог отредактировать
Это как бы прогресс игрока и так же защита данных от редактирования со стороны пользователя платформы, так что вполне оправдано его использование
Тогда надо шифровать перед сохранением, и правда будет понадежнее
Добрый день. Не нашёл ваших контактов.
Есть ли у вас платная услуга код ревью?
Напишите мне на почту dredstd@gmail.com, договоримся
Интересные видео,, с Вами можно как то связаться? Интересует клиент сервер на c# unity и в целом возможность переноса игры на движёк юнити или воссоздание и ли оно того?
Здравствуйте, вы можете написать на почту dredstd@gmail.com если есть предложения
Интересно, а можно ли Вам проект на обзор скинуть? Джуны, но вроде пишем понятно
Привет, скинуть можете, а когда у меня время будет я не знаю
А не слишком ли перегруженная архитектура, стейтмашина, кастомный проброс зависимостей вместо использования готового DI?
Да, лучше когда кода мало, но работает
привет, подскажи пожалуйста прогу для разминки глаз
Eye leo
Получается не разбор тестового, а скорее разбор архитектуры от K-Syndicate :) Ничего нового вообще не было добавлено.
Я конечно сам ее юзаю в некотором варианте, но если бы делал тестовое, что наверное бы делал что-то свое. Ведь каждый джун уже пишет так, как конкурировать если все одинаково?)
Надо посмотреть что за KSyndicate, столько людей говорят о них, а я пропустил как-то. По поводу что-то своё - я согласен что надо экспериментировать и развивать архитектурные подходы
@@gamedev_expert у них курс в 2019-20г архитектуры в основном они просто показывают бутстрап/сервис локатор/стейт машину показывают ещё пару паттернов
По сути, да, это точная копия их проекта, своя мысль там начисто отсутствует.
Что-то есть в папке Resources? Fail ! Из всего делаем гребанные адрэсибэлс и ничего не засовываем в ресорсэс. Нах** столько классов и интерфейсов - элемент в grid layout - гребанный префаб с одним скриптом на нем и один скрипт с интерфейсом на все окно, еще файл другой на настройки и модели данных и не е**м никому мозги.
Без особых требований на не использование какого-то механизма, фейлить тестовое на субъективной оценке инструмента путь одиночки, а не командного игрока
Капец код перегружен. Если б от меня зависело решение брать или не брать, я б тоже не взял. На мой взгляд архитектура должна быть максимально простой, но при этом максимально удобной и функциональной. Иначе на реальном тяжёлом проекте, где постоянно с тебя трясут быстрее, офигеешь от собственного нагромождения сервисов
А что тут неудобного и нефункционального?))
это приверженцы патернов, не обращай внимания. Они на своей волне. Поэтому от них прекрасный код, но нихрена нет успешных игр.
Привет, работу не ищешь случайно?)
У нас создается новая команда под юнити и это первая юнити команда в компании(другие игры были под веб на typescript), пока еще вроде никого не нашли, удаленка, компания из США, но все в основном из стран снг, не гк, проекты которые мы делали довольно таки серьезные, все игры онлайн, ситибилдеры и шутер от первого лица, нфти, крипта и подобное
Привет! Спасибо за предложение, сейчас только бекенд пишу. Есть два друга, с которыми вместе работали раньше, их может заинтересовать, можешь отправить ссылку на вакансию dredstd@gmail.com
@@gamedev_expert дал контакты нашему hr ну и подал запрос дружбы в линке)
Привет, а куда можно в личку написать?
Привет, можно на почту dredstd@gmail.com
ЗП очень маленькое для Мидла((( Так везде в гемдеве?
А среднем да. Всегда было что в геймдеве меньше денег.
Такое впечетление, что после курсов синдиката код написан)
Наверное так и есть
@@gamedev_expert наверно поэтому и отказали, думаю их уже все знают) Плюс это всего лишь один из вариантов архитектуры. я думаю с той стороны посмотрели на какую то непонятную хрень и забили просто, ожидали простой код для мобилочек а получили вот это все
@@UnityFAN_unity Автор канала похоже зря не показал текст тестового задания. Главным критерием оценки была архитектура проекта. По фидбеку сказали что моё тестовое сильное и из 10 выполнивших только 3 хорошо выполнили. Кстати я правда делал тестовое прямо после курса)
Что за курс? Можно подробнее???
www.youtube.com/@KSyndicate@@Vinnnik
Самая главная ошибка, выполнять бесплатно такие тестовые
1400 долларов за миддла ну да это жестко)
Для РФ - норм, геймдев сейчас не в лучшей форме там
@@petrow_ в англосфере сейчас сколько +-мидлу дают?
Код под копирку с курса @KSyndicate по архитектуре :D
К сожалению, да, никакой фантазии
а что плохого в том чтобы копировать удачную архитектуру?)
@@gamedev_expert Вроде ничего) Просто они вроде говорили, что на их уроке показываются внутренности DI, чтобы люди понимали как примерно работает тот же Zenject, и для чего это нужно. Другими словами, есть много готовых решений, чтобы не писать этот сервис локатор.
Я сам относительно новичек, и ещё только учу и пытаюсь понять всю суть архитектуры и подобных моментов, и пока мне вот конкретно вот такая часть кода, которая была разобрана в этом видео, все ещё сложно даётся. Я уже начал что-то делать для себя в Unity, и сильно привык к монобехам, и [SerializeField] полям, в которые через инспектор легко всё перетягивается. И вот подобный код, где всё надо прокидывать через конструкторы или иногда даже паблик поля, мне выглядит очень неудобным..
@@BlackWindX Юнити молодцы и сделали удобный инспектор, он упрощает быстрое прототипирование. И до какого-то размера игры я тоже за то, чтобы просто прокинуть ссылки. А дальше легко проспать и инспектор станет приговором игре из-за запутанности и сложности внесения исправлений
@@gamedev_expert мне кажется плохо (плохо для соискателя) копировать популярную архитектуру, т.к. она уже всем намозолила глаза. Типа, вот, ещё один пришёл с копипастой от синдиката.
Простенький инвентарь за полтора штуки баксов? А готовый "киберпанковский" инвентарь тогда 50к должен стоить)
у меня есть джуниоровское тестовое задание 3х летней давности когда я был в программировании месяца 1.5
пойдет на обзор? :D
Мне кажется это не будет интересно, вы и сами можете разобрать ошибки в том ТЗ)
Соглашаться на тестовые задания - это ошибка
Работать ошибка
Асинхронность методов для StateMachine совершенно не нужна и избыточна, если она правильно написана.
Привет, асинхронный метод превращается в стейт машину при компиляции в il код. Так что да, стейт машиной можно заменить асинхронный метод при желении. Если речь о стейт машине в загрузке, то у меня противоположное мнение
@@gamedev_expertПривет, да, речь о стейт-машине (на 11:36), а зачем ей быть асинхронной? Может дальше будет ответ - не досмотрел до конца, комментирую по ходу дела, пока мысль свежа. Другими словами, зачем методу Enter быть асинхронным и кто должен ожидать его заверешния? В момент вызова Enter включается в работу новый стейт и вся дальнейшая работа - это уже работа нового стейта, а предыдущий уже полностью свое отработал, поэтому он переключил и закончил на этом свою миссию. А так получается, что будет выплнен еще какой-то код из предыдущиего стейта после завершения Enter. Можно, конечно, применить логику, что Enter - это только пореходный момент в новый стейт, но даже в этом случае неясно, зачем предыдущему стейту что-то делать после того, как переход будет закончен.
Сразу оговорюсь, что я не навязываю свое мнение, а дискутирую.
По поводу - не писать тип явно где только можно, как раз наоборот делаю - пишу везде, кроме каких-то очевидных ситуаций, как в случае с using, где все и так знают, что за тип будет образован. В других случаях, когда другой программист будет читать мой код (или я сам через какое-то время), то даже беглый взгляд на конструкцию `Dictionary images = GetImages()` сразу дает четкое представление о смысле строки, а учитывая, что в контексте будут и другие строки, намного быстрее складывается общий смысл происходящего, чем в случае с `var images = ...`, т.к. тип - это еще и семантика. Завтра кто-то решит отрефакторить код так, что теперь метод будет возвращать текстуры и это сразу отразится в явном типе. Да, это может потребовать в некоторых IDE вручную пройти и отредактировать тип во всех местах вызова метода, но если это укорит понимание фрагмента кода пускай даже на 10 секунд, то я считаю, что оно того стоит. В примере вроде этого
```
var total= GetTotalAmountOfSometing();
var completion = GetCompletionPercent();
var completedAmount = total / 100 * completion;
```
было бы в разы проще не допустить или найти потенциальную ошибку, будь типы указаны явно, поэтому численные типы тоже указываю.
@@igd1591 верно говоришь
У меня было похожее тз, такое описание, но зажание другое, нужно было целую игру сделать, я по глупости сделал, отправил и меня просто кинули, никакой обратной связи, не ведитесь на это
Я не могу понять что вы все прицепились к тестовому заданию? Оно супер элементарное учитывая что чел идёт на мидла. Само задание умещается на одной странице документа, где большую часть занимают расписанеые статы.
А чел взял и буквально НАСРАЛ в код. Тебя просили срать?
Такой сотрудник никому нахрен не всрался, по факту такие люди будут только мешать/спорить/тратить время впустую.
Есть задача, она четко прописана - тебе надо её сделать. ВСЁ! Не сидеть придумывать кучу сервисов и всякой херни которые никогда не будут использованы и на которые ты потратишь в 200 раз больше времени чем должен был, и недайбох кому то другому кроме тебя придется это читать.
Ахахха, по сути ничего нового у тебя просто ещё 1 вариант как сделать
что это вообще такое? Ниче не понимаю... Где такому уровню учат?
очень круто, но очень тихо(
Спасибо, в следующем сделаю громко
1400 это аж никак не зарплата мидла. джун или джун + на крайняк
В общем согласен, но больше зависит от компании, чем от человека
@@gamedev_expert но сам видос отличный :) Было увлекательно)
Серьёзно, система инвентаря? Я думал что бы стать разработчиком надо как минимум писать онлайн игры
Большое начинается с малого)
Привет!!!
Как с тобой можно связаться?
Хотел бы пообщаться
Привет, напиши на почту dredstd@gmail.com
Написал, жду ответ :)
@@ИгорьБилык-п5д ответил