• Собственная игровая аналитика за $300 в месяц
    0
    Ну и тут вопрос скорее не в пропускной способности, а в количестве данных, которые накапливаются. Как видно из расчетов, прирастает примерно по 600Гб в месяц. Бывает нужно делать очень кастомные запросы за довольно большой промежуток времени.
  • Собственная игровая аналитика за $300 в месяц
    0
    Звучит неплохо. Есть несколько вопросов:

    * Приходилось ли ELK стэком визуализировать real-time данные (ну или в случае с Kibana с частым auto-refresh)?
    * Какой максимальный объем данных приходилось хранить?
    * Какова производительность запросов, например за сколько можно произвести аггрегацию данных всей базы?
    * Хватало ли инструментов по визуализации?
  • Собственная игровая аналитика за $300 в месяц
    0
    Я тут пересчитал все без HDInsight, так как нет смысла это все пихать на Hadoop для таких объемов данных. Apache стэк так же вышел очень рентабельный =)
  • Собственная игровая аналитика за $300 в месяц
    0
    Google BigQuery тоже клевое решение! На нем можно построить примерно то же самое.
  • Собственная игровая аналитика за $300 в месяц
    0
    Слишком сложно и дорого.

    А в чем сложность? Все сводится к тому, чтобы поднять через портал пару сервисов, и связать их вместе. Ну в нашем случае еще пару Azure Functions написать — но это опциональный шаг, если нужна гибкость.

    Такой поток метрик — довольно детская нагрузка. Среди основных требований — легко масштабироваться. Если игра схватит фичеринг, то легко можно вырасти в 10,20,30 раз.

    У меня нет большого опыта с ELK. Но те студии, с которыми мы работали, у которых была своя система аналитики, ELK для игровой аналитики не пользовали. Пользовали для мониторинга.
  • Собственная игровая аналитика за $300 в месяц
    0
    Я писал
    Решение «на голых VM» оценивалось ровно с такой же конфигурацией, что предлагает HDInight. Конечно, пожертвовав надежностью, можно уменьшить размер кластера и снизить цену, но это не совсем корректное сравнение.

    Дело в том, что цена кластера — важный параметр. Но такой же важный параметр и надежность. Что будет, если эта единственная нода упадет? А что если в аналитику идут бизнес-критичные данные, по которым потом рассматривают тикеты пользователей?

    Оценка Apache Stack'a была довольно грубой, широкими мазками, так сказать. Я понимал что конфигурация кластера мощнее, что можно это все развернуть руками на виртуалках меньших размеров, но я так же понимал, что студиям придется заниматься администрированием. А как я и говорил раньше, они не очень готовы в это вкладываться.
  • Собственная игровая аналитика за $300 в месяц
    0
    Спасибо за отзыв! Со многими пунктами согласен. Видимо не удалось передать основную идею запросов от партнеров. Как я и писал 1к в сек — смешная цифра. Но это то, с чего обычно начинают игры на старте. И заканчивают на этапе сансета.

    азур стека пересчитать под более близкую нагрузку к kafka+spark (за $1181) разница будет в тысячи долларов.


    Давайте пересчитаем =) Какую нагрузку вы считаете оптимальной для такой конфигурации кластера?

    а тысячу событий просто же в mysql/postgres легко писать можно.

    Можно, но у нас есть конкретные примеры, когда игровым студиям было проблематично поддерживать БД больших размеров (3TB+), и запросы на них выполнялись многими часами.

    плюс возможности kafka+spark+настоящий map-reduce явно другая вселенная в плане возможностей напрограммировать.

    Можете рассказать поподробнее, в чем вы видите ограничения по возможностям напрограммировать?

    3 ноды по 4 ядра хадупа явно на два-три порядка более, чем 1к событий/сек прожуют

    с 1к/сек нет смысла так усложнять архитектуру, а рост нагрузки приводит к дополнительным расходам на каждый чих.

    Согласен, но задача была посчитать **минимальную** конфигурацию, начиная от 1к событий в сек. Я ориентировался на минимальную архитектуру Apache Stack'a в рамках HDInsight.

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

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

    Они хотят начать с малого, платить за то что используют. Но при этом, в случае если игра бомбанет, быть уверенными, что ничего не шлепнется. Быть способными переварить весь возросший объем данных.
  • Собственная игровая аналитика за $300 в месяц
    0
    Ну это же облако. Там есть свои лимиты на Data Lake Storage аккаунт, но там скорее в деньги упрешься.

    Плюс обычно делают, что данные архивируют в другие виды хранилищ, так как дешевле, и не всегда ты ими пользуешься. Так что можно считать, что нет.
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    0
    Когда я проводил исследования, аллокации от команд были незначительными, по сравнению с аллокациями при поддержке иммутабельности.

    Команды можно сделать struct, но тогда придется пожертвовать, например, строгой типизацией. Ведь чтобы хранить контейнер полиморфных команд, их все равно придется боксить. Поэтому команду придется привести к одному классу, а тип внутри команды обозначить enum. Параметры же придется организовать в виде какого-нибудь Dictionary<string, object>.

    В таком случае команда будет выглядеть примерно так:

    public struct Command
    {
        public enum Type {
            AddCoins
        }
    
        public Type type;
        public Dictionary<string, object> parameters;
    }
    
    ...
    
    void HandleCommand(Command cmd)
    {
        switch (cmd.type)
        {
            case AddCoins:
                ...
                break;
        }
    }
    


    Если же хранить команды в контейнере не надо, то можно писать отдельные типы команды, а сам тип определять по cmd.GetTypeCode() (обычный GetType боксит), по нему же выбирать какой хэндлер вызвать.
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    0
    Ну я за эти годы повидал несколько крупных проектов. И там стейт был далеко не маленьким. Например, были прецеденты, когда все получаемые в игре вещи/апгрейды складывались в стейт. Таким образом, если юзер хайлевел, и ему некуда их утилизировать, то они накапливались.

    Хоть они и стакались, количество уникальных вещей со временем все равно росло сильно. В итоге стейт очень разрастался.

    Это проблема и архитектуры и дизайна, но от этого никто не застрахован.
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    0
    Адекватным подходом — никак. Либо искать реализации каких-либо древовидных структур, которые скрывают возможность изменения стейта за методами, возвращающими новую ссылку на стейт, а под капотом по-умному генерируют дифф над предыдущим состоянием.
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    +1
    Реактивное программирование не обязательно должно быть полностью по ФП.

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

    Так то в ивенты можно отдавать отдельные иммутабельные подмножества стейта.
    В любом случае — это довольно субъективный взгляд и каждый решает как ему удобнее.

    Что касается того, что каждый раз нужно создавать новый стейт — лишние аллокации в играх ни к чему хорошему обычно не приводят :), а если стейт жирный, то можно на хорошие такие грабли наступить.
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    +1
    Я пришел в итоге к выводу, что если такие люди есть, и они не понимают объяснений, что так делать не надо, то с ними лучше не работать. По моему опыту большинство людей достаточно умны, чтобы так не делать. Ну а новичкам всегда код-ревью делать.

    Так же чудаки всегда умудрятся любую защиту сломать =)

    Если же это действительно критично, и если уж совсем по кананам, то это фиксится просто:

    1. Делаем IReadonlyGameState
        public interface IReadonlyGameState
        {
            int coins { get; }
        }
        [System.Serializable]
        public class GameState : IReadonlyGameState
        {
            public int coins { get; set; }
        }
    

    2. В stateUpdated кидается IReadonlyGameState.

    У этого подхода есть большой минус.
    Если GameState содержит вложенные объекты, то их тоже нужно делать с двумя интерфейсами мутабельным и иммутабельным. Это выливается в кучу проблем.

    Если бы C# поддерживал что-нибудь типа const в С++, то ситуация была бы намного проще =)
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    0
    А можешь поделиться линком где можно поподробнее почитать?
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    0
    Нет, такой подход не пробовал, но идея интересная :) Не знаю насколько это будет удобно.
    Я использовал UniRx для построения запросов к модели. Было довольно удобно.
  • Развязываем игровой код с помощью паттерна Command, и дебажим, летая на машине времени
    +1
    Это же tutorial, как построить что-то похожее своими руками. Как комбинировать паттерны. Я не претендую на инновационность

    Пожалуй перефразирую, чтобы не было дальнейших казусов. =) Спасибо за отзыв.

    На счет устоявшейся практики — это преувеличено. Многие пишут код прямо во View и не парятся.
  • Строим распредёленное реактивное приложение и решаем задачи согласованности
    0
    Понятно, благодарю за разъяснение.
  • Строим распредёленное реактивное приложение и решаем задачи согласованности
    0
    S3 отлично позволяет хранить данные, но не даёт возможности выполнять эффективные поисковые запросы


    а возможностей Amazon Athena недостаточно?
  • Docker в продакшене: обновление
    0
    Согласен. Но учитывая, что докер построен вокруг именно такой идеологии, то в случае с одной системой его выгода сомнительна.
  • Docker в продакшене: обновление
    0
    Вопрос в том — зачем? Ведь докер говорит о том, что должно работать одинаково на всех системах. Build, Ship, and Run Any App, Anywhere
  • Рояль должен быть исчезнут: уровни профессионального развития и их оценка, у программистов
    +5
    В моем понимании, упущен один из важных уровней развития — понимание, что программирование не только про код, архитектуру и разработку.

    Говоря в терминах статьи — это еще более высокий уровень. Уровень осознания задачи и понимания ее значения в бизнесе. Именно это понимание останавливает человека от того, чтобы писать код ради самого кода.

    Этот этап становления программиста, мне кажется одним из самых ключевых.

    А в остальном — идея статьи очень интересна, спасибо.
  • Архитектуры ReactNative, Xamarin, PhoneGap и Qt. Часть 2
    0
    Со своей стороны хочу добавить про то, что сейчас Qt — это больше QML, нежели C++. Конечно, с мобильными платформами все посложнее будет, но ситуация постепенно улучшается. Я все же надеюсь на появление библиотек нормального качества для работы с API мобильных платформ. А то прокидывать, например, все через JNI — то еще удовольствие.

    Что мне нравится в QML, так это внятная декларативность. А в случае, когда декларативности не хватает — можешь писать на JavaScript. И то и другое может освоить даже дизайнер. Таким образом, можно иметь одного опытного чувака, который будет работать на C++ glue и предоставлять все нужное для QML. А в QML могут работать люди, которые знакомы с JS, или даже дизайнеры. Например подкрутить анимации или накидать экран — реально просто.

    На счет подгона под Look&Feel платформы — все так. Это может быть та еще боль и страдания. Один скролл чего стоит.
  • С чего начать молодым разработчикам мобильных игр из России [Часть 3]
    +1
    В целом, вся бизнес-логика мета-игры должна быть отвязана от Unity-классов. Тогда написать Unit тесты не составит проблем. Чтобы начать unit-тестить можно попробовать туторы от Unity.

    Идея в том, чтобы Unity был только прослойкой для вызова соответствующих методов. Тогда после написания бизнес-правил и unit-тестов, все что останется — привязать соответствующие вызовы из UI.

    Если тесты написаны правильно, то все должно работать как часы. И проблемы могут быть только на стороне UI или взаимодействия с сервером.

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

    Помимо Unit-тестов можно так же сделать интеграционные тесты. Например, я тестировал интграцию с facebook, получив руками токен, и запуская тесты, которые дергали разные API методы FB и проверяли, что наш код работает ок.

    Такие штуки могут так же позволить отловить проблемы, когда инеграция со сторонним сервисом отваливается.

    Но в принципе, unit-тесты самый простой и быстрый способ.
  • С чего начать молодым разработчикам мобильных игр из России [Часть 3]
    0
    Я первое время тоже шел по пути «не хватает рук», но потом понял, что тестировать Unit-тестами всякую логику для meta-игры гораздо проще. Не каждый раз запускать игру и проверять. С геймплеем, конечно, все посложнее будет. Но это точно никак меня не замедлило, скорее наоборот.
  • С чего начать молодым разработчикам мобильных игр из России [Часть 3]
    0
    Вижу что вы очень серьезно относитесь к качеству и тестированию. По моему опыту ручное тестирование может выявить дай бог 10% багов.

    Интересно, проводите ли вы только ручное тестирование, или же еще пользуетесь автоматизированным? (Unit тесты, игровые боты и т.д.). Например, мне, в свое время, очень помог игровой бот, который выявлял проблемы с уровнями, которые были только на определенных устройствах.

    Успехов с проектом!
  • С чего начать молодым разработчикам мобильных игр из России в текущих реалиях
    0
    Будет интересно узнать как у вас с этим дела. Я заметил тенденцию, что многие инди не учитывают, что в случае успеха, их юзербаза резко вырастет и все может загнуться :). Именно поэтому важно проектировать игру с учетом этих особенностей. Потом оптимизировать и переделывать будет гораздо сложнее. А возможно и слишком поздно.
  • Узники системы
    0
    Большинство менеджеров разработки, с которыми я сталкивался, понятия не имеют как эту самую разработку менеджить. Да и вообще плохо понимают что такое менеджмент.

    Это очень печально.
  • Узники системы
    0
    Вообще, во всех организациях, кроме благотварительных, цель — получение прибыли. Agile как раз про это, ведь он позволяет оперативно реагировать на изменения рынка/требований. Внедрять Agile сложно в организациях, где правят староверы или где разработка — не основной вид деятельности.
  • Узники системы
    0
    Конечно сложно сдвинуть что-то гигантское. Но положительный тренд уже прослеживается. Если банки смотрят в эту сторону, то значит Agile может отвечать всем требованиям качества/безопасности.

    Кстати, еще вспомнил про Альфа-банк. Они не так давно писали про их Agile.
  • Узники системы
    +1
    Кстати, я заметил, что слишком много людей в менеджменте не имеют представления что это такое. Не имеют профильного образования. Не желают слушать и учиться. От того и помехи :(.
  • Узники системы
    0
    И толковый менеджер должен в этой ситуации не «продавить», а спросить «а как мы можем сделать чтобы это было на один пиксел левее?»

    Согласен. Но и толковый программист, если заинтересован в успехе проекта, должен предложить альтернативные решения.

    Вообще, так как программист лучше всего осведомлен о текущем состоянии проекта, мне кажется, это обязанность программиста — предупреждать о возможных рисках/проблемах, и предлагать варианты решения. Менеджер же не должен пропускать это мимо ушей, должен принимать конкретные решения и дейтвовать.
  • Узники системы
    0
    А как же банки? Сбербанк практикует Agile. Надежность для них крайне критична. Бабло, ответственность, все дела.
  • Узники системы
    +1
    Это можно сказать о всем где есть «философия». А методики — тоже философия.
  • Узники системы
    +1
    Проблема отсутствия уважения существуют с двух сторон. Программисты тоже часто не уважают менеджеров просто за тот факт, что они менеджеры. Но в целом я согласен. В этом плане CTO во многом может на все влиять.
  • Узники системы
    0
    Просто посмотрите кто придумал эти методологии. http://agilemanifesto.org/authors.html
    Лично мне кажется, что они изначально разрабатывались в помощь программистам. Но все их понимали по-своему и модифицировали, Эти же парни (авторы agile manifesto) были поражены, что появилась такая вещь, как Dark Scrum.

    Возможно и мы сами их понимаем неправильно, боясь облажаться перед начальством.

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

    Поэтому я могу сделать вывод, что это все зависит от начальства. Хотя и мы сами, если будем говорить о проблемах, можем повлиять на их точку зрения.
  • Узники системы
    +4
    Честно говоря я не встречал прямо таки нездоровой конкуренции между разработчиками. Командные игроки выгоднее для проекта, чем «звезды-одиночки».
  • Узники системы
    0
    Например, скрам-покер — известный факт что в большинстве случаев, программист over-optimistic при оценке задач, особенно при ограниченном колиестве информации и времени на оценку, а также психологическом давлении при публичном их вынесении, чтобы казаться лучше в глазах коллег и начальства.


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

    Часто сталкиваю с тем, что люди молчат о проблемах и дуются.

  • Узники системы
    0
    Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.


    Общая тенденция ужасна. Тут я абсолютно согласен.

    Это да. Но как по мне нельзя однозначно сказать что хуже — потерянное время на прослушивание уже известных вещей или отсутствие информации о развитии проекта.


    Как правило, информацию о развитии проекта можно выбить из определенных людей :) А вот время вернуть сложно. В любом случае можно организовывать митинг в формате «сейчас новая инфа: бла-бла-бла. А теперь остаются те, кто не в курсе последних событий».
  • Узники системы
    0
    Вероятно ноги растут из излишнего фанатизма или некоторого ЧСВ программистов выше джуно

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

    Например, я работал с аниматором, которому было западло однотипно называть файлы анимаций, чтобы их было легко загрузить из кода. Он сказал «Я аниматор, я хочу анимировать, а не файлики переименовывать».

    По аналогии и программеры поступают. «Я программист, хочу код писать, а не на митинги ходить и таски заводить».
  • Узники системы
    0
    Вы зрите в корень :) Да, статья подводит к DevOps.