...Допустим, мы хотим создать оригинальную игру, в которой игрок должен собирать синие шары (джва года ждал!). Как бы мы могли это реализовать с точки зрения механики?
Ну, у нас есть игрок и игровые объекты – синие шары (нет, это не те balls, о которых вы подумали, но вы ведь уже погуглили Urban Dictionary? — теперь живите с этим).
Понятно, что все вместе они находятся внутри некоего игрового мира. Пока пусть будет обычное игровое поле, на котором разбросаны шары и перемещается игрок, собирая их. При этом возникает множество вопросов.
Как игрок будет выполнять эти два простых действия (для одаренных поясняю: ходить и собирать)? Нужен ли ему аватар? Будут ли шары втягиваться собираться автоматически, едва аватар/курсор окажется рядом (хм... надо все же взять на заметку тему втягивания), или игроку нужно будет предпринять дополнительные действия, например станцевать макарену (мы же помним, что на самом деле игрок может лишь нажать на какую-то кнопку на клавиатуре, мышке или ином контроллере)? Хотим ли мы ограничить передвижение игрока? Будут ли шары неподвижно лежать на одном месте или «убегать» от игрока?
Nota Bene: Если вы не понимаете важность этих вопросов, если вас беспокоят другие вопросы, типа: «Вы изждеваетесь? Собирать синие шары?! Это же тупо!» или «WTF?! Вот же, идея есть. Осталось только нагуглить нарисовать спрайты и написать код включить GameMaker Unity» – увы, вам не стать хорошим геймдизайнером.
Допустим, мы будем придерживаться механики классических 2D платформеров и выведем на игровое поле запасного аватар игрока. Допустим, способ перемещения по игровому полю тоже выберем классический – четыре кнопки вправо-влево-вверх-вниз. Хотя, погодите-ка...
Будет ли наш игрок перемещаться по диагоналям? Нам следует уже сейчас ответить на этот вопрос, чтобы впоследствии не обнаружить неприятных сюрпризов, которые вызывают непроизвольное сокращение ротовых мышц и голосовых связок, производящих сакраментальное "бХХХь", неожиданно ломающих динамику во время тестирования игры.
В этот момент также самое время решить вопрос об игровом поле и характеру перемещения по нему. Будет ли оно «цельным» – где координаты изменяются попиксельно или «в клеточку» – где координаты перепрыгивают через заданное кол-во единиц.
Ну, допустим, мы хотим, чтобы игрок перемещался по полю на манер шахматной ладьи – тогда мы фактически вынуждены выбирать поле в клетку (кто ответит на вопрос "какая тут причинно-следственная связь" — тому 10 синих шаров из 10 пять с плюсом).
С другой стороны, поле в клетку как-то уж слишком старомодно – раз, и впоследствии нам придется подстраивать под него сеттинг – два. А последнее означает, что разработчик —мудила ограничены возможные варианты. Пожалуй, чёрт с ним, пусть ходит куда и как захочет!
Что ж, с первым действием игрока (а заодно и с базовой характеристикой поля) мы более-менее разобрались. Пора браться за blue balls синие шары.
...to be continued!
______________
P.S.
1. Комментарии для минусов — как принято, наличествуют. Продолжение последует в течение нескольких часов, максимум — суток. Текст разбит на части, поскольку несколько превышает стандартный длиннопост.
2. Я ни в коей мере не мню себя гуру геймдизайна. И это не поучение для опытных программеров, руководство предназначается таким же как и я: не умеющим профессионально кодить, не умеющим профессионально рисовать. Оно описывает третий подход к разработке игр: разработке механик и сеттинга. Тот самый подход, который практически не освещается ни в данном сообществе (я уже почти год пристально слежу за постами в лиге разработчиков), ни в рунете в целом (на самом деле, есть несколько хороших ресурсов, где опубликованы частичные переводы западной литературы, посвященной этой стороне геймдиза — если кому будет интересно, я сделаю подборку ссылок).
3. Всем благ и хорошей кармы )