Привет. ‎Расскажу‏ ‎про ‎то, ‎как ‎устроен ‎код‏ ‎в ‎проекте,‏ ‎чего‏ ‎придерживался, ‎что ‎пришлось‏ ‎менять. ‎Тут‏ ‎есть, ‎о ‎чем ‎поговорить.‏ ‎Я‏ ‎поделюсь ‎своим‏ ‎опытом.

Разграничения

Как ‎уже‏ ‎писал ‎в ‎предыдущей ‎статье, ‎пространства‏ ‎имен‏ ‎– ‎это‏ ‎отличный ‎способ‏ ‎разграничить ‎островки ‎игровой ‎логики ‎в‏ ‎проекте‏ ‎в‏ ‎крупном ‎масштабе.‏ ‎На ‎более‏ ‎низком ‎уровне‏ ‎идет‏ ‎разбиение ‎на‏ ‎классы. ‎Помните, ‎Божественный ‎объект ‎–‏ ‎это ‎антипаттерн.‏ ‎К‏ ‎слову, ‎один ‎заказчик‏ ‎немного ‎разбирался‏ ‎в ‎программировании ‎и ‎всерьез‏ ‎хотел,‏ ‎чтобы ‎мы‏ ‎делали ‎именно‏ ‎божественные ‎объекты ‎в ‎играх.

Тогда ‎еще‏ ‎совет.‏ ‎Вы ‎–‏ ‎специалист ‎своего‏ ‎дела, ‎который ‎знает ‎технические ‎подробности‏ ‎реализации‏ ‎проекта,‏ ‎и ‎это‏ ‎ваша ‎обязанность‏ ‎– ‎настоять‏ ‎на‏ ‎правильном ‎обоснованном‏ ‎техническом ‎решении.

Альманах

Не ‎забываем ‎про ‎абстракцию.‏ ‎Если ‎того‏ ‎требует‏ ‎ситуация, ‎сначала ‎делаем‏ ‎абстрактный ‎класс‏ ‎или ‎интерфейс, ‎потом ‎более‏ ‎конкретную‏ ‎реализацию. ‎Не‏ ‎беспокойтесь, ‎никогда‏ ‎не ‎поздно ‎начать ‎извлекать ‎методы‏ ‎и‏ ‎выделять ‎классы.

Интерфейс‏ ‎или ‎абстрактный‏ ‎класс? ‎Абстрактный ‎класс ‎уместней ‎использовать‏ ‎при‏ ‎очевидной‏ ‎общности ‎наследников,‏ ‎интерфейс ‎же‏ ‎– ‎лишь‏ ‎модель‏ ‎поведения, ‎которую‏ ‎могут ‎реализовать ‎объекты, ‎не ‎имеющие‏ ‎ничего ‎общего‏ ‎между‏ ‎собой.

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

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

Только ‎спустя‏ ‎пару ‎лет‏ ‎практики ‎программирования ‎начинаешь ‎понимать ‎принципы‏ ‎SOLID‏ ‎и‏ ‎ООП ‎по-настоящему.‏ ‎Не ‎просто‏ ‎так ‎в‏ ‎каждом‏ ‎ролике, ‎в‏ ‎каждой ‎статье ‎или ‎интервью ‎с‏ ‎разработчиками ‎повторяется‏ ‎как‏ ‎мантра: ‎каждая ‎механика‏ ‎– ‎это‏ ‎отдельный ‎островок, ‎который ‎работает‏ ‎независимо‏ ‎от ‎других;‏ ‎удаляя ‎один‏ ‎компонент, ‎другой ‎не ‎должен ‎сломаться…‏ ‎Старайтесь‏ ‎придерживаться ‎принципов‏ ‎программирования, ‎это‏ ‎в ‎любом ‎случае ‎дешевле ‎обойдется,‏ ‎чем‏ ‎потом‏ ‎переделывать ‎все,‏ ‎поправляя ‎одно,‏ ‎ломая ‎тем‏ ‎самым‏ ‎другое. ‎

Совет.‏ ‎Не ‎переставайте ‎менять ‎именование ‎полей,‏ ‎методов ‎и‏ ‎классов‏ ‎до ‎тех ‎пор,‏ ‎пока ‎не‏ ‎станет ‎максимально ‎удовлетворять ‎вас.‏ ‎Именование‏ ‎должно ‎лаконично‏ ‎передавать ‎суть‏ ‎и ‎все. ‎Классы ‎именуются ‎как‏ ‎имя‏ ‎существительное, ‎методы‏ ‎как ‎глагол.‏ ‎События ‎привычно ‎писать ‎со ‎слова‏ ‎On‏ ‎(OnHit,‏ ‎OnLoaded, ‎OnError),‏ ‎но ‎методы,‏ ‎которые ‎на‏ ‎них‏ ‎подписываются, ‎должны‏ ‎передавать ‎свою ‎суть ‎(GetDamage, ‎Unfade,‏ ‎SetDefaultValues). ‎Помните,‏ ‎большую‏ ‎часть ‎времени ‎вы‏ ‎прежде ‎всего‏ ‎читаете ‎код, ‎нежели ‎непосредственно‏ ‎пишите‏ ‎его. ‎Решиться‏ ‎на ‎изменения‏ ‎в ‎коде ‎гораздо ‎легче, ‎если‏ ‎хорошо‏ ‎владеть ‎IDE‏ ‎(например, ‎переименование‏ ‎и ‎извлечение ‎метода).

