Пятница, 29.03.2024, 18:39
Главная Регистрация RSS
Приветствую Вас, Гость
Поиск по сайту
Авторизация

Меню сайта
Game Maker
Если вы только-только начали изучать игрострой и еще даже не успели скачать сам Game Maker, предлагаем вам на выбор следующие версии программы:

Game Maker 8.1
Классика. Идеально подходит для создания простых 2D игр на PC. Требует активации.
Game Maker for Mac
Абсолютно та же программа, но только для пользователей Mac. Требует активации.
Game Maker Studio
Самая новая версия с возможностью кроссплатформенной разработки. Бесплатна.
Топ 5 игр
Агент Green 4.2 / 5.0
FeDo 4.2 / 5.0
To Mars: Sec... 4.2 / 5.0
To Mars+MapE... 3.9 / 5.0
Paintball 3.8 / 5.0

Топ игр составлен путем пользовательского голосования.

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



На сайте: 1
Гостей: 1
Пользователей: 0
Главная » Статьи » Уроки по Game Maker

7 советов по улучшению кода

Как я уже когда-то говорил, так уж сложилось, что комьюнити Game Maker в основном состоит из любителей, для которых создание игры на этом движке порой является первым опытом в программировании в целом. Поэтому при написании кода людьми часто допускается множество ошибок, которые в результате кочуют из исходника в исходник, от игродела к игроделу. Мне доводилось работать со множеством чужих исходников; да и самому писать кучу кода, в том числе плохого кода (даже по меркам GML), поэтому я бы хотел поделиться своим опытом и предостеречь начинающих программистов от распространенных ошибок. В этой статье приведены 7 советов по улучшению качества вашего кода (почему 7? Да потому что мне лень придумывать 11).

 

Соблюдайте стандарты оформления кода!

GML – это, конечно, тот еще мутант. Но это не должно помешать вам соблюдать хотя бы основные стандарты оформления кода. Да-да, я говорю в первую очередь о табуляции. К сожалению, очень часто люди копи-пастят код из каких-нибудь уроков или исходников, а в процессе теряется форматирование кода. И в итоге получается какая-то лапша, равномерно распределенная по левому краю. Не надо так. Определенно, в GM8 не самый удобный редактор кода и имеет некоторые проблемы с табуляцией. Но вам ничего не стоит потратить минуту, чтобы вручную расставить табы! А в проектах на GMS и выше вообще должно быть стыдно не ставить табы, так как там редактор кода проапгрейжен и никак не препятствует нормальным отступам.  
Ну и конечно пару слов о фигурных скобках. Обычно я расставляю их без переноса на новую строку (эдакий JS-стайл):
[code]if (a == b) {
}[/code]
И, как вы могли заметить, я очень люблю выделять условие скобками. Делать это в Game Maker, конечно, необязательно. Но это делает код более читаемым (собственно, во многих ЯП это стандарт)

 

Выделяйте локальные переменные!

Если для какого-то куска скрипта необходимо ввести новую переменную (например, итератор для цикла), не засоряйте память объекта и объявляйте переменную локально для скрипта.
Делается это очень просто:
[code]var variable;[/code]
В GMS и выше можно вообще сразу же присвоить значение переменной в строке с инициализацией, что очень удобно:
[code]var variable = 32;[/code]

 

Избегайте глобальных переменных!

На самом деле порой удобно юзать глобальные переменные. Но если вы планируете в дальнейшем расширять свой код, лучше постарайтесь сократить их количество. Во всяком случае обычно переменные относятся к той или иной сущности. Так что не должно составить труда приютить их куда-нибудь в качестве локальной переменной. И никогда не используйте объявление через globalvar:
[code]globalvar variable;[/code]
Лучше инициализировать глобальную переменную так, чтобы в дальнейшем не было возможности случайно получить к ней доступ, без приписки global:
[code]global.variable = 0;[/code]
Дело в том, что такие переменные никак не подсвечиваются в редакторе, и с первого взгляда просто непонятно, является ли переменная глобальной или локальной, что усложняет чтение кода. Использовать их стоит только тогда, когда вы целенаправленно хотите, чтобы к ним никто не лез. В таком случае не помешает, например, поставить в имя нижнее подчеркивание (или даже два нижних подчеркивания) для уверенности в том, что никто случайно не заденет эту переменную:
[code]globalvar __variable;[/code]

 

Не используйте цикл repeat!

