Хватит страдать: Выбросьте ООП и ECS. Есть путь проще

Я тут если что не пытался выступать против ООП, я выступал против той парадигмы, которую описал автор. ООП, если его правильно готовить, позволяет работать изолированно (хотя ECS для этого подходит натурально лучше, уже 100 раз описано почему в других статьях). Вообще не понял откуда такая "защита" ООП, если я его даже не "атаковал".

Интересно как крупные ААА игры пишутся, на олдскульной парадигме? Просто кому то ООП не нравится вот и придумают новое, а по факту все нужное уже есть😅

AAA игры не пишутся на олдскульной парадигме, достаточно заглянуть в документацию UE4/5, либо поискать инсайты из других закрытых движков, там везде +- одно и тоже (ООП). Но это так, к слову.

Хватит страдать: Выбросьте ООП и ECS. Есть путь проще

Это конечно всё классно, но "Talk is cheap. Show me the code".

Из того, что я прочитал и понял (сужу только по тексту, кода то нет), выглядит как решение для небольших/средних проектов и небольших команд.

Я просто представляю как 50 программистов на проекте, где 500 фичей в которых количество компонентов и систем иногда переваливает за полсотни, будут писать на этой одскульной парадигме.

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

Ещё тяжелее представить, как объяснить полсотне людей идею, правила и идиомы. На любом проекте каждый программист и так пишет по-своему, но с ECS это "по-своему" имеет одинаковый скелет, схожий интерфейс для взаимодействия между фичами и какие-то рамки.

Ещё непонятно где данные держать, тот же массив Unit[] или MagicData[]. В глобальной переменной с типом GameData?)))

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

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

LuaJIT: что делает его таким производительным и почему вам стоит его попробовать

Все бенчмарки подобного рода - мусор.

Разница иногда в 10 раз, Lua уходящая в "timeout", ну и местами мягко говоря неодинаковый код (например JS worker-threads против обычной Lua), кароче не вериться.
Peak-mem у Lua в 2-10 раз ниже, то есть вполне возможно, что у Lua большая часть времени ушла на сборку мусора, а условный "default-heap-size" просто забыли настроить. Ну и смысл от таких сравнений.

Unity: корутины и UniTask — когда что использовать

1. Корутины можно остановить через StopCoroutine, имхо это даже проще токенов.

2. На пример с "ECS" больно смотреть, написали бы лучше пример с заведомо async вещами, тот же http-запрос, потому что игровую логику тасками в ECS не пишут, но окей.

3. Пример с ECS не раскрывает минуса корутин, свой глобальный CoroutineManager для сцены пишется за 5 минут. Я бы наоборот выделял привязку к объекту как возможный плюс, потому что таскаться с токенами, либо ловить нулрефы в повисших тасках не прикольно.

Исследование переработок в игровой индустрии

Звучит как "давайте делать интересные игры, чтобы программистам было интереснее работать", но программирование это работа, и хоть там есть свой фан, платят за результат, а не за то, что тебе весело делать фичу. Продукт не должен подстраиваться под исполнителя, поэтому в этом нет никакой проблемы.

Насчёт мобильных игр сервисов нужно пожалуй отдельное исследование проводить, но из анекдотов и рассказов пока складывается следующая картина, что кранчей больше всего в инди и ААА, потому что либо твоё время на разработку ограничено денежными накоплениями, либо игрокам обещали релиз к конкретной дате, либо очень много желающих поработать над большим крутым проектом, даже в ущерб себе, здоровью и личной жизни.
В этом плане мобильные дрочильни с донатом, особенно которые взлетели, самое комфортное место для работы, именно потому, что туда никто не рвётся, при этом там хорошо платят, и там большую часть времени можно работать "с 9 до 5".
Ситуация буквально зеркальная с программированием вне геймдева. "Скучные", но прибыльные проекты, условный энтерпрайз, финтех и т.д. как правило предлагают наилучшие условия, как по зарплате, так и по загруженности.

ООП: худшее, что случалось с программированием

Я то конечно согласен с утверждением, что ООП не единственная и не самая лучшая парадигма на свете, и далеко не всегда её применяют уместно. Люди начитываются клинкодов и книжек по паттернам и начинают писать по догмам, это всё понятно.

