Для деяких людей це невід’ємна частина життя, але лише мало хто знає, як виглядає день розробників комп’ютерних ігор. Ми хотіли б представити цей процес читачам блогу iTizzi на прикладах, які вказують на певні методи, використовувані під час виробництва софта для ігор. Запрошуємо до прочитання.
Який робочий день у розробника ігор? Звичайно, час від часу в рамках своєї роботи він буде тестувати свій власний проект, але, перш за все, він повинен спочатку створити його, так що: моделювання тривимірних моделей, програмування поведінки об’єктів, додавання можливостей взаємодії в грі, перевірка, чи все працює правильно . І це тільки верхівка айсберга. У будь-якому випадку, занадто багато роботи, щоб зробити все за один день. Середній день розробника софта для ігор зводиться до створення одного невеликого елемента гри – наприклад, створення моделі вогнепальної зброї, використовуваного героєм, або програмування можливості використання такої іграшки в грі.
Залишається питання: що відбувається з даними ігровим елементом після його створення?
Якщо доданий елемент працює для нас, це не означає, що він буде працювати для гравців автоматично. У разі колективної роботи наші результати повинні передаватися іншим людям. Теоретично це здається ясним і логічним, але насправді все не так тривіально.
Чому потрібно ділитися своєю частиною роботи з іншими співробітниками працюють над нею?
Зрештою, адже можна пару тижнів самому попрацювати над неточностями, а тільки після коригування відправити частину іншим членам команди. Можна, але це невигідно. Це пов’язано з тим, що вартість усунення колізій і помилок прямо пропорційна моменту їх виявлення. Наприклад: якщо є ситуація, коли двоє людей беруть участь в створенні набору з десяти одиниць вогнепальної зброї в грі, буде набагато менше втрат, якщо вони дізнаються про помилку на етапі розробки першого набору зброї, ніж після виготовлення двох таких наборів. У першому випадку було б витрачено даремно в десять разів менше часу. В останньому випадку доведеться за непотрібністю викинути весь набір в сміттєву корзину.
Інша справа, що в добре організованій команді розробників iTizzi таких колізій бути не може. Але якщо вони дійсно трапляються, завдяки швидкому спілкуванню (щоденного) з іншими членами команди, ми втрачаємо набагато менше, ніж в разі менш частого спілкування (наприклад, раз на місяць).
Те ж саме відноситься до помилок в дизайні. Помилки в опублікованих версіях негативно вплинуть на ставлення гравців до роботи. Помилки, що виникають при створенні проекту, заважають роботі команди, тягнуть за собою затримки в усьому процесі і розчаровують авторів. Як може негайна синхронізація змін всередині команди вплинути на кількість помилок? Коли справа доходить до розробки програмного забезпечення в Східній Європі (включаючи ігри), ключем до усунення неполадок є раннє їх виявлення, можливе завдяки злагодженій співпраці компанії iTizzi в Вінниці, Львові, Дніпрі. Перевага швидкої зміни і автоматизації процесу побудови гри – обидві ці практики компанії iTizzi (Одеса, Київ) покращують спілкування всередині команди, тому що кожен може точно бачити, яке поточний стан проекту, «будується» він і чи правильно він працює.
Одним з важливих елементів роботи компанії є організація і обслуговування фізичних машин в режимі готовності. Щоб отримати максимальний прибуток від безперервної інтеграції, ми використовуємо сервери, які працюють без зупинки, щоб швидко виявляти проблеми незалежно від часу доби.
Процес розробки гри, розробки програмного забезпечення для ігор дуже цікавий. У компанії iTizzi він складається з етапів, які зроблять гру максимально функціональної і підходящої до високих вимог сучасних користувачів:
- Народження і обговорення ідеї гри;
- Підготовка до виробництва гри;
- Програмування та розробка софта для ігор;
- Створення графіки для гри;
- анімації;
- Звук і музика;
- Тести і поширення;
- Післявиробничий етап.