Управление на Android

[Christopher]

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

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

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

Клавиатурный эквивалент хардовых кнопок устройства:

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

Кнопка "Назад".
индекс кнопки - 8
Клаиватурный эквивалент - Backspace(vk_backspace)
Кнопка "Поиск"
В последнее время все меньше используется при разработке устройств, однако есть на телефонах и старых планшетах.
индекс - 17
Клавиатурный эквивалент - Ctrl(vk_control)
Кнопка "Дом"
всвязи с архитектурой ОС, эту кнопку нельзя переназначить, т.к. она является обязательной
Кнопка "Меню"
индекс - 77
Клавиатурный эквивалент - "M"(ord("M"))

ОСТОРОЖНО, КОСТЫЛЬ!

Итак, для начала нам понадобится три обьекта в комнате:
obj_swype_controller,
obj_swype_start,
obj_swype_main
У первого пишем такой код:

:create: Create

Код:

global.swype=0

Global Left Button

Код:

if global.swype=0
{
    instance_create(0,0,obj_swype_main)
    instance_create(mouse_x,mouse_y,obj_swype_start)
}

Далее переходим к obj_swype_start

  Global Left Released

Код:

instance_destroy()

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

Create

Код:

[code]global.swype=1

[/code]Step

Код:

if instance_exists(obj_swype_start)
{
//    draw_line(obj_swype_start.x,obj_swype_start.y,obj_swype_main.x,obj_swype_main.y)
//данная строчка чисто для отладки, показывает линию между ними
    if distance_to_object(obj_swype_start)>32//можем задать и любое число, это число инициирует минимальную длинну свайпа
    {
        if obj_swype_main.x<obj_swype_start.x//если свайп произошел влево
        {
        //делаем что-то
        }
        if obj_swype_main.x>obj_swype_start.x//вправо
        {
         //делаем что-то другое
        }
        else
        {
        //если свайпа не было... делаем это
        }
    }
}

End Step

Код:

x=mouse_x
y=mouse_y

Global Left Released

Код:

global.swype=0
instance_destroy()

в  Step obj_swype_main

Код:

if xstart>x//свайп влево
{
//делаем что-то
}
if xstart<x//соответственно, вправо
{
//делаем еще что-нибудь
}

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

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

Сначала нужен контроллер, пишем в Create:

Код:

global.pad=0

Далее создаем Global Left Pressed ивент и пишем код:

Код:

if global.pad=0
{
    global.pad=1
    instance_create(mouse_x,mouse_y,obj_pad)  
}

Собственно, создаем сам obj_pad и идем в ивент Step :

Код:

if point_in_circle(mouse_x,mouse_y,xstart,ystart,96) //ограничиваем движение пада по кругу в радиусе 96 пикселей
{
    x=mouse_x
    y=mouse_y
    lenght_a=point_distance(x,y,xstart,ystart) //узнаем расстояние от начальной точки
    dir_a=point_direction(xstart,ystart,x,y)           //узнаем направление отклонения от начальной точки
    global.pad_dir=dir_a //(опционально) передаем в глобальные переменные
    global.pad_lenght=lenght_a
}
else
{
    x=xstart+lengthdir_x(96,point_direction(xstart,ystart,mouse_x,mouse_y)) //запрещаем движение за пределами радиуса
    y=ystart+lengthdir_y(96,point_direction(xstart,ystart,mouse_x,mouse_y)) //но разрешаем передвижение по краям
    lenght_a=point_distance(x,y,xstart,ystart) //все равно собираем данные
    dir_a=point_direction(xstart,ystart,x,y)
    global.pad_dir=dir_a  //и все равно передаем их в globalvar
    global.pad_lenght=lenght_a
}

Дальше нужен Draw, в котором рисуем круг за самим стиком:

Код:

draw_self()
draw_sprite(xstart,ystart,spr_dpad_circle)

Global Left Released:

Код:

instance_destroy()//убиваемся
global.pad=0 //обнуляем значение контроллера
global.pad_lenght=0 //обнуляем значение длинны, но не обнуляем направление

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

Для мультитача преобразовать проще простого.

Вроде бы просто и работает.
Надеюсь, статья для вас хоть мало-мальски полезной оказалась...

(Прим. возможно дополню статью дополнительными плюшками насчет управления на сенсорниках)

[Fur]

Кучи объектов, совершенно не правильная реализация стика. (Однако хотя бы не встроенными виртуальными кнопками). Свайпы вообще какая-то жуть.
Ты б сам для начала прочитал, как это правильно делается. Можешь начать с события Draw GUI и функций mouse_*.

Алсо, теме не место в статьях, ничему хорошему она не научит.

[Christopher]

Свайпы вообще какая-то жуть.
Ты б сам для начала прочитал, как это правильно делается. Можешь начать с события Draw GUI и функций mouse_*.

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

НУ почему же... про кнопочки хардовые хоть кто-то, что-то да узнает 

[Fur]

про функции и Draw GUI прекрасно знаю, принцип от того, где используется вообще не поменяется, на самом деле

