Опрацювання ідей
На основі попереднього документа створюється другий, найбільш важливий, який носить ім'я дизайн-документ. Він буде використовуватися на всіх наступних етапах.
В даний момент, немає єдиного визначення цього поняття, тому набір пунктів може змінюватися в широких межах залежно від проекту.
Для чого потрібен дизайн документ? Для розробників, бо містить формалізоване подання ідей; для менеджера проекту, оскільки дозволяє управляти витратами і робочим процесом розробки; для тестувальників, які повинні будуть знати, в якому вигляді передбачається функціонування різних аспектів; для дизайнерів і художників усіх рівнів, для належного розуміння з їхнього боку, створення єдиної спрямованості графічного вмісту; у разі зовнішнього замовлення - для замовника, який бачить майбутню спрямованість і плановані результати .
Установлені пункти, яким варто бути присутніми в дизайн-документі:короткий опис ігрового проекту:
платформа і системні вимоги;
список інструментів, які будуть використані у проекті (редактори, системи контролю версій, і т.д.);
архітектура ШІ, фізичного моделювання, мережевої взаємодії;
передбачуваний користувальницький інтерфейс, реалізація взаємодії з користувачем;
звуки і музика;
можливості графічного движка;
список специфічних для гри можливостей, їх реалізація;
Вимоги до моделей, рівням, текстурам. Додаткові корисні пункти:
розбивка проекту по етапах;
оцінки складності завдань;
опис архітектури ігрового движка, його компонентів
опис скриптів і спецефектів;
способи налагодження;
структуру інтерфейсу;
угоди про код;
різні технічні стандарти і правила;
формати файлів;
опис систем збирання, локалізації.В настоящий момент, дизайн документ для разрабатываемой игры находится в процессе создания.
Планування процесу
Процес розробки щодо ігр найчастіше виражається двома підходами: класичної Водоспадної моделлю, і новими гнучкими методологіями розробки - Agile.
Класична водоспадна модель є досить громіздкою річчю, коли мова йде про розробку ігор. Через великої складності ігор, тимчасові витрати на реалізацію кожного етапу в цілому досить вагомі. Так як кожен етап не може бути розпочато, поки не завершений попередній, то будь-яка зміна вимог веде до великих тимчасових витратах на втілення. Як показує практика, зміна вимог - досить часте явище.
Розробники ігор все частіше звертають увагу на гнучкі практики розробки ПЗ. Вони дозволяють набагато полегшити процес розробки, і більш стійкі до різних змін.
Серед найбільш перевірених та працюючих практик виділяють наступні :
ітеративна розробка, що складається з невеликих циклів по 2-3 тижні кожен; в кінці кожної ітерації виходить продукт, придатний до використання в тому чи іншому наборі можливостей;
юніт-тестування, яке складається в перевірці на коректність окремих модулів програми у відриві від інших;
розробка через тестування, що припускає реалізовувати спочатку тести, а потім вже функціонал, який покривається цими тестами;
рефакторинг, що полягає в постійному поліпшенні якості коду шляхом переписування проблемних ділянок; в поєднанні з юніт-тестуванням знімаються побоювання зламати працюючий функціонал непомітно для розробників;
парне програмування, в якому за комп'ютером присутні дві людини, один з яких пише код, а інший його перевіряє, задає питання і поправляє при потребі; плюс даного підходу ще й у тому, що не залишається ділянок коду, підтримуваних виключно однією людиною;
постійна інтеграція, коли зміни від розробників потрапляють на централізований сервер побудови, який займається безперервної збіркою і тестуванням всіх нових змін; плюс даного підходу в більш швидкому виявленні помилок.
Для реалізації задуманого ігрового проекту будуть використані гнучкі методології розробки, що дозволяють отримувати результат швидко і якісно.