Игровой движок для первой игры: выбор начинающего соло-разработчика

Продолжаю рассказывать о своём начинании в геймдеве. Теперь настала пора выбрать игровой движок. И выбор пал на лучшее, что случалось в игровой индустрии — GameMaker. Далее в статье я попытаюсь объяснить своё решение.

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

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

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

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

В мире игровой индустрии только и разговоров что о движках. А их список вовсе не ограничивается известными всем Unity, Unreal Engine, GameMaker, Godot или Defold. В реальности их как-то неприлично много. Но зачем их столько? И на каком остановиться?

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

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

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

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

Безусловно, не ускользнут от нашего внимания и оговорки, которые противоречат этому списку, если таковые будут иметь место. Все эти извечные «но», в духе: «Да, вы можете создать игру, пользуясь лишь средствами визуального программирования, НО для чего-то более масштабного и серьёзного вам не избежать взаимодействия с кодом». Хотя относительно Unreal Engine я слышал и обратное: «Да, вы можете быть программистом от бога, НО, чтобы создать что-то более существенное, вам не обойтись без блюпринтов». Так это или нет, я узнаю как-нибудь потом. А пока это не имеет особого значения, т.к. на данный момент я не смотрю в сторону Unreal Engine.

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

Подсознательно я уже понимал, что буду разрабатывать на GameMaker, т.к. не сомневался, что смогу его освоить. К тому же, чуть ли не каждый блогер от мира программистов рассказывает, насколько он прост в изучении. Мне лишь оставалось убедиться, что он подходит для моих целей. Либо подстроиться… И я начал разбираться.

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

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

Слева у нас третьи Герои, справа — очевидно, ПК последней модели для игры в третьих Героев (принимайте в семью, так сказать). А если серьёзно, то, в силу отсутствия у меня опыта разработки, мне удобно смотреть на движки через призму редакторов карт. В моём понимании движки балансируют между двумя крайностями: комбо из готовых решений и сопутствующих ограничений (как в редакторе карт или уровней) и абсолютной свободой творчества (как если бы мы разрабатывали на голом языке программирования). Это два крайних состояния, когда среда разработки в одном случае ещё не стала движком, а в другом — уже перестала быть ею. А между ними всё то, что уже можно отнести к категории движков, или как-то на них похоже: начиная с фреймворков, заканчивая конструкторами вида RPG Maker.

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

Как всё это выглядит на деле? Из очевидного, движки предлагают нам полный набор библиотек и вспомогательных инструментов, в которых за тебя уже решён ряд сложных и разносторонних задач, что существенно облегчает разработку. Всё как под капотом у редакторов карт, где за тебя проделали всю работу, и осталось лишь собрать уровень или создать карту. При этом любые готовые решения могут накладывать определённые ограничения. Например, нередко движки заточены под конкретный жанр, в зависимости от того, каким технологиям в них уделяется наибольшее внимание. Будь то шутер, гоночный симулятор, платформер, файтинг, стратегия в реальном времени и т.д. Здесь мы тоже имеем очевидное сходство с редакторами карт. За одним лишь исключением: редакторы карт ориентированы только на одну конкретную игру, и не предполагают каких-то вольных отклонений.

А как дела обстоят с универсальными движками? Даже они могут ассоциироваться у нас с определённым жанром. Например, Unreal Engine. Первое, что приходит на ум — шутеры (как-никак именно из этого жанра он и возник).

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

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

Значит ли это, что я могу просто взять любой универсальный движок и использовать его для создания любой игры? Бытует мнение, что возможно всё. Даже сделать 3D-игру в GameMaker. Вопрос, какой ценой. В любом случае, с этим главное не перестараться. Конечно, если мы не ставим целью превратить буханку белого (или чёрного) хлеба в троллейбус.

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

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