ГУИ очень сильно облегчает жизнь. Если в игре есть камера и движущиеся виды, то полетит твоя система к чертям. .-.

[Neo]

Достаточно бесполезная тема, если её не дорабатывать только по той причине, что примеры реализаций управления для сенсорных экранов поставляются вместе с самим ГМСом (вернее есть в списке примеров, но нужно докачать), где, помимо наличия исходного кода, дается описание по примеру и используемых функциях для достижения задуманной цели и наличие возможности проверить это на практике. Ну а тут я вижу какой-то костыль и достаточно глупую реализацию объектами. Конечно, это не есть плохо, но так делать крайне не рекомендуется. Бывают такие случаи, что по чистой глупости кто-то забывает добавить в ход соответствующий экземпляр объекта, который работает только в паре с другим, после чего некоторые такие личности бегут на форумы со своей проблемой.

Так же предлагаю ознакомиться с простым однообьектным джойстиком, который можно применять как SixAxis или стики на Dualshock контроллерах.

О реализации аналогового контроллера на форуме было не 1 и 2 примера(О, да! Оно же есть еще и в том списке примеров ГМС. Совпадение? Возможно.). Нет никакого смысла дублировать. Да, я имею ввиду дублировать, а не просто дублировать.

про функции и Draw GUI прекрасно знаю, принцип от того, где используется вообще не поменяется, на самом деле

ГУИ очень сильно облегчает жизнь. Если в игре есть камера и движущиеся виды, то полетит твоя система к чертям. .-.

Всегда делал привязку view_ функциями, выполняя отдельно от всего в соответствующем объекте, предназначенный для манипуляции видами, но DrawGUI все еще считаю несколько бесполезным.

Однако хотя бы не встроенными виртуальными кнопками

А что с этим не так?

[Dmi7ry]

Всегда делал привязку view_ функциями, выполняя отдельно от всего в соответствующем объекте, предназначенный для манипуляции видами, но DrawGUI все еще считаю несколько бесполезным.

То есть постоянно пересчитывать координаты и масштаб всех элементов GUI (как для отрисовки, так и для событий нажатия) более полезно, чем не делать этого? 

[NickLatkovich]

DrawGUI все еще считаю несколько бесполезным.

А если надо нарисовать GUI в 3D игре, например FPS. Тоже будешь считать DrawGUI бесполезным? Мало того, что для отрисовки интерфейса нужно будет выделять целый объект, с самой низкой глубиной (в то время как игрок должен быть, наоборот, с самой высокой глубиной) так ещё и дополнительную проекцию нужно будет установить, а это дополнительные как минимум три строчки (включить ортогональность, выключить удаление скрытых сюрфейсов и включить её после отрисовки ГИПа). Подведём итог:

Отрисовка GUI без помощи DrawGUI

Код:

1) Создать новый объект.
2) Установить ему низкую глубину.
3) Создать событие Draw.
4) Включить ортогональную проекцию.
5) Выключить удаление скрытых сюрфейсов.
6) Нарисовать GUI.
7) Включить удаление скрытых сюрфейсов.
0) Включить 3D проекцию снова.

Отрисовка GUI с помощью DrawGUI.

Код:

1) Создать событие DrawGUI.
2) Нарисовать в нём GUI.
0) Включить 3D проекцию снова ЕСЛИ она поменялась.

И что мы имеем? Ах да, мы создаём дополнительный объект, который должен работать в связке с игроком (или камерой). А как ты сам говорил:

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

Ты всё ещё считаешь DrawGUI бесполезным?

[luden]

Всегда делал привязку view_ функциями, выполняя отдельно от всего в соответствующем объекте, предназначенный для манипуляции видами, но DrawGUI все еще считаю несколько бесполезным.

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

[NickLatkovich]

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

Кстати да, отличный пример)

[Neo]

Всегда делал привязку view_ функциями, выполняя отдельно от всего в соответствующем объекте, предназначенный для манипуляции видами, но DrawGUI все еще считаю несколько бесполезным.

То есть постоянно пересчитывать координаты и масштаб всех элементов GUI (как для отрисовки, так и для событий нажатия) более полезно, чем не делать этого? 

Перечитал по событию и вроде работает так же, как и

Код:

d3d_set_projection_ortho()

для случая с 3D, но как насчет динамического интерфейса, к примеру, существует какой-то противник и рядом с ним рисуется короткая сводка по статистикам?

DrawGUI все еще считаю несколько бесполезным.

А если надо нарисовать GUI в 3D игре, например FPS.

Уже практиковал с такой динамической камерой и элементы интерфейса оставались статичными.

И что мы имеем? Ах да, мы создаём дополнительный объект, который должен работать в связке с игроком (или камерой). А как ты сам говорил:

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

Немного не ту мысль уловил. Под своим сообщением я имею ввиду, что было бы неплохо использовать

Код:

point_distance()

,чем

Код:

distance_to_object()

,что позволит сфокусироваться на одном экземпляре объекта, чем использовать пару.

[Fur]

Однако хотя бы не встроенными виртуальными кнопками

А что с этим не так?

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