NO PAIN NO GAME: THE VIDEOGAME (Дневник разработки. #2)

  Привет, ребза!

  Некоторое время назад мы начали делать свою собственную видеоигру по мотивам шоу No Pain No Game. Кто-то этому факту порадовался, кто-то остался равнодушен, а кто-то отнёсся весьма скептически, аргументировав это тем, что и дело это сложное, и шоу не настолько популярно, чтобы делать о нём игру.

  На последний аргумент я могу ответить сразу следующим образом – игра No Pain No Game не рассчитана исключительно на аудиторию шоу. Мало того –
она не рассчитана и на аудиторию моего канала и канала моего со-ведущего –
Станислава Андреевича. Наша игра – это нечто большее. Нечто, что будет понятно любому геймеру, а особенно хоть немного увлекающемуся коллекционированием видеоигр и ценящему физические копии игр, а вот таких людей по всему миру уже действительно невероятно много.

  Наша игра рассчитана на взрослых людей, но в неё можно будет играть с детьми. Она рассчитана на опытных геймеров, но в неё сможет играть абсолютно любой. В конце концов она рассчитана на любителей «компьютерных
мордобоев», но в неё смогут играть фанаты многих других видеоигровых жанров. И да, у нас большие амбиции, которые, надеюсь, оправдаются, а посему представляю вашему вниманию продолжение дневника разработки нашей игры NO PAIN NO GAME: The Videogame, и если вы вдруг не понимаете о чём речь, вот по этой ссылке вы легко найдёте первую часть: https://boosty.to/justevgen/posts/73aa0a5f-6a64-448e-8b18-1bfacb98281b

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

- Продвигается, но очень медленно.

Действительно, работа над игрой идёт, и, мне кажется, не было ни дня, когда бы она останавливалась – хотя бы какая-то новая мысль, хотя бы какое-то исправление, хотя бы добавление пары пикселей, но каждый день наша игра становится чуть ближе к своему появлению на свет, хоть об этом говорить ещё крайне рано. Да, работа идёт, но очень медленно, и по большей части потому,
что нас по-прежнему очень мало. За пару месяцев к разработке игры присоединилось несколько человек, но пока что я могу показать труд лишь одного из них (это касается именно графической части) – другие либо ещё не успели что-то сделать и я представлю их позже, либо начали помогать, но быстро поняли, что это действительно большая работа с сомнительной перспективой заработать (сейчас мы обладаем только деньгами, которые собраны благодаря вам на Boosty, и они пока что уходят на поиск опытного пиксельного художника или художника-аниматора, но об этом я расскажу чуть позже). Кроме того, некоторых людей отпугивает отсутствие «свободы действий». Я имею ввиду то, что художники, желающие присоединиться к проекту, как любые другие художники, имеют своё видение того, как этот проект должен выглядеть, и если мотивом поработать над игрой являются не деньги, то это, как минимум, желание творчески реализоваться, что становится не очень простой задачей, учитывая уже формирующийся стиль игры и необходимость так или иначе под него подстраиваться. Некоторые на это способны, понимая, что у любого проекта должен быть художественный руководитель, а некоторые нет, отчего вспоминается известная басня «Лебедь, рак и щука»:

  Итак, из тех, кто уже плотно влился в нашу небольшую команду, и с кем мы, как мне кажется, отлично сработались, я могу представить вам Андрея Уточкина – постоянного зрителя канала, и вообще человека, который уже не раз помогал развитию канала своими активными действиями!

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

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

ВНИМАНИЕ-ВНИМАНИЕ! Если ты способен таким же образом обрисовывать скетчи пиксельной графикой, имея один-два готовых пиксельных кадра, в качестве
примера – свяжись со мной по почте hard-vision@mail.ru - ты нам необходим!

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

Давайте я сейчас немного продолжу тему художеств и художников, и расскажу, что ещё мы делаем в этом направлении.

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

Рисовал я что-то вроде вот таких простеньких вещиц:

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

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

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

Ну и я считаю, что мы с Shiru8bit поступили правильно, когда решили добавить главным героям сумки, т.к. это, во-первых, намекает на то, что мы не просто так передвигаемся по России, а именно в поисках игр, и сумки нам нужны хотя бы для того, чтобы игры было куда складывать. И плюс ко всему, сумка – отличный элемент, который не только добавляет полноты образам, но и добавляет динамики в моменты движения. А кроме того (но это пока не точно) – сумкой можно и отлично ударить по голове при необходимости!

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

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

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

  Результаты оказались, честно говоря, финансово не утешительными, но руки мы не опускаем, и, конечно, будем делать всё, чтобы справляться и дальше. И спасибо огромное всем, кто нам в этом помогает!

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

Первый вариант прислал наш соотечественник Joe Vondayl, и, надо сказать, что
хоть мы посчитали, что Joe не совсем попал в те образы, которые мы хотели бы видеть в игре, но его труд был не напрасным – именно нарисованные им ноги и кроссовки у Станислава Андреевича мы решили, чуть-чуть доработав, использовать в наших спрайтах.

  А ещё у Joe мне понравилась проработка рук, после чего я решил и в наших спрайтах руки чуть-чуть подправить.

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

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

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

Композитором в нашей игре выступает Globian. Хотите верьте, хотите нет - это во первых очень талантливый композитор, а во вторых - очень опытный. Его музыку слышали тысячи, а может и сотни тысяч людей, но, правда, в несколько иной, не игровой области. Когда-нибудь я всё объясню, но не сейчас. Просто поверьте - с музыкой в игре всё будет очень хорошо!

  И, что хотелось бы поведать - это то, что началась работа над двумя анимационными роликами. Один из них будет использован в качестве промоматериала для нашей будущей игры, а второй в качестве заставки к игре. Я так же очень надеюсь, что уже к следующей части нашего дневника я вам смогу представить и человека, который нам в этом деле помогает (а он, чёрт возьми, хорош в своём деле!), и какой-то маленький фрагмент его труда! А пока вот для истории сохраню тут кадр с черновой раскадровки, который был сделан чисто для того, что бы объяснить концепцию заставки:

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

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

  Приветствую читателей наших дневников!

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

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

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

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

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

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

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

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

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

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

В то время одним из немногих компонентов, который можно было выделить в легко переиспользуемый код, была звуковая часть, т.е. звуковые движки (тогда известные просто как 'звуковой код', 'процедура' или 'драйвер'), остальное же почти всегда писалось каждый раз заново. Для придирчивых читателей упомяну, что были, конечно, и исключения (Z-Machine аж 1979 года, Freescape/3D Construction Kit 1991-го, некоторые другие ‘конструкторы игр’), но в целом в коммерческой разработке это имело малое распространение.

Значительный вклад в дело формирования представления об игровых движках как о переиспользуемом коде, не зависящем от конкретной игры, внесла небезызвестная id Software со своими небезызвестными играми Wolfenstein 3D, Doom и Quake. Движки Wolf'а, Doom'а и первых двух частей Quake использовались в десятке игр каждый. В конце 90-х вышли игры Quake III и Unreal, и именно они и их технология (id Tech 3 и первый Unreal Engine) окончательно сформировали современное понимание движка - технологическое решение, специально разработанное для последующего лицензирования сторонним разработчикам, которые могли бы создавать на них игры разного содержания и жанров.

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

  Примерно тогда же взяли старт и такие движки, как GameMaker, ориентированный на простые двухмерные игры, Macromedia (позже Adobe) Flash, ориентированный на легковесную двухмерную векторную графику и анимацию для распространения через тогдашний медленный телефонно-модемный интернет. Их отличительными особенностями стала доступность энтузиастам, а также уменьшение порога вхождения - визуальные средства разработки, требующие значительно меньше программирования, чем в движках прошлых лет (которые по сути были просто исходным кодом и набором утилит для командной строки). Тогда же начали появляться и первые широко доступные 3D движки, например, ныне забытый Ogre 3D, а к середине 2000-х подтянулись и такие нынешние столпы, как Unity и Construct. Стало возможным использование универсальных движков на игровых консолях, где в силу более ограниченных мощностей ранее требовалась более тонкая оптимизация кода под нужды конкретных игр.

  И вот мы добрались наконец до момента зарождения совета не писать свой движок. Если до начала 2000-х доступной альтернативы просто не было, и каждому разработчику приходилось так или иначе писать свой собственный код, то к середине 2000-х появилось и возмужало множество готовых решений. Одновременно с этим сложность устройства игр выросла на порядки - новичку-одиночке ещё как-то по силам написать с нуля простой двухмерный платформер, но разработать с нуля современную тому периоду трёхмерную игру со сложной системой отрисовки графики, физикой, скриптами и сложными инструментами стало если ещё и возможно, то очень, очень трудоёмко. Многие энтузиасты периода 2000-2005 годов по несколько лет писали и переписывали свои собственные движки, пытаясь догнать технический прогресс, так и не приступая к созданию собственно игры. Тогда и начал хождение совет - хочешь делать игру, возьми готовый движок и делай игру. С тех пор сложность устройства игр возросла ещё многократно, и для того, кто пытается создать современную 3D игру этот совет становится только актуальнее. Сейчас написать игровой движок современного уровня, тем более универсальный, предназначенный для использования широким кругом лиц разного уровня компетенции - задача очень высокой сложности даже для команды самых опытных профессионалов.

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

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

  Во-вторых, нам нужен движок для конкретного, довольно специфического жанра. Unreal Engine, Unity, Construct 2 и GameMaker не вполне полезны для наших целей. По большому счёту они сыграли бы роль межплатформенной прослойки, но сам движок игры всё равно пришлось бы реализовывать внутри них собственными силами. Или взять готовый, что вовлекает ещё одно ненадёжное решение от третьей стороны. По сути выбор, который мог бы сэкономить силы на разработке собственного движка, ограничен единственным вариантом, OpenBOR - специализированным движком для игр жанра beat'em up.

  В-третьих, наш проект полон довольно уникальных задумок. Это не beat'em up в чистом виде, и очень вероятно, что возможностей OpenBOR нам не хватило бы для реализации всего задуманного, а нашей целью является создание именно такой игры, какую мы хотим сделать, а не просто какой-нибудь. Дополнить же чужое существующее решение необходимыми, не предусмотренными в нём изначально возможностями довольно сложно даже для его оригинальных авторов, а для простых пользователей технологии это по трудозатратам (разобраться в огромном чужом проекте и исправить его) сравнимо с созданием собственной альтернативы. К тому же, готовый движок создаёт ощущение геймплейного сходства между играми, сделанными на нём, и избежать этого довольно сложно, и я не думаю, что кто-то хотел увидеть именно ещё-одну-игру-на-OpenBOR.

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

  Правильный ли это выбор? Как бы поступили профессионалы? Достаточно посмотреть на примеры аналогичных проектов:

Streets of Rage 4 - свой оригинальный движок

TMNT: Shredder's Revenge - свой оригинальный движок (низкий уровень на FNA)

Final Vendetta - Unity

  Также можно упомянуть интересный пример со свежайшим проектом в другом жанре, но в том же формате ретро-игры для современных платформ, от создателя Blazing Chrome - Vengeful Guardian Moonrider. Эта игра изначально разработана на движке Construct 2. Однако, вставки с псевдо-3D в ней, выходящие за рамки типичных проектов на этом движке, реализованы вне него, в виде отдельной внешней программы. Более того, так как Construct 2 довольно ресурсоёмкий, при издании игры на Nintendo Switch она была полностью переписана заново на C++, чтобы обеспечить стабильные 60 FPS.

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

  И теперь несколько слов о собственно нашем движке, носящем название EvgEngine. Он пишется на C++, платформозависимая часть реализована на SDL2 и ряде других open source библиотек, что обеспечивает хорошую кроссплатформенность. Рендер графики у нас полностью программный, в виде растрового буфера низкого пиксельного разрешения - мы полностью контролируем каждый пиксель, SDL просто выводит итоговое изображение на экран. Подобным же образом устроены эмуляторы всех 8-16 битных платформ. Это позволяет нам реализовывать совершенно любые графические эффекты, максимально аутентичные выбранной эпохе, и обеспечить переносимость на другие платформы, не привязываясь к возможностям конкретных графических библиотек.

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

Это снова я, Евген, и, надеюсь, что вам было интересно почитать очередную часть нашего дневника, и, возможно, вы стали чуть ближе к пониманию того, как ведётся работа над нашей игрой. Но было бы не справедливо не показать вам больше именно визуальных материалов, потому держите ещё один скриншот из нашей NO PAIN NO GAME: The Videogame! Главное помните - изображение не является финальным. Всё это разработка, и всё ещё может поменяться!

  И на этом всё на сегодня, а я напомню, что если у вас есть возможность и желание поддержать игру финансово, вы можете это сделать в соответствующем разделе тут на Boosty: https://boosty.to/justevgen/single-payment/donation/273335?share=target_link

А мы, на последок, скажем ОГРОМНОЕ СПАСИБО уже поддержавшим наш проект: