Почти полный список моих личных проектов

Несколько прототипов игр, эксперименты с процедурной музыкой, разработка модов, два геймджема, пара веб-сайтов и диплом на тему искусственного интеллекта в видеоиграх. Всё с открытым исходным кодом.

До 2015 года у меня ничего особо не сохранилось, к сожалению. Тогда я был занят учёбой, занимался программированием микроконтроллеров и ПЛИС, а в свободное время хотел сделать робота. Закупился деталями, купил гусеничное шасси с двумя двигателями, пару сервоприводов, микроконтроллеры AVR ATmega и пару радио-модулей. Для начала просто хотел сделать гусеничную платформу с управлением по радиоканалу, но так ничего и не доделал, так как сложно было совмещать работу, учёбу и проекты.

В какой-то момент я решил, что надо бы сделать свою игру. Я изучал Java, а самой популярной библиотекой для разработки игр на джаве была libGDX. К сожалению, libGDX — это не движок, поэтому кучу вещей пришлось писать самому: переключение сцен, модель актёров, поиск пути и много другого.

Идея игры у меня появилась после того, как я поиграл в Frozen Synapse. Захотелось сделать тактический top-down шутер для мобильных устройств, в котором можно пальцем рисовать траекторию движения персонажа.

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

Технологии: Java, libGDX.

Исходники: GitHub.

К счастью, наработки VT не пропали совсем уж даром. Я доработал прототип и использовал его как полигон для изучения и тестирования алгоритмов поиска пути. Написал курсовую работу по алгоритмам, в которой сравнил производительность алгоритма Дейкстры и A*. Я использовал ассеты игры, чтобы нарисовать, какие шаги проходят оба алгоритма, прежде чем находят оптимальный путь. Получилось познавательно.

Технологии: Java, libGDX.

Исходники: курсовая работа, ветка VT с поиском пути.

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

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

Исходную проблему оно решило, часть одногруппников им успешно пользовалась. Я даже пробовал его продвигать. Распечатал объявление со ссылкой на Google Market и повесил его в холле университета рядом с другими объявлениями. На следующий день его там уже не было. Раз университет не захотел сотрудничать, я забил.

Технологии: Java, RxJava, Android SDK, HTML.

Исходники: GitHub.

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

Для этого я собрал простой top-down шутер на Unity с одной ареной и небольшим набором правил. На арене есть стены (блокируют обзор и выстрелы), укрытия (блокируют 50% выстрелов), пара аптечек и пара ботов, которые сражаются друг с другом. Назвал его Vector Tactics. Вообще, это название принадлежит VT (который и есть Vector Tactics, просто сокращённо), но так как я его уже вряд ли бы продолжал, название освободилось.

Всего было 4 бота, по одному на каждый алгоритм принятия решений: конечный автомат, дерево поведения, нечёткая логика и нейронная сеть (простой трёхслойный перцептрон). Я их стравливал друг с другом в тысячах боёв и собирал статистику.

Технологии: C#, Unity.

Исходники: GitHub.

В 2016-2017 годах я учился в Wargaming Academy. Подробнее об этом можно почитать у меня в посте о том, как я попал в разработку игр. В качестве проекта я делал хоррор про антиутопию на Unity (жанр и сеттинг выбирались по жребию). На новогодних праздниках в январе 2017 я прошёл примерно десяток хорроров, изучая жанр. Больше всего меня впечатлил Layers of Fear, поэтому я решил сделать игру, в которой окружение меняется, когда игрок не видит.

Игра проходится минут за 5. Игрок ходит по школе в антиутопическом сеттинге во время комендантского часа. Можно заходить в разные комнаты, но когда ты в неё заходишь, она перемещается, и выйдешь ты уже в другом месте.

В комнатах нужно искать книжки (типичная механика для хорроров тех времён). При посещении каждой комнаты у игрока росла шкала безумия. За каждую найденную книжку она уменьшалась. Чем больше уровень безумия, тем более странные комнаты появляются в игре и тем сильнее искажается окружение. В игре даже есть две концовки: для низкого безумия и для высокого.

