Хороший процесс разработки игр для программиста

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

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

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

game-design process

— Тае Сунг Шин
источник

Ответы:

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

Это копия письма, которое я отправил одному из членов моей команды.

Выпиши краткое описание игры
Запишите основные события геймплея
прототип идеи на бумаге и посмотреть, если они логически имеют смысл. «Играть» через события на бумаге
Напишите базовый вариант использования для каждого из событий
Нарисуйте некоторые концепции художественного произведения для игры
Нарисуйте диаграммы вариантов использования для каждого из основных вариантов использования
Детализируйте необходимые системные взаимодействия, чтобы сделать возможными варианты использования (не пропускайте никаких взаимодействий, которые кажутся чёрной магией: «нажмите на экран, и единорог появляется на местности». Существует много преобразований данных, чтобы доставить единорога в точное местоположение местности под мышкой.)
начните писать диаграмму классов (избегайте классов Бога, таких как «GameCoordinator», и вместо этого создайте класс для каждого логического объекта и разбейте как можно больше взаимодействия между этими классами, это был болезненный урок)
сделать игровую демоверсию игры с ограниченными функциональными возможностями
пусть друзья сыграют и сломают
повторять ... повторять ... повторять события геймплея
вытянуть интерфейс.
заставить работать интерфейс
начать рассылать запросы на просмотр на все веб-сайты, посвященные обзорам мобильных приложений
отполировать интерфейс
испытай это на МНОГИХ мобильных устройствах, а не только на твоих
плакать от плохих отзывов
исправить большие проблемы
улыбнись на хорошие отзывы
Обновить игру

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

— Brandon
источник

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

— Брэндон

Мне очень нравятся оба ответа. Но я не думаю, что на этом этапе я сделаю шаг 2, 4, 6 для своих игр. Начиная с шага 8, это больше реализации и других действий, чем дизайн. Единственная причина, по которой я принимаю это как ответ, состоит в том, что это кажется надмножеством другого. Как вы и предлагали, я сначала начну с подхода Тетрада, а затем посмотрю, нужны ли мне какие-либо дополнительные шаги в вашем ответе.

— Тэ Сон Шин

@ Пол хороший план. Некоторые из них предназначены для шутки, но все же дают подсказки к тому, что вы испытаете. Я бы больше посмотрел на события на твоем месте. Скажем, я хотел сделать RTS, у меня были бы такие события, как «Создать структуру, обновить структуру, продать структуру, отменить сборку, переместить юнит, построить структуру формы юнитов» и т. Д. Записать их, а затем дополнительно описать, как они работают на системном уровне, можно быть полезным, прежде чем погрузиться в код. Удачи, хотя! Это всегда опыт ваших первых сольных проектов

— brandon

Лично я бы начал с быстрого прототипирования.

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

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

— тетрада
источник

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

— Джокинг

Это интуитивно понятно, но, исходя из формального опыта программирования, я чувствую, что мне нужно что-то сделать перед написанием кода. Я думаю, что при таком подходе было бы достаточно краткого описания проекта и списка дел. Спасибо.

— Tae-Sung Shin

Резюме проекта и список задач - это именно то, что я имел в виду под «несколькими заметками». Хотя держать список дел текучим; просто запишите достаточно задач, чтобы начать, а затем начать. Вы добавите больше материала в список, как вы идете.

— Джокинг

@ Пол, я полагаю, вы думаете о UML-подобных конструкциях, когда говорите, что пришли из формального опыта программирования? Все эти диаграммы (по моему скромному мнению) служат только для демонстрации вашей работы другим без объяснения кода. Я думаю, дизайн документы служат той же цели. Они могут быть использованы, чтобы показать вашу игру кому-то, если вам нужны деньги или другие виды поддержки от этого человека.

— TravisG

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

— Tae-Sung Shin