Очередной раз разрабатывая и оптимизируя архитектуру не вполне стандартного проекта, для чего у AI, ожидаемо, нет готового шаблона, а только «лоскутки» чужих решений, решил зафиксировать свой ход мыслей и последовательность этапов в решении нестандартной задачи. Чтобы абстрактную программистскую «чуйку» зафиксировать в более чёткий и осознанный «свод правил».

Представьте, что у вас есть некая система, которая работает определённым образом. У неё есть свой API, свои архитектурные принципы, рекомендуемые подходы к разработке и т.п. С другой стороны, у вас у самого есть видение своего будущего проекта, его архитектуры и того, как бы вы хотели управлять функционалом, предоставляемым «некой системой». Видение есть, а вот уверенности, что так можно – нету. Вот, делюсь своим подходом, как я поступаю в таких ситуациях.

Если вы занимались профилированием своего приложения, то, глядя на CPU Flame Chart, вероятно, испытывали смесь досады и азарта, глядя на особо «жирный» метод. Досады – что ваша программа всё ещё не идеальна по скорости. Азарт – от того, что вы можете докопаться до причины проблемы и отжать для процессора ещё немного свободного времени на более полезные вычисления. По крайней мере, я регулярно становлюсь жертвой обоих этих чувств, чему данная статья и обязана своим появлением.

Мой кейс – это попытка выжать из игрового движка Flame больше скорости и возможностей, чем он может «из коробки». Гейм-разработка имеет свои особенности по сравнению с «парсингом большого json» или устранением подлагивания при разовом проигрывании анимации, как минимум потому что здесь потенциально объёмные вычисления производятся абсолютно на каждом кадре. Так что, наверное, мой опыт не сильно будет перекликаться с теми проблемами, которые встречает большинство Flutter-разработчиков.

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

Всем привет! В свободное от не-работы время я CTO собственной компании (DigitalWand), и как следствие – чем мне только ни приходится заниматься! И вот недавно один из наших клиентов посетовал на проблемы в своей внутренней кухне: мол, вирус положил внутренние сервисы, включая git и площадки для разработки. И тут мне вспомнилась собственная аналогичная проблема, которая произошла год тому назад. Вот эту страшилку и хотел бы рассказать. Думаю, будет полезна как начинающим сисадминам и девопсам, так и вообще людям, которые каким-то боком с линуксовыми серверами связаны, но серьёзного пороха ещё не нюхали.

Мой опыт работы с игровыми движками для Flutter привёл меня к, в целом, удручающим выводам: производительность хромает, и без специально проработанных «хаков» сделать что-то сложнее простой казуалочки представляется нереальной задачей.

Ранее я перечислил ряд подходов, которые смогут ускорить ваши вычисления от нескольких десятков до нескольких сотен раз. Однако, это не предел. Сегодня расскажу ещё об одном методе, который поможет вывести игровой движок Flame на новый уровень.

Как я уже писал ранее, на FPS в Flame в основном влияют операции, производимые на CPU. Если в вашей игре достаточно много взаимодействующих объектов, то одной из самых дорогих операций будет определение столкновений. Настолько дорогой, что на экране performance-метрики она закроет собой любые другие неоптимизированные участки.

Сами авторы Flame отлично осознают, что их алгоритм – не идеальный, а просто «дающий достаточную производительность». Достаточна она, видимо, для случаев, когда у вас всего объектов 10, не более. Если же у вас что-то более сложное – тогда приятного чтения!

В предыдущей статье я разбирал проблемы Bonfire и причины, по которым он не очень подходит для сложных игр. Несмотря на то, что чистый Flame намного легче, там тоже не всё так гладко. В этой статье я поделюсь своими рецептами увеличения производительности игры и распишу причины, почему это работает. Хочу сразу заметить, что среди этих рецептов нет серебряных пуль, и маловероятно получить существенный буст, применив только что-то одно. Однако в комплексе они достаточно эффективно работают – проверено часами медитации над CPU-профайлером.

Всем привет! Продолжаю делиться своими раскопками в области использования Dart и Flutter не совсем по назначению. Хотя, учитывая недавний выход в релиз тулкита от Flutter для разработки казуальных игр (https://flutter.dev/games), можно сказать, что статья как раз тематическая. Ну, решайте сами. Кому интересно, что может выйти, если попробовать сделать на Flutter игру серьёзнее "крестики-нолики" и взять в качестве основы фреймворк Bonfire - приглашаю под кат.

Кто-нибудь пробовал использовать Dart / Flutter как на клиенте на нескольких платформах, так и в качестве сервера? Кто-то, конечно. пробовал, хотя далеко не каждый за этим приходил к Flutter. Я на своём pet-проекте провёл такой эксперимент, и хотел бы поделиться результатами и выводами.