Совет. ‎Используйте ‎ключевое‏ ‎слово‏ ‎field‏ ‎в ‎атрибутах,‏ ‎оно ‎позволяет‏ ‎воспринимать ‎свойства‏ ‎как‏ ‎поля, ‎отображая‏ ‎их ‎в ‎инспекторе, ‎но ‎все‏ ‎еще ‎инкапсулировать‏ ‎данные.‏ ‎Не ‎пренебрегайте ‎ограничением‏ ‎доступа ‎к‏ ‎данным. ‎Этот ‎трюк ‎сокращает‏ ‎количество‏ ‎строчек ‎в‏ ‎2 ‎раза,‏ ‎Карл! ‎Этот ‎десяток ‎строк ‎мог‏ ‎выглядеть‏ ‎как ‎20‏ ‎строк.

Спаун ‎противников

Тут‏ ‎вроде ‎все ‎просто. ‎Враги ‎появляются‏ ‎по‏ ‎волнам.‏ ‎Волны, ‎количество‏ ‎противников ‎и‏ ‎период ‎их‏ ‎создания‏ ‎во ‎время‏ ‎волны ‎определяется ‎в ‎SpawnerData. ‎Они‏ ‎могут ‎появляться‏ ‎на‏ ‎протяжении ‎всей ‎волны,‏ ‎могут ‎в‏ ‎начале ‎волны ‎или ‎только‏ ‎в‏ ‎конце; ‎по‏ ‎одному ‎в‏ ‎секунду ‎или ‎сразу ‎скопом.

С ‎самого‏ ‎начала‏ ‎я ‎не‏ ‎до ‎конца‏ ‎продумал ‎как ‎именно ‎будут ‎появляться‏ ‎противники‏ ‎на‏ ‎арене, ‎а‏ ‎я ‎очень‏ ‎хотел ‎внести‏ ‎какую-то‏ ‎оригинальность ‎в‏ ‎моей ‎игре. ‎Поэтому ‎мне ‎пришлось‏ ‎переопределить ‎архитектуру‏ ‎этой‏ ‎части ‎кода. ‎Теперь‏ ‎точка ‎появления‏ ‎и ‎логика ‎этого ‎события‏ ‎делегируются‏ ‎в ‎отдельный‏ ‎класс ‎SpawnDealer.‏ ‎Он ‎стал ‎отвечать ‎за ‎то,‏ ‎как‏ ‎именно ‎и‏ ‎где ‎появится‏ ‎противник. ‎Например, ‎арахниды ‎появляются ‎с‏ ‎помощью‏ ‎червя‏ ‎Нидуса, ‎если‏ ‎такого ‎нет‏ ‎на ‎сцене,‏ ‎сначала‏ ‎появится ‎червь,‏ ‎проиграется ‎анимация, ‎а ‎уж ‎потом‏ ‎появится ‎противник‏ ‎из‏ ‎него. ‎Духи ‎появляются‏ ‎только ‎в‏ ‎темных ‎участках ‎арены, ‎а‏ ‎демоны‏ ‎в ‎точках,‏ ‎где ‎есть‏ ‎огонь ‎(факел, ‎костер, ‎пожар). ‎Некоторые‏ ‎противники‏ ‎появляются ‎с‏ ‎помощью ‎молний,‏ ‎только ‎на ‎участках ‎арены ‎под‏ ‎открытым‏ ‎небом.

Красными‏ ‎точками ‎отмечены‏ ‎темные ‎места‏ ‎для ‎появления‏ ‎Духов,‏ ‎а ‎белыми‏ ‎точки ‎под ‎открытым ‎небом ‎для‏ ‎создания ‎молнии‏ ‎и‏ ‎спауна ‎противников ‎из‏ ‎них.

Урон ‎и‏ ‎здоровье

Эту ‎часть ‎игры ‎тоже‏ ‎пришлось‏ ‎переписывать ‎после‏ ‎первых ‎попыток.‏ ‎Итогом ‎стали ‎абстрактный ‎класс ‎Health‏ ‎и‏ ‎его ‎наследники‏ ‎HealthPart ‎и‏ ‎HealthParent. ‎Предполагалось, ‎что ‎попадание ‎в‏ ‎разные‏ ‎части‏ ‎тела ‎(HealthPart)‏ ‎дает ‎множитель‏ ‎на ‎получаемый‏ ‎урон,‏ ‎передавая ‎значения‏ ‎на ‎HealthParent, ‎который ‎у ‎противника‏ ‎есть ‎в‏ ‎единственном‏ ‎экземпляре. ‎Это ‎решение‏ ‎из ‎общей‏ ‎папки ‎с ‎кодовой ‎базой,‏ ‎на‏ ‎самом ‎деле‏ ‎в ‎проекте‏ ‎используется ‎только ‎HealthParent.

Так ‎как ‎в‏ ‎игре‏ ‎есть ‎стихийный‏ ‎урон ‎и‏ ‎различные ‎мета-данные ‎нанесения ‎урона ‎(с‏ ‎какой‏ ‎стороны‏ ‎прилетел ‎удар,‏ ‎точка ‎удара,‏ ‎физическая ‎сила‏ ‎удара,‏ ‎префабы ‎попадания),‏ ‎я ‎сделал ‎структуру ‎HitData, ‎а‏ ‎также ‎DamageDealer‏ ‎для‏ ‎удобства ‎заполнения ‎этих‏ ‎данных.

