Загрузка

Адаптация PC-игры для планшета

Теги: алгоритмы, мобильные игры

ПОТРЕБНОСТЬ В АДАПТАЦИИ

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

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

КАСАНИЯ И ЖЕСТЫ

Мышь и клавиатура - традиционные устройства ввода, работа с ними для обеспечения взаимодействия программы с пользователем знакома всем разработчикам PC-игр. Но что же из себя представляет сенсорный экран с точки зрения программиста? Во первых, сенсорный экран - это устройство, призванное заместить для пользователя и мышь, и клавиатуру одновременно, универсальное устройство для работы с графическим пользовательским интерфейсом. При этом, работа с  устройством основывается на касаниях - одиночных или множественных, коротких или продолжительных, точечных или направленных. Касание - основное событие сенсорного экрана, и основным параметром его является координата. Все сорвеменные сенсорные экраны поддерживают технологию Multi-Touch, поэтому, в один момент времени может происходить сразу несколько касаний. Это значительно расширяет возможности сенсорного экрана.

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

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

Кроме снижения количества возможностей, большое влияние сенсорный экран оказывает и на удобство. Те действия, которые были удобны при работе с мышью, могут быть крайне затруднительны для выполнения с помощью сенсорного экрана. К примеру, нажатие клавиши на клавиатуре и одновременный щелчок в каком-либо месте на экране выполнить гораздо проще, чем удерживать "нажатым" какой-либо элемент управления на экране, и одновременно коснуться экрана в нужном месте. Работать с планшетом двумя руками сразу не всегда бывает возможно, так как одной рукой приходится его держать. Эти и многие другие проблемы с удобством использования оказывают большое влияние на планирование будущей адаптации.

ЖИВОЙ ПРИМЕР

В своей предыдущей статье я написал, что адаптировать игровой проект к работе на планшете можно несколькими простыми функциями. Для того, чтобы проверить, так ли это на самом деле, я совместно с SaiLight начал доработку игры Crown. На этом примере я и продолжу дальнейшее рассуждение относительно процесса адаптации.

Напомню, что игра разрабатывается на языке Delphi, в среде разработки Delphi 7. Она представляет собой логическую вариацию на тему "три в ряд". Более подробно о ней можно почитать на странице проекта. Соответственно, все примеры приведенного ниже кода протестированы на Delphi 7. На первый взгляд покажется глупым создавать игру, ориентированную на поддержку планшетных компьютеров, в древней среде разработки. Конечно же, сейчас мало кто занимается поддержкой новых возможностей для этой среды, однако, нам повезло, и мы нашли зарубежного единомышленника, который написал API для работы с сенсорным экраном для Delphi 7.

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

Сначала стоит перечислить проблемы, которые мешали играть в эту игру на планшетном компьютере:

  1. Нажатие на экран срабатывало неправильно. Для нажатия на элементы управления или игровое поле приходилось дважды касаться экрана.
  2. Отсутствовала возможность смены типа удара (кнопки 1, 2, 3 на клавиатуре)
  3. Отсутствовала возможность изменения направления удара (колесо мыши)
  4. Отсутствовала возможность перемещения камеры (перемещение указателя с зажатой правой кнопкой мыши)

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

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

ЛОГИКА ИНТЕРФЕЙСА УСТРОЙСТВ ВВОДА

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

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

  1. onMouseMove - движение указателя
  2. onMouseDown - нажатие кнопки мыши
  3. onMouseUp - отпускание кнопки мыши
  4. onClick - "щелчок" = нажатие и отпускание

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

Внутриигровая логика работы с мышью устроена следующим образом:

  1. В таймере происходит проверка на попадание указателя на каждый из игровых объектов (решение производить это действие не в событии onMouseMove очевидно - чтобы снизить количество вызовов функции). Если указатель мыши попадает на объект, то это фиксируется в параметре объекта FIsMouseInside.
  2. При событии onMouseUp в игровом окне вызывается игровая процедура pMouseUp, которая фиксирует в параметре объекта FWaitForMouseUp - должно ли на следующем шаге таймера для него вызваться событие onClick. Это происходит в том случае, если указатель мыши попадает на объект. Подход может показаться не совсем верным, однако, был обусловлен некоторыми особенностями внутриигровой логики.
  3. В таймере происходит проверка - если параметру FWaitForMouseUp присвоено истинное значение, выполняется функция, назначенная на событие onClick элемента управления.

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

  1. При касании экрана (вернее, при потере контакта пальца с экраном) возникает событие onClick - одновременное onMouseDown и onMouseUp. Событие onMouseMove происходит в то время, когда палец прикасается к экрану. Поэтому при коротком касании происходит одновременное перемещение указателя в позицию касания и вызов события onMouseUp, которое устанавливает параметр FWaitForMouseUp.
  2. В таймере, как и было описано ранее, происходит проверка на попадание указателя мыши на игровые объекты. Если параметр FWaitForMouseUp установлен, то вызывается событие onClick для объекта.

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

