Наскільки детально та / або повно є Ваші проектні документи на гру перед початком проекту?

Мені цікаво, наскільки зазвичай оформлені ваші проектні документи перед початком реалізації проекту? Я говорю про середні до дуже малі проекти з дуже маленькою командою, де навіть повністю продуманий весь документ може становити лише кілька десятків сторінок.

Ви починаєте з грубої рамки і починаєте деталізувати деталі в той же час, коли починається реалізація?

Ви повністю розгортаєте кожен розділ повністю, перш ніж будь-яка реалізація навіть розпочнеться? Якщо так, то який відсоток змін ви побачили після початку впровадження?

Якщо у вас є досвід одного із двох сценаріїв, які я окреслив, я хотів би почути вашу думку щодо того, які проблеми викликали цей конкретний маршрут та які перешкоди, на вашу думку, допомогли вам уникнути.

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

Якщо я тим часом працюю над іншим проектом, я витрачаю свій час, складаю каракулі, щоб зрозуміти, як повинен виглядати прототип (намагайся не відволікатися на мистецтво ескізів). Тоді я ділюсь цим із друзями, почасти, щоб побачити, чи є в них внесок, але в основному, щоб змусити себе думати про речі, які не очевидні відразу (завжди є тонни речей, навіть для найрозумніших людей, які продумують найпростіші ідеї). Через пару годин, як це, я занотую деякі ключові поняття, які повинні бути в архітектурі, буквально ~ 20 слів. Тоді я можу побудувати прототип, коли матиму час.

В даний час мої ігрові конструкції були достатньо деталізовані перед початком.

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

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

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

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

З технічної сторони, перед тим, як зробити код справжнім, слід мати щонайменше кілька хвилин роздумів. Але ви завжди можете пізніше змінити рефактори.

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

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