Создание скриптов на RGSS для людей со средними знаниями и экспертов

**Arnon** · 24.01.2010, 15:48

4. Окна

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

4.1. Основы

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

Окна состоят из нескольких спрайтов и многие из них вызывают лаги.
Окна использует рисунок под называнием contents, его размер практически идентичен размеру окна, однако, меньше на 32 пикселя по ширине и 32 по высоте и его координаты x и y смещены на 16 пикселей. Если окно меньше 33×33 пикселей, и вы попытаетесь создать его рисунок стандартными средствами, то появится ошибка: невозможно создать Bitmap (could not create Bitmap).
Перерисовка содержимого окна (обычно этот метод называется refresh) занимает время и вызывает лаги. Лучше всего перерисовывать окна в тот момент, когда их содержимое изменилось.
НИЗАЧТО не перерисовывайте окна всё время! Обновляйте — да, но не перерисовывайте (refresh).
Перемещение окон занимает время и вызывает лаги.
Изменение атрибутов x и y перемещает окно, в то время как изменение атрибутов ox и oy заставит переместиться рисунок (bitmap), а не само окно.
Позиция z — это значение третьего измерения, которое определяет как «высоко» должно окно отображаться над другими окнами, спрайтами и т.д. Чем больше это значение, тем окно ближе к игроку.
Если рисунок окна превышает его размеры, то появятся маленькие стрелки, взятые из графики обложки окна (windowskin). Держите размеры рисунка под контролем, чтобы избежать этого.
Если вы сделаете окно активным (active), то курсор (если таковой присутствует) начнёт мигать, тогда как в неактивных окнах его анимация замораживается. Чтобы удалить курсор по умолчанию, вам нужно установить index окна равным -1. Для этого вы можете использовать команду self.index, но не обращайтесь к @index напрямую. Помните, что только в Window_Selectable есть методы управления курсором, а в Window_Base их нет. Однако, вы можете создать ваш собственный класс окна, который сможет работать с курсором и при этом основываться на Window_Base.
Если вы установите окно в режим паузы (pause), то внизу появится маленький индикатор, который знаком вам по окнам сообщений и предназначен для ожидания ввода от пользователя.
Уничтожайте окна (dispose), если вы не используете их часто или они вам больше не нужны. Не забывайте установить переменную, в которой содержится экземпляр окна на nil. Своевременное уничтожение окон и их создание — это ключ к избавлению от лагов, даже если ваши окна анимированные (т.е. перемещаются).
Не делайте окна больше, чем необходимо. Чем оно больше, тем больше лагов оно вызывает.

В RGSS есть сверхкласс Window с которого наследуются все основные параметры. Любые его экземпляры создаются с уже определенными спрайтами, что довольно быстро, так как класс Window скомпилирован в библиотеке RGSS10XX.dll. Window_Base — это класс с дополнительными методами, которые помогут в работе с окнами. Window_Selectable — подкласс Window_Base и используется для создания окон с элементами выбора, так как в нём для этой цели специально предопределены полезные методы.

4.2. Неправильный способ создания окон

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

Код:

class My_Window < Window_Base
  def initialize
    super(x, y, w, h)
    self.contents = Bitmap.new(width - 32, height - 32)
    self.contents.font.name = ‘Arial’
    self.contents.font.size = 22
    refresh
  end
  def refresh
    self.contents.clear
    self.contents.draw_text(x, y, w, 32, ‘string’)
  end
end

Если вы создадите окно неправильным способом, то оно будет ужасно выглядеть (схема 4.2.1.). Представьте себе такой метод прорисовки:

Код:

  def refresh
    self.contents.clear
    self.contents.draw_text(13, 2, 128, 32, 'This')
    self.contents.draw_text(53, 7, 128, 32, 'window')
    self.contents.draw_text(111, 5, 128, 32, 'looks')
    self.contents.draw_text(140, 12, 128, 32, 'awful!')
  end

схема 4.2.1. – это окно выглядит ужасно

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

Код:

  def refresh
    self.contents.clear
    self.contents.draw_text(0, 0, 128, 32, 'This')
    self.contents.draw_text(72, 0, 128, 32, 'window')
    self.contents.draw_text(0, 28, 128, 32, 'looks')
    self.contents.draw_text(72, 28, 128, 32, 'better!')
  end

схема 4.2.2. – это окно выглядит намного лучше

Числа 128 и 32 служат специальной цели. 128 — ширина прорисовки. Если ваш текст слишком большой и не влезает в эту границу, то он будет сжат. 32 отвечает за высоту. В основном его можно оставить таким же, 32, так как обычно высота играет меньшую роль, особенно если она больше необходимой. Размер высоты чаще всего совпадает с размером шрифта, однако некоторые шрифты на самом деле всё же могут быть больше, чем их размер. К примеру, размер шрифта равен 24, но размер высоты прорисовки должен быть большее, 26.