Итак, в чём GameMaker силён? Безусловно, в 2D. Как я уже упоминал, я делаю 2D-игру. И с этой задачей GameMaker способен справиться без особых усилий прямо из коробки. Ему под силу работа со спрайтами, тайлами, уровнями, эффектами, шейдерами и пр. Он располагает обширным встроенным функционалом, который решает эти задачи легко и непринуждённо. Кроме того, в GameMaker мы изначально оперируем двухмерной системой координат, а не пытаемся изобразить 2D-игру в 3D-среде, что положительно сказывается на производительности игры. Важность этого не будет отрицать даже начинающий дэтээфер. Не говоря уже о прожённых экспертах, которым достаточно лишь беглого взгляда на игру, чтобы вынести свой неутешительный вердикт о её оптимизации.

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

По этой причине GameMaker отлично подходит для прототипирования. Что, в свою очередь, будет полезным для будущих проектов. А сами проекты делать на Unity или Unreal Engine, с привлечением профильных специалистов. В конце концов, общаться с ними мы будем уже на одном языке, ведь побочкой от знания какого-либо движка идёт способность разговаривать на программистском. Это упростит постановку задач кодерам.

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

Так есть ли у GameMaker сообщество? GameMaker не хайповый движок. В какой-то момент я задался вопросом, а не загибается ли он. Если посмотреть на хронологию упоминаний движка на том же YouTube, то видео по нему выпускаются там довольно редко. Его разработчики пилят его тихо, а разработчики игр, которые работают на нём, сильно не отсвечивают. Но если как следует зарыться в изучение тонкостей движка, вдруг осознаёшь, что движ есть. И он присутствует ровно в том объёме, который требуется на конкретный момент.

В перспективе я хочу, чтобы в моей игре появился сетевой режим. Как обстоят с этим дела в GameMaker? Полагаю, что не так радужно (no pun intended), как в Unreal Engine. А если быть честным, то на данный момент весь сетевой код придётся писать самостоятельно. Да, сейчас находится в разработке инструмент Rollback Multiplayer. Однако как было объявлено в конце 2023-го года, он был поставлен на паузу на достаточно неопределённый срок, или, если быть чуть более конкретным, до релиза новой среды выполнения движка (GMRT). К слову, новая среда выполнения с июля прошлого года уже доступна для открытого бета-тестирования, и сулит много интересного к середине 2025-го года. С тем, как я запрягаю, нужный мне инструментарий может подоспеть даже вполне себе вовремя. А может и не подоспеть. Однако учитывая недавнюю новость за ноябрь 2024-го года, работы по мультиплееру продвигаются очень даже бодро.

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

Не сказать, что состояние мультиплеера в GameMaker меня сильно воодушевляет. Я даже немного напрягся, когда мне стала открываться суровая правда. Особенно, когда на тебя холодным душем выливается вот такое мнение:

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

Остаётся лишь закусить удила и уходить с головой в работу. Ну, или пересмотреть приоритеты и, действительно, сперва довести до публикации в Steam какой-нибудь сингл-плеер в духе Grangerman.

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

Как я уже упомянул, работать над 3D-игрой в GameMaker будет не самым лучшим решением, потому что это просто неудобно. GameMaker предлагает нам не так много для разработки 3D-игр. Конечно, он располагает базовым функционалом для этого, но разработчику понадобится делать всю работу самостоятельно. Например, ты не можешь импортировать 3D-модель, т.к. необходимые типы файлов просто не поддерживаются движком. Если ты хочешь использовать файл типа .obj, то тебе понадобится написать скрипт, который будет интерпретировать этот файл, а также файлы текстур и пр., затем написать скрипты (или использовать сторонние) для отрисовки вершин и, в конечном итоге, отрисовки 3D-модели.

