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

Получается такая прослойка между SetActive и вьюхой.

Согласен. Как способ донести мысль хорошо, вот бы развить ещё. Лет двенадцать назад пилил с товарищем игру на Unity, нас было всего двое, поэтому экономили на всём. Делать надо было с первого раза, как дизайн УАЗа «буханки». Мы прицелились в мобилки и ПК, включая игровые контроллеры и VR. Те навыки и нестандартные подходы пригодились мне и в «кровавом» энтерпрайзе со скоростным импортозамещением.)

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

Для больших анимаций лучше писать самостоятельные обертки

А под статусной моделью вы понимаете типа css с его hover, selected и т.д. ?

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

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

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

Определиться с жанром, игровыми контроллерами, механикой, а дальше как выше описано...

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

Механик много, контроллеров много, это все еще должно дублироваться для разных модулей: вьюхи, ассеты, дто. Тут только для одного компонента View слоя нужно несколько сущностей-комманд. А таких сущностей тысячи

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

Ну, на работе я каждый день такое делаю)

Ого, это круто. А сколько человек в штате? Мне кажется это нереальным для игр, может я упусаю что-то.

Обычно такую работу делают в паре дизайнер и системный аналитик, но последние несколько лет занимаюсь такими задачами самостоятельно по запросу владельцев продукта.