Gamedev + Образование

Всем привет! Прошёл всего-навсего месяц - и я наконец возвращаюсь с рассказом о том, как учусь в Вышке делать игры. Предыдущая часть здесь, занятия заканчиваются, конец близок, погнали скорее!

Как говорится, вы находитесь здесь: основная часть учёбы позади, мы сдали все основные экзамены, впереди у нас только защита проекта. На ней я буду рассказывать, понятно, про то, как работала над карандашной адвенчурой про собаку Paper Bum. И следующий выпуск симулятора студента, судя по всему, будет последним - вот так всё быстро заканчивается:(

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

Психологическая монетизация и смертные грехи

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

Если коротко и на примере Киану Ривза, суть в том, что Киллеры любят убивать (да ладно?!), демонстрировать силу, участвовать в PvP-боях, рейтингах, марафонах, соревнованиях и так далее.

Карьеристы ценят прокачку уровней, навыков, скиллов, любят достижения, крафт, накапливают ресурсы и ценности. В другом варианте перевода их, кстати, называют “накопителями” (ага, внешние SSD).

Исследователи (мой любимый тип игроков, для них и стараемся) - любители нелинейного сюжета, квестов, диалогов, пасхалок, ценители многообразия выбора и баланса. В идеальной игре для игрока-исследователя есть огромные локации и обилие контента.

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

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

А именно:

- Киллеры готовы платить за пропуск прокачки; мощное оружие; визуальное подтверждение силы.

- Карьеристы могут купить VIP (премиум), если он даст больше денег или ресурсов; мощную защиту, которая позволит не зависеть от других игроков; сундуки - если они дают ощущение власти и богатства.

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

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

Перейдём к самому интересному - обвинению четырёх психотипов игроков во всех смертных грехах (и это не фигура речи). Далее почти цитирую слайды с лекции.

1. Гордыня - всегда быть первым, везде быть первым

- Киллеры – убить всех людей! Я - д`Артатьян, а вы…

- Карьеристы – взобраться на вершину рейтинга!

- Социальщики – быть самым известным и популярным!

- Исследователи – хочу все знать!

2. Зависть - сравнение себя с другими игроками

- Киллеры – хочу меч “Тысячи душ” и чтобы при покупке в чат написали, пусть завидуют!

- Карьеристы – хочу уникальную ачивку!

- Социальщики – хочу уникальный скин!

- Исследователи – поскромнее остальных, но завидуют знаниям.

3. Гнев - разрушительная мощь, поэтому игроки пытаются оградить себя от него

- Киллеры – не хотят злиться, что не могут убить.

- Карьеристы – не хотят злиться, что их убивают.

- Социальщики – просто не хотят злиться.

- Исследователи – философы, ведь смерть - это тоже интересно.

4. Леность - я сюда отдыхать пришёл, а не работать!

- Киллеры – а можно не качаться и сразу все купить?

- Карьеристы – я пашу с утра до ночи, но готов купить, а за это ачивка будет?

- Социальщики – лень - это грех? Да ладно?

- Исследователи – очень интересно, а можно как-то все автоматизировать?

5. Алчность - больше золота! Но не для всех

- Киллеры – равнодушны, за золото же не убить! Или убить?

- Карьеристы – где деньги дают? А много?

- Социальщики – равнодушны, это же игра!

- Исследователи – а за золото можно открыть пасхалку?

6. Жадность (чревоугодие) - мне всего много и по скидке!

- Киллеры – Хочу убить всех!

- Карьеристы – Лишние вещи есть? Что знает нет?

- Социальщики – Вещи? Играть? А это не чат что ли?

- Исследователи – кому вещи отдать?

7. Похоть - универсальный грех для всех!

- Киллеры – секс? Ммм... а заверните, попробую!

- Карьеристы – мне без очереди и дайте два!

- Социальщики – секс в игре? хочешь займемся виртом?

- Исследователи – тут еще и секс есть? Так что же вы сразу об этом не сказали! /me “Ушел проверять секс”.

Пока исследователь ушёл проверять секс, пойдёмте посмотрим, к кому и когда можно соваться за деньгами.

Инвесторы и паблишеры: где искать и с чем идти

В самом конце курса нам прочитали лекции об инвестициях в играх два брата: Кирилл и Роман Гурские, лидеры игрового направления GEM Capital.

Зачем вообще нужны инвестиции? Помимо того, что деньги - это здорово и приятно, и на них можно покупать еду, инвестиции выполняют три функции для разработки: ускоряют рост проекта, дают экспертизу и привносят дисциплину.

А вот чем отличаются инвесторы от паблишеров.

Паблишеры:

- инвестируют в продукт;

- в первую очередь смотрят на продукт;

- рассчитывают на окупаемость, хотят долю в выручке, контролируют производство игры;

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

Инвесторы:

- инвестируют в компанию;

- в первую очередь смотрят на людей;

- хотят владеть частью компании;

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

Где искать и тех, и других?

Google советовать не буду, скажу, что в список полезных ресурсов входят App2top и Investgame. Кроме того, создатели игры Torn Away поделились табличкой с огромным списком издателей. Кстати, если будет время, почитайте их грустную, долгую и трогательную историю.

Также имеет смысл ходить на профильные конференции: DevGAMM и White Nights.

С чем идти к инвестору?

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

Ошибки, которые наши преподаватели советуют избегать:

1. Неинформативный питч дек (презентация с информацией об игре, команде и запрашиваемой суммой инвестиций. В дек должна входить информация об опыте команды, анализ ниши и конкурентов, USP (уникальные фичи) продукта, бюджет разработки.

2. Пыль в глаза. Лучше честно рассказать о своих сильных и слабых сторонах.

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

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

5. Обида на отказ. С инвестором не стоит прекращать общаться после первого отказа, имеет смысл оставаться на связи, присылать квартальные обновления по прогрессу. И если прогресс оказался достойным - нет может вполне превратиться в да!

На этой оптимистичной ноте предлагаю закончить на сегодня:) Спасибо за то, что прочитали и до скорой встречи!

P. S. Дочитывать Student Simulator также можно в VK, твиттере и телеге.

P. P. S. На случай, если кого-то заинтересуют технические подробности про курс, на котором я учусь - традиционно оставляю ссылку на программу “Менеджмент игровых проектов”.

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

P.S. Передаю привет тому человеку, который ставит минусы на всё, что я пишу. Счастья тебе, здоровья.

Ссылки на предыдущие гайды:

Первый гайд

Второй гайд

Третий гайд

Сегодня мы поговорим о следующем:

- Что такое массивы и для чего они нужны? Что такое структуры данных?

- Какие виды структур данных существуют в GMS? Их особенности.
- Реализуем сетку карты.

Что такое массивы и для чего они нужны?

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

Индекс - это порядковый номер элемента в массиве.

Важно знать:

1. Индексы в массивах начинаются с нуля.

2. В массив можно запихнуть массив, в него запихнуть массив и так до бесконечности. Отсюда следует:

2.1. Массив называется одномерным, если в него не вложены другие массивы. Если в массив вложен другой массив, то это уже двумерный массив. Если в массиве есть массив с массивом - трёхмерный. И так далее.

Массив - структура данных. Что такое структура данных?
Структура данных - это "контейнер", который хранит данные в определённом формате. Соответственно, массив - один форматов хранения данных.

Какие виды структур данных существуют в GMS? Их особенности.

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

1.array = array_create(10, noone)
2. array = [1, 2, 3, 4] // внутри пишем любые свои значения
3.
array[0] = 1
array[1] = 2

И так далее. Также можно объявить сколько угодно мерный массив:

array[0][0][0][0] = 1.

Такие массивы преспокойно встраиваются в сохранение стандартными средствами GMS. Также здесь в автономном режиме работает "сборщик мусора". И это важно, поскольку в структурах данных (приписка DS) этого нет. Соответственно, их придётся удалять вручную.

Structs или структуры.

По сути, тот же массив, но вместо индексов - у нас именованные значения. Структуры используются для упорядоченного хранения информации. Пример объявления структуры из мануала:

// Create event
mystruct =
{
pos_x : x,
pos_y : y,
count : 1000
};
// Clean Up event
delete mystruct;

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

Обращение к struct для вычленения из него данных похоже на таковое для объектов. Нам нужно назвать структуру, а затем через точку - нужную нам "переменную".

show_debug_message(mystruct.pos_x)

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

mystruct =
{
a :
{
aa : "Example"
},
b :
{
bb : "Another"
},
};

В таком случае, нам нужно будет обратиться к структуре, к значению, а затем к значению внутри значения.

show_debug_message(mystruct.a.aa)

Также для простоты к структуре можно обращаться через with

with(mystruct)
{
a += other.x;
}

Ну и последнее, что стоит сказать. Мы можем использовать функции-конструкторы. Они позволяют создавать новые структуры по шаблону, который будет описан в такой функции.

// Функция-конструктор.
function Vector2(_x, _y) constructor
{
x = _x;
y = _y;
static Add = function(_vec2)
{
x += _vec2.x;
y += _vec2.y;
}
}
// создаем новую структуру
v2 = new Vector2(10, 10);

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

DS Grids или сетки.

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

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

Как создать:

переменная = ds_grid_create(ширина в клетках, высота в клетках)

DS Lists или списки.

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

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

переменная = ds_list_create();
Вставить новое значение:
ds_list_add(переменная, значение)

DS Maps или словари.

Словарь по своей сути похож на struct: он хранит данные в паре "ключ : значение". Если представить это образно, то это две колонки. Первая - это ключ. Второе - значение. Обращаясь к первой колонке, к ключу, мы можем спокойно получить значение. Или получить все ключи по определённому значению.
Мы будем их использовать в следующем гайде, когда будем разбирать пути и будем писать свои функции для их создания.
Способ создания:

переменная = ds_map_create()
Вставить новое значение:
ds_map_add(переменная, ключ, значение)

Мануал рекомендует использовать вместо DS Maps - структуры. Собственно, с ними нам тоже придётся поработать.

DS Queues, DS Priority Queues, DS Stacks

Всё это - "очереди", только по разному работающие. Разберём сначала Stacks и Queues.

Stacks это структура типа LIFO (last-in-first-out / последним пришёл - первым ушёл). Как и со списками, мы можем "вычленять" последние значения из стаков с помощь команды pop. Особенность LIFO в том, что в таком случае мы получим последнее значение, которое загружали в список.

С Queue ситуация обратная. Там используется FIFO (first-in-first-out / первым пришел - первым ушёл). То есть, забирая значение из queue (очередь), мы получим первое значение, которое вставили.

Важная оговорка. pop - берёт значение из массива, при этом удаляя его из него.

Priority Queue или приоритетная очередь - это та же очередь, но в которой каждое значение имеет свой "вес" - приоритет, что влияет на расположение данных в структуре и позволяет отбирать, скажем, наиболее дешёвые пути. Как говорит мануал, полезно для создания таблиц лидеров или информационных списков. Мы же будем это использовать для написания алгоритма поиска путей А* (A star, А звездочка).

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

Создаём сетку комнаты.

1. У объекта oGameManager пропишем две дополнительные макро переменные, которые будут хранить ширину и высоту одной клетки.

#macro CellWidth 32

#macro CellHeight 32

2. Создадим объект oGrid, который расположим в нашей основной комнате.

3. У этого объекта создадим событие Create, где будем создавать нашу сетку.

3.1. Для наглядности, создадим сетку с помощью команды mp_grid_create
mp в данном случае - это "motion planning" - планирование движения. Система, которая позволяет создать сетку комнаты и сразу же по ней создавать пути, используя встроенные алгоритмы. Они не дают всего необходимого функционала, поэтому этот пункт выполняем исключительно для наглядности.

global.grid = mp_grid_create(0, 0, ceil(room_width / CellWidth), ceil(room_height / CellHeight), CellWidth, CellHeight)

3.1.1. Перейдём в событие Draw, где отрисуем сетку.

draw_set_alpha(0.1)
mp_grid_draw(global.grid)
draw_set_alpha(1)

3.1.2. Зайдём в игру и посмотрим, что получилось.

Как видно, у нас получилась квадратная сетка. Используя функции mp_grid_* мы можем закрашивать нашу сетку, делая определённые квадраты непроходимыми. Но мы не можем назначать таким клеткам свою стоимость.
Иными словами, если будет два одинаковых по длине пути, но один через условные зыбучие пески, а второй по асфальту, то получим 50/50, что персонаж выберет медленный и потенциально опасный путь, просто потому что мы не можем указать, какой из путей будет приоритетнее.

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

3.2. Удаляем или комментируем то, что мы написали. Сейчас будем работать со структурами данных.
3.2.1. Создаём сетку через ds_grid_create в событии create

var cells_x = ceil(room_width / CellWidth)
var cells_y = ceil(room_height / CellHeight)
global.grid = ds_grid_create(cells_x, cells_y)

Ок. По сути, сетка готова. Теперь по ней мы можем создавать объекты. Давайте же заполним всю нашу комнату oDirt, а дальше уже будем разбираться.
3.2.2. Всё там же в Create нам нужно пройтись циклом по осям x, y, создавая объект oDirt по указанным координатам. Затем мы передадим получившиеся координаты, в клетках, в переменные внутри объектов, для удобства.

for (var _y = 0; _y < cells_y; ++_y)

{

for (var _x = 0; _x < cells_x; ++_x)

{

ds_grid_set(global.grid, c, u, 0) // 0 - это стоимость клетки. Ноль - значит непроходима.

var inst = instance_create_layer(_x * CellWidth + 16, _y * CellHeight + 16, "Instances", oDirt)

inst.coordx = _x

inst.coordy = _y

}

}

if instance_position(mouse_x, mouse_y, oObject)
{
var inst = instance_position(mouse_x, mouse_y, oObject)
scrOutlinedText(dmxg + 10, dmyg + 10, c_white, c_black, string(inst.coordx) + " " + string(inst.coordy), depth, fontArialRusSmall, fa_left, fa_top)
}

Работает! Впрочем, это только первая часть того, что нам нужно, не так ли? Помимо создания карты, мы должны иметь возможность располагать объекты самостоятельно, удалять их при необходимости. Да и с расположением земли не всё так гладко, как хотелось бы. Мы ведь совсем не добавили фон!

Начнём с конца, ибо это, на самом-то деле, достаточно просто.
У нас с вами есть два пути.
1. Мы создаём слой для спрайтов, на котором у нас будут спрайты фона.
2. Мы создаём для каждого нашего объекта "переднего плана" дубликат для заднего фона. По сути, увеличиваем количество объектов в комнате в два раза, соответственно увеличивая и нагрузку.

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

Первый вариант, несмотря на преимущество в скорости работы, имеет существенный минус. Мы не сможем обращаться к спрайтам по их координатам, да и в целом будем сильно ограничены в работе с ними. Придётся хранить ID каждого отрисованного нами спрайта. Для этого нам придётся создать вторую переменную, которая будет хранить координаты клеток (по x, y), а также id спрайта.
Так как мы знаем размер одной клетки, мы можем легко получить индекс той клетки, на которую сейчас наведены. Следовательно, можем получить и ID текущего спрайта - удалить его или назначить новый.

Получаем порядковый номер клетки. Для этого берём координату x текущей клетки, к ней плюсуем произведение текущей координаты y и максимального размера сетки по x. Т.Е. формула:

cell_id = x + y * max_x

В коде же это будет выглядеть следующим образом:

var cell_id = mouse_x div CellWidth + mouse_y div CellHeight * ceil(room_width / CellWidth)

Итак, работаем.

1. Создаём новый слой - Asset Layer, который назовём Backs.
2. Перейдём к объекту oGrid.
3. Добавим ещё одну глобальную переменную сразу после объявления сетки - global.grid_array = []
4. Чуток допишем цикл. Сделаем так, чтобы в список у нас добавлялись значения x и y.

var cells_x = ceil(room_width / CellWidth)

var cells_y = ceil(room_height / CellHeight)

global.grid = ds_grid_create(cells_x, cells_y)

global.grid_array = []

for (var _y = 0; _y < cells_y; ++_y)

{

for (var _x = 0; _x < cells_x; ++_x)

{

ds_grid_set(global.grid, _x, _y, 0) // 0 - это стоимость клетки. Ноль - значит непроходима.

var inst = instance_create_layer(_x * CellWidth + 16, _y * CellHeight + 16, "Instances", oDirt)

inst.coordx = _x

inst.coordy = _y

array_push(global.grid_array, [_x, _y])

}

}

5. Ок. Осталось ставить спрайты на "фон". Мы могли бы делать это и в цикле, при создании объектов, но зачем нам лишняя нагрузка? Правильно, незачем. Перейдём к объекту oDirt и у него создадим событие Destroy. Этот код будет выполняться перед уничтожением объекта.
С-но, алгоритм прост. Рисуем спрайт, сохраняя его ID. Узнаём индекс нужного нам массива и в него вставляем ID нарисованного спрайта.

var back = layer_sprite_create("Backs", x - 16, y - 16, sDirtBG)
var cell_id = coordx + coordy * ceil(room_width / CellWidth)
array_push(global.grid_array[cell_id], back)
ds_grid_set(global.grid, coordx, coordy, 1) // Делаем проходимым

if instance_position(mouse_x, mouse_y, oObject)
and mouse_check_button_pressed(mb_right)
{
var inst = instance_position(mouse_x, mouse_y, oObject)
with(inst)
{
instance_destroy();
}
}

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

Если упрощать, то нам нужно сделать следующие шаги, чтобы данную систему реализовать в полной мере.
1) Реализовать глобальную переменную, чтобы мы могли отслеживать событие: открыто сейчас какое-либо меню или нет. Простой переключатель, который будет закрывать старое меню при переключении на новое.
2) Сделать родительский объект или функцию для всех меню, так как логика взаимодействия у нас не отличается.
3) Расписать отдельно логику для каждого пункта. Конкретно сейчас, нам нужно таким образом реализовать меню строительства.

Теперь о самом меню строительства.
При активации оно должно выводить список всех возможных к постройке объектов. Следовательно, самое оптимальное здесь - использовать массив, в который мы передадим все эти объекты. Желательно заранее предусмотреть систему, которая убережёт нас от ситуаций, когда интерфейс уходит за границы экрана.

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

Непосредственно реализация.

Начнём с того, что заблокируем наш пользовательский интерфейс на нужных нам значениях. Пусть это будет FHD. Тогда, в объекте oGameManager, в Create, нужно будет добавить одну строку кода:

display_set_gui_size(1920, 1080);

Нового здесь ничего нет, поэтому повторяться не буду. Всего это шесть новых объектов.
В oGameManager пропишем переменную-тумблер:

global.placing = noone

object_list = [["Земля", oDirt], ["Камень", oRock], ["Металл", oMetal], ["Уголь", oCoal]]

object_name = noone
object_to_draw = noone
menu = noone

dmxg = device_mouse_x_to_gui(0)
dmyg = device_mouse_y_to_gui(0)
if instance_position(dmxg, dmyg, self) and mouse_check_button_pressed(mb_left)
{
// Если не активно - делаем активным
if !active
{
active = !active
global.placing = "Building";
var startx = x + sprite_width * 2 + 5
var starty = y - sprite_height
for (var i = 0; i < array_length(object_list); ++i)
{
var inst = instance_create_layer(startx + 64 * i + 5, starty, "Instances", oCell)
inst.object_name = object_list[i][0]
inst.object_to_draw = object_list[i][1]
inst.menu = "Building"
}
}
else
{
active = !active
global.placing = noone
}
}

if menu != noone and global.placing != menu
{
instance_destroy();
}

draw_self()
if object_to_draw != noone
{
draw_sprite(object_get_sprite(object_to_draw), 0, x + 32, y + 32)
}

Это только часть того, что нам нужно, верно?
Во-первых, мы не выводим название. Делать мы это будем отдельно, конечно же.
Во-вторых, у нас нет ограничения для объектов по оси X, а по оси Y они не двигаются вообще.

Начнём с первого, так как это просто. Выводить название объекта мы будем при наведении на него.
Для этого дополним Draw GUI у oCell. Если мы наведены на объект - нарисовать чёрный полупрозрачный прямоугольник и поверх него текст для лучшей отчётливости. И немного настроим "глубину", чтобы не было перекрытия этого текста.

if object_to_draw != noone

{

draw_sprite(object_get_sprite(object_to_draw), 0, x + 32, y + 32)

if instance_position(device_mouse_x_to_gui(0), device_mouse_y_to_gui(0), self)

{

depth = -1000

draw_set_font(fontButtonText20)

var width = string_width(object_name)

var height = string_height(object_name)

draw_set_alpha(0.33)

draw_set_color(c_black)

draw_rectangle(x, y - height, x + width, y, false)

draw_set_color(c_white)

draw_set_alpha(1)

scrOutlinedText(x, y - height, c_white, c_black, object_name, depth, fontButtonText20, fa_left, fa_top)

}

else

{

depth = 0

}

}

var starty = display_get_gui_height() - 64 - 64 * (array_length(object_list) div 10)

var inst = instance_create_layer(startx + 64 * (i mod 10) + 5, starty + (i div 10) * 64, "Instances", oCell)

Конечный результат меню:

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

Нам нужно завести ещё одну переменную, которая будет хранить объект, который мы хотим использовать. Иными словами, при клике на объект oCell, мы должны из него "вычленять" тот объект, который он хранит. Как следствие, получим спрайт, который будем отрисовывать в качестве "призрака".

Сделаем же это. Для этого у объекта oPlayer пропишем переменную:

place_object = noone;

if instance_position(device_mouse_x_to_gui(0), device_mouse_y_to_gui(0), self)
and mouse_check_button_pressed(mb_left)
{
oPlayer.place_object = object_to_draw;
mouse_clear(mb_left)
}

if place_object != noone

{

var cell_x = mouse_x div CellWidth * CellWidth

var cell_y = mouse_y div CellHeight * CellHeight

draw_sprite(object_get_sprite(place_object), 0, cell_x + 16, cell_y + 16)

// Обводочка по границам объекта, для удобства.

draw_set_color(c_white)

draw_rectangle(cell_x, cell_y, cell_x + 32, cell_y + 32, true)

}

Может выглядеть кривовато, но это из-за спрайта земли. Проверял на простых квадратах - всё встаёт четко в границы. :)

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

Step у oPlayer:

var cell_x = mouse_x div CellWidth
var cell_y = mouse_y div CellHeight
var cell = cell_x + cell_y * ceil(room_width / CellWidth)
if mouse_check_button_pressed(mb_right)
{
// Сбрасываем объект или удаляем объект/фон
if place_object != noone
{
place_object = noone
}
else
{
// Если в текущей позиции нет объекта - удаляем фон, иначе - объект
var inst = instance_position(cell_x * CellWidth, cell_y * CellHeight, oObject)
if inst
{
with(inst)
{
instance_destroy();
}
}
else
{
if array_length(global.grid_array[cell]) > 2
{
layer_sprite_destroy(global.grid_array[cell][2])
array_delete(global.grid_array[cell], 2, 1)
}
}
}
mouse_clear(mb_right)
}
if mouse_check_button_pressed(mb_left)
{
var place_x = mouse_x div CellWidth * CellWidth + 16
var place_y = mouse_y div CellHeight * CellHeight + 16
if place_object != noone
and !instance_position(device_mouse_x_to_gui(0), device_mouse_y_to_gui(0), oGBuild)
{
// Удаляем объект, если находим.
var inst = instance_position(cell_x * CellWidth, cell_y * CellHeight, oObject)
if inst
{
with(inst)
{
instance_destroy()
}
}
// Удаляем фон
if array_length(global.grid_array[cell]) > 2
{
layer_sprite_destroy(global.grid_array[cell][2])
array_delete(global.grid_array[cell], 2, 1)
ds_grid_set(global.grid, cell_x, cell_y, 0)
}
// Ставим новый объект
var new_inst = instance_create_layer(place_x, place_y, "Instances", place_object)
new_inst.coordx = mouse_x div CellWidth
new_inst.coordy = mouse_y div CellHeight
mouse_clear(mb_left)
}
}

Собственно говоря, система размещения объектов сделана. Осталось её дорабатывать напильником.
Результат:

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

Собственно, OChar - родитель oCharPlayer и oCharNoControl.
oCharNoControl - родитель oCharNeutral и oCharEnemy.

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

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

- Сохранение. Встроенное VS самописное.

- Звуки.

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

Есть вопросы или что-то не получается - обращайся, помогу.

Есть пожелания или замечания - буду рад выслушать.

Ссылка на скачивание файла проекта для ЛЛ:
https://disk.yandex.ru/d/w31aDLE9ClPy9Q

Привет!

Приношу свои извинения за долгое отсутствие. Лето, выходные, ну вы понимаете. :)

Ссылки на предыдущие гайды:
Первый гайд
Второй гайд
Третий гайд

Недавно проводил один из стримов, на котором частично воссоздал старые добрые "танчики" с Денди (Battle City). Исходники, которые можно будет допилить самому, приложу к посту ниже. Там тоже есть что потыкать.

Иерархия объектов

Кратко:
Тоже самое, что и с классами. Есть родительский класс и дочерний, который наследует его свойства. В нашем случае, слово "класс" заменяется на "объект, но смысл не меняется.
Важно: свойства эти можно "переписать", создав событие заново. В нём же можно дополнительно указать, если мы хотим сохранить свойства, при этом дополнив их.

Подробно:
Перед созданием любого объекта, мы должны чётко представлять его предназначение. Часто множество объектов исполняют схожие функции, но с небольшими отклонениями. Таким образом, вырисовывается проблема: создавать стопицот объектов с одинаковым кодом - бред, который захламляет код и делает его нечитаемым.
Решение этой проблемы - создание универсального "шаблона", на основе которого будут строиться другие объекты с нужными дополнениями.
Таким образом, наш шаблон становится родителем. А все, кто создан по этому шаблону - его "детьми" (дочерними объектами). Они перенимают его свойства, но могут их в нужной степени корректировать.

Работа иерархической системы в GML (GameMaker Language) имеет особенность, с которой быстро придётся познакомиться на практике.
Все "дочерние" объекты по умолчанию считаются частью "родительского".
У нас есть общий родительский объект для всех блоков. При этом, в комнате его у нас нет. Но есть его дочерние объекты.
Следовательно, делая проверку на наличие родительского объекта, у нас высветится "истина".
Делайте проверки на наличие тех или иных объектов в комнате обдуманно.

Как это использовать - можете придумать сами. Ниже примеры, которые использовал я.
- Для создания систем юнитов, зданий
- ИИ, который выбирает приоритетные цели на основе их родительского объекта.
- Для создания инвентарной системы.
- Для создания меню.

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

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

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

Небольшие пояснения, слева направо.

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

Аналогично с объектами.
- Всё, что есть в игре, кроме персонажей - у нас будет объектом, с которым мы можем взаимодействовать.
- Каждый такой объект мы делим по двум типам: постройки, которые что-то делают (или не делают), но суть - должны быть построены. И природные объекты, которые игрок ставить не сможет.
Дальше, соответственно, они снова делятся.

Как это выглядит в движке.

Создадим два объекта: oObject и oNature.
Первый - родительский объект для всех типов объектов, второй - только для "природных". При этом, у нас также есть объект для земли - oDirt.
Перейдём к oObject.
Нажмём у него на Parent. Далее - на плюсик, где поставим ему дочерним объект oNature.

Аналогично проделаем с oNature для oDirt. Как видно, родитель у него уже выставился.

Ок. Родительские объекты сделали.

Перейдём обратно к oObject и создадим у него событие Create.
Теперь немного мыслей в слух.

Базово, каждый наш объект должен иметь следующий перечень "настроек":
- Количество ХП. Так как каждый объект интерактивен, следовательно, каждый объект можно атаковать. С-но, вводим переменную hp и приравниваем её к 0 по умолчанию.
- Координаты по сетке. coordx, coordy. Не столько необходимость, сколько просто упрощение. Делаем их равными -1 по умолчанию, так как мы в любом случае будем их переназначать при размещении объектов.
- Может объект гореть или нет - flammable. False по умолчанию.

Пока остановимся на этом. Перейдём к объекту oNature.

Как видно, событие "Create" у нас здесь уже есть. Оно унаследовалось от нашего родительского объекта oObject.
Если создать ещё одно событие Create, то мы перепишем родительское. Но, можно предоставить себе выбор, что мы хотим сделать.
Для этого, по существующему событию мы нажмём правой кнопкой мыши.

У нас появится выпадающее меню из трёх опций:
- Open Parent Event - открыть это же событие в родительском объекте.
- Inherit Event - унаследовать событие
- Override Event - переписать событие.

С-но, нам нужно выбрать второй пункт: унаследовать событие.

Тогда у нас откроется окно кода с готовой строкой:

event_inherited();

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

Следуя плану, сейчас нам нужно убрать связь между oNature и oDirt, создать ещё два объекта (oResource и oNotResource) и уже затем выставить связь между oNotResource и oDirt.

Собственно говоря, для не-ресурсных объектов - это всё.
Для ресурсных - нам нужно объявить, какие ресурсы он может содержать.

Открыв объект oResource (родительский для всех блоков, с которых что-то будет добываться), создадим его с наследованием от родителя.

Далее - обозначим ресурсы, приравняв их все к нулю.

Metal = 0;
Coal = 0;
Wood = 0;
Stone = 0;
Gem = 0;

По сути - всё.

Теперь, когда будем создавать ресурсные объекты, в качестве родителя будем у них выставлять oResource. Создавая объект, будем наследовать событие создания у oResource, переписывая нужные нам строки кода.

Проверим, как это всё работает.

Создадим объект oRock.
Поставим ему в качестве родителя oResource.
Создадим у него событие Create, унаследовав код.
Пишем код:

event_inherited();
Stone = irandom_range(5, 15)

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

Добавлю ещё кое что прежде, чем закрыть эту тему.
Когда выстраивается взаимодействие между объектами игры, которые не находятся под прямым управлением игрока, очень часто, чтобы избежать ошибок, придётся делать проверку на наличие объекта в комнате. Для этого используется команда: instance_exists(объект);.
Это ещё одна вещь, которую нам позволяет делать иерархия и которая немного развязывает руки в разработке.

Глобальные переменные

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

1. Локальные переменные. Объявляются с помощью ключевого слова var

var название = значение

Эти переменные нельзя использовать где-либо, кроме текущего события. С-но, в другом событии они будут недоступны, также будут недоступны и для изменения из посторонних объектов.

2. Обычные переменные (не знаю, как правильно их обозвать:D)
Мы с ними уже активно работали, объявляются они просто:

название = значение

В дальнейшем, их можно вызывать из других объектов, используя with или обращаясь к объекту через переменную, хранящую его id. К примеру:

inst.coordx = 1;

global.название = значение

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

4. Макро переменные. По сути, те же глобальные переменные, но за одним исключением. Они не могут быть изменены. Также используются для хранения значений, которые являются константами и могут пригодиться в нескольких местах программы. Объявляются следующим образом:

#macro Название Значение

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

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

План, как всегда.
- Массивы и с чем их едят, а также grid (сетка комнаты), размещение объектов по сетке. Включая объяснение, в каких случаях лучше использовать встроенные функции, в каких – писать свои с нуля.

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

- Иные способы хранения информации в GMS2, когда их стоит или не стоит использовать.

- Сохранение. Встроенное VS самописное.

- Звуки.

Всем привет! Пролетели ещё две недели учёбы, я внимательно прослушала лекции и выбрала для вас самое крутое и полезное! Для тех, кто впервые наткнулся на этот дневник и увидел аж 18-ю часть, напоминаю - я учусь делать игры в Вышке (она же НИУ ВШЭ), а предыдущая часть здесь.

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

Заканчивая коктейльную аналогию, перехожу к теме одного из занятий по маркетингу, а именно…

Трезвый взгляд на игровые выставки

Вряд ли мне нужно объяснять вам, что такое игровые выставки, поэтому просто перечислю ключевые названия:

- White Nights

- DEVGAMM

- GamesCom

- PAX (EAST/WEST)

- China Joy

- Casual Connect

А вообще по миру проходит примерно 200 выставок в год - вряд ли инди-команда сможет успеть на все:) Но при этом каждая выставка - это возможность за пару дней получить максимум выгоды!

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

- зачем нам туда: кого хотим найти, что показать, с кем и зачем поговорить, что нового узнать?

- с чем нам туда идти: есть ли билд, у кого запросить стенд?

Понятные, чёткие и непротиворечивые цели - ключ к адекватной подготовке! И кстати, отсутствие билда - не беда, всё опять-таки зависит от ваших целей.

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

Параллельно готовим материалы: это баннеры или плакаты, визитки, материалы для стенда (видео, промо), раздаточные материалы и пресс-киты, если требуются (это комплект документов о проекте: видео, аудио, тексты).

К встречам на выставках тоже нужно готовиться заранее: заблаговременно их назначить (за две недели или больше), указать в приглашении всю необходимую инфу, причём на английском. Что обязательно в нём нужно обозначить: кто мы такие, чего хотим и зачем с нами встречаться. Во время встречи мы рассчитываем максимум на 15 минут. Из них не больше пяти минут должна занять презентация, основной фокус - на проекте. Всегда стоит подводить итоги встречи и сразу записывать, о чём именно договорились (иначе всё забудется).

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

Не поверите, но правила корректного поведения на вечеринках тоже есть:)

Вот они:

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

2. Лучше держаться ближе к тем, с кем вы успели познакомиться (правило на радость интровертам) - ведь они могут познакомить вас с кем-то ещё.

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

4. С собой нужно всегда иметь определённую сумму денег.

Да, правила весьма универсальные и подойдут, по-моему, для любой вечеринки:)

Маркетинговые ассеты: starter pack

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

Основные ассеты такие:

1. Логотип. Это может быть оригинальное написание названия игры/студии; символ, вызывающий ассоциацию с продуктом или комбинация символа с текстом. Логотип должен быть простым, индивидуальным, привлекательным и охраноспособным.

2. Иконка игры. Это не то же самое, что скриншот, на иконке должен быть узнаваемый персонаж или говорящая об игре сценка. Название игры должно соотноситься с иконкой.

Иконки очень важны для мобильных игр, поэтому их стоит тестировать, например, через Google Play Experiments, SplitMetrics или Storemaven. Хорошая иконка способна добавить 35% загрузок, а плохая - убить до 50%.

3. Игровой арт. В идеале - это самое красивое и привлекательное из всего, что могут создать дизайнеры проекта:) Арт должен содержать одного или нескольких героев игры, отражать суть проекта и передавать его дух. Стоит понимать, что арт - это дорого и долго. При этом арты нужны разные - в зависимости от рынков, на которые вы выходите.

4. Скриншоты. Каждый скриншот должен отражать яркий, сочный момент геймплея, и на его понимание должно хватать 1-2 секунд. При снятии скриншотов нужно избегать артефактов, неудачных углов съёмки и слепых пятен. Хороший скриншот способен объяснить, что умеет ваша игра, чем выделяется из общей массы и демонстрирует игру в наиболее выгодном свете. Скриншотов должно быть… несколько:) Для магазина хватит четырёх, но пользователям столько будет маловато.

4. Ролик. Это визитная карточка проекта, по которому его будет узнавать пресса. По ролику 55% пользователей решают, скачивать ли приложение (по данным Google Analytics). Пока команда готовит ролик, она успевает кучу раз перессориться и поскандалить - это нервный процесс.

Хороший ролик - это когда:

- минимум 70% от хронометража - геймплей;

- минимум 2 фичи проекта видны в первые 10 секунд;

- удовольствие можно получить как со звуком, так и без;

- есть локализация;

- есть призыв поиграть в финале.

Чтобы всё это получилось, нужно написать ТЗ на ролик от маркетинга (описать, какие фичи показываем и какие чувства должен вызывать ролик), провести мозговой штурм, расписать подробное ТЗ на производство ролика, сделать раскадровку, драфт, показать маркетологам и внести корректировки, докрутить финальную версию и сделать локализацию.

5. Маркетинговые тексты. Основные правила: суть игры должна быть понятна по первым двум строчкам, предложения должны быть короткими и ясными при беглом просмотре, юмор всегда уместен (но должен вписываться в тематику игры), локализация обязательна.

Пресс-релиз - это по сути игровая новость для прессы. В первые две строки нужно уместить саму новость, а весь пресс-релиз должен занимать максимум страницу. Пресс-релиз нужно сопроводить ссылкой на пресс-кит. В пресс-кит входят скриншоты (в высоком разрешении, без надписей), ролик (в двух разрешениях, локализованный), арт, логотипы игры и компании.

Культурализация как понимание игры на особом уровне

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

В культурализацию может входить:

- адаптация шуток;

- анализ соответствия требованиям законодательства;

- анализ отсутствия грубых нарушений этикета;

- адаптация игры под возрастные требования;

- перерисовка изображений в соответствии с культурными особенностями страны;

- изменение жестов персонажей.

Здесь можно выделить некие “культурные переменные”, на которые стоит обратить особое внимание:

1. Религия. Культуры, выстроенные на религии или традициях, часто бывают менее гибкими, чем светские культуры.

Так, файтинг Kakuto Chojin сняли с продажи из-за того, что в её озвучке были строки из Корана. А разработчикам EA Sports UFC 2 пришлось извиняться и менять анимацию, потому что в их игре при выходе в октагон Хабиб Нурмагомедов осенял себя крестным знамением - и это заметили фанаты бойца.

2. История. Многие страны старательно защищают свои интерпретации исторических событий.

Например, в Age of Empires японская армия Ямато вторгается на Корейский полуостров и захватывает империю Чосон. Но в версии для Южной Кореи империя Чосон захватывает Японию.

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

Иногда разработчикам приходится цензурировать игру, которая кажется людям слишком жестокой, как в случае с Manhunt 2, или перекрашивать персонажа, как в Chuchel или менять анимации героям, как сделали с Трейсер в Overwatch.

4. Геополитика. Самое явное влияние - это спорные территории.

К примеру, Ghost Recon 2 запретили в Южной Корее из-за наличия в ней воинственного северокорейского генерала и боевых действий с Северной Кореей.

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

Для этого нужно:

- познакомиться с рынком: получить базовое представление о чувствительном контенте, задавать вопросы, назначить ответственных;

- находить проблемные места: найти похожий контент, изучать внешние ресурсы;

- оценивать критичность: классифицировать найденные проблемы, документировать важные решения;

- вносить только те изменения, без которых точно не обойтись.

На этой назидательной ноте и закончим:) Спасибо за то, что дочитали и до скорой встречи!

P. S. Читать Student Simulator также можно в VK, твиттере и телеге.

P. P. S. На случай, если кого-то заинтересуют технические подробности про курс, на котором я учусь - традиционно оставляю ссылку на программу “Менеджмент игровых проектов”.