Римейк Race Into Space: как улучшить геймплей и интерфейс?

Идея отметить День космонавтики-2012 просмотром фильмов на эту тему привела к тому, что я серьезно заинтересовался историей космонавтики. И тут оказалась к месту игра, о которой я знал, но не интересовался достаточно, чтобы ознакомиться. Она вышла в 1993 году и называлась тогда Buzz Aldrin’s Race Into Space. Легендарный астронавт Базз Олдрин принимал участие в её разработке как технический консультант. В 2005 году разработчики выкупили права и перевыпустили игру под лицензией GPL, убрав имя Олдрина. Игра очень интересная и всячески рекомендуется к ознакомлению, однако, спустя некоторое время, мне стали очевидны моменты, в которых игру можно улучшить. Так появился Open Source проект Space Race: The Game. Рассказом о нём и тех улучшениях, которые запланированы, я и хочу с вами поделиться под катом.

Краткое описание игры

Исходная Race Into Space представляет собой экономическую пошаговую стратегию, в которой игрок осуществляет управление космической программой СССР/США. Исследуя ракеты-носители, беспилотные и пилотируемые космические аппараты, управляя отрядом космонавтов, игрок запускает космические миссии, получая очки престижа в зависимости от их результата и степени первенства. Редкость и ценность игрового геймплея заключается в том, что:

1. В условиях отсутствия ограничений по времени на принятие решения (игра пошаговая)
2. Игрок оценивает степень риска своего элементарного действия (принимает решения по пуску/отмене миссии, желая опередить соперника)
3. Осуществляя долгосрочную стратегическую программу (окончание игры — пилотируемая лунная миссия, до которой много шагов)

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

Принятие решения о разработке римейка

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

1. Игра 1993 года разработки содержит очень древний код на C/C++, языках, которые я не знаю, и, наверняка, кишит ограничениями, исходящими из нехватки ресурсов тогдашних компьютеров. Говоря коротко, нерационально и не хочется в нём копаться.
2. Некоторые изменения фундаментальны настолько, что проще сделать заново, чем переделывать то, что уже есть.

Характеристики проекта

1. Язык разработки: Java как один из самых популярных, и иррационально мне нравящийся.
2. Модель разработки: Open Source. Игра, помимо основной цели получения удовольствия, должна давать знания об истории освоения космоса и вызывать интерес к этой тематике. Это, во-первых, не должно быть платным, и, во-вторых, должно иметь возможность развиваться вне моих усилий.

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

Часть первая. Улучшения геймплея

