Game maker размер окна

Game maker размер окна

Вопросы про разрешение экрана

useruser Дата: Вторник, 05 Сентября 2017, 13:35 | Сообщение # 1

Недавно начал изучать тему создания игр и Game Maker Studio 2.0.
Вопрос такой — как сделать игру под разные разрешения экрана? Планирую сделать игру в полноэкранном режиме.
Посмотрел кучу видео по этой теме и так и не нашел ответа на свой вопрос. Может что то и не понял.

Все ниже моё представление о графике и ИМХО. Возможно и неверное.
——-
Давайте разберем проблему разрешения экрана на примере игры — шахматы.
Игрок видит всю доску и фигуры на доске. Т.е. всю комнату, говоря языком Game Maker Studio.
Пусть мы нарисовали графику (растровая) для разрешения экрана 1024х768. Выглядит отлично.
Что нам теперь важно, с точки зрения графики? Две вещи — положение графики (картинок объектов) и их пропорциональность.

То есть — если у пользователя разрешение экрана не 1024х768, а 800х600 (рассмотрим простой пример с соотношением сторон 1.3) то мы должны как то уменьшить всю нашу картинку. Доску, фигуры и т.д.
И тут вопрос — как правильно это делать?

Хорошо, мы уменьшили нашу картинку. Пропорции и положение сохранено, но графика стала хуже.
Уже не видно части линий и изгибов. Объективно — уменьшение растровой графики вызовет её ухудшение.
Мы потеряем часть пикселей при уменьшении.
А вот при пропорциональном увеличении произойдет дублирование пикселей (при равном соотношении сторон) и качество графики должно остаться прежним.

Несмотря на это мы видим, что в большинстве игр то же окно авторизации (как и другие объекты) намного больше на разрешении 800х600 и меньше на 1024х768. Т.е. окно не изменяет свой размер.
Выходит окно имеет постоянный размер и только меняет позицию — всегда по центру экрана. Т.е. при запуске игры идет расчет положения объектов в зависимости от разрешения экрана?
Например в игре Warcraft 3. При низком разрешении мы увидим большие здания, юнитов и немного карты вокруг.
При высоком — мы увидим нормальные здания, юнитов и большой участок карты вокруг.
Наверно на плазменной панели на пол стены мы увидим пол карты — если игра это позволяет.

Но вернёмся к нашей игре — шахматы.
Мы хотим сделать наилучшую графику на всех разрешениях. Уменьшать — плохо.
Как сделать хорошую графику на низком разрешении?
В принципе мы можем изменить область камеры. Не показывать что за доской, а сфокусировать камеру на доске (viewport).
Тогда будет не очень удобно — часть доски может быть не видна. Но цель мы достигнем.

А если нам нужно сделать хорошую графику на высоком разрешении?
Мы можем увеличивать картинку или увеличивать область камеры. Если у нас за доской ещё что то есть.
То есть если на 1024х768 доска занимала весь экран, то на 1920х1080, при увеличении области камеры, доска будет занимать уже пол экрана.
А при увеличении картинки — графика будет пропорционально увеличена на весь экран.

Источник

Масштабирование в Game Maker

1. Проблема

Тем, кто работает с Game Maker, известно, что GM выделяет в памяти место для не сжатых картинок, не взирая на изначальный формат. То есть будь это хоть jpeg, хоть gif — GM «смотрит» на него как на bmp.

В связи с этим, рано или поздно, большинство разработчиков сталкивается с проблемой масштабирования картинки, так как «большие» изображения занимают много памяти и приводят в конечном итоге к торможению и большому времени загрузки. Значимая доля разработчиков в принципе работает с «маленькой» графикой, либо из-за ностальгии по старым приставкам, либо из-за «выдранных» ресурсов из игр для тех же старых приставок. Так или иначе, все они приходят к вопросу «как вывести на экран увеличенное в 2 (3, 4, 5) раз изображение».

Это меню настроек Game Maker. На картиночке видно, что GM позволяет запускать игру сразу же на полный экран, сделать процентное масштабирование в окне, сохранить исходные размеры даже при отображении в полном экране и так далее. Есть даже галочка «interpolate colors between pixels», которая должна по идее отвечать за включение/выключение сглаживания графики при масштабировании, но на практике это оказывается не так.

Стоит заметить, что не всем принципиально это самое «сглаживание». В основном, проблема касается тех, кто использует пиксельную графику, которая теряет огромную долю своего очарования при интерполяции. Именно для них в этом месте начинаются проблемы.

Проблема заключается в том, что GM сглаживает или не сглаживает картинку неуправляемо, основываясь на «показаниях» видеокарты. Если карта тянет — сглаживание происходит, если нет — обходится без него. Ни на какие «галки» GM при этом не смотрит.

2. Обходные пути

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

Второй путь мог бы стать решением, если бы не одно «но».


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

3. Решение

Суть третьего и единственного на данный момент более менее работающего метода заключается в использовании «поверхностей» (surface).