Я очень доволен архитектурой игры и вообще всем, что связано с кодом. Каждая комната — это отдельная сцена в Unity. У неё есть параметры, при каком уровне безумия она может появляться. Когда игрок подходит к двери, за которой может оказаться одна из этих комнат, игра выбирает все комнаты для текущего уровня безумия и берёт одну из них случайным образом. Когда игрок заходит в комнату, игра делает то же самое, но уже для дверей: игра ищет подходящие дверные проёмы, к которым можно переместить комнату и выбирает один из них. Т.е. игрок может выйти совсем в другом коридоре с совсем другим окружением.

А вот всё, что касается работы с графикой и ресурсами, было сделано, по моему мнению, плохо. Я просто купил пак ассетов для хоррор-школы. Я не разбирался в текстурах и материалах (да и сейчас стало не сильно лучше), поэтому каждая стена была вытянутым кубом, на которую я натягивал текстуру школьной стены. При этом если стены были разного размера, у них были разные материалы, потому что я не знал, как сделать материал, который одинаково хорошо смотрелся бы на стенах длиной и 2 метра, и 10 метров.

Но всех этих проблем с ассетами не видно в готовой игре, а на производительность они не сильно влияли — игра слишком простая для этого. В итоге я получил диплом за лучший проект Wargaming Academy 2017.

Технологии: C#, Unity.

Исходники: GitHub.

В 2018 году я стал подумывать о разработке полноценной игры в свободное время. Мне захотелось сделать игру, в которой ты защищаешь свой город от огромных годзилла-образных монстров. В такой концепт можно засунуть просто огромное количество отсылок: кайдзю (Годзилла, Тихоокеанский рубеж), огромные летающие тарелки (День независимости), ангелы (Евангелион), стена вокруг города (Тихоокеанский рубеж, Атака Титанов), огромные человекоподобные роботы (меха-аниме), тупые военные, открывающие огонь, когда не надо (куча всего).

Я думал, что можно сделать RTS в таком сеттинге. Начал делать прототип, чтобы проверить, будет ли это работать. Взял бесплатные ассеты с городом, каким-то драконом, танками и начал собирать из этого игру.

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

Потом я стал добавлять экономику. В RTS мы всегда добываем какие-то ресурсы. Какие вообще могут быть ресурсы в таком сеттинге? Я так и не придумал. Решил, что главный ресурс, который может быть в такой игре — это время. У тебя чрезвычайная ситуация, ты можешь вызывать войска в любом количестве, не думая о деньгах, но всегда нужно время, чтобы войска прибыли до места действия.

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

К сожалению, прототип показал, что играть в это не так весело. Микро-менеджмент в духе классических RTS просто не подходил этом сеттингу. Я вдохновлялся фильмами типа Годзиллы, а RTS, где ты только и делаешь, что гоняешь танки по улицам — это не совсем тот опыт. Хочется чего-то с глобальными решениями.

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

Технологии: C#, Unity.

Исходники: GitHub.

В 2019 году я проходил курс по теории музыки на Udemy. Просто захотелось понимать музыку и как она устроена. Тогда же у меня появилась идея заняться генеративной (процедурной) музыкой, т.е. музыкой, которая создаётся с помощью алгоритмов. Есть хорошая презентация на эту тему с интерактивными примерами.

Главная идея была такая: если мы играем в определённом ключе, то все (почти) аккорды в этом ключе будут звучать хорошо. Возможно, вы слышали про такие термины как «ля минор» или «до мажор». Вот это и есть ключ. Не буду углубляться в музыкальную теорию, так как всё равно не смогу ничего объяснить и перевру половину.

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

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

Тут есть два варианта.

Первый: использовать машинное обучение и научить компьютер генерировать музыку на основе существующей библиотеки аудио. Это задача для Google, Apple, Spotify или еще кого-нибудь, у кого есть огромная коллекция музыки для обучения алгоритмов. К сожалению, компьютер не будет понимать, что он делает — нейронки просто копируют что-то существующее с изменениями.

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

Мне нравится второй подход, но это очень сложно. У меня нет музыкального образования, и я никогда не писал музыку, поэтому мне очень сложно проектировать подобную систему. Сейчас проект заморожен и мне очень обидно из-за этого. Я бы хотел ещё над ним поработать, но понимаю, что просто не потяну его.

Технологии: C#, Unity.

Исходники: GitHub.