Совет. ‎Старайтесь‏ ‎подписываться ‎на ‎события ‎(если‏ ‎это‏ ‎не ‎дочерние‏ ‎компоненты), ‎нежели‏ ‎напрямую ‎завязывать ‎внешние ‎объекты ‎между‏ ‎собой.‏ ‎Это ‎уменьшит‏ ‎связность ‎проекта,‏ ‎позволит ‎убирать ‎или ‎добавлять ‎что-либо‏ ‎на‏ ‎сцену,‏ ‎не ‎ломаю‏ ‎остальное.

Завершение

Понимаешь ‎диаграммы‏ ‎классов? ‎Что-то‏ ‎стоит‏ ‎поправить? ‎Что‏ ‎думаешь? ‎Есть ‎польза ‎от ‎написанного?‏ ‎Критикуй, ‎пиши,‏ ‎прочтем.‏ ‎Я ‎очень ‎надеюсь,‏ ‎что ‎делаю‏ ‎какое-то ‎полезное ‎дело, ‎в‏ ‎надежде‏ ‎повысить ‎свою‏ ‎и ‎вашу‏ ‎грамотность ‎в ‎написании ‎кода.

Разработчик | Проект | YouTube | e-mail | Поддержка

Привет, ‎коллеги.‏ ‎Пора ‎переходить ‎от ‎описания ‎девлога‏ ‎к ‎описанию‏ ‎проекта.‏ ‎В ‎этой ‎статье‏ ‎я ‎расскажу‏ ‎про ‎структуру ‎проекта:

• Порядок ‎файлов‏ ‎и‏ ‎папок, ‎почему‏ ‎именно ‎так,‏ ‎какие ‎еще ‎варианты ‎бывают
• Общая ‎архитектура‏ ‎кода
• Советы‏ ‎по ‎организации‏ ‎кода ‎в‏ ‎проектах
• Порядок ‎инициализации

Файловый ‎порядок

В ‎целом ‎мы‏ ‎на‏ ‎работе‏ ‎использовали ‎два‏ ‎подхода ‎по‏ ‎организации ‎файлов‏ ‎в‏ ‎проекте: ‎сортировать‏ ‎в ‎папки ‎по ‎типу ‎файлов‏ ‎или ‎по‏ ‎смысловой‏ ‎общности ‎(аля ‎ассет‏ ‎или ‎игровая‏ ‎механика). ‎Все ‎скрипты ‎лежат‏ ‎в‏ ‎одной ‎папе,‏ ‎а ‎все‏ ‎текстуры ‎в ‎другой? ‎Это ‎сортировка‏ ‎по‏ ‎типу ‎файлов.‏ ‎Если ‎же‏ ‎все ‎текстуры, ‎материалы, ‎анимации ‎и‏ ‎скрипты‏ ‎относятся‏ ‎к ‎одной‏ ‎игровой ‎механике‏ ‎и ‎лежат‏ ‎в‏ ‎папке ‎с‏ ‎игровой ‎механикой, ‎то ‎это ‎второй‏ ‎тип ‎порядка‏ ‎в‏ ‎проекте.

Долгое ‎время ‎мы‏ ‎придерживались ‎первого‏ ‎варианта, ‎но ‎на ‎практике‏ ‎рано‏ ‎или ‎поздно‏ ‎приходишь ‎к‏ ‎следующим ‎выводам:

• В ‎процессе ‎разработки ‎ты‏ ‎работаешь‏ ‎не ‎с‏ ‎файлами ‎как‏ ‎таковыми, ‎а ‎с ‎игровой ‎механикой‏ ‎(с‏ ‎файлами,‏ ‎которые ‎к‏ ‎ней ‎относятся).‏ ‎Жутко ‎неудобно‏ ‎искать‏ ‎скрипт ‎в‏ ‎одной ‎папке, ‎править ‎шейдер ‎в‏ ‎другой ‎папке,‏ ‎далеко‏ ‎от ‎первой. ‎Ты‏ ‎вроде ‎работаешь‏ ‎над ‎одним ‎кирпичиком ‎проекта‏ ‎(над‏ ‎одной ‎игровой‏ ‎механикой), ‎а‏ ‎файлы ‎раскиданы ‎по ‎всему ‎проекту.‏ ‎Это‏ ‎жутко ‎неудобно.
• Если‏ ‎ты ‎скачиваешь‏ ‎готовые ‎ассеты ‎с ‎Ассет ‎Стора,‏ ‎то‏ ‎они‏ ‎скачиваются ‎именно‏ ‎в ‎выше‏ ‎изложенном ‎виде‏ ‎–‏ ‎отдельная ‎папка‏ ‎игровой ‎механики, ‎внутри ‎которой ‎все,‏ ‎что ‎к‏ ‎ней‏ ‎относится: ‎скрипты, ‎текстуры,‏ ‎анимации, ‎звуки.
• Так‏ ‎и ‎так ‎ты ‎используешь‏ ‎оба‏ ‎подхода, ‎но‏ ‎в ‎разных‏ ‎масштабах. ‎Глобально ‎папки ‎сформированы ‎по‏ ‎игровым‏ ‎механикам, ‎но‏ ‎внутри ‎этих‏ ‎папок ‎есть ‎папки ‎Scripts, ‎Sources,‏ ‎Prefabs.