Углубляться в механизм действия поверхностей я не буду, однако вкратце смысл таков.

Каждый игровой шаг GM выводит картинку на экран. Фактически, он рисует прямо на экране. Однако можно рисовать вначале на surface, производить над surface какие-то действия, а результат выводить экран.

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

Для этого мы создаем три скрипта:

Затем, при запуске игры создаем постоянный (persistent) и видимый (visible) объект, в котором прописываем наши скрипты:

Событие CREATE screen_init ();
Событие BEGIN STEP screen_begin ();
Событие END STEP screen_end ();
Событие GAME END surface_free (screen);

Запускаем игру и радуемся)

Метод работает, но возможны проблемы из-за разных видеокарт. Я с ними не встречался, однако говорят, что такое бывает.

И еще, не забудьте включить использование вида в настройках комнаты, и сделать нулевой вид видимым по умолчанию. Размеры вида и порта на экран должны быть одинаковыми!

Источник

Уроки по Game Maker Studio 2 для начинающих (Часть 1)

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

Пробуем создать свой Арканоид

Я всегда всем советую начать изучение движка с создания простой игры. Да я и сам в свое время учился так. Создав 5-6 отличных друг от друга игр вы получите очень хорошую базу знаний по движку.

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

А теперь к делу.

Запускаем наш Game Maker Studio 2.

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

Нажимаем «New» , что значит «Новый» , для создания нового проекта. У вас далее появится следующий выбор:

Тут следует немного остановиться подробнее. Движок GMS2 позволяет создавать игры на своем языке программирования GameMaker Language (GML) либо вообще без написания кода, то есть собирать игру как бы из логических блоков (Drag and Drop). Я бы рекомендовал учиться сразу писать код. Но вы можете конечно попробовать поиграть с блочной системой. Конкретно в этом уроке я буду объяснять работу именно проектов на основе кода, т.е. выбираем второй вариант. Ну а далее вы выбираете место, где будете сохранять своей проект и дадите ему имя.

Готовим ресурсы для игры

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

Для игры нам будут нужны: бита, мяч, стены и блоки.

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

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

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

Назовите объекты так как я их назвал. Это пригодится далее в уроках. Итого у вас должно быть 4 спрайта и 4 объекта в дереве ресурсов.

Далее подготовим комнату и расставим все объекты в ней для первого уровня. Кроме мяча. Мяч мы будем создавать кодом.

Задайте ей размеры 960 пикселей в ширину и 540 пикселей в высоту. Создайте несколько слоев именно того типа, что я пометил стрелочкой (т.е. слои для объектов). Поменяйте им названия. Расположите их в том же порядке что у меня на скриншоте. И далее на каждый слой перетащите и расставьте соответствующие объекты, как они у меня расставлены в комнате. Т.е. на слой «Walls» , например, расставляем объекты «Wall» и т.д.

Так же можете поменять цвет фона. Для этого просто щелкаете на слой Background и чуть ниже выбираете нужный нам цвет. Но это не обязательно. Можно оставить и изначальный черный.

Обратите внимание, что мы создали еще и слой «Ball» , но на него ничего не ставим. Мы подготвили этот слой заранее, чтобы потом создать кодом на нем наш мяч (объект Ball).

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

Т.е. при запуске у вас откроется подобное окно:

Справились? Поехали дальше!

Начинаем писать логику для игры

Давайте начнем с биты, так как игрок будет управлять именно ей. Щелкнем на объект биты и создадим ей событие шага ( Step ), о котором я писал в прошлых статьях. Создаем именно событие Step , не Begin Step и не End Step . Для чего нужны они, объясню когда-нибудь в последующих статьях. Но запомните, в 95% вы будете использовать именно событие Step из этих трех возможных, так что пока не забивайте голову.

И вот наконец-то у нас открылось окно редактора кода. Как долго же мы шли к этому событию! Для начала, давайте сделаем так, чтобы бита двигалась вправо и влево по нажатию кнопок со стрелками вправо/влево на клавиатуре.

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

Т.е. если нажата клавиша «стрелка вправо» ( vk_right — это как раз обозначение этой самой клавиши), то x биты прибавит 10 пикселей, а так как ось X в GMS направлена слева-направо , то бита как раз сдвинется вправо. Вот этот код как раз отвечает за прибавление 10 к x: x+=10.

Аналогично для левой стороны. Итак, жмем клавишу для запуска игры, чтобы потестировать. Сделаю оговорку: мы очень часто будем запускать игру для проверки текущего кода, чтобы избежать ошибок на первых порах. Напишем небольшой кусочек, проверим, напишем еще — снова проверим и по такой схеме постоянно. Если возникнет какая-то ошибка, то нам проще будет найти тот участок кода, в котором мы ее допустили.

Протестировали? Хм. Код и правда УЖЕ работает не так, как нам хотелось бы, правда? Т.е. зажав стрелочку вправо, например, бита сдвинется чуть вправо и остановится, пока мы не отожмем клавишу и заново ее не нажмем. Т.е. чтобы нам двигать биту, нам нужно постоянно клацать на клавишу стрелки. Согласитесь, это не очень удобно. Что же мы сделали не так?

