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

**Arnon** · 24.01.2010, 15:48

6. Улучшаем свои навыки

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

6.1. Скрипты с фигурными {} скобками

Чтобы в самом начале отсечь все недоразумения, поясню, что команда {…} делает абсолютно то же самое, что и do … end. Они обе используются для определения блока. В блоке команды собираются вместе и интерпретируются в целом. Это МОЖЕТ улучшить производительность вашего скрипта, если используется правильно, но совсем не обязательно. Все локальные переменные, определённые в блоке удаляются после выхода из этого блока.

Код:

loop {
  a = 0 if a == nil
  a += 1
  break if a == 100
}
a.ceil

Такой код покажет ошибку undefined method or variable (неопределённый метод или переменная) для объекта a. Более подробную информацию можно найти в файле помощи к RMXP. Помните, что фигурные скобки {} используются и для определения хэша Hash — произвольного класса в RGSS, который очень похож на Array, где для определения используются квадратные скобки []. Фигурные скобки {} также указываются во время внедрения переменной в строку (смотрите раздел 5.3). Вы видите, что у {} есть несколько функций. Таким образом, один лишь факт использования фигурных скобок {} в скриптах не делает вас крутым скриптером, даже если вы подражаете более известным личностям.

6.2. Однострочные методы и функции

Однострочные методы и функции — это напрасная трата свободного места в коде. Для того чтобы разобраться, почему они являются операциями, занимающими лишнее время, нужно понять что происходит во время вызова такого метода. Я дам только краткое объяснение принципов работы архитектуры CPU, потому что всё описание целиком может занять целую книгу.

У процессоров обычно есть несколько регистров, которые выступают в качестве рабочей памяти, которая хранит обрабатываемые в настоящий момент данные (у разных CPU разное количество регистров, так например у Pentiums 4 их 128, у более старых ARM их 37, и т.д.) Эти регистры намного ближе к самому процессору, чем так называемый L1 кэш. Процессор работает непосредственно с этими регистрами. Обычный размер регистра равен 32 битам (или 4 байтам), но в настоящее время всё более популярны на рынке процессоры с 64-битными регистрами.

Ваш код в скрипте не запускается в таком виде, как он есть, для начала его нужно перевести на язык понятный процессору. Так как RGSS является объектно-ориентированным языком (в главе 8 это описано более подробно), то процесс перевода довольно сложен. За первые шаги перевода ваш код чаще всего трансформируется в более простой код (который занимает больший объём), где, допустим, ваши циклы полностью упрощаются. В конце код переводится в ассемблерные команды и затем в машинный код. Некоторые интерпретаторы без встроенной оптимизации могут перевести код сразу в команды ассемблера, который займёт меньше места, но замедлит работу CPU из-за выполнения множества ненужных команд.
Во время вызова функции в вашем компьютере происходит следующее:
- Все команды в вычислительном конвейере необходимо усечь, что приводит к потере 20 циклов процессора на Pentium 4 и означает, что простой вызов метода уже занимает такое же время, как 20 операций сложения.
- Процессор хранит адрес текущей команды в оперативной памяти (RAM) в стеке, который занимает времени на обработку в 10 или 15 раз, чем время, за которое CPU бы сложил два числа.
- Теперь все аргументы, которые передаются на функции, должны быть добавлены в стек, что снова отнимает время у процессора.
- Теперь за дело берётся т.н. счетчик команд (который определяет адрес следующей выполняемой команды) и устанавливается адрес переводимой функции.
- Вычислительный конвейер заполняется, от чего следует, что CPU нужно подождать ещё 20 циклов до выполнения следующей команды.
Теперь функция запускается на выполнение. После того как достигнуто её окончание, запускается очень похожий процесс, который восстанавливает старую позицию в коде, в которой следует продолжать выполнение. Плюс ко всему в стеку сохраняются все возвращаемые значения, ведь CPU нужно получить доступ к результатам выполнения функции уже после её выполнения, в том месте, где она вызывалась. И вот вновь вычислительный конвейер нужно заполнить командами ожидающими выполнения с того места, где обработка остановила выполнение кода для перехода к адресу функции.

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

Код:

def sum_two_numbers(a, b)
  return a + b
end

Код:

class Scene_Load < Scene_File
  def commandnewgame_partysetup
    $game_party.setup_starting_members
  end
