КН: Call of Ocean #6 - Построение архитектуры движка

Всем привет!

[ВСТУПЛЕНИЕ]

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

[MAP PARSER]

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

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

Не вижу смысла расписывать весь процесс создания парсера, если вам интересна данная тема, то вы можете посмотреть как это сделать своими руками при помощи уроков 15-17 с плейлиста по данной ссылке ( https://www.youtube.com/watch?v=3DKriWbJJ50&list=PL-K0viiuJ2RctP5nlJlqmHGeh66-GOZR_&index=15 ).

У автора видео успешно запустился данный парсер, но у меня возникли проблемы с открытием файла map.tmx со стороны библиотеки tinyXML (при вызове метода xml.LoadFile() возвращается NULL, хотя путь 100% указан правильно), я думаю это связано с какими-то неправильными настройками внутри файла. Я планирую решить эту проблему чуть позже (чисто для себя, чтобы понять в чем же было дело, поскольку в моем движке парсер не пригодится). Если кто-то сталкивался с похожими ошибками, буду рад совету.

[РАЗРАБОТКА АРХИТЕКТУРЫ]

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

1) Сегментация игры на сцены. Нужно разбить игру на определенные сцены (например, "меню", "настройки", "карта" и т.п.);

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

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

[РАБОТА НАД ОБНОВЛЕНИЕМ ФОРМАТА]

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

1) Мало визуального контента. Большая часть систем находится только на этапе концептирования и проработки, поэтому в статьях присутствует большое количество текста, что трудновато для восприятия.

2) Серьезные затраты времени на написание контента. В среднем на написание поста уходит от 3-5 часов, которые могли бы быть затрачены на работу над игрой (навряд ли при смене формата оно уменьшится, однако оно может быть распределено куда более эффективно);

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

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

1) Сократить частоту выпуска письменного контента до одного раза в две недели с целью повышения качества;

2) Выпускать статьи только в формате devlog'а, остальной контент выпускать в формате нескольких коротких-средних видео;

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

[ЗАКЛЮЧЕНИЕ]

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

Спасибо за внимание!