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

Зачем нужен план

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

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

Корректировка плана

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

График: внесите в план временные рамки

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

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

Взгляните на вещи в перспективе

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

Реалистичная оценка

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

Если с предстоящим заданием вы еще не сталкивались, оценку уместно умножить на еще большее число (2 или более), чтобы быть уверенным: есть время на всякие неожиданности. При работе постоянно заглядывайте в журнал с расписанием. Его можно использовать для улучшения своих предположений, оценки эффективности и уточнения расписание. Что-то вроде My Hours способно помочь отслеживать свое время, как и ранее упомянутая Assembla.

Прекратите транжирить время

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

Это ладно, но как мне понять, что планировать?

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

Непременно нужно внести как можно больше подробностей, после чего вы и подойдете к финалу – созданию игры, потому что ваша работа с дизайн-документом как раз и означает заставить всех (включая себя) работать над игрой уже на его страницах. Если у кого-то остаются вопросы к вашей игре, прочитав ДД, они должны оказаться в состоянии ответить на них. Если ответа нет, ваш дизайн-док недостаточно детален. А если дизайн игры описан недостаточно подробно, значит, он не завершен. Найдутся и такие, что скажут будто «дизайн игры» прописывать ни к чему.

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

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

• Биографии персонажей;
• Эскизы персонажей;
• Эскизы уровней;
• Блок-схема игры;
• Эскизы игрового интерфейса.

Для эскизирования пользовательских интерфейсов я рекомендую пользовать софт типа Pencil Project.

Звучит не дурно, но... что насчет программирования? Движок-то какой использовать?

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

Скажем, поддерживает ли избранная технология платформы, на которых вы намерены работать, поддерживает 2D или 3D-движок, если игра делается на продажу, какую часть прибыли можно потратить на этот движок, какой он поддерживает файлопровод и т. д. Так, Unreal и Unity в общем сопоставимы, но имеют различия. Я мог бы выбрать Unreal, если бы речь шла об очень тяжелой игре, требующей высокой производительности графики. Unity я мог выбрать, если бы делал небольшую игру, но при этом имел необходимость полностью контролировать ее логику, а кроме того комфортнее ощущал себя в C#, а не C++. Знаю, здесь люди могут начать спорить, и любые примеры, которые я даю, способны лишь разжечь пламя холивара. Но все дело в том, что разумнее отдавать предпочтение одной технологии.

Технический дизайн

Технический дизайн – это проявление уважения к дизайну вашей игры. Видеоигры – это программное обеспечение, а в мире дизайна оно разговаривает на собственном языке. Унифицированный язык моделирования (англ. Unified Modeling Language) един для описания технической составляющей. UML конкретно говорит о том, что делает программа, какие будут у вас объекты и как эти объекты друг с другом взаимодействуют. Выстроенные вами UML-диаграммы формируют техдизайн, их цель – организационное обеспечение дизайна вашей игры. Существует множество инструментов, помогающих создавать такие диаграммы – взять хотя бы StarUML.

Вывод

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

• План: цели, задачи, проблемы. Все должно быть детализировано.
• В сутках 1440 минут. Не тратьте время впустую.
• Планы могут и будут меняться.
• Расписание: отныне ваш план содержит даты. Сроки – в них нужно укладываться. Но и ваше расписание, скорее всего, претерпит изменения.
• Используйте программное обеспечение Calendar, Time Tracking и Project Management, чтобы облегчить себе планирование и составление расписания.
• Дизайн-документ: исчерпывающий источник информации о вашей идее.
• Технический игровой дизайн, также известный как документ по разработке программного обеспечения, обычно написанный с использованием UML.

Ну, благодарю за внимание.

Дональд Мэй

Оригинал взят на https://www.gamedev.net