end

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

Код:

class Game_Enemy
  def gold
    return $data_enemies[@enemy_id].gold
  end
end

Избегайте однострочные методы любой ценой. Ещё немного информации об архитектуре процессора можно найти в [IURL="http://rpgmaker.su/showthread.php/518-Создание-скриптов-на-RGSS-для-людей-со-средними-знаниями-и-экспертов?p=9622&viewfull=1#post9622"]главе 8[/IURL].

6.3. Бесполезные и бессмысленные команды

Как же я обожаю такие вещи. Встречаются люди, которые публично заявляют себя великолепными скриптерами и каким-то образом другие люди им верят, хотя такие ораторы совершают грубые ошибки и пишут код из 20 строчек там, где можно обойтись лишь 10. Это не было бы так плохо, не будь их ошибки очевидными. Я не буду называть имя автора следующего кода, но я думаю его довольно легко узнать. Он позволяет переключить лидера партии путём последовательного выбора каждого героя при нажатии кнопок L или R (Q или W). Взгляните на следующий код и, скорее всего, вы найдете способ сократить его самостоятельно.

Код:

class Game_Party
  def shift_forward
    @actors << @actors.shift
    $game_player.refresh
  end
  def shift_backwards
    @actors.insert(0, @actors.pop)
    $game_player.refresh
  end
end
class Scene_Map
  alias_method :s____partycycling_scnmap_update, :update
  def update
    if Input.trigger?(Input::L)
      $game_party.shift_forward
    elsif Input.trigger?(Input::R)
      $game_party.shift_backwards
    end
    s____partycycling_scnmap_update
  end
end

Не правда ли он прекрасен? О да, прекрасен в своём безобразии. Следующий код будет делать то же самое:

Код:

class Scene_Map
  alias upd_ptc_later update
  def update
    if Input.trigger?(Input::L)
      $game_party.add_actor($game_party.actors.shift.id)
    elsif Input.trigger?(Input::R)
      $game_party.actors.unshift($game_party.actors.pop)
      $game_player.refresh
    end
    upd_ptc_later
  end
end

Это возвращает нас к названию этого раздела: используйте то, что уже есть. Я использовал метод add_actor из класса Game_Party, в котором уже есть вызов функции $game_player.refresh. Так как нет способа добавить героя на первую позицию в партии и передвинуть каждого героя на одну позицию, я удалил последнего героя (pop) и поставил его на первое место (unshift) (смотрите [IURL="http://rpgmaker.su/showthread.php/518-Создание-скриптов-на-RGSS-для-людей-со-средними-знаниями-и-экспертов?p=9617&viewfull=1#post9617"]раздел 3.3[/IURL] где описывается принцип работы с массивами). Используйте то, что вам дано, не пишите новый код, если он не нужен. Вызов метода является очень дорогостоящей операции ко времени выполнения, особенно одностроковые методы (смотрите [IURL="http://rpgmaker.su/showthread.php/518-Создание-скриптов-на-RGSS-для-людей-со-средними-знаниями-и-экспертов?p=9620&viewfull=1#post9620"]6.2[/IURL] для подробностей). Обратите внимание, как мне удалось управлять массивом @actors с помощью вызова методов pop и unshift и это не смотря на то, что массив @actors приватный экземпляр переменной в Game_Party, и доступен только для чтения, но не для изменения. Это значит, что вы можете обратиться к $game_party.actors, но не можете ничего изменить $game_party.actors = something (смотрите 7.8. для подробностей).

6.4. Слишком много SephirothSpawn’а

Смотрите разделы 6.2., 6.3., 6.5. и 6.7., где описаны все типичные ошибки.

6.5. О том как не выставить себя дураком

Что я понимаю под дураком: это когда автор скрипта, во-первых, полон невежества, во-вторых, высокомерен и в-третьих, предосудителен. Если это не о вас, то можете пропустить эту часть.
Если кто-нибудь обнаружил в вашем творении баг, ОБРАТИТЕ НА ЭТО ВНИМАНИЕ. Не говорите “Это твоя вина, у меня всё работает.” Конечно, можно упомянуть “Попробуй установить последнюю версию.”, может вы уже исправили его там. Но если пользователь уже использует новую версию, то постарайтесь найти ошибку. Очень часто происходят такие ситуации, когда вы не рассмотрели все возможные результаты обработки скрипта или же просто допустили опечатку. Так же бывает, что обычное изменение кода (даже если вы вносили исправление!) приносит новые баги. Чем больше и сложнее ваш скрипт, тем больше вероятность произвести баг. А чем больше скриптов в проекте, тем больше вероятность, что они будут конфликтовать друг с другом. Даже сделав ваши собственные скрипты совместимыми друг с другом, вы можете избежать многих ошибок, будь это скрипт с 5 или 1000+ строками кода, или очень сложная система (вроде энкодера или дектриптора).