1. Сокрытие надёжности
В исходной игре надёжность компонента (ракеты-носителя или космического аппарата) показывается явно. Соответственно, игроку точно известно, когда уже нет смысла исследовать, например, ракету-носитель и пора приступать к пускам. Математически подкованный игрок может рассчитать надёжность миссии, перемножив надежности входящих в неё элементов. Мне это показалось неправильным, поэтому в римейке надёжность компонентов скрыта от игрока. В самом деле, Королёв решился пустить «Восток» с человеком только после двух подряд успешных пусков с собаками, никто никаких вероятностей успеха ему не показывал. Соответственно, в римейке у компонентов есть время их исследования, за которое они набирают надежность с некоторым случайным отклонением, а затем игрок может «дорабатывать» эти компоненты, если надёжность его не устраивает.
2. Увеличение количества беспилотных миссий
В оригинальной игре беспилотных миссий весьма мало: простой спутник, пролетные миссии Луны и пяти планет, беспилотная посадка на Луну. Мне это кажется излишним упрощением, поскольку не передаёт интриги, например, получения фотографий обратной стороны Луны, или не показывает важности Лунохода или «Луны-16». Также, с точки зрения геймплея, я хочу дать беспилотную альтернативу высадке человека на Луну. Т.е. игрок, который очень успешно развивался в начале игры, может попытаться не рисковать людьми (или получить слабое финансирование из-за своих успехов, как СССР в реале) и выиграть игру по очкам, отправляя на Луну автоматы, и занимаясь, например, орбитальными станциями (примерно то, что в реальной истории делал СССР). В римейке уже реализованы основные миссии автоматов с небольшой альтернативной составляющей — переносом в прошлое «Вояджеров», «Вег» и марсоходов.
3. Введение в игру времени доставки компонента
В BARIS компонент покупался и доставлялся на космодром мгновенно. Это крайне нереалистично и лишает игрока интриги случайных событий «задерживается производство компонента N». Несмотря на риск сделать игру менее интересной, я надеюсь этим пунктом добавить стратегической глубины и необходимости планирования действиям игрока.
4. Снижение длительности хода в игровом времени
Оригинальный ход представлял собой полгода игрового времени. Соответственно, партия могла длиться от ~22 ходов (высадка на Луну в 1968) до ~50 ходов (срабатывало ограничение по времени). Это приводило к тому, что случайные события были слишком сильными, например, достаточно часто блокировалась возможность покупки компонентов или запуска каких-либо миссий. С такой важностью хода невезение или ошибка имели слишком большое значение, что иногда сильно раздражало. В римейке один ход занимает 1 месяц игрового времени.
5. Добавление гибкости условиям победы
В исходной игре условием победы была высадка человека на Луну. В римейке планируется гибкая система выбора правил окончания игры, с партиями разной длительности и опциональным окончанием игры высадкой человека на Луну.
6. Усложнения отношения с правительством
Правительство даёт задачи и финансы. В реальной истории СССР проиграл лунную гонку из-за того, что не давали денег, несмотря на все успехи до этого. Также этот пункт должен заменить положительную обратную связь (успех — больше денег — больше успеха — ещё больше денег — …) на отрицательную (успех — необходимость повышения профессионализма, так как денег не дадут, раз у тебя и так всё хорошо).
7. Замена модуля «навешиваемые ускорители» на модификации ракет-носителей
В исходной игре есть модуль «навешиваемые ускорители», который может добавляться к некоторым ракетам-носителям, повышая их грузоподъемность. В реальности что-то подобное было только у РН «Титан-III», а более распространённым вариантом было добавление или модификация верхней ступени (блоки «Е» и «И» у СССР на Р-7, «Аджена» и «Центавр» у США на «Атласах»). Для повышения реализма (и разделения надежности различных модификаций) было принято решение представить один тип ракеты-носителя несколькими модификациями.
8. Замена ускорителей на планетарные коэффициенты
В BARIS есть три типа ускорителей — A,B,C. Они нужны для лунных миссий, однако без мануала не разобраться, какой зачем нужен. Для упрощения ситуации было принято решение ввести коэффициенты увеличения массы (например, Луна — х3, Марс/Венера — х10 и т.п.). Соответственно, «Союз» на низкую околоземную орбиту можно поднять РН «Р-7 — блок „И“», но для того, чтобы отправить его же к Луне, понадобится уже «Протон-К».
9. Запрет выполнения полётов к Луне аппаратам второго поколения («Восход», «Джемини»)
В исходной игре возможны пилотируемые миссии к Луне вплоть до высадки на аппаратах второго поколения («Восход», «Джемини»). Несмотря на то, что для такого решения были некоторые предпосылки — существовали планы по модификации «Джемини» для лунных миссий, с точки зрения реального проектирования требовались очень серьезные доработки, а с точки зрения геймплея аппараты третьего поколения («Союз», «Аполлон») становятся де-факто не нужны, поскольку ничего нового для игрока не дают.
10. Сохранение некоторых решений, принятых для баланса
В оригинальной игре экипаж «Восхода» снижен до двух человек, но взамен ему дана возможность производить стыковку, что не было возможно в реальности. Решение принято из очевидных балансовых соображений — корабли второго поколения в игре предназначены для отработки внекорабельной деятельности и стыковки.
11. Перенос надежности ВКД из исследования в отработку
В BARIS есть очень хорошая идея — стыковку невозможно «изучить». Необходимо посылать миссии, которые и удачами и неудачами повышают надёжность стыковки. И это несмотря на то, что у США особых проблем со стыковкой не было. А вот с внекорабельной деятельностью — были. Астронавты страшно уставали, не могли выполнять полные планы работ. Мне показалось, что историчности и интереса ради, будет хорошо распространить механизм «отработки» стыковки и на ВКД.
12. Очевидные улучшения
Поддержка многоязычности (сейчас русский/английский, новые языки могут добавляться без проблем), нормальный мультиплеер — всего этого не было в оригинальной игре.

