Стоит ли планировать, прежде чем прыгать в коде?

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

РЕДАКТИРОВАТЬ: я работаю один над этим проектом.

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

Вы сказали две умные вещи в своем вопросе:

1. «код вместо мышления» - это целая философия, описывающая это: http://gettingreal.37signals.com/toc.php
2. «Доказательства концепции, чтобы проверить, можно ли это сделать» - я видел и имел много идей, которые оказались невозможными или чрезвычайно трудными для воплощения, когда они были почти закончены. Иногда вы просто не можете предсказать это, потому что ваша среда программирования (язык, библиотеки, производительность оборудования) ограничивает вас.

Вот почему я говорю:

• дизайн, но не создавайте огромный дизайн-документ, если вы не ищете соавторов или инвесторов, если вам не интересно, и вы не воспринимаете это как перерыв в программировании;
• всегда имейте в виду, чего вы хотите достичь; каждый модуль должен иметь спроектированный вход и выход; таким образом, вы можете легко протестировать модуль и не чувствовать блуждания в тумане;
• помните, что в любом случае вы разрабатываете большую часть времени, так как ввод кода занимает всего около 5% вашего времени (по крайней мере, ввод окончательного кода);
• программирование не является теоретической наукой, вместо того, чтобы проверять, сработает ли что-то на листе бумаги, вы можете просто написать его и попробовать; конечный продукт в основном состоит в том, чтобы сделать ввод данных пользователем безошибочным, графический интерфейс пользователя красивым и иметь дело с особыми случаями - грязная проверка идеи может быть сделана сразу;
• создайте список задач, если вы боитесь забыть свои идеи
• поговорите со своими друзьями о ваших идеях, так как они будут менее восторженными и могут иметь больше опыта в данной области; однажды у меня появилась идея держать в секрете параметры юнитов (в стратегической игре), но мой друг сказал мне, что это плохая идея, поскольку он играл в такую ​​игру, и это было ужасно для пользователя.

Да, но только немного .

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

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

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

Некоторые говорят, что вы должны писать код, а не думать? Чтобы писать код, вам нужно знать, что вы хотите создать, чтобы знать, что вы хотите создать, вам сначала нужно подумать о том, что вы хотите иметь, поэтому вы должны подумать, прежде чем писать код;).

И, если серьезно, вам, вероятно, не нужен подробный план в самом начале, но наличие плана и / или этапов всегда полезно - также для вашего отношения, когда вы вычеркиваете вещи, как сделано, вы будете более склонны делать больше Работа.

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

Вы должны знать, куда вы идете, прежде чем писать код, и написание / рисование может быть хорошим способом материализации того, чего вы хотите достичь. Я говорю рисование, потому что рисование диаграмм, эскизов и т. Д. Также может вам очень помочь. Вам не нужно делать замечательный документ, созданный с помощью Word или чего-либо еще, просто возьмите карандаш и лист бумаги (много кусочков бумаги?) И нарисуйте, напишите все, о чем вы можете подумать.

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

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

(Я предполагаю, что вопрос сделан с точки зрения дизайна кода / архитектуры, а не с точки зрения дизайна игры, хотя ответ, по крайней мере, в некоторой степени относится к обоим.)

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

Вообще, на мой взгляд, вы можете приблизительно судить о том, имеете ли вы правильный баланс, думая о сценариях «что если», как в «что если я позже (когда все полностью реализовано в той же парадигме, которую я использую сейчас) выясняю» что часть А должна работать немного по-другому, что будет означать, что мне придется полностью переделать часть В, которая соединяется с ней, чтобы учесть изменения? ". Если архитектурное изменение в одной части не требует от вас изменения более чем одной или двух других частей, и изменения не каскадируются (это означает, что вам, в свою очередь, необходимо изменить также следующие части, соединяющиеся с частью B, а затем части, соединяющиеся с их и т. д.), код разделен относительно хорошо.

Но на самом деле, это то, что вы почувствуете после получения некоторого опыта. Это отчасти потому, что каждый дает начинающему игроку совет сначала написать что-то известное и простое (Breakout / Tetris / Snake) и сделать это полностью, со всеми меню, звуками, эффектами, всем, чтобы сделать игру полностью законченной - лучше испортить меньший проект, и выполнение его (хорошим или плохим способом) точно поможет вам понять, как далеко распространяются эффекты различных архитектурных решений.