Если кто-то у вас попросит помощи разобраться с чужим скриптом, не делайте кислую мину и не говорите “Чего?! Это не мой скрипт. Иди к его автору. Тут одни нубы!” Не надо обижать новичков исходя только из того факта, что вы не автор. Само собой очевидно, что автор лучше разбирается в своём творении, но вы всегда можете сказать “Я посмотрю, но ничего не обещаю. Будет лучше связаться с автором, он лучше знает свой скрипт.” Это имеет отношение не столько к скриптам, сколько к хорошим манерам. Очень неприятно видеть именитых скриптеров, которые ведут себя не самым лучшим образом. Разочарование от их слов разрушает ваше представление о человеке и в дальнейшем с ним не захочется иметь ничего общего.
Никто не будет использовать ваши скрипты, если вы грубиян. В мире много и других отличных скриптеров на RGSS. К тому же если вы читаете эту электронную книгу, то вы, скорее всего, не один из лучших.

6.6. Повторное изобретение колеса

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

Вам нравится панельки у SephirothSpawn’а? Или у Trickster’а? А может мои? Но почему бы не попробовать создать их самостоятельно? Скачайте все наши работы, сравните их, разберитесь, как они работают и (что наиболее важно) почему они работают. Затем попробуйте создать собственный скрипт. Да, вы снова изобретёте колесо, но это будет хорошим опытом. Вы узнаете, как работать с рисунками и как создавать их с помощью скриптов.

Вы можете подумать “Но скрипт, который мне нужен УЖЕ существует. Зачем создавать ещё один? Ведь он будет точно таким же…” Это не так. Ваш код никогда не будет идентичен другим. Он может быть похож, но не точно таким же (если только ты не скопипастишь, ворюга!). Ваши мысли о том как долны работать вещи, например, переключение игроков в партии, скорей всего, будут полностью отличаться от идей других людей. В этом случае у вас должна быть задача “Сделать скрипт лучше, чем этот парень.” Учитесь на чужих ошибках. Улучшение не значит лишь добавление новых фишек или изменение внешнего вида. Улучшение также может означать избавление от ненужного кода и замена его на полезный код.

С другой стороны, можно сделать свой скрипт легким для понимания, даже путем добавления кода. Само собой лишь пара новых методов каши не сварят. Вам нужно будет составить коллекцию методов, которые другие люди смогут использовать в нужной для них ситуации, а не дожидаться пока посыпятся “А как мне сделать это и это? Помоги мне?” Не бойтесь и сами задавать такие вопросы, вы ничего не теряете.

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

6.7. Навязывание стандартов

НЕ НАВЯЗЫВАЙТЕ СТАНДАРТЫ! Наличие стандартов — это хорошо, использование стандартов — тоже неплохо, но навязывание стандартов — это кривая дорожка корпорации Microsoft: Людям приходится использовать их, или всё пойдёт не так. Люди такие существа, у которых есть идеалы и индивидуальные особенности. Навязывая им свои стандарты, вы ОБЯЗАТЕЛЬНО наживёте себе врагов, которые не согласны с вашим подходом. Именно поэтому из принципа многие не станут использовать ваши скрипты или им просто не захочется внедрять их в свои игры, потому что они не совместимы с другими системами. В итоге вы окажитесь невежественным придурком, постоянно повторяющим “Вам нужно это, вам нужно то, вам нужно третье, чтобы мой скрипт заработал, потому что он основан на стандартах и ни на шаг от них не отойдёт.”, особенно если это даже не общепринятый стандарт. О том, как не выставить себя дураком смотрите в разделе 6.5.

Не поймите меня неправильно, стандарты хороши, но только не тогда, когда они надуманы самим автором. В них нет никакого смысла, если не ВСЕ ЛЮДИ пользуются и следуют им. Если у вас нет полномочий для обеспечения соблюдения стандарта, не делай их!