Вообще цикл repeat юзабелен, когда вам надо выполнить строго определенное количество действий без дополнительных условий и итераторов. Но такие ситуации встречаются не так часто. И обычно я вижу цикл repeat там, где должен быть for:
[code]
// Например, такую конструкцию …
var i;
i = 0;
repeat 10 {
    i += 1;
    a[i] = i;
};

// Лучше заменить на цикл for
var i;
for (i = 0; i < 10; i+=1) {
    a[i] = i;
}[/code]

 

(Если хотите) не ставьте нижнее подчеркивание!

Я сам очень любил так делать, потому что это выглядит довольно красиво в контексте GML. Но когда приходится писать много кода, понимаешь, что постоянно ставить нижнее подчеркивание не очень удобно. Гораздо приятнее использовать названия в стиле Паскаля:
- Любая переменная начинается с маленькой буквы, но при этом каждое последующее слово в этом названии начинается с большой:
oPlayer (вместо o_player), timeToStart (вместо time_to_start)
- А вот название функций (скриптов в GM) должно называться с большой буквы:
Move(), ResetParameter()

 

Не избегайте ООП!

А теперь немного продвинутых советов. Несмотря на то, что в GML вроде как и есть объекты, реализовано ООП в нем ну очень криво. Для каждого объекта приходится выделять отдельный нод (который, в терминологии GML так и называется – объект), в коем уже понамешано довольно много часто абсолютно ненужной логики, замедляющей работу программы. Поэтому продвинутые пользователи ну очень боятся использовать лишние объекты в своей игре. И это приводит к плохому и неудобному коду.
Например, нам нужно реализовать инвентарь. И у каждого предмета в этом инвентаре должно быть несколько параметров. Совершенно очевидно, что удобно для такого случая создать некоторую сущность с несколькими полями:
[code]
// Create oItem
name = "none";
cost = 0;
sprite = sDefault;[/code]
И в дальнейшем добавлять в наш инвентарь вещи следующим образом:
[code]var item;
item = instance_create(0, 0, oItem);
item.name = "Plumbus";
item.cost = 300;
item.sprite = sPlumbus;

array[0] = item;[/code]
На основе родительского объекта oItem можно создать множество дочерних объектов (например, oWeapon, oArmor, oDrink) и реализовать в них какую-то дополнительную логику, уникальную для того или иного объекта. Например, добавлять к ним уникальные поля, не свойственные другим. Или реализовать пользовательские события, которые бы вызывались при активации итема (что очень сильно разгрузило бы Step для инвентаря):
[code]if (пользователь_активировал_предмет) {
    with (items[selected]) event_user(0);
}[/code]
Но вместо всего этого счастья зачастую создают несколько отдельных структур данных:
[code]item_name[0] = "Plumbus";
item_cost[0] = 300;
item_sprite[0] = sPlumbus;[/code]

Определенно, когда нам надо лишь только вывести на экран содержимое, такая реализация может даже показаться более лаконичной и предпочтительной. Однако, как только появляется дополнительная логика и необходимость расширения, начинается свистопляска, так как работать с десятком массивов строк и цифр не так уж и просто:
- вместо лаконичных событий, приходится обвешивать Step кучей и кучей if’ов.
- хочешь поменять местами предметы в инвентаре? Или просто удалить что-то? Будь добр, обработай сразу 3 массива (а может быть и 10, или даже 20).
- хочешь дополнить код? Переписывай и правь множество отдельных кусков кода (не забудь про if’ы в Step)
По сути, это очевидные преимущества объектно-ориентированного подхода, который крайне полезен при разработке игровой логики. Game Maker предоставляет мало возможностей для написания качественного удобного кода, так что не стесняйтесь использовать то, что есть. И не переживайте особо за производительность. Она не просядет значительно даже от сотни таких вот объектов.

 

Используйте списки!

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

[code]
// Инициализация списка
list = ds_list_create();

// Добавление строки в список
ds_list_add(list, "Sample Text");

// Перебор списка
for (i=0; i<ds_list_size(list); i+=1) {
    show_message(list[! i]);
    // или show_message(ds_list_find_value(list, i)) для GM8
}[/code]

 

Категория: Уроки по Game Maker | Добавил: BRESS (06.07.2020)
Просмотров: 741 | Комментарии: 1 | Рейтинг: 5.0/3
Всего комментариев: 1
0
1 BRESS   (06.07.2020 01:03) [Материал]
BRESS Почему-то комментарии на первой строчке не подсвечиваются. Потом разберусь :c

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]