Все дело в том, что мы выбрали не совсем нужную нам функцию нажатия клавиши. Их существует три. Давайте подробнее на них остановимся.

  1. keyboard_check_pressed()
  2. keyboard_check_released()
  3. keyboard_check()

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

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

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

По умолчанию, GMS2 настроен вроде на 30 шагов в секунду (этот параметр можно будет поменять потом). Т.е. каждую секунду весь код в Step’е будет выполнен от начала до конца аж 30 раз! Соответственно, если мы зажмем и будем не отпускать стрелку вправо при такой функции, то за секунду бита уедет аж на 300 пикселей вправо (30 раз * 10 пикселей сдвиг за шаг).

Меняем код и пробуем:

Теперь не нужно жмякать на стрелочки, чтобы сдвигать биту каждый раз по чуть-чуть, а просто нажимаем клавишу и наслаждаемся «полетом» биты!

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

Теперь бита кажется более плавной. А давайте вообще заменим скорость переменной, чтобы можно было потом в самой игре менять скорость движения биты, например, когда подбираем какой-нибудь бонус. Согласны?

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

Создаем событие Create (так же как мы создавали Step ) и в нем напишем всего одну строчку кода:

А в самом событии шага (Step) чуть изменим код на такой:

Т.е. мы просто цифры заменили именем переменной, а так как она равна 5, то результат при запуске будет тот же. Но в дальнейшем нам это пригодится.

Не люблю повторяться, об этом я писал в прошлых статьях, но тут все таки сделаю исключение. Напомню, что событие Create выполняется лишь раз, в момент создания объекта. Т.е. весь код, что написан в событии Create выполнится лишь раз, в самом начале, в отличии от Step , где он выполняется циклически, т.е. неприрывно.

Делаем столкновения со стеной

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

Т.е. что нам нужно сделать? Алгоритм такой:

  1. Проверить нажата ли клавиша вправо
  2. Проверить находится ли бита все еще левее самой крайней стены
  3. Если да, то только в этом случае сдвигаем ее на 5 пикселей вправо

Тоже самое потом проделываем и для левой стороны. Чуть дорабатываем наш код:

Ну, давайте разбираться, что мы тут написали.

Сначала как и прежде первой строкой проверяем нажата ли клавиша «стрелка вправо». И если она нажата, то все, что идет далее между скобок <> будет выполняться, если нет, то код в них просто будет игнорироваться.

А в скобочках у нас еще одно условие (if). Им мы проверяем если x-координата биты меньше значения 891, то можем выпонить код следующий далее в скобках <>. А в нем у нас как раз прибавление координаты x на 5 пикселей, т.е. сдвиг вправо. Таким образом, если у нас x биты меньше 891, то она сдвинется вправо, а если больше или равно, то код в скобках не будет выпоняться, т.е. бита не сдвинется и будет стоять, т.е. как бы упрется в стену.

То же самое для левой стороны, только там условие чуть отличается. Если x больше 67, то бита сдвинется влево на 5 пикселей, если меньше или равно 67, то соответственно нет.

Где я взял эти значения: 67 и 891? Это просто координаты в комнате. Как уже сказал, ось X в GMS идет слева направо. Т.е. самая левая координата комнаты будет равна 0, а самая правая — значению ширины комнаты (которое мы задавали при создании комнаты, т.е. 960 пикселей в нашем случае).

Сетка в комнате у нас идет размером 32 на 32 пикселя. На рисунке я пометил как расположена ось X (ось Y кстати направлена сверху вниз, но об этом потом).

Координата x биты находится в ее центре (помните, при создании спрайта, мы указывали куда расположите его центр (он был отмечен крестиком — так вот там мы как раз определяли, где будет находится x и y координата нашего спрайта/объекта)

Я пометил точки на уровне (64 пикселя и 896), но почему я в условиях поставил не эти цифры? Попробуйте заменить на них и увидете, что бита будет чуть заезжать в стену. Т.е. мы не учитываем еще и скорость, у нас же бита смещается на 5 пикселей, а сетка 32. Т.е. координата ровно не делится. По этому я отнял значение скорости (64+5=69 и 896-5=891). А вот скажем если скорость поменять с 5 на 2, например (в Create поменять код на spd=2), то в условии можно будет оставлять 64 и 896, ведь бита теперь будет смещаться ровно по 2 пикселя, т.е. кратно сетке.

Ну тут нужно немного практики и понимание координатной плоскости и умение считать. Если вы кстати поводите курсором в редакторе комнат по сетке, то увидите координаты комнаты, где расположен курсор, это может вам немного помочь на первых порах понимать координатную плоскость.

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

Пока, пробуйте, эксперментируйте. И не забудьте сохранить своей проект.

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

Источник

Читайте также:  Отделка окон пластиковыми откосами снаружи
Поделиться с друзьями