Ігрові прототипи

Введення

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

Теорія

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

Спершу небагато термінологія.

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

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

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

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

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

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

    * Ризик нєїграбельності фічи. Стандартний ризик, який може виникнути на будь-якому етапі розробки. Як правило, він відноситься до новаторських feature. Вірогідність виникнення цього ризику практично безпосередньо залежить від досвідченості геймдізайнера, тому реалізація в прототипі креатівних feature для молодих і недосвідчених є практично обов'язковою дією.
    * Ризик безинтересності фічи в плані ігрового процесу. Стандартний ризик. Як правило, застосовний до фічам другого порядку (кажучи іншими словами, другорядними), але в принципі не виключено і виникнення ризику по відношенню до основних фічам. Без прототіпірованія даний ризик може виявитися як на стадії first-playable, так і на стадії альфа версії, що досить сильно може вплинути на терміни появи бета-версиі.
    * Ризик ускладнення ігрового процесу за рахунок впровадження фічи. Вельми поширений ризик серед геймдізайнеров, виявляється виключно із-за неконтрольованого потоку думок. Знову ж таки, даний ризик виявляється у більш недосвідчених (хоч і у досвідчених це теж може виявитися). Спроба зробити мега-фічу, як правило, призводить до того, що ігровий процес може стати настільки складним, що грати в подібну гру зможуть тільки хардкорниє гравці після триразового прочитання керівництва користувача. Можливо, тут злегка утрирується проблема, але так стає зрозумілішою суть подібного ризику, без прототіпірованія якого, можливий зрив термінів із-за внесення відповідних змін на стадії first-playable або навіть пізнішому терміні, що ще гірше.
    * Ризик несумісності однієї фічи з іншою. Не сильно поширений ризик, проте, від цього не менш важливий. Без геймплей-тестів досить складно виявляється. Фактично, визначити наявність цього ризику буде важко навіть для досвідченого дизайнера (природно йдеться не про очевидні речі, на зразок "стріляти з дробовика і чесати собі спину при цьому"). Без прототіпірованія наслідку від спрацьовування даного ризику можуть різнитися від ступеня важливості фічи і її вкорінення в ігровому процесі.

Для кращого впровадження в мозок інформації про описані види ризиків, приведемо приклад по кожному з них.

Як нєїграбельності фічи приведемо приклад з проекту "Призначення", в демо-версії якого була реалізована така здатність персонажа: використовуючи магію, контролювати положення предмету в просторі з можливістю кидати його від себе. Проте щоб кинути предмет (та або просто його пересунути), потрібно було хіба що з бубном не танцювати. Судите самі: для виконання цієї дії потрібно було відвідай курсор на об'єкт, затиснути праву кнопку миші, потім колесом миші підтягти предмет до себе і, утримуючи праву кнопку миші, нажинати ліву. Фактично здійснити це вдавалася мінімум з відстані в 30-40 метрів. Ближче гравець просто не встигав нічого зробити. Правильною реалізацією подібної фічи може служити гравітаційна гармата в Half-Life 2.

Прикладом нецікавої фічи може служити псевдопокроковий бій з автопарируванням ударів знову ж таки з проекту "Призначення". Псевдопошаговость полягало в тому, що персонажі проводили удари один по одному по черзі (удари головного персонажа контролював сам гравець), але в реальному часі. При цьому захист від ударів проводився автоматично залежно від параметрів супротивників. Технічно, грати можна, але тривіально не цікаво, не було ні драйву, ні чогось іншого, що могло б зацікавити гравця. Прикладом же цікавого бою може служити такій з гри Dark Messiah або, наприклад, консольного God of War.

Як фічи, що ускладнює ігровий процес, приведемо приклад з гри Arx Fatalis, де для того, щоб використовувати заклинання, потрібно було намалювати з використанням миші послідовність знаків (місцями дуже непростих). Спочатку ця особливість розважає, але потім вона починає заважати, навіть не дивлячись на той факт, що в грі можна запам'ятовувати заклинання наперед. При цьому реалізація використання заклинань в класичному вигляді аніскільки б не погіршила і не змінила ігрового процесу в проекті.

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

Примітка: Авторові здається, що тут можуть розгорітися дебати, що все-таки динамічність і пошаговость можу уживатися. Проте варто пам'ятати, що стаття в першу чергу повинна бути зрозумілою людям з малим досвідом або зовсім без нього, тому тут наводяться якомога очевидніші приклади, зрозумілі з першого погляду.