Кроме того, редактор комнат не поддерживает 3D, а потому предварительный просмотр получившегося результата недоступен. И, несмотря на то, что с каждым годом GameMaker предлагает нам всё больше решений для упрощения работы с 3D, этого всё ещё недостаточно. И осмелиться делать 3D-игру в GameMaker пока могут только те разработчики, которые действительно хорошо знакомы с движком, и им проще продолжать работать в нём, чем переключиться на какой-нибудь другой. Но даже в этом случае, это, скорее всего, будет лишь малый сегмент 3D-игр: например, игры в ретро-эстетике, наподобие Doom 1993-го года. Ведь вряд ли кому-то захочется ввязываться в реализацию супер-детализированной 3D-графики с тонной шейдеров и эффектов, потому что всё это пришлось бы делать своими руками.

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

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

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

Ещё один недостаток, на мой взгляд, это то, что Unreal Engine под завязку упакован всякой AAA-штукой под шутер. И чтобы сделать что-то другое, нужно произвести много действий по вырезанию всего лишнего и оптимизации состава модулей в движке. В частности, если ты работаешь над условным 2D-платформером, и хочешь, чтобы он запустился и работал на мобилке.

Потому, собственно, и не рекомендуется делать 2D на Unreal Engine. Да и с оптимизацией у такой игры дела будут обстоять не лучшим образом, если верить расхожему мнению. Это всё же трёхмерный движок, и при работе с двухмерной графикой будут задействоваться 3D-технологии в сочетании с фиксированной камерой.

Хотя и здесь бывают исключения. Например, когда у тебя псевдо-2D/2.5D, где используется двухмерный свет, карта нормалей для придания объёма 2D-спрайту, какое-то затенение. Подобные задачи хорошо решаются 3D-движками. Правда, Андрей Апанасик вряд ли такое оценит. Ему даже 3D в 2D не зашло. Живите теперь с этим знанием.

Но если делать точный, попиксельный платформер по типу Super Meatboy, то Unreal Engine для этой цели будет избыточен и неудобен.

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

Вот пока ссылка на неплохое сравнение Unreal Engine c GameMaker. Редко кто, рассказывая о движках, уходит сильно дальше маркетинговых материалов, а в этом видео автор опирается на личный опыт. Кстати, кто на опыте, можете подтвердить или опровергнуть его утверждения? Во всём ли он прав по части Unreal Engine? Или всё дело в “I have a programmer on the team”. Было бы интересно послушать. Я лишь могу пока только верить на слово.

Если в Unreal Engine разработчикам предоставляют практически всё прямо из коробки (визуальный скриптинг, сеть и пр.), то на Unity многого, скорее всего, может и не быть, пока не купишь это в ассете. В итоге на формирование инструментария под твои проекты может уйти несколько лет — пока не накопится какая-то вменяемая библиотека ассетов.

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

Ну, и как в случае с Unreal Engine, 2D реализован через 3D, со всеми вытекающими.

Язык программирования в Unity — C#. Он, в свою очередь, считается более сложным, чем любой встроенный скриптовый язык в некоторых других движках. А я сложностей не ищу.

Если бы так случилось, что GameMaker по какой-то причине прекратил своё существование или был заброшен, то, вероятно, я бы смотрел в сторону Godot. Ряд недостатков движка упоминаемых некоторыми блогерами больше связаны с привыканием к нему: интуитивность интерфейса, многоуровневая вложенность нодов, понимание самой сути нодов. Эти шероховатости больше затрагивают тех разработчиков, которые уже имеют опыт работы в других движках и пока ещё не могут абстрагироваться от него.

Однако меня отпугивает другое: то, что считается одним из его основных преимуществ — открытый исходный код. Мне не совсем понятно, кто является центром принятия решений в таких продуктах. Кто обеспечивает единство всей системы? Считается ли это нормальным, когда старая и новая версии движка практически несовместимы, и при переносе проекта из старой версии в новую, приходится править кучу ошибок в ранее работоспособных функциях по взаимодействию с API самого движка? Или я зря драматизирую, и от этой проблемы не застрахован ни один движок?