Часть вторая. Улучшение интерфейса

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

1. Главное окно

Симпатично, анимировано, но с точки зрения функциональности является графическим меню, позволяющим открыть окно исследований, сборки компонентов миссии, окна различных тренировок космонавтов, и замедляет интерфейс, параллельно повышая сложность освоения (что это за здания, и в каком меню какой важный пункт находится, первоначально плохо понятно). Исходя из желания увеличить скорость взаимодействия с интерфейсом, это окно убрано, и на его месте находятся элементы интерфейса первостепенной важности — элемент взаимодействия с компонентами и космонавтами, склад, лист ожидания и планирования и кнопка «закончить ход». Кнопки «конец хода» и «новая миссия», ожидаемо наиболее часто используемые, перенесены в углы согласно теореме Фиттса. Очевидный плюс — стало удобнее. Очевидный минус — стало скучнее.
Любопытный вопрос возник при проектировании логики. В исходной игре невозможно было уйти в отрицательные финансы, так как деньги на исследование или покупку каждый раз выделялись нажатием кнопок, и, при нехватке финансов, кнопка просто не нажималась. Однако в новом интерфейсе введены кнопки с хранением состояния «исследуем/не исследуем», и, в ситуации, когда было включено длительное исследование, а деньги кончились, надо что-то делать. В текущей реализации блокируется кнопка «закончить ход», и в поле «ошибки» выдается текстовое предупреждение о нехватке денег на исследование/доработку, предлагая игроку выключить наименее важные (или все по необходимости) исследования. Также есть альтернативный вариант — выключать автоматически все активные исследования (выключать частично, принимая решение за игрока, мы не можем). Какой вариант лучше, думаю, станет ясно только после более-менее серьезной эксплуатации приложения.

2. Окна исследования и покупки

Сразу видна интерфейсная ошибка. Может быть, она была обусловлена архитектурными или системными ограничениями, я говорю не осуждения, а улучшения ради. Окно покупки находится в двух кликах мыши («Администрация» — «покупка») от главного окна, окно исследования в одном (здание на игровом поле). Перед тем, как исследовать компонент, надо купить хотя бы один экземпляр. То есть в реальности действия пользователя ложатся в следующую последовательность: «игровое поле» — «окно исследования» — «окно покупки» — «покупка компонента» — «окно исследования» — «начало исследований компонента». Это долго. Поэтому было принято решение вынести информацию, покупку, доработку, заказ компонента и формирование экипажей для пилотируемых кораблей на верхний уровень главного окна.

3. Окно новой миссии.

Здесь можно очень наглядно показать следующие аспекты проблем проектирования интерфейсов:

