Архитектурные решения для мобильной игры. Часть 1: Model

Вообще комманды и сложные конструкции во View-ах будут описываться во второй и третьей части статьи, которые я планирую завтра и послезавтра. Так что тут отвечу кратко. Случай на столько архитипичный, что я пожалуй включу туда в качестве отличного жизненного примера.

Да, подписывание в модели, конечно, только для примера, на самом деле такие строчки находятся, конечно, в View.ConnectModel(), но про вьювы я тут ещё не говорил, поэтому фейковый пример кинул сюда.

У нас в практике тоже был такой случай, когда открываются мистери боксы, и конечно деньги должны поменяться только когда анимация доиграется до конца. Один из наших разработчиков решил упростить себе жизнь, и по команде значение не менять, но серверу говорить, что изменил, а по концу анимации запускать callback, который поправит значения в модели на нужные. Молодец, короче. Две недели он эти мистерибоксы делал, а потом у нас ещё трижды всплывали очень трудно уловимые ошибки, ставшие результатом его деятельности и на их ловлю пришлось истратить ещё три недели по итогу, при том, что времени на «переписать по нормальному» уже, конечно, никто выделить не мог. Из чего ярко следует, как мне кажется, вывод что лучше нужно было с самого начала сделать всё с нормальной реактивностью.

Так вот, моё решение примерно такое. Конечно деньги лежат не в отдельном поле, а являются одним из объектов в словаре inventory, но это сейчас не так важно. У модели есть одна часть, которая проверяется сервером, и на основе которой работает бизнес-логика, и другая, которая существует только на клиенте. Деньги в основной модели начисляются сразу по факту принятия решения, а во второй части в списке «отложенное показывание» создаётся элемент на ту же сумму, который фактом своего появления запускает анимацию, а по окончании анимации запускается команда, которая этот элемент удаляет.
И в реальном поле показывается не просто значение поля, а значение поля за минусом всех клиентских откладываний. В коде это будет примерно так:

public class OpenMisterBox : Command {
    public BoxItemModel item;
    public int slot;
    // Эта часть команды выполняется и на сервере тоже, и проверяется.
    public override void Applay(GameState state) {
        state.inventory[item.revardKey] += item.revardCount;
    }
    // Эта часть команды выполняется только на клиенте.
    public override void Applay(GameState state) {
        var cause = state.NewPersistent<WaitForCommand>();
        cause.key = item.key;
        cause.value = item.value;
        state.ui.delayedInventoryVisualization.Add(cause);
        state.ui.mysteryBoxScreen.animations.Add(new Animation() {cause = item, slot = slot}));
    }
}
public class MysteryBoxView : View {
    /* ... */
    public override void ConnectModel(MysteryBoxScreenModel model, List<Control> c) {
        model.Get(c, MysteryBoxScreenModel.ANIMATIONS)
            .Control(c, 
                onAdd = item => animationFactory(item, OnComleteOrAbort => {
                    AsincQueue(new RemoveAnimation() {cause = item.cause, animation = item}) }),
                onRemove = null
            )
    }
}

public class InventoryView : View<InventoryItem> {
    public Text text;
    public override void ConnectModel(InventoryItem model, List<Control> c) {
        model.GameState.ui.Get(c, UIModel.DELAYED_INVENTORY_VISUALIZATION).
            .Where(c, item => item.key == model.key)
            .Expression(c, onChange = (IList<InventoryItem> list) => {
                int sum = 0;
                for (int i = 0; i < list.Count; i++)
                    sum += list[i].value;
                return sum;
            }, onAdd = null, onRemove = null ) // Чисто ради показать сигнатуру метода
            .Join (c, model.GameState.Get(GameState.INVENTORY).ItemByKey(model.key))
            .Expression(c, (delay, count) => count - delay)
            .SetText(c, text);
        // Здесь я написал полный код, но в реальности это операция типовая, поэтому для неё, конечно же, существует функция обёртка, которая дёргается в проекте во всех случаях, выглядит её вызов вот так:
        model.inventory.CreateVisibleInventoryItemCount(c, model.key).SetText(c, text);
    }
}
public class RemoveDelayedInventoryVisualization : Command {
    public DelayCauseModel cause;
    public override void Applay(GameState state) {
        state.ui.delayedInventoryVisualization.Remove(cause);
        state.DestroyPersistent(cause);
    }
}
public class RemoveAnimation : RemoveDelayedInventoryVisualization {
    public Animation animation
    public override void Applay(GameState state) {
        base.Applay(state);
        state.ui.mysteryBoxScreen.animations.Remove(animation);
    }
}

