Приблизно два з половиною роки тому я був найнятий компанією, не пов'язаною з розробкою ігор, щоб взяти участь в їх експериментальному проекті - розробці f2p-соціалочки з продакт-плейсментом. До цього весь мій досвід у геймдеві обмежувався півтора десятками невеликих флеш-казуалок і невигадливих iOS-додатків.
- Не переоцінювати себе
- Розраховувати терміни максимально песимістично - так не прогадаєш
- Геймдізайн і планування дуже важливі
- Не захоплюватися не пов'язаними з ігровим процесом речами
- Не намагатися зробити багато і погано, краще мало і добре
- Не давати приймати геймдизайні рішення людям, з геймдизайном не пов'язаним
- Тестувати на незацікавлених людях якомога раніше
- Не рефакторити завчасно (важливий продукт, а не краса коду)
- Проводити стрес-тестування і тестування на слабкому з'єднанні
- Не боятися просити допомоги
- У грі потрібно надавати гравцеві інформацію про те, на що він може впливати
- Рано чи пізно релізитися все одно потрібно
- Говорити всім гравцям одне і те ж
Команда підібралася настільки компактною, наскільки можливо: серверник, клієнтник, дизайнер, художник-аніматор. Роздувати штат інвестор не хотів, тому як сам не був упевнений в доцільності даного підприємства. При цьому кожен (крім, мабуть, мене) добре знав свою справу і був у ньому дійсно хороший. Здавалося б, все повинно вийти!
Приголомшливого успіху не було, retention і платіжні показники виявилися вкрай скромними (правда, і гроші в розкрутку не вкладалися - оцінки робили по перших 200к гравців, які прийшли в гру в перші тижні просто з каталогу «Вконтакте», поки гра висіла в розділі «нові»). У питаннях монетизації і геймдизайну я багато досвіду все одно не набрав, проте кілька висновків для себе зробив і хотів би ними поділитися - може, кому знадобиться. Тим більше, зараз, працюючи у великій ігровій компанії, я особливо чітко бачу, як розумні і досвідчені люди уникають моїх «дитячих» помилок.
На цю ж тему, до речі, я ще можу порекомендувати чудові статті «Як примудритися зробити 14 помилок, розробивши одну соціальну гру» і «Цілеспрямований збір і аналіз граблів у розробці ігор для соцмереж».
Нижчезкладене, повторюся - це суто мої персональні висновки (багато в чому капітанські), засновані на власних спостереженнях і (часто) помилках. Отже...
Не переоцінювати себе
Приступаючи до проекту, я не мав раніше досвіду в розробці ігор такого розміру і масштабу і легковажно говорив собі: «Ну, зробити гру, в якій в п'ять разів більше фіч і контенту, ніж в іграх, які я робив до цього, займе в п'ять разів більше часу», - і сильно помилявся. В результаті вилізло багато нюансів і підводних каменів, про які я навіть не здогадувався і, за великим рахунком, знати не міг. «Нам не потрібен геймдизайнер, почитаємо статей, подивимося на схожі ігри - і самі з усім розберемося», «альфа-версія буде готова до вересня, тому що мені здається, що цього буде цілком достатньо», «у інших компаній терміни великі через бюрократію, роздутого штату і занадто формалізованих процесів, а ми ж зараз як справжні інді накинемося і все зробимо».
Можливий вихід: попросити детальну консультацію тих людей, які вже таким займалися і з'їли собаку. Навіть якщо за це доведеться заплатити грошей - воно себе окупить.
Розраховувати терміни максимально песимістично - так не прогадаєш
Досить загальна рекомендація. Якщо здається, що завдання можна вирішити за тиждень - краще запланувати на неї два тижні. А то й три. Краще взяти більше часу і зробити раніше терміну (показавши себе завбачливим і швидким), ніж спробувати зарекомендувати себе умільцем-героєм, взявши часу впритул, пропрацювавши в виснажливому кранчі і все одно не вклавшись (зменшивши до себе довіру в майбутньому, і забезпечивши, що до твоїх слів вже не будуть прислухатися як раніше).
Геймдізайн і планування дуже важливі
Відсутність диздоку і плану затягнули розробку рази в два-три. Ми мали лише загальне уявлення про те, якою буде гра, на рівні: "Це буде симулятор того-то, де можна буде робити те-то і те-то... ну і ще хотілося б того-то ". Все інше вигадувалося на ходу: фічі, баланс, інтерфейс, графічний стиль. У міру того, як нам приходили в голову нові ідеї, ми нерідко відмовлялися від старих, вирізаючи шматки вже готового функціоналу, а сам проект роблячи все менш схожим на початкове бачення і повним стирчущих шматків від віддалених фіч. Виходило часом приблизно як у коміксі, тільки в межах одного проекту.
Не захоплюватися не пов'язаними з ігровим процесом речами
Був у нас у грі предмет - раковина у ванній і на кухні, звичайний собі умивальник. Надумали зробити так, щоб можна було по ньому клікнути, і звідти починала текти водичка. Художник намалювала анімацію, я додав на предмет дію і два стани: відкритий і закритий. Потім спантеличився тим, як зробити, щоб водичка продовжувала течу, якщо вийти на карту, а потім знову повернутися додому. Потім подумалося, що непогано було б зберігати стан об'єкта, щоб вода текла навіть якщо перезаходиш в гру, не закривши кран.
А тільки потім вже, після всього цього, прийшло усвідомлення: на чорта це все потрібно? Абсолютно ніякої цінності це не додає ні ігровому процесу, ні монетизації - а час марно витрачено.
Не намагатися зробити багато і погано, краще мало і добре
Це вже було озвучено мною тут в іншій формі. Суть в тому, що не варто намагатися гнатися за максимумом контенту - краще переконатися в тому, що вже існуючий працює добре. Тетріс і Bejeweled прекрасні - адже в них немає RPG-елементів, виду від першої особи, підтримки DirectX 11, аномалій і хабара. Інакше це створює лише питання начебто: «А навіщо в грі предмети XXX і ZZZ?» - «Ну, ми думали колись додати фічу YYY, пов'язану з ними, але так і не дійшли руки толком доробити».
Не давати приймати геймдизайні рішення людям, з геймдизайном не пов'язаним
У багатьох, хто не пов'язаний з розробкою ігор, буде бажання давати поради і рекомендації щодо ігрового процесу - але це зовсім не означає, що цих людей слід слухати. Навіть інвестор не повинен ставати продюсером - будучи product owner'ом, він може приймати рішення про фінансування, загальну тематику проекту, допустимі терміни та інші вимоги, однак не про баланс, арт і набір фіч.
Тестувати на незацікавлених людях якомога раніше
Ми робили непоганий ігровий процес, який був зрозумілим і досить зручним. Ну воно ж і видно, що там все просто - чого завчасно людям показувати не готову гру.
А ось тривожним дзвіночком стало те, що коли на пізніх стадіях садили когось за комп'ютер потикати в гру, постійно доводилося підказувати: «Ні-ні, тут потрібно не так», «Ну от дивись, щоб на карту вийти - потрібно на цю кнопку натиснути, хіба незрозуміло», «Ні, тут так не вийде, тут треба по-іншому натискати». І це був наш ровесник, що періодично грає в комп'ютерні ігри. А ми планували виходити в соціальні мережі, і цілитися на людей взагалі різного віку і з різним бекграундом!
І ще одна - як я читав, досить поширена - річ: критику тестувальників слід сприймати з вдячністю, без образ і спроб захиститися («ось, мовляв, гра-то хороша, просто вони нуби і не розуміють нічого»).
Не рефакторити завчасно (важливий продукт, а не краса коду)
Потенційний ґрунт для суперечок, однак моя особиста думка і висновки, зроблені з досвіду: якщо код працює і в ньому мало багів - значить, не слід чіпати його принаймні до релізу. У проекту є інвестор, кожен день розробки коштує грошей, а конкуренти за цей час випускають по три аналогічних продукти. Рефакторинг стає малополізним онанізмом на красу коду, а результати оптимізації в дусі «тепер цей конфіг парситься не за 0.3, а за 0.1 секунди - в три рази швидше!» виявляються сумнівними з урахуванням того, що згаданий конфіг завантажується тільки один раз при запуску гри; при тому, що на цю оптимізацію було витрачено три дні при незакінченому проекті. Хочеться ідеально красивого коду - пиши вечорами опенсорс-движок на гітхабі.
У комерційному ж проекті слід пам'ятати про те, що кожна дія займає час і відтягує реліз - і, відповідно, коштує грошей. Дуже спрощено: припустимо, тиждень вашої роботи коштує тисячу доларів, і ви витрачаєте її на рефакторинг. У цьому випадку слід робити це, будучи впевненим, що супровід і налагодження невідрефактореного коду в єдності відніме в сумі більше тижня часу, або можливі баги можуть принести збитки більше, ніж на тисячу доларів.
Проводити стрес-тестування і тестування на слабкому з'єднанні
Тут все просто: яким би надійним і швидким не здавався сервер - він, швидше за все, не витримає навантаження в перші ж дні. Аналогічно, якою б надійною і ефективною не здавалася взаємодія клієнта з сервером - швидше за все, при повільному або рветься коннекті щось у клієнті буде працювати не так, як слід, або не працювати зовсім.
Не боятися просити допомоги
Я не скажу за інших учасників команди, проте особисто я постійно відмовлявся від пропозицій «здай частину проекту аутсорсерам, ми виділимо тобі на це грошей скільки потрібно, нехай вони напишуть частину коду паралельно з тобою». Просто тому що не був впевнений у своєму коді. Ось, думав, у мене тут така огидна структура коду, що інші люди, напевно, навіть не захочуть з ним працювати, або будуть критикувати; і взагалі, у мене тут все так тісно зав'язано, що не можна правити щось одне, не переписуючи шматки по всьому коду - тому працювати з ним більше ніж одній людині буде взагалі незручно; та й мені тут трохи залишилося - ось ще дрібниця за пару тижнів допишу, а далі все легко буде, ось тоді можна буде подумати про аутсорсерів. Одним словом, тільки тим і займався, що придумував виправдання, чому мені не потрібна нічия допомога. А насправді - я просто боявся попросити допомоги.
У грі потрібно надавати гравцеві інформацію про те, на що він може впливати
Це - досить загальна порада, озвучена багато разів у статтях та іграх. Гравцеві слід в тому чи іншому вигляді надавати інформацію про те, на що він може вплинути і що залежить від нього. Якщо гра безпосередньо реагує на його дії - гравець повинен мати чітке уявлення, як і чому. Досить уявити, наприклад, Counter-Strike без індикатора здоров'я або патронів, або World Of Warcarft, в якому не буде відображатися рівень мобів або кількість досвіду, що залишився до наступного рівня героя. Механіка не буде відрізнятися, проте гравець буде незадоволений тим, що гра незручна і не дає йому всієї важливої інформації.
Рано чи пізно релізитися все одно потрібно
Це ще Сід Мейєр сказав, а мужик адже справа знає!
Гра завжди здавалася нам незакінченою, порожньою і абсолютно не готовою до релізу. Здається мені, що ми б могли працювати над нею ще роками, і це відчуття нікуди б не пішло. Виною цьому в першу чергу недостатнє планування і відсутність виразного диздоку, в якому спочатку був би описаний перелік фіч, необхідних до релізу, і тих, що будуть додані з оновленнями. Однак навіть і при наявності диздоку може бути необхідний фічекат, якщо терміни підтискають - і це абсолютно нормально, а часто і корисно, дозволяючи прибрати необов'язкове лушпиння.
Говорити всім гравцям одне і те ж
Створивши для гри групу Вконтакте, я залишив посилання на свій профіль у розділі «Адміністратори». Після цього мені постійно писали особисті повідомлення гравці (з них практично всі - наша ЦА: дівчатка до 14 років), серед яких часто звучали питання щодо планів на наступні оновлення і планованого контенту. Намагаючись відповідати якомога коротше, іноді я все ж говорив про щось, що тільки витало у нас в далекосяжних планах на рівні: «Може якщо руки дійдуть, додамо фічі ХХХХХ і YYYYY». На жаль, вже наступного дня в групі Вконтакте вже були повідомлення від цього ж гравця: "Розробники мені сказали, що в грі буде XXXXX", і відтепер питання "а коли ви вже зробите XXXXX? Ви ж обіцяли! "від гравців ставав регулярним.
До слова, Сергій Галенкін у своїй чудовій книзі про маркетинг дуже здорово розповідає про спілкування з гравцями, і серед іншого каже: "Якщо ви заводите представництво в соціальній мережі, будьте готові відповідати там на питання і надавати технічну підтримку. Гравці не будуть користуватися тими інструментами, які зручні вам - вони завжди виберуть те, що зручно їм ".. Я наївно вважав, що створивши в пабліку тему: «Технічні питання по грі» - я буду тільки там їх і бачити. Нічого подібного! Питання, коментарі, відгуки і скарги були скрізь: в особистих повідомленнях, під новинами в групі (абсолютно не пов'язаними з темою питання), і навіть у коментарях під особистими фотографіями в моєму профілі. Відчуваючи бажання написати, юзери пишуть скрізь, де є форма посту.