Это да, но аббревиатура KISS расшифровывается: Keep It Simple Stupid. Последнее слово как-раз имеется ввиду, что ты можешь сделать решение более топорное, возможно даже немного накостылять и захардкодить
В идеале так и нужно писать простой код, соблюдая SOLID. В статье речь идет о том, что можно уйти в крайности:
Простая система, может превратиться в God Object
Супер гибкая система, может превратиться в спагетти.
Поэтому в статье объясняется, что нужно держать баланс. Нельзя просто следовать SOLID. В тоже время нужно контролировать, чтобы Stupid классы не превращались в God Object'ы.
Такое сработает, если разработчик уже решал похожую задачу ранее. Если для специалиста задача новая, то легко угодить в ловушку двух зайцев. Думать одновременно о том, чтобы код и работал и был причесан, может очень сильно тормозить процесс разработки (по себе знаю). В результате будет потрачено больше времени, сил и энергии. Поэтому рабочий код и чистый код — это разного рода задачи, и лучше рефакторить после проверки работоспособности кода.
К сожалению не будет удобнее, уже проходил это с интерфейсами. В результате на большом проекте у тебя будет 500+ интерфейсов, которые нужно будет прописывать на каждый чих, и код-база будет расти слишком быстро. Поэтому в атомарном подходе в основном лучше использовать динамическую типизацию вместо статической.
character.Is("TakeDamagable");
Это и есть интерфейс, просто динамически типизированный.
Но сделать вот так на атомарном подходе тоже можно (писал про пример с аптечкой)
А зачем сериализовывать все? Если мы говорим про мультиплеер, то достаточно сериализовать состояние объекта (то есть данные) и синхронизировать их с игровым объектом на сервере.
Тут да, в атомарном подходе объект по умолчанию представляет собой набор данных и логики, а в ECS сущность — только данные. Но на самом деле это не мешает создать объект на атомарном подходе только из данных без логики, и позволить другим классам и системам манипулировать этими данными.
Также если нужно, можно добавлять и удалять данные объекта в Run-time по аналогии с добавлением и удалением компонентов в сущности. (см главу про Динамические объекты)
Не совсем понял примеры с кодом проброса геттеров из конкретных компонентов, можешь, плиз, привести пример кода?
Ключевое отличие атомарного подхода от ECS заключается в том, что атомарный подход остается в парадигме ООП, а ECS нет. Атомарный подход подчиняется принципам ООП: инкапсуляция, наследование, полиморфизм, а ECS — нет.
Единственное, что эти концепции объединяет — это то, что оба подхода применяют принцип разделения данных и логики, для того, чтобы можно было переиспользовать структуры данных и механики, а в ECS переиспользовать компоненты и системы.
Поэтому разработчику, который привык писать на ООП, не придется перестраивать мозг на атомарном подходе, в отличие ECS.
Не, у ECS есть свои тараканы и там практически нет полиморфизма.
На обычных интерфейсах делать можно, я уже это проходил, но проблема в том, что придется делать их очень много, на каждый чих + для каждого игрового объекта делать дополнительный фасад . В результате такой дизайн выглядит слишком избыточным... Поэтому айдишники в виде строк — это самый компактный и гибкий вариант
Это да, но аббревиатура KISS расшифровывается: Keep It Simple Stupid. Последнее слово как-раз имеется ввиду, что ты можешь сделать решение более топорное, возможно даже немного накостылять и захардкодить
В идеале так и нужно писать простой код, соблюдая SOLID. В статье речь идет о том, что можно уйти в крайности:
Простая система, может превратиться в God Object
Супер гибкая система, может превратиться в спагетти.
Поэтому в статье объясняется, что нужно держать баланс. Нельзя просто следовать SOLID. В тоже время нужно контролировать, чтобы Stupid классы не превращались в God Object'ы.
Такое сработает, если разработчик уже решал похожую задачу ранее. Если для специалиста задача новая, то легко угодить в ловушку двух зайцев. Думать одновременно о том, чтобы код и работал и был причесан, может очень сильно тормозить процесс разработки (по себе знаю). В результате будет потрачено больше времени, сил и энергии. Поэтому рабочий код и чистый код — это разного рода задачи, и лучше рефакторить после проверки работоспособности кода.
😐
К сожалению не будет удобнее, уже проходил это с интерфейсами. В результате на большом проекте у тебя будет 500+ интерфейсов, которые нужно будет прописывать на каждый чих, и код-база будет расти слишком быстро. Поэтому в атомарном подходе в основном лучше использовать динамическую типизацию вместо статической.
Это и есть интерфейс, просто динамически типизированный.
Но сделать вот так на атомарном подходе тоже можно (писал про пример с аптечкой)
Вы просто не поняли :)
А зачем сериализовывать все? Если мы говорим про мультиплеер, то достаточно сериализовать состояние объекта (то есть данные) и синхронизировать их с игровым объектом на сервере.
Тут да, в атомарном подходе объект по умолчанию представляет собой набор данных и логики, а в ECS сущность — только данные. Но на самом деле это не мешает создать объект на атомарном подходе только из данных без логики, и позволить другим классам и системам манипулировать этими данными.
Также если нужно, можно добавлять и удалять данные объекта в Run-time по аналогии с добавлением и удалением компонентов в сущности. (см главу про Динамические объекты)
Не совсем понял примеры с кодом проброса геттеров из конкретных компонентов, можешь, плиз, привести пример кода?
Ключевое отличие атомарного подхода от ECS заключается в том, что атомарный подход остается в парадигме ООП, а ECS нет. Атомарный подход подчиняется принципам ООП: инкапсуляция, наследование, полиморфизм, а ECS — нет.
Единственное, что эти концепции объединяет — это то, что оба подхода применяют принцип разделения данных и логики, для того, чтобы можно было переиспользовать структуры данных и механики, а в ECS переиспользовать компоненты и системы.
Поэтому разработчику, который привык писать на ООП, не придется перестраивать мозг на атомарном подходе, в отличие ECS.
Не оч понял, почему дорого будет сделать сериализацию состояния мира или протестировать игровые объекты?
Не оч понял аргумент, почему сущность теряет гибкость и тестируемость, если объект состоит из данных и логики?
В атомарном подходе тип — это просто маркер или тэг объекта.
Не, у ECS есть свои тараканы и там практически нет полиморфизма.
На обычных интерфейсах делать можно, я уже это проходил, но проблема в том, что придется делать их очень много, на каждый чих + для каждого игрового объекта делать дополнительный фасад . В результате такой дизайн выглядит слишком избыточным... Поэтому айдишники в виде строк — это самый компактный и гибкий вариант
Главное — не сдохнуть на этом проекте 😅
Веду разработку на канале: https://www.youtube.com@CodeCraftUnityEdition
Да, я оч хочу добавить механику командиров и механику различных активностей на карте)
Если говорить честно: и да, и нет. Для более сложных задач сначала писались тесты, а потом код, для более простых задач — сначала код, потом тесты)
Честно, не понял про способность прогнознозировать
Зов души, мечта детства)
Огонь, спасибо большое! 🔥
Очень полезная информация! ❤️