Что мы имеем в итоге? Есть два View, в одном из них играется некая анимация, окончания которой ждёт отображение денег в совсем другом вьюве, понятия не имеющем кто и зачем хочет чтобы показывалось другое значение. Всё реактивненько. В любой момент можно загрузить в игру полное состояние GameState и оно начнёт играться ровно с того места, на котором мы остановились, в том числе и анимация запустится. Правда запустится с начала, потому что мы этап анимации не сторим, но если очень нужно, сторить можем даже его.

Эпик фейл!!! Только что обнаружил, что из-за ошибки в форматировании, (неэкранированной треугольной скобки) половина статьи не показывалась! Афигеть вообще…

Не очень понял Ваш подход. Вы описываете случай реал тайма (игровой цикл) или рассматриваете социалки (запрос-ответ)?

«Но анимации совершенно разные и поле должно обновиться в совершенно разные моменты, а не сразу вместе с моделью.»

Если рассматривать социалки (запрос — ответ) — тут обычно делается отдельный запрос на сбор возобновляемого ресурса / побежденного босса / взятии груза. Если заказан самолет с деньгами, деньги лучше забирать отдельным запросом, записывая в модель (на клиенте и сервере) факт того, что груз заказан (который фиксируется в первом запросе). За убийство босса тоже лучше начислять награду отдельным запросом на взятие награды или в запросе на ластхит.

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

«Босс должен после смерти красиво упасть и только потом зачислятся деньги.»

Награда в моделях начисляется сразу, клиент же может предсказывать сервер (используя тот же сид рандома к примеру), либо ждать награду от сервера (если логику начисления награды нужно скрыть от пользователя) — это не важно, главное, чтобы исполнение команды было упорядоченным и давало одинаковые результаты на клиенте и сервере.
Первый вариант FlowerGivesMoneyView по сути корутина Unity — произошла команда, она изменила модель, далее ее поймала вьюшка и она описывает логику отрисовки (вложенные корутины).
Клиент и сервер синхронны, все чисто. Как ведет себя второй вариант — у нас появляется две команды и вторая команда ждет первую? (которая нужна лишь для анимации
и не изменяет модель, чтобы потом запустить вторую с начислением денег?) Потом каждая команда запускает свой запрос, или это только клиентская штука?

Заранее извиняюсь если неверно все понял.

В таком решении вы мешаете чисто клиентскую декоративную логику — анимацию — с серверной бизнес-логикой — зачислением денег. А это может привести к проблемам.
Например, если вы командой запускаете катсцену при убийстве босса, и в конце её зачисляете награду за убийство. А другой человек реализует функциональность пропуска катсцен — отменой команды. Или же игрок босса добил, а анимацию решил не смотреть и перезагрузил страничку, скажем. И в результате игрок не получает награду.

Не знаю, насколько вероятен такой пример в реальности, но предложение автора — отдельные события «обновить деньги на сервере» и «показать обновление денег клиенту» мне нравится больше.

Почему именно игры яснее видно во второй части про команды: habr.com/post/435704
В отличии от бизнес-приложений типичная игра почти полностью детерминирована клиентской информацией, поэтому предиктит почти все действия сервера, кроме того возникают типичные для игр, но не характерные для бизнес-приложений проблемы, что много анимаций, которые надо асинхронно контролировать. Наконец именно для игр характерна ситуация отладки когда цена ошибки невелика, ДАУ очень велико, но при этом информация, известная программисту обычно явно недостаточна, и логов мало, и приложение делает очень много что не сообщая об этом серваку.

Но так то да, комплекс проблем характерен не только для игр.