Варто планувати, перш ніж стрибати в код?

Я завжди вважав, що планування важливе для гри. Але я не знаю, в який момент. Деякі кажуть мені кодувати замість планування, але я вважаю, що це все ще важливо, тому що, коли ти будеш в коді, ти будеш знати, що робити далі легше. Зараз я працюю над грою, в якій буде багато вмісту, тому я вирішив почати розробляти документ, що представляє вміст thhos, і на бічному рівні я роблю докази концепції, щоб перевірити, чи можна це зробити. Частини кожного доказу поняття потім можуть бути використані пізніше в реальній грі.

EDIT: Я над цим проектом працюю один.

Отже, моє запитання: чи варто планувати, перш ніж стрибати в код? Мені все ж цікаво знати, що інші мають сказати з цього приводу. Тому що я все ще отримую деякий poeple кажу, що я повинен кодувати, а не думати .. так що ви думаєте з цього приводу?

У своєму запитанні ви сказали дві розумні речі:

1. "код замість думки" - це ціла філософія, що описує це: http://gettingreal.37signals.com/toc.php
2. "докази концепції, щоб перевірити, чи можна це зробити" - Я бачив і мав багато ідей, які виявилися неможливими або надзвичайно важкими, коли вони були майже закінчені. Іноді ви просто не можете цього передбачити, оскільки ваше програмне середовище (мова, бібліотеки, продуктивність обладнання) обмежує вас.

Ось чому я кажу:

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

Так, але лише трохи .

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

Але ігри потрібно створювати ітераційно . Ви не можете створити величезну специфікацію для своєї гри і сподіваємось, що це буде весело грати. Вам потрібно регулярно проводити тестування, щоб з’ясувати, що працює, а що ні, і продовжувати повторювати. Найшвидший запуск виконуваного файлу, найшвидший дизайн гри може бути протестований, найкраща гра в кінці. Тому завжди краще почати кодування ASAP, з дуже неформального дизайну ігор, подивитися, що виходить, і продовжувати.

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

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

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

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

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

Для мене є хорошою практикою використовувати олівець і папери, це допомагає матеріалізувати свої ідеї, а також встановити, куди ви хочете піти, щоб не зайти кудись, виправити свою мету. Він працює на все, що потребує рефлексії. І в багатьох областях очевидно, щоб записати речі, перш ніж робити фактичну роботу.

Робіть все, що працює для вас. Особисто я планую речі в невеликій мірі, але не маю проектних документів, які є надзвичайно детальними планами, перш ніж я розпочну щось кодувати. Робіть все, що для вас найпродуктивніше, тим більше, що ви працюєте в самоті.

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

Як уже було сказано, вам потрібно і те, і інше. Як перепроектування, так і недоозначення потоку / структури коду може спричинити проблеми. Важко сказати, що таке правильний баланс, але, як правило, я вважаю, що мені потрібно мати хоча б розпливчасте уявлення про те, як решта коду з'єднається з тим, що я програмую на даний момент, і подумати про можливі проблеми, інакше я схильний "кодувати себе в глухий кут" - потрапляю в ситуацію, коли я усвідомлюю: "добре, тепер завдяки тому, як я вирішив цю проблему, я створив нову проблему, яка вирішила все моє попереднє рішення (або навіть більше, в гірших випадках" ) марний ».

Взагалі, на мою думку, ви можете приблизно оцінити, чи маєте ви правильний баланс, думаючи про сценарії "що робити", як у "що робити, якщо я пізніше (коли все буде повністю реалізовано в аналогічній парадигмі, яку я зараз використовую) дізнаюся ця частина A повинна працювати трохи інакше, що означатиме, що я повинен повністю переробити частину B, яка підключається до неї, щоб змінити? ". Якщо архітектурна зміна однієї частини не вимагає від вас змінити більше однієї або двох інших частин, і зміни не каскадуються (тобто, у свою чергу, ви повинні змінити також наступні частини, що з'єднують частину B, а потім частини, що з'єднуються з їх і т. д.), кодекс розподіляється порівняно непогано.

Але насправді це те, що ви відчуєте після отримання певного досвіду. Частково тому всі дають пораду gamedevs спочатку кодувати щось відоме і просте (Breakout / Tetris / Snake) і робити це повністю, з усіма меню, звуками, ефектами, усім, щоб зробити його повністю закінченою грою - краще накручувати менший проект, і його виконання (добре чи погано) точно допоможе вам відчути, наскільки далеко впливають різні архітектурні рішення.