Концепт

Чтобы покупателям не было скучно стоять в очередях, Ашан добавил веселый квест, разобраться с которым под силу далеко не каждому .

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

1. Проблемы

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

Порядок при первом использовании

- Понять что нужно делать
- Найти сканер или нечто похожее
- Отсканировать чек с qr-кодом
- Найти куда вносить купюры
- Внести купюры
- Найти куда вносить монеты
- Внести монеты
- Найти откуда брать сдачу
- Взять сдачу
- Найти откуда брать чек
- Взять чек об оплате (а почему их два?)
- Понять какой чек нужен на выходе
- Выйти

Ура! так выглядел обыденный процесс покупки пакета молока после работы.

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

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

2. Проблемы оформления

• На кислотном красном нормально читаться будет только белый

• Белые подложки усиливают общую контрастность, выделяя все и не выделяя ничего

• Текст у сканера закрывается корзинкой для сдачи мелочи при виде сверху

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

• Инструкция на мониторе показывает схематически неправильный терминал,
  несуществующий штрих-код, и указывает на несуществующий сканер

3. Возможное решение

Меньше шума, больше информации

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

Самый сильный акцент ушел на область сканера. Это первый и основной шаг. Рядом со сканером
схематический чек с qr-кодом. Покупатель может не знать, что это такое, но штуку с похожим рисунком ему только что дали на кассе и он держит ее в руках.

Направляющие и подсказки

Второй по важности этап оплата.

Добавим акцент на купюроприёмник,
но гораздо слабее, чем на чек.

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

Добавим стрелку к оплате монетами. Этот этап происходит одновременно с оплатой купюрами,
но менее важен.

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

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

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

такое оформление не требует никаких технических изменений

"Это решение уже завтра можно напечатать на плёнке и расклеить на каждый терминал"

4. Варианты без привязки к цвету корпуса

Белый вариант

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

Зеленый вариант

Спокойный и не нагруженный вариант. Хорошо выглядит в сочетании с белым и белой заставкой на экране, но немного превращается в кашу с зеленой.

можно придумать еще несколько вариантов оформления цифр, чека, стрелок

(почти)Идеальные варианты в сферическом вакууме

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

Чек на выходе

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

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

В некоторых магазинах вместо первого qr-кода дают обычный чек со штрих-кодом, который, однако, также не сработает на сканер на выходе и создаст еще больше путаницы внешней идентичностью со вторым чеком

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

Итеративный подход

Существуют различные подходы к организации геймдизайна. Я предпочитаю использовать итеративный способ, вернее путь к итоговым механикам и структурам через прототипирование ядра неполной концепции, с последующим многократным тестированием и дополнением. То есть под итерациями понимаются не просто новые слои улучшений, а и сама суть концепции видоизменяется под влиянием результатов её практического применения.

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

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

Таким образом, итеративный подход, он про эксперименты и как раз ожидает, что при соприкосновении концепта с реальностью будут возникать различные задачи, которые нужно будет решать, адаптируя идею, и в то же время получая через практику новые подсказки о том, в какую сторону её следует развивать.

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

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

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

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

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

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

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

Прототипирование Microspace project в Godot engine

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

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

В качестве движка был выбран Godot engine, а конкретнее версия 3.2.1, язык GDScript и gles3 рендер. В целом данный проект относится к категории достаточно код-интенсивных, всё-таки это далеко не аркада, где можно обойтись вобще без программирования. Выбор GDScript'а не особо принципиален, просто на нём быстрее писать внутри редактора, без открытия лишних окон, а так - вся логика без каких-то особых проблем переносится на тот же C#. Gles3 тоже не принципиален, но я взял более мощный рендер в качестве целевой платформы, а на упрощённом всегда можно собрать отдельную версию, только потребуется переработать частицы.

Началось всё с набросков карты сектора и написания контроллера, чтобы добавить модель кораблика и полетать по получившемуся "космосу" (попутно придумалась музыкальная композиция для глобальной карты):

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

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

Подготавливая приблизительные иконки с персонажами/предметами для инвентаря я завёл пару текстурных атласов в формате png, размерами 512 на 512. Таким образом в каждом можно держать по 64 иконки размерами 64 на 64. Godot, кстати, сам умеет сшивать несколько выбранных картинок в атлас, но у меня почему-то эта его функция не срабатывает, поэтому набросал заготовки в графическом редакторе.

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

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

Следующее обновление принесло ещё один важный момент, которого не хватало - собственно, партию героев, к основному звездолётику Wanderer добавились Spira и Vanguard. Появились новые враги, отображение получаемого урона, самописный ориентировочный трек сражения, доработки инвентаря и специальная станция, где можно отправить одного из героев с основного корабля на задние, а потом забрать его, после истечения срока.

