Всем привет! Меня зовут Пётр, и я твёрдо решил, что смогу хорошо зарабатывать на собственных играх, которые я делаю.
Подписывайтесь и оценивайте статью, чтобы следить за процессом, так как прямо сейчас начинается всё самое интересное!
В предыдущей статье я описал самый стартовый, и, зачастую, самый важный этап создания игры - планирование. Рекомендую прочесть сперва её, а затем уже переходить к чтению обратно - сюда.
Сегодня мы поговорим о таком явлении, как прототип игры, а именно - почему он вам очень нужен и что же с ним делать.
Часть 1. Абстракции
После того, как вы прошли все этапы планирования, подумали обо всех описанных мною моментах, добавили деталей от себя и них тоже подумали, можно переходить к абстракции.
Я, на самом деле, не уверен, что верно определил данную категорию, но суть её заключается как раз в таком названии.
Когда вы начинаете работать над игрой, вам нужно продумать глобальный и конечный (это важно!) набор первоначальных механик, осознать геймплей и попытаться посмотреть на всю игру целиком. Можно в контексте сравнения с игрой, близкой по жанру, но уже вышедшей.
И при проектировании абстрактной игры нужно держаться четких правил.
- Набор механик конечен для всей игры.
Не стоит наполнять игру механиками "по мере поступления". Это плохая практика, приводящая к сверхзадачам, решать которые затруднительно с каждой итерацией. Так, если в вашей игре игрок может передвигаться по земле, стрелять, прыгать и приседать, вам стоит сразу определить эти факторы. Под них в дальнейшем вы будете создавать дизайн локаций, анимации, и всё, на что влияет сам игрок. Ибо если в какой-то момент вы решите дать ему возможность лазать по стенам, то придется шерстить всю уже созданную половину игры, расставляя интерактивные области, перестраивая локации, чтобы данная активность вписывалась. В общем - набор механик конечен и определен заранее, но это вовсе не означает, что он должен быть 100% неизменен на всех циклах разработки. На этапе прототипа всё можно менять и переделывать. На то он и прототип. - Прототип не должен быть игрой.
Серьезно, это тоже очень важно. Код (и не только код) чистового проекта не должен следовать из кода прототипа. На этапе создания прототипа вы будете переписывать и модифицировать механики, интерактивности, разные скрипты и места, требующее начального осмысления. Невозможно сесть и сразу писать чистовой вариант кода. Не бойтесь ошибаться на этапе прототипа, не пишите код так, словно завтра вам его нести в "академию чистого кода". Ошибайтесь, не боясь, придумывайте костыли, которые впоследствии станут чем-то бОльшим. - Прототип должен быть большой солянкой.
Тут стоит пояснить, что речь идет о наборе механик, скриптов, разных возможностей, и всему, что будет в игре. Так, если в вашей игре персонаж должен ходить, стрелять, прыгать и приседать, то вам нужно сделать это в прототипе. Не часть из этого, а прям всё. На базовом уровне, но сделать. Если в игре есть стреляющие враги, вам тоже нужно сделать хотя бы одного. В игре планируется переход между уровнями? Отлично! В прототипе делаем один-два мини уровня и переход между ними. Если в игре подразумевается взаимодействие с предметами - смело реализуем. Наша задача сейчас - набить как можно больше шишек, продумать все основные моменты, поработать над архитектурой. Не стоит относиться к прототипу, как к конечному проекту. Будьте готовы к тому, что его архитектура окажется неверной, и вам придется переписать его полностью. - Прототип должен быть целостным.
Очень частая ошибка начинающих игроделов - делать прототип без какой-то важной части, думая, что они потом легко её внедрят. Если в вашей игре есть диалоги, не ленитесь продумать их на этапе прототипа. Сделайте кустарный UI, настройте элементы, оживите скрипты. Если в игре есть звук - добавьте озвучку в прототип. Помните, чем больше проблем вы встретите на этом этапе, тем проще с ними бороться будет потом. Так, если в игре ваш персонаж издает звук шагов при движении, заранее подумайте, как сделать переход между поверхностями, "хлюпания" ног по лужам и поступь по кафелю.
Следуя данным правилам, постройте на бумаге (или в голове) схему, или текстовое описание, или зарисуйте ваши представления об игре. Это могут быть зарисовки локаций, их описание, наброски описания механик. Подумайте о размерах игрового мира, и не бойтесь опираться на игры из вашей ниши. Смотрите на успешные проекты, во всяком случае на те, что нравятся лично вам. Прототип, как я ранее уже говорил, не должен становиться игрой. Он нужен, чтобы собрать все грабли, разложить их по своим местам и успешно обойти в будущем.
В итоге в вашей голове должна быть абстрактная игра, в которую вы можете мысленно поиграть, глядя на зарисовки или читая описания. У вас должна быть картина происходящего.
Часть 2. Архитектура
На этом этапе вам уже потребуется компьютер. В зависимости от выбранного инструмента, подумайте, как вы будете структурировать файлы в игровом проекте, разложите всё максимально удобно по папкам, чтобы вы всегда в любой момент времени знали, где расположен любой объект, звук, изображение, чтобы вы могли прописывать нужные вам пути не прибегая к постоянному "сканированию" проекта. Распределите папки так, чтобы вы могли ориентироваться в проекте. Интуитивность - главная спецификация на этом пункте.
В будущем от этого будет зависеть удобство навигации в проекте, если, по каким-то причинам вы отойдете от разработки игры и вернетесь к ней через какое-то время. Постарайтесь облегчить себе жизнь на ранних этапах.
Часть 3. Hello World!
Во многом данный пункт опирается на выбранный инструмент. Познакомиться с ним вы должны были ещё не первом этапе (планирование), так как перенести проект с одной среды разработки в другую дело не то, чтобы долгое, а вообще невозможное. Хоть и не всегда.
В геймдеве все инструменты и языки настолько рознятся, что перенос проекта тут - это создание его с полного нуля в другой среде. Вы не сможете использовать ничего из прошлого проекта, кроме базовых вещей, таких, как звуки, изображения, и т.д. Всё остальное придется создавать заново.
Так что постарайтесь сразу начать с простых вещей, пройти какой-то базовый обучающий курс. Такой курс должен присутствовать в документации, как минимум. Демонстрация самых базовых возможностей движка.
Ваша задача на 100% понимать происходящее в коде. Если у вас есть сомнения или полное отсутствие ответов на вопрос - как работает "Hello World", учитесь.
Незнание инструмента может породить большую цепочку последовательных ошибок, приводя к большой беде, что ваша игра будет тормозить, работать не правильно или вообще не работать. Вы должны (просто обязаны!) уметь отыскать, классифицировать, и устранить ошибку. Не нужно заучивать используемый язык на 100%, но научиться пользовать документацией - обязательно. Прививайте себе сразу привычку "гуглить" искомый механизм. Наверняка вы не первый, кто пользуется инструментом. Не стесняйтесь своего незнания, не выпячивайте грудь. Если вы отлично верстаете сайты или администрируете БД, ваши знания могут оказаться абсолютно бесполезными. Учитесь быть адаптивными.
И это как раз следующий пункт.
Часть 4. Протипирование.
Тут важно обрести понимание, что можно сразу писать в чистовом проекте, а что оттачивать и отлаживать в прототипе. Например, если в вашей игре враги будут ориентироваться на местности в поисках игрока, определяйтесь сразу, какой технологией они будут это делать. Navigation Mesh. AStar, RayCasting, и так далее. Технологий и реализаций много, алгоритмы есть в интернете. Если вы работаете над своим прототипом, не поленитесь создать чистый проект и воспроизвести сложную механику там. Прям выделите под неё отдельный маленький проект. После успешной реализации переносите опыт (не "копи-пастите" только) в прототип игры.
В процессе работы над прототипом не бойтесь выносить глобальные задачи во внешнюю область и решать их вне среды. Получив опыт и решение - применяйте его уже в своем прототипе.
И главное - пока вы не завершите прототип, не нужно начинать создавать основную игру.
Прототип должен содержать в себе полноценный участок игры, основные механики, в общем всё, что будет в основной игре.
В прототипе вы можете использовать ресурсы, вроде графики, как из основного проекта, так и черновые наброски, вплоть до базовых примитивов, типа прямоугольников или кубов, чтобы очертить объекты.
Основная задача прототипа - реализовать механики, геймплей, попытаться прочувствовать игровой процесс.
Звуки, графику, модели, это всё то, что можно заменить на любом этапе игры. Но и это не рекомендуется делать.
Часть 5. Итоги.
На создание прототипа может уйти достаточно много времени. Не пугайтесь сроков в месяц, три, или даже шесть. Наша задача на этапе прототипирования, - это не сделать прототип как можно быстрее; важно почувствовать игру изнутри, реализовать всё то, что вы бы хотели видеть. Нужно начать ориентироваться в механиках, игровых ресурсах, в проекте вы должны ощущать себя, как рыба в воде. Открывая любую сцену или локацию, вы должны чётко понимать, за что отвечает каждый объект, является ли он интерактивным, наносит ли игроку вред и т.д.
Итогом работы должен стать игровой проект, сочетающий в себе основные механики, диалоги, примерные уровни. Пусть визуально он сильно не дотягивает до самой игры, пусть в нем не те звуки, не те модели, важно "слепить" всё это в целостный, органичный проект, чтобы вы могли на его основе получить драгоценный опыт разработки именно той игры, какую вы хотите.
И не бойтесь ошибаться! Ошибки на этапе прототипа очень важны. Исправив их сейчас, вы с большей вероятности решите их и в будущем.
Большое спасибо всем за внимание! Подписывайтесь на мой канал и оценивайте эту статью, чтобы не пропустить следующие.
Впереди у нас ещё много интересного!