Это дебютный и достаточно личный проект, созданный одним разработчиком, Тарой. Много лет она придумывала и формировала мир, персонажей и историю. Сегодня же игра наконец вышла в релиз на PC. Стоит, кстати, всего 269 рублей:
Кратко об игре: - Уникальная, созданная вручную визуальная эстетика; - Выбор и действия игрока влияют на финал; - Двойственность окружающего мира; - Неординарные головоломки; - Пронзительная история.
Немного подробней о сюжете:
Игра предлагает погрузиться в психологически глубокое путешествие, где реальность сплетается с иллюзиями, а внутренние демоны становятся буквально видимыми. Анку видит то, чего не видят другие: навязчивых красных чертей, хозяйничающих в головах окружающих ворон. Когда этих существ становится слишком много, Анку отправляется в путь, чтобы разобраться, что происходит, и найти способ освободить мир от этой напасти.
Однако никто не просит его о спасении. Может ли быть, что это лишь игра разума? Вдруг Анку ошибается? Или, наоборот, он — единственный, кто видит правду?..
Сделал тут игру в одно рыло небольшую игру в жанре настольной абстрактной стратегии, хотелось бы узнать на сколько заходит или не заходят людям такой тип игр.
Наиболее близкий и в тоже время отдаленный аналог это китайская настольная игра GO.
В игре можно захватывать территорию, атаковать элементы соперника, укреплять свои позиции, продумывать защиту и нападение.
elemental
Действие происходит на игровом поле, вы расставляете свои элементы, которые образуют энергетические связи с соседними элементами, чем больше связей тем сильнее ваш элементы.
Можно усиливать свои структуры добавляя количество связей и элементов в структуру, можно разрушать связи соперника ослабляя его структуры.
Цель игры захватить большее территории, чем у соперника, либо полностью лишить соперника всей его территории.
elemental
Особенности игры:
— Очень большое многообразие возможных тактических ситуаций на игровом поле и вариантов их решения;
— Не слишком долгие игровые сессии, в среднем новичок может пройти уровень за 6-10 минут;
— Очень простые правила игры, достаточно сыграть два-три раза и все становится понятно (правила есть в игре);
— 12 уровней в режиме игры против компьютера;
— Есть возможность играть вдвоем против друг друга на одном компьютере
Asemulator — удобный плагин для Aseprite, который проверяет анимацию вашего спрайта ещё до того, как она попадёт в игру.
Работает просто:
Настраиваем физику, камеру и фон, запускаем персонажа и смотрим, как он ведёт себя в игровой сцене. Нужные движения можно записать и сохранить в формате гифки.
В общем, если вы рисуете пиксельных персонажей в Aseprite, штука довольно полезная, к тому же бесплатная. Автор распространяет расширение по принципу Name Your Own Price (при желании можно поддержать монетой).
Думаю, кто-то из читателей знает, что я делаю мини игровую консоль. А для неё нужен игровой движок. В интернете я не нашел готовых удобных решений под мою задумку, да и копаться в чужом коде занятие не из самых приятных. Поэтому я решил сделать свою разработку.
Никогда ранее не разрабатывал движки, и хочу пойти по пути не изобретения велосипеда из своих "гениальных" идей, а взять лучшее из существующих решений и что САМОЕ ГЛАВНОЕ, разобраться, зачем и почему сделали именно так. Ну и плюс адаптировать под слабое железо.
Единственное, у меня есть своя основная концепция, которой я хочу придерживаться - хочется сделать так, чтобы не надо было в каждой новой игре плодить C++ классы для новых видов воинов, их особенных параметров и т.д.
Получается я хочу систему, которая имеет набор свойств и операций, из которых уже собираются разные игры.
Как сильно упрощенный пример - движок знает, что существуют координаты объекта и его размеры + есть С++ реализация операции столкновения. А уже конкретная игра решает, что делать при событии столкновения.
И да, можно было бы попросить нейросети написать за меня движок. И у меня уже есть 20 страничная концепция движка от ChatGPT на основе моей идеи. И даже некоторый рабочий код, который двигает воинов на экране по этой концепции.
Но бездумно использовать код от ИИ, особенно в таком проекте, по моему это плохая идея. Плюс ИИ как автонабор текста улетает вперед и уже есть 1000 строк кода, который я ваще не понимаю. А я вот только переварил что такое Entity ID и таблицы свойств.
Поэтому я пошагово разбираю каждый кирпичик движка и составляю сначала архитектурный конспект, потом уже перехожу к коду и классам.
И у меня вопрос - кому нибудь было бы интересно читать итеративный процесс разработки моего движка со всеми пояснениями?
Если вы делали игру хотя бы несколько месяцев, наверняка знаете это чувство: смотришь на неё и уже не понимаешь, хорошо получилось или просто глаз «замылился».
Причём проблема часто не в графике, не в бюджете и даже не в количестве багов. Иногда игрок закрывает игру через несколько минут, а разработчик искренне не понимает почему.
Вот три вещи, которые, на мой взгляд, стоит проверить до релиза.
1. Разработчик слишком хорошо знает свою игру
Это звучит странно, но знание игры может мешать её тестировать.
Вы знаете, куда нажать. Помните, что было сказано пять минут назад. Интуитивно понимаете, где искать нужный предмет.
Игрок ничего этого не знает.
У меня был простой пример: кнопка «Продолжить» на одном из экранов настолько сливалась с фоном, что её постоянно пропускали. Я же смотрела на неё десятки раз и даже не замечала проблемы — потому что всегда знала, где она находится.
Поэтому иногда достаточно просто посадить человека за игру и молча посмотреть, что он делает. Не объяснять. Не подсказывать. Не говорить: «Ну тут же понятно». Именно в этот момент обычно находится много интересного.
2. «Друг сказал, что игра классная» — это ещё не тестирование
Друзья — плохие тестировщики не потому, что они плохие люди. Просто им зачастую неловко сказать:
— Я запутался. — Мне было скучно. — Я не понял, что от меня хотят. — Я закрыл игру через десять минут.
Однажды мне сказали: «Игра огонь». Позже выяснилось, что человек даже не дошёл до первого босса — просто «что-то не зашло».
И это нормальная реакция. Не каждая игра обязана нравиться каждому. Но для разработчика гораздо полезнее услышать честное «на третьей минуте мне стало скучно», чем вежливое «ну, прикольно».
3. Некоторые проблемы нужно обнаружить тогда, когда их ещё можно исправить
За день до релиза внезапно выяснить, что игроки не понимают механику, не видят важную кнопку или бросают игру на первом боссе — удовольствие сомнительное.
Особенно обидно, когда в проект вложено много деталей: отсылки, скрытые смыслы, необычная подача. Разработчик видит всю картину, а игрок может просто пропустить половину текста и уйти, потому что не понял, куда идти дальше.
И нет, это не обязательно означает, что игрок «невнимательный». Если одна и та же проблема возникает у нескольких людей, возможно, стоит посмотреть на неё со стороны игры.
Главная мысль простая: игру желательно показывать людям раньше, чем вам психологически хочется.
Сначала нескольким людям, потом после исправлений — ещё нескольким. И желательно тем, кто не знает вас лично и не будет переживать, что честным отзывом разрушит вашу мечту.
Иногда десять минут наблюдения за тем, как человек впервые запускает вашу игру, дают больше полезной информации, чем ещё неделя самостоятельного тестирования.
А у разработчиков здесь есть такие истории? Когда тестер или обычный игрок нашёл проблему, которую вы сами в упор не замечали?
Часто думаю о том, что поезд уже ушёл и я опоздала со входом в индустрию. Да, 10 лет назад было куда проще устроиться: не было этих 9 кругов ада собеседований, тестовых на 60 часов, таких требований и конкуренции. Но и обучиться тогда было куда сложнее.
А если мне сейчас отказывают, значит, я действительно пока не готова. Значит, нужно продолжать учиться, становиться лучше и пробовать снова.