Архитектура приложения

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

Собственно, про некоторые особенности движка Godot и я рассказывал вот в этой статье:

А внутренняя архитектура прототипа космической jrpg следующая: есть основная 2д сцена - стартовый экран, куда попадает пользователь. При выборе уровня к корню стартовой сцены крепится сцена космического сектора, в которую дочерним объектом крепится звездолётик и на него навешиваются слушатели некоторых сигналов. Сама стартовая сцена при этом скрывается, но её скрипт обрабатывает сигналы от кораблика - столкновение с врагом, открытие инвентаря, попадание в зону планеты. Когда игрок открывает инвентарь, то стартовая сцена снова показывается, но отображает не менюшку входа в игру, а окошко инвентаря.

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

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

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

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

Где брать идеи

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

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

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

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

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

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

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

Вот нам нужна игра про партию героев, которые сражаются с врагами, исследуют различные города, имеют систему развития, разные предметы... Начните с одного героя. Одного врага. Сражение с одной только опцией - удар. Вместо города несколько примитивов изображающих дом. Отображение пустого окошка с информацией о герое. И так далее. Потом героев станет два. В статистике появится имя. Врагов станет двое. Кроме ударить, появится вторая опция, пусть она даже сначала не работает. Коробок-домов станет несколько. Появится отображение содержимого сумки, пусть сначала только одна ячейка. Затем героев станет три, и можно будет менять их местами. Враги станут попадаться группами по 2 или 3. Появятся ещё боевые опции. Появится вторая область с "домиками", до которой можно добраться. Итак далее.

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

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

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

Н

Всем тем, кто не хочет читать: игра не игра, когда она выступает против игрока, то есть наделяется какой-то определённой целью выступать против или за. Понятие "уровня" и "lvl", стоит только его ввести в концепт игры - убивает саму игру, превращая её в обыкновенный спорт, порождающий спидранерство. Но если на территории вашего уровня существует множество некоторых песочных мелочей, которые позволяют не следовать главной "цели", - аркадная игра превращается в отыгрыш собственной личности в пределах закодированного пространства и тех "фич", за счёт которых сие можно производить (например "кулинарии"). Если же изначально игра делается "ролевой", вы опять-таки игру наделяете "самоцелью", а потому разрушаете её бесцельность, и поэтому сталкиваетесь с тем явлением, что именуется манчикизмом. Манчкизм что в RPG, будь они настольные или в киберпространстве, что в MMORPG производится строго по той причине, что игрока обязывают соблюдать эти самые условия прохождений "сюжета" и "уровней", игнорируя тот факт, что сам по себе игрок не хочет участвовать в вашем спектакле, а хочет уйти в лес. Дайте ему возможность погулять в лесу больше, чем спускаться в ваше подзмелье. Ответ хейтерам.

Его (тип игрока*) нельзя изучить, используя методы социологии, потому что он не связан строго ни с каким определённым социумом такой игрок не есть ни человек пользы, приобретения, профессии, труда[1]. Здесь об этом стоит возразить следующим образом: игрок есть адаптирующийся субъект в условии бесцельного экзистенциирования; играть - адаптироваться в условии бесцельного экзистенциирования соответственно. И только на этом моменте понимания "игрока" как адаптатора могут вступить в полемику Юнгеровские счастливый случай, искусность и подражание, к которым сводятся все игры; с того момента как процесс адаптации завершается, то завершается и игра. Но при этом это не будет означать что игра завершится благоприятным или неблагоприятным исходом, завершение игры может произойти и посредством её прервания, ведь сама из себя игра вовсе и не обязана к чему-либо приводить.

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

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

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

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

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

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

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

Из всего этого можно вывести тезис: киберпространственные игры есть игры только ролевые для одиночного игрока, или спортивные игры для (что очевидно) спортсменов. То же, что совмещает спорт и ролевую игру в киберпространстве не есть массовая многопользовательская ролевая онлайн- игра, поскольку мморпг лишь иллюзорно обладает спортивными элементами командного соперничества: ММОРПГ не заканчивается НИКОГДА, в ней НЕЛЬЗЯ ни победить, ни проиграть, и собственно умереть в ней нельзя. ММОРПГ является в своей сути ни киберспортом, и не киберролеплеем, - это есть одно из самых настоящих порождений киберигровой мифологии.

[1] Ф.Г. Юнгер: Игры и ключ к их значению, стр.68

[2] Г.В.Ф. Гегель: Феноменология Духа, стр.28