В 2019 я решил сделать собственный мод для Beat Saber и разобраться, как они работают в играх на Unity. В Beat Saber нет встроенной поддержки модов, поэтому нужно было их сначала туда как-то добавить. Так я узнал про BSIPA, Unity Doorstop, Mono.Cecil и Harmony. В них используется несколько очень крутых технических решений: например, модификация библиотек игры и движка, внедрение в таблицу импорта DLL и вмешательство в загрузку Mono Runtime, который используется в Unity, чтобы можно было запускать C#-скрипты в движке, написанном на C++.

С этого проекта начался мой блогерский путь на DTF. Я написал две статьи: одна про внедрение модов и одна про разработку:

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

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

Технологии: C#, Unity, декомпилятор C#, C, BSIPA, Unity Doorstop, Mono.Cecil, Harmony.

Исходники мода: GitHub.

В январе 2020 я участвовал в Finnish Game Jam 2020 (финское отделение Global Game Jam). Тема джема была «Ремонт». Мы решили сделать игру, в которой инопланетянин на своём космическом корабле пытается добраться до дома. К сожалению, его корабль настолько плох, что ломается несколько раз в минуту.

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

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

В команде было 3 человека. Я отвечал за геймдизайн и код паззлов.

Технологии: C#, Unity.

Исходники: GitHub.

Однажды я узнал, что на GitHub есть сервис GitHub Pages. По сути, это бесплатный хостинг для статических сайтов. Я решил, что можно сделать там свой личный сайт с блогом и портфолио. Судя по описанию, в качестве движка сайта можно взять Jekyll, выбрать там какую-нибудь визуальную тему, а GitHub сделает всё остальное.

На практике всё оказалось сложнее, и мне пришлось самому дописывать кучу всего для шаблонов страниц на смеси HTML, YAML и Liquid и частично переписывать стили в CSS. Ну хоть работает.

Технологии: Jekyll, GitHub Pages, HTML, CSS.

Исходники: GitHub.

В какой-то момент я узнал, что у DTF есть API и что здесь используются инкрементные идентификаторы для статей и пользователей. Это значит, что можно просто скачать всех пользователей и статьи, запрашивая их по идентификатору, начиная с 1.

Так я и сделал. За несколько дней я выкачал все доступные данные с DTF и построил кучу графиков и таблиц:

Технологии: Python, PostgreSQL.

Исходники: GitHub.

В октябре 2020 на DTF был джем от народа с темой «Изоляция». Я был банален и сделал игру про самоизоляцию. Главным героем игры является Кукуха, которой нужно сидеть дома и никуда не поехать (серьёзно, всё это делалось ради этого каламбура).

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

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

Я писал в своём блоге на DTF, как устроена эта система и как она выбирает, что будет дальше:

Я решил использовать этот геймджем, как возможность начать изучать Unreal Engine 4. Из-за этого половину времени я делал не игру, а боролся с движком, так как не знал, как делать базовые вещи. Но вроде бы чему-то научился, так что всё было не зря.

Технологии: C++, Unreal Engine 4.

Исходники: GitHub.

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

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

Это первый раз, когда я делал веб-проект с нуля. Я выбрал Vue.js для фронта и Python (Flask) для бэкенда. Практически с самого начала разработки я обнаружил, что шутки про огромное количество технологий, фреймворков и библиотек в веб-разработке — это не шутки. Хочешь хранить на сервере сессию пользователя? Вот тебе Flask-Login. Хочешь, чтобы состояние пользователя было доступно всем Vue-контроллерам? Вот тебе Vuex. И так далее.

Ещё я написал статью про алгоритм назначения получателей. Там про теорию графов, гамильтоновы циклы и поиск с возвратом:

Технологии (да, я перечислил вообще все): Python, Flask, Flask-CORS, Flask-Login, Passlib, SMTP, JavaScript, Vue.js, Vue Router, Vuex, Axios, HTML, AWS EC2, nginx, DNS Records, Certbot (Let’s Encrypt).

Исходники: фронтенд, бэкенд.

Сейчас я пока ни над чем не работаю, но у меня в планах один проект на Unreal Engine 4. Ничего серьёзного, просто проект для изучения движка, но я планирую периодически выпускать дневники разработки у себя в блоге.

#приходько_разработка