• скорость доступа. Поместить одно из наиболее часто вызываемых окон за три клика от основного окна — это явная ошибка. Не знаю, почему она была сделана, можно было нарисовать здание проектирования миссии, или использовать нарисованные стартовые сооружения (отменить миссию там можно, а вот новую запланировать — нет).
• скорость взаимодействия. Реализация интерфейса планирования новой миссии сделана в стиле мастера (несколько окон с малым количеством компонентов). Здесь понятно, почему было принято такое решение — из-за маленького экранного разрешения. А, по-моему, здесь лучше смотрится одно окно с большим количеством компонентов, что и было реализовано.
• проблемы использования пиктограмм. Пиктограммы экономят место, но за это приходится платить повышением сложности освоения интерфейса. Например, попробуйте определить, что означает пиктограмма со скафандром и двумя желтыми секторами из шести. Некоторое время я думал, что это — количество человек в экипаже. Но нет, оказывается, это длительность миссии. Я решил не экономить место, а писать прямо текстом.
• фильтры, фиксаторы, перемотка. Пиктограммы являются индикаторами признаков миссии. При нажатии маленького квадратика в правом нижнем углу пиктограммы индикатор становится фильтром и позволяет показывать только миссии с таким состоянием индикатора. Однако для перехода в список отфильтрованных миссий необходимо нажать кнопки «вверх» или «вниз» и ими перематывать полученный список. Никакой информации о длине или составных элементах списка без перемотки получить невозможно. При проектировании нового окна принято решение сохранить фильтры как удобные, но заменить на соответствующие элементы — списки, радиокнопки, чекбоксы — что лучше подходит. И список подходящих миссий показывать полностью.
• проблема состояний интерфейса. Кнопка «Continue» в окне номер 3 имеет два состояния, которые никак на ней не показываются. Если выбрана миссия «нет миссии», то кнопка используется для закрытия окна. Если же выбрана любая другая миссия, то кнопка используется для движения дальше по мастеру новой миссии. Естественно, если пользователь передумал (или столкнулся с проблемами при планировании миссии), он забывает сознательно нажать «Reset» и только потом «Continue», что весьма раздражает. В римейке поставлены обычные кнопки «ОК» и «Отмена».
• показ миссий. Список миссий собирается только из возможных миссий. Например, при наличии только одного стартового комплекса, невозможно будет даже увидеть миссии совместных полётов или многопусковые миссии. В моём проекте используется обратный подход — показываются все возможные миссии, что позволяет проинформировать игрока о том, что вообще возможно сделать. Но при попытке выбрать такую миссию показываются требуемые шаги, которые не были сделаны.
• убраны два экрана. Перед запуском миссии игрок должен был зайти в экран монтажно-испытательного комплекса и собрать ракету (это теперь просто список подходящих носителей в окне новой миссии) и определить месяц пуска (это вообще убрано, миссия планируется на следующий месяц).

4. Окно показа миссии

Для иллюстрации прохождения этапов миссии используются тематические картинки и видео. Выбор видео понятен, однако, увы, на мой взгляд, недостатки такого метода перевешивают. Космического видео достаточно мало, и смотреть в очередной раз разделение первой и второй ступеней «Аполлона-6», показывающееся при запуске даже советских ракет (нет у нас аналогичного видео, совсем) быстро надоедает. Или, например, на приведенной картинке советский лунный модуль разгоняется к Луне, а показывают вход «Джемини» в плотные слои атмосферы. Видео быстро приедается и начинает прокликиваться. В идеале, мне кажется, надо делать полноценную синтезированную картинку, и различные виды неисправностей показывать соответствующим поведением аппарата. Надеюсь, когда-нибудь так и будет, а пока что сделан алгоритм генерации текстового отчета. Каждый шаг имеет несколько вариантов написания, если выпадает неисправность, она может помещаться в любое подходящее место (например, отказ двигателя может произойти и на десятой и на сотой секунде полёта). Таким образом, я надеюсь, отчет о миссии сделан более интересным, а для тех, кому это надоест, введены варианты скорости показа результата миссии — полный отчет сразу, поэтапный отчет, или текстовая имитация докладов, которые бы звучали в реальных ЦУПах.

Проект находится в стадии альфа-версии, версия 1.0 ожидается через один-два года. Если вы заинтересовались его текущим состоянием, с ним можно ознакомиться на GitHub, я буду рад фидбеку.

Использованные материалы:

1. Диаграмма космической гонки взята из Википедии
2. Скриншоты BARIS взяты из Open Source версии 1.0.0