Принципы минимализма при разработке игр для мобильных платформ

Преамбула


В конце лета прошлого года мы решили сделать продолжение нашей игры Папа Пингвин как полноценную новую игру. Вначале мы хотели лишь слегка изменить имеющуюся идею и выпустить на основе нее более серьезный проект, использующий наши наработки, однако мы недостаточно основательно подошли к вопросам препродакшена и не определили достаточно четко фокус и базовый геймплей проекта с самого начала. В результате игра получилась не такой лаконичной и цельной, как могла бы, а разработка игры затянулась. Причем не все запланированные фичи были реализованы, а в процессе разработки приходилось несколько раз останавливаться, пересматривать полученные результаты и упрощать как саму идею, так и дизайн уровней, интерфейс и т.д. Последние упрощения были сделаны после проведенных тестов и отзывов. В итоге получился именно Капитан Антарктика, а не Папа Пингвин 2. Результатом, откровенно говоря, я не совсем доволен. Хотя игра получилась очень интересной, многое в ней можно упростить и улучшить (что мы и постараемся сделать в ближайших обновлениях).

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

Итак, по порядку:

1. Минимализм идеи

  • Идея игры должна быть проста и понятна игроку.
  • Идея должна быть настолько простой и короткой, что игрок мог бы моментально поделится ею с другими (что способствует распространению игры).
  • Идея должна напрямую поддерживать простоту геймплея.
  • Простая идея должна запасть в душу игроку и запомнится надолго.


Примером здесь могут служить Tiny Wings
image

и Angry Birds.
image

2. Минимализм дизайна

  • Геймплей должен быть максимально простым и понятным без подсказок и обучения.
  • Управление должно быть простым и подходящим большинству игроков. Нежелательно делать несколько вариантов управления. Желательно, чтобы управление осуществлялось так же просто на других платформах, чтобы при портировании не пришлось изобретать новое.
  • Геймлуп и игровая сессия должны быть короткими, но геймплей и остальная инфраструктура (например, магазин) должен давать возможность снова и снова переигрывать (endless mode или возможность постоянного улучшения результатов).
  • Уровень должен быть устроен так, чтобы всегда легко можно было бы внести изменения и протестировать их.
  • Никаких параметрических заданий-миссий внутри игры одновременно с достижениями. Зачем две вещи, если они фактически выполняют одно и то же (JetPack JoyRide)?
  • Процесс Игра->Улучшения/Магазин->Игра->… должен быть быстрым, максимально упрощенным и интуитивно понятным.
  • Магазин и товары в нем должны быть простыми, чтобы не нужно было объяснять, что это за товар и что он предоставляет игроку, но тем не менее оставлять игроку возможность выбора.
  • Меню должно быть максимально простым, как можно меньше переходов. Желательно, чтобы вообще было 3 экрана: главное меню, магазин и сама игра.
  • В игре должно быть как можно меньше текста (в идеале только название игры и авторы). Все остальное — визуально (иконки, стрелочки и т.д.) и интуитивно понятно. Это минимизирует работы по локализации.
  • В дизайне должно быть как можно меньше цифр — это упрощает настройку. И, конечно, как можно меньше цифр (кроме статистики) должно быть предоставлено на обработку игроку.


Под эти пункты (но не все) я бы подписал JetPack JoyRide
image

и Run In Crowd.
image

3. Минимализм в графике

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


Сюда подойдут Cut the Rope
image

и Contre Jour.
image

4. Минимализм программирования

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


Сюда бы я приписал все продолжения Angry Birds, Cut the Rope Experiments и Mega Run.
image

5. Минималистичность звукового оформления

  • Легкая, не утруждающая фоновая музыка, которая понравится всем.
  • Маленькое количество звуков (они нагружают процессор и увеличивают размер билда).
  • Звуки должны быть простыми, не отвлекающими и не нагружающими, а погружающими в геймплей.


Contre Jour, Cut the Rope.

6. Другие (дополнительные) требования:

  • Желательно, чтобы приложение было универсальным, так как, отдельные версии приходится дольше собирать и тяжелее поддерживать. Целесообразно ли это с точки зрения маркетинга — вопрос спорный.
  • Приложение должно быть рассчитано на максимально широкую аудиторию.
  • Поддержка Retina-дисплеев.
  • Хорошо, если приложение поддерживает все имеющиеся устройства Apple на iOS (порадуем всех) и работает на них без тормозов.
  • Итоговый размер приложения не должен превышать 50Мб (для iOS > 5), а еще лучше, если он будет меньше 20 (для старых устройств, не поддерживающих iOS 5).
  • В приложении не должно быть платформозависимых элементов, что позволит в дальнейшем распространять его на остальные платформы.


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

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

habrahabr.ru