бамп
бамп
бамп
бамп
Роман suckутин,угадал?
>а дальше то что
Писать хороший(читай понятный) код
И не только он. Есть чел с канала Acerola (на ангельском) и конкретно ролик Game Development Tutorials Are LYING To You
Но больше всего меня вот этот коммент поразил
>Писать хороший(читай понятный) код
Отлично, как это сделать нормально?
бамп
бамп
бамп
бамп
Объектно-ориентированное программирование позволяет организовать программу вокруг её данных (т.е. объектов) и набора вполне определенных интерфейсов с этими данными. Объектно-ориентированную программу можно охарактеризовать как данные,
управляющие доступом к коду.
## Три принципа ООП (инкапсуляция, наследование, полиморфизм):
### Инкапсуляция
Это механизм, связывающий код и данные, которыми он манипулирует, защищая оба
эти компонента от внешнего вмешательства и злоупотреблений.
Инкапсуляцию можно считать защитной оболочкой, которая предохраняет код и данные от произвольного доступа со стороны другого кода, находящегося снаружи оболочки. Доступ к коду и данным, находящимся внутри оболочки, строго контролируется тщательно определенным интерфейсом.
Основу инкапсуляции в Java представляет класс - определяет структуру и поведение (данные и код), которые будут совместно использоваться набором объектов. Каждый объект данного класса содержит структуру и поведение, которые определены классом. Поэтому иногда объекты называют экземплярами класса. Таким образом, класс - это логическая конструкция, а объект - ее физическое воплощение.
Назначение класса состоит в инкапсуляции сложной структуры программы, и по
этому существуют механизмы сокрытия сложной структуры реализации в самом
классе. Каждый метод или переменная в классе могут быть помечены как закрытые
или открытые.
Открытый интерфейс класса представляет все, что должны или могут знать внешние пользователи класса. Закрытые методы и данные могут быть доступны только для кода, который является членом данного класса.
Следовательно, любой другой код, не являющийся членом данного класса, не может получать доступ к закрытому методу или переменной. Закрытые члены класса доступны другим частям программы только через открытые методы класса, и благодаря этому исключается возможность выполнения неправомерных действий.
## Наследование
Процесс, в результате которого один объект получает свойства другого, называется наследованием. Это очень важный принцип ООП, поскольку наследование обеспечивает принцип иерархической классификации. Объект может наследовать общие атрибуты от своего родительского объекта, это помогает определять его характеристики.
Подклассы наследуют все свойства родительских классов вплоть до суперкласса (изначального).
Новый подкласс наследует атрибуты всех своих родительских классов и поэтому не содержит непредсказуемые взаимодействия с большей частью остального кода системы.
## Полиморфизм
Полиморфизм - это принцип ООП, позволяющий использовать один и тот же интерфейс для общего класса действий. Каждое действие зависит от конкретной ситуации.
В более общем смысле принцип полиморфизма нередко выражается фразой
"один интерфейс, несколько методов”: Это означает, что можно разработать общий интерфейс для группы связанных вместе действий. Такой подход позволяет уменьшить сложность программы, поскольку один и тот же интерфейс служит для указания общего класса действий. А выбор конкретного действия (т.е. метода) делается применительно к каждой ситуации и входит в обязанности компилятора.
управляющие доступом к коду.
## Три принципа ООП (инкапсуляция, наследование, полиморфизм):
### Инкапсуляция
Это механизм, связывающий код и данные, которыми он манипулирует, защищая оба
эти компонента от внешнего вмешательства и злоупотреблений.
Инкапсуляцию можно считать защитной оболочкой, которая предохраняет код и данные от произвольного доступа со стороны другого кода, находящегося снаружи оболочки. Доступ к коду и данным, находящимся внутри оболочки, строго контролируется тщательно определенным интерфейсом.
Основу инкапсуляции в Java представляет класс - определяет структуру и поведение (данные и код), которые будут совместно использоваться набором объектов. Каждый объект данного класса содержит структуру и поведение, которые определены классом. Поэтому иногда объекты называют экземплярами класса. Таким образом, класс - это логическая конструкция, а объект - ее физическое воплощение.
Назначение класса состоит в инкапсуляции сложной структуры программы, и по
этому существуют механизмы сокрытия сложной структуры реализации в самом
классе. Каждый метод или переменная в классе могут быть помечены как закрытые
или открытые.
Открытый интерфейс класса представляет все, что должны или могут знать внешние пользователи класса. Закрытые методы и данные могут быть доступны только для кода, который является членом данного класса.
Следовательно, любой другой код, не являющийся членом данного класса, не может получать доступ к закрытому методу или переменной. Закрытые члены класса доступны другим частям программы только через открытые методы класса, и благодаря этому исключается возможность выполнения неправомерных действий.
## Наследование
Процесс, в результате которого один объект получает свойства другого, называется наследованием. Это очень важный принцип ООП, поскольку наследование обеспечивает принцип иерархической классификации. Объект может наследовать общие атрибуты от своего родительского объекта, это помогает определять его характеристики.
Подклассы наследуют все свойства родительских классов вплоть до суперкласса (изначального).
Новый подкласс наследует атрибуты всех своих родительских классов и поэтому не содержит непредсказуемые взаимодействия с большей частью остального кода системы.
## Полиморфизм
Полиморфизм - это принцип ООП, позволяющий использовать один и тот же интерфейс для общего класса действий. Каждое действие зависит от конкретной ситуации.
В более общем смысле принцип полиморфизма нередко выражается фразой
"один интерфейс, несколько методов”: Это означает, что можно разработать общий интерфейс для группы связанных вместе действий. Такой подход позволяет уменьшить сложность программы, поскольку один и тот же интерфейс служит для указания общего класса действий. А выбор конкретного действия (т.е. метода) делается применительно к каждой ситуации и входит в обязанности компилятора.
Тщательно продуманная иерархия классов служит прочным основанием для многократного использования кода, на разработку и проверку которого были затрачены время и усилия.
Инкапсуляция позволяет возвращаться к ранее созданным реализациям, не нарушая код, зависящий от открытого интерфейса применяемых в приложении классов. А полиморфизм позволяет создавать понятный, практичный, удобочитаемый и устойчивый код.
Инкапсуляция позволяет возвращаться к ранее созданным реализациям, не нарушая код, зависящий от открытого интерфейса применяемых в приложении классов. А полиморфизм позволяет создавать понятный, практичный, удобочитаемый и устойчивый код.
Да я знаю что это такое. Я не всегда могу понять когда это надо использовать, ведь проще не париться над этим и ебашить все в одном классе например
Просто выполняй то, что говорит солид. Сам солид подразумевает то, что ты не будешь бездумно всегда следовать ему, а думать своей головой и иногда забивать на то, что кажется ненужным или даже вредным.
ООП в юнити нахуй не нужно, там вместо этого ECS. Если ты работаешь без ООП, то для тебя это ненужное знание. Если бы ООП тебе было бы необходимо, ты бы разобрался, так как это мастхевная во многих вещах вещь.
> Отлично, как это сделать нормально?
Писать код, который, как ты мог догадаться, понятен. Не используй "магические" числа(типа speed9.8f, вместо этого speedgravity), используй паттерны проектирования, следуй принципам солид, именуй нормально переменные, просто думай головой.
> эти компонента от внешнего вмешательства и злоупотреблений.
Пошел нахуй, долбаеб. Сразу бы написал инкапсуляция == сокрытие.
Ну переменные я нормально именую, константы использую, а вот паттерны и остальное я же написал я просто бля не понимаю когда это применять
Шарпы пиздец простые, почти весь язык основывается на полиморфизме подтипов. Научишься реализовывать его - считай игру прошел.
чего скрытие? хуя в твоём анусе?
А вот и ебанат, обоссал бы тебя на собесе за такое.
Ты пишешь на юнити, забей. Тебе дали ECS в качестве замены ООП.
Почитай нормальное определение и поймешь, что ты дебил и жертва кривых переводов.
Штаны снять не забудь, скрывальщик
Я не хочу забивать. А про ESC прочитаю спасибо
Макака не осилившая 2 определения, спокуха.
> паттерны
Если ты не пишешь просто гигантскую йобу, в 99% они тебе не нужны, кроме пары ну совсем типовых структурных или порождающих.
> SOLID
Это буквально "изолируй компоненты нормально, а не как долбоеб" - это вообще дефолт.
> OOP
Ого, код можно представлять в виде взаимодействующих объектов, ебать как сложно-то.
> алгоритмы
Все сводятся к разбиению задачи на куски, втыкаемые в правильные структуры данных, ну и подсчету итоговой сложности O(n)
виталя жопачич фуфел
Правильно написал, красава.
Я геймдевом не занимаюсь, но суть та же.
Чтобы сделать ИДЕАЛЬНО у тебя на руках должна быть вся концепция по всем сущностям в игре, взаимосвязи между ними, действия которые эти сущности делают и что над ними делают.
А теперь ты понимаешь, что у тебя в начале разработки НИКОГДА не будет подобного на руках? Скорее всего разработчики игр пользуются некими своими референсными моделями(т.е. типовыми), которые они наработали через боль и которые позволяют определить эти взаимосвязи в самом начале разработки в зависимости от верхнеуровневой концепции, которую слепит главный по тарелочкам. Т.е. условно - делаем пошаговую РПГ, значит такие-то базовые сущности, вот тут вот может поменяться, вот здесь ебанём абстракцию и т.д. А если делаем экшен от первого лица, то будет такая модель, ну ты понел. Такие вещи могут знать только опытные пожравшие говна разработчики. В книжках обычно же дают ультимативные гайды, которые тебе голову забьют.
По поводу ЧИСТОТЫ, лол, кода скажу только лишь, что его не существует. Тот же самый Мартин Роберт К. в своей книге "Чистый код. Создание, анализ и рефакторинг " противоречит сам себе. Поэтому самоет главное - код должен быть понятным и легко читаемым. Есть исключения это какие-нибудь переоптимизированные куски кода на С с какими-нибудь ассемблерными вставками, но это дикая редкость.
мимо-архитектор
гл наносек будущий
Тогда отойди от юнити. Но это очень долгий процесс, что бы понимать, какие паттерны вообще использовать и в каких случаях.
Я не осилил? Мань, это ты описал инкапсуляцию так, что приравнял ее к сокрытию.
дмитрий базовичок насрал в рот жопичу
Я вообще мимо проходил, а тот долбоеб копипастнул с какой-то хуйни, три принципа ооп.
димка куприянов
>На работе у нас один из главных принципов "главное чтобы работало"
Это говнокотора. Постарайся сбежать оттуда.
мимо-такой-же
>Делаю игру для себя
А тебе не нужен композитор/саунд-эффект инженер?
хочешь бесплатно это делать?
Компания чуть ли не лидер в РФ в своей сфере. Бежать планирую но некуда, никуда не берут
Игры делаю максимально простые ссылку могу дать увидишь, так что нет.
>используй паттерны проектирования, следуй принципам солид,
Говноеды паттерны ради паттернов в треде, я спокоен. Привет Барбаре
>Только можно без советов в стиле "пиздуй учить ассемблер и регистры"?
Попроситься подмастерьем в нормальную геймдевелоперскую.
>Как применять все эти паттерны/SOLID/OOP/
Никак, это кал.
>Вводные: программирую на C#, и
Сочувствую.
>где автор говорит о том что 99% гайдов в интернете они сделаны максимально неверно с точки зрения оптимизации, и хуже начинающего юнити разраба трудно найти кого-то.
Тоже слышал, проиграл с этой хуйни.
Просто делай нормально. Постоянно думай как уменьшить кол-во исполнения кода, как постоянно уменьшать нагрузку и сокращать кол-во операций в кадре.
>Уважаемые наносеки, как лечиться от этой хуйни? Только можно без советов в стиле "пиздуй учить ассемблер и регистры"? Спасибо
Делай на ECS и императивщине. Под C# ECS движков полно уже, просто бери один из них и работай. Будет оптимально.
Просился - из 20 вакансий только 2 на джуна, остальные от мидла и выше. А на собесе на мидла обосрался с тестовой задачей причем достаточно простой.
Да, годно, надо в эту сторону копать
>РФ
Настоятельно рекомендую тебе заводить трактор в Турцию, Армению и работать на зарубежных заказчиков. Подтягивай английский и уёбывай дальше. В РФ гейдева не будет
мимо-архитектор
Сколько работаешь суммарно?
я из группировки зоодауны
Оно отжимается?
Я достаточно хорошо знаю английский. А как мне "уебывать" я хз если я даже здесь особо никому не нужен.
Вот уже год пошел. До этого год не работал а до этого 10 мес эникеем работал. Мне тема админства больше нравится, тут я скорее от безысходности. А игры для себя делаю, радует что вырвался из этой секты безыгорных
>"главное чтобы работало"
Ты попал в говноконтору. Работаю на заводе, и по поводу оптимизации нас ебут за каждую лишнюю строчку кода.
По поводу геймдева, что ты пишешь - я столкнулся с этим же самым. Писал по дипломной работе мобильную игру на юнити, в которой костыль на костыле. Мне нужно было замутить удаление трупов на уровне, для этого я мутил разные таймеры и прочую хуйню, а потом узнал, что можно просто в конце скрипта прописать количество фреймов, через которые скрипт сработает, то есть:
> [функция], 5f
По поводу туторов не понимаю говна. Да, они не сделают из тебя трухацкера (или сделают?) Я наоборот костыльность кодов из уроков считаю плюсом. Если ты не тупой и хоть немного думаешь, то начнешь понимать, что код не идеален, и его надо дорабатывать. А это повышает твои вкатыши. Вооот.
В общем, ищи инфу, справочники всякие, не пиши сразу код, обдумай функцию. Вдруг, окажется, что за место двадцати строк выйдет всего ПЯТЬ
Хуй знает, тоже пишу на шарпе игры и у нас в проекте есть места где по 10к строк кода в одном файле одного класса. Главная проблема наверное в том, что конечный результат нихуя не известен, гейдизайнеры/продукты постоянно переобуваются и вносят правки в дизайн фичи. Потом еще появляются фичи модифицирующие изначальную фичу, а т.к. этих модификаций никто не предусматривал вставляются костыли и вот так постепенно проект обрастает говном.
Удваиваю мнение этого говнокодера.
Ничего не учи оп, думай там про всякие кол-ва кода и т.д. и пиши не особо думая крч "чтобы проста работала!!" - нечего покушаться на работу тру программистов с их паттернами, видами архитектуры и т.п.
>Ты попал в говноконтору. Работаю на заводе, и по поводу оптимизации нас ебут за каждую лишнюю строчку кода.
это ты попал в говноконтору, бро
Сам додумал?
По каким критериям ты это понял?
Я полгода в говноконторе за 20 работал, потом в другую говноконтору съебался за 20к, выпросил до 80к, уже два года в ней сижу, вот к интервью готовлюсь, резюме подобновил. Твои действия: гугли че модно щас,читай статьи, дрочи ооп/солиды, смотри ютабчик по теме, учи вопросы по интервью, патерны, обнови и открой резюме на хх, соберись с силами и найди в тг чатиках кто поможет написать небольшой пет но очень качественный, чтобы ты тестовые эти не делал. Я по такому плану щас действую. Как найдешь новую работу резюме не закрывай, но начинай подрачивать литкод и сисдизайн чтобы залететь не сеньера. Не теряй времени как я, в таких конторах можно бесконечно сидеть.
по тем которые процитировал
Ну и закрепляй модные штуки на работе, постарайся писать новые фичи на нормальной архитектуре с тестами и тд. Иначе в 30 лет так и останешься жуниор+.
Ну если проект интересный, почему бы нет?
Работал как-то в конторке, где был шизо-тимлид, который написал собственный ECS и собственный DI-фреймворк для игры, по итогу, из-за хуевого подхода и вот этой ментальности "паттерны ради паттернов" игра очень хуево работала (в 40-30 кадров на новых телефонах), а в коде было невозможно разобраться, потому что было очень много зависимостей. Такие еще люди дрочат тебя за то, что ты GetComponent пишешь и прочую хуйню и не совсем понимают, что нынешние железки могут спокойно справляться со многими "тяжелыми" функциями.
Такие шизы еще начинают потом страдать и стандартные компоненты Юнити переписывать самостоятельно (тот же ScrollRect, например и т.д), и получаются велосипеды.
Имхо, я считаю, что Юнити-техи лучше шарят, чем какие-то мамкины чуваки с их паттернами, да и большинство паттернов не совсем применимо для Юнити (тот же MVC, например, нахер там не сдался), потому что сам Юнити архитектурно использует компонентный подход. Зачем плодить паттерны ради паттернов, которая не особо-то и даст производительности — непонятно.
К чему я: я не за то, чтобы люди писали говнокод, но скорее за итерационный подход к обучению. Нужно балансировать и использовать "наивный" подход. Сфокусируйся больше на реализации какой-то фичи, на самой геймплейной механике, а не о том, как сразу сделать правильно всегда сделаешь неправильно
Итерационно обучайся, улучшай свой код и смотри на места, где можно что-то отрефакторить и сделать, возможно, вынести куда-то ТАК, чтобы человек, который пришел с другого места мог разобраться в этом коде.
Такие шизы еще начинают потом страдать и стандартные компоненты Юнити переписывать самостоятельно (тот же ScrollRect, например и т.д), и получаются велосипеды.
Имхо, я считаю, что Юнити-техи лучше шарят, чем какие-то мамкины чуваки с их паттернами, да и большинство паттернов не совсем применимо для Юнити (тот же MVC, например, нахер там не сдался), потому что сам Юнити архитектурно использует компонентный подход. Зачем плодить паттерны ради паттернов, которая не особо-то и даст производительности — непонятно.
К чему я: я не за то, чтобы люди писали говнокод, но скорее за итерационный подход к обучению. Нужно балансировать и использовать "наивный" подход. Сфокусируйся больше на реализации какой-то фичи, на самой геймплейной механике, а не о том, как сразу сделать правильно всегда сделаешь неправильно
Итерационно обучайся, улучшай свой код и смотри на места, где можно что-то отрефакторить и сделать, возможно, вынести куда-то ТАК, чтобы человек, который пришел с другого места мог разобраться в этом коде.
Создай резюме на LinkedIn и проходи собесы. Быстро поймёшь что от тебя требуют. Чем раньше начнёшь, тем лучше.
Есть и другие сайты для работы, но LinkedIn самый крутой, единственное, он может потребовать номер телефона, а на номера РФ смска не приходит
Вот этого двачую. Паттерны ради паттернов хуита полная. Не надо забывать, что разраб в первую очердь создаёт ценность за конкретные сроки и за конкретный бюджет. Не надо писать движок скайрима, если у тебя это далеко не скайрим
мимо-архитектор
просто есть чуваки, которые писали хуигры до юнити, и они свой подход пытаются тащить туда, так как разбираться в екс юнити им нахуй не упало
это я к тому, что дело не в шизе, а в лени
Ну вот смотри. Погромист Мортал Комбата
https://www.ppa.pl/gry/interview-with-richard-costello-coder-of-mortal-kombat-primal-rage-terminator-2-golden-axe-gauntlet-2.html учился на исходнике, так сказать. Он самостоятельно осваивал Ассемблер во время внеклассных занятий. И как-то додумывался строить правильные логические логические цепочки в коде. Ни Ютюба, ни даже Скиллбокса не було. Как ему это удавалось? В чем секрет? Может потому что он просто фанатично штудировал ассемблер и получал от этого кайф?
>Имхо, я считаю, что Юнити-техи лучше шарят, чем какие-то мамкины чуваки с их паттернами, да и большинство паттернов не совсем применимо для Юнити (тот же MVC, например, нахер там не сдался), потому что сам Юнити
Ты НИЧЕГО не знаешь о Юнити, если судить по твоим разглагольствованиям.
https://youtu.be/syvjmS-mflY
А SuckOotIn тот еще шиз же. Вот, например, ТЗ для джуна по юнити.
Лепить абстракцию над абстракцией, потому что это демонстрация "знаниев" паттернов это ну оч странно.
книги были, древнее знание бумеров
Нет, он просто как это делают на практике и применил эти знания. Это не rocket science, а элементарное обучение на практике
паттерны нужны в интерпрайзе и вебе, в гейдеве достаточно солида и екс если есть готовое двигло
А по Юнити древнего знания древних петушониксов сейчас нет?
Паттерны нужны как минимум для прохождения интервью.
> говнокодер на ООП бахнул и не осознал что ECS и есть архитектура
Юнити уже абстрагировала рендер-логику для тебя, чтобы ты мог сидеть и думать о МоноБехах, как о контроллерах для логики твоей игры.
Пытаться слепо следовать паттернам, потому что это паттерны - это крайне хуевая затея, ну и по сути, аутизм ради аутизма.
>> говнокодер на ООП бахнул и не осознал что ECS и есть архитектура
>Юнити уже абстрагировала рендер-логику для тебя, чтобы ты мог сидеть и думать о МоноБехах, как о контроллерах для логики твоей игры.
Ладно, оправдывайся сколько влезет.
ТАБЛИЦА УМНАЖЕНИЯ НИ НУЖНА
@
У НАС ВЕДЬ КАРКУЛЯТОРЫ ЕСТЬ))
>ECS
>а в коде было невозможно разобраться, потому что было очень много зависимостей.
Хуя пиздабол.
Зачем ты свою фотографию запостил, пердикс?
>пердикс?
Он петушоникс, ты перепутал.
Блядь... Да как ты капчу вводишь? Просишь кого-то из взрослых помочь?
Речь о применении паттернов, а не о знании. И о том, чтобы отговорить человека в лишний раз быть аутистом, а наконец взять и допилить фичу.
А так, ничего против паттернов не имею. Можешь хоть 300 человекочасов потратить ради охуительной архитектуры. Вопрос в том: действительно ли это нужно для Юнити и действительно ли это нужно тебе?
Люди не просто так GoF писали, даж там написано, что должно быть чёткое понимание того, в каком кейсе тебе надо применять определенный шаблон.
В геймдев-проектах очень много грязного кода, где-то даж исходники Ori был или Hollow Knight-а, и там было много синглтонов, простых наблюдателей.
Лучшей идеей будет вообще для Юнити это не пользоваться вашими MVC, MVVM, и работать с игровыми объектами как с отдельной системой.
Либо использовать ECS, как уже выше предлагали
Двачую этого. Это по сути то, что я и хотел сказать выше
Годный совет спасибо
мне мой дногруппник говорил что залетел без опыта откликнувшись на мидловскую вакансию и те после собеса дали ему джуновскую при том что изначально у них такой не было
Я про его DI, c его ECS у меня проблем не было.
У нас чётко был разбит мета-геймплей и сам геймплей игры.
В мете у нас в основном был MVC, а для самой игры - ECS.
Ну и еще поверх всего этого DI, с помощью которого ты инжектишь зависимости и туда и туда.
Но биндить их, регать, и смотреть за всей этой магией, а потом смотреть и не понимать откуда это пришло — тот еще аутизм.
Ну, сиди дальше проектируй охуенную архитектуру для передвижения куба в пространстве и свой векторный класс, пока все нормальные челы уже игровые механики будут добавлять, лол.
ОП, ты удивишься, но чтобы писать НОРМАЛЬНЫЕ игры, тебе нужно овладеть ЛОГИКОЙ в первую очередь. И как обще-дидактической из учебников, так и логикой самой жизни. Тебе нужно разработать инстинкт, который помогает достигать сложных целей простыми путями. Начни читать литературу, которая сама направляет на размышления по типу Аристотеля или Агады, наблюдай за природой, изучай движения бойцов или хореографов, прочти общий курс физики, находи ответы на старинные загадки древних сфинксов, погрузись в Дао. Всё, что – это часть вселенской логики. Стройной и безупречной.
Алсо, Юнити-физикой тож не вздумай пользоваться, это да, это не для тебя написано.
>ну знаю я эту концепцию ООП и SOLID
> как всю эту хуйню применять в реальной жизни?
Не знаешь.
>На работе у нас один из главных принципов "главное чтобы работало"
Беги оттуда нахуй. Вы небось ещё и тесты не пишете.
Если знаешь и понимаешь SOLID - то всегда думаешь о соблюдении принципов при написании кода. Сразу подсекаешь любую возможность его нарушить. Читая чужой код - видишь, где автор обосрался.
SOLID - это не абстрактная академическая хуйня, это вполне понятные и конкретные принципы, соблюдая которые ты напишешь чистый, поддерживаемый, тестируемый и расширяемый код.
мимо синьор-помидор, тред не читал
>Алсо, Юнити-физикой тож не вздумай пользоваться, это да, это не для тебя написано.
Петушоникс, спок. Ты себе много накрутил.
>мимо синьор-помидор, тред не читал
>Мимо сеньор-пиздобол
Бля, ток ща заметил, что ты квадрипл.
А так, да, чет мало работы с DOTS. На самом деле, давно пора.
Еще раздражает то, что во многих новых проектах все еще старая UI-система, а не новый Ui Toolkit, но в целом, какие-то проекты просто живут овердохуя лет и перейти на что-то новое позволить се не могут.
Сеньер пиздабол, нахуй пройди, найди хоть одну геймдев компанию в которой всей этой хуйне следуют, если делать все как "надо", то нихуя в сроки не сделать да и нихуя работать не будет, гейдев это в целом костыли на костылях
Действительно, как я мог спутать.
Петушоникс, не рвися.
А понял, совсем обдвачевался.
>В мете у нас в основном был MVC, а для самой игры - ECS.
>Ну и еще поверх всего этого DI
Бля бред какой-то. Нахуя к ECS такую хуиту прикручивать? Там же ДАННЫЕ, какие DI и MVC ещё? Для ECS dataflow паттерны есть, которые предсказуемо каждый мессаж обрабатывают.
>если делать все как "надо", то нихуя в сроки не сделать
Так говорят только ебланы, которые сами нихуя кодить не умеют. А ворох багов разгребать есть время? А кучу кода ради одной фичи переписывать есть время? А разбираться в нечитаемой хуйне, написанной полгода назад есть время? Ойблять, иди нахуй.
Чистый код пишется не дольше говнокода, если даже не быстрее. Чистый код - это минимальное проектирование и скилл, а не пердолинг и ООП ради ООП.
Еблан, баги будешь разбирать только те которые совсем пиздецовые, и потом еще коммунити сможешь показать что вот смотрите баги фиксим хуле ноете что контента нет и похуй что контентом и багами занимаются разные люди, а к старой хуйне в гейдеве возвращаются только чтобы переписать, понятное дело что прям базу механик надо бы написать нормально, но все остальное пишут на один раз шобы работало,.
Так как принципиально нового никто почти не пишет, зная паттерны, можно перебрать их у себя в голове и попытаться использовать один-два для решения своей задачи. Использовать паттерн ради использования паттерна это хуита, понятное дело.
Откровенно — я хуй знает. Знаю только то, что когда я пришел на проект, я увидел кучу инжектов везде, были еще свои классы-регистраторы и много прочей залупы.
А лид объяснял это тем, что это просто удобно, что ты берешь и не задумываешься, и вместо того, чтобы самому вешать ссылки на объекты тебе проще написать одну строчку.
А еще, как я понял, его ECS и не совсем-то и правильно порой отрабатывал. Долго не мог понять, почему бы не использовать что-то готовое.
Я был там зеленым джуном и на мои вопросы он всегда отвечал что-то вроде "Мы великая компания и себе это можем позволить, м ы не должны полагаться на сторонние штукенции"
Я бы мог бы еще рассказать сторю о том, как он не разобрался с маскированием (и отказался от использования стороннего SoftMask, и от СВГ, когда у нас были спрайты с лесенками, но это долго.
Всё так.
Ну зато опыт охуенный получил, лол. Как точно не нужно делать.
Есть. Ситуация та же. А я даже бейджики апнул некоторые
> Как применять все эти паттерны/SOLID/OOP
Ну как применять, лол, просто берёшь применяешь.
Посмотри на свой код, пройдимь по всем принципам солид и подумай, какие из них он нарушает.
Паттерны ты и так используешь, просто не знаешь их названий - поэтому ещё раз пройдись по всем паттернам, вспомни их и подумай где какие могли бы круто зайти.
Ты как бы можешь нормально программировать и не зная про солид и паттерны, а самостоятельно дойти до схожих концепций, прсото вся из суть - это чтобы код был понятным и легко пооддерживаемым, поэтомц в следующий раз когда заметишь что залупа получается(именно с практической точки зрения - вот надо поменять что-то и ты видишь что просто земля говном надо кучу всего дергать) - думай, как бы это можно было сделать лучше
>алгоритмы
Ну если игры делаешь, то иногда они нужны
Что-то научиться делать можно только через собственный опыт. Вот и делай магнум опус на >100к строк кода, который тебе реально интересно писать. Типа своего фичастого 3д-фреймворка, таким все норм вкатуны в геймдев занимались. В дотнете есть игровые движки, но нету полноценного code-first 3d гейм фреймворка, пока даже у сраных джавистов есть libgdx и у растовых хипстерков есть bevy с fyrox. Можешь в очередной раз попробовать исправить эту несправедливость, взяв silk.net и начав писать всю хуйню. Ну или хотя свой GUI общего назначения можно написать, это тоже мишн импосибл. Ну или свой рендерер векторной графики со сглаживанием, sdf-шрифтами, типографикой и прочей хурмой. Без солида и прочих паттернов просто автоматически зашьёшься, начиная с какого-то объёма кода. И отслеживай, в каких моментах начинается страдание и какими способами ты его лечишь. Только на собственной шкуре реально понять, в чём смысол всего этого пиздабольства об архитектуре.
Лол, это неплохой совет, на самом деле, хоть и слишком широкий. Я так забил на сраный геймдев и стал скалистом в тиньке. Может быть, именно в этом великая сермяжная правда логика жизни. Нахой он нинужон этот геймдев, там одно расстройство, посоны.
Чел, ты ебанулся? Если писать говно, то потом будет такая душниловка ближе к релизу, что ебанутьчя можно
>то потом будет такая душниловка ближе к релизу, что ебанутьчя можно
Примерно так и работают многие гейдев компании
>и стал скалистом в тиньке.
Писюнькой лакомишься за 150 тысеч??
>Петушоникс, не рвис
потому что человек не в силах все запомнить
читай книжки про всякие ооп, статьи итд. в голове выстраивай идеальную структуру. а при возможности текущий код улучшай, если не сильно дофига времени займет или не надо будет 100500 классов переписывать.
так и научишься
Я бля не понимаю кстати как техническую литературу читать. Только разве как справочник если. Ибо как обычную книгу читать у меня нихуя не запоминается
你好！
Ну да, кто спорит то, только как по другому? На всю компанию 2-3 нормальных программера которые делают базу, и бездари которые клепают все остальное
Ну да, кто спорит то, только как по другому? На всю компанию 2-3 нормальных программера которые делают базу, и бездари которые клепают все остальное
ну про ооп я бы не сказала что она прям техническая. там философии больше всякой должно быть. не сами паттерны, а то где как и когда их применять.
прикидываешь себе систему сущностей и пытаешься придумать какими паттернами ее реализовать.
но вообще если речь шла про юнити, там могла быть другая оптимизация - графическая. как фпс увеличить. это вообще совсем из другой сказки
Да, скорее всего, в ролике про фпс было но тем не менее, к примеру грамотно реализованный спавн врагов делает игру производительнее нежели брутфорсом
Как применять все эти паттерны/SOLID/OOP/алгоритмы в реальной жизни и не привлекать внимания санитаров?
Вводные: программирую на C#, и на работе тоже. Делаю игру для себя (уже сделал, но хочу новые делать). Наткнулся буквально 5 минут назад на ролик, где автор говорит о том что 99% гайдов в интернете они сделаны максимально неверно с точки зрения оптимизации, и хуже начинающего юнити разраба трудно найти кого-то.
Вопрос: как всю эту хуйню применять в реальной жизни? Ну изучил я какие-нибудь алгоритмы, ну знаю я эту концепцию ООП и SOLID, а дальше то что? На работе у нас один из главных принципов "главное чтобы работало", но хочется же делать нормально. А как сяду делать игру, то постоянно костыль на костыле получается, хоть и игра до безумия простая и там оптимизация особо не нужна. Но меня пугает что эта привычка сохранится и я так и останусь долбаебом.
Уважаемые наносеки, как лечиться от этой хуйни? Только можно без советов в стиле "пиздуй учить ассемблер и регистры"? Спасибо