схема 4.2.3. – сжатый текст

схема 4.2.4. – высота слишком мала

Я очень рад, что окна в RGSS ограничены прямоугольной формой… Пробуйте создавать свои окна и отыщите ещё больше неправильных способов их отрисовки. И во имя всего святого, ни за что не используйте их!

4.3. Насколько хорошо они выглядят?

схема 4.3.1. – ужасные окна!

Хотя, по правде сказать — они не такие ужасные. По крайней мере, на схеме 4.3.1. Что не так на этом скриншоте? Я имею ввиду, почему они ужасно расположены? Есть три возможные причины этого беспорядка:

a) размер окон
b) позиция окон
c) смещение рисунка окон

Позвольте сразу дать совет: лучше всего создавать все окна с размерами, делящимися на число 32 (64, 96, 128…) или, в некоторых особых случаях, на 16 (48, 64, 80, 96, 112…). Так же важно не задавать размеры меньше 33×33, в противном случае вы получите ошибку.

Позиция окна — это немного другая история. Рекомендуется задавать такие расположения окон, координаты (x и y) которых делятся на 8. Если вы перемещаете окно, то на время можете проигнорировать это (эстетическое) правило, пока оно не достигнет своей окончательной позиции.

Последним, с чем может быть проблема, является превышение рисунком размеров окна (а также позиции, ox и oy). Обычно вам нужно избегать этого. Единственная ситуация, в которой имеет смысл создавать рисунки больше окон — это прокручиваемые окна.

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

схема 4.3.2. – хороший порядок окон

Взгляните на схему 4.3.2. Разве она не выглядит лучше? Вот свойства окон:

Код:

1.	x = 0, 		y = 0, 		width = 160, 		height = 224
2.	x = 0, 		y = 224, 	width = 160, 		height = 96
3.	x = 0, 		y = 320, 	width = 160, 		height = 96
4.	x = 0, 		y = 416, 	width = 160, 		height = 64
5.	x = 160, 	y = 0, 		width = 480, 		height = 480

(где x — координата x, y — координата y, width — ширина, height — высота)

Скорее всего, вы уже заметили, что все номера имеют общий делитель: 32.

Со следующей проблемой сталкиваются практически все начинающие скриптеры. Знакома ли вам ситуация показанная на схеме 4.3.3?

схема 4.3.3. – проблемы со стрелками

Как уже неоднократно говорилось ранее, это происходит, потому что рисунок больше чем размеры окна. В предоставленном примере окно размером 96×64, а его рисунок больше 64×32. Один простой способ избежать этого нежелательного эффекта заключается в указании специальных размеров рисунка в def initialize.

Код:

  def initialize
    …
    self.contents = Bitmap(width - 32, height - 32)
    …
  end

Нужная часть выделена красным жирным начертанием. width и height — методы, определяемые в классе Window, которые соответственно возвращают ширину и высоту текущего окна. Главное чтобы слова width и height не были переопределены в методе в качестве локальных переменных. Наш трюк поможет избежать появления стрелок, даже если размеры рисунка всё равно больше чем окно, он просто укоротит его.

И последняя проблема связана с позицией окна. Взгляните на схему 4.3.4.

схема 4.3.4. – картина, от которой младенцы сразу начинают плакать

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

схема 4.3.5. – похоже что дизайнер что-то перепутал

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

схема 4.3.6. – ничего особенного, но выглядит лучше

4.4. Окно или спрайт

Выбирайте окна, если вы хотите чтобы использовалась графика обложек. Если вы хотите создать прозрачный фон или особое изображение фона, не используйте окно с прозрачностью = 0, используйте спрайт. Помните, что вы столкнетесь с риском того, что вам придется заново переписывать код специальных методов (вроде draw_actor_hp) или скопировать их из класса Window_Base. Хотя это может оказаться даже лучшим вариантом, например, если вы хотите использовать шрифт поменьше и т.д. Но будьте осторожны, ведь вам придётся написать больше кода, а значит, его впоследствии будет труднее понять. В любом случае это уменьшит количество лагов в вашем интерфейсе, ДАЖЕ ЕСЛИ вы напишите больше кода (смотри пункт [IURL="http://rpgmaker.su/showthread.php/518-Создание-скриптов-на-RGSS-для-людей-со-средними-знаниями-и-экспертов?p=9619&viewfull=1#post9619"]5.4[/IURL]).