Совет.‏ ‎С‏ ‎самого ‎начала‏ ‎и ‎до‏ ‎конца ‎работы‏ ‎на‏ ‎игрой ‎придерживайтесь‏ ‎какого-то ‎порядка ‎и ‎не ‎переставайте‏ ‎его ‎соблюдать.‏ ‎Несортированные‏ ‎файлы ‎и ‎непродуманная‏ ‎архитектура ‎накапливается‏ ‎и ‎с ‎каждым ‎разом‏ ‎и‏ ‎все ‎больше‏ ‎усложняет ‎процесс‏ ‎разработки. ‎Тебе ‎попросту ‎больше ‎не‏ ‎хочется‏ ‎в ‎этом‏ ‎всем ‎разбираться.‏ ‎Книга ‎Роберта ‎Мартина ‎«Чистый ‎код»,‏ ‎как‏ ‎мне‏ ‎показалось, ‎прежде‏ ‎всего ‎учит‏ ‎придерживаться ‎порядка.‏ ‎А‏ ‎какой ‎именно‏ ‎порядок, ‎это ‎уже ‎вам ‎решать.‏ ‎Придерживайтесь.

Структура ‎кода

Все‏ ‎Unity-проекты‏ ‎– ‎это ‎монолитное‏ ‎приложение. Внутри ‎же‏ ‎мы ‎можем ‎использовать ‎различные‏ ‎подходы,‏ ‎например, ‎MVC и‏ ‎его ‎разновидности‏ ‎или ‎ECS (в ‎Unity ‎встроен ‎DOTS).

Совет.‏ ‎Не‏ ‎забывайте ‎пользоваться‏ ‎пространствами ‎имен, очень‏ ‎помогает ‎организовать ‎работу ‎кода. ‎Еще‏ ‎вариант,‏ ‎к‏ ‎которому ‎я‏ ‎не ‎склонился‏ ‎– ‎это‏ ‎AssemblyDefinition. Как‏ ‎по ‎мне,‏ ‎подобный ‎способ ‎неудобен ‎из-за ‎чувствительной‏ ‎настройки. ‎А‏ ‎еще‏ ‎ты ‎можешь ‎долгое‏ ‎время ‎не‏ ‎понимать ‎почему ‎не ‎компилируется‏ ‎код,‏ ‎и ‎кто‏ ‎на ‎кого‏ ‎должен ‎ссылаться. ‎Звучит ‎как ‎отговорка,‏ ‎но‏ ‎я ‎не‏ ‎пришел ‎к‏ ‎этому ‎способу, ‎просто ‎использую ‎пространства‏ ‎имен.

В‏ ‎проекте‏ ‎есть ‎общее‏ ‎пространство ‎имен‏ ‎IndieBroGames, ‎внутри‏ ‎которого‏ ‎есть ‎остальные.‏ ‎Например, ‎IndieBroGames.Common ‎содержит ‎в ‎себе‏ ‎мою ‎накопленную‏ ‎базу‏ ‎скриптов, ‎база ‎формировалась‏ ‎в ‎процессе‏ ‎работы ‎над ‎другими ‎проектами,‏ ‎включает‏ ‎мои ‎наработки,‏ ‎измененные ‎версии‏ ‎других ‎скриптов ‎и ‎чужого ‎опыта.‏ ‎Это‏ ‎пространство ‎имен‏ ‎не ‎имеет‏ ‎зависимостей ‎от ‎конкретного ‎проекта ‎и‏ ‎используется‏ ‎в‏ ‎каждом ‎проекте‏ ‎в ‎одностороннем‏ ‎порядке.

А ‎есть‏ ‎пространство‏ ‎имен ‎IndieBroGames.Soulskiller,‏ ‎к ‎которому ‎относятся ‎скрипты ‎этой‏ ‎игры. ‎Это‏ ‎пространство‏ ‎имен ‎может ‎использовать‏ ‎скрипты ‎из‏ ‎IndieBroGames. ‎Common. ‎Здесь ‎формируется‏ ‎конкретная‏ ‎реализация ‎игровых‏ ‎механик, ‎относящихся‏ ‎только ‎к ‎этой ‎игре.

Под ‎IndieBroGames.Soulskiller‏ ‎лежат‏ ‎остальные ‎пространства‏ ‎имен, ‎которые‏ ‎отсортированы… ‎по ‎игровым ‎механикам, ‎как‏ ‎папки,‏ ‎в‏ ‎которых ‎и‏ ‎лежат ‎эти‏ ‎скрипты. ‎Например,‏ ‎поведение‏ ‎противников ‎основано‏ ‎на ‎машине ‎состояний ‎(об ‎этом‏ ‎поговорим ‎чуть‏ ‎позже),‏ ‎где ‎машина ‎состояний‏ ‎находится ‎в‏ ‎пространстве ‎имен ‎IndieBroGames.Common.StateMachineSystem, ‎а‏ ‎состояния‏ ‎противников ‎унаследованы‏ ‎от ‎абстрактного‏ ‎класса ‎State.

Порядок ‎инициализации

