Слайд 8. «Механики и игровые механизмы»

В рамках игры были приняты следующие условности:

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

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

· Дискретность игрового пространства. Мир не является непрерывным, а поделён на разное количество игровых локаций. Игровые локации объединяются в системы локаций. Считается, что, попадая в игровую локацию, персонажи обязательно встретятся, если только это не противоречит некоторой другой механике. То есть локация – это самая маленькая, с точки зрения игрового пространства, единица игрового места. Локациями могут являться, например, районы города, тогда сам город – это система локаций (набор районов в этом городе)

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

Также были приняты следующие механизмы работы игры:

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

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

· Персонаж может получить «запрос на действие» и обязан каким-то образом отреагировать на него. «Запрос на действие» — это механика, похожая на всплывающее окно с выбором в Crusader Kings 2. Фактически это некоторое событие, на которое имеется несколько вариантов реакции. Каждая реакция ведёт к активированию некоторого количества событий. Например, «запрос на действие» используется в торговле. Когда один из торгующих отправляет предложение другому, то последний получает запрос на действие с 3 вариантами: подтвердить обмен (совершается передача ресурсов от одного персонажа к другому), остановка торговли (завершается торговля без передачи ресурсов), ответное предложение (закрывается «запрос на действие», чтобы персонаж мог отправить ответное предложение)

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

Слайд 9. «Текущая стадия разработки»

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

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

Для того, чтобы протестировать работу игры, всех её имеющихся компонентов и механик мной был разработан тестовой мир, населённый персонажами, которых я называю «торговцы капустой». Вот в чём заключается его идея: создаётся мир, который состоит из 4 полян, соединённых по кругу тропами; каждая поляна имеет внутри 5 мест, являющихся игровыми локациями; в мире случайно появляются 10 персонажей, которые при себе имеют по 300 кочанов капусты; персонажи перемещаются по миру случайным образом и при встрече обмениваются друг с другом случайным количеством капусты, причём могут, как отдать больше, чем получить, так и наоборот.

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

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