Как начать разработку игры? [закрыто]

Что вы делаете в первую очередь, когда начинаете новый игровой проект? Как начать? Что дает вам лучший старт для завершения проекта, а не выгорает до того, как он куда-то попадет?

Моды, пожалуйста, помогите с тегами … Я понятия не имею, как классифицировать это … 🙂


Прототип. Попробуйте реализовать свою игровую концепцию, используя какой-нибудь инструмент быстрой итерации. Попробуйте python или просто какой-нибудь простой в работе api с открытым исходным кодом, чтобы воплотить в жизнь свою «игровую идею». Постарайтесь максимально упростить, используйте шары вместо символов, сведите видение к какой-нибудь визуальной репрезентации. Таким образом, вы всегда можете посмотреть на него, обсудить, обсудить и дать отзыв. Установите временную шкалу для каждого прототипа (может быть, 2 дня или максимум недели?). Таким образом, вы сможете сделать в прототипе ровно столько, сколько хотите.

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

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

Надеюсь, эти несколько советов помогут 🙂


$ begingroup $

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

Лучшее средство от этого — безжалостно ограничивать вашу область видимости. Вместо того, чтобы говорить «как мне сохранить достаточно энергии, чтобы закончить длинный проект?» вместо этого вы должны спросить: «Как мне разработать проект, который будет достаточно коротким, чтобы я мог закончить его, прежде чем он мне надоест?»

События «Game jam» (make-a-game-in -а-выходные) — отличный способ начать работу, и они отлично подходят для выработки хороших привычек при создании быстрых прототипов. В WORST вы проводите выходные, создавая паршивую игру … вы, вероятно, чему-то научились в процессе … И вы сэкономили месяцы работы над идеей, которая в итоге оказалась не такой крутой, как вы первоначально думали. В лучшем случае вы обнаружите, что у вас есть что-то действительно особенное, и можете начать добавлять небольшие функции по одной, пока у вас не появится полнофункциональный проект.

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

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

$ endgroup $


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

Лучшее средство от этого — безжалостно ограничивать вашу область видимости. Вместо того, чтобы говорить «как мне сохранить достаточно энергии, чтобы закончить длинный проект?» вместо этого вы должны спросить: «Как мне разработать проект, который будет достаточно коротким, чтобы я мог закончить его, прежде чем он мне надоест?»

События «Game jam» (make-a-game-in -а-выходные) — отличный способ начать работу, и они отлично подходят для выработки хороших привычек при создании быстрых прототипов. В WORST вы проводите выходные, создавая паршивую игру … вы, вероятно, чему-то научились в процессе … И вы сэкономили месяцы работы над идеей, которая в итоге оказалась не такой крутой, как вы думали изначально. В лучшем случае вы обнаружите, что у вас есть что-то действительно особенное, и можете начать добавлять небольшие функции по одной, пока у вас не появится полнофункциональный проект.

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

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


$ begingroup $

Я бы сказал, что действительно важно всегда что-то показывать.

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

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

Небольшой момент, но кое-что, что действительно помогает.

$ endgroup $


Я бы сказал, что действительно важно всегда что-то показывать.

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

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

Небольшой момент, но кое-что, что действительно помогает.


$ begingroup $

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

$ endgroup $


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


$ begingroup $

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

Так что, если вы работаете в команде, я думаю, вам нужен стимул. Вам нужен кто-то, кто постоянно находится в контакте со всеми, чтобы убедиться, что они выполняют свою работу, и напоминать им , почему они хотят продолжать это делать.

Если вы работаете один; Я не совсем уверен. Я ужасен с художественными работами и т. Д., Поэтому я в основном сосредотачиваюсь на двигателе. Этого всегда достаточно, чтобы меня заинтересовать 🙂

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

$ endgroup $


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

Так что, если вы работаете в команде, я думаю, вам нужен стимул. Вам нужен кто-то, кто постоянно находится в контакте со всеми, чтобы убедиться, что они выполняют свою работу, и напоминать им , почему они хотят продолжать это делать.

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

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


$ begingroup $

Есть много хороших ответов, но я тоже добавлю свой:

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

Я хотел бы немного подробнее остановиться на последнем пункте, поскольку я видел, как это происходило несколько раз: никогда не создавайте сначала фреймворк. Есть много причин, но в основном у вас не будет необходимого видения, чтобы делать все правильно, вы потратите много времени на размышления о том, что, если, и вы потеряете моральный дух, когда после X дней/недель работы произойдет нечего показать.

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

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

$ endgroup $


Есть много хороших ответов, но я тоже добавлю свой:

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

Я хотел бы немного подробнее остановиться на последнем пункте, поскольку я видел это несколько раз: никогда не создавайте сначала фреймворк. Есть много причин, но в основном у вас не будет необходимого видения, чтобы делать все правильно, вы потратите много времени на размышления о том, что, если, и вы потеряете моральный дух, когда после X дней/недель работы произойдет нечего показать.

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

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


$ begingroup $

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

$ endgroup $


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


$ begingroup $

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

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

Независимо от вашей стратегии развития. Я не могу не подчеркнуть, что вы не зацикливаетесь на попытках спроектировать и закодировать игровой «движок». Каждая функция, которая не оказывает видимого или тактильного воздействия на игру, принесет очень небольшую награду. Чтобы компенсировать это с помощью основных систем, выведите на экран информацию о разработке.. IE FPS, переменные AI и любой другой текст, который поможет выявить то, чего раньше не было. Нет ничего более утомительного, чем потратить 10 часов на кодирование системы, компиляцию и получение того же опыта, что и раньше.

Несколько лет назад я написал статью о поиске своей игровой души, которая может вас заинтересовать здесь: http://deleter.phatcode.net/index.php?page=articles&a=8

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

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

$ endgroup $


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

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

Независимо от вашей стратегии развития. Я не могу не подчеркнуть, что вы не зацикливаетесь на попытках спроектировать и закодировать игровой «движок». Каждая функция, которая не оказывает видимого или тактильного воздействия на игру, принесет очень небольшую награду. Чтобы компенсировать это с помощью основных систем, выведите информацию о разработке на экран. IE FPS, переменные AI и любой другой текст, который поможет выявить то, чего раньше не было. Нет ничего более утомительного, чем потратить 10 часов на кодирование системы, компиляцию и получение того же опыта, что и раньше.

Несколько лет назад я написал статью о поиске своей игровой души, которая может вас заинтересовать здесь: http://deleter.phatcode.net/index.php?page=articles&a=8

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

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


$ begingroup $

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

$ endgroup $


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


$ begingroup $

Начните с концепции игры, установите причину игры, игровой процесс, внешний вид игры, которую вы хотите создать.

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

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

$ endgroup $


Начните с концепции игры, установите причину игры, игровой процесс , внешний вид игры, которую вы хотите создать.

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

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


$ begingroup $

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

В противном случае я как бы задерживаюсь с на раннем этапе он оказался провальным проектом:/

$ endgroup $


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

В противном случае я как бы задержусь на ранних этапах проект оказался провальным:/

Оцените статью
techsly.ru
Добавить комментарий