Начало ‎начал ‎в‏ ‎игре‏ ‎– ‎это‏ ‎первая ‎сцена‏ ‎для ‎инициализации ‎ядра ‎из ‎пространства‏ ‎имен‏ ‎IndieBroGames.‏ ‎Common. ‎По‏ ‎сути ‎Core‏ ‎– ‎это‏ ‎точка,‏ ‎в ‎которой‏ ‎инициализируются ‎все ‎основные ‎системы, ‎а‏ ‎также ‎это‏ ‎фасад для‏ ‎доступа ‎ко ‎всем‏ ‎этим ‎системам.

Ядро‏ ‎включает ‎систему ‎сохранения, ‎локализацию,‏ ‎асинхронный‏ ‎загрузчик ‎сцен,‏ ‎механику ‎паузы‏ ‎и ‎некоторые ‎другие ‎вещи.

Вторая ‎сцена‏ ‎–‏ ‎инициализация ‎ядра‏ ‎проекта ‎и‏ ‎выбор ‎предварительных ‎настроек ‎– ‎языка‏ ‎локализации,‏ ‎громкости‏ ‎и ‎вибрации.

Ядро‏ ‎проекта, ‎по‏ ‎аналогии, ‎содержит‏ ‎в‏ ‎себе ‎вещи,‏ ‎к ‎которым ‎нужен ‎доступ ‎в‏ ‎процессе ‎игры.‏ ‎Только‏ ‎те ‎вещи, ‎которые‏ ‎относятся ‎к‏ ‎этому ‎проекту.

После ‎всех ‎инициализаций‏ ‎запускается‏ ‎сцена ‎с‏ ‎убежищем ‎главного‏ ‎героя, ‎охотника ‎на ‎нечисть.

Завершение

Что ‎не‏ ‎так‏ ‎сказал? ‎Какие‏ ‎бывают ‎еще‏ ‎способы ‎упорядочить ‎проект? ‎Мысли, ‎критика?‏ ‎Пиши,‏ ‎прочтем.

Разработчик | Проект | YouTube | e-mail | Поддержка

Привет, ‎коллеги.‏ ‎Расскажу ‎про ‎игровой ‎цикл ‎и‏ ‎на ‎какие‏ ‎игры‏ ‎ориентировался ‎в ‎процессе.

Об‏ ‎игре ‎и‏ ‎вдохновителях

Игра ‎будет ‎по ‎сути‏ ‎ареной,‏ ‎в ‎которой‏ ‎противники ‎нападают‏ ‎волнами. ‎По ‎завершении ‎одной ‎волны,‏ ‎игрок‏ ‎активирует ‎следующую‏ ‎на ‎определенной‏ ‎точке ‎на ‎арене. ‎Примерами ‎игр‏ ‎по‏ ‎волнам‏ ‎могут ‎быть‏ ‎Killing ‎Floor‏ ‎(pc), ‎Only‏ ‎One‏ ‎(android), ‎They‏ ‎are ‎Billions ‎(pc). ‎С ‎каждым‏ ‎разом ‎противников‏ ‎будет‏ ‎больше ‎и ‎разнообразней.‏ ‎Придется ‎учитывать‏ ‎их ‎особенности ‎и ‎расставлять‏ ‎приоритеты.

В‏ ‎свое ‎время‏ ‎мне ‎очень‏ ‎нравилась ‎игра ‎Painkiller ‎(pc). ‎Да,‏ ‎она‏ ‎была ‎не‏ ‎самой ‎оригинальной‏ ‎в ‎плане ‎игровых ‎механик ‎(хотя‏ ‎там‏ ‎были‏ ‎карты ‎таро‏ ‎и ‎специфичная‏ ‎пушка ‎у‏ ‎героя,‏ ‎а ‎у‏ ‎каждого ‎оружия ‎альтернативный ‎огонь), ‎но‏ ‎какая ‎там‏ ‎была‏ ‎атмосфера! ‎Мрачные ‎текстуры‏ ‎подземелий ‎и‏ ‎заброшенных ‎зданий ‎в ‎совокупности‏ ‎с‏ ‎отлично ‎подобранными‏ ‎звуками, ‎отлетающие‏ ‎в ‎виде ‎тряпичных ‎кукол ‎противники‏ ‎и‏ ‎награда ‎–‏ ‎душа ‎поверженного‏ ‎противника!

Противники

Противники ‎в ‎игре ‎– ‎главная‏ ‎особенность‏ ‎проекта.‏ ‎Каждый ‎противник‏ ‎имеет ‎свою‏ ‎собственную ‎модель‏ ‎поведения.‏ ‎Я ‎хотел‏ ‎прежде ‎всего ‎сделать ‎каждого ‎противника‏ ‎индивидуальным, ‎они‏ ‎не‏ ‎должны ‎отличаться ‎друг‏ ‎от ‎друга‏ ‎только ‎очками ‎здоровья ‎и‏ ‎скорости.‏ ‎Об ‎особенностях‏ ‎поведения ‎я‏ ‎расскажу ‎в ‎отдельной ‎статье, ‎как‏ ‎реализовано‏ ‎и ‎какие‏ ‎особенности ‎бывают.

Механики

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

