Pray_AD
JARG

Представление игровых объектов

Добавлен , опубликован
Предлагаю обсудить представление игровых объектов
  1. Каждая новая логика реализуется новым классом с новой реализацией, для контроля общей логики используются наследование от абстрактных классов, например IFuel IChest. Отличная организация, дублирование кода. Нет возможности изменять логику -> все объекты одного класса по-сути идентичны (в предыдущей реализации на с# использовалось это, экземпляры создавались из текстового json файла через рефлексию)
  1. Есть некоторые очень глобальные классы, например Block Monster Item. У этих классов, для реализации разного поведения есть некоторый список скриптов. Например
list<functor> update 
void update() {
foreach up in update do up();
}
т.е. someblock.update.add(furnance_functor); делает из чего угодно печку. Средняя организация, возможность комибиинровать логику без компиляции, но некоторые ограничения на логику
  1. Есть некоторый набор текстовых флагов, например list<string> flags. Есть некоторый глобальный класс, который делает что-то вроде 
void update() {
if some.sontainsFlag("fuel") do something;
}
Добавление логики делается добавлением флага. Плохая организация, но зато можно реализовать логику любой сложности. Например аи работает примерно так. Флаг чего монстр боится, флаг, от чего злится и т.д. Позволяет делать совершенно новую логику в блокноте без компиляции
  1. ?
сейчас реализация -- это что-то среднее между 1, 2 и 3. Есть флаги для кода нативной логики и есть скрипты на js
Хотелось бы услышать ваше мнение по этому поводу.
14 окт 2014
  • Размещен: 14.10.2014 16:16:57
  • Создан: 14.10.2014 16:16:57
  • Обновлен: 14.10.2014 16:16:57
1 123
`
ОЖИДАНИЕ РЕКЛАМЫ...
2
29
10 лет назад
Отредактирован Doc
2
Всё кроме 1 бред, есть интерфейс Entity, у которого есть методы update итд итп, от него все наследуется, не нужно мудрить. Если нужна поддержка скриптов она реализуется конкретно в объекте. Типичная новичковская ошибка пытаться все сделать супердуперуниверсальным.
0
14
10 лет назад
Отредактирован Pray_AD
0
Doc:
Всё кроме 1 бред, есть интерфейс Entity, у которого есть методы update итд итп, от него все наследуется, не нужно мудрить. Если нужна поддержка скриптов она реализуется конкретно в объекте. Типичная новичковская ошибка пытаться все сделать супердуперуниверсальным.
Я тоже так считаю, надо посильнее выделить в тексте оценку каждого метода, просто решил привести все, что придумалось, 2 3 определенно слабее, но тем не менее они используются, например система флагов взята из DwarfFortress/Canaclysm.
Не знаю почему там выбран именно этот способ, вообще качество кода в этих проектов не лучшее да и решения, но сами проекты прекрасны
2
29
10 лет назад
2
В зависимости от того, что ты хочешь. Я использую такую логику:
 // Какой то базовый класс, которые отвечает онли за характеристики объекта, можно экстендить и т.д.
class GameObject {
    // Тут список поведений
    private IList<Type> objectBehaviours;
    private IList<IGameObjectBahaviour> objectBehaviourInstances;
    // Инстанцируем поведения
    private void InitializeBehaviour() {
         objectBehaviourInstances = objectBehaviours
              .Where(x => x.Implements(IGameObjectBehaviour))
              .Select(x => Activator.Create(x, new[] {this}))
              .ToList();
    }

    // Вызываем поведения
    public void Damage(float damage) {
           // меняем характеристики
           // ....
           // и вызываем обработчики
           objectBehavioursInstances.Foreach(x => x.Damage(damage));
    }
}

// Интерфейс определяющий какое либо поведение игрового объекта
interface IGameObjectBehaviour {
  GameObject Current { get; }

  void OnDamage(...);
  void OnDeath(...);
  void OnStart(...);
  void OnEnd(...);
  void OnTick(...); 
  // и т.д.
}
Ну вот как то так.
ПС. Кажется я осознал для чего можно использовать Injection
Чтобы оставить комментарий, пожалуйста, войдите на сайт.