У жовтні 1997 року двоє співробітників Angel Studios розмістили на стіні повідомлення: «1 вересня 1999 року ми випустимо гру, яка подобається людям. Ми будемо знати, що вони люблять це, тому що до 1 січня 2000 року було продано два мільйони примірників».
Незабаром після цього Capcom вибрала для портування Angel Studios Обитель зла 2 до Nintendo 64. Директор проекту Кріс Фодор і провідний програміст Джеймі Браянт були доручені цим завданням, і вони почали закладати основу та збирати команду. Хоча вони обидва вже мали досвід роботи з Nintendo 64, цей амбітний і складний проект швидко продемонстрував, що вони насправді не знали, як працює N64. Звичайно, у нього є центральний процесор, і геометричний процесор, і графічний чіп, і пожежні виходи тут, тут і там, але на якій саме висоті опускаються кисневі маски, чи їх має запускати пілот вручну? У наступні кілька місяців ОС було перебудовано, векторні пристрої (так, N64 має векторний блок) емансиповані, і N64 зачаровано розкрила свої секрети.
Оригінальний Обитель зла 2 для Playstation складався з двох компакт-дисків. Ми повинні були отримати його на одному патроні. Але це просто порт, чи не так? У наших руках була класична гра з чудовим дизайном, усіма художніми роботами та налаштованим і на місці ШІ. Однак для роботи на N64 знадобилося досить розумне програмування. Групи новин, ігрові веб-сайти та, можливо, навіть видавець сумнівалися, що це завдання можна виконати.
Що пішло правильно
1. Робоче середовище та команда
Зважаючи на те, що це був дуже технічний проект, було надзвичайно важливо, щоб у нас була сильна та згуртована команда програмістів. Проект швидко набирав обертів, коли до нього прийшов Алекс Ерат, а потім і я невдовзі в грудні 1998 року. Алекс приніс багатий досвід, відданість і наполегливу працю. Щойно закінчив коледж, мені доручили зняти повноцінне відео. (Щоб дізнатися більше про те, як було досягнуто цього подвигу, перегляньте мою статтю «Місія: Compressible — досягнення повнорухомого відео на Nintendo 64» у вересневому випуску журналу за вересень 2000 р. Розробник гри.) Кріс Фодор і Джеймі Брайант поділили своєрідне спільне лідерство. Іноді це призводило до «надто великої кількості кухарів на кухні», але найчастіше вони доповнювали один одного та забезпечували ефективне керівництво протягом усього проекту. Кен Камдар прийшов наприкінці проекту, принісши відчуття безтурботності та спокою (а також своїми навичками програмування) у потрібний час. На цьому етапі у нас були представлені Австралія, Німеччина, Англія, Іран і США. Ви б не вибрали його, але це незвичайне поєднання мало рівень синергії, який рідко можна знайти в багатьох командах програмістів.
Скріншоти з Обитель зла 2 для Nintendo 64 |
У нас, програмістів, наші столи розташовувалися півколом обличчям назовні, але це не так починалося. Спочатку Кріс мав власний офіс, а Алекс і Джеймі сиділи досить далеко один від одного, обмежуючи свою територію. Однак через місяць у проекті ми значно відставали від графіка. Нам потрібно було бути в курсі справ і набагато більше спілкуватися.
Ми вирішили посидіти разом. Коли я, а пізніше Кен, прибули, вони просто збільшили півколо. Багато було написано про стани мозку та зону, і, як згадує Джеймі, «Алекс інколи перебивав мене з усіма моїми яйцями в повітрі, щоб розповісти мені якийсь дуже дурний жарт, але я гарантую, що втрачений час був ніщо в порівнянні з виграш ефективності, коли всі будуть тут». На початку проекту виникає багато запитань і рішень, які необхідно прийняти. Кожен міг слухати, навіть якщо спочатку не брав участі в обговоренні, і часто хтось повертався і пропонував перлину мудрості або нове розуміння, яке вело до кращого рішення. До середини проекту ми стали краще не перебивати нікого в глибоких роздумах. Зрештою, я вважаю, що ми заощадили місяці: «Він вийшов з ладу» [бали]. [Повертає голову] «О так, це помилка лизання — не натискайте кнопку B, коли вона це робить [бали] — і я перевірю виправлення через десять хвилин».
Довгі важкі години створили міцну взаємну довіру між групою. Незабаром ми всі працювали над своїми завданнями без нагляду. Це дозволило встановити гнучкий графік роботи без шкоди для продуктивності.
2. Забивання першої віхи
Якщо ваша компанія не видає власні назви, значить у вашому видавництві є зовнішній продюсер. Коли продюсери йдуть випити пива, вони говорять про те, як запізнилися їхні розробники, і сваряться про те, як привести їх у чергу. Багато виробників вважають, що розробники не мають уявлення про маркетингові терміни, бюджети та всі інші речі, про які ми насправді не маємо поняття. Ми розмовляємо іншою мовою. Але якщо ви досягли своєї першої віхи, ви змінилися.
По-перше, ваш продюсер має іншу історію, щоб розповісти своєму босові та колегам. По-друге, ви створили основу для спілкування — ви продемонстрували, що розумієте, що означає слово «дедлайн». Вивчивши перше слово в лексиконі продюсера, ви побачите, що потім він відкритий для обговорення більш складних ідей і навіть гнучкий щодо майбутніх термінів. Нарешті, ви маєте довіру продюсера та видавця. Якщо ви пропустите свою першу віху без уваги, ваш продюсер назавжди покладе вас у смітник для «дитячих розмов».
3. Відсутність релігійної прихильності
Ніколи не варто надто прив’язуватися до того, що ви зробили, будь то бізнес-процес, алгоритм чи просто реалізація. Якщо щось не працює, не робіть цього. Якщо щось спрацювало, а більше не працює, відкиньте це та знайдіть щось нове.
Ми застосували цей принцип до наших групових комунікацій. Ми почали з використання Microsoft Team Manager 97. Це тривало навіть не місяць. Потім ми розмістили свої столи півколом, щоб усі були під рукою та в одній кімнаті. Це спрацювало дуже добре, і ми його зберегли.
Далі Джеймі вирішив подивитися, що станеться, якщо всіх змусять використовувати один і той самий редактор із однаковою клавіатурою. Результатом стало те, що ви вивчаєте новий редактор за один день, вільно володієте ним за тиждень, і кожен може сісти за ваш комп’ютер і користуватися ним, як своїм власним.
Ми використовували систему завдань Outlook. Здавалося б, простий список завдань Outlook може використовувати електронну пошту для синхронізації завдань кожного. Це працювало дуже добре протягом кількох місяців, але через деякий час ми використовували його рідше. Це було тому, що наприкінці проекту був просто цілий список дуже добре відомих речей, які потрібно було зробити. Ми спробували дуже наочне відображення, зробивши папірці для кожного пункту завдання та прикріпивши їх на стіні під іменами кожного. І вони залишалися там, практично недоторканими, до дня, коли ми опублікували гру. Їх замінили електронними таблицями Excel.
Коли справа дійшла до програмування, таке ставлення творило чудеса для розвитку нашої системи FMV. Невпинне випробування всього, часто кілька разів (оскільки покращення якості чи швидкості робило раніше відхилений підхід знову життєздатним), принесло нам чудовий результат і вперше в галузі — високоякісне відео на консолі на основі картриджа.
Ми також дізналися про цінність написання коду для поточного завдання, а не про те, яким завданням воно може бути в майбутньому. Я сподіваюся, що більшість програмістів вважають це очевидним, але багато хто з нас (включно зі мною свого часу) загубилися на землі C++. Є багато переваг C++, але багато з них просто непридатні для продуктивності та розміру на застарілій консолі. Під час написання об’єктно-орієнтованого коду дуже легко потрапити в пастку, намагаючись створити навіть розумну систему. Не турбуйте. Будьте готові все переписати. Можливо, ви зможете переписати деяку частину коду втричі швидше, ніж це знадобиться для створення ідеальної ієрархії класів. Суть в тому, що не варто прив’язуватися до того, що є. Будьте готові викинути це і спробувати щось інше.
4. Використання детального розкладу та плану
З самого початку RE2 мав чіткий і детальний план того, що саме буде потрібно, розбитий на дуже дрібні деталі. Маючи цю інформацію, наш досвідчений продюсер Стюарт Спілкін зміг точно спланувати завдання проекту та розподілити ресурси (Стюарт відіграв важливу роль у вирішенні зовнішніх труднощів, що дозволило нам зосередитися на розвитку, завжди наближаючи проект до завершення). Я не можу переоцінити важливість детального плану. Це змушує вас досліджувати та часто виявляти, що насправді потрібно зробити, і дозволяє спланувати це. Ви не можете мати занадто багато деталей. Безумовно, це був амбітний графік, але той, який був досяжним — що робило його водночас важким і корисним.
Ми визначили пріоритетність функцій. З наближенням кінцевого терміну ми безжалісно працювали лише над основними стратегічними функціями. Час від часу виникали суперечки щодо того, які функції потрібні, а які — ні, але таке ставлення гарантувало, що ми дотримувалися плану й завершили проект. Ми хотіли, щоб наша гра була ідеальною, але її потрібно було відправити. Зробіть усе, що потрібно, щоб вивести його з дверей, а потім зробіть усі необхідні зміни, на які у вас є час.
Ми з апломбом сприйняли прохання видавця додати нові функції, особливо наприкінці проекту. Замість внутрішньої атаки «повзучості функцій», вони прийшли ззовні. Щоразу, коли пропонувалася нова функція, ми перевіряли, що знадобиться для її реалізації, і чесно розповідали про те, які ресурси знадобляться для її реалізації. Наприклад, ми підрахували, що з додатковим штатним програмістом ми точно зможемо виконати завдання А, ймовірно, завдання Б (80 відсотків) і, можливо, завдання С (20 відсотків). Тоді клієнт мав усю необхідну інформацію, щоб зробити вибір, і в більшості випадків він вибирав «ні».
Робота з цим додатковим тиском може бути стресовою, і щоразу це відриває вас від роботи. Однак ви можете заощадити графік і бюджет проекту, раціонально проаналізувавши, що потрібно зробити і що вимагатиме реалізація нової функції.
5. Максимальне повторне використання
З величезною кількістю ресурсів, наданих версією PSX, було набагато більш доцільним аналізувати кожен тип даних (2D-спрайти, дані про зіткнення тощо) і реалізувати конвеєр, який потім перетворював би специфічні ресурси PSX у те, що ми можна читати та використовувати на N64. Оскільки це був порт, ми могли бути впевнені, що в кінцевому підсумку отримаємо всі потрібні частини, якщо просто перетворимо їх повністю, замість того, щоб підправляти кожен окремо вручну, і заощадимо величезні суми часу таким чином. На написання коду, який перетворював усі 2D-спрайти у потрібний нам формат, знадобилося кілька днів, але художнику знадобилося б дуже багато часу, щоб відредагувати тисячі спрайтів вручну.
Коли це було можливо, ми емулювали специфічні для PSX процедури та апаратні функції, щоб досягти подібних результатів на N64, максимізуючи наше повторне використання існуючого вихідного коду.
Джерело: https://www.gamasutra.com/view/feature/131556/postmortem_angel_studios_.php?page=1
- "
- рахунки
- Додатковий
- AI
- Alex
- алгоритм
- ВСІ
- серед
- аргументація
- навколо
- Art
- стаття
- художник
- Активи
- Австралія
- дитина
- пиво
- рада
- Помилка
- бізнес
- який
- стягується
- контроль
- чіп
- ближче
- код
- коледж
- Комунікація
- зв'язку
- компанія
- сконцентрувати
- дані
- день
- справу
- дизайн
- Столи
- деталь
- Розробник
- розробників
- розробка
- DID
- Директор
- Не пропустіть
- Падіння
- редактор
- Ефективний
- ефективність
- співробітників
- England
- Навколишнє середовище
- перевершувати
- облицювання
- особливість
- риси
- в кінці кінців
- кінець
- Пожежа
- Перший
- виправляти
- формат
- свіжий
- майбутнє
- гра
- азартні ігри
- геометрія
- Німеччина
- добре
- великий
- Group
- апаратні засоби
- голова
- тут
- Як
- How To
- HTTPS
- ідея
- У тому числі
- промисловість
- інформація
- Іран
- IT
- мова
- вести
- Керівництво
- УЧИТЬСЯ
- вчений
- Led
- рівень
- Лінія
- список
- Довго
- любов
- Робить
- Маркетинг
- маски
- Microsoft
- мільйона
- Місія
- місяців
- Нова функція
- Нові можливості
- Nintendo
- пропонувати
- відкрити
- Інше
- прогноз
- Кисень
- Папір
- Люди
- продуктивність
- пілот
- Playstation
- press
- виробник
- Виробники
- Програмування
- проект
- публікувати
- якість
- RE
- Причини
- ресурс
- ресурси
- результати
- біг
- сенс
- спокій
- загальні
- простий
- сайти
- Розмір
- навички
- So
- проданий
- швидкість
- Стажування
- Стейкінг
- почалася
- Штати
- Стратегічний
- система
- технічний
- Майбутнє
- час
- топ
- торкатися
- Довіряйте
- нас
- us
- значення
- Відео
- Багатство
- Web
- week
- Work
- лист