Также очень многие ругают встроенный физический движок Godot. Как утверждают, он был заброшен на полпути, потому что разработчика, который над ним трудился, наняла какая-то компания. Конечно, попутно рекомендуют альтернативу в виде плагинов Jolt для 3D и Box2D для 2D, но тем не менее. Ведь насколько я понимаю, при работе над оупенсорсным движком, никто не связан никакими обязательствами доводить курируемую им часть до конца, а значит подобные ситуации могут повторяться.

Ну, и последнее: для создания более или менее разнообразных игр, одним GDScript не ограничишься — все равно нужно знать какой-нибудь язык программирования. На странице сайта нам предоставляют для скачивания версию, которая поддерживает C#. А для работы с другими языками, и в частности C++, предлагается экспериментальное решение GDExtension. Что это означает для меня, как начинающего разработчика? Это означает ненулевую вероятность увязнуть в прокрастинации на подступах к новой для себя области знаний. А я не уверен смогу ли я обойтись одним лишь GDScript, делая свою игру в Godot.

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

По сути, на данном этапе уже можно приступать к разработке своей игры… Если только вы не пытаетесь вести блог. Вот уж где, действительно, пожиратель времени. Лично для себя я бы не стал обосновывать, почему я выбрал GameMaker. Я просто его выбрал. Но когда ведёшь публичный дневник, хочется выглядеть человеком разумным, а разумность предполагает аргументацию, для которой приходится активно копать в поисках информации, сравнивать. О чём я, к слову, не пожалел. Это оказалось полезным занятием.

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

Вишенкой на торте стала гифка игры Grangerman: Gabedan’s Prize, которая послужила для меня своего рода экзаменом. С помощью неё я хотел проверить своё утверждение выше о простоте разработки в GameMaker. Проверка оказалась успешной, хоть и ничего революционного я не создал. Да и код игры никуда не годится. Ведь когда ты хочешь сварганить что-то максимально простое, исключительно для демонстрации, во что даже никому не дашь поиграть, ты не будешь заморачиваться об архитектуре, удобстве кода, оптимизации. Ты не будешь писать скрипты и создавать собственные функции, которые помогли бы избежать дублей в коде, ты не будешь использовать списки, массивы или другие структуры данных, не понадобится тебе и автомат состояний (state machine). Ты просто будешь решать возникающие в моменте задачи для каждого конкретного объекта. С одной стороны, здорово, что такое возможно. С другой стороны, забавно, что говнокод тоже имеет право на существование. А в сочетании с вайб кодингом это просто ядерная сила.

В итоге я приобщился к разработке, но пока не преисполнился в своих познаниях о программировании. Мне ещё только предстоит написать сто триллионов миллиардов строк кода на триллионах и триллионах таких же планет, как наша Земля. Но начало положено, и я не собираюсь останавливаться.

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

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

Что касается моего блога, то дальше будет уже непосредственно об игре: разработка, поиск визуального стиля, прокачка сопутствующих навыков, и т.д. Контентных идей много, но всякий результат требует выполнения определённой работы, и порой не знаешь, за что хвататься. Хотелось бы уже стать кем-то наподобие профессионального сёрфера, который «оседлал» цунами задач, устремив свой взор на безмятежный горизонт, в то время как активность под доской неустанно бурлит. Пока что каждая задача лишь лупит в лицо хлёстким, косым ливнем. Прошу меня извинить за эту графоманию, но я не придумал лучшего способа описать желаемую эффективность, чем через эти метафоры.

Немного оправдался за своё длительное молчание, хоть в этом и не было необходимости. Многие, наверняка, закатывают глаза, когда видят такое. Просто хотел сказать, что в скором времени к своему контенту на DTF я добавлю Telegram-каналы, где я буду рассказывать о процессе разработки больше и чаще. Так называемые щитпосты, но о своей игре. На DTF всё же хотелось бы продолжать публиковать более глобальный охват происходящего. Ссылками на свои Telegram-каналы я пока не делюсь, поскольку ещё не настало время. Для начала не мешало бы их минимально наполнить.

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