1. Пока не проверял, вроде должен занулять (у меня пока с этим проблем не было). На крайний случай можно использовать IsInstanceValid() (примерно как-то так называется метод в годо)
2. Делать так, что у тебя компонент одной сущности ссылается на компонент другой — странно
Максимум у меня компонент одной сущности может ссылаться на другую сущность в целом
3. Про урон, как ты сделаешь так и будет. Ты можешь прежде чем добавить новый компонент DamageReceive, проверить есть ли он уже и если есть просто инкрементировать его значение
4. Расскладывать по смыслу в ecs я точно не буду, я не представляю как и зачем.
К примеру MoveSystem использует компоненты MoveComponent и TransformComponent, но эти же компоненты используют еще куча других систем, как ты будешь группировать?
Ну и во-вторых, это репозиторий не проекта, а фреймворка. Сюда я выношу код, который можно будет испльзовать в других проектах. Я например могу потом заюзать компонент MoveComponent, но систему не брать, а написать другую.
В проекте я уже группирую скрипты внутри компонентов/систем
Комментарий отредактирован:
12 января 2025, 10:28
(3 раза)
1. Не совсем понял про удаление. Например у компонента есть ссылка но ноду и эта нода удалилась, так?
Если да, то все nullable типы нужно проверять на null, поэтому я их помечаю так:
[Export] public Node? Target = null;
И там где идет обращение к таким полям, нужна проверка
2. Два одинаковых компонента нельзя. Точнее ты физически можешь, но добавиться только последний.
Код в энтити:
public T AddComponent<T>(T component, bool attach = true) where T : EcsComponent
{
if (HasComponent<T>())
RemoveComponent<T>();
Я даже не представляю как организовывать потом системы если можно будет добавлять несколько одинаковых компонентов. Вижу только минусы
Планируется кооперативный режим, да. Попробую на серверах стима сделать. Но это будет не скоро, первым делом отполирую кор механики
Про архитектуру в следующей статье напишу
Добаление компонентов не так часто происходит, а вот итерация каждый божий кадр
К тому же я кажется эту возможность еще нигде не использовал
2. Делать так, что у тебя компонент одной сущности ссылается на компонент другой — странно
Максимум у меня компонент одной сущности может ссылаться на другую сущность в целом
3. Про урон, как ты сделаешь так и будет. Ты можешь прежде чем добавить новый компонент DamageReceive, проверить есть ли он уже и если есть просто инкрементировать его значение
4. Расскладывать по смыслу в ecs я точно не буду, я не представляю как и зачем.
К примеру MoveSystem использует компоненты MoveComponent и TransformComponent, но эти же компоненты используют еще куча других систем, как ты будешь группировать?
Ну и во-вторых, это репозиторий не проекта, а фреймворка. Сюда я выношу код, который можно будет испльзовать в других проектах. Я например могу потом заюзать компонент MoveComponent, но систему не брать, а написать другую.
В проекте я уже группирую скрипты внутри компонентов/систем
Если да, то все nullable типы нужно проверять на null, поэтому я их помечаю так:
И там где идет обращение к таким полям, нужна проверка
2. Два одинаковых компонента нельзя. Точнее ты физически можешь, но добавиться только последний.
Код в энтити:
Я даже не представляю как организовывать потом системы если можно будет добавлять несколько одинаковых компонентов. Вижу только минусы
Про архитектуру в следующей статье напишу