Маленькая заметка на полях: SDK (Standard Development Kit = Стандартный комплект разработчика) весьма ироничное название, потому что на самом деле оно не соответствует самоопределению «Стандартный». Не существует такой вещи, как стандартная зависимость. SDK своим существованием вызывает только несовместимость в скриптах, разделяя их на использующие и SDK не использующие SDK скрипты, независимо от того, применяются ли псевдонимы (смотрите раздел [IURL="http://rpgmaker.su/showthread.php/518-Создание-скриптов-на-RGSS-для-людей-со-средними-знаниями-и-экспертов?p=9616&viewfull=1#post9616"]2.1[/IURL]). SDK 2.x ещё более несовместимы, чем скрипты для SDK 1.x. Даже сегодня в программировании не существует стандартов, так как это довольно творческая ветвь индустрии. Просто к настоящему времени достаточно развиты лишь несколько методов и подходов для программирования. Стандарты не имеют никакого смысла, пока все повсеместно не начнут их использовать. А этого никак нельзя достичь, навязывая их, особенно, заявив, что ваши стандарты безупречны, что само собой не так. Пытаться установить стандарты не следует людям, которые не являются профессионалами в этой области, и которые не имеют достаточного авторитета. Если лучшие из лучших не могли создать стандарты в течение 50 лет программирования, как несколько любителей в состоянии это сделать?

6.8. О скриптах, которые никому не нужны

Эту тему довольно трудно объяснить. Пример поможет лучше понять, что я имею ввиду:

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

Иногда это не легко увидеть, но иногда просто очевидно. Главная причина, почему не стоит тратить время на создание таких скриптов — их никто не будет использовать. Вы бы использовали упомянутый мною скрипт? Я бы не стал. Даже с точки зрения игрока я не вижу необходимости в такой функции. Это будет раздражать. А не подогревать интерес к игре. Подумайте об этом.
Разум человека может придумать всё что угодно, даже абстрактные формы и это значит, что в реальном мире они в них не будет никакого смысла. Так и со скриптами, есть такие идеи, которые попросту не нужны. Другой подобной проблемой является проблема со скриптами, у которой бессмысленные настройки. Вы когда-нибудь хотели выбрать в бою 2 случайных героя, которые не были бы одним из тех героев, что выбирает конкретный враг или одного врага, следующего в списке за тем, что выбирает герой?! Извините меня, но это идиотизм.

Определите цель скрипта, который вы создаёте, и подумайте о том, сколько в ней смысла, и следует ли вкладывать туда бесполезные настройки, которыми никто не пользуется. Это прекрасно, если в нём несколько жизненно важных вариантов использования или гибкость настройки, а может быть и совместимость с другими скриптами. Но слишком много настроек только запутает пользователя так, что он не захочет использовать ваше творение и наверняка принесёт головную боль и вам самим.
Представьте себе скрипт на 100 строчек с 30 настройками (что даёт приблизительно 70 строк рабочего кода). Нужно ли пользователю дать возможность выбирать 13 или 14 кадров в переходе экрана, если в любом случае можно использовать стандартное значение?! Если и найдётся такой человек, которому понадобится эта возможность, то он попросту попросит вас об этом. Вы скажите ему, как персонализировать ваш скрипт под его нужны, изменив одну или две строчки кода, чтобы всё работало, вместо того чтобы терять драгоценное время на реализацию отдельной настройки и параллельно нескольких других. Лучше уж пусть будет несколько нужных настроек, чем гора ненужных. Конечно, если у вас накопится несколько запросов одной и той же опции, то её можно добавить. Хорошая программа рождается постепенно по мере работы с клиентами, а не наличием кучи опций в самом начале. Эта лишняя трата времени.

Большинство людей не читает инструкции, и не знает на что способен ваш скрипт, особенно если там надо изменить 30 и более опций. Это довольно обескураживающе, когда встречаешь новенький скрипт, который должен добавлять тень и отражение, а в нём 5-страничная инструкция с 50 вариантами настройки, большинство из которых бесполезные. Обычный пользователь не владеет навыком написания скриптов, они довольны тем, что вы даёте игрушку и она работает сразу после добавления в их проект. Придерживайтесь качества, а не количества.

6.9. RAM или CPU?

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

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

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