Вас не приводит в ярость несоответствие? Когда в гайдах всё просто, а по факту упускается огромный пласт вопросов, потому как пример берется - наипростейший. Системы, сервисы, логические слои кроме тех, что в аббревиатуре... Кто кем управляет и за что отвечает. В том же MVP при разных интерпритациях векторы инфы идут в разные стороны. Пытаешься "навести логическую чистоту", а на подсознании всегда маячит "просто сделай eventbus и х с ним, с чистотой и защитой сущностей". Вас не раздражает вариативность ролей?
Я за опыт. Пробуешь, через какое то время видишь что хренова получилось - думаешь как по другому будет лучше, повторяешь.
MANAB
Это долго. Но по факту так и происходит. Вернее, всегда в проекте, который был задуман "ну теперь-то будет как в аптеке" присутствует "зато работает и расширяемо". К сожалению
Dmitry_togliatti
> как пример берется - наипростейший
так в этом и смысл гайдов и примеров. Простейший и по теме, без лишнего.
как ты всё это вместе потом организуешь - исключительно на твоих плечах
Только опыт поможет понять как лучше будет для твоего проекта. Я часто пишу какую-то фигню, потому что не понимаю как сделать лучше именно сейчас. Спустя время возвращаюсь и переделываю, так как картина сложилась уже более цельная. Поэтому лучше старого дедовского метода проб и ошибок еще ничего не изобрели. Все эти 100500 вариантов архитектур в статьях/гайдах больше кашу в голове наводят.
Jaxel
У меня также. Но выбешивает порой. Когда есть где-то вот рядом готовое красивое, а ты размазывал спагетти.
Dmitry_togliatti
Ну спагетти прям я уж не размазываю. Иногда просто проще написать какой-то отдельный скрипт на костылях, который решит определенную проблему очень быстро. Спустя время, если появляется необходимость развивать этот код, то уже думаю над тем как переписать и организовать все нормально.
МВ паттерны родом из энтерпрайза и к геймдеву особого отношения не имеют, поэтому не парься, насильно их пытаться применять - плохая идея и путь вникуда
Dmitry_togliatti
> Системы, сервисы, логические слои кроме тех, что в аббревиатуре... Кто кем управляет и за что отвечает.
Сервисная модель хорошо ложится в игры, в чем конкретно сложность?
Dmitry_togliatti
> В том же MVP при разных интерпритациях векторы инфы идут в разные стороны.
Отличный паттерн, если его использовать там где надо - в UI
Dmitry_togliatti
> Пытаешься "навести логическую чистоту", а на подсознании всегда маячит "просто сделай eventbus и х с ним, с чистотой и защитой сущностей"
Event Bus тоже себе паттерн, и в целом можно аккуратно применять местами, однако все строить через него не самая лучшая идея.
Increaser
> Сервисная модель хорошо ложится в игры, в чем конкретно сложность?
По сути ни в чем кроме вариативности. Кто чем занимается. Если нет единообразия - начинаешь забывать, кого какими полномочиями наделил. То ли сервис исключительно защищает дату-модель, то ли делает ещё чётIncreaser
> Отличный паттерн, если его использовать там где надо - в UI
Ну, он позиционируется несколько шире. 1 из трактовок - animator, rb, transform,meshrenderer и прочее - тоже view... И тогда презентеры начинают выполнять роль думателей. Перетягивать одеяло у систем, становиться системами. Я посмотрел на это и родумал, ну, сомнительно, но ОК. Пусть игровая Timebehavior(спецкласс monobeh для кастомного управления групп timescale) Сущность управляет презентерами через свой кастом тик. Пусть она больше ничего не умеет, тупой итератор. Пусть это будет реактивная коллекция и пусть они добавляются через SO конфиг... Через его сценарий. Ичерез zj для инъекций в презентеры всякого. Вроде норм. Генеральная сущность макс абсрактна и тупо запускает презентеры по кругу. Только вот презентеры уже не презентеры...Increaser
> Event Bus тоже себе паттерн, и в целом можно аккуратно применять местами, однако все строить через него не самая лучшая идея.
Event Bus - ключ от всех дверей слабых связей. Очень заманчивая штука, чтобы исп там где не надо. Как по мне - в идеале надо юзать в тупиковых системах (ничего не меняющих в данных) типа Системы сообщений об уроне на экране.
Dmitry_togliatti
> Если нет единообразия - начинаешь забывать, кого какими полномочиями наделил.
Это странно. Возможно проблема с наименованиями. При нормальном именовании невозможно "забыть".
Например, IQuestStateProvider. По-моему, абсолютно очевидно, чем он занимается, и при надобности взять стейт квеста это первое, что придет в голову.
Dmitry_togliatti
> Ну, он позиционируется несколько шире. 1 из трактовок - animator, rb, transform,meshrenderer и прочее - тоже view...
Это и есть неверное применение MV* паттернов. Используй MV-паттерны для UI, и все у тебя будет хорошо. Не пытайся тянуть их в геймплей, тем более это противоречит компонентной модели Unity.
Dmitry_togliatti
> Я посмотрел на это и родумал, ну, сомнительно, но ОК
Большинство ютуберов не выпустило в жизни ни одну игру. Я видел реальные проекты, где люди тянули MV* паттерны в геймплей, и ни разу не видел, чтобы это что-то упростило.
Dmitry_togliatti
> Генеральная сущность макс абсрактна и тупо запускает презентеры по кругу.
И максимально бесполезная. Если бы убер-абстракция существовала, ее бы давно уже изобрели. Отталкивайся от потребностей кода, а не от потребности делать абстракции.
Абстракции вообще тонкая вещь, и я бы советовал поменьше заниматься абстракциями. Жди, когда контракт сам выразится в коде, и потом утаскивай его в абстракцию, а не наоборот.
Вообще наследование надо применять аккуратно в Unity. Лучше использовать композицию.
Dmitry_togliatti
> Event Bus - ключ от всех дверей слабых связей. Очень заманчивая штука, чтобы исп там где не надо.
Да, так и есть. Но можно и вообще без него.
Dmitry_togliatti
> Как по мне - в идеале надо юзать в тупиковых системах (ничего не меняющих в данных)
Хорошее ограничение.
У меня есть еще одно. Я использую EventBus только в случае, если ивент настолько общий, что его сложно выделить в какой-то сервис или просто излишне.
Dmitry_togliatti
Натягивание MVx паттернов на кор логику это не очень практика, я тут соглашусь с Increaser. MVx паттерны пришли из десктопа и мобильных приложений, где все приложение по большей части UI. Там эти подходы работают отлично. Говорю как человек, который два года работал мобильщиком + писал плагин для десктопного приложения, все это было очень удобно. В геймдеве эти паттерны тоже могут неплохо работать в мета-геймплее и возможно частично в коре для UI, где поведение игры очень схоже с мобильными/десктопными приложениям, но все равно имеет свои ньюансы.
Вообще я на своем опыте пришел к выводу, что в коре лучше всегда отталкиваться от чистых моделей с данными, без всяких наследований и паттернов. Модель - это просто класс с данными. Изменяются эти данные уже в игровых системы. Почему это удобно, потому что можно реюзать данные, получить к ним доступ откуда угодно (из UI, из других систем), следовательно легче поддерживать, очень просто дебажить (можно вывести все в какую-то панельку), не появляются всякие оопшные костыли при модификации. Можно еще вместо обычных данных в модели юзать их реактивные обертки (ReactiveProperty из UniRx, или написать свои), тогда уйдут эти неудобные C# ивенты и лишний бойлерплейт. Это все потом привело конечно к ECS, но я здесь больше про то, что можно писать и без ECS код ориентированный на данные, а не на паттерны и абстракции.
Increaser
> И максимально бесполезная. Если бы убер-абстракция существовала, ее бы давно уже изобрели. Отталкивайся от потребностей кода, а не от потребности делать абстракции.
Я всегда тяготел к изобретательству абстрактных композиций.
Мне пока нравится. Код внутри модулей короткий, всё через интерфейсы. Пересобирать быстро и легко через внешний конфиг. Хоть пулю, хоть character, хоть level. Общение происходит через главную сущность и кэширование интерфейсов внутри исполнителя. Единственная проблема - нейминг. Изначально это были презентеры. Но это точно не они, это скорее handlers.Increaser
> Вообще наследование надо применять аккуратно в Unity
Я и не применяю. Почти. Это да, плохо. Наследование в моем случае - если хочется применять custom group time scale. Пожалуй, сделать промежуточный абстрактный класс TimeBehaviour и подключиться к ITimeService - норм. Можно конечно, сделать композиционно, типа ITimeTicker или вроде того... Но проще abstract inheritance, так не забыть про customTick методы.
Jaxel
Я про это и писал, что раздражает отсутствие некоего идеального расширяемого прототипа. Эталона. Там где "Модель - это просто класс с данными. " - именно. Единственный источник истины с реактивщиной (UniRx, R3). Я тоже баловался с AdroidStudio когда-то и был в восторге от data binding библиотеки. Раздражает то, что нет некоего классического прототипа, чтобы не хранить данные в компонентах и всё работало идеально, что эту концепцию надо изобретать по месту.