Не совсем только понятен момент по ФП. Вы специально ввели свою терминологию, где описали ФП как структуры + функции. Замечательно, то есть сюда помимо канонично функциональных языков программирования (Haskell, F#, Scala и т.д.) подходят как минимум C, Odin, Zig, наверное ещё Rust, а также в зависимости от стиля JS/TS, Python, C++, Go и многие другие языки.

Вы приводите пример с row polymorphism:

const getDisplayName = (user: {firstName: string, lastName?: string, middleName?: string} | null | undefined) => { ... }

Если что данной фичи нет в большинстве языков, которые я привёл. Так умеет только TS, а также JS и Python (из-за типизации). Почему это свойство приписывается к ФП (в вашем понимании), не совсем понятно.

Затем вы приводите пример с union:

type Shape = Circle | Rectangle

Тут лучше, хотя даже здесь я могу выделить C, C++ и Go, которые на уровне языка tagged unions не поддерживают. И всё ещё непонятно, почему данный способ приводиться как универсальный и заведомо лучший. Zig и Odin оба поддерживают tagged unions на уровне языка, но достаточно открыть реализацию структуры Allocator стандартной библиотеки для каждого из них и вот что мы увидим:

// Odin
procedure: Allocator_Proc,
data:      rawptr,

// Zig
ptr: *anyopaque,
vtable: *const VTable,

Ого, это ООП или ещё нет? По-моему вполне себе попытка эмулировать ООП, причём очень успешная, потому что люди заходят создавать свои аллокаторы, а не юзать юнион из 5 которые предоставляет std/core.

Потом вы называете методы мусором:

// Rust
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

// Zig
const Door = struct {
    is_open: bool,
    pub fn open(door: *Door) void {
        door.is_open = true;
    }
    pub fn open_can_be_null(door: ?*Door) void {
        door.?.is_open = true;
    }
    // Door.open(door)
    // door.open_can_be_null()
};

А это можно называть методами? Думаю да. Языки ООП в привычном понимании? Вообщем-то нет, я бы оба отнёс к процедурным.

В целом непонятна эта неприязнь к методам, ведь как я уже сказал, если вы в условном C мы напишем глобальную функцию принимающую конкретную структуру, то никакого магического ducktyping по полям там не случится и переиспользовать эту логику для чего-то ещё не выйдет. Метод это обычная глобальная функция, где как вы сами сказали, есть неявный (а иногда и явный) this/self, и удобный вызов через точку. Тут нет никаких кардинальных отличий, и в некоторых языках это отлично видно. Тоже самое можно сказать про class/struct/type, зачастую это просто синтаксис, и разница видна только в конкретных языках в конкретных кейсах.

При всём этом вы приводите Go как язык, который вот уже почти подобрался к званию идеального, ведь там нет классов, но создатели таки оставили методы. Странно, потому что Go вроде как считается классическим ООП языком, там тебе и методы, и интерфейсы, и облегчённое наследование через включение полей структур, и инкапсуляция через camelCase.

Это уже не говоря о попытке показать инкапсуляцию для "ФП", когда мы используем замыкания, которых нет в части языков, которые я привёл, а в некоторых нет даже лямбд, и не во всех из них можно свободно и удобно кастить указатели на функции. Зато в Rust, Zig, а также частично в Odin, откуда-то взялись "pub" или "(private)". Скрыть поля или логику можно даже в C через opaque/incomplete types или static.

В итоге, вы формируете свой термин ФП (который большинство называет ПП), а затем начинаете "уничтожать" ООП языки, разбирая механизмы, которые не имеют прямого отношения к ООП, через механизмы, которые не имеют прямого отношения к "ФП" в той терминологии которую вы используете.

Статья выглядит больше как реклама TypeScript на фоне Java/C#, либо даже как реклама классического ФП (не в вашем понимании), но никак не как успешная попытка столкнуть между собой две парадигмы. Запинать ООП или тот же C# можно было бы гораздо изящнее.

Цири, как протагонист Ведьмак 4 — это провал?

Так и слава богу, что заткнутся и примут, потому что сейчас люди не особо понимают, что повестка, а что нет, в итоге она им в каждой игре мерещится. У Цири нормальная внешность, которая к повестке никакого отношения не имеет.

«Make games great again»: Илон Маск спровоцировал скандал из-за повесточки в игре

Возможность выбрать местоимение в видеоигре это так плохо, особенно если это фентези, мы будем бороться против этого, это ведь здравый смысл.

Какой джун без гитхаба и хоть одного дипломного проекта, казалось бы? А ВОТ`!`

Может самим на вакансии откликаться?) И статьи прикреплять, там может оценят.

Nau Engine: взгляд под капот. Ядро движка

Как разработчик на Unity в СНГ, вопрос, почему надо таргетить именно Unity и СНГ?

Даже если мы берём Unity как самый популярный движок по миру, любой ААА движок это всегда C++, самый популярный скриптовый язык среди геймдев плюсовиков это Lua, так что на мой взгляд отличный выбор.

Если ориентироваться на популярность, то скриптовым языком надо добавлять Python или JavaScript, но ориентироваться надо не на вакансии. Движок должен быть ориентирован на целевую аудиторию (не самую широкую из возможных) и использовать соответсующий инструментарий.

К тому же как с Godot, можно прикрутить любой язык, так что C# на стороне скриптинга мы тоже в последствии увидим.

Возможно, вам не нужен ECS