АНАЛИЗ ПРОБЛЕМЫ

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

Позднее в дневнике проекта Crown появится статья с более подробным описанием адаптации этой игры к сенсорному экрану. В рамках данной статьи рассматривается именно процесс адаптации в целом, поэтому я не стану углубляться в подробности конкретной ситуации, а опишу её решение в общих чертах. Стоит заметить, что в процессе адаптации мы не можем вносить серьезные изменения в структуру игры (хотя у нас было такое желание и даже попытки это сделать). Все структурные изменения влекут за собой множество серьезных сложностей, для исправления которых понадобится очень много времени.

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

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

ПОИСК РЕШЕНИЯ

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

Для этого мы ввели внутри класса игры поле FWaitForMouseUp и процедуру  pDelayMouseUp. Эта процедура вызывается в событии onClick игрового окна и устанавливает параметр FWaitForMouseUp. Теперь, во время следующего шага таймера, если общеигровой параметр FWaitForMouseUp установлен, мы вызываем процедуру pMouseUp (которая ранее вызывалась при событии onMouseUp игрового окна). Теперь можно представить, какие действия и в каком порядке выполнялись бы при касании.

Внутриигровая логика работы с сенсорным экраном после внесения изменений:

  1. При касании указатель мыши переносится в позицию касания и вызывается событие onClick игрового окна. В событии проверяется наличие сенсорного экрана. Если он присутствует, то вызывается процедура pDelayMouseUp и устанавливается общеигровой параметр FWaitForMouseUp.
  2. В таймере происходит проверка на попадание мыши на игровые объекты. После этого вызывается процедура pMouseUp, поскольку параметр FWaitForMouseUp был установлен.
  3. В процедуре pMouseUp фиксируется параметр FWaitForMouseUp для объекта, на который попадает указатель мыши.
  4. На следующем шаге таймера происходит вызов события onClick для этого объекта.

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

НОВЫЕ ВОЗМОЖНОСТИ

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

Procedure TfrmGameForm.pGesture(var vMsg: TMessage);
var
  ...
begin
  if (NOT(vIsTouchEnabled)) then Exit;//Сенсорный экран недоступен
//Обработка жеста
  ...
    case vGestInfo.dwID of
      GID_PAN: begin//Жест: Сдвиг
       {Перемещение камеры}
      end;
      GID_TWOFINGERTAP: begin//Жест: Касание двумя пальцами
        {Смена типа удара}
      end;
      GID_ROTATE: begin//Жест: Поворот
        {Смена направления удара}
      end;
   ...
    end;
  end;
 ...
end;

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


На этом примере я постарался показать сложность адаптации игр, в которых по ходу разработки многое было ориентировано на традиционный интерфейс с применением мыши. Можно представить себе менее структурированную игру, где многие действия напрямую зависят друг от друга и происходят в результате событий мыши onMouseMove, onMouseDown и onMouseUp. Такую игру было бы ещё сложнее адаптировать к сенсорному экрану, ведь понадобилось бы вносить изменения во множество функций. Поэтому, можно сказать, что сложность адаптации игры напрямую зависит от её внутренней структуры.

ЭКРАННАЯ КЛАВИАТУРА

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

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

Поделиться
Адаптация PC-игры для планшета
Адаптация PC-игр к планшетным компьютерам - сложная задача, стоящая перед разработчиками игр. Что представляет собой адаптация, какие именно сложности препятствуют этому процессу, что следует предпринять во время разработки проекта, чтобы облегчить процесс адаптации, и в каких случаях он становится...
article
3 Монеты
SpectreZ (3 года назад)

2 комментария:
SpectreZ, уровень 2 (3 года назад):

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

Также, эта статья может быть интересна тем, кто занимается развитием и поддержкой своих старых проектов, где не были использованы кроссплатформенные движки. Например, проект Warzone 2100 развивается до сих пор, но для сенсорных экранов интерфейс пока не проработан. Конечно, я не рассчитываю, что кто-либо из разработчиков Warzone 2100 увидит эту стаью :), но наверняка есть и русские проекты с подобной ситуацией.

CTAP4E, уровень 1 (3 года назад):

Респект за познавательную статью. По моему с предыдущей версии сайта она была изменена, не? Единственное, сегодня она вряд ли станет популярной - никто не хочет делать игры ручками, все перешли на движки и конструкторы, где все, что ты описал, уже учтено.)))

Войти