4.5. Основы графического интерфейса (HUD)

Есть 4 важные вещи, которые вы должны помнить при создании собственного HUD:

Если ваш HUD можно отключить, то убедитесь, что вы УНИЧТОЖИЛИ (DISPOSE) ваши окна/спрайты, а не просто сделали их невидимыми. Вам придётся написать больше кода, однако количество лагов заметно уменьшится.
Отображайте только ту информацию, которую игроку очень нужно видеть всё время. Показывать, например Силу бессмысленно, так как она не так часто меняется и не важна для игрока постоянно, а займёт лишь больше ресурсов и места на экране.
Обновляйте HUD ТОЛЬКО, если данные изменились. Карта уже перегружена спрайтами событий и меньше всего ей нужно обновлять ваш HUD каждую секунду или ещё хуже, каждый кадр. Чтобы сделать это, храните все ваши отображаемые данные в экземплярах переменных и сравнивайте их в методе update с текущими значениями. Если какое-нибудь значение изменилось, обновляйте HUD и записывайте новые значения. Вы можете пойти дальше и обновлять только ту секцию, которая изменилась. Вам потребуется больше кода, но это поможет снизить время обновления. Например, представьте 20 значений, каждому из которых требуется 0.01 секунды для прорисовки. Это приведёт к 0.2 секунды перерисовки всего HUD, причём каждый раз будут заметные на экране лаги. Если же вы перерисуете только ту секцию, которая изменилась, то вам понадобятся номинальные 0.01 и этот процесс пройдёт незамеченным. Вы можете удалить отображаемые части экземпляра Bitmap используя fill_rect(x, y, width, height, Color.new(ANY, ANY, ANY, 0)). Это удалит выбранную область рисунка и вы сможете нарисовать новую информацию. Если вы хотите пойти ещё дальше, то прекратите обновлять статически слова, вроде HP, SP или EXP. В зависимости от того как выглядят ваши изменяемые значения (числа, градиенты и т.п.), возможно вам даже не потребуется удалять их fill_rect перед перерисовкой. (Для своего HUD я прорисовываю значение HP на полосе градиента. Таким образом мне не нужны статические слова HP/MAXHP, всё итак понятно. Мне также не нужно очищать секции градиента перед перерисовкой.)
Учитывайте дилемму о спрайтах и окнах (смотрите пункт [IURL="http://rpgmaker.su/showthread.php/518-Создание-скриптов-на-RGSS-для-людей-со-средними-знаниями-и-экспертов?p=9618&viewfull=1#post9618"]главе 8[/IURL]).

4.6. Проблема с отображение не важной информации

Прежде всего, вам необходимо решить: какие данные важны, а какие нет. HUD, который содержит количество золото и значок будет вызывать лаги каждый раз при перерисовке, занимать место на экране, а обновляться будет лишь после битвы. Если вы работаете над боевой системой ABS, то возможно оно будет обновляться чаще. Но, в конце концов, зачем игроку в глубоком подземелье нужно знать своё благосостояние всё время пока он там? Он, например, может вызывать меню и посмотреть там, если его и правда это интересует. Как уже было сказано, только для ABS это может пригодиться и только, если сделать эти данные небольшими на экране. Наиболее важная информация: HP, SP, EXP и другие значения важные для битвы, вроде накопленных комбо-ударов, процента ярости, выносливости и др. Так же в большинстве случаев HUD вам вообще не понадобится, потому что свои задачи он выполняет только в боевых системах вроде ABS. Или HUD пригодится для мини-игр, специальных параметров, вроде выносливости и т.п. К другому же использованию стоит присмотреться, стоит ли увеличивать лаги на карте, которые итак уже есть благодаря событиям и спрайтам. Не говоря уже об огромных картах размером 200×200.

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

4.7. RAM или CPU?

В этой главе вы должны были усвоить идею о том, как заставить ваши окна выглядеть профессионально. В отличие от хаотичного дизайна живой природы, случайность — это табу при создании окон. Не отображайте бесполезной и ненужной информации и не перерисовывайте постоянно ваши окна. Используйте спрайты, если вам нужно создать прозрачный фон и/или вы используйте фоновое изображение. Вы можете нарисовать изображение прямо на спрайте. Так же не забывайте о правиле 32 пикселей. Оно поможет вам сэкономить время при проектировании, ведь у вас будет только 20×15 (640/32×480/32) возможных позиций окон вместо 640×480.

[IURL="http://rpgmaker.su/showthread.php/518-Создание-скриптов-на-RGSS-для-людей-со-средними-знаниями-и-экспертов?p=9614&viewfull=1#post9614"]Вернуться к содержанию...[/IURL]