Боевые‏ ‎особенности.‏ ‎Герой ‎применяет‏ ‎автоматические ‎способности,‏ ‎как ‎только ‎противник ‎приблизится ‎достаточно‏ ‎близко.‏ ‎Подошел ‎близко?‏ ‎Получи ‎удар‏ ‎мечом. ‎Еще ‎далеко, ‎но ‎на‏ ‎расстоянии‏ ‎выстрела?‏ ‎Луки ‎к‏ ‎бою! ‎Много‏ ‎вражин? ‎Граната‏ ‎решит‏ ‎проблему. ‎Помимо‏ ‎автоматических ‎способностей ‎есть ‎магия, ‎которую‏ ‎игрок ‎выбирает‏ ‎куда‏ ‎применить, ‎перетаскивая ‎иконку‏ ‎способности ‎в‏ ‎точку ‎на ‎арене. ‎Магия‏ ‎перезаряжается.‏ ‎Но ‎так‏ ‎же ‎есть‏ ‎свитки, ‎которые ‎выпадают ‎из ‎противников.‏ ‎Свитки‏ ‎по ‎своей‏ ‎сути ‎–‏ ‎одноразовая ‎магия ‎без ‎выбора ‎точки‏ ‎применения.‏ ‎Например,‏ ‎самолечение ‎или‏ ‎удар ‎молнии‏ ‎в ‎одного‏ ‎из‏ ‎случайных ‎противников.

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

Убежище

Это ‎наше‏ ‎Лобби.‏ ‎Место, ‎в‏ ‎котором ‎охотник ‎подготавливается ‎к ‎следующему‏ ‎забегу. ‎Здесь‏ ‎можно‏ ‎изучить ‎свитки, ‎прочитать‏ ‎в ‎Альманахе‏ ‎особенности ‎поведения ‎противников, ‎выбрать‏ ‎снаряжение‏ ‎и ‎повысить‏ ‎навыки ‎главного‏ ‎героя. ‎Знакомясь ‎в ‎процессе ‎боя‏ ‎с‏ ‎новыми ‎противниками,‏ ‎вы ‎пополняете‏ ‎страницы ‎Альманаха, ‎в ‎котором ‎описывается‏ ‎поведение‏ ‎и‏ ‎особенности ‎вновь‏ ‎изученного ‎противника.

Итогом

Пусть‏ ‎это ‎будет‏ ‎фишкой‏ ‎девлога, ‎я‏ ‎буду ‎определять ‎пользу ‎и ‎итоги‏ ‎как ‎для‏ ‎себя,‏ ‎так ‎и ‎для‏ ‎читателей ‎отдельно.

Написав‏ ‎все ‎это, ‎я ‎скомпоновал‏ ‎в‏ ‎своей ‎голове‏ ‎краткое ‎описание‏ ‎игры, ‎еще ‎раз ‎прошелся ‎по‏ ‎механикам‏ ‎и… ‎кажется‏ ‎все ‎не‏ ‎так ‎плохо, ‎игра ‎потенциально ‎может‏ ‎удивить‏ ‎заядлого‏ ‎игрока, ‎порадовать‏ ‎новыми ‎игровыми‏ ‎механиками ‎или‏ ‎дать‏ ‎новое ‎представление‏ ‎уже ‎знакомым ‎механикам.

Для ‎вас ‎же‏ ‎итогом ‎будет‏ ‎пару‏ ‎советов. ‎Старайтесь ‎делать‏ ‎свои ‎игры‏ ‎самобытными, ‎индивидуальными, ‎иначе ‎какой‏ ‎смысл‏ ‎в ‎таком‏ ‎творчестве. ‎Многие‏ ‎большие ‎игры, ‎которые ‎сейчас ‎выпускают,‏ ‎очень‏ ‎шаблонные ‎и‏ ‎привычные ‎игрокам.‏ ‎Цвет ‎зеленый-синий-золотой ‎для ‎противников ‎и‏ ‎оружия,‏ ‎аванпосты‏ ‎и ‎собирательство‏ ‎ресурсов, ‎награда‏ ‎за ‎проделанную‏ ‎работу.‏ ‎Пусть ‎лучше‏ ‎сам ‎процесс ‎приносит ‎удовольствие, ‎чем‏ ‎награда ‎после‏ ‎рутины.

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

Немного ‎пользы ‎от‏ ‎статьи. ‎Как‏ ‎запомнить ‎названия ‎планет? ‎Джоел‏ ‎поможет.‏ ‎"Мама ‎всегда‏ ‎запрещала ‎мне,‏ ‎юному ‎следопыту, ‎учить ‎названия ‎планет"‏ ‎(Меркурий,‏ ‎Венера, ‎Земля...)

Вопросы,‏ ‎мнение, ‎критика?‏ ‎Пиши, ‎что ‎думаешь.

Какие ‎магические ‎способности‏ ‎реже‏ ‎всего‏ ‎встречаются? ‎Я‏ ‎бы ‎сказал,‏ ‎что ‎большинство‏ ‎игр‏ ‎стараются ‎воздействовать‏ ‎магией ‎напрямую ‎на ‎противника. ‎Я‏ ‎бы ‎хотел‏ ‎как-нибудь‏ ‎сделать ‎игру ‎про‏ ‎ведьму, ‎которая‏ ‎побеждает ‎непрошенных ‎гостей ‎Темного‏ ‎леса‏ ‎косвенным ‎путем,‏ ‎влияя ‎на‏ ‎природу ‎или ‎на ‎снаряжение ‎противников,‏ ‎на‏ ‎их ‎восприятие‏ ‎мира.

Разработчик | Проект | YouTube | Поддержка

