Композиция против наследования, паттерн Команда и разработка игр в целом

Сегодня утром я как раз рекомендовал человеку почитать статью на тему ECS. Я ни в коем случае не говорю, что сказанное в статье — моя идея. Более того, я даже указал в статье, что это известный в гейм-деве паттерн «команда».

Вы правы, подход очень близок к ECS по сути, хоть и не является им. Целью статьи было, скорее, на примере показать, как в реальной жизни применяется композиция вместо наследования и какие из этого можно получить преимущества, потому что в среде JS обычно на эту тему пишут очень странные вещи.

Я рад, что они получились интересными, но ведь без кода нет истории)

Почему? Устали? Мама сказала идти обедать? Ребенок попросил с ним поиграть? Позвонили из лотереи и сказали, что вы победили? Дом рухнул из-за взрыва газа, вы сейчас под обломками и не можете читать дальше?

Мне кажется, что тут нечего выносить. Ну на самом деле можно реализовать что-то вроде такого, пока мы пользуемся исключениями и не типизируем их:

execute () {
    const spellAbility = this.source.getAbility(SpellCastAbility);

    ensureNotNull(spellAbility, 'NoSpellCastAbility')

Можно даже пойти дальше и создать метод, который вместо null возвращает ошибку, тогда не придется вообще писать этого:

execute () {
    const spellAbility = this.source.requireAbility(SpellCastAbility);

Но, во-первых, в идеале нужно отказаться от исключений в пользу кодов возврата:

execute () {
	const spellAbility = this.source.getAbility(SpellCastAbility);

	if (spellAbility == null) {
		return Status.NoSpellCastAbility;
	}

	this.addChildren(new PayManaCommand(this.source, this.spell.manaCost));
	this.addChildren(this.spell.getCommands(this.source, this.target));
	
	return Status.Success;
}

А тогда не будет возможности вынести это в метод, ведь всё-равно нужно if и return.

Во-вторых, что более важно, я не совсем согласен, что это самоповторение. Там разные абилки и разные коды возврата. И, на самом деле, таких if (!cond) return error у нас на практике будет много совершенно разных. Все мы никак не сможем красиво заDRYить.

Судя по вашему описанию и скриншотам на офф странице, Unity3D тоже вполне подходит. Уверен, что и Unreal.

Я глянут на Godot. Хорошо, что он опенсорсный. Но, с другой стороны, в нем явный уклон на свой скриптовый язык (Юнити не зря отказались от ДжаваСкрипта), а еще хуже, что Шарповая версия тоже страдает от динамичной природы. К примеру, тут:

var plusButton = (Button)GetNode("PlusButton");
plusButton.Connect("pressed", this, "ModifyValue", new object[] { 1 });

На шарпах лучше бы выглядело так:

var plusButton = GetNode<Button>("PlusButton");
plusButton.Connect("pressed", ModifyValue);

Или так, если с аргументами:

var plusButton = GetNode<Button>("PlusButton");
plusButton.Connect("pressed", () => ModifyValue(-1));

Мне кажется, им стоит сконцентрироваться на Шарповой версии.

Но почему бы вам не написать о нем статью на Хабру с разбором сильных и слабых сторон?

Такое и композируется лучше, и по иерархиям бегать потом не надо, чтобы понять что происходит со стейтом, да и юнит тесты писать проще.

Начнем с того, что это обычная маркетологичная чушь, которой нас пичкают на всех афтепати. Нет, композируется точно так же, по иерархиям бегать надо точно так же, юнит тесты писать точно так же. По сути от замены класса на функцию для всех этих факторов меняется только форма записи. Почему вдруг должны упроститься эти вещи о которых вы говорите — я не знаю. Может вам не понравилось использование addChildren вместо прямого вызова метода класса? Но тут дело не в классах. На функциях тоже можно написать такой код через каррирование.

Вообще когда я вижу класс с единственным методом, я не очень понимаю, почему это не может быть функцией

Жаль, что вы из тех, кто бездумно повторяет за своим кумиром. Видите ли, в топике было раскрыто, зачем нужно классы и почему их нельзя заменить, к примеру, на функции. А если точнее — вы, как и предыдущий автор, совершенно забыли про вьюшку. Да, для простых вещей, которые пишутся на Редакс подойдет подход «изменили всю модель — перерисовали всю вьюшку». Но проблема в том, что этот подход просто отвратительно анимируется. Вот представьте себе настолку и там правило: «когда самурай стает на клетку рядом с противниками — он атакует каждого из них, но контратаку получает только от первого». Любой геймдевелопер знает, что это совсем обычная абилка для пошаговых игр. Итак, у нас получится такая иерархия:

SAMURAY_ID = 100;
ENEMY_1_ID = 201;
ENEMY_2_ID = 202;
ENEMY_3_ID = 203;

Movement( SAMURAY_ID, 3, 5 )
	Attack( SAMURAY_ID, ENEMY_1_ID )
		DealDamage( ENEMY_1_ID, 3 )
		CounterAttack( ENEMY_1_ID, SAMURAY_ID)
			DealDamage( SAMURAY_ID, 1 )
	Attack( SAMURAY_ID, ENEMY_2_ID )
		DealDamage( ENEMY_2_ID, 3 )
			Death( ENEMY_2_ID )
				GiveMoney( PLAYER_1, 300 )
	Attack( SAMURAY_ID, ENEMY_3_ID )
		DealDamage( ENEMY_3_ID, 3 )

При подходе с классами у меня есть вся эта иерархия на клиентской модели или на сервере, я ее сериализую и отправляю во вьюшку, а вьюшка отображает это так:

await animateMovement(SAMURAY_ID, 3, 5);
await animateAttack(SAMURAY_ID, ENEMY_1_ID);
await showDamage(ENEMY_1_ID, 3)
await animateAttack(SAMURAY_ID, ENEMY_1_ID);

Что же будет при вашем «удобном» подходе с функциями? Все функции синхронно выполнятся, И все, что мы можем послать во вьюшку будет:

У самурая новое положение и на 3 меньше хит-поинтов
У двох врагов на 3 меньше хит-поинтов
Один враг умер

Вы посылаете вот эту скупую информацию на клиент и говорите: «у меня все удобно и круто тестируется». А клиентский программист шлет вас подальше и увольняется. А игра никогда не выпускается, потому что программист, который отвечал за модель перечитал, но не понял ФПшников.

А если вы скажете: «так пусть рисует по тому, что получилось в результате в модели» — я вам отвечу: «попробуйте реализовать следующее»:

Самурай имеет абилку телепортации и может ходить на 1 клетку.
Игрок решает сначала телепорироваться с клетки (3, 3) на клетку (3, 4).
А потом походить с клетки (3, 4) на (3, 5).
Художники, неожиданно, нарисовали разные анимации для телепортации и для ходьбы.

Вот представьте, у нас есть какая-то модель, которая выполняет этот код. Или он выполняется на сервере, приходит на клиент в виде json и разархивируется в классы. Если произошло сложное действие — на клиент (во вьюшку) сразу приходит вся информация о действии с начала до конца. Представьте, что воин двойным ударом ударил монстра и тот этот удар не пережил. У воина айдишник 3, а у монстра — 5. За это игрок получает 100 монет. С сервера/клиентской модели мы получаем оповещение, которое можно отобразить следующим деревом:

Ability( type: 'DoubleAttack', source: 3, target: 5 )
  Attack( source: 3, target: 5 )
    DealDamage( target: 5, amount: 2 )
  Attack( source: 3, target: 5 )
    DealDamage( target: 5, amount: 2 )
      Death( target: 5 )
        GiveMoney( player: 1, 100 )

Для простоты просто выравниваем его и во вьюшке видим его как список:

Ability   ( source: 3, target: 5, type: 'DoubleAttack' )
Attack    ( source: 3, target: 5 )
DealDamage( target: 5, amount: 2 )
Attack    ( source: 3, target: 5 )
DealDamage( target: 5, amount: 2 )
Death     ( target: 5 )
GiveMoney ( player: 1, 100 )

Итак, у нас во вьюшку сихнронно пришло 7 команд с сервера, которые мы должны заанимировать. Пишем где-то методы, которые описывают, как это все анимируется:

drawAbility (ability: AbilityCommand) {
  if (ability.type == 'DoubleAttack') {
    var unit = this.unitsViews.findById(ability.source);
    await unit.launchPentagramAnimation();
  }
}

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

Описываем дальше, атака:

drawAttack (attack: AttackCommand) {
  var source = this.unitsViews.findById(attack.source);
  var target = this.unitsViews.findById(attack.target);
  
  var angle = source.getAngleTo(target);
  await source.rotateAt( angle );
  await source.launchSwordAnimation();
}

Юнит сперва должен повернуться, а потом — ударить мечём. Но отлетающий урон мы не отрисовываем — за это ответственна другая команда (может он вообще броню не пробил и урона не будет?)

drawDamage (damage: DealDamageCommand) {
  var target = this.unitsViews.findById(attack.target);
  
  this.canvas.createNewFloatingNumber( `-${attack.amount}`, { color: 'red' });
}

Для демеджа мы запустили вылетающую красную цифру, но обратите внимание — никакого await. Ведь нам не нужно ждать, пока цифра окончательно пропадет. Пусть себе летит дальше, а мы уже можем запускать следующую анимацию — снова удар.

Таким образом мы примитивно описываем все реакции на любую команду с сервера. Теперь если на сервере гейм-дизайнер добавит 100 новых абилок на базе этих реакций — они автоматически подхватятся на клиенте.

Приблизительно так устроены всякие Heartstone и подобные игры.

PS: Наверное в VampireSpell опечатка, castTo должно быть getCommands.

Да, вы правы, спасибо.

Я понимаю если бы это был какой-то CommandExecutor / Scheduler, в который мы просто кидаем в конец новые команды и они в свое время выполняются. Зачем нужно addChildren?

Да, и тут вы правы. Конечно, у нас есть CommandExecutor. Но тут я ввел addChildren, который нужен, чтобы не делать дополнительный DI. Чтобы не было вопросов — а откуда у нас экзекьютор появился, а как правильно его передать в команду? И так далее.

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

Вот представьте тот пример, который я выше приводил:

Movement( SAMURAY_ID, 3, 5 )
	Attack( SAMURAY_ID, ENEMY_1_ID )
		DealDamage( ENEMY_1_ID, 3 )
		CounterAttack( ENEMY_1_ID, SAMURAY_ID)
			DealDamage( SAMURAY_ID, 1 )
	Attack( SAMURAY_ID, ENEMY_2_ID )
		DealDamage( ENEMY_2_ID, 3 )
			Death( ENEMY_2_ID )
				GiveMoney( PLAYER_1, 300 )
	Attack( SAMURAY_ID, ENEMY_3_ID )
		DealDamage( ENEMY_3_ID, 3 )

Если команда добавляет своих детей в очередь, а не выполняет синхронно, то сперва выполнятся 3 атаки, а только потом их дети.

Или они должны выполняться не по принципу FIFO очереди, а там какой-нибудь depth-first search обходом.

Да, именно так. depth-first search — то, что нужно. Когда мы делаем ундо, то, конечно, нужно сделать ундо и всем детям.

У меня, правда, ундо не делается (все-таки в играх оно редко необходимо), но ничего не мешает его прикрутить. Команды выполняются приблизительно таким методом (псевдокод):

class CommandExecutor {
  RunTree (Command command) {
    TriggerBeforeEvent(command);
    command.Execute();
    TriggerInsideEvent(command);
    foreach (var child in command.children) RunTree (child);
    TriggerAfterEvent(command);
  }
}

Нормально работает. Подобное крутилось на рядовом сервере и держало тысячи онлайна. Уж одного игрока оно выдержит. Тем более этот движок можно вынести в отдельный поток.