Я так понимаю речь про "ROC theorem: Readable, Optimised and Correct code."? Если да, то это какой-то левый сайт, где нет никакой математики и доказательств, поэтому хз кто осмелился назвать это теоремой. Максимум субъективное рассуждение. Другой "теоремы" найти увы не смог.

Заповедь о преждевременной оптимизации это не заповедь и не фундаментальный закон, а совет, который много кем критиковался и который нельзя применять или использовать как оправдение в большом количестве кейсов.
Да, не нужно оптимизировать прототипный или временный код, но нужно разделять оптимизацию и непессимизацию ((с) Кейси Муратори). Если библейские заповеди говорят мне написать какую-то медленную шляпу, когда я могу с теме же усилями написать что-то быстрее и не потерять в читаемости, либо даже потерять, но получить большой буст к перфе, то мой долг как программиста не следовать заповедям и догмам, а сделать так, чтобы у юзера был нормальный фпс. Мы пишем игры в конце концов.

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

Возможно, вам не нужен ECS

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

Это опыт анекдотический, но недавно прийдя на проект, где каждый день десятки программистов пушат сотни коммитов, я не чувствую себя потеряным. Вот эта однородность и понимание где какой кусок логики/данных может находиться, а также простые и чётки правила парадигмы не дают качеству кода упасть ниже определенного уровня. Ну может есть какие-то легаси системы, но они как правило не очень большие, да и отдают только компоненты и сущности, и с этим уже можно работать.

Если взять данный проект, куда я попал, в текущем состоянии, всё продумать, то можно его написать на ООП, в теории лучше, чем это позволил бы ECS. Можно сделать классный нейминг и методы, которые грамотно всё инкапсулируют и делают работу удобной, но на "хорошее" ООП нужно времени. На ООП хорошо писать то, что хорошо изучено и где более менее понятные требования, и это не совсем про игры.

Видеоигры упёрлись в потолок? Куда дальше развиваться?

А что из этого относится к новым проблемам? Игры всегда было рискованно делать и большая их часть навсегда забыта. То есть игры всегда было неинтересно делать? Может раньше конкуренция была меньше, но провалившиеся проекты и впустую потраченные усилия тоже были. Сейчас ты хотя-бы можешь зайти на рынок и конкурировать вместе со всеми без вложений, тратя только личное время, а лет 20 назад такой возможности, насколько я знаю, не было.

Видеоигры упёрлись в потолок? Куда дальше развиваться?

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

Файтинги: cложности и особенности при разработке или почему инди-файтинги редкость?

Разница в том, что если ты будешь использовать "традиционную" модель нетворкинга + предикцию для отзывчивости на клиенте ты получишь:
Нажал кнопку -> показал анимацию на клиенте -> передал сообщение по сети -> 50-100мс задержка из-за пинга -> информация о ударе/блоке дошла до другого игрока.

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

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

То есть если ты нажал кнопку на 50мс, длительность удара 300мс, удар дошёл на 150мс, то игрок увидит у себя удар будто он уже 100мс в процессе, естественно с интерполяций, чтобы это не выглядело рвано. Тогда игра получается отзывчивой и "честной", можно легко определить кто раньше нажал блок, кто кого первее ударил и т.д.

https://youtu.be/1JHetORRpfQ?si=YhnkMT6EhSnoPnfN

Unity для детей: топ-25 бесплатных видеоуроков

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

Языки программирования, которые могут заменить C++ — Rust, Go, Swift, Carbon

То что в нём есть методы и трейты не делает его в привычном понимании ООП языком.
Классический код на Rust не "ориентирован" на объекты и их взаимодействие, это скорее смесь процедурного и функционального программирования.
Извернутся конечно можно, но извернутся можно на любом языке, а в Rust придётся ещё бороться с компилятором.

Игрострой. С чего начинать

Информации по Visual Scripting'у мало, по каким-то сторонним no-code решениям ещё меньше. Вбив "Unity without code" или "Unity visual scripting" получаем 2 ютуб канала.
Абсолютное большинство гайдов для программиста (само слово) включают в себя работу с C#. Если новичок не умеет в C# он теряет почти весь существующий материал для обучения.
Если брать тот-же Unreal, то там бывает сложнее найти плюсовый гайд, чем гайд на BP, а на Unity без C# делать особо нечего.

Factorio: оптимизации 2.0

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

Лучшие практики для Unity 3D проекта

Если опираться на название, то я не согласен, что это лучшие практики. Советы крайней субъективные и вряд-ли похожи на распространенные "лучшие практики", так ещё и проверены на крайней меленьком проекте, что выглядит как минимум не убедительно. Рассказывать про лучшие практики надо, когда есть проект в релизе, вам нравится как он написан и работает, и тогда уже есть смысл чем-то поделиться.
В остальном, похоже на попытку перенести вебовские практики в игры и юнити, где это не очень уместно. Есть множество более удобных и простых вариантов построить архитектуру для малых, средних и большие проектов.

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