Продовжимо нашу розмову про мотиви вибору фіч до реалізації в прототипі. Не розкритим залишилося тема оцінки вартості подібної реалізації. Багато хто може подумати, що тут може діяти класичний трикутник Час - Гроші - Якість з фіксацією будь-яких двох вершин. Проте, слідуючи визначенню поняття прототіпірованія про чорнову реалізацію функціональності, вершиной Якість можна нехтувати (у реалізації прототипу цілком доречно правило "Головне, щоб працювало!"). У результаті у нас залишаються два вершини: Час і Гроші. Відповідно, в які пропорції і співвідношення можуть бути між ними (по відношенню до прототіпірованію), залежить від конкретного проекту. Єдино, тут варто відзначити той факт, що бувають випадки, коли при фіксованому бюджеті наявний досить солідний шматок часу, який можна витратити на прототіпірованіє, а точніше, на реалізацію більшого числа фіч в прототипі. Проте подібне, як правило, трапляється при неправильному плануванні. Тому розраховувати на даний збіг обставин не варто. Ідеальний варіант, якщо прототіпірованіє закладатиметься спочатку в розробку проекту.

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

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

Почнемо з того, що якщо геймдізайнер хоче зробити щось хороше, то прототіпірованіє доречно завжди, може лише мінятися його об'єм. Швидше за все, кожний з нас коли-небудь робив який-небудь прототип, сам того не підозрюючи - точніше, не називаючи своє творіння прототипом. Наприклад, все в тому ж проекті "Призначення" з метою перевірки працездатності системи писалася текстова програмка, що симулює бій згідно ролевим правилам між двома персонажами. Для проекту "Корабель Поколінь" писалася невелика програма, що моделює отримання персонажем досвіду, розвиток персонажа згідно ролевій системі, а також симулятор системи стрілянини із зброї, там же дизайнер міг контролювати склад зброї, доступний для використання гравцеві на певному рівні розвитку. Таким чином, можна припустити, що кожен геймдізайнер займався чимось подібним. До речі, прототип це не обов'язково програмний продукт, наприклад, в книзі Ендрю Роллінгза і Дейва Моріса "Проєктірованіє і Архітектура Ігор" приводиться приклад гри Warrior Kings, для якої створювався прототип у вигляді намальованої від руки настільної гри.

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

    * Все фічи проекту є перевіреними багатьма проектами, що раніше вийшли. Таке можливе, якщо гра є клоном, або робиться з метою швидкого випуску на ринок, наприклад, гра по фільму.
    * Вартість реалізації прототипу порівнянна або більше вартості розробки playable демо-версії. Даний варіант можливий, якщо наявний готовий інструментарій розробки гри (engine) і при цьому велика частина фіч або як мінімум ключові, перевірені іграми, що вийшли.

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

Практика

Попередній розділ стосувався теоретичних викладень з проблеми прототіпірованія, і ми з'ясували, що створення прототипу виявляється корисним у багатьох випадках. Проте при цьому була зроблена обмовка, що прототіпірованіє доречно тоді, коли воно не є економічно невигідним для проекту. Крім цього існує і зворотний бік медалі, а саме, той факт, що навіть в рамках одного проекту прототип повинен володіти гнучкою системою настройки його функціональності. Створення подібного програмного продукту - завдання нетривіальна, до того ж, якщо вона робитиметься тільки під поточний проект, то вийде вельми витратною. Що ж робити?

Відповідь проста: було б непогано мати якийсь інструментарій, в якому була б наступна функціональність:

   1. Можливість проведення теоретичних досліджень: балансування гри, перевірка працездатності і функціонування механіки гри, збір статистичних даних, виведення необхідної інформації у вигляді графіків і діаграм, проведення різних математичних розрахунків.
   2. Можливість прототіпірованія ігрових діалогів і пов'язаних з ними геймплейних моментів.
   3. Можливість швидкого створення прототипу без знання складних мов програмування.
   4. Можливість швидкої зміни параметрів і функціональності прототипів.
   5. Можливість легкого використання отриманих в ході прототіпірованія даних.

Після аналізу початкових даних, а також наявного тимчасового відрізка, було вирішено як засіб створення подібного програмного продукту використовувати як мову програмування C#, а як середовище - Visual Studio .NET 2005. Чому був вибраний C#, можна пояснити дуже коротко - це швидко, гнучко і візуально.