Сделай игру

Для начала давайте определимся с терминологией. Состояние приложение - это набор данных приложения, или модель данных, которая необходима для верной работы приложения. Она может в себя включать как все данные приложения, так и лишь некоторые. Библиотек состояния приложения сейчас довольно много и это обоснованно. Состояние приложения - это очень удобно: всегда есть нечто вроде "карты" состояния всего и сразу; в любой момент можно понять что и как: какое окно открыто, какой текст введён в поле ввода или какие привилегии есть у пользователя после авторизации...

Не так давно некий упитанный бородатый министр с экранов разных устройств, на голубом глазу, рассказывал, что стране просто позарез необходимо 600 тысяч айтишников, чем, безусловно, вызвал у ИТ сообщества не то, чтобы скепсис - полное недоумение. С точки зрения министерств всё ясно: каждое пытается доказать, что только оно единственное нужное, правильное и полезное, а, значит, именно в него нужно направить финансовые потоки и по его направлению создавать рабочие места и направления. Однако время...

Сама идея написания тестов мне всегда казалась избыточной. Не то, чтобы я отрицал их пользу, однако большую часть времени они были сущей профанацией: проверялись какие-то случаи, которые с высокой степенью вероятности будут проверены на правильность ещё во время разработки, либо писались для откровенно фантастических случаев. Я уж не говорю о том, что те, кто эти тесты писал, нередко, также как и я не понимали зачем тестировать "это"? Оттого, тесты часто и получались лишь для галочки. Но однажды всё поменялось...

При написании игр, нередко, можно столкнуться с проблемой: вот есть мой персонаж, который представляет из себя сложную форму, совсем не похожую на прямоугольник; и есть другой персонаж, тоже совсем не похожий на прямоугольник. И они, в какой-то момент, пересекаются - и как же определить, что факт пересечения наступил? Эту прикладную задачу и рассмотрим в статье. Изначально о простом: определить пересечение двух прямоугольников просто, а двух многоугольников - нет. Но "не просто" не значит невозможно,...

В любом 2D-платформере, файтинге или даже простой аркаде столкновения — это основа игрового процесса. Пол, стены, враги, платформы — всё это работает благодаря системе обработки столкновений. Но на самом деле, такие системы используются не только в играх: любая графическая среда, где объекты взаимодействуют друг с другом (например, UI-анимации или симуляции), тоже опирается на схожие принципы. В этой статье я хочу разобрать способ создания своего обработчика столкновений. Обработка столкновений всегда идёт рука об руку с перемещением объектов...

Морской бой - одна из лучших игр для скучных уроков или лекций. И, если в прошлом она требовала лишь два листа бумаги, то теперь понадобится лишь выход в интернет. Давайте его сделаем. Мы сделаем клиент-серверную версию, где будет лёгкий клиент - веб страница, которую, при желании, можно перенести в какое-нибудь приложения, вроде telegram, а сервер будет написан на Go. Хотя данную задачу можно решить и средствами одного лишь html+js, мы, всё же, пойдём по пути клиент-серверного решения: кто знает, может быть следующим шагом мы захотим сделать сетевую версию...

Задача сделать чат кажется довольно тривиальной: даже если вам не приходилось его делать самостоятельно, то, наверняка, видели примеры, как делают чаты в учебных примерах для различных технологиях. Поэтому мы не будем фокусироваться на деталях, а попробуем спроектировать архитектуру системы и рассчитать нагрузку, которая позволит всему этому функционировать. Кто-то называет это гордо system design, но как по мне - это просто предварительный расчёт. Давайте предположим что у нас есть некая "браузерная...

SOLID — это не просто модное слово из мира программирования. Это набор принципов, которые помогают писать код, который: Если игнорировать SOLID, код быстро превращается в "лапшу", где всё зависит от всего, а любое изменение требует танцев с бубном. Давайте разберём каждый принцип на реальных примерах. Класс должен делать что-то одно. Если у него несколько задач — рано или поздно они начнут мешать друг другу. Изначально класс Basic даёт доступ к страницам 1, 2, 3 и для Visitor, и для Admin. Потом выясняется, что Visitor не должен заходить на страницу 3...

Мы уже делали симуляцию движения кораблика по волнам (вот тут), но это была, так сказать, математическая подготовка к более сложной версии решения. Теперь, давайте сделаем симулятор волн, но в 3D. За основу я взял три технологии: JS, WASM и WebGL. Задумка в том, чтобы генерировать точки внутри wasm-пакета (я выбираю rust), передавать их в js приложение, а уже оттуда передаваться в webgl. Поскольку рисунок морской качки будет повторяться - разобьём пространство на плитки, скажем, MxN и каждую плитку будем отрисовывать единым шейдером, но по разным параметрам...

Программист — тоже потребитель, который хочет удобства. Разработчики привыкают к мощным компьютерам, быстрым SSD и современным IDE. Это создаёт комфортную среду, где код пишется и отлаживается мгновенно. Однако такая роскошь формирует ложное ощущение, что приложение будет так же быстро работать у всех пользователей. На деле многие из них используют слабые ноутбуки, старые смартфоны или бюджетные устройства с ограниченными ресурсами. В 2017 году игра PlayerUnknown’s Battlegrounds (PUBG) на ПК требовала 8 ГБ ОЗУ, но из-за плохой оптимизации лагала даже на топовых видеокартах...

Разработка игр — это не только про креатив и геймдизайн, но и про управление сложностью кода. Чем больше растёт проект, тем сложнее вносить изменения, и если не следить за архитектурой, даже простые правки могут превратиться в кошмар. Давайте разберём ключевые принципы, которые помогут избежать коллапса. Хороший код должен не только работать, но и оставаться гибким для доработок. Если игра выдаёт ошибки или лаги, это критично, но не менее важно, чтобы код позволял быстро добавлять новые механики без переписывания половины движка...

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