Введение

Это концептуальный план!

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

В этом контексте данный концептуальный дизайн — своего рода эксперимент. Я планирую потратить 1–2 месяца на детализацию идей по ускорению процесса разработки (создание чернового дизайна, написание документации, проектирование классов и т.п.), а затем, взвесив альтернативные издержки, либо приступить к непосредственной разработке, либо оформить свои размышления в виде текста.

Почему именно tower defense

gameplay-sceneПример геймплея и управления

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

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

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

Минималистичный дизайн-код

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

info-panel-design-process Дизайн информационной панели башни, вызвавший больше всего раздумий. В каждом варианте есть свои недостатки

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

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

notification-system4 типа уведомлений, вызываемых во время игры

design-examplesГлавное меню и окно настроек. Иконки взяты из Fontawesome

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

Технические аспекты разработки

notion-darknotion-lightСтраница Notion, которую я даже подумываю выложить в открытый доступ, когда она будет более-менее оформлена

Технические цели, которые можно достичь в этом проекте, не грандиозны. Я планирую отточить и реализовать уже знакомые концепции — стратегии управления проектами (правила именования, принципы SOLID), шаблоны проектирования (синглтон, событийно-ориентированное программирование), основные критерии качества Android-приложений. Когда появится время, можно будет попробовать что-то новое из следующего списка:

В процессе написания документации я случайно наткнулся на Awesome Lists и среди них нашёл проект, связанный с Unity, а также особенно подробный и полезный opensource-проект Nodulus. Мне не хватало понимания того, как на самом деле управляется проект, и эти материалы могут сильно помочь в плане структуры скриптов и управления ассетами.