Целью ‎девлога‏ ‎для ‎меня ‎стало, ‎как ‎я‏ ‎писал ‎в‏ ‎предыдущей‏ ‎статье, ‎повышение ‎мотивации‏ ‎в ‎разработке‏ ‎и ‎завершении ‎игры ‎(а‏ ‎еще‏ ‎немного ‎покормить‏ ‎графоманство). ‎Тогда‏ ‎же ‎для ‎вас ‎этот ‎девлог‏ ‎будет‏ ‎интересен ‎по‏ ‎следующим ‎причинам:

• Я‏ ‎расскажу ‎про ‎технические ‎подробности ‎в‏ ‎разработке,‏ ‎это‏ ‎будет ‎полезно‏ ‎разработчикам. ‎Вообще,‏ ‎искать ‎новые‏ ‎технические‏ ‎решения ‎и‏ ‎удобные ‎аналоги ‎уже ‎изученным ‎вариантам‏ ‎– ‎часть‏ ‎нашей‏ ‎работы. ‎Нельзя ‎стоять‏ ‎на ‎одном‏ ‎и ‎том ‎же, ‎делать‏ ‎то‏ ‎же ‎самое‏ ‎на ‎том‏ ‎же ‎фундаменте ‎(привет, ‎Starfield). ‎(Обожаю‏ ‎это‏ ‎видео, не ‎реклама)

• Расскажу‏ ‎про ‎процесс‏ ‎разработки, ‎что ‎делал ‎помимо ‎написания‏ ‎кода‏ ‎и‏ ‎где ‎брал.‏ ‎Моделирование, ‎риг,‏ ‎анимация, ‎озвучка,‏ ‎эффекты,‏ ‎геймдизайн, ‎ИИ,‏ ‎локализация, ‎сервисы, ‎тестирование, ‎ну ‎еще‏ ‎менеджмент ‎проекта,‏ ‎а‏ ‎в ‎дальнейшем ‎и‏ ‎дистрибуция. ‎Я‏ ‎ничего ‎не ‎забыл? ‎Вообще-то‏ ‎много‏ ‎вышло ‎как-то,‏ ‎может ‎показаться,‏ ‎что ‎разработка ‎игр ‎– ‎это‏ ‎тяжелый‏ ‎труд. ‎Не‏ ‎показалось.
• Расскажу ‎о‏ ‎возникших ‎проблемах ‎и ‎решениях. ‎Сразу‏ ‎обозначу,‏ ‎что‏ ‎я ‎стараюсь‏ ‎сразу ‎решать‏ ‎возникшую ‎проблему‏ ‎не‏ ‎костылями. ‎«Если‏ ‎хочешь ‎вставить ‎костыль, ‎сразу ‎бей‏ ‎себя ‎по‏ ‎рукам»,‏ ‎говорил ‎мне ‎мой‏ ‎руководитель ‎на‏ ‎предыдущем ‎месте ‎работы.
• Черпнем ‎чуть‏ ‎больше‏ ‎за ‎пределами‏ ‎самого ‎проекта.‏ ‎Например, ‎какие ‎бывают ‎ИИ ‎в‏ ‎играх‏ ‎и ‎какой‏ ‎выбор ‎сделал‏ ‎я.

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

Тяжело ‎делать‏ ‎игру ‎одному.‏ ‎Например, ‎разработчик ‎Stardew ‎Valley ‎делал‏ ‎игру‏ ‎в‏ ‎одиночку. ‎Разработчик‏ ‎возложил ‎на‏ ‎себя ‎и‏ ‎написание‏ ‎музыки, ‎и‏ ‎рисование, ‎и ‎анимацию, ‎по ‎мере‏ ‎совершенствования ‎навыков‏ ‎он‏ ‎множество ‎раз ‎переделывал‏ ‎уже ‎готовые‏ ‎части ‎игры. ‎Не ‎забудем‏ ‎про‏ ‎финансовые ‎трудности‏ ‎(приходилось ‎работать‏ ‎билетером ‎в ‎театре) ‎и ‎ожидания‏ ‎со‏ ‎стороны ‎игроков‏ ‎и ‎издателя,‏ ‎которые ‎все ‎никак ‎не ‎видели‏ ‎релиза‏ ‎игры.‏ ‎Эрик ‎Бароне‏ ‎очень ‎творческий‏ ‎человек, ‎но‏ ‎все‏ ‎еще ‎человек.‏ ‎А ‎еще ‎делать ‎игру ‎в‏ ‎одного ‎–‏ ‎это‏ ‎долго, ‎процессы ‎не‏ ‎идут ‎параллельно,‏ ‎появляются ‎кранчи ‎(переработки). ‎В‏ ‎один‏ ‎момент ‎он‏ ‎уснул ‎прямо‏ ‎за ‎столом. ‎В ‎конце ‎концов‏ ‎игра‏ ‎вышла ‎и‏ ‎получила ‎много‏ ‎наград, ‎но ‎вряд ‎ли ‎вы‏ ‎бы‏ ‎захотели‏ ‎окунуться ‎в‏ ‎такой ‎процесс,‏ ‎зная ‎все‏ ‎эти‏ ‎подробности. ‎Как‏ ‎и ‎в ‎кооперативных ‎играх, ‎друзья‏ ‎делают ‎все‏ ‎лучше:‏ ‎если ‎делать ‎не‏ ‎одному ‎–‏ ‎это ‎уже ‎хорошо.

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

Кранчи.‏ ‎Я‏ ‎пока‏ ‎не ‎прочувствовал‏ ‎на ‎себе‏ ‎это ‎слово,‏ ‎ведь‏ ‎делал ‎игру‏ ‎тихо, ‎что ‎не ‎ограничивает ‎меня‏ ‎в ‎продолжительности‏ ‎разработки.‏ ‎Хочу ‎делаю, ‎хочу‏ ‎не ‎делаю.‏ ‎Конечно, ‎при ‎публикации ‎проекта‏ ‎меня‏ ‎все ‎еще‏ ‎никто ‎не‏ ‎обязует ‎делать ‎все ‎быстро. ‎Глянем‏ ‎на‏ ‎этот ‎вопрос‏ ‎с ‎другой‏ ‎стороны: ‎вместо ‎того, ‎чтобы ‎растягивать‏ ‎процесс,‏ ‎появляется‏ ‎мотивация ‎продолжать.

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

Когда ‎я ‎в ‎очередной ‎раз‏ ‎забросил‏ ‎одну‏ ‎из ‎игр,‏ ‎я ‎подумал,‏ ‎что ‎стоит‏ ‎взять‏ ‎что-то ‎менее‏ ‎масштабное, ‎не ‎делать ‎полноценную ‎игру.‏ ‎Так ‎я‏ ‎в‏ ‎одиночку, ‎а ‎нередко‏ ‎в ‎составе‏ ‎небольшой ‎команды ‎(даже ‎два‏ ‎человека‏ ‎– ‎команда)‏ ‎выпустили ‎несколько‏ ‎ассетов ‎в ‎Unity ‎Asset ‎Store.

Это‏ ‎интересно?‏ ‎Я ‎в‏ ‎любом ‎случае‏ ‎продолжу ‎писать ‎статьи ‎и ‎делать‏ ‎игру,‏ ‎но‏ ‎если ‎у‏ ‎тебя ‎есть‏ ‎мнение, ‎совет‏ ‎или‏ ‎критика, ‎пиши‏ ‎в ‎комментариях. ‎Это ‎будет ‎полезно‏ ‎нам ‎обоим.

Разработчик | Проект | YouTube | Поддержка

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

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

О ‎проекте.‏ ‎Игра ‎разрабатывается‏ ‎на ‎движке ‎Unity, ‎URP ‎рендеринг,‏ ‎используются‏ ‎по ‎максимуму‏ ‎встроенные ‎и‏ ‎интегрированные ‎системы ‎(URP, ‎Addressables, ‎Remote‏ ‎Config,‏ ‎Analytics,‏ ‎Shader ‎Graph,‏ ‎UniTask, ‎FMOD,‏ ‎DoTween…). ‎Целями‏ ‎проекта‏ ‎стали:

• самореализация
• небольшой ‎шаг‏ ‎в ‎публичность
• демонстрация ‎своих ‎навыков ‎разработчика

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

Об‏ ‎игре.‏ ‎Soulskiller ‎–‏ ‎это ‎игра ‎в ‎жанре ‎TDS‏ ‎(Diabloid), ‎в‏ ‎котором‏ ‎главным ‎героем ‎выступает‏ ‎охотник ‎на‏ ‎нечисть ‎и ‎потусторонние ‎проявления.‏ ‎Он‏ ‎выполняет ‎заказ‏ ‎на ‎зачистку‏ ‎заброшенной ‎деревни ‎от ‎непрошенных ‎гостей.

Вдохновителями‏ ‎для‏ ‎игры ‎стали:

• Painkiller‏ ‎– ‎старая‏ ‎серия ‎игр, ‎шутер ‎на ‎комп,‏ ‎который‏ ‎цеплял‏ ‎своей ‎атмосферой‏ ‎и ‎антуражем,‏ ‎но ‎однообразное‏ ‎поведение‏ ‎противников ‎и‏ ‎игра ‎от ‎арены ‎до ‎арены‏ ‎быстро ‎наскучивали.
• Witchfire‏ ‎–‏ ‎от ‎тех ‎же‏ ‎создателей. ‎Главный‏ ‎герой ‎бегает ‎по ‎локации‏ ‎и‏ ‎борется ‎с‏ ‎нечистью ‎на‏ ‎острове, ‎улучшаясь ‎и ‎экипируясь ‎в‏ ‎своем‏ ‎убежище ‎неподалеку.‏ ‎Эта ‎игра‏ ‎уже ‎более ‎похоже ‎на ‎рогалик.
• Vampire‏ ‎Survival‏ ‎–‏ ‎бесконечная ‎игра,‏ ‎в ‎которой‏ ‎комбинация ‎собранной‏ ‎экипировки‏ ‎могла ‎создавать‏ ‎большое ‎многообразие.
• F.E.A.R. ‎– ‎серия ‎игр,‏ ‎в ‎которой‏ ‎многие‏ ‎хвалили ‎продвинутый ‎искусственный‏ ‎интеллект. ‎Я‏ ‎бы ‎хотел ‎в ‎своей‏ ‎игре‏ ‎сделать ‎каждого‏ ‎противника ‎особенным,‏ ‎с ‎индивидуальным ‎поведением, ‎чего ‎и‏ ‎добиваюсь.

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