Спасибо, статья хорошая
Хо, хотя конечно аналогичные уже были, тема все же довольно старая.

Я думаю можно поправить термины немного.
Вы описали разницу между движком и библиотекой, но обычно так описывается разница между фреймворком и библиотекой.
Вы вызываете код библиотеки.
Фреймворк вызывает ваш код.
С этой точки зрения "игровой движок" - очень широкий термин. Это может быть и библиотека / набор библиотек, и фреймворк и целый тул инструментов, включающий редактор и дополнительные инструменты типа редакторов материалов, текстур и анимаций.
То есть в минимальном варианте это библиотека для графики, к примеру.
В максимальном варианте это Unity или Unreal, в которых вы работаете в редакторе и встраиваете ваши скрипты в готовую структуру.

Ну человек прав в том, что все rust комьюнити этого не понимает.
То есть они пытаются писать движки вместо игр

Ожидания:
- ИИ позволит сократить потребность в программистов на 30%, уволив до половины Junior и Middle разработчиков.
Реальность:
- Теперь мы можем впихать микроконтроллер и софт даже в бутылки кефира! Или, встречайте - первая умная табуретка!

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

Но дисбаланс то есть все равно.
Я, впрочем, не знаю, где обоснованная пропорция.
Может даже при полном равенстве девушкам это будет меньше интересно, кто знает.

Ну хз
Есть интерфейс в абстрактном смысле - это то, как с объектом можно взаимодействовать. И это буквально список публичных функций и полей объекта.
В этом смысле интерфейсы есть в большинстве ЯП

И есть интерфейсы в техническом смысле - интерфейсы в C# и Java, протоколы в obj-c, трейты в Rust, ленивая типизация в Go и т.д.

Интерфейсы можно наследовать и использовать в полиморфизме (когда один и тот же метод работает по разному в разных объектах)

В этом смысле к абстрактным интерфейсам и наследованию интерфейсов претензий нет.

Проблемы начинаются, когда наследуется не только интерфейс.

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

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

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

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

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

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

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

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

Я бы сформулировал это как несколько разных тезисов:

• Rust отличный язык, но у него есть ограничения и недостатки. Ставя во главу угла надежность и Zero Cost Abstractions, он увеличивает как порог входа так и сложность разработки

• Требования к инструментам могут быть противоречивы. Разработка игр требует высокой скорости итераций, крайне позднего связывания и data-driven дизайна. Некоторые особенность rust противоречат этим требованиям, поэтому движки и пытаются их исправить. В частности те же ECS отказывается от нативного обращения к данным по ссылкам и контроля ЖЦ, создавая свою систему поверх (индексы через сущности и свой контроль времени жизни сущностей)

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

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

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

Я прекрасно понимаю, как пишутся игры.
И согласен с посылом статьи.
"В прод это и не должно пойти"
Я про это. Кого мы обманываем, прототипный код регулярно идет в релиз.

Поэтому мы нагородим целую систему с параллельным индексированием и ЖЦ поверх (ECS) и будем игнорировать безопасность раст на высоком, архитектурном уровне.

Не в оправдание проблем, но кого мы обманываем.

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

Темный лес рушится при многих допущениях на самом деле.

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

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

Тем же может служить и союзные цивилизация (которые потенциально можно найти в п1 и задружиться). В таком случае может быть создана целая сеть, неуязвимая для одного удара, обменивающаяся информацией об агрессорах и т.д.

Мсье знает толк...
Мое уважение

Отличная статья, спасибо
Тоже постоянно вижу эту боль, пусть и держу ее внутри.
Как говорится, хочешь сделать плохо другу - научи его видеть плохой кернинг

Пожалуй это можно занести в анналы:
Сложнейшие проблемы программирования:
- Инвалидация кеша
- Именование
- Нентрирование

Справедливости ради, во многих приведенных вами примерах было корректное центрирование либо по телу, либо по обводу шрифта.
К сожалению иногда и это смотрится криво.