Русский
Русский
English
Статистика
Реклама

Геймдизайн

HEY! LISTEN! Каким получилось путешествие в золотой век видеоигр?

29.01.2021 12:17:38 | Автор: admin

Стив Макнил хорошо известный в Великобритании телеведущий, подкастер, стендапер, стример, актёр, а по совместительству еще и очень увлечённый геймер, ставший соавтором Dara O Briains Go 8 Bit популярного британского телешоу о видеоиграх.

В 2019 г. Стив выпустил книгу под названием Hey! Listen!, своего рода В поисках утраченного времени для геймеров, так оценил книгу один из рецензентов, подчеркнув тем самым две её главные особенности: тщательное восстановление генеалогии игровой индустрии и глубоко личное, неравнодушное отношение к описываемым событиям. Недавно книга стала доступна и для русскоязычного читателя.

Hey! Listen! очень добротная обзорная экскурсия по прошлому игровой индустрии. Каждая из 12 глав посвящена важному отрезку или эпохальному событию в истории разработки игр, так что в итоге читатель получает компактно упакованную летопись, охватывающую диапазон с 1930-ых до нашего времени. Основное внимание автора на 1970-1980-ых годах, горячем периоде, сформировавшем, по мнению Макнила, весь облик современной индустрии игр.

При этом подход Макнила далек от академичности, а сама книга меньше всего похожа на классический учебник. Рассказ о событиях то и дело прерывается комментариями и отступлениями автора. В одних случаях он, например, делится личными эмоциями от игры, в других отпускает хулиганские шутки, а в третьих разыгрывает читателя, вбросив невероятную версию.

Похоже, такие вставки должны работать на создание неформального восприятия: читатель будто попадает на стендап-шоу. Но иногда эти кульбиты выходят слегка вымученными и несмешными. Кажется, будто Стиву нужно во что бы то ни стало пошутить и продемонстрировать гиковость даже там, где этого никто не требует. Но в общем, это единственный серьёзный недостаток книги, и он не перечеркивает ее достоинств. Кстати, еще одна особенность книги это небольшие дополнительные акценты на британском геймдеве.

У истоков золотого века


Зарождение современной индустрии игр Макнил обнаруживает в 30-ых годах прошлого века, когда в барах Чикаго и других американских городов появились электромеханические пинбол-машины. Они быстро стали популярными как у азартных посетителей, так и у криминальных структур, отмывавших через них деньги.

Однако из-за законодательных запретов и ограничений уже к концу 1950-ых производство пинбол-автоматов стало убыточным. Компания Service Games воспользовалась ситуацией и выкупила часть невостребованных машин для игровых комнат военных баз в Японии. Чуть позже Service Games переименовалась в Sega Enterprise Ltd. и перешла к разработке собственных автоматов (например, симулятора военной субмарины Periscope). Параллельно производством игровых автоматов занялись и другие компании, в том числе Namco и Nintendo. Мощным стимулом развития тогдашнего геймдева Макнил считает использование монетоприемника, что в сочетании с растущим спросом на аркады и азартные игры (pachinko) открыло окно получения сверхприбыли даже начинающим компаниям.


Magnavox Odyssey

В эти же годы в США и Европе программисты-энтузиасты начинают разработку первых компьютерных игр, от версий шашек, шахмат и тенниса до разработанной Стивом Расселом Spacewar! (1962), в которой игрок управлял звездолетом в открытом космосе при помощи подключаемых к компьютеру контроллеров. Эта игра разошлась по вычислительным центрам, и один из ее многочисленных поклонников, Нолан Бушнелл, сделал попытку портировать игру для автоматов в парках развлечений. Не очень удачную, но достаточную для создания компании Atari будущего гиганта игровой индустрии. Еще одна попытка создать порт Spacewar, но уже для домашнего использования в связке с телевизором, стала в итоге основой для появления первой коммерческой игровой приставки Magnavox Odyssey.

Первой же коммерчески успешной компьютерной игрой в истории оказался Pong (1972). Простая и увлекательная игра, первый продукт Atari, предмет судебных разбирательств, Pong совершил революцию в зарождавшейся индустрии. Благодаря невероятной популярности и низкой себестоимости, автоматы с Pong приносили невиданную по тем временам прибыль. Кроме того, зимой 1975 г., после долгих переговоров, Pong выпустили на домашних консолях Sears Tele-Games и первые 150 000 экземпляров быстро были раскуплены.

Разумеется, у Pong появилось большое количество клонов и версий, помогло распространение технологии чипа, вмещающего сразу несколько игр. Да и самих консолей стало много: кроме Sears и Odyssey, на рынок вышли японская Nintendo Color TV-Game, Coleco Telstar, портативная Auto Race от Mattel и другие.

Всё это, считает Макнил, вело к новому этапу истории видеоигр, которые к лету 1978 года из развлечений для избранных фактически стали крупным международным бизнесом.

Расцвет и упадок рынка


Ещё одним фундаментальным сдвигом в конце семидесятых стало широкое использование в аркадных автоматов микропроцессоров: теперь игры создавались не инженерами-электронщиками, а программистами. Поздние семидесятые были увлекательной эпохой зарождения игр как формата.


Galaxian

Доступность и выгода микропроцессоров позволили создавать игры с более сложной графикой, векторные мониторы познакомили игроков с изображением в высоком разрешении. Но кроме них существовало и третье нововведение, которое буквально украсило индустрию, цвет! Да, до этого там и тут попадались отдельные цветные мониторы, но ни один из них не совершил такого прорыва, какой устроила [...] Galaxian. Она была не просто цветной, но и сочетала несколько цветов в каждом спрайте.

В этот же период золотой век аркадных автоматов выходят легендарные Pac-Man и Donkey Kong (дебют Nintendo на американском рынке). Успех игр был ошеломительным. Они выгодно выделялась на фоне многочисленных спортивных симуляторов и стрелялок и, кроме того, использовали анимационные катсцены для погружения в сюжет и знакомства с персонажами. Впервые целью игры стало не получить лучший счет, а пройти игру и узнать, чем всё закончилось.

Тем не менее, стремительный рост предложения и серьезное снижение спроса (в том числе из-за проникновения домашних консолей) привели к кризису в индустрии аркадных автоматов. А немного позже кризис настиг и консольщиков. Агрессивная стратегия, которой придерживалось большинство компаний, наводнила рынок множеством игр, зачастую просто халтурного качества (одной из причин этого Макнил считает бытовавшее тогда невнимательное отношение к разработке и к самим разработчикам игр). Кульминацией стал крайне неудачный выпуск игры E.T. по мотивам фильма Стивена Спилберга. Низкие продажи (при тираже в 5 млн штук!) и феноменальное количество возвратов от разочарованных покупателей стали ударом не только по репутации Atari.

Вся индустрия рухнула на дно. Череда эпических промахов Atari подорвала доверие покупателей. Рынок был переполнен нескончаемыми альтернативными консолями. У магазинов оставалось столько нераспроданных игр, что они сбывали их по дешевке. В свою очередь они перестали закупать новые партии, так что склады игровых компаний оказались забиты неходовым товаром. Компании объявляли себя банкротами, и товар сбывали уже ликвидаторы, что приводило к настоящему наводнению рынка играми за 5 баксов вместо стандартных 40. [...] Многие потребители убедились, что индустрия видеоигр действительно была пустышкой, пусть и открывшей второе дыхание в конце семидесятых.

Развитие игр для компьютеров и эпоха Nintendo


Однако в тени консольного рынка очень активно, хоть и незаметно для многих, развивались компьютерные игры: первые адаптации аркадных развлечений, первые проекты с трехмерной графикой (Maze, Microsoft Flight Simulator), первые текстовые адвенчуры (Adventureland, Zork) и адвенчуры с анимированной графикой (Kings Quest), первые ролевые игры (Akalabeth, Ultima, The Black Onyx). Они становились хитами среди пользователей и приносили авторам хорошую прибыль, несмотря на неразвитость системы дистрибуции и пиратство. Да и сам рынок был раздроблен из-за растущего числа конкурирующих машин. Положительную роль сыграл выпуск недорогих устройств от Sinclair (ZX80, ZX81, Spectrum) и Commodore (C64). Их широкое распространение Макнил называет игровой революцией, вдохновившей множество людей создавать и продавать собственные игры.


Super Mario Bros.

Одна из самых вдохновенных частей Hey! Listen! это рассказ о выходе на мировой рынок консоли NES от Nintendo. Не очень удачный запуск Family Computer (Famicom) на японском рынке, недоверие дистрибьюторов в США к очередной консоли, сорванные переговоры с Atari, старт продаж в самый сложный период (Рождество в Нью-Йорке) и в итоге поразительный успех, случившийся благодаря выходу игры Super Mario Bros.

Super Mario Bros. была первым сайд-скроллером, позволяя Марио проноситься через длинные уровни, наполненные разнообразными яркими штуками и существами. Первый же уровень настоящий шедевр геймдизайна, почти что исподволь знакомящий игрока с правилами воображаемого мира без отрыва от игрового процесса и остановок на скучные текстовые подсказки.

Nintendo удалось подмять под себя рынок, получить от других компаний эксклюзивные права на выпуск и диктовать издателям свои условия. Это повлияло благотворно на уставший от второсортных консольных продуктов рынок каждая игра Nintendo проходила строжайший контроль. Годом окончательного закрепления Nintendo на американском рынке стал 1987-ой, когда для консоли вышли Metroid, Punch-Out!!! и The Legend of Zelda, завоевавшие бешеную популярность, а на фоне роста аудитории была открыта бесплатная горячая линия по вопросам с прохождением и запущено издание собственного журнала Nintendo Power. Следующим триумфальным шагом стала карманная консоль GameBoy, часто с Tetris в комплекте (и Макнил увлеченно рассказывает о перипетиях истории прав на игру Алексея Пажитного).

Казалось, Nintendo просто не оставила шансов конкурентам. Но не тут-то было. В 1989 Sega выпускает в США 16-битную приставку Genesis. Благодаря, с одной стороны, хорошему железу и, с другой, недовольством авторитарной политикой Nintendo, Sega смогла привлечь к производству игр такие компании, как Activision, Electronic Arts и Disney. Свою роль в популяризации сыграл и ёжик Соник маскот Sega (хронике его разработки посвящена отдельная глава). Ответом Nintendo стала консоль SNES и множество новых игр в самых разных жанрах (например, сверхуспешный Street Fighter 2), а также, как с радостью отмечает Макнил, ослабление требований и ограничений для издателей.

Конец золотой эры


Пока консоли переживали ренессанс, игры для компьютеров тоже не стояли на месте. Макнил выделяет два ключевых вектора их развития. Первый создание кинематографичных игр с акцентом на захватывающей истории (продукты LucasArts и Sierra), и тут помогло появление CD-дисков и стандарта Multimedia PC. Второй развитие игр с открытым миром, где игрок буквально сам творил свою историю (игры Сида Мейера, стратегии в реальном времени). Формировалась и дистрибуция игр: от BBS и пересылки дискет по почте до компьютерных журналов (Softdisk) и интернет-доступа.


Doom

Именно в этой горячей среде Джон Кармак и Джон Ромеро (id Software) создают легендарные Wolfenstein 3D и DOOM интересные не только геймплеем и дизайном, но и условно-бесплатным распространением, которое приносило авторам баснословный доход.

Консольные гиганты не могли не видеть широких перспектив применения CD (особенно учитывая востребованность 3D-графики): Commodore, Atari и даже Philips сделали попытки выпуска дисковых консолей о каждой из них книга подробно рассказывает и каждая в итоге оказалась неудачной. На поле конкуренции остались Sega Saturn и Sony Playstation, которая в конечном итоге и выиграла борьбу за счет низкой цены и поддержки производителей.

1990-ые годы автор книги называет эпохой слияний и поглощений. Рынок укрупняется, заключается множество сделок, и к середине десятилетия складывается ощущение, что амбиции игропрома растут с невероятной скоростью. Перечисляя множество игр и студий, Макнил отдельно останавливается на трёх компаниях, которые в будущем стали знаковыми: Bethesda c серией RPG The Elder Scrolls, Interplay (переименованная потом в Blizzard) c Warcraft, Diablo и Starcraft, определившими развитие MMORPG, и, наконец, Valve с Half-Life.

С выходом Half-Life игры повзрослели то ли с сожалением, то ли с радостью замечает автор.

Заключительная часть Hey! Listen! дайджест по второй половине 90-ых: выход Sony Playstation 2 и Nintendo 64, новый тип геймпада с аналоговыми стиками, Crash Bandicoot и Super Mario 64, Tomb Raider и Resident Evil, Pokemon и Tamagotchi, первые Metal Gear Solid и Grand Theft Auto, а также The Legend of Zelda: Ocarina of Time (реплика из которой и дала название книге). Кажется, что Макнил просто разрывается в своем стремлении показать, насколько сильно выросла индустрия игр, какой она стала разнообразной и полифоничной.

В эпилоге, говоря уже о современных трендах, автор одновременно робко и по-хулигански пытается дать прогнозы на развитие рынка в ближайшие годы. Часть уже сбылась, пока книга шла к российскому читателю, а остальные что ж, посмотрим

ПРЕДСКАЗАНИЯ СТИВА НА 2024 ГОД
  • PlayStation 5
  • Очередная игра про Марио, скорее всего платформер
  • Замороченное железо, которое станет еще меньше и мощнее
  • Виртуальная реальность всё ещё фигня
  • Киберспорт в виде пилюль

В качестве заключения


Каким же в итоге получилось путешествие в золотой век видеоигр?

Безусловно, на революционные открытия оно не претендует. Никакого эксклюзива в книге нет. Как видно даже из гиперссылок к этой публикации, большую часть изложенной Макнилом информации можно найти в Википедии и других открытых источниках. Но привлекательность книги в том, что она старательно пытается быть гидом по ретро-геймингу, своеобразным, иногда очень неровным и субъективным, но искренне любящим свою тему. Пусть и с оговорками, но автору удалось передать и пассионарность разработчиков, и остроту конкурентной борьбы, и мучительные поиски инноваций.

Для тех, кто уже в теме, Hey! Listen! это панорамный взгляд (местами остроумный) на индустрию. А для тех, кто только начинает погружаться в историю игр, компактный, весёлый и очень дружелюбный путеводитель.

Подробнее..

Перевод Самый опасный геймер (про четвертое измерение, про игры Braid, Witness и их загадочного творца Джонатана Блоу)

22.06.2020 12:13:23 | Автор: admin
Статья 2012 года

Видеоигры сейчас один и самых прибыльных видов развлечений в Америке, а также один из самых подростковых, глупых и не нагружающих мозг. Серьезно? По крайней мере, так считает Джонатан Блоу. Он самый жесткий критик игровой индустрии и ее самый ценный разработчик, который стремится изменить наше представление об играх и сторителлинге. Следующим релизом, The Witness, Блоу может укрепить свое наследие или закончить карьеру. Может ли истинное искусство процветать в индустрии с многомиллиардным доходом от лазерных пушек и плотоядных пришельцев?



Как и многие состоятельные люди, Джонатан Блоу хорошо помнит момент, когда он стал богатым. В то время, в конце 2008 года, он был в минусе на 40 000 $ и жил в скромной квартире в Сан- Франциско, более трех лет тщательно оттачивая свою видеоигру, Braid в жанре платформер-головоломка с возможностью изменения масштаба времени. (как если бы, Super Mario Bros. встретился с Борхесом), в которую Блоу влил еще 200 000 $. Хотя Braid был выпущена и разрекламирована прессой, на августовском сервисе Microsofts Xbox Live Arcade, Блоу не увидел ни цента от игры, пока в один осенний день он не сел в кафе in the citys Mission district.



Я открыл свой веб-браузер и, святые угодники, теперь я богат, вспоминает он. На моем банковском счете было много нулей.

Однако, на этом сходство Блоу со средним миллионером заканчивается, потому, что в отличие от большинства богатых людей, он, кажется, слегка раздражен воспоминанием о том, как разбогател. Когда Блоу сказал мне во время типично метафизического разговора в парке возле его офиса в Беркли, что его неожиданность оказалась абсурдной, он не имел в виду это в причудливом смысле Можете ли вы поверить в мою удачу? он имел в виду это в философском, разочарованно-горьком смысле глубоко ироничной шутки Провидения.

Это лишь возвращает нас к тому, какая же фикция эти деньги, сказал Блоу, щурясь от не по сезону яркого декабрьского солнца. В один день я смотрю на свой банковский счет, и денег там не так уж много, а на следующий день их уже огромное количество, и я богат. В обоих случаях это просто цифра на экране компьютера, и единственная причина, по которой я богат, кто-то набрал эту цифру на моем банковском счете. Для самого одержимого в мире разработчика игр, семизначный перевод дал еще одну возможность поразмыслить о природе значений во вселенной.

Которая, однако, не означала, что Блоу откажется от своего состояния. Когда Braid стал настоящим феноменом в первый год продал несколько сотен тысяч копий, завоевал множество отраслевых наград и стал Примером с большой буквы в случае с видеоигрой (как с законным творческим средством) Блоу значительно улучшил свой аскетический образ жизни. Вместо своей старой Хонды он теперь управляет алой Tesla Roadster, с низкой посадкой и полностью электрическим двигателем, стоимостью 150 000 долларов, которое рвёт с места словно пуля, когда Блоу жмет газ в пол. И после триумфального года, наполненного лекциями и лаврами, он переехал в просторную квартиру на вершине холма, где из окон открывался вид на восточную часть города и залив сапфирового цвета.



И все же, кроме своего электромобиля достоинства которого он превозносит с мессианским рвением Блоу демонстрирует полное безразличие к материальным плодам богатства. Его квартира в основном пустует; книги по физике и восточной философии навалены беспорядочными грудами, как будто он только наполовину перевез свои вещи. Его минималстичная коллекция мебели почти полностью взята в аренду, в том числе пружинящий бежевый диван, который он купил всего несколько месяцев назад, лишь для того, чтобы нескольким журналистам по видеоиграм, с которыми он договорился о встрече, было где сидеть. Мне никогда не нравились деньги, сказал мне Блоу Мне не интересно иметь много очков на банковском счете. У меня сейчас хорошая машина, но у меня не так много вещей, и я не знаю, на что еще я бы потратил деньги. Так что для меня, деньги это лишь инструмент, который я использую, чтобы добиться цели.

В частности, Блоу решил использовать свои деньги почти все для финансирования самой амбициозной в истории видеоигры, которая, как он надеется, радикально расширит горизонты мира видеоигр. Хотя видеоигры давно достигли полной коммерческой зрелости (например, пропитанный адреналином военный шутер Call of Duty: Modern Warfare 3 набрал 400 миллионов долларов в первые 24 часа продаж в магазинах прошлой осенью), эта форма остается художественным застоем, страдающее от мультяшных убийств и бесконечных продолжений, приносящих доход. Блоу намеревается встряхнуть это подростковое господство с The Witness, одиночной игрой-головоломкой на загадочном заброшенном острове. В среде, все еще ожидающей своего квантового интеллектуального скачка, Блоу стремится сделать The Witness новаторским образцом интерактивного искусства сотворить своего рода гражданина Кейна в видеоиграх.



Это характерно дерзкий план для человека, который заработал репутацию не только как самого умного разработчика индустрии видеоигр, но и как его самого проницательного и поляризующего внутреннего критика. Для Блоу быть названным самым интеллектуальным мужчиной в видеоиграх это все равно, что быть названным самой целомудренной женщиной в борделе: это не совсем то, что нужно для мамы и папы. Я думаю, что массовая игровая индустрия это гребаный притон посредственности, сказал он мне. Есть несколько умных человек, которые барахтаются там, но окружающая среда препятствует творчеству, силе и строгости, так что то, что вы получаете это, в основном, атрофия.

Как разработчик, личный успех которого освободил его от власти монолитных игровых корпораций, Блоу имеет привычку лоббировать риторические ручные гранаты в отрасли. Он заклеймил так называемые социальные игры, такие как FarmVille, злом, потому что весь их смысл в том, чтобы максимизировать корпоративную прибыль, заставляя игроков одержимо регистрироваться и покупать бесполезные внутриигровые предметы. (В одном из выступлений Блоу удалось сравнить разработчиков FarmVille с грабителями, алкоголиками, Берни Мэдоффом и муравьиными паразитами.) Однажды во время онлайн-дискуссии о достоинствах короткого игрового опыта Блоу написал: Геймеры кажется, хвалят игры за то, что они вызывают зависимость, но разве это не похоже на стокгольмский синдром?

Все его публичное поведение бросает вызов интеллектуальной лени жанра. Блоу единственный разработчик на планете, который читает лекции с такими названиями, как Видеоигры и состояние человека, единственный, кто говорит о воздействии Итало Кальвино на его работу, и единственный, кто так мутит воду в сообществе геймеров, и кого воспринимают так претенциозно, что популярный гейм-блогер Kotaku ссылался на него в основной части своего поста Когда ты любишь игру, но не ее создателя.

Тем не менее, несмотря на то, что Блоу может быть суровым по отношению к своей отрасли, он применяет еще более строгие стандарты к своей собственной работе. С The Witness, на который он потратил около 2 миллионов долларов своих собственных денег, он планирует сделать не что иное, как превратить видеоигру в произведение искусства среду, способную создавать нечто более богатое и более значимое, чем предлагаемые в настоящее время мертвые цифровые игрушки.



Блоу рисует в своем воображении игры будущего, которые передают такие же острые и возвышенные впечатления, как те, что можно найти в литературе и фильмах, но выраженные способами, характерными для игр. Если видеоигра будет использоваться в художественных целях, то она должна использовать ее форму каким-то образом, специфичным для этой среды, верно?, сказал он мне. Фильм и роман могут одновременно создавать повествовательные сюжеты, но романы очень сильны во внутренних ментальных махинациях в чем фильмы посасывают, а фильмы хороши в выполнении определенных визуальных вещей. Таким образом, вопрос в том, где находятся игры на той же карте? Это вопрос, на который намеревается ответить Блоу.

Я встретил Джона Блоув начале 2011 года, когда мой друг Том Бисселл журналист и автор, нанятый для написания сценария для The Witness пригласил меня на ужин однажды вечером, когда Блоу посещал Портленд, штат Орегон. Зная неоднозначную репутацию Блоу, я ожидал что-то вроде огнедышащего техно-Демона, охваченного яростью ботаника.
Вместо этого, когда я вошел в квартиру Бисселла, я увидел очень серьезно выглядящего мужчину, медленно исполняющего ряд движений Тай-цзи в гостиной.


Jonathan Blow

Его лицо, обрамленное выступающей по центру линией роста короткостриженных волос, и со сжатыми челюстями, излучало тихую невозмутимость. Но самая поразительная черта Блоу это его глаза, которые сидят под постоянно нахмуренным лбом и, кажется, всегда обдумывают, исследуют, оценивают. Его неизменное каменное выражение лица делает чрезвычайно трудным определить, где находится Блоу на спектре между наслаждением вашей компанией и презрением ко всему, что вы отстаиваете.

Я был удивлен, когда после приятного ужина, в основном потраченного на оплакивание творческих неудач игровой индустрии, Блоу предложил мне сыграть в раннюю версию The Witness на своем ноутбуке. Разработчики игр, как правило, ведут себя патологически скрытно, предоставляя посторонним доступ к незаконченной игре только на условиях параноидального контроля, и берут клятву на крови о том, что Вы никогда не сообщите, что, скажем, пистолет-пулемет также стреляет плазменными гранатами. Блоу, напротив, подключил контроллер к своему ноутбуку, сказал мне: Получи удовольствие, и ушел, чтобы поиграть в LittleBigPlanet 2 с Бисселлом.

На тот момент игра представляла собой скорее трехмерный цифровой альбом для зарисовок без истории, построенный из устаревшей специальной графики и наполненный идеями головоломки на разных этапах завершения, но его основная механика была полностью функциональной.

В The Witness игрок открывает различные области загадочного необитаемого острова, решая серию головоломок для рисования линий на синих панелях. Первые панели достаточно просты, но позже они становятся все более изобретательными и все более жесткими. Я потратил целых 30 минут, пытаясь не пробить кулаком экран ноутбука, работая над одной особенно сложной головоломкой. В это время Блоу периодически смотрел на меня с каким-то удивленным выражением, с которым обычно смотрят на домашнюю кошку, которая гоняется за светящейся красной точкой лазерной указки. Только позже Блоу признался, что решил, что конкретная головоломка слишком сложна, чтобы оставаться в игре.

Хотя такие моменты, как правило, подтверждают репутацию Блоу как мизантропа, на самом деле он почти одержимо добросовестен. Просто у него нет терпения, чтобы няньчиться или поливать дерьмом. Много месяцев спустя в его офисе в Беркли, когда я играл в более утонченную сборку The Witness, я повернулся к Блоу за соседней партой и спросил, не упустил ли я какой-нибудь ключ к разгадке конкретной головоломки. Он уставился на меня взглядом, который мог вбить гвоздь в стену. Ключ к разгадке в том, что ты делаешь это неправильно сказал он. Другими словами: не проси меня думать за тебя.

Даже друзья Блоу выбирают такие слова, как сложный и колючий, когда описывают его. Вы должны подойти к Джону на условиях Джона, сказал Крис Хеккер, его ближайший друг из игровой индустрии, за эмпандасом с Блоу в просторном кафе в Окленде. Это не Давай пойдем и повеселимся. Это больше похоже на Давайте обсудим эту тему или Давай поработаем над нашими играми. Вы не спрашиваете Джона о тусовках, потому что он просто спросит: Зачем?

Дружба с Блоу требует терпения к его жестким, часто загадочным личным кодексам. Он любит разговаривать, но не терпит пустых разговоров и в особенности о личном. Он ходит на танцы несколько вечеров в неделю, но предложение посетить тот же клуб за пивом вызовет длительную антибарскую диатрибу. Ты отравляешь себя алкоголем, выдохнул Блоу, когда Хеккер понимающе улыбнулся рядом с ним. Вы как бы общаетесь, но громкая музыка мешает вам общаться на самом деле. Это все настроено, чтобы помочь общаться людям, которые не чувствуют себя достаточно комфортно, чтобы честно сказать, почему они там. Это меня бесит. Просто пойми, чем ты занимаешься, и делай это.

Погоди, возразил я. Ты считаешь, что люди в барах должны просто подходить друг к другу и говорить: Я бы хотел иметь с Вами половой акт?

Я думаю, что мы могли бы жить намного ближе правде, и нам всем было бы лучше, ответил он.

Беспощадное стремление Блоу к более глубокой правде началось в раннем возрасте. По словам Блоу, родившийся в 1971 году в семье среднего класса из Южной Калифорнии, эмоционально далекий от родителей, он начал выписываться из своей семьи (от которой он по-прежнему отчужден) еще в начальной школе. Его мать была набожной бывшей монахиней, которая постоянно напоминала своему склонному к науке молодому сыну о скором возвращении Иисуса. (Когда старшая сестра Блоу вышла в роли лесбиянки в середине 80-х годов, их мать отреклась от нее.) Отец Блоу весь день работал на подрядчика по обороне TRW, затем возвращался домой и проводил каждый возможный момент один в своей берлоге, где детям были не рады. Очень рано я обнаружил, что дома нет хороших примеров, так что, я вроде как должен был сам разобраться сказал мне Блоу. Я должен был принять парадигму самодостаточности.

Строгие личные кодексы Блоу достигли своего пика, когда он был ребенком. Подлинная духовная уверенность в себе стала его одержимостью, эскапизмом и суеверием для его главных врагов. Я не хотел прятаться от вещей, и я не хотел верить в удобные вещи только потому, что они были хорошими, сказал он мне. Чтобы избежать этого, вы должны быть готовы выстоять на морозе и пренебречь комфортом, а не делать свое личное счастье и благополучие целью существования.

Для Блоу это правило повлекло за собой бесчисленные акты самосовершенствования, как к примеру, отказ от предложения поехать домой из школы на машине во время ливня. Он также демонстрировал навязчивую секретность, постоянно лгал другим детям, чтобы скрыть то, о чем он действительно думал. Если вы собираетесь их перехитрить, они не должны об этом знать, сказал он мне. Неудивительно, что с таким подходом он завоевал немного друзей.

Вместо эмоциональной связи со своей семьей или с другими детьми, молодой Блоу развил глубокую привязанность к компьютерам. Когда он впервые столкнулся с Commodore VIC-20 в компьютерном классе на пятом году обучения, Блоу интуитивно понял это; он видел волнующую чистоту в логике его внутренних систем. И вскоре он почувствовал рывок своего призвания.



Первое, что я сделал в этом классе, была игра, вспоминает он. Это было похоже на игровой автомат, где вам нужно было нажимать кнопку в нужное время, чтобы сопоставить число на экране, но я заставил экран мигать разными цветами и добавил звуковые эффекты. По сути дела, полировка дерьма, как говориться, которое, на самом деле, было хорошим развитием для современной индустрии разработки игр.

Даже будучи подростком, Блоу пытался улучшить неполноценные игры, которые были на рынке. На неуклюжем домашнем компьютере TRS-80 он разработал приключенческую игру в духе Индианы Джонса на основе текстовой графики ASCII, в которой игрок уклонялся от стрел и обходил ловушки.



На Commodore 64 Блоу сделал еще одну игру, которая была объективно лучше, чем Pac-Man во многих отношениях, а именно потому, что в ней было большое разнообразие карт.



Но только в середине 20-х годов Блоу начал заниматься разработкой игр. После пятилетнего обучения в университете Беркли, где он изучал информатику и писательское мастерство, но не успел закончить один учебный семестр, Блоу несколько лет метался от скучных технических работ в Bay Area.

В 24 лет, он взял 24 000 $ своих сбережений и с другом из Беркли создал свою собственную гейм-дизайн студию бизнес, который упорно отказывался процветать. Несмотря на то, что они выпустили законченную игру (трехмерную многопользовательскую научно-фантастическую игру о войне с ховертанками). Эта крошечная фирма стартовала как раз в то время, когда кончалась эра небольших студий и началось доминирование многомиллионных корпораций разработке игр. Бизнес рухнул через четыре года, задолженность составила 100 000$.

К началу 2000-х над Блоу нависла серьезная опасность стать провальным разработчиком игр. Он зарабатывал на жизнь консалтингом для технологических компаний и игровых студий, но изо всех сил старался поддерживать любой энтузиазм по этому поводу. У меня ужасная трудовая этика, когда я делаю вещи, которые меня не волнуют, сказал он мне. Я не могу замотивировать себя что-то делать, если это что-то не самое важное для меня. Так что, я бы делал плохую работу.

В течение многих лет он проводил экспериментальный семинар по геймплею на ежегодной конференции разработчиков игр и писал ежемесячную колонку по программированию для журнала Game Developer (в котором его произведения носили заголовки вроде Скалярное квантование и Мой друг, Ковариационное тело), в то же время он недовольно возился с секретными игровыми проектами, от которых он вскоре отказался.

Затем, в конце 2004 года, у Блоу появилась идея Braid, и все изменилось навсегда.
Нет хорошего способа сказать это, но это должно быть сказано: видеоигры, с очень немногими исключениями, являются тупыми. И они не просто глупы, в том радостном, подмигивающем способе, что и большой голливудский фильм; они глупы в своей легкомысленности, мучительно-серьезно глупы, как взрослый человек в силиконовых эльфийских ушах, рассказывающий эпическую поэму о Гэндальфе. Помимо нескольких по-настоящему умных игр, рейтинговые, такие как The Elder Scrolls V: Skyrim и Call of Duty: Black Ops как правило, так простецки и плохо написаны, что они делают фильмы Майкла Бэй похожими на сериал Крестный отец.

В играх кирпично-подобные мужчины выкрикивают такие броские фразы, как Suck pavement!, и держат в руках гигантские винтовки, которые выглядят как двуручная пила, в то время невероятно пышногрудые женщины рвутся в бой в одежде, которая заставит даже фотографа Victoria's Secret покраснеть. Нюансов и развития персонажей в играх просто не существует. В играх любое затруднительное положение или линия диалога, от которой у среднестатистического студента-второкурсника, страдающий от СДВГ, начнут зудеть мозги, вычеркивается, а затем, в идеале, заменяется катсценой чего-то большого взрывающегося.

Даже самые стойкие защитники отрасли признают хроническую тупость современных видеоигр, обычно с беспомощным пожатием плеч, потому что, эй, самые нелепые игры также могут быть самыми веселыми. (В конце концов, тот факт, что в играх Super Mario речь идет о пухлом водопроводчике с густым итальянским акцентом, который прыгает на зловещих двуногих грибах, не делает игры менее приятными для прохождения). Но эта ситуация ставит в тупик защитников видеоигр. Трудно требовать уважения к творческой среде, когда нужно постараться назвать хоть что-то, что можно назвать художественным или высокоинтеллектуальным из того, что в это среде создано за последние 30 лет.

Когда я впервые встретил друга Блоу Криса Хекера в его бунгало в Окленде, он бросился к своему столу в тапочках с клейкой лентой, чтобы показать мне свою любимую демонстрацию этой обескураживающей реальности. Посмотрите на это никогда не подводит, сказал он, склонившись над клавиатурой компьютера. На одном из своих мониторов-близнецов Хеккер открыл раздел трейлеры фильмов на Apple.com; с другой стороны, он загрузил страницу предстоящих релизов GameSpot.com.

Фильмы, указал Хеккер, охватывают огромное разнообразие тем и подходов: от дурацких комедий до исторических драм и высокохудожественных фильмов. С другой стороны, видеоигры представляли собой почти все вариации на одну тему: причудливо одетые люди, вооруженные гигантским оружием, расстреливающие все подряд.

Люди думают, что игры появятся, когда люди начнут воспринимать их всерьез, сказал Хеккер, взволнованно повысив голос. Нет! К играм не относятся серьезно, потому что материал, который выходит дерьмо. Почему это кого-то волнует? Это просто подростковая ерунда.

Фактически, когда Роджер Эберт лихо заявил в своем долгом (и плохо изученном) эссе, что видеоигры никогда не смогут быть искусством, интеллектуальная элита игрового сообщества смогла указать только два популярных названия, которые могли опровергнуть его утверждение.

Одно из них успокаивающая игра для PlayStation 3 Flower, в которой игрок берет на себя роль ветра и проникает через буколические пейзажи, опыляя растения и исправляя экологические ошибки. Это замечательная игра, такая же художественная, как картины Томаса Кинкейда.

Другим, более подходящим предложением была игра Блоу Braid.

Когда в августе 2008 года дебютировал Braid, никто никогда не видел видеоигру, подобную ей. Одной только ее эстетики было бы достаточно, чтобы Блоу выиграл награду.

В то время как большинство игр начинаются с громоподобной музыки и сногсшибательной кинематографии, Braid открывается темным, живописным полотном ночного города, здания которого охвачены огнем. Твой персонаж Тим стоит в тени на переднем плане; по мере продвижения его по экрану, редкие и грустные саундтреки успокаивают, и вы вдруг видите, что эта картина является игрой. Вскоре Тим появляется на освещенной лампой улице в школьном костюме и галстуке с задумчивым выражением лица. Когда он входит в свой дом и затем открывает единственную доступную дверь, Тим оказывается в комнате, сделанной из нежно струящихся облаков, и начинается игра.

На первый взгляд, Braid это простой двумерный платформер с боковой прокруткой (игра, в которой персонаж тратит много времени на прыжки между платформами), который логически вытекает из устаревших игр. Тим отправляется на поиски, чтобы спасти принцессу, читает Тим в первой книге, среди облаков и разноцветных блесток, сверкающих на ее страницах. Ее схватил ужасный и злой монстр. Но Braid настолько же о спасении принцессы, насколько Метаморфоза Кафки о насекомом.



Через книги, которые находит Тим, Блоу раскрывает, что Тим совершил ошибку и надеется исправить ее, с чем связан основной игровой механизм: уникальная способность Тима перематывать время. Поскольку Тим пытается разрушить свое прошлое, он также должен разгадывать головоломки, которые вращаются вокруг его контроля над течением времени.

Вдохновленный альтернативными реальностями, представленными в Невидимых городах Итало Кальвино и Снах Эйнштейна Алана Лайтмана, Блоу создал пять основных сфер, в которых время ведет себя совершенно по-разному. В одном мире некоторые объекты не подвержены перемотке Тимом; в другом его простое движение влево и вправо заставит жителей мира путешествовать во времени назад и вперед.

Еще, возможно, самая поразительная особенность Braid в том, что она гораздо больше, чем любая другая игра, ощущается как полностью авторский текст она также богата смыслом и эмоциями, как и любой хорошо продуманный рассказ.

Тим в своем путешествии встречается со многими книгами, наполненными подсказками, и вскоре мы начинаем подозревать, что его стремление спасти принцессу это не то, что казалось первоначально. В некоторых местах принцесса чувствуется материальной, и мы узнаем, как далеко от нее Тим, о том, что она никогда не понимала мотивов, которые им двигали. Но иногда принцесса становится загадочно абстрактной: Если она существует, она должна! Она преобразит его и всех остальных.

Со временем Блоу делает портретный набросок человека, бегущего изо всех сил в погоне за чем-то духовно бльшим, чем он сам, человека, бескомпромиссная интеллектуальная серьезность которого изолировала его от мира, который течет наоборот. В общем, человека, очень похожего на Джона Блоу.

Это чувство авторства не было случайностью, потому что основной целью Блоу в Braid было передать сообщение, которое, как он выразился, достаточно важно для меня, чтобы я провел три с половиной года своей жизни, пытаясь выразить его. Удивительно, но базовое игровое программирование заняло совсем немного времени. Когда в декабре 2004 года Блоу впервые решил воплотить в жизнь свою идею о перемотке времени, он был в отпуске с другом в Таиланде.

Я чувствовал себя довольно замотивированным, вспоминал Блоу в своей квартире однажды вечером. Итак, я сказал: Почему бы мне не провести эту неделю в кафе в Чиангмае и не заняться этой идеей? И за эту неделю у меня уже была рабочая основа игры.

То, на что потребовалось следующие три с половиной года жизни Блоу, а также много денег, было совершенствование его видения.

К концу 2005 года, головоломки из Braid были закончены, но Блоу отказался выпускать игру до того, как он почувствует, что она готова. Джона не напрягало время или бюджет, сама игра всегда была на первом месте сказал Дэвид Хеллман, художник, который создал живописные картины для Braid. Я дал Джону кучу идей, и быстрый выбор не был для него главным приоритетом. Даже когда мы приступили к мельчайшим деталям, он все еще искал, что изменить в одной строке, если это позволит сделать ее тоньше.


David Hellman

Блоу упаковал мир Braid с небольшими визуальными намеками на более глубокую историю. И вместо того, чтобы платить композитору игровой музыки за создание саундтрека, Блоу сделал необычный шаг в лицензирование существующей музыки. Люди, которые создавали эти песни, законно заботились о музыке, которую создавали, пояснил он. Это было правило номер ноль, самое важное.

Из-за потока глубоких мыслей, которыми Блоу наполнил каждый кадр, сообщество видеоигр сначала не знало, что делать с Braid. Многие геймеры осыпали игру похвалой, но очень немногие могли сказать вам, каково ее значение загадка, лучше всего воплощенная в гениальной концовке Braid, ставшая одним из самых известных эпизодов в истории видеоигр.

После прохождения в Braid пяти основных царств, Тим, наконец, достигает мира, который удерживает его принцессу, места, где время беспрестанно течет оборот. Когда саундтрек катится назад, мы видим, как пузатый рыцарь, спускается по лозе, а у него в лапах принцесса, которая вырывается от него и взывает о помощи. Между Тимом и принцессой стоит длинный горизонтальный барьер. Когда стена огня приближается к ним слева, они мчатся назад к моменту времени, когда они были в последний раз объединены, уклоняясь от врагов и помогая друг другу выбираться из ловушек. Однако, когда Тим наконец достигает принцессы, нет нежной сцены воссоединения влюбленных; вместо этого его прибытие вызывает зловещую вспышку. Мы видим принцессу, спящую в коттедже. Тим беспомощно стоит снаружи.

И затем время начинает перематываться (что заставляет события разворачиваться в их правильной последовательности), позволяя нам увидеть правду: все это время принцесса не ждала Тима, чтобы он спас ее; она бежала от него. То время, когда, казалось, она убирала препятствия для Тима, на самом же деле, она отчаянно бросала их на его пути. Крепкий рыцарь, который ее утащил, на самом деле был ее спасителем. Мы понимаем, что ужасный и злой монстр Тим. Далее следуют звуки взрывов мозга нескольких сотен тысяч игроков.



Отсюда все становится даже по неигровым стандартам необычайно загадочным. Тим находит новые книги с загадочными сообщениями: виньетка с Тимом возле кондитерской, в которую невозможной войти; цитата из моментов после легендарного испытания атомной бомбы Тринити; описание того, как Тим вживил вольфрамовые столбы в черепа обезьян, жаждущих воды.

Опытные игроки внезапно осознают, что Braid это аллегория развития атомной бомбы. И эта интерпретация кажется только началом. Как и любое другое произведение искусства, Braid полна всевозможных интерпретаций. Как сказал мне Том Бисселл: Braid это игра о прыжках на дерьме, и то, что Джон имел достаточно дерзости, чтобы взять платформер и превратить его в грандиозное утверждение о человеческом существовании, это просто невероятно.


Tom Bissell

Однако, к бесконечному ужасу Блоу, основное сообщество видеоигр оказалось не заинтересованным в изучении скрытых глубин Braid. Чаще всего люди предполагают, что игра о расставании, что Блоу горячо отрицает; он даже оставил гневные комментарии на интернет-досках объявлений, чтобы исправить неверные интерпретации. Что еще более распространено, так это то, что люди проходят финальный уровень с принцессой, а затем начинают считать, что это похоже на неожиданный финал М. Найт Шьямалана, сказал Блоу, когда немного поостыл, и смог сдерживать свою ярость. Как если бы вы сказали: Вот, дерьмо, Тим все это время был сталкером! Но это даже не имеет смысла.

Не то, чтобы Блоу когда-либо на самом деле прямо говорил, о чем Braid. Каждый раз, когда его спрашивают, он дает какую-то версию одного и того же ответа, которая заключается в том, что ответ находится в игре, если только вы захотите посмотреть.

Другими словами: не просите меня думать за вас.

Несмотря на его хладнокровие, сдержанную манеру вести себя, Джон Блоу вряд ли самый терпеливый человек в Сан-Франциско. Столкнувшись с какой-либо задержкой, он имеет привычку нервно барабанить по ближайшей поверхности или проскальзывать в последовательность Тай-цзи.

Даже не источая бешеной, зависимой от смартфона ауры современного бизнесмена, Блоу является ревностным максимизатором своего времени. Он презирает просмотр спортивных состязаний, потому что слишком мала их реальная отдача от часов, инвестированных в них. Если электрическая бритва и волнистые пучки волос, разбросанные вокруг его раковины в ванной, являются доказательством, он, кажется, сам подстригает волосы дюжиной быстрых движений, когда это необходимо. И чтобы сделать получасовые поездки из своей квартиры в Беркли более конструктивными, Блоу слушает аудиокниги литературной классики в своей Tesla. Когда я пришел в гости, он только что отбросил Анну Каренину за то, что этот роман слишком похож на мыльную оперу. Теперь он слушал Уолдена.

На протяжении всего моего визита, каждый раз, когда я забирался в его Roadster, мы сразу же слышали, как актер делал свое лучшее впечатление Торо, заявляя в стенторианских тонах о пушистых зверях в их норах. Это имело определенное резкое качество. Однако однажды, после долгого разговора о видении Блоу The Witness, шокирующе громко Торо казался почти ясновидящим. С чуть более обдуманным выбором своих занятий, заявил он, все люди, возможно, станут учениками и наблюдателями, поскольку их характер и судьба, несомненно, интересны для всех.

Блоу выключил стерео и повернулся ко мне. Честно говоря, я этого не планировал, сказал он.

В очень многих словах Громкий Торо только что описал центральную идею Блоу для The Witness. В то время как многие современных игр построены на основе стрельбы или прыжков, или, скажем, творческого использования шахтерского оборудования для уничтожения космических зомби, Блоу хочет, чтобы смысл The Witness был актом наблюдения, обращением внимания на окружающее. Говоря об этом, он начинает звучать почти как мастер Дзен. Вещи сокращаются до базовых актов движения и наблюдения, пока эти чувства не станут утонченными, сказал он мне. Чем дальше погружаешься в игру, тем больше речь идет даже не о мыслящем уме, но об интуитивном уме.

Таким образом, игровой мир The Witness источает монашеское чувство тишины и покоя, которое только усиливает великую тайну в его сердце. Когда игра начинается, вы обнаруживаете себя в мрачном коридоре, ваш взгляд сосредоточен на отдаленном участке света. После перемещения вперёд (The Witness, в отличие от Braid, представлен в 3D), вы попадаете в то, что кажется бункером времен Второй мировой войны, как если бы его придумала IKEA, оборудованный редкой модернистской мебелью, сквозь окна проникает солнечный свет. Вскоре вы обнаружите, что застряли в странном комплексе на маленьком острове (установка, вдохновленная классической игрой Myst), чьи пышные сады были созданы и окружены заботой на уровне Букингемского дворца. Единственный ключ к разгадке, почему вы там, который вы получаете, это ряд аудиокассет, разбросанных по всему острову, рассказанных загадочным человеком, который утверждает, что хочет помочь вам. Все здания заперты вам придется выяснить, как попасть внутрь, говорит он, имея в виду сотни разбросанных вокруг голубых панелей-загадок. Но он добавляет: У вас есть время; вам не угрожает какая-то опасность не больше, чем мне, во всяком случае".

Отсюда и игра сама простота (за исключением, конечно, время от времени взрывающих мозг головоломок). Игрок может свободно бродить по острову, принимая вызовы в любом желаемом порядке. Кривой обучения не существует; все, что вы делаете в The Witness, это передвигаетесь, решаете головоломки и замечать вещи. Этот аскетизм следует основным принципам философии игрового дизайна Блоу. То, что я делаю сейчас, это то, как много вы можете сделать и как далеко вы можете продвинуться с минимальными элементами управления, сказал он мне. Каждый раз, когда вы выбираете игру, в которой есть много элементов управления, вы начинаете нажимать не на те кнопки и вновь задаетесь вопросом: "Что же делает X?" Это не тот игровой процесс, который мне нужен. Вместо того, чтобы заставлять вас играть с 15 кнопками, Блоу хочет, чтобы вы обратили внимание на в общем-то, чтобы вы обращали внимание. И он упаковывает The Witness с минимальным и достаточным количеством деталей окружающей среды, чтобы сделать осознанность полезной.
Первый день, который я провел в его небольшом открытом офисе в Беркли, Блоу осмотрел тщательно продуманный новый игровой мир с архитектором-дизайнером по имени Динна Ван Бурен, которую он нанял для проектирования зданий острова. Хотя Блоу и Ван Бурен работали над архитектурой The Witness более года, целью ее визита в этот день было собрать скриншоты зданий для публикации дизайна. Однако остров был в беспорядке. Блоу и его команда 3D-художников активно обновляли визуальные эффекты с тех пор, как я в последний раз видел игру, почти год назад, поэтому сейчас, когда цвета бросались в глаза, а вода мерцала великолепно, в процессе все беспорядочно перемешалось; деревья местами парили на высоте 20 футов над землей, а блестящие клочки травы были похожи на разбитые окна в другом измерении.

Ничто из этого не создавало проблем для Блоу, который не только знал каждую причуду острова, но и сам написал программу редактирования уровней игры. Для первых снимков Блоу пилотировал себя в Крепости, разрушенной серой башне, расположенной среди живых изгородей и пушистых осенних деревьев красного, оранжевого и желтого цветов. Его пальцы пролетели над клавиатурой, складывая и вычитая визуальные элементы. О, мне это нравится, сказал Ван Бурен, когда его взгляд залип на лестнице внутри башни, ведущей вверх. Это на самом деле передает историю этого места. Позже Блоу ускорился к Фабрике, просторному зданию с красной крышей, которое, как оказалось, плыло по ряби океана. Брови Блоу нахмурились. Давайте поместим это на какую-то землю, сказал он, вызывая травянистую равнину.

Местным языком для острова являются адаптивно повторно используемые здания, сообщила мне Ван Бурен, пока мы ждали. Поскольку я понятия не имел, что это значит, я спросил, была ли это первая видеоигра, над которой она работала. Пффф. Будь уверен. Ты не найдешь много архитекторов, которые бы делали что-то подобное. И ей могло нравиться проектировать для виртуального мира? Она улыбнулась: Это намного веселее, чем соблюдать строительные нормы и правила.

Когда Ван Бурен ушла, Блоу высвободил меня из своего терминала и плюхнулся на диван с ноутбуком, чтобы ответить на несколько писем. То, что меня оставили бродить, наполнило меня головокружительным чувством, которое я испытывал в детстве в заброшенных залах общественной радиостанции, где мой отец работал утром по воскресеньям; без присмотра я мог раскрыть неисчислимые секреты этого места. Нажимая на кнопку редактирования, я перемещался сквозь стены и склоны холмов в поисках наполненных подсказками аудиокассет от загадочного рассказчика игры.

И все же, к своему удивлению, я обнаружил лишь несколько атрибутов традиционного повествования в этих лентах очень мало предыстории или драматических сюжетов. Вместо этого я столкнулся с серией очень личных виньеток. В одной рассказчик говорит о своем одиноком детстве в Калифорнии 1970-х годов; он вспоминает, что на каждой перемене он в одиночестве играл на качелях, закрывая глаза и фантазируя, что когда-нибудь Та Самая Девушка просто увидит меня здесь, мои глаза будут все еще закрыты; она подойдет, ничего не говоря, и нежно поцелует меня Я ждал, но этого не случилось. В другой записи он описывает эмоциональную боль, которую он испытывал, когда начал лысеть в 20 лет, и как сегодня полуостров из волос высовывается наружу под углом к левой стороне моего лица. Возможно, самая поразительная запись начинается так: Я мог сделать что-нибудь со своей жизнью, но каким-то образом я закончил создавать головоломки, ни последние из них находятся здесь, на этом острове.

Я отвернулся от монитора и посмотрел на мужчину на диване лицо, залитое светом его ноутбука, V-образная линия роста волос слегка отклонился влево, и я понял, что с самого начала я бродил внутри разума Блоу.

Отложив в сторону описание Блоу The Witness как игры, основанной на обращении внимания, трудно точно сказать, о чём игра. В первом воплощении своей истории Блоу работал с Бисселлом над созданием традиционного повествования, наполненного сложными персонажами и драматическими ритмами, подход, от которого Блоу вскоре отказался, так как он был слишком голливудским. (Только в мире Джона Блоу супер-сжатая история, основанная на картинках из сознания замученного человека, станет голливудским сценарием, усмехнулся Бисселл) Таким образом, Блоу взял на себя обязанности по написанию и создал непоследовательную вымышленную структуру, которая расширяет саму идею повествования в интерактивной среде. Чтобы разгадать тайну вашей цели на острове, вы должны собрать воедино ответы из подсказок, похожих на сфинксов. Но если вернуться к вопросу в начале этого абзаца, The Witness на самом деле о двух вещах: о Джоне Блоу и о смысле жизни.

Или, объединяя эти два момента, речь идет о смысле жизни Джона Блоу.

Загадка, почему кто-то столь скрытный решил публично раскрыть свои самые глубокие секреты в The Witness, является непростой, особенно если говорить о Блоу, человеке, который принципиально отказывается объяснять смысл своих игр. Тем не менее, ответ на этот вопрос помогает нам понять саму суть того, что делает его игры такими трансформирующими. В The Witness Блоу стремится отдать должное видеоигре как художественной среде, полностью независимой от всех своих предшественников.

Отказ Блоу объяснить смысл его игр, в конце концов, проистекает из глубокого уважения к его искусству. С тех пор, как современные технологии впервые сделали возможным создание сложных видеоигр, разработчики предположили, что художественная судьба видеоигры стать фильмом с интерактивностью игрой, переплетенной со сценами, основанными на языке кино. И не только любые фильмы. Фактически, эталоном для видеоигр является дерьмовый боевик, сказал Блоу во время разговора в столовой с Крисом Хеккером одним солнечным днем. Вы не пытаетесь создать такую игру, как Гражданин Кейн; вы пытаетесь сделать Bad Boys 2. Но несмотря на то, что вопросы о вкусе фильма не имеют значения, идея о том, что игры даже попытались бы избежать неприятностей, связанных с фильмом Блоу. Как объяснил Хеккер: Смотри, фильм не превращался в фильм, пытаясь быть театром. Во-первых, они должны были выяснить, что они могли сделать, а чего не мог театр, например, перемещать камеру и редактировать эпизоды и только тогда фильм стал самим собой. Именно поэтому Гражданин Кейн сделал так много, чтобы поставить кинопроизводство на карте: не просто потому, что оно было хорошо сделано, а потому, что оно дало богатый опыт, который не мог предоставить ни один другой медиум до этого.

И поэтому Блоу, всегда верный своему кодексу, чувствует, что он обязан защищать свое призвание, не сводя видеоигры к терминам, которые мы используем при разборе фильмов и книг. Это означает, что в некоторой степени невероятно, что Блоу не верит даже в попытку передать главное послание игры словами; сам носитель, утверждает он, является посланием. Если игры это просто фильмы с интерактивностью, если у них нет ничего, что является их основной компетенцией, то вы не сможете использовать их эффективно, пояснил он. Теперь, одна из этих ключевых компетенций для игр это определенный вид невербального сложного общения, верно? Вы играете в игру часами, и, в конце концов, у вас, надеюсь, будет несколько возвышенное и сложное понимание того, что трудно выразить словами, потому что вы поняли это невербально.

К черту, головоломки и окружения как Braid, так и The Witness функционируют как длинный поток невербального общения вот почему он не будет убивать их, выражая их сообщения словами. В одной памятной беседе после разговора, который он дал в Университете Райса, студент настаивал на объяснении начальных образов Braid, и Блоу ответил категорическим отказом. Насколько я понимаю, вся информация о том, что там происходит, содержится в игре, и это все, что должно произойти, сказал он. И именно поэтому я делаю видеоигры. Вот почему я не хочу тебе говорить.

Решение Блоу обнажить свою душу в The Witness вытекает из того же стремления полностью реализовать потенциал своего художественного творчества; он считает, что значимая игра должна быть честной. Он свободно признает, что рассказчик The Witness является тонко завуалированной версией его собственной психики. Когда рассказчик говорит о своей вине за то, что он потратил миллионы на создание острова, заполненного головоломками, вместо того, чтобы использовать эти деньги для более важных дел, это настоящая духовная дилемма Блоу. Когда рассказчик размышляет о своих чувствах пустого тщеславия, об отчуждении от других, о своем стремлении к истине и глубокому пониманию, это боли и желания Блоу.

Я не думаю, что для человечества в конечном счете слишком важно, чтобы я сообщал о проблемах моей личной жизни, пояснил он. Мне больше интересно говорить о более широких фактах существования, которые выходят за рамки индивидуумов, но путь к этому честно и без обиняков лежит через личное. Эти откровения жгут его, но Блоу чувствует, что его высшая цель в создании The Witness оправдывает дискомфорт.

Если вы даже не можете иметь дело с кем-то, кто знает личные секреты мыльной оперы о вашей девушке или о том, как вы себя чувствовали, когда были ребенком, или что-то в этом роде, если вы чувствуете необходимость скрывать те вещи, которые настолько крошечны по сравнению с По-Настоящему-Важными, с которыми мы должны иметь дело, как вы могли бы попросить кого-то еще пойти дальше? спросил он. Это было бы подделкой!

Это то, что делает игры Блоу такими замечательными: за большие личные деньги, способами, которые ни один другой разработчик даже не пытался, он изо всех сил пытается донести глубоко достоверное видение смысла человеческого существования. В обеих играх Блоу стремится использовать уникальный язык видеоигр, чтобы передать мудрость, которую он приобрел на своем жизненном пути. В The Witness он надеется помочь игрокам попытаться выйти за пределы своей человеческой точки зрения и увидеть, что представляет собой мир. А в Braid он стремился рассказать что-то более личное.
Однажды ночью в его квартире, когда огни Сан-Франциско мерцали за его окнами на многие мили, я предупредил Блоу, что собираюсь сделать что-то, что может его раздражать: я собирался сказать ему, что я думал о Braid, и он мог делать с этим все, что он хотел.

Хорошо, ответил он с полуулыбкой, откинувшись на спинку стула.
Очевидно, что существует тема создания атомной бомбы, начал я.
Я думаю, что вы можете привести очень веские аргументы в пользу того, что это недвусмысленная ссылка, ответил он, что я интерпретировал как эквивалент Да на языке Блоу.

Но я думаю, что вы разочарованы тем, что люди интерпретируют Braid, как создание атомной бомбы, так как она сама по себе является метафорой для определенного вида знаний, продолжил я. Вы преследовали какую-то глубокую форму понимания всей своей жизни, и я думаю, что вы нашли, что квест после этого знания приносит отчуждение с ним. Чем дальше вы идете по этому пути, тем дальше он уводит вас от других людей. Таким образом, знание в конечном итоге разрушительно для вашей жизни, как и атомная бомба это своего рода истина, которая оказывает катастрофическое воздействие. Вы думали, что погоня за этим знанием сделает вас счастливыми, но, как и Тим, часть вас в конце концов желала бы, чтобы вы могли повернуть время вспять и сделать все заново.

Блоу молчал.

Это имеет смысл? спросил я.
Да-да.
Так?
Ну, я бы сказал, что я не буду разочарован такой интерпретацией он улыбнулся.

Самая большая удача, которую я когда-либо видел, была, когда однажды ночью мы встретились с его другом Марком Тен Бошем в Оклендском филиале легендарной местной сети под названием Чикагская пицца Закари. Тен Бош высокий, серьезный независимый разработчик, чья серьезная сдержанность дала развлекательный контрапункт философской экспансии Блоу. Когда Тен Бош упомянул, что он некоторое время работал в Electronic Arts в команде, которая разработала стратегическую игру в реальном времени Command & Conquer: Red Alert 3, я спросил, нашел ли он проект интересным. Тен Бош задумался об этом на мгновение с торжественной силой человека, свидетельствующего перед подкомитетом Сената.

м, наконец сказал он.
Ооо! вмешался Блоу. Это абсолютный дисс!
Именно когда Тен Бош начал объяснять мне свой текущий игровой проект, Блоу казался больше всего в своей стихии. На самом деле, я должен изменить это, чтобы попытаться объяснить, потому что за те 20 минут, которые десять Бош потратил на описание своей игры, Miegakure, почти все, что он сказал, соскользнуло с моего мозга, как капли дождя с Горе-Текса. Он сказал, что Miegakure это платформер на основе головоломок, который разворачивается в четырех измерениях четырех пространственных измерениях.

Но нет четырех пространственных измерений, запротестовал я.
Ну, возразил Тен Босх, это то, что было бы, если бы они были.

И это было последнее, что он сказал, и я понял это довольно долго, пока он и Блоу жадно болтали о выдавливаемых поверхностях и воображении плоскости в виде труб. В Miegakure два пространственных измерения постоянны, и игрок решает головоломки, переключаясь между двумя другими с нажатием кнопки. Даже когда Блоу и Тен Бош становились все более оживленными, а их объяснения более изобретательными, их слова продолжали отскакивать от моего лба как теннисные мячи. Наконец, Тен Бош вытащил свой iPhone и загрузил Miegakure, включив образец видео игрового процесса, в котором крошечный рыжеволосый персонаж шел по плавучему острову. По подсказке игрока ткань игрового мира внезапно деформировалась и сместилась так, что наземная масса, казалось, воссоздала себя изнутри. Эффект был завораживающим.

Это четвертое измерение, сказал Тен Бош.
Челюсть отвисла, я посмотрел на Блоу, который просто улыбнулся мне.

Для Блоу, такой проект, как Miegakure, воплощает то, что делает видеоигру уникальной и захватывающей художественной средой. Так же, как он работал, чтобы донести до человека что-то невыразимое о состоянии человека в Braid и в The Witness, Тен Бош в своей игре дает игрокам новый взгляд на мир так, как это может сделать только игра. Это ценный вклад в человеческий опыт, верно?, сказал позже Блоу. Мне нравятся игры, которые показали мне то, чего я иначе не увидел бы, и Марк создает опыт, который был бы невозможен, если бы он не сделал это. И это довольно интересно.

Блоу хорошо знает, что достижение этой высокой цели через The Witness может заставить его обанкротиться. Он хотел бы, чтобы игра хорошо продавалась, когда она выйдет, возможно, в конце этого года, но его главной заботой является то, что она соответствует художественным параметрам, которые он для нее установил. Я всегда могу вернуться к тому, чтобы стать независимым разработчиком, пожал он плечами. Даже если у меня будет ноль долларов, я смогу сделать то же, что и в 2005 году, но лучше. Если мне удастся просто сэкономить на год или два на низкобюджетную жизнь, это все, что мне нужно. Несмотря на свое богатство, Блоу все еще думает как аскет.

Которым, в некотором смысле, он и является духовным искателем, стремящимся к истине в еще не изученном мире. Это условия, в которых он видит свое искусство. Люди, подобные нам, которые делают что-то немного отличное от основного направления, каждый выбрали одно направление, в которое мы выходим в пустыню, но мы все еще не очень далеко от лагеря, сказал он мне. Там просто огромное количество территории, чтобы исследовать и пока у вас нет карты этого, никто не может сказать, на что способны игры.

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:



Читать еще




Подробнее..

Прыгни со скалы! взлеты и падения легендарного геймдизайнера Уоррена Спектора

02.06.2021 10:16:01 | Автор: admin
image

Будь у игровой индустрии зал славы, почетное место там занял бы Уоррен Спектор. Человек-легенда, визионер, автор культовых Deus Ex и System Shock, основоположник жанра immersive sim, давший игрокам неслыханную свободу выбора. Кажется, что с таким авторитетом и признанием открываются все двери и любая идея находит поддержку. Но, увы, не всё так просто, и биография Спектора тому подтверждение: много раз он прыгал со скалы, пытаясь сделать игру своей мечты, и почти всегда сталкивался с неразрешимыми проблемами и непониманием инвесторов. Давайте вместе с журналистом Джейсоном Шрайером проследим тернистый творческий путь легенды геймдева.

От настолок к созданию Deus Ex


С самого детства Уоррен был одержим созданием интерактивных историй. Он рано увлекся настольными ролевыми играми, а когда переехал в 22 года в Остин (штат Техас), присоединился к компании приятелей, регулярно играющих в Dungeons & Dragons. Любопытный факт одна из игровых сессий продлилась 10 лет, а гейм-мастером был будущий корифей жанра киберпанк Брюс Стерлинг. В Техасском университете Спектор изучал кинематограф, писал диссертацию и преподавал, чтобы было чем оплачивать счета, пока в один прекрасный день его не уволили. Спустя некоторое время друг пригласил его поработать редактором настолок в компанию Steve Jackson Games. Скромная зарплата Уоррена не смущала: тогда, по его словам, он был геймером-любителем, и такая работа давала возможность создавать собственные игровые системы и кампании.
image

Через три года, в 1986 г., ему позвонили из TSR Inc. висконсинской фирмы, стоявшей за созданием D&D, и предложили должность редактора: событие, сопоставимое приглашению в NBA студента, играющего за баскетбольную команду родного колледжа. Тем не менее, долго он там не задержался: сказывался не только суровый северный климат, но и однообразная работа, которая быстро наскучила Спектору. Вскоре он вернулся в Техас, чтобы присоединиться к недавно созданной Origin Systems, которую основал знаменитый Ричард Гэрриот.
image
Ultima

Благодаря успеху игры Ultima (к 1989 г. вышло уже несколько продолжений) и на волне бума видеоигровой индустрии, студия быстро расширялась. Работа в Origin научила Спектора ремеслу продюсера руководить командами дизайнеров, управлять проектами и делать, казалось бы, невозможные вещи: объединять упрямых талантливых людей единым творческим видением. Вместе с Гэрриотом Спектор работал над Ultima VI, помогая создавать детально проработанную историю об орде горгулий (где они применили новаторский для того времени прием, наделив антагонистов сложными мотивами действий), а вместе с Крисом Робертсом над известным космическим симулятором Wing Commander. Бизнес-модель у меня была следующая, вспоминает Спектор. Я запускал четыре проекта (два внешних и два внутренних) и каждый год два наименее успешных закрывал, призывая всех сотрудников работать так, чтобы именно их проект оказался в числе лучших.

image
System Shock

В эти же годы началась дружба Спектора и Пола Нейрата, главы кембриджской студии Looking Glass, сотрудничавшей с Origin. Вместе с Looking Glass были выпущены Ultima Underworld и System Shock игры разные по сеттингу, но близкие по геймдизайну, построенному на принципах Dungeons & Dragons. Обе они помогли сформироваться тому жанру, что сегодня часто называют immersive sim (букв. симулятор погружения). Речь об играх, которые дают игроку инструменты для решения игровых задач различными способами, множеством вариантом, в отличие от тех же стандартных экшн-шутеров, которые в процессе прохождения будет требовать только одного уничтожить противника. Дать игроку ощущение неограниченных возможностей и свободы выбора для индустрии начала 1990-ых это был фундаментальный сдвиг парадигмы.

image
Пол Нейрат

Увы, несмотря на новаторский геймдизайн, у Origin возникли проблемы с финансированием, и в 1992 г. Гэрриот продал компанию крупному издателю Electronic Arts (EA). Поначалу всё шло отлично: менеджеры EA дали Спектору большой бюджет и свободу в творчестве, однако ожидаемой отдачи не было. Затраты у команды Уоррена были большими, счет проектов в работе шел на десятки, но успешных, по меркам EA, среди них так и не оказалось. Начался прессинг: руководство издателя зачастило в Остин, а в адрес Спектора посыпались упреки в неэффективном управлении. EA заявляли, что их главный приоритет увеличение прибыли акционеров, а с теми продуктами и жанрами, которые культивирует Уоррен, добиться серьезного роста невозможно. В пример ставили коллегу Криса Робертса, чей Wing Commander стал чрезвычайно успешен как коммерческий продукт, в то время как проекты Спектора, хоть и высоко оценивались критиками и сообществом, приносили очень маленькую прибыль.

image
Джон Ромеро

На фоне всего этого оставалось только уволиться из Origin. После разговора с Нейратом, в 1996 г. Спектор открыл в Остине офис студии Looking Glass и начал работу над новым проектом научно-фантастической многопользовательской игрой Junction Point. Но и тут не ждал успех: не получив инвестиций, студия закрылась через несколько месяцев, а игра в итоге осталась на стадии проекта. В поисках финансирования, Спектор чуть было не подписал контракт на разработку РПГ по серии Command & Conquer (C&C), но тут в дело вмешался легендарный Джон Ромеро. Разругавшись с коллегами из id Software, автор Doom создал собственную студию под названием Ion Storm и вот теперь предлагал Уоррену вместо сделки по C&C поработать на него. Да еще и на шикарных условиях: Неограниченный бюджет на разработку и больший маркетинговый бюджет, чем когда-либо. Мне предложили сделать игру моей мечты, без какого-либо вмешательства. Какой дурак от такого откажется?, вспоминает Спектор.

image
Результатом стала Deus Ex уникальная смесь жанров и воплощение идеи immersive sim, в котором все препятствия игрок мог преодолевать совершенно разными способами. Как позже писал Спектор, цель была в том, чтобы сделать игру о самовыражении игрока, а не о том, насколько умны мы сами дизайнеры, программисты и рассказчики. Игра вышла в июне 2000 года и стала не только феноменом, новой страницей в истории индустрии, но и коммерческим успехом (было продано более миллиона копий).

Однако вскоре Спектору снова повезло: из независимой компании Ion Storm превратился в подразделение крупного издателя Eidos. Несмотря на успех Deus Ex, на активную работу над продолжением (Deus Ex: Invisible War) и над новой игрой из серии Thief, менеджеры и маркетологи издателя третировали Спектора и его подход к геймдизайну. В частности, запретили разрабатывать игру про Дикий Запад, аргументируя отказ тем, что эта тема никогда не принесет больших денег (что позже успешно опровергли Rockstar с серией Red Dead Redemption). Дошло до того, что боссы попросили его не употреблять слово история в дискуссиях о видеоиграх.

Индустрия игр построена на конфликте между двумя фракциями творческими людьми, пытающимися создать создать произведение искусства, и коммерсантами, которым нужно получить прибыль. И этот конфликт основная причина большинства проблем индустрии видеоигр.


Спектор работал, не задумываясь о требованиях прибыльности и оптимизации затрат: Я никогда в жизни, ни в одном своем проекте не составлял бюджет и расписание. И всегда спрашиваю в этом случае: можете ли вы назвать хоть одну по-настоящему замечательную игру, которая была выпущена в срок и в рамках бюджета? В глазах издателя эта позиция выглядела безответственно, и неудивительно, что в 2004 г. Спектор покинул Ion Storm (а в 2005 г. студия была закрыта).

Что же дальше? Куда податься почти 50-летнему геймдизайнеру в индустрии, где, кажется, правят бал двадцатилетние? На каждый проект уходит по 2-3 года, большая часть в итоге не доходит до релиза, сколько проектов он сумеет завершить?

Прыгни со скалы! Прыгни со скалы!


Возможно, именно эти слова супруги Спектора Кэролайн заставили его набраться храбрости и открыть собственную студию, названную Junction Point (в честь отмененной игры). К поиску заказчиков и инвесторов Уоррен привлек своего приятеля Шеймуса Блэкли, интеллектуала с хорошими связями в индустрии. На тот момент Блэкли как раз работал в качестве агента, помогающего привлекать финансирование и успевшего поработать с Тимом Шафером (Psychonauts, Grim Fandango) и Лорном Лэннингом (Oddworld). Первой стала сделка на разработку фэнтэзийной RPG под названием Sleeping Giants для компании Majesco, однако та отменила игру год спустя. Вторым проектом стал новый эпизод Half-Life 2, и его тоже через несколько месяцев отменили.

Трудно поверить, но команда опытнейших разработчиков во главе с легендой индустрии не могла найти финансирование на новый проект. Если бы эта ситуация возникла спустя несколько лет, то они вполне могли бы воспользоваться альтернативными способами, доступными инди-разработчикам: Kickstarter, самостоятельная дистрибуция, небольшие издатели. Но в середине 2000-ых таких возможностей еще не существовало. Единственным вариантом для Спектора были крупные издатели типа EA и Activision, но, похоже, никому из них творчество Спектора не было интересно

Это было похоже на конец карьеры. Прыгнув со скалы, можно легко разбиться о камни.

image

Спасение пришло оттуда, откуда никто не ожидал, из Disney. Перед игровым подразделением корпорации стояло две большие задачи: запустить собственное игровое подразделение (до этого лицензии на создание игр с персонажами отдавали другим компаниям) и разработать игру с Микки Маусом, который, хоть и был легендой анимации, но в играх серьезной популярности не имел. Игровое подразделение возглавил Грэм Хоппер, который нанял стажеров и поручил им делать игру о противостоянии Микки Мауса и кролика Освальда персонажа, которого Уолт Дисней создал на заре своей карьеры (глава студии Боб Айгер специально для этого случая выкупил права на Освальда у Universal). Прототип игры получился довольно впечатляющим, однако студийные боссы хотели, чтобы таким знаковым проектом занималась известная и крутая студия. Так состоялась встреча с Уорреном Спектором.

С одной стороны, для Спектора это было большой радостью: кто откажется работать над игрой о знаменитом на весь мир персонаже, да еще и за хорошую оплату (с учетом того, как тяжело было найти финансирование). Но с другой, было условие, которое шло вразрез со всем личным опытом: Disney настаивал на поглощении студии Junction Point. То, что раньше произошло с Origin и Ion Storm, ставших частью больших корпораций, теперь должно было случиться и с его собственной студией, и Спектор догадывался, чем это могло закончиться. Но другого выхода попросту не было за исключением Disney, денег никто не предлагал. Поэтому, после долгих обсуждений, размышлений и торгов, Спектор согласился на сделку.

На разработку игры ушло три года. Epic Mickey стал эксклюзивом для платформы Nintendo Wii, сочетавшим необычный способ управления (посредством контроллера Wiimote) с элементами immersive sim: каждый выбор игрока имел последствия, влияя на сюжет и диалоги. Не любивший укладываться в сроки и бюджет, Спектор часто конфликтовал с руководством Disney, несколько раз его чуть было не увольняли. Однако ему удалось продавить своё видение и график, и в конце 2010 года игра наконец вышла.

Продажи Epic Mickey оказались хорошими (1,3 млн копий за первый месяц), критикам и аудитории игра пришлась по душе. Проект почти окупился, что для консольного эксклюзива уже считалось успехом. Казалось, что победа одержана, всё замечательно и стоит ждать сиквела, но

Disney наносит ответный удар


image
Джон Плезантс

К концу нулевых игровая стратегия Disney кардинально изменилась. Виной тому была не только рецессия на глобальном рынке, но и стремительный рост популярности мобильных игр и игр на социальных площадках типа Facebook. Многие аналитики и вовсе всерьез считали, что игровые консоли скоро вымрут. За несколько месяцев до релиза Epic Mickey мышиный дом заключил сделку на 763 миллиона долларов с компанией Playdom, выпускавшей социальные игры. Руководителем Хоппера стал бывший босс Playdom Джон Плезантс, веривший в онлайн и, кажется, презиравший консольные игры, неудивительно, что Хоппер скоро уволился, тем самым оставив Спектора без защиты. С точки зрения Плезантса, корпеть годами над одной игрой, тем более сжигая деньги на сиквел для умирающих консолей, было крайне бессмысленно куда рациональнее было вкладываться в быстрые проекты, которые смогли бы приносить прибыль уже через год.

А Уоррен Спектор так не мог: для него три года были эталонным сроком создания игры. Вот и теперь, как когда-то в Origin, он разделил студию на команды, каждая из которых работала над своим проектом, и к концу 2010 года, уже через несколько месяцев, был готов прототип сиквела Epic Mickey, на который Спектор планировал потратить еще два-три года спокойной работы параллельно с разработкой новых игр.
Но сразу после рождественских каникул пришла директива: во-первых, никаких новых проектов. Во-вторых, Disney подсчитал, что окупиться продолжение Epic Mickey сможет, только если выйдет к осени 2012 года, и поэтому потребовал усилить штат студии и форсировать производство. Результатом стало не только то, что штат студии вырос до 200 человек (и это в то время, когда Disney закрывала целые студии!), но и снижение качества продукта: времени на поиск решений не хватало, а из-за притока новых людей возникали конфликты и недопонимания. Под давлением Disney разработчикам приходилось лезть в те области, в которых они были новичками, но корпорация настаивала на включение в игру популярных трендовых элементов, вплоть до вариантов с переходом на freemium-модель или превращения в MMORPG. Спектору это не улыбалось. Он всё меньше и меньше участвовал в разработке, предпочитая заниматься новыми прототипами и идеями.

image
В начале 2012 г. конфликт перешел в острую стадию. Во время обсуждения перспектив студии Плезантс и Спектор доспорились до того, что последний швырнул в оппонента указкой и ушел, хлопнув дверью. Ответной мерой стала директива по сокращению расходов часть сотрудников требовалось уволить, остальных загрузить сверхурочной работой. Спектор старался сохранить штат и оставить хотя бы 75 сотрудников (из 200), но ни один из его многочисленных планов спасения не поддержали. Всего лишь за пару лет Junction Point превратилась из флагманской студии Disney в бесправную жертву гонки за новыми трендами.

Epic Mickey 2 вышла 18 ноября и это оказалось провалом. Критики осуждали игру за скучный и однообразный игровой процесс и за непроработанность персонажей. Но главная беда продажи были удручающе низкими: по количеству проданных копий сиквел существенно уступал первой части, и это при том, что он уже не являлся эксклюзивом Wii, а был доступен на популярных платформах XBox и PlayStation. Это стало окончательным приговором для студии. И хотя Спектор никак не мог с этим смириться (он даже организовал мозговой штурм на тему создания мобильной игры), всё было кончено. 29 января 2013 г., через два месяца после предрелизных кранчей, Спектор собрал сотрудников в комнате отдыха и объявил, что студия закрывается. Сам он очень тяжело переживал произошедшее, винил в крахе студии себя, свое поведение на встречах, неучастие в разработке игры.

Я съехал с катушек. Несколько месяцев я только и делал, что валялся на диване с пультом и просто щелкал пультом. Я был подавлен и просто ничего не мог делать. Disney был моим лучшим этапом в моей профессиональной деятельности и одновременно худшим.


Долгий эпилог, который, хочется верить, станет новой главой


Уйти на пенсию 57-летнему Спектору помешал звонок из родного Техасского университета его пригласили читать курс по дизайну и разработке видеоигр, чем он с энтузиазмом занимался три года, пока не понял, что его больше привлекает не преподавание, а само создание игр. Да и грант, выделенный на курс, заканчивался, а финансировать продолжение желающих не нашлось. Игра Underworld Ascendant, в которой Спектор выступил как консультант и которую называли новым словом в разитии жанра immersive sim, провалилась: аудитория не оценила монотонный геймплей и забагованность (что, в свою очередь, возможно, стали результатом нехватки финансирования средств, привлеченных черех краудфандинг, оказалось недостаточно). В конце 2015 г. Джон Нейрат пригласил его поучаствовать в создании System Shock 3, продолжение культовой игры, к разработке которой Спектор имел непосредственное отношение. Но, увы, и тут возникли финансовые проблемы: шведский издатель Starbreeze, с которым был заключен контракт на финансирование, обанкротился, и Спектору пришлось, как в старые добрые времена, самому примерять роль коммерсанта и летать на встречи с инвесторами. В мае 2020 года спаситель наконец-то был найден: права на издание игры приобрел китайский холдинг Tencent. Новость оптимистичная, учитывая мощь и возможности корпорации, однако не то ли самое можно было когда-то сказать и о Disney?

image
Концепт-арт System Shock 3

***

В индустрии игр немного людей, которые отдали ей свыше тридцати лет своей жизни, как это сделал Спектор, и именно его биография показывает, почему их так немного. Все четыре студии, с которыми связана его карьера (Origin, Looking Glass, Ion Storm, Junction Point), закрылись или при нем, или через несколько лет после его ухода. Спектор делал игры, которые стали культовыми и были высоко оценены критиками, но так и не добился значительного коммерческого успеха. Его путь, при всей уникальности, это символ той нестабильности, с которой постоянно приходится сталкиваться разработчикам видеоигр (при том, что ему еще повезло: не было необходимости переезжать из города в город к новому работодателю, как это часто происходит в геймдеве).
Своими играми Спектор вдохновил тысячи разработчиков и оказал огромное влияние на всю индустрию, однако его собственным проектам и студиям это не помогло выжить. По крайней мере, пока



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Три способа стать геймдизайнером, иконы игр и тренды GameDev. Интервью конференции DUMP

05.05.2021 22:05:36 | Автор: admin

Когда играешь в особенно крутую игру, останавливаться не хочется, пока не пройдешь всё до конца. А ещё хочется создать свою игру! Знакомая история? Для участников DUMP тоже:) В этом году впервые на конференции будет представлена секция GameDev.

Мы решили узнать больше о разработке игр и пообщались с представителями индустрии из компании Targem Games Евгением Бушуевым (Game Designer Crossout) и Алексеем Честных (Creative Director).

Расскажите, как вы попали в игровую индустрию?

Женя: Я заканчивал УПИ, Менеджмент в энергетике и на промпредприятиях. 15 лет назад высшее образование было некой защитой от армии. Дальше я мог пойти по специальности, но этот вариант казался тоскливым. И как-то раз я увидел на ag.ru новость о том что в Екатеринбурге есть студия Targem. Хотел устроиться здесь менеджером, но после интервью меня взяли геймдизайнером. Это было супер предложение! Диплом менеджера я получил уже позже, через год. Но на момент собеседования переживал, что заветной корочки не было.

Алексей: Начну издалека. Я с детства был повернут на видеоиграх. Просто был маньяком, зависал при виде любой анимированной гифки. Кажется, пугал этим родителей. Помню, ездили в Москву, и там в Парке Горького был вагончик с игровыми автоматами, 16-битными. Тогда я попал в рай. Изучал, как что работает. Пиксельное безумие! У меня был компьютер Spectrum. Я пытался делать на нем пиксель арты.

Всегда, когда была возможность во что-то поиграть, я ее использовал.

Как я сюда попал? Ну, наверное, не то чтобы случайность. Я получил высшее образование, филологическое, и собственно, до этого никогда не работал, жил в своем мире эльфов. Через полтора года после выпуска нашел объявление о том, что Targem Games набирали сотрудников.

Знакомая многим игра X-COMЗнакомая многим игра X-COM

Какая игра, на ваш взгляд, является иконой геймдизайна?

Женя:

Они сменяются, их же много на самом деле. Какой-то одной совсем нет. Я X-COM любил классический очень часто к нему возвращался. Очень важная для меня игра.

Когда я поработал в геймдеве несколько лет, я начал думать, как сделать любимые игры еще лучше. В X-COM был тип прокачки, где нужно таскать тяжелые пушки, чтобы качать силу, бегать по карте ради скорости. В результате, чтобы играть эффективно, нужно было играть странно. Или например в Тарелку не зайдешь, чтобы заряд плазмы не получить. Пули можно на базе забыть, а во второй части вовсе с подводным оружием на надводную миссию улететь.

Еще хочется выбрать альтернативную икону. Есть Герои, но я больше предпочитал Disciples. Она проще, цифры там меньше и мне нравилось, что там больше контроля над происходящим. При этом она и выглядит классно.

А так выглядит DisciplesА так выглядит Disciples

Алексей:

Я соглашусь с Женей. Это, конечно же, X-COM, причем второй. Я до сих пор помню звуки стрельбы пушек и гибели инсектоидов. Цикличность мне очень нравилась и это вылилось в то, что я до сих пор люблю игры с петлями в геймплее. По началу из икон были X-COM, Герои Меча и Магии вторые и третьи.

Еще в детстве я открыл для себя эмуляторы, а в особенности, игру Chrono Trigger. Она перевернула мой мир. Я помню, что сидел и играл в неё двое суток без остановки!

Вот две игры, которые являются для меня иконами Chrono Trigger и (внезапно) Front Mission 3. Это лучшая игра про роботов, в принципе. Очень дорогая, с прекрасными роликами и сюжетом.

Но иконы меняются. Поэтому недавно я был поражен игрой Undertale. Финальный босс меня очень порадовал. Игра вся пиксельная, трехцветная, а босс сделан в Фотошопе из различных фотографий. Но это лишь половина прикола. Вторая часть заключается в том, что босс выкидывает тебя из игры, если ты умираешь. Это меня поразило и порадовало. В NieR: Automata тоже очень любопытные механики, которые ломают четвертую стену. В принципе, из последнего, именно эти две игры выбивают из привычного гейминга.

А какая топовая игрушка была топовой для Spectrum?

Алексей:

Конечно же, Элита. Тогда производили впечатление такие игры как Саботаж. Там, где был крупный персонаж, во весь рост это производило впечатление. Еще там был первый Wolfenstein вид сверху. The Verse тоже была классная та в которой робота строишь.

Персонаж из игры СаботажПерсонаж из игры Саботаж

Какую роль геймдизайн играет в разработке игр? В чем ежедневный труд и какие бывают типы?

Женя:

Проще всего сравнить с режиссером. По крайней мере, главного дизайнера на проекте. Геймдизайнер такой волшебный человек. С одной стороны, он полностью представляет себе игру: зачем и кто в это будет играть, все правила. От него идет задание программистами, художникам. Их результат дизайнер пытается слепить воедино в то, что он изначально себе представлял. На самом высоком уровне делает концепт, а на самом низком работает руками.

Алексей:

Классифицировать дизайнеров можно по-разному. Выделяют нарративных дизайнеров, которые отвечают за текст и повествование. Левел дизайнеры делают уровни для игры. Дизайнеры игровой логики решают, где нужно стрелять и так далее.

Чем больше проект, чем больше компания, больше специализаций. У нас, например, есть дизайнер по сборке машин. Есть дизайнер по балансу человек, который занимается балансом текущих деталей и вводом новых.

А откуда появляются геймдизайнеры?

Женя:

Как по мне, идеальный путь это геймджемы. Соревнования, где людям дают тему и срок, чтобы сделать игру. По сути, это вариация хакатона. Лучший способ попасть в геймдизайнеры сделать игру. Благодаря дедлайну, такой формат позволяет не оттягивать выпуск игры мечты навечно, а создать достойный MVP за короткий срок. Также ты сможешь попробовать каждый аспект создания игры, что потом облегчит коммуникацию с коллегами по команде.

Второй путь это много играть. Просто разбирать игры и понимать как они сделаны, почему они так сделаны. Третий пользоваться чужими разборами на YouTube. Это кажется идеальным форматом в наше время.

Алексей:

Геймдизайнер товар штучный и редкий. Как бы ни художник, ни программист. Нужен толковый человек, который играет в игры. В последние годы ситуация улучшилась благодаря тому, что появились курсы и бесплатные движки. Сейчас самое удобное время для разработки Unity и Unreal копеечные. Самые удобные инструменты.

Поэтому сейчас у нас более строгие требования, и кандидаты приходят подготовленными. Сейчас мы ждём, что кандидат сделал хотя бы один свой прототип. Может, даже сделал какую-то игру и продал ее на AppStore. Мы ожидаем людей с опытом либо прототипов, либо джемов, либо пройденных курсов. Плюс, какие-то элементарные теоретические знания. Например: понять что такое кривая сложности, игровой баланс, метаигра. Немножко терминов, но главное опыт. Мы стараемся брать молодых людей, плотно с ними работать, проводить для них ивенты и лекции.

Возраст у геймдизайнера имеет значение?

Алексей:

Мне кажется, что всё равно какая-то пассионарность больше есть у молодежи. Вот последние успешные дизайнеры, которых мы наняли, они студенты последних курсов, у них горят глаза. Потому что знания знаниями, но важен драйв. Главное свойство геймдизайнера это не только обладать видением, но уметь его доносить до других. Заражать других не мечом, а словом. Поэтому, лично я, по поводу найма отдаю предпочтение джунам. Потом мы воспитываем их в компании на более высокие грейды и зарплаты.

Как последний год изменил индустрию?

Алексей:

Индустрия только выросла, предыдущий год был очень прибыльным. Люди стали больше играть. На подъеме мобильный гейминг. Про тренды геймдизайна: сейчас время ремейков. Это происходило в обычной масс-культуре, но в играх тоже произошло, хоть и с опозданием.

В Targem изменилось то, что мы ушли на удаленку, как и многие. В офисе могли находится только новички, которые проходили свой первый срок, и их наставники. У нас были большие перемены в организации труда. Это пошло нам на пользу.

Какие практики помогают сохранить эффективность?

Алексей:

Мы стали больше фиксировать информацию и чаще созваниваться. Отмечаем затраченное на задачи время в трекере. Я не в большом восторге, признаюсь честно. Жду, когда мы снова будем работать как прежде.

Некоторые игры достаточно долго делают. Как угадать с тем, что будет релевантно и актуально через несколько лет?

Алексей:

Я боюсь, что правильный ответ ты можешь не угадать. Нет инструментов, чтобы заглянуть в будущее. Нужно принимать риски и делать соответствующие решения. Индустрия игр это heat-driven индустрия, как кино. Выходит 1 000 игр из которых, одна игра получает всё, 9 в топе получают половину, а остальные ничего. К сожалению, так это работает. Есть пул игр, из которых что-то может выстрелить. Нет никаких гарантий.

Мы, Targem, старались следовать за трендами, но ничего не получалось. Тренды нужно создавать. Мы начали создавать казуалки, когда они были на подъеме, а закончили, когда уже весь интерес к ним утих. Надо рисковать, делать что-то смелое. И делать то, к чему душа лежит. Ради денег ничего не выйдет.

Женя:

Ты должен ощущать вакуум, пустое место, которое собираешься занять. Например, в этом месте должна стоять игра, ее не хватает. Плюс, свои сильные стороны использовать. Трендам следовать ты всегда опоздаешь, высокая конкуренция.

Где баланс между чистым творчеством и коммерческим проектом, зарабатыванием денег?

Алексей:

Мы стараемся в наши текущие проекты вкладывать душу. Коммерческий проект - это не синоним плохого проекта. Мы стараемся создавать ценности. При этом Targem - это бизнес, а цель бизнеса - заработать. Поэтому мы больше про коммерческую разработку. Если мы говорим о чистом искусстве, то выступаем в роли ремесленников.

Есть в Targem практика свободных дней? В которые кто-то пилит свои проекты или занимается творчеством?

Алексей:

У нас пару лет проводится неделя свободного творчества. Где люди могут свои старые таски пособирать, что-то еще поделать. И в рамках таких недель некоторые фичи могли быть добавлены в игру. Это не очень системно. Мы пока в другой психологии все напряженные, нужно выполнять план, делать новые фичи. Наверное, мы потихонечку будем внедрять эту тему. Хочется больше делать для того, чтобы атмосфера была творческая.

Кто из гейм-дизайнеров ваш топ?

Женя:

Я скорее назову студии, а не людей. Потому что я точно не знаю, кто у них занимается дизайном. Мне очень нравится студия Klei, они выпускают разные игры. Они продуманные, красивые, расширяют пространство этого жанра. Как пример, назову Invisible, Inc.. Я больше всего с ней времени провел. Последнее у них Griftlands, Ninja Mark, Dont Starve, Dont Starve Together.

Кодзиму я не то чтобы люблю, но отношусь к нему с большим уважением.

Самое большое впечатление за последнее время произвел Disco Elysium, это студия ZA/UM. Они при этом из нашей культуры. На одном из награждений благодарили Маяковского и Цоя. Это очень круто.

Алексей:

Мой любимый дизайнер Тим Шейфер. Мне нравится то, что он сам делает визуальный арт и дизайн игр. Мне нравятся инди-игры. Например, создатель Undertale. Создатели Hades Supergiant Games. Они тоже иногда раздвигают жанры.

Создатели FTL Subset Games; они создали целое поколение последователей.

Griftlands от студии KleiGriftlands от студии Klei

Какой был самый громкий фейл?

Женя:

Я самоед, поэтому всё, что выпускалось, было для меня не совсем так и не совсем то. Наверное, это синдром самозванца. Я всеми проектами над которыми работал несколько недоволен, но так чтобы совсем фейл такого не назову.

Алексей:

Я соглашусь с Женей, мы с ним в этом плане похожи. Всегда есть общее недовольство, всегда можно было сделать лучше. Но для меня проект Sledgehammer фейл. Я был там и сценарист, и дизайнер, и менеджер. Мы долго пытались его согласовать, я писал десятки концептов, но ничего не подходило. А когда думал, что уйду, предложил концепт игры и его приняли. Я был недоволен и роликами, и сюжетом. А потом я в него как-то поиграл много лет спустя и удивился там столько геймплея, оружия, она такая большая. И, в принципе, не так всё плохо. Поэтому в моменте есть недовольство тем, что делаешь.

Чем больше всего гордишься?

Алексей:

Ex Machina. Я считаю её своим полностью проектом. У меня есть ощущение, что она получилась именно такой, в основном, из-за сценария. И, наверное, Crossout. Это черный лебедь. Никто не знает, почему оно работает. Что-то получилось, непонятно благодаря и вопреки. Но этот проект прямо хороший.

Ex Maсhina от Targem GamesEx Maсhina от Targem Games

Еще у нас была ключевая игра, с которой мы вышли на консоли Armageddon Riders. Это был Sledgehammer, который сам по себе противоречивая игра. На его движке за полгода мы сделали Riders. На PC игра прошла мимо, а вот на консолях вышла хорошо и мы смогли заработать.

Star Conflict первый наш онлайновый проект, смелый эксперимент. Было интересно, получится ли что-нибудь? Но он до сих пор живет, несмотря на то, что похожие игры с драйвом приходили и уходили. Мы любим все наши проекты во все вложена душа.

Спасибо ребятам за такую подробную беседу! Надеемся, тебе было интересно. А сейчас немного деталей конференции и секции GameDev:

14 мая в секции GameDev выступят 7 спикеров. Их можно услышать офлайн и онлайн, задать вопросы. Подробнее о программе https://dump-ekb.ru/gamedev

А в бесплатном стриме с конференции в рамках секции выступит Марина Бондаренко. Ее доклад Гиперказуальные игры. Обзор сделок и рынка смотри по ссылке в нашем телеграм-канале https://t.me/DUMPOnline. Ссылку на трансляцию опубликуем там 14 мая.

Подробнее..

Как я написал браузерный 3D FPS шутер на Three.js, Vue и Blender

07.05.2021 02:13:27 | Автор: admin
Стартовый экран игрыСтартовый экран игры

Мотивация

На пути каждого коммерческого разработчика (не только кодеров, но, знаю, у дизайнеров, например, также) рано или поздно встречаются топкие-болотистые участки, унылые мрачные места, блуждая по которым можно вообще забрести в мертвую пустыню профессионального выгорания и/или даже к психотерапевту на прием за таблетками. Работодатели-бизнес очевидно задействует ваши наиболее развитые скилы, выжимая по максимуму, стек большинства вакансий оккупирован одними и теми же энтерпрайз-инструментами, кажется, не для всех случаев самыми удачными, удобными и интересными, и вы понимаете что вам придется именно усугублять разгребать тонну такого легаси Часто отношения в команде складываются для вас не лучшим образом, и вы не получаете настоящего понимания и отдачи, драйва от коллег Умение тащить себя по-мюнхаузеновски за волосы, снова влюбляться в технологии, увлекаться чем-то новым [вообще и/или для себя, может быть смежной областью], имхо, не просто является важным качеством профессионала, но, на самом деле, помогает разработчику выжить в капитализме, оставаясь не только внешне востребованным, конкурентоспособным с наступающей на пятки молодежи, но, прежде всего, давая энергию и движение изнутри. Иногда приходится слышать что-нибудь вроде: а вот мой бывший говорил, что если бы можно было не кодить, он бы не кодил!. Да и нынешняя молодежь осознала что в сегодняшней ситуации честно и нормально зарабатывать можно только в айти, и уже стоят толпою на пороге HR-отдела... Не знаю, мне нравилось кодить с детства, а кодить хочется что-нибудь если не полезное, то хотя бы интересное. Короче, я далеко не геймер, но в моей жизни было несколько коротких периодов когда я позорно загамывал. Да само увлечение компьютерами в детстве началось, конечно же, с игр. Я помню как в девяностые в город завезли Спектрумы. Есть тогда было часто практически нечего, но отец все-таки взял последние деньги из заначки, пошел, отстоял невиданно огромную очередь и приобрел нам с братом нашу первую чудо-машину. Мы подключали его через шнур с разъемами СГ-5 к черно-белому телевизору Рекорд, картинка тряслась и моргала, игры нужно было терпеливо загружать в оперативную память со старенького кассетного магнитофона [до сих пор слышу ядовитые звуки загрузки], часто переживая неудачи... Несмотря на то что ранние программисты и дизайнеры умудрялись помещать с помощью своего кода в 48 килобайт оперативной памяти целые миры с потрясающим геймплеем, мне быстро надоело играть и я увлекся программированием на Бейсике)), рисовал спрайтовую графику (и векторная трехмерная тогда тоже уже была, мы даже купили сложную книжку), писал простую музыку в редакторе... Так вот, некоторое время назад мне опять все надоело, была пандемийная зима и на велике не покататься, рок-группа не репетировала Я почитал форумы и установил себе несколько более-менее свежих популярных игр, сделанных на Unity или Unreal Engine, очевидно. Мне нравятся РПГ-открытые миры-выживалки, вот это все... После работы я стал каждый вечер погружаться в виртуальные миры и рубиться-качаться, но хватило меня ненадолго. Игры все похожи по механикам, однообразный геймплей размазан по небольшому сюжету на кучу похожих заданий с бесконечными боями Но, самое смешное, это реально безбожно лагает в важных механиках. Лагают коммерческие продукты которые продают за деньги А любой баг, имхо, это сильное разочарование он мгновенно выносит из виртуальной среды, цифровой сказки в реальный мир Конечно, отличная графика, очень круто нарисовано. Но, утрируя, я понял что все эти поделки на энтерпрайзных движках, по сути даже не кодят. Их собирают менеджеры и дизайнеры, просто играясь с цветом кубиков, но сами кубики, при этом практически не меняются... Вообщем, когда стало совсем скучно, я подумал что а я ведь тоже так могу, да прямо в браузере на богомерзком непредназначенным для экономии памяти серьезного программирования джаваскрипте. Решил наконец полностью соответствовать тому что все время с умным видом повторяю сыну: уметь делать игры, намного интереснее чем в них играть. Одним словом, я задался целью написать свой кастомный браузерный FPS-шутер на открытых технологиях.

Итак, на данный момент, первый результат по этой долгоиграющей таски на самого себя можно тестить: http://robot-game.ru/

Стек и архитектура

Вполне может быть, что я не вкурсе чего-то (ммм на ум приходит что-нибудь вроде quakejs и WebAssembly), но, с основной технологией было, походу, особо без вариантов. Библиотека Three.js давно привлекала мое внимание. Кроме того, в реальной коммерческой практике, несколько раз, но уже приходилось сталкиваться с заказами на разработку с ее использованием. На ней я сделал собственно саму игру.

Очевидно, что нужно что-то вокруг для простого интерфейса пользователя: шкал, текстовых сообщений, инструкций, контролов настроек, вот этого всего. Я решил поленился, не усложнять себе жизнь и использовать любимый фреймворк Vue 2, хотя, надо было, конечно, писать на свежем, похожем по дизайну и еще более прогрессивном по сути молниеносном Svelte. Но так как хорошенько разобраться предстояло, прежде всего, с Three, думаю, это было правильное решение. Хорошо знакомый и предсказуемый, лаконичный, изящный, удобный и эффективный Vue, позволил практически не тратить время на внешний пользовательский интерфейс.

Когда-то давно я работал дизайнером на винде и достаточно бойко рисовал 2D в Иллюстраторе, но навыков 3D у меня никаких не было. А вот в процессе создания шутера пришлось пойти, скачать и установить одним кликом на свой нынешний Linux Blender. Я быстро научился рисовать с помощью примитивов мир, отдельные объекты, и даже научился делать UV-развертки на них. Но! В целях простоты, скорости работы и оптимизации объема ассетов в моей нынешней реализации не используются текстурные развертки. Я просто подгружаю чистые легковесные бинарные glTF: .glb-файлы и натягиваю на них всего несколько вариантов нескольких текстур уже в джаваскрипте. Это приводит к тому что текстуры на объектах искажаются в разных плоскостях, но на основном бетоне для стен, смотрится даже прикольно, такой разный, рваный ритм. Кроме того, сейчас персонажи не анимируются пока не было времени изучить скелетную анимацию. Одной из основных целей написания этой статьи является желание найти (по знакомым не получилось) специалиста который поможет довести проект до красоты (очень хочется) и согласится добавить совсем немного анимаций на мои .glb (об условиях договоримся). Тогда враги, будут погружаться в виде glTF со встраиванием: .gltf-файлов со встроенными текстурами и анимациями. Сейчас уже есть два вида врагов: ползающие-прыгающие наземные дроны-пауки и их летающая версия. Первых нужно научить шевелить лапками при движении и подбирать их в прыжке, а вторым добавить вращение лопастей.

Модель дрона-паука в BlenderМодель дрона-паука в Blender

Для того чтобы игру нельзя было тупо-легко прочитить через браузерное хранилище я добавил простенький бэкенд на Express с облачной MongoDB. Он хранит в базе данные о прогрессе пользователя по токену, который на фронте записывается в хранилище. Хотелось сделать не просто FPS-шутер, а привнести в геймплей элементы РПГ. Например, в нынешней реализации мир делиться на пять больших уровней-локаций между которыми можно перемещаться через перезагрузку. При желании локации можно быстро дорисовывать из уже имеющихся и добавлять в игру, указывая только двери входа и выхода, стартовую и конечную координату, хорошее направление камеры для них (при переходе живого персонажа через дверь текущее направление сохраняется-переносится). На каждом уровне есть только одна формальная цель найти и подобрать пропуск к двери на следующий уровень. Пропуски не теряются при проигрыше на локации (только при выборе перехода на стартовый уровень после выигрыша на последнем пятом). А вот враги и полезные предметы цветы и бутылки при переходе между локациями, проигрыше или перезагрузке страницы пока выставляются заново согласно основной glb-модели одновременно и схеме, и визуальной клетке локации об этом дальше. И тут вот первое важное про архитектуру: мой фронтенд это совсем примитивное SPA. Vue, например, ни для чего не нужен роутер. Вероятно, я получу негативную реакцию некоторых продвинутых читателей, после того, как сообщу что потратил кучу времени для того чтобы попробовать организовать перезагрузку-очистку сцены внутри системы и пока с самым провальным результатом. Вот к такой спорной мысли я пришел в процессе своих экспериментов: самый эффективный, простой, даже, в этой ситуации, правильный и при этом, конечно же, топорный подход, это нативный форс-релоад после того как мы сохраняем или обнуляем данные пользователя на бэкенде:

window.location.reload(true);

А потом просто дадада считываем их обратно )) и строим всю сцену заново, с чистого листа, так сказать. Тут, конечно, можно было бы улучшить прокидывать пользователя через хранилище вместо того чтобы ожидать разрешения запроса, но это не критично, в данном случае. Небольшое количество оптимизированных текстур (меньше полтора мегабайта сейчас), сильно компрессированного аудио (MP3, понятно: 44100Гц 16 бит, но с сильным сжатием 128 кбит/с меньше полтора мегабайта все вместе сейчас), основная модель-локация весящая около 100Кб и модели отдельных объектов каждая еще меньше... Я добился того что переход между локациями полная перезагрузка мира занимает вполне приемлемое время, судя по записи перфомансов примерно две с чем-то, три секунды. И это, кажется, меньше чем во всех шовных открытых мирах от энтерпрайза которые я видел. Продвинуто бесшовный я тоже один нашел и поиграл, но он лагал хуже всех, и когда сюжет наконец двинулся с мертвой точки вдруг перестали работать сейвы; тут я уже забил

Все использующиеся в игре текстурыВсе использующиеся в игре текстурыПерфомансПерфоманс

Хочется сразу сказать что техлиды и сеньоры с менторским тоном и заоблачной экспертизой в микробенчмаркинге в комментариях только приветствуются. Это же вообще самое забавное и интересное на Хабре когда лиды с сеньорами начинают рубиться в комментариях за стоимость операций в джаваскрипте и то, чей микробенчмаркинг заоблачнее! Остается только надеятся на то, что когда вы будете размазывать мой форсрелоад как дешёвое и сердитое средство изменения сцены вы обязательно продемонстрируете ваши работающие примеры в которых сцена Three с большим количеством разнообразных объектов на ней очищается и заново инициализируется через свои внутренние методы (например, без перезагрузки текстур и прочих ассетов, аудио). Я же не говорю что это невозможно, это очевидно дорого. Намного дороже чем просто сделать форсрелоад. Понятно что хороший проект это прежде всего кодовая база которая может и должна легко развиваться. Но невозможно прикрутить все фичи сразу, а использование дешевого релоада сейчас никак не блокирует добавление более сложного функционала в будущем. Да и кроме дешевизны более простой подход и идеологически привлекателен. Я убежден что хороший код это простой и понятный код, хороший подход простой подход, точно так же как и интерфейс который они предоставляют. Простое решение лучше сложного, особенно если мы только начинаем строить что-то.

Для того чтобы избежать лишних сложностей в моей реализации сцена практически неизменна. Она разворачивается, запускается и дальше функционирует в некотором постоянном виде [порождая и уничтожая только выстрелы и взрывы] пока не происходит переход в другую локацию (или проигрыш на этой). Конкретнее: cейчас я нигде кроме удаления не подлежащих внешнему учету выстрелов и взрывов не использую scene.remove(object.mesh) например при сборе героем полезных предметов, делая вместо этого:

// встроенное свойство на Object3D в Threeobject.mesh.visible = false;// кастомный флаг кастомного массива объектовobject.isPicked = true;

Поэтому мы, например, можем даже использовать свойство id: number mesh`ей вместо uuid: string для учета и идентификации объектов. Так как все подлежащие учету объекты всегда остаются на сцене мы можем быть уверены что Three не поменяет айдишники, сдвинув нумерацию под коробкой при удалении элемента (но если вы хотите все-таки удалять что-то такое просто опирайтесь на uuid при работе с этим).

Я нигде и не на чем не использую .dispose(), так как мне просто нечего удалять. В документации библиотеки сказано что лучший момент и повод для этого переход между уровнями, когда можно и нужно, например удалить ненужные текстуры. Как вы видите выше, текстур у нас совсем немного и они все всегда нужны.

Посмотрим на структуру проекта:

. /public // статические ресурсы   /audio // аудио     ...   /images // изображения     /favicons // дополнительные фавиконки для браузеров       ...     /modals // картинки для информационных панелей       /level1 // для уровня 1         ...       ...     /models       /Levels         /level0 // модель-схема Песочницы (скрытый уровень 0 - тестовая арена)           Scene.glb         ...       /Objects          Element.glb          ...     /textures        texture1.jpg        ...   favicon.ico // основная фавиконка 16 на 16   index.html // статичный индекс   manifest.json // файл манифеста   start.jpg // картинка для репозитория ) /src   /assets // ассеты сорцов     optical.png // у меня один такой )))   /components // компоненты, миксины и модули     /Layout // компоненты и миксины UI-обертки над игрой       Component1.vue // копонент 1       mixin1.js // миксин 1       ...     /Three // сама игра        /Modules // готовые полезные модули из библиотеки          ...        /Scene           /Enemies // модули врагов             Enemy1.js             ...           /Weapon // модули оружия             Explosions.js // взрывы             HeroWeapon.js // оружие персонажа             Shots.js // выстрелы врагов           /World // модули различных элементов мира             Element1.js             ...           Atmosphere.js // модуль с общими для всех уровней объектами (общий свет, небо, звук ветра) и проверками взаимодействия между другими модулями           AudioBus.js // аудио-шина           Enemies.js // модуль всех врагов           EventsBus.js // шина событий           Hero.js // модуль персонажа           Scene.vue // основной компонент игры           World.js // мир   /store // хранилище Vuex     ...   /styles // стилевая база препроцессора SCSS     ...   /utils // набор утилитарных js-модулей для различных функциональностей     api.js // интерфейс для связи с бэкендом     constants.js // вся конфигурация игры и тексты-переводы     i18n.js // конфигурация переводчика     screen-helper.js // модуль "экранный помощник"     storage.js // модуль для взаимодействия с браузерным хранилищем     utilities.js // набор полезных функций-атомов   App.vue // "главный" компонент   main.js // эндпоинт сорцов Vue ... // все остальное на верхнем уровне проекта, как обычно: конфиги, gitignore, README.md и прочее

То как я работаю со стилями и оформлением компонент в UI-обертке подробно описано в моем первом масштабном тексте для сообщества. Целью данной статьи не является рассмотрение отдельных разрозненных особенностей перечисленных выше технологий и инструментов. Хочется рассказать об опыте, проблемах и найденных возможных путях их решениях которые возникли в результате практической попытки совместить данные технологии именно для решения конкретной задачи создания кастомного браузерного шутера.

Сейчас игра в спокойном состоянии когда потревоженных врагов нет или совсем мало, на компьютере с поддержкой GPU выдает практически коммерческие 60FPS в Google Chrome (ну или Yandex Bro). В Firefox игра запускается, но показатель производительности не менее чем в 2-3 раза ниже. А когда начинается мясо, появляется много потревоженных врагов, выстрелов и взрывов в Лисе процесс начинает лагать и может вообще повиснуть. Моя экспертиза в микробенчмаркинге сейчас пока не позволяет с умным видом рассуждать о причинах этой разницы. Будем считать что дело в более слабой поддержке WebGL и вычислительных способностях, что-то такое))...

Легенда

Так как выбранный мною тип игры совсем обычный классический FPS, пиф-паф, ойойой, мне была нужна актуальная захватывающая легенда. Прообраз главного героя Робот-собутыльник появился из нашего с друзьями музыкального рок-творчества: существует пластинка его имени и забавный клип про него... В игре речь, видимо, идет о потомках пьющего робота

Земля, далекое будущее. Люди давным-давно перебили друг-друга в ядерных войнах, выясняя кто правый, кто левый, кто белый, а кто красный и прочее. На не затронутых бомбардировками атоллах в Тихом Океане размножилось несколько рас человекоподобных роботов. Например, более человекоподобные, имитирующие органику, двуполость и личные отношения Собутыльники, которые перерабатывают животных и растительность в жизненную силу и спецэффекты. Внутри них, по тонким крепким трубкам, течет специальный сброженный органический микс, схожий с человеческим вином, приводя их в движение. Или более машиноподбные однополые Кибер-Танцоры, проповедующие медитативный Дзинь-Нойз. На почве гендерных и религиозных разногласий между культурами, конечно же, понеслась жестокая война.

Пара молодых Собутыльников отправились в свадебное путешествие по океану. Но катер внезапно дал течь и они с трудом дотянули до ближайшего атолла. Прекрасный на первый взгляд остров оказался опасной ловушкой, так как был давно облюбован для медитаций Танцорами.

Робот-Собутыльник приходит в себя на полу пыточной камеры тюрьмы Однополых... Баки пусты... Его мучители, видимо, решили что он уже не жилец, и оставили подыхать... На стене висит портрет легендарного Последнего Президента идеологического предтечи и кумира Танцоров человека, когда-то развязавшего последнюю в истории человечества войну

Аллегории прозрачные, конечно. Но сама рамочная идея про конфликт однополых и двуполых машин в будущем, имхо, замечательная. Так и будет, точно, все предпосылки уже налицо. ))

В игре пока нет самих главных врагов, только их дроны (нужен специалист по скелетной анимации отзовись!), но уже присутствуют специфические объекты и отдельная механика позволяющая глубже раскрыть генезис Собутыльников, историю их борьбы против демократической диктатуры Танцоров. Это информационные панели которые включаются когда герой находится поблизости и важно в одном помещении с ними. Ниже об этом будет подробнее, когда будем разбирать постройку мира и взаимодействие модулей.

ДашбордДашборд

Если подойти к панели и нажать E открывается модаль с исторической справкой:

Рассказ о будущем внутриРассказ о будущем внутри

Это задел для дальнейшего развития в сторону РПГ. Например на таких дашбордах несложно организовать торговый ларек, в котором можно было бы менять поверженный и подобранный металлолом на полезные цветы и бутылки.

Геймплей

В моей игре любой выстрел сталкиваясь с препятствием вызывает взрыв который уронит и врагов и героя на величину зависящую от расстояния. Поражение врага вызывает взрыв повышенной мощности следует быть осторожным в ближнем бою.

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

Цветы и бутылкиЦветы и бутылки

Так как у нас почти РПГ и возможно собирать полезный стафф перемещаясь назад по локациям цветы и бутылки имеют определенный вес и герой не может носит с собой больше 25 его единиц. Вес вместе с количеством возвращаемого приемом цветка здоровья помогает сбалансировать всю эту механику: тупые цветы дающий неуязвимость красный и прокачивающий виномет фиолетовый весят больше, а здоровье дают меньше чем более интересные желтый и зеленый.

Сейчас уже есть три уровня сложности игры они влияют на срок действия цветов, дистанцию на которой героя обнаруживают враги (если персонаж ползет может подобраться в два раза ближе) и, конечно же силу урона от выстрелова и взрывов.

Уровни сложностиУровни сложности

Если я найду скелетного аниматора и смогу довести до ума то что уже есть и потом продолжить развивать проект дальше, можно будет подумать о следующих фичах:

  • Разное оружие. Виномет потеряет прицел, но станет работать как пулемет-автомат не нужно будет все время нажимать на левую кнопку мыши. С прицелом будет снайперская винтовка стреляющая стальными снарядами (которые, например, можно делать из собранных разрушенных врагов тут бы пригодился уже упомянутый торговый ларек на дашбордах).

  • Еще один вид бутылок с крепышом часовые мины: установил быстро отбегаешь. Будут полезны для разрушения Танков с огромным здоровьем или крупных скоплений любых врагов.

  • Новые типы врагов. Танки медленные, но очень живучие и с убойным выстрелом. Стационарные дроны-пушки умеющие стрелять не в горизонтальной плоскости навесом как делают дроны сейчас, а под разными углами и двойными зарядами. Рядовые бойцы Танцоры Роботы-Курицы мой барабанщик почему-то их именно так видит. В идеале они высаживаются как спезназ, приземляясь на челноке в центр третьей локации когда герой на нее заходит. В пятой локации может появиться босс: Робот-Блогер Финальный с ракетницей

  • Трубочных и двуполых Собутыльников нарисовать сложно, но в идеале было бы рассадить их по камерам Централа четвертой локации.

  • Можно добавить 2D-карту с врагами (внизу и по центру экрана)

Планов полно, но без скелетной анимации они бессмысленны, конечно

Но хватит лирики, перейдем к техническим решениям и собственно коду.

Конфигурация

Особенный кайф от написания кастомной игры в том, что после того как вы доставили новые фичи или любые изменения в код вам просто необходимо расслабиться и их честно искренне протестировать. Ручками. Сделать несколько каток, по любому. Тесты тут никак и ничем не помогут, даже, убежден, наоборот будут мешать прогрессу, особенно если вы не работаете по заранее известному плану, а постоянно экспериментируете. Браузерная игра на джаваскрипт это в принципе превосходный пример того, когда статическая типизация или разработка через тестирование будут только мешать добиться действительно качественного результата. (А на чем тут необходимо проверять типы, господа сеньоры? Я до сих пор в замешательстве от React c CSS Modules и просто Flow, а не TS даже в котором авторы маниакально проверяли что каждый, еще и передаваемый по цепочке компонент, класс модулей для оформления !!! это string А тут что будем маниакально типизировать, вектора?). И даже сам Роберт Мартин в Идеальном программисте делает несколько пассажей на тему бессмысленности TDD, когда говорит о рисках при разработке GUI. В моей игре можно сказать что и нет практически ничего кроме тонны двумерного и трехмерного GUI, ну и логики для него. Любая ошибка либо вызовет исключение, либо неправильное поведение во вьюхе и геймплее, которое может быть очень быстро обнаружено с помощью визуальной проверки, но очень сомнительно что вообще способно быть покрыто тестом.

На самом деле, создавая любую программу или даже просто разметку для программы вы всегда непреложно должны следовать некоторым общеизвестным простым принципам (но не всегда это TDD). Чтобы не происходило укороченный нереальный дедлайн, термоядерная перестрелка за окном вы должны писать свой код таким образом, чтобы его можно было легко отлаживать и развивать. Любое важное или повторяющиеся больше одного раза значение должно быть отражено в конфигурации. Влияющие на геймплей параметры должны быть локализованы в одном файле балансируя геймплей работать вы должны именно и практически только с ним одним.

Все настройки настройки и значения влияющие на геймплей и дизайн (константа DESIGN), а также весь текстовый контент-переводы у меня сосредоточены в constants.js.

Контрол

На сайте библиотеки Three представлено большое количество полезных примеров с демо-стендами, самых разных реализаций, функциональностей которые стоит изучить и по возможности к месту использовать. Я отталкивался в своих исследованиях, прежде всего, вот от этого примера. Это правильный, мягкий инерционный контрол от первого лица который математически обсчитывает столкновения с клеткой-миром gld-моделью с помощью октодерева. Проверять столкновения можно для капсулы (для героя или врагов) или обычных сферы Sphere и луча Ray от Three. Этого в принципе достаточно для чтобы сделать FPS-игру: сделать так чтобы герой и враги не сталкивались с миром и между собой, выстрелы взрывались при попадании в другие объекты и тд.

Для того чтобы понимать что происходит когда вы нажимаете кнопку Играть, игра запускается и курсор мыши пропадает вы должны знать о браузерной фиче Pointer_Lock_API. Мы добавляем такой контрол вместе со всей стандартной кухней Three в инициализации основного компонента-сцены, ищите:

// Controls// In First Person...

Но! Тут нюанс браузеры обязательно оставляют путь для панического отступления пользователю и резервируют клавишу Esc для того чтобы пользователь всегда мог разлочить указатель. Это касается нашего UI/UX в игре необходима клавиша P ставящая мир на паузу. Когда указатель залочен то бишь запущен игровой процесс нажатие на Esc, как уже сказано вызовет паузу. Но если мы попытаемся добавить обработку отпускания по 27ому коду даже только для режима паузы, все равно очень быстро увидим в консоли:

ОшибкаОшибка

Поэтому: забудьте про Esc. Пауза по клавише P. Есть еще одно ограничение и проблема связанная с созданием хорошего FPS-контрола: оружие. Я так понял что в энтерпрайзных реализациях руки-оружие это отдельный независимый план наложенный поверх мира. С Three, насколько я понимаю, сделать так не получится. Поэтому мой пока единственный в арсенале грозный виномет с оптическим прицелом это объект сцены который приделан к контролу. Я копирую вектор направления камеры на него. Но около зенита и надира в результате его начинает штормить он не может однозначно определить позицию. При взгляде совсем под ноги я его просто скрываю, а вот стрелять наверх нужно. Что делать с этим небольшим и не особо заметным багом я пока не придумал.

Оптический прицел винометаОптический прицел винометаВыстрел вверхВыстрел вверх

Пытаясь сделать скоростной задорный шутер на Three мы можем сразу забыть о тенях или дополнительных источниках освещения, особенно движущихся. Да, я пытался запилить качающиеся на ветру лампы для особенного мрачняка и криповости, движущиеся тени от них. Нет никак нельзя даже статичные точечные источники света сильно просаживают производительность (а нам еще врагов гонять). По поводу света я пришел к простому компромиссу: чтобы картинка не выглядела совсем сухо и скучно приделать мощный фонарик к контролу, герою. Фонарик можно выключать клавиша T.

Далее я просто пройдусь по основным модулям давая небольшие комментарии в интересных моментах.

Сцена

Основной компонент Scene.vue предоставляет:

  • всю стандартную кухню Three: Renderer, Scene и ее туман, Camera и Audio listener в ней, Controls

  • набор утилитарных переменных для использования в анимационных циклах низовых модулей

  • переменные для хранения коллекций примитивных дополнительных объектов превдоmesh`ей по которым работает кастинг

  • в том числе и через используемые миксины все необходимые ему самому или его низовым модулям геттеры и экшены стора Vuex

  • обрабатывает большинство (кроме тех, что удобно ловить в логике героя) событий клавиатуры, мыши и так далее

  • инициализирует Аудиошину, Шину Событий и Мир

  • анимирует Шину Событий, Героя и Мир

  • в наблюдателях значений важных геттеров добавляет игровой логики

Весь код тут простой, прямо очевидный, практически не требующий дополнительных пояснений. Что-то мы будем рассматривать дальше, например что за такие превдоmesh`и для кастинга. Но стоит только остановить внимание на такой простой базовой сущности как переменные. Дело в том что существует еще один действительно важный аспект который позволит нам вытянуть эту задачу с шутером это тут можно начинать смеяться экономия памяти в джаваскрипте (господа техлиды-сеньоры?). Да не надо ни при каких обстоятельствах создавать переменные в анимационных циклах и проверках низовых модулей, нужно использовать только те что уже есть в основном компоненте (ну или модуле), созданы заранее. Контекст основного компонента можно передавать в публичные методы низовых модулей-функций.

Стандартный модуль героя, врагов, предмета или специфического объекта вроде двери или информационной панели в общем виде выглядит так:

import * as Three from 'three';import { DESIGN } from '@/utils/constants';function Module() {  let variable; // локальная переменная - когда очень удобна или необходима при инициализации или во всей логике    // ...  // Инициализация  this.init = (    scope,    texture1,    material1,    // ...  ) => {    // variable = ...    // ...  };  // Функция анимационного цикла для этого модуля - опционально (предметы, например, не нужно анимировать)  this.animate = (scope) => {    // А вот тут и в остальной логике стараемся использовать уже только переменные Scene.vue:    scope.moduleObjectsSore.filter(object => object.mode === DESIGN.ENEMIES.mode.active).forEach((object) => {      // scope.number = ...      // scope.direction = new Three.Vector3(...);      // variable = ... - так, конечно, тоже можно, главное не let variableNew;      // ...    });  };}export default Module;

Стор

Хранилище Vuex поделено на 3 простых модуля. layout.js отвечает за основные параметры игрового процесса: паузы-геймоверы и тд, взаимодействует с API-бекенда. В hero.js большое количество полей и их геттеров, но всего два экшена/мутации. Этот модуль позволяет в максимально унифицированной форме распространять изменения значений отдельных параметров, шкал, флагов на герое с помощью setScale или может пакетно установить эти значения через setUser.

Третий модуль совсем примитивный preloader.js и целиком состоит из однотипных boolean-полей с false по дефолту. Пока его поле isGameLoaded единственное в состоянии модуля с геттером с false не получает true при запуске или перезагрузке приложения пользователь будет видеть лоадер. Каждое из остальных полей обозначает подгрузку определенного ассета: текстуры, модели, аудио или постройку определенного типа объектов.

Если нам нужно подгрузить, например, текстуру песка:

import * as Three from 'three';import { loaderDispatchHelper } from '@/utils/utilities';function Module() {  this.init = (    scope,    // ...  ) => {    const sandTexture = new Three.TextureLoader().load(      './images/textures/sand.jpg',      () => {        scope.render(); // нужно вызвать рендер если объекты использующию эту текстуру заметны "на первом экране"          loaderDispatchHelper(scope.$store, 'isSandLoaded');      },    );  };}export default Module;
// В @/utils/utilities.js:export const loaderDispatchHelper = (store, field) => {  store.dispatch('preloader/preloadOrBuilt', field).then(() => {    store.dispatch('preloader/isAllLoadedAndBuilt');  }).catch((error) => { console.log(error); });};

Когда отправка сообщения о том что элемент подгружен разрешается функция-помощник из набора атомов-утилит отправляет экшен проверяющий все ли готово?.

Согласен что решение по прелоадера не идеальное с точки зрения UI в том смысле что мы не демонстрируем общий прогресс по загрузке. Но на данном этапе это не кажется критически важным, особенно в свете озвученной выше концепции и даже факта быстрой перезагрузки локаций.

Аудиошина

Одна только необходимость воздействовать сразу на все звучащие аудио, например, при переходе в режим паузы или при включении машины времени диктует требование формирование общего микшера в системе аудиошины. Кроме того, такой подход максимально удобно унифицирует синтаксис однообразных похожих вызовов и избавляет от необходимости следить за очередностью подгрузки аудио на объекты (когда на одном объекте может звучать несколько) с помощью LoadingManager`ов.

Аудио бывают:

1) Звучащие на контроле-герое и PositionalAudio на объектах

2) Луп или сэмпл

Насколько я понял аудио-API Three полностью отражает API браузера. Меня как человека уже всю осознанную жизнь занимающемуся на досуге звукорежиссурой несколько напрягает необходимость станцевать с бубном в коде для того если захочется добавить простой фейд в начале или конце сэмпла, но что тут поделаешь. При желании мы как раз можем удобно добавить такую функциональность именно с помощью модуля аудиошины.

В Hero удобно записывать аудио в переменную чтобы можно было просто работать [в обход шины] с ними в специфической логике:

// В @/components/Three/Scene/Hero.js:import * as Three from "three";import {  DESIGN,  // ...} from '@/utils/constants';import {  loaderDispatchHelper,  // ...} from '@/utils/utilities';function Hero() {  const audioLoader = new Three.AudioLoader();  let steps;  let speed;  // ...  this.init = (    scope,    // ...  ) => {    audioLoader.load('./audio/steps.mp3', (buffer) => {      steps = scope.audio.addAudioToHero(scope, buffer, 'steps', DESIGN.VOLUME.hero.step, false);      loaderDispatchHelper(scope.$store, 'isStepsLoaded');    });  };  this.setHidden = (scope, isHidden) => {    if (isHidden) {      // ...      steps.setPlaybackRate(0.5);    } else {      // ...      steps.setPlaybackRate(1);    }  };  this.setRun = (scope, isRun) => {    if (isRun && scope.keyStates['KeyW']) {      steps.setVolume(DESIGN.VOLUME.hero.run);      steps.setPlaybackRate(2);    } else {      steps.setVolume(DESIGN.VOLUME.hero.step);      steps.setPlaybackRate(1);    }  };  // ...  this.animate = (scope) => {    if (scope.playerOnFloor) {      if (!scope.isPause) {        // ...        // Steps sound        if (steps) {          if (scope.keyStates['KeyW']            || scope.keyStates['KeyS']            || scope.keyStates['KeyA']            || scope.keyStates['KeyD']) {            if (!steps.isPlaying) {              speed = scope.isHidden ? 0.5 : scope.isRun ? 2 : 1;              steps.setPlaybackRate(speed);              steps.play();            }          }        }      } else {        if (steps && steps.isPlaying) steps.pause();        // ...      }    }  };}export default Module;

Казалось бы шаги нужно делать лупом? Ан нет, не получится. И, например, вешать еще один последний шаг на окончание движения не позволит само устройство инерционного контрола собирающего много быстрых событий. С ним даже не особо ясно когда это вообще происходит когда позиция героя перестаёт изменяться нам уже не надо. Найденное мною решение простое и хорошо работает, дает нужный эффект. Сэмпл шага это ровно два шага. Если появляется событие клавиатуры запускаем аудио. И оно всегда отыгрывает до конца. Если персонаж переходит на бег или начинает ползти просто меняем скорость.

Тут надо упомянуть только об одном обнаруженном мною нюансе. Если аудио не луп с ним возникают проблемы при постановке и снятии с паузы. При следующих запусках отыгранная в предыдущий раз часть трека съедается пока он вообще не перестает звучать. Фиксит это данная строчка в функции добавления аудио на шину:

if (!isLoop) audio.onEnded = () => audio.stop();

Имейте ввиду!

import * as Three from "three";import { DESIGN, OBJECTS } from '@/utils/constants';import { loaderDispatchHelper } from '@/utils/utilities';function Module() {  const audioLoader = new Three.AudioLoader();  // ...  let material = null;  const geometry = new Three.SphereBufferGeometry(0.5, 8, 8);  let explosion;  let explosionClone;  let boom;  this.init = (    scope,    fireMaterial,    // ...  ) => {    // Звук наземных врагов - загружаем в инициализации на объекты через шину    audioLoader.load('./audio/mechanism.mp3', (buffer) => {      loaderDispatchHelper(scope.$store, 'isMechanismLoaded');      scope.array = scope.enemies.filter(enemy => enemy.name !== OBJECTS.DRONES.name);      scope.audio.addAudioToObjects(scope, scope.array, buffer, 'mesh', 'mechanism', DESIGN.VOLUME.mechanism, true);     });    // Звук взрыва - то есть - "добавляемой и уничтожаемой" сущности - загружаем и записываем в переменную    material = fireMaterial;    explosion = new Three.Mesh(geometry, material);    audioLoader.load('./audio/explosion.mp3', (buffer) => {      loaderDispatchHelper(scope.$store, 'isExplosionLoaded');      boom = buffer;    });  };  // ...  // ... где-то в логике врагов:  this.moduleFunction = (scope, enemy) => {    scope.audio.startObjectSound(enemy.id, 'mechanism');    // ...    scope.audio.stopObjectSound(enemy.id, 'mechanism');    // ...  };  // При добавлении взрыва на шину взрывов:  this.addExplosionToBus = (    scope,    // ...  ) => {    explosionClone = explosion.clone();    // ..    scope.audio.playAudioOnObject(scope, explosionClone, boom, 'boom', DESIGN.VOLUME.explosion);    // ..  };}export default Module;

Попробуйте подобрать и принять зеленый цветок запускающий машину времени в игре, классно? ))

Шина событий и сообщения

Очевидно что кроме аудиомикшера игре необходима еще одна одна шина: делей для событий модуль который будет задерживать отправку изменений в контексте игрового времени. Например, если было показано сообщение, а потом система поставлена на паузу мы не можем использовать нигде обычные таймауты только обновляемые в анимационном цикле часы Clock Three. Модуль хранит актуальные записи о связанных событиях и в нужный момент вызывает переданный коллбэк.

В игре присутствует интерфейс текстовых сообщений которые показываются в правом верхнем углу экрана. Сообщения могут быть двух видов: постоянные и временные. Первые должны быть видимы, например, когда герой кастит предмет или дверь и игра сообщает об этом. Вторые сообщают о состоявшихся игровых событиях, нумеруются и должны показываться в виде очереди на короткий интервал времени каждое. Для них категорически необходима функциональность шины событий.

Мир

Модель первой локацииМодель первой локации

В инициализации модуля мира по порядку:

  1. Загружаются все переиспользуемые в остальных модулях текстуры и создаются все такие материалы и геометрии.

  2. Загружается и разбирается модель уровня. На ее основе формируются массивы данных обо всех игровых объектах в OBJECTS и рабочие массивы, списки псевдообъектов для сущностей с одинаковой функциональностью в основном контексте.

  3. На примитивы которые должны стать видимыми элементами, строительными блоками мира накладываются текстуры. Места-пустышки обозначающие места рождения врагов или нахождения полезных предметов после учета удаляются.

  4. Двери переносятся в отдельную группу из основной модели. Из этих двух групп очищенной сцены и все дверей создаются стартовые октодеревья.

  5. Инициализируются все остальные модули.

Я разбираю один файл glb и как совершенно необходимый такой игре редактор уровней и как готовую модель для построения стартовых октодеревьев мира, и, отдельно дверей в нем, и как почти готовую не текстурированную основу самого примитивного визуального мира. Различать примитивы можно с помощью специфических маркеров в их наименовании. Это не самое надежное соглашение, оно чревато ошибками, но они легко обнаруживаются визуально при ручном тестировании. Изменения можно вносить очень быстро. Тут уже все зависит от вашей фантазии и выдуманного с помощью нее дизайна и геймплея, ну и количества времени которые вы можете на это потратить. Например, я использую маркер Mandatory если хочу чтобы цветок или бутылка были обязательными, если его нет постройка зависит от рандома. Или для механики включения-выключения информационных панелей собирается отдельный массив с их комнатами параллелепипедами определяющими объем в котором панель реагирует на персонажа. Для геометрии такого объекта следует сделать при инициализации:

room.geometry.computeBoundingBox();

room.visible = false;

И теперь у нас может быть вот такой публичный метод в модуле панелей и его забегая вперед можно будет использовать в модуле Атмосферы при проверках отношения панелей к герою:

// В @/components/Three/Scene/World/Screens.js:this.isHeroInRoomWithScreen = (scope, screen) => {scope.box.copy(screen.room.geometry.boundingBox).applyMatrix4(screen.room.matrixWorld); if (scope.box.containsPoint(scope.camera.position)) return true;return false;};

При постройке дверей я использую примитив из основного файла как массив самой двери, добавляя дизайн уже в джаваскрипте текстуру, маркеры уровня доступа с обеих сторон и псевдоmesh. Для правильной работы дверей все равно нужен некоторый такой дополнительный псевдообъем и подобная комнатам панелей логика для того чтобы не дверь не закрывалась когда герой находится в ее проеме и отскакивала если зашел в него во время закрытия.

Псевдообъект-помощник для двериПсевдообъект-помощник для двериДверь не закрываетсяДверь не закрывается

Совершенно точно что тут можно улучшить сделать пустышки обозначающие место рождения врагов не планами один на один метр а большими планами для наземных юнитов и трехмерными коробками для воздушных чтобы они могли появляться в случайной точке некоторого прямоугольника на поверхности или трехмерного объема. Но пока лень. )

Анимационный цикл мира это просто список анимационных циклов всех модулей врагов, объектов и оружия которые должны быть анимированы кроме героя. Если включена машина времени то он вызывается через раз.

Кастинг

Вот мы и добрались до самого интересного: кастинг и столкновения. Как сделать так, чтобы предметы можно было собирать, а герой и враги не сталкивались с миром и друг-другом. Для обоих механик я использую дополнительные невидимые примитивы, псевдоmesh`и. Они инициализируются и записываются в абстрактные объекты которыми оперирует система вместе с основным видимым и всеми необходимыми им флагами-свойствами. Для движущихся врагов еще записывается коллайдер Sphere. Псевдомеши идут на кастинг (предметы) или построение и обновление октодеревьев (враги). А коллайдер для проверки столкновения с ними.

Псевдообъекты-помощники для предметовПсевдообъекты-помощники для предметов

Геометрия и материал готовиться в мире перед инициализацией всех вещей и надежнее сделать материал двусторонними так кастинг будет работать даже если герой оказался внутри псевдообъекта:

// В @/components/Three/Scene/World.js:const pseudoGeometry = new Three.SphereBufferGeometry(DESIGN.HERO.HEIGHT / 2,  4, 4); const pseudoMaterial = new Three.MeshStandardMaterial({ color: DESIGN.COLORS.white, side: Three.DoubleSide,});new Bottles().init(scope, pseudoGeometry, pseudoMaterial);

В модуле конкретной вещи:

// В @/components/Three/Scene/World/Thing.js:import * as Three from 'three';import { GLTFLoader } from '@/components/Three/Modules/Utils/GLTFLoader';import { OBJECTS } from '@/utils/constants';import { loaderDispatchHelper } from '@/utils/utilities';function Thing() {  let thingClone;  let thingGroup;  let thingPseudo;  let thingPseudoClone;  this.init = (    scope,    pseudoGeometry,    pseudoMaterial,  ) => {    thingPseudo = new Three.Mesh(pseudoGeometry, pseudoMaterial);    new GLTFLoader().load(      './images/models/Objects/Thing.glb',      (thing) => {        loaderDispatchHelper(scope.$store, 'isThingLoaded'); // загружена модель        for (let i = 0; i < OBJECTS.THINGS[scope.l].data.length; i++) {          // eslint-disable-next-line no-loop-func          thing.scene.traverse((child) => {            // ... - тут "покраска" материалами частей вещи          });          // Клонируем объект и псевдо          thingClone = thing.scene.clone();          thingPseudoClone = thingPseudo.clone();          // Псевдо нужно дать правильное имя чтобы мы могли различать его при кастинге          thingPseudoClone.name = OBJECTS.THINGS.name;          thingPseudoClone.position.y += 1.5; // корректируем немного позицию по высоте          thingPseudoClone.visible = false; // выключаем рендер          thingPseudoClone.updateMatrix(); // обновляем          thingPseudoClone.matrixAutoUpdate = false; // запрещаем автообновление          // Делаем из обхекта и псевдо удобную группу          thingGroup = new Three.Group();          thingGroup.add(thingClone);          thingGroup.add(thingPseudoClone);          // Выставляем координаты из собранных из модели уровня данных          thingGroup.position.set(            OBJECTS.THINGS[scope.l].data[i].x,            OBJECTS.THINGS[scope.l].data[i].y,            OBJECTS.THINGS[scope.l].data[i].z,          );          // Записываем в "рабочие объеты" - по ним будем кастить и прочее          scope.things.push({            id: thingPseudoClone.id,            group: thingGroup,          });          scope.objects.push(thingPseudoClone);          scope.scene.add(thingGroup); // добавляем на сцену        }        loaderDispatchHelper(scope.$store, 'isThingsBuilt'); // построено      },    );  };}export default Thing;

Теперь мы можем тыкать направленным вперед лучом из героя в анимационном цикле Hero.js:

// В @/components/Three/Scene/Hero.js:import { DESIGN, OBJECTS } from '@/utils/constants';function Hero() {  // ...  this.animate = (scope) => {    // ...    // Raycasting    // Forward ray    scope.direction = scope.camera.getWorldDirection(scope.direction);    scope.raycaster.set(scope.camera.getWorldPosition(scope.position), scope.direction);    scope.intersections = scope.raycaster.intersectObjects(scope.objects);    scope.onForward = scope.intersections.length > 0 ? scope.intersections[0].distance < DESIGN.HERO.CAST : false;    if (scope.onForward) {      scope.object = scope.intersections[0].object;      // Кастим предмет THINGS      if (scope.object.name.includes(OBJECTS.THINGS.name)) {        // ...      }    }    // ...  };}export default Hero;

Кастинг очень полезен и для усовершенствования ИИ врагов. С помощью него возможно проверять имеет ли смысл, есть ли возможность двигаться-прыгать вперед, лететь вниз, делать выстрел. В утилитах:

// В @/utils/utilities.js:// let arrowHelper;const fixNot = (value) => { if (!value) return Number.MAX_SAFE_INTEGER; return value;};export const isEnemyCanMoveForward = (scope, enemy) => { scope.ray = new Three.Ray(enemy.collider.center, enemy.mesh.getWorldDirection(scope.direction).normalize()); scope.result = scope.octree.rayIntersect(scope.ray); scope.resultDoors = scope.octreeDoors.rayIntersect(scope.ray); scope.resultEnemies = scope.octreeEnemies.rayIntersect(scope.ray); // arrowHelper = new Three.ArrowHelper(scope.direction, enemy.collider.center, 6, 0xffffff); // scope.scene.add(arrowHelper); if (scope.result || scope.resultDoors || scope.resultEnemies) {   scope.number = Math.min(fixNot(scope.result.distance), fixNot(scope.resultDoors.distance), fixNot(scope.resultEnemies.distance));   return scope.number > 6; } return true;};

Для наглядной визуальной отладки подобных механик очень полезен объект Three ArrowHelper. Если мы включим его добавление на сцену в функции выше:

Отладка с включенными стрелочными помощникамиОтладка с включенными стрелочными помощниками

С помощью подобной простой функции можно добиться того что враги не реагируют на героя через стены строим луч от центра коллайдера к камере и сравниваем дистанцию от камеры до обнаруженного столкновения:

// В @/utils/utilities.js:export const isToHeroRayIntersectWorld = (scope, collider) => { scope.direction.subVectors(collider.center, scope.camera.position).negate().normalize(); scope.ray = new Three.Ray(collider.center, scope.direction); scope.result = scope.octree.rayIntersect(scope.ray); scope.resultDoors = scope.octreeDoors.rayIntersect(scope.ray); if (scope.result || scope.resultDoors) {   scope.number = Math.min(fixNot(scope.result.distance), fixNot(scope.resultDoors.distance));   scope.dictance = scope.camera.position.distanceTo(collider.center);   return scope.number < scope.dictance; } return false;};

Враги

Кроме инициализации самих низовых модулей врагов, модуль Enemies.js содержит и всю общую логику обслуживающую жизненный цикл врагов. Сейчас у меня четыре этапа-режима жизни у врагов:

// В @/utils/constatnts.js:export const DESIGN = {  DIFFICULTY: {    civil: 'civil',    anarchist: 'anarchist',    communist: 'communist',  },  ENEMIES: {    mode: {      idle: 'idle',      active: 'active',      dies: 'dies',      dead: 'dead',    },    spider: {      // ...      decision: {        enjoy: 60,        rotate: 25,        shot: {          civil: 40,          anarchist: 30,          communist: 25,        },        jump: 50,        speed: 20,        bend: 30,      },    },    drone: {      // ...      decision: {        enjoy: 50,        rotate: 25,        shot: {          civil: 50,          anarchist: 40,          communist: 30,        },        fly: 40,        speed: 20,        bend: 25,      },    },  },  // ...};
// В @/components/Three/Scene/Enemies.js:import { DESIGN } from '@/utils/constants';import {  randomInteger,  isEnemyCanShot,  // ...} from "@/utils/utilities";function Enemies() {  // ...  const idle = (scope, enemy) => {    // ...  };  const active = (scope, enemy) => {    // ...    // Где-то в логике агрессивного режима: решение на выстрел (если отдыхает)    scope.decision = randomInteger(1, DESIGN.ENEMIES[enemy.name].decision.shot[scope.difficulty]) === 1;    if (scope.decision) {      if (isEnemyCanShot(scope, enemy)) {        scope.boolean = enemy.name === OBJECTS.DRONES.name;        scope.world.shots.addShotToBus(scope, enemy.mesh.position, scope.direction, scope.boolean);        scope.audio.replayObjectSound(enemy.id, 'shot');      }    }  };  const gravity = (scope, enemy) => {    // ...  };  this.animate = (scope) => {    scope.enemies.filter(enemy => enemy.mode !== DESIGN.ENEMIES.mode.dead).forEach((enemy) => {      switch (enemy.mode) {        case DESIGN.ENEMIES.mode.idle:          idle(scope, enemy);          break;        case DESIGN.ENEMIES.mode.active:          active(scope, enemy);          break;        case DESIGN.ENEMIES.mode.dies:          gravity(scope, enemy);          break;      }    });  };}export default Enemies;

В зависимости от вспомогательных проверочных функций которые мы затрагивали выше, своего состояния (на полу или в прыжке, например, если это наземный юнит) каждый живой враг может с некоторой частотой принимать определенные решения.

Но! Самое важное на что нужно обратить внимание: в idle спокойном режиме полноценно двигается некоторое случайное время только один выбранный случайным образом враг. Остальные поворачиваются на месте + может и должна быть запущена анимация. Такая оптимизация позволяет действительно полноценно разгрузить систему.

Столкновения

Октодеревом в данном тексте обозначается максимально упрощенная модель 3D-пространства которое занимает некоторая группа объектов с минимально необходимым и достаточным для обсчета количеством граней, рёбер и вершин.

Такие октодеревья, как вы уже наверняка поняли из примера полезной функции из конца раздела про кастинг помогают нам грамотно обсчитывать кастинг лучей или столкновения коллайдеров героя/врагов с миром и другими объектами. В случае если персонаж движется и мы обнаруживаем столкновение октодерева с коллайдером капсулой героя или сферой врага вектору ускорения этого объекта добавляется вектор выталкивающий обратно центр его коллайдера (и все остальное, соответственно).

В текущей реализации используются три октодерева: мир: 1) пол, бетонные блоки, трубы, стекла, а также 2) двери и 3) враги. Каждый из врагов обсчитывает свои столкновения с персональным октодеревом врагов собранным без него.

Мы можем и должны обновлять октодеревья. Если дверь была открыта-закрыта или враг передвинулся нам нужно пересобрать соответствующее октодерево. При открытии закрытии двери лучше всего сделать это два раза: когда дверь открылась или закрылась настолько что герой уже может или наоборот больше не может пройти через нее и когда процесс открытия/закрытия завершен.

В моей реализации на объекты врагов инициализируется по две псевдо-коробки. Это не оптимально, но сделано в целях балансировки визуальной составляющих двух механик: 1) столкновение героя с врагами 2) столкновения врагов с миром и между собой. Визуальное тестирование показало что для реализации первой механики нужна коробка намного более меньшего размера чем для второй.

Точность обсчета столкновений с октодеревьями напрямую зависит от качества оптимизации анимационного цикла и ее непосредственного результата фактической производительности системы. Если скорость объекта высокая, но система начинает захлебываться, то есть фрейм, дельта анимационного цикла удлиняется обсчет с октодеревом не успеет компенсировать или даже вообще зарегистрировать столкновение и пользователь может отхватить глюк: герой или враг может быть вытолкнут через стену-стекло. Но не будем о грустном. )

Мы не можем обновлять октодерево врагов героя или персональные октодеревья врагов каждый раз когда вызывается обсчет столкновений наша система просто сразу ляжет в таком случае. Но достаточно делать это, например, каждые полсекунды. Обновили октодерево всех врагов для героя запускаем таймер на полсекунды. Точно также и с персональными октодеревьями врагов.

// В @/utils/constatnts.js:export const DESIGN = {  OCTREE_UPDATE_TIMEOUT: 0.5,  // ...};
// В @/utils/utilities.js:// Обновить персональное октодерево врагов для одного врагаimport * as Three from "three";import { Octree } from "../components/Three/Modules/Math/Octree";export const updateEnemiesPersonalOctree = (scope, id) => {  scope.group = new Three.Group();  scope.enemies.filter(obj => obj.id !== id).forEach((enemy) => {    scope.group.add(enemy.pseudoLarge);  });  scope.octreeEnemies = new Octree();  scope.octreeEnemies.fromGraphNode(scope.group);  scope.scene.add(scope.group);};
// Столкновения враговconst enemyCollitions = (scope, enemy) => {  // Столкновения c миром - полом, стенами, стеклами и трубами  scope.result = scope.octree.sphereIntersect(enemy.collider);  enemy.isOnFloor = false;  if (scope.result) {    enemy.isOnFloor = scope.result.normal.y > 0;    // На полу?    if (!enemy.isOnFloor) {      enemy.velocity.addScaledVector(scope.result.normal, -scope.result.normal.dot(enemy.velocity));    } else {      // Подбитый враг становится совсем мертвым после падения на пол и тд      // ...    }    enemy.collider.translate(scope.result.normal.multiplyScalar(scope.result.depth));  }  // Столкновения c дверями  scope.resultDoors = scope.octreeDoors.sphereIntersect(enemy.collider);  if (scope.resultDoors) {    enemy.collider.translate(scope.resultDoors.normal.multiplyScalar(scope.resultDoors.depth));  }  // Делаем октодерево из всех врагов без этого, если давно не делали  if (scope.enemies.length > 1    && !enemy.updateClock.running) {    if (!enemy.updateClock.running) enemy.updateClock.start();    updateEnemiesPersonalOctree(scope, enemy.id);    scope.resultEnemies = scope.octreeEnemies.sphereIntersect(enemy.collider);    if (scope.resultEnemies) {      result = scope.resultEnemies.normal.multiplyScalar(scope.resultEnemies.depth);      result.y = 0;      enemy.collider.translate(result);    }  }  if (enemy.updateClock.running) {    enemy.updateTime += enemy.updateClock.getDelta();    if (enemy.updateTime > DESIGN.OCTREE_UPDATE_TIMEOUT && enemy.updateClock.running) {      enemy.updateClock.stop();      enemy.updateTime = 0;    }  }};

Своя атмосфера

Модуль с романтическим названием Atmosphere.js отвечает за элементы мира которые одинаковы для всех локаций: свет, небо, и в дальнейшем взаимодействие между другими модулями в анимационном цикле работает посредником.

Если вывалится за стену и забежать за край небаЕсли вывалится за стену и забежать за край неба

Я долго придумывал и придумал как сделать прикольное небо, облака: это огромная вывернутая по одной из осей и вращающаяся текстурированная сфера.

При некотором изменении позиции героя (сейчас это 10 метров) модуль проверяет всех живых врагов и панели и меняет их режимы в зависимости от актуальной ситуации. Сейчас дроны не видят героя через толстые пуленепробиваемые стекла. Для того чтобы это изменить нужно выделить стекла в отдельное октодерево, как и двери.

Пуленепробиваемые стеклаПуленепробиваемые стекла

Да, это вам не React c TS и тестами в финтех и банки!

Выводы которые я могу сделать на основе практики создания браузерной FPS на Three:

  • Мы не можем использовать тени и множество источников света

  • Мы должны экономить память в анимационном цикле и использовать в нем только готовые переменные

  • Мы должны и во всех остальных возможных аспектах максимально тщательно оптимизировать анимационный цикл, кастинг и обсчет столкновений в нем в контексте геймплея, так, чтобы сохранить драйв, но избежать падения производительности

  • Статическая типизация и юнит-тесты ничем не могут помочь в данном эксперименте

В принципе, я доволен тем что сейчас уже получилось. И хочется довести это до полной красоты. Поэтому если вы знаете кого-то кто увлекается скелетной анимацией и может согласится добавить несколько простых треков на мои glb скиньте, пожалуйста ему ссылку на статью?

Подробнее..

Автоматизация или смерть как управлять тысячами единиц игрового контента с помощью гугл-таблиц

10.06.2021 18:12:02 | Автор: admin

Несколько лет назад в нашем онлайн-шутере столкнулись с немного абсурдной проблемой: контента стало так много, что мы уже не могли с ним работать вручную. Сотни единиц оружия, карт, механик, гаджетов и много чего еще все нужно балансировать между собой, иначе геймплей развалится на части. Можно нанять больше людей, но лучше прибегнуть к алгоритмам, формулам и автоматизации.

Звучит сложно, но на деле хватило обычных гугл-таблиц. Ну, как обычных с тысячами строк и формулами, которые не помещаются на экран монитора. Пришлось немного повозиться с их организацией, зато теперь всей игрой мы управляем из нескольких документов.

Под катом на примерах расскажу, как автоматизировать работу с контентом, если в проекте его уже свыше тысячи единиц, как внедрить новые механики и фичи, не ломая при этом баланс и игровой опыт, и даже, как избавить QA-отдел и программистов от лишней работы.

Баланс в онлайн-шутере крайне важная штука. Нужно, чтобы геймплей нравился всем игрокам не было тех, кто не может вообще никого убить или, наоборот, тех, кто доминирует и фрустрирует всех остальных.

На первых годах жизни Pixel Gun 3D использовалась простая схема: весь контент добавлялся и редактировался вручную. Нужно поменять урон пушке? Заходишь в Unity, открываешь нужный файл и правишь руками. Дело на пару минут.

Потом индустрия начала переходить на freemium. От рынка отставать не стали и проект тоже изменил модель монетизации переработали экономику, прогрессию и многое другое, но сейчас не об этом. В результате DAU полетело вверх, а мы усиленно начали добавляли больше режимов, оружия, персонажей и так далее.

Проблемы начались, когда только оружия в каждой категории накопилось по 20-30 единиц, появились гибридные механики, а данных стало так много, что их уже невозможно было разобрать руками. Вместе с этим повысился порог входа в процессы для новых сотрудников только что пришедший в команду геймдизайнер не мог ориентироваться в контенте, так как банально не знал его на уровне названий.

Нужно было глобально что-то менять.

Сначала просто хотели сэкономить немного времени на балансировке контента, а в итоге автоматизировали большинство процессов, избавились от лишней ручной работы и разгрузили сотрудников. И все это с помощью гугл-таблиц.

Из гугл-таблиц в Unity

В первую очередь стали разбираться, как упростить работу с данными и можно ли их загружать в Unity из обычных гугл-таблиц. Оказалось, можно. Это был ключевой момент и первый шаг на пути к автоматизации назвали его удаленным контролем.

Для получения данных с таблиц мы используем Google Apps Script. Первое время заводили отдельные скрипты на каждую таблицу, в которых обрабатывали данные в JSON. Затем, получая в редакторе JSON, применяли их по назначению.

Сейчас пришли к тому, что опубликовали один скрипт. С его помощью получаем сырые данные с таблиц и уже в проекте конвертируем их в необходимый формат на С#. Этот подход более быстр и удобен.

Так выглядит наш скрипт:
function doGet(e){ if (e === undefined || e.parameter === undefined) {   return FailWithMessage("nullable parameters"); } var tableId = e.parameter["table"]; var listName = e.parameter["list"]; if (listName !== undefined && listName !== "" && listName !== "null") {   var startRow = parseInt(e.parameter["startRow"]);   var startColumn = parseInt(e.parameter["startColumn"]);   var numRow = parseInt(e.parameter["numRow"]);   var numColumn = parseInt(e.parameter["numCol"]);   return GetSigleList(tableId, listName, startRow, startColumn, numRow, numColumn); } else {   return GetAllTable(tableId); }}  function GetSigleList(tableId, listName, startRow, startColumn, numRow, numColumn){ var ss = SpreadsheetApp.openById(tableId); if (ss == null) {   return FailWithMessage("table with name: " + tableId + "not found"); } var sheet = ss.getSheetByName(listName); if (sheet == null) {   return FailWithMessage("list with name: " + listName + "not found"); }  if (numRow < 1) numRow = sheet.getLastRow(); if (numColumn < 1) numColumn = sheet.getLastColumn(); var range = sheet.getRange(startRow, startColumn, numRow, numColumn); var data = range.getValues(); var str = JSON.stringify(data);  var resultObject = {   "resultCode": 2,   "message": str }; var result = JSON.stringify(resultObject); return ContentService.createTextOutput(result);}  function GetAllTable(tableId){ var ss = SpreadsheetApp.openById(tableId); if (ss == null) {   return FailWithMessage("table with name: " + tableId + "not found"); }  var result = {};  var listModes = ss.getSheets(); for(var i = 0; i< listModes.length; i++) {   var sheet = listModes[i];   var sheetName = sheet.getSheetName();     var range = sheet.getRange(1, 1, sheet.getLastRow(), sheet.getLastColumn());   var data = range.getValues();   result[sheetName] = data; }  var str = JSON.stringify(result);  var resultObject = {   "resultCode": 2,   "message": str };  var result = JSON.stringify(resultObject); return ContentService.createTextOutput(result);} function FailWithMessage(message){ var result = {   "resultCode": 1,   "message": message };   var str = JSON.stringify(result);  return ContentService.createTextOutput(str);}

Для его использования необходимо создать новый скрипт, вставить содержимое из примера, опубликовать и в разрешениях указать, что запускать могут все, даже анонимные пользователи.

После публикации получится ссылка такого формата:

https://script.google.com/macros/s/WwlCZODTDRXJaHhdjfwFRcKtHRQOHqzYisjndduZzDihMpXehLrNxdi/exec

Ее нужно использовать для запуска скрипта. Чтобы скрипт знал, с какой таблицы нужны данные, в get-запрос подставляем ID таблицы. Получить его можно из URL таблицы. Например, в https://docs.google.com/spreadsheets/d/example_habr/edit#gid=0, ID будет example_habr.

Если нужно получить данные с конкретного листа, можно в запрос добавить его название тогда данные вернутся только по нему. То же самое и с диапазоном интересующих ячеек.

Полный запрос будет выглядеть так:

https://script.google.com/macros/s/WwlCZODTDRXJaHhdjfwFRcKtHRQOHqzYisjndduZzDihMpXehLrNxdi/exec?table=example_habr&list=MyList&startRow=1&startColumn=2&numRow=10&numCol=5

У Google есть ограничения на количество запросов и время выполнения. Поэтому нельзя использовать этот инструмент, например, для подтягивание конфигов напрямую в клиент у пользователей при превышении лимита скрипт начнет выдавать ошибку.

Теперь большинство параметров контента редактируется не внутри проекта, а во вне. Движок просто получает данные из таблицы в реальном времени. Например, нужно всем пушкам добавить 5 урона: вбиваем в ячейку, протягиваем по столбцу и нажимаем загрузить. Готово все данные ушли в клиент. По сути, мы с помощью нескольких гугл-таблиц управляем всей игрой.

Сейчас таких таблиц баланса уже много, все с закрытыми доступами на нужных специалистов. Отдельно по оружию, питомцам, гаджетам, экономике уровней и другим вещам. Но принцип работы один ничего не делается по отдельности руками на клиенте.

Но мы пошли дальше.

Из Unity в гугл-таблицы

Когда пользователь играет матч, вся статистика отправляется на наш сервер: по ID игрока в базу данных сохраняется, с какой пушкой он ходил, какие результаты показал и прочее. Таких необработанных данных очень много по каждому пользователю и единице контента: киллрейты, результаты матчей, частота взятие пушек и другое. Их мы давно использовали для аналитики но все было вручную, долго и сложно.

Почему бы не использовать таблицы не просто для загрузки данных в Unity, но и в обратную для обработки собираемой статистики и метрик или поиска проблемных мест? Да и вообще для генерации самого контента.

Начали с простеньких задачек. Например, мы часто превышали лимит в 500 символов на описание апдейта в Google Play. Стор такое отклоняет, нужно переписывать и отправлять заново. Задались вопросом, а есть ли формула для подсчета символов в ячейке? Разумеется, в гугл-таблицах большой перечень базовых формул, которые можно комбинировать как угодно и решать практически любые задачи. Написали в ячейке, чтобы описание апдейта автоматически проверялось на количество символов =ДЛСТР(номер ячейки). Теперь проблемы нет.

Гугл-таблицы закрывают большинство наших потребностей. Формулы состоят из простых операторов, но сочетания такие, что иногда не помещаются на экран 27-дюймового монитора. Есть отдельные специалисты, которые их составляют, знают разные фишки, специальные округления, сложные погрешности, выборки.

В гугл-таблицах огромное количество функций, ознакомиться со всеми можно на сайте саппорта Google.

Например, решили составить коллекции для галереи оружия (это такие подборки оружия по схожим признакам: цвет, сеттинг, сезон). Чтобы составить одну коллекцию, нужно оценить визуал, смотрятся ли они вместе, схожий ли у них класс и другие детали. Для этого сделали таблицу, в которую из базы данных выгрузили список всех пушек, написали формулу и подгрузили превьюшки, с которыми можно визуально работать. А уже из таблиц по балансу подтягиваем названия, теги и остальную информацию.

В результате получили таблицу, которую можно подгрузить в любую другую и взаимодействовать с пушками наглядно они автоматом подтягиваются по тегу. Например, по тегу Weapon970 сразу подгружается ее название, превью и так далее. С этим уже можно спокойно работать.

Еще пример. Решили поменять баланс дробовиков (скорострельность, дальность и так далее). Надо понимать, что механик много, а позиций еще больше. Каждую нужно учитывать в формулах в виде отдельных коэффициентов. Геймдизайнер не может зайти и перепечатать параметры руками их придется менять у каждого дробовика, которых может быть несколько десятков.

В формулах есть множество коэффициентов. Есть даже коэффициент крутости добавляем его, если, например, текстура пушки получилась особенно красивой. В таком подходе мы уже думаем через переменные, а не через частные случаи. Уже не хочется вручную переделывать руками 40 позиций, хочется иметь один коэффициент, который сделает все сам.

В итоге таблицы экономят колоссальное количество времени. На подготовку уйдет максимум пару часов (если совсем что-то нестандартное), зато потом можно ворочать огромным количеством данных или сущностей. Вручную те же задачи могут спокойно занять неделю.

Где используем автоматизацию

Мы применяем ее практически везде, где это возможно. И всегда ищем новые способы, чтобы сделать себе жизнь проще и переложить часть работы на формулы.

Балансировка контента

Самые базовый способ применения, о котором уже упоминали выше. Так мы ищем проблемные места, добавляем новый контент, не ломая старый, нерфим или бафаем оружие и так далее.

Если есть ошибка в балансе пушки, то апдейтим ее прямо на сервере, после того, как пересчитали в таблице. Такие правки стараемся переводить в формат удаленного контроля, чтобы не выпускать отдельные патчи в сторы.

Например, если на сервере не контролируется размер обоймы, а в коде добавили лишний нолик и у пулемета стало 50 тысяч патронов без патча такое не пофиксить. Пока он выйдет, пулемет купит большинство, баланс посыпется, появится куча негатива в соцсетях. Но если сделать это на сервере, то достаточно убрать одну цифру все наладится, а игроки даже не заметят. По максимуму вводить удаленный контроль очень хорошая практика.

Генерация сущностей

Автоматизацию можно использовать не только для баланса, но и для генерации нового контента. Так, в каждом батлпассе у нас есть порядка 140 разных челленджей (например, сыграть 10 игр в определенном режиме или убить 30 противников из пистолета). Каждый раз придумывать это вручную долго и нудно, поэтому сделали генерацию. Собрали подробный список условий и прямо из гугл-таблицы создаем квесты теперь одна формула придумывает нам все задачи на каждый сезон.

Естественно, со сгенерированным пулом работает уже человек и настраивает кривую сложности. Игрок должен плавно войти в ивент, тем самым повысив конвертацию в платеж или в более длинную игровую сессию.

Подобным образом мы генерируем задачи и для клановых войн.

Пример формулы:

=ifs(I2="EndMatch";ifs(AE2<=TasksData!$O$34+TasksData!$N$34;"TeamDuel";AE2<=TasksData!$O$34+TasksData!$N$34+TasksData!$M$34;ЕСЛИ(A2=0;"TeamDuel";"Spleef");AE2<=TasksData!$O$34+TasksData!$N$34+TasksData!$M$34+TasksData!$L$34;"Duel";AE2<=TasksData!$O$34+TasksData!$N$34+TasksData!$M$34+TasksData!$L$34+TasksData!$K$34;ЕСЛИ(A2=0;"Duel";"BattleRoyale");AE2<=TasksData!$O$34+TasksData!$N$34+TasksData!$M$34+TasksData!$L$34+TasksData!$K$34+TasksData!$J$34;ЕСЛИ(A2=0;"TeamFight";"DeadlyGames");AE2<=TasksData!$O$34+TasksData!$N$34+TasksData!$M$34+TasksData!$L$34+TasksData!$K$34+TasksData!$J$34+TasksData!$I$34;"CapturePoints";AE2<=TasksData!$O$34+TasksData!$N$34+TasksData!$M$34+TasksData!$L$34+TasksData!$K$34+TasksData!$J$34+TasksData!$I$34+TasksData!$H$34;"FlagCapture";AE2<=TasksData!$O$34+TasksData!$N$34+TasksData!$M$34+TasksData!$L$34+TasksData!$K$34+TasksData!$J$34+TasksData!$I$34+TasksData!$H$34+TasksData!$G$34;"Deathmatch";AE2>TasksData!$O$34+TasksData!$N$34+TasksData!$M$34+TasksData!$L$34+TasksData!$K$34+TasksData!$J$34+TasksData!$I$34+TasksData!$H$34+TasksData!$G$34;"TeamFight"); I2="killPlayer";ifs(AE2<=TasksData!$N$35;"TeamDuel";AE2<=TasksData!$N$35+TasksData!$L$35;"Duel";AE2<=TasksData!$N$35+TasksData!$L$35+TasksData!$K$35;ЕСЛИ(A2=0;"TeamFight";"BattleRoyale");AE2<=TasksData!$N$35+TasksData!$L$35+TasksData!$K$35+TasksData!$J$35;"DeadlyGames";AE2<=TasksData!$N$35+TasksData!$L$35+TasksData!$K$35+TasksData!$J$35+TasksData!$I$35;"CapturePoints";AE2<=TasksData!$N$35+TasksData!$L$35+TasksData!$K$35+TasksData!$J$35+TasksData!$I$35+TasksData!$H$35;"FlagCapture";AE2<=TasksData!$N$35+TasksData!$L$35+TasksData!$K$35+TasksData!$J$35+TasksData!$I$35+TasksData!$H$35+TasksData!$G$35;"Deathmatch";AE2>TasksData!$N$35+TasksData!$L$35+TasksData!$K$35+TasksData!$J$35+TasksData!$I$35+TasksData!$H$35+TasksData!$G$35;"TeamFight"); I2="killPet";ifs(AE2<=TasksData!$G$36;"Deathmatch";AE2>TasksData!$G$36;"TeamFight"); I2="killPlayerThroughWall";ifs(AE2<=TasksData!$I$37;"CapturePoints";AE2<=TasksData!$I$37+TasksData!$H$37;"FlagCapture";AE2<=TasksData!$I$37+TasksData!$H$37+TasksData!$G$37;"Deathmatch";AE2>TasksData!$I$37+TasksData!$H$37+TasksData!$G$37;"TeamFight"); I2="killPlayerFlying";ifs(AE2<=TasksData!$I$38;"CapturePoints";AE2<=TasksData!$I$38+TasksData!$H$38;"FlagCapture";AE2<=TasksData!$I$38+TasksData!$H$38+TasksData!$G$38;"Deathmatch";AE2>TasksData!$I$38+TasksData!$H$38+TasksData!$G$38;"TeamFight");I2="ramEscort";"Siege";I2="escortDestroyGate";"Siege";I2="winBrNoChest";"BattleRoyale";I2="crashChest";"BattleRoyale";I2="winBrInParty";"BattleRoyale";I2="flagCapture";"FlagCapture";I2="pointCapture";"CapturePoints")

Пример таблицы с вводными для генератора:

Пример формулы (в ней представлена часть с генерацией описаний задач, Key_номер это ключи локализаций, из которых составляются задачи):

=IFS(I2="endMatch";(ЕСЛИ(T2=0;"Key_7220";"Key_7234"));I2="killPet";ЕСЛИ(W2="None";"Key_7228";"Key_7224");I2="killPlayer";ЕСЛИ(Q2=1;"Key_7227";(ЕСЛИ(W2="NONE";ЕСЛИ(R2=1;"Key_7232";ЕСЛИ(S2=1;"Key_7233";"Key_7221"));"Key_7216")));I2="killPlayerFlying";"Key_7225";I2="killPlayerThroughWall";"Key_7226";I2="ramEscort";"Key_7235";I2="escortDestroyGate";"Key_7236";I2="winBrNoChest";"Key_7229";I2="crashChest";"Key_7230";I2="winBrInParty";"Key_7231";I2="flagCapture";"Key_7237";I2="pointCapture";"Key_7238";I2="";"")

И еще более эпичная, уже проходящая через ячейки параметров и рандомайзеров:

=ifs(L3="DeadlyGames";0;L3="BattleRoyale";0;L3="TeamDuel";0;1=1;ЕСЛИ(I3="killPlayer";ifs(A3=0;ЕСЛИ(СЧЁТЕСЛИ($I$2:I2;"killPlayer")>=(TasksData!$B$34+TasksData!$B$36+TasksData!$B$38)*6;ЕСЛИ(СЧЁТЕСЛИ($I$2:I2;"killPlayer")<(TasksData!$B$34+TasksData!$B$36+TasksData!$B$38+TasksData!$B$47)*6;1;0);0);A3=1;ЕСЛИ(СЧЁТЕСЛИ($I$2:I2;"killPlayer")>=(TasksData!$B$34+TasksData!$B$36+TasksData!$B$38+TasksData!$B$47+TasksData!$B$48+TasksData!$C$34+TasksData!$C$36+TasksData!$C$38)*6;ЕСЛИ(СЧЁТЕСЛИ($I$2:I2;"killPlayer")<(TasksData!$B$34+TasksData!$B$36+TasksData!$B$38+TasksData!$C$34+TasksData!$C$36+TasksData!$C$38+TasksData!$B$47+TasksData!$B$48+TasksData!$C$47)*6;1;0);0);A3=2;ЕСЛИ(СЧЁТЕСЛИ($I$2:I2;"killPlayer")>=(TasksData!$B$34+TasksData!$B$36+TasksData!$B$38+TasksData!$B$47+TasksData!$B$48+TasksData!$C$34+TasksData!$C$36+TasksData!$C$38+TasksData!$C$47+TasksData!$C$48+TasksData!$D$34+TasksData!$D$36+TasksData!$D$38)*6;ЕСЛИ(СЧЁТЕСЛИ($I$2:I2;"killPlayer")<(TasksData!$B$34+TasksData!$B$36+TasksData!$B$38+TasksData!$B$48+TasksData!$C$34+TasksData!$C$36+TasksData!$C$38+TasksData!$D$34+TasksData!$D$36+TasksData!$D$38+TasksData!$B$47+TasksData!$C$47+TasksData!$C$48+TasksData!$D$47)*6;1;0);0));0))

Симуляция процессов

Другой пример. Добавляем в игру сундук с предметами: игрок открывает и получает приз. У сундука есть множество правил, как и что будет выпадать. Можно написать код и отдать QA-отделу, чтобы это проверить, но есть способ лучше. Прямо в гугл-таблице делаем симулятор дропа: вносим правила, условия, открываем 1000 сундуков и корректируем всю модель под нужный исход. Для этого не нужен ни код, ни программист достаточно таблицы и самой концепции.

Пример части вводных данных:

Пример использованных формул в ячейках:

=СЛУЧМЕЖДУ(1;100)
=СРЗНАЧ(13;15)*6
=СУММ(B4:F4)
=IFS($A32<=G32;"Mythic";$A32<=F32;"Legend";$A32<=E32;"Epic";$A32<=D32;"Rare";$A32<=C32;"Common")

Сами по себе формулы простые, но при правильном построении связей ячеек и порядка выполнения действий получается нужный результат.

Пример результатов дропа по номерам открытий:

Разумеется, в самом проекте все пишет программист, но проверить это можно заранее. По сути все, что есть в игре, можно симулировать в таблице. И если результаты устраивают передавать в разработку.

Воркфлоу создания таблицы

Рассказать, как именно происходит работа с данными и создание таблиц, лучше всего на примере. Допустим, мы решили выяснить, какие пушки сейчас самые популярные в игре. А для этого нужно подтянуть множество дополнительных данных.

Расскажу подробнее по шагам (цифры в примере изменены в рамках конфиденциальности):

Эти же данные можно брать из таблицы баланса. Разница в том, что таблица баланса дает актуальные параметры (и не дает метрики), а на сервере информация хранится с пометкой даты ее можно выгрузить за нужный период (и вместе с метриками).

2. Затем создается гугл-таблица, в которой будет происходить основная работа. И в нее загружается полученный CSV-файл.

3. Для удобства из другой таблицы с помощью формулы подтягиваются картинки пушек. Арты предварительно загружены на сервис для получения прямой ссылки в формате (важно именно расширение в конце ссылки):

http://адрес_сервиса/путь/номер/имя картинки.jpg

Для добавления в таблицу используем простую функцию:

=IMAGE("https://files.fm/u/wdrhemgnk#/view/special_offer_pixelman_reward_big.png")

Пример формулы для подтягивания артов с перебором:

=ЕСЛИ(ЕНД(ВПР(A4;importrange(имя_таблицы;Лист1!B:F);5;ЛОЖЬ))=ЛОЖЬ;ВПР(A4;importrange(имя_таблицы;Лист1!B:F);5;ЛОЖЬ); ЕСЛИ(ЕНД(ВПР(A4;importrange(имя_таблицы;Лист1!C:F);4;ЛОЖЬ))=ЛОЖЬ;ВПР(A4;importrange(имя_таблицы;Лист1!C:F);4;ЛОЖЬ); ЕСЛИ(ЕНД(ВПР(A4;importrange(имя_таблицы;Лист1!D:F);3;ЛОЖЬ))=ЛОЖЬ;ВПР(A4;importrange(имя_таблицы;Лист1!D:F);3;ЛОЖЬ); ЕСЛИ(ЕНД(ВПР(A4;importrange(имя_таблицы;Лист1!E:F);2;ЛОЖЬ))=ЛОЖЬ;ВПР(A4;importrange(имя_таблицы;Лист1!E:F);2;ЛОЖЬ);НИМА ТАКОГО))))

Теперь можно работать не с абстрактными строками, а наглядно. Если пушек 30 штук, можно зайти в игру и посмотреть, но когда их 700 так уже не сделаешь.

Важный момент: после подгрузки данных мы их вырезаем (ctrl+x) и вставляем без привязки к формуле (ctrl+x+v). Формулу затем удаляем, иначе после каждого обновления страницы она будет пересчитывать все строки. В данном случае более 800.

Далее одну базу можно использовать для всех задач, где требуется отображение картинок оружия.

4. При желании можно выгрузить название пушки в игровом магазине (а также все необходимые для задачи параметры, например, дополнительные свойства).

5. Также используем форматирование ячеек. Оно может выполнить множество полезных преобразований. Например, покрасить ячейки, в которых значение больше 2 или меньше 1.

В применении к данным о киллрейте пушки (соотношение числа убийств из пушки к смертям игрока с ней) видно превышение обозначенного предела, а также низкие значения, которые явно являются поводом передать эти данные в отдел балансирования.

6. Добавляем столбец с категориями оружия (у нас их 6) и прибегая к тому же условному форматированию красим каждый в свой цвет. Стало видно, что в топе нет пушек категории Special, что уже наталкивает на анализ механик этой категории оружия.

В итоге, чтобы собрать такую таблицу с категориями, свойствами, превью и прочим пришлось вытащить эту информацию из нескольких разных мест. И на это ушло около 15 минут, а не весь день. Так как формулы операций типовые, а таблицы с рендерами и данными есть уже готовые.

Теперь можно сортировать, строить графики, добавлять продажи или другую информацию, чтобы быстро и обоснованно сделать нужные выводы или проверить теории.

Для наглядности на основе данных можно построить и график. Делается это через простую операцию добавления: добавить диаграмма (сразу можно выделить нужный диапазон ячеек).

График популярности оружияГрафик популярности оружия

Жизнь после автоматизации

На самом деле сплошные профиты. Проблемы дисбаланса значительно сократились, стало проще следить за контентом и предугадывать возможные проблемы, потому что общая картина всегда перед глазами, а проблемные места подсвечиваются.

Теперь легче что-то поменять, перезалить или вообще обновить целый класс оружия, в котором 100+ позиций. Достаточно вбить новые параметры все автоматически и с учетом механик пересчитается под норму (а часть параметров пересчитаются сами под новые вводные).

Мы избавились от мелкого ручного менеджмента, освободили время сотрудников для более интересных задач, сняли дополнительную нагрузку на технический отдел и теперь программисты не отвлекаются от написания кода. И что еще важно новички в команде теперь легко вливаются в процессы и намного быстрее разбираются с проектом на реальных задачах.

Переход к автоматизации непрерывный эволюционный процесс, и во многом непаханное поле. Теперь постоянно думаем, как оптимизировать ресурсы и упростить задачи, пробуем новые варианты, формулы и всегда ищем более удобные решения. Например, сейчас работаем над добавлением всех этих процессов прямо в админку.

P.S. Данный подход меняет сам принцип работы с различными инструментами. Например, в том же Slack можно видеть BB-коды наглядно с помощью простой команды #:

Полезные ссылки

Подробнее..

Игра, стоившая мне рассудка Китайская трещотка

15.06.2021 18:13:51 | Автор: admin

Хабр, у меня от тебя нет секретов.

В первой части своего пока-что-трехстатейного цикла я хочу поделиться геймдизайн-паттерном моего собственного изобретения, который, я надеюсь, поможет начинающим игроделам исполнить свою мечту. Но даже если вы никоим образом не относитесь к геймдеву, полагаю, мне удастся вас как минимум удивить. В хорошую или в плохую сторону - этого мне не дано знать - я о биполярности доброго и худого хотя и написал уже в будущей статье, поведать пока еще только надеюсь.

Моя граничащая с безумием уверенность в том, что материал вообще оглашать стоит вызвана, в первую очередь, тем, что я уже публиковался на ваш суд однажды, шесть лет тому назад, и тот мой опыт, мягко говоря, удался. По крайней мере в моих собственных глазах. С другой стороны, свое дерзновение я могу оправдать в том числе и тем, что я полтора года назад и правда сошел с ума вплоть до медикаментозного вмешательства, доковырявшись-таки до грани со своей выдуманной игрой, которую писал. Хотите послушать историю никому не известного программиста о мирах, лежащих за стеной здравомыслия?

Прежде чем вы окончательно решите для себя - дать ли шанс мне все рассказать вам по порядку - позвольте напоследок задать всего один вопрос. Какие три цвета являются образующими и позволяют получить любой оттенок палитры? После того как я произнесу ответ, часть из вас согласно кивнет, большая же половина воззрится на меня с недоумением, а заодно с недоверием глянет и на тех, кто окажется со мной согласен. Эти цвета: красный, синий и... желтый.


Однажды -
Только ты повеpь -
Маятник качнется в пpавильную стоpону
И вpемени больше не будет.

01 - Гражданская Оборона - Солнцеворот.mp3

Ищущим правильного ответа на просторах сети я сразу рекомендую набрать "основные цвета в рисовании" и испытать когнитивный диссонанс, который испытал когда-то и я. Кивнуть в знак согласия со мной был шанс лишь у тех, кто либо ну очень хорошо слушал учителя по рисованию в первом классе, либо закончил художественную школу. Когда я впервые сам узнал об этом парадоксе, пытаясь оседлать самоучитель по рисованию для детей (мы ведь все должны развиваться прежде всего в тех областях, где меньше всего что-либо из себя представляем, не так ли?), изумлению моему не было предела. Причем самым поразительным для меня оказалось то, что это было не какое-нибудь ортогональное смещение привычного RGB на желтый, фиолетовый и любой другой еще, а настоящий удар под дых - два цвета были правильными, а один - нет. Однако в конце концов через тернии многочисленных попыток я нашел-таки ключ к этой несостыковке и обязательно поделюсь им с вами, но, уж простите, не сейчас. Сейчас лишь намекну, вдруг вы сами хотите сделать для себя это открытие. Все дело в точке отсчета.

От ее выбора часто зависит куда больше, чем кажется нам на первый взгляд. Помните школьные задачки по физике на сохранение потенциальной и кинетической энергии в замкнутой системе? Ну, те, в которых предмет изначально находится на определенной высоте и если за начало вертикальной координаты принять уровень земли, то тело по умолчанию обладает потенциальной энергией, если же нулем выбрать его стартовую вертикальную позицию - то нет. Если не помните, придется поверить мне на слово - такие задачи есть. Разумеется, в этих упражнениях сделанный выбор на решение никак не влияет - ответ остается тем же. Хотя если так по совести-то разобраться, то как так? Асимметричная же ситуация складывается: в одном случае на то, чтобы упасть на землю, у тела в запасе нет энергии вовсе, а чуть по-другому взгляни - есть еще как.

Так вот всем нам кажется, что у любого дела есть всего две точки отсчета - начало и конец. Давайте назовем их нулем и единицей. И для того, чтобы, скажем, выпустить собственную игру, нужно выйти из нуля и идти, идти, идти, наращивать с каждым шагом по одной сотой выполнения поставленной перед собой задачи, по одной тысячной, каждый раз превозмогая себя, чтобы наконец прийти в эту самую единицу, где игра закончена. На самом деле это не так. Ну то есть вы можете думать, что так, это тоже верно, но как по мне - это сильное упрощение, я вижу ситуацию иначе. На самом деле для того, чтобы выпустить свою игру, достаточно сделать всего один шаг. Любой. Позвольте я попытаюсь вам это доказать, пусть даже и безуспешно.

Видите ли, точек отсчета на самом деле не две, их три. Вы, возможно, уже догадались, что у нуля есть еще один антагонист кроме единицы - это бесконечность. Все три этих позиции ключевыми в каждом деле и являются. Причем с точки зрения чистой математики промежуток между первыми двумя величинами - нулем и единицей - обладает одним характерным свойством: если многократно умножать какое бы то ни было число на значение любой точки этого отрезка, вы будете в результате приближаться к нулю, скатываться обратно. Стоит же вам перейти через правый рубеж данного интервала и вот уже умножение будет работать на вас, устремляя значение произведения в бесконечность. Как вы понимаете, в деле, в котором ноль - это начало, а бесконечность - (никогда не достижимый) конец, единица играет роль не более чем масштаба. Собственно, поэтому какой именно шаг выбрать в качестве того единственного, первого, который и позволит вам успешно выпустить свою игру - на самом деле не имеет никакого значения. Даже, пожалуй, чем меньше он будет - тем лучше. Хотя, может и нет. Вот, собственно, и вся моя идея.

Вы знаете как сходят с ума?

Я не сказать, что прямо таки жаждал этот опыт освоить, но коль скоро однажды на какое-то время по ту сторону стены здравого рассудка оказался, позвольте мне побыть для вас странствующим бардом и рассказать что происходит там, за стеной. Когда человек впервые сталкивается с так называемым "психозом", он сам не способен этого понять. Его мозг не может без посторонней помощи диагностировать, что сломался. Уж не знаю какими try/catch там все в сознании обернуто, но абсолютно любая идея, которая приходит в этот момент бедняге в голову, тут же становится для него истиной. Можете сами почитать, это называется "отключение критического мышления". Представьте на секунду, что весь невообразимый сонм if'ов в вашем мировоззрении переключился намертво в положение true. Мне в этот момент повезло спалить только процессор, жесткий диск до самого последнего момента усердно фиксировал все происходящее, поэтому и сейчас я помню если не каждую свою мысль, то уж все свои логические построения точно. В общей сложности я бился в душевном припадке около пяти дней, так что передумать и поверить я успел очень многое и почти во все.

Поначалу идеи похожи на редкие капли, падающие в колодец сознания - кап, кап, кап. Вопросом возникновения мыслей и их ловлей на этапе зарождения занимается, если что, буддизм. Потом все чаще, одна за другой, мысли начинают приходить к тебе в голову все быстрей, причем порой в наибсурднейшей форме, но их адекватность ты уже не способен оценить, каждая принимается за аксиому. Частота увеличивается, напор становится все более и более бурным, к тому же уже полученные "знания" никуда не исчезают из оперативной памяти болезненного рассудка, они как шарики в арканоиде, у которого запечатали пропасть снизу, отражаются от стенок сознания и возвращаются в игровое поле, бодаясь там с новыми и новыми идеями, коих поток и так, сам по себе, грозит вот-вот перегреть биологический процессор ума. Мысли наползают друг на друга, сталкиваются, отталкиваются, слипаются, схватываясь в диковинные симбиозы. Тут тебе и видео, которым ты не управляешь, и концепции, сопоставлять которые ты бы в жизни не додумался, и даже "откровения" о том как этот мир устроен на случай, если ты захочешь что-нибудь эдакое новое изобрести. Короче, как вы понимаете, при таком обильном выборе я обещаю, что не буду натирать вам сознание банальными атомарными идеями типа "точка на плоскости листа бумаги - это на самом деле прямая, перпендикулярная поверхности этого листа". Последовавший за этой вспышкой месяц, проведенный среди таких же гениев, как и я, обошелся без пустых переливаний из пустого в порожнее с соседями по палате, я лежал и методично перебирал весь накопленный мною энтропийный архив всевозможных сочетаний мыслей, стараясь расплести целиком нагроможденную кипу мутировавших в моем уме понятий и оставить только действительно стоящие и более или менее адекватные на мой взгляд экземпляры, в беспристрастности которых я, тем не менее, сомневаюсь до сих пор. Я потому, собственно, их вам и принес. Я и в процессе пытался достучаться до Хабра, как заправской Эйнштейн, но что-то меня не поняли (ну надо же!) и по паре фраз, брошенных мною нехотя, гения во мне не признали.

Эта история начинается с того, что я читал книгу "Искусство геймдизайна" Джесси Шелла. Автор в конце своего труда просил передавать ему всяческие приветы, так что, мистер Шелл, здравствуйте, мой Вам большой привет. Спасибо за книгу, я прочитал ее почти что на одном дыхании. "Почти что" потому что... ну вы поняли. Реальность начала искажаться в момент прочтения 28ой главы, в которой новоиспеченным игроделам предлагается поработать над презентацией их игры. Автор этой без сомнения потрясающей книги, будучи чистым геймдизайнером без художественных и технических отклонений, говорит о привлечении внимания инвестора к будущему, еще не начатому проекту. Мне же, инди-разработчику, мечтающему о полной, в том числе финансовой, независимости производства, было куда интереснее создать материал, стимулирующий интерес широкой общественности к уже готовому и выпущенному релизу. Как нельзя кстати пришелся к месту и такой термин как "Речь в лифте" - паттерн проектирования монолога, позволяющий наточить выдающиеся грани описания вашего детища до состояния японской катаны, разрезающей, как известно, шелк на лету.

И вот еду я в лифте с Биллом Гейтсом. Рассказываю ему такой, рассказываю про свою игру, вижу, что он проникается, глаза его начинают гореть, не дослушав и половины, он восклицает: "Отлично! Великолепно! Куда надо нажать? Где можно скачать?" А я ему такой: "Я Вам не скажу". Он: "Почему?" А я ему: "Так мы же с Вами не в "Я пиарюсь".

Готовя план продвижения еще не выпущенной игры, я зашел как-то на Reddit, чтобы поискать там соответствующие мобильному геймдеву сообщества, и в своих изысканиях накликал себе несколько вкладок. Сперва прошелся по более мелким из их числа, в самом конце открыл наиболее крупное, судя по количеству подписчиков, коммьюнити. И вижу вдруг краем глаза на этой странице табличку такую всплывшую. Не глядя на нее, думаю: "Ну, понятно, наверное предупреждение, мол, "Осторожно, тут много людей, не флудите, премодерация, вход только с высокой кармой". Перевожу на нее взгляд и брови мои медленно начинают ползти вверх, там написано: "Это сообщество насчитывает более N тысяч участников, начните новый тред и вы наверняка найдете себе среди них собеседников".

Привыкший к тому, что с трибуны говорить надо строго по делу, а лучше и не говорить вовсе, я был, мягко говоря, озадачен таким подталкиванием в совершенно противоположном направлении. Подумал: "Серьезно? То есть хоть кто-нибудь, да прочитает все, что я напишу?" Я, признаться, эту-то статью создавал так: зафиксировал текстом все, чем хотел поделиться, затем попытался (безуспешно) сжать каждый абзац до одного предложения, чтобы суть был концентрированная, как у Ницше (хотя куда мне), а тут - на тебе - такое приглашение.

Хабр тогда активно выходил на англоязычную платформу, вслед за первым роликом спустя некоторое время в моем мысленном телеэфире начали крутить другой видеоряд, похожий, но с иной концовкой, как это сейчас бывает принято в сфере рекламного дизайна. В этом видео парень рассказывает своей девушке эту же историю, говорит: "Еду я в лифте с Биллом Гейтсом, рассказываю ему про свою недавно выпущенную игру, рассказываю, вижу он заинтересовался, кивает одобрительно. Наконец закончил я перечислять достоинства релиза и говорю ему: "Но ссылку я Вам, разумеется, не покажу". Повисает пауза, девушка делает огромные удивленные глаза и спрашивает: "А он чего?" На что парень отвечает: "А он так хмыкнул и говорит: "Правильно, ты же не в "Я пиарюсь".

Надо понимать, что устная и письменная речь сильно отличаются друг от друга.

Для устной речи нужно время. В письменной речи времени нет. В тот момент когда труд закончен, пост отправлен или конверт с письмом запечатан, все события этого текста происходят одновременно: у истории уже детерминированный конец, финал свершился и неважно дойдет до него читатель или нет - история от этого никак не изменится. Если бы в нашей системе отсчета был один только ноль, он не имел бы никакого смысла - без единицы и тем более без бесконечности, это просто точка, ничего не значащая и бесконечно мало стоящая. Такая точка на шкале времени называется, как вы знаете, "моментом".

Так вот представьте, что вы едете в лифте со всем Хабром. У вас есть, скажем, 12 секунд. Но из-за того, что Хабр письменный, на самом деле вам достаточно будет и одной. И неважно как долго вы будете к этому моменту готовиться, Хабр будет стоять и ждать вас, продолжая делить с вами кабину, окруженную едущей шахтой. В тот же момент когда пост будет опубликован, ось t исчезнет, событие свершится, вы либо за эту бесконечно малую величину времени убедите всех в том, что ваша игра - шедевр, либо нет. Но, знаете, учитывая эту особенность письменной формы повествования, я бы воспользовался мнимо единственной единицей вашего внимания так же, как первым и последним запросом, гарантированно исполняемым с помощью волшебства джинном. Попросил бы еще желаний, выпалил бы: "Хабр, позволь я поведаю тебе о своей игре за 12 секунд. Первой я хочу воспользоваться так же, как и нулевой, а за вторую рассказать тебе о..." и далее по тексту. Ваша история может длиться хоть вечность, было бы лишь вам что повествовать. И точно так же, как одну-единственную секунду можно развернуть аж в целых 12, пусть и немного схитрив в кратковременное течение ее, не возбраняется делать и наоборот: долгие годы труда сворачивать в один-единственный момент - момент публикации.

А знаете что на самом деле я бы сказал Биллу Гейтсу, если бы оказался с ним в одном лифте? Я бы сказал: "Билл Гейтс, сэр, помните Вашу книгу "Дорога в будущее", которую Вы опубликовали в 1995 году? У вас там есть глава про положительно и отрицательно раскручивающиеся спирали. Так вот, сэр, Вы используете неправильную терминологию. Эти спирали называются системами с положительной и отрицательной обратной связью, мы их в МЭИ на ТАУ проходили".

Я поясню на всякий случай о чем идет речь. Десятый и одиннадцатый класс я учился в лицее 1502 при МЭИ (Владимир Львович, здрасьте). До последнего моего учебного года в нем, это образовательное учреждение имело одну любопытную преференцию - его выпускные экзамены считались вступительными в МЭИ. То есть итоговые работы писались в родных стенах, под надзором привычных и ни капельки не страшных уже преподов, а результат считался как полноценно заполненные твоими каракулями листы, содержимое которых было натужно извергнуто в чужеродных аудиториях под контролем незнакомых, демонических в своей неопределенной строгости педагогов. Это на выходе.
На входе же, при наборе в лицей, были вступительные экзамены - просто перевестись в него из обыкновенной школы было нельзя. Но для тех, кто очень хотел поступить, существовал межшкольный факультатив (МШФ) - платные вечерние занятия, на которых за деньги его родителей любого желающего готовы были натаскивать по экзаменационным предметам, было бы лишь у него желание учиться. Разумеется, поступали и те, кто на МШФ не ходил. И, разумеется, не все, кто посещал МШФ, - поступали.
В середине же этой цепочки, во время учебы, был Супермарафон - ежегодная серия творческих и интеллектуальных конкурсов, а также спортивных состязаний. Соревновались между собой все без исключения классы - с 9ых по 11ые, у мероприятия был общелицейский масштаб, длилось оно почти полгода - весь второй семестр. Победители классом ехали за границу, второе место - куда-то по России, третье - экскурсия где-нибудь в Москве. Все это за счет лицея. Ну и там компьютерные классы, спортзалы, мебель, преподавательский состав.

Так вот как это работало: родители абитуриентов вливали деньги через МШФ, эти средства шли на все вышеперечисленное (то, что в середине), престиж лицея от этого поднимался и на следующий год желающих поступить было уже больше, денег, соответственно, - тоже, они снова бросались на развитие лицея и так по кругу.

И надо же было такому случиться, что именно в год моего выпуска уговор с МЭИ отменили. Теперь ты должен был отдельно писать выпускные экзамены в лицее, а отдельно - ехать в институт и сдавать там вступительные, наравне со всеми остальными. Но я помню как Чудов, желая успокоить общественность, выступил с заявлением, сказав, что "какие-нибудь преференции все равно будут". "Может быть на балл больше всем лицеистам", "может еще что".
"Я сделаю все, - сказал наш директор. - Чтобы, при прочих равных условиях, из двух абитуриентов, один из которых закончил пятнадцать-ноль-два, а другой - нет, комиссия зачисляла именно наших лицеистов".
Престиж лицея удалось спасти. Положительно разворачивающаяся спираль не развернулась в отрицательную. Я знаю это потому что через пару лет "пятнадцать-ноль-два" отстроил себе на своей территории собственный бассейн. А ведь могло случиться и так, что из-за отмены одного-единственного преимущества, на МШФ в будущем пришло бы меньше народу, в результате чего что-нибудь в середине пришлось бы урезать, престиж бы упал, на следующий год школьников, желающих поступить, оказалось бы еще меньше, а дальше по цепочке ситуация начала бы скатываться к нулю.

(Автор, все уже почти забыли в чем там изначально суть была-то)

Как вы понимаете, эта положительная и отрицательная обратные связи вопрос лишь того оказываетесь ли вы справа от единицы в нашей трехточечной системе координат, либо же - слева. В первом случае вы неизбежно попадаете в бесконечность, во втором - бесконечно стремитесь к нулю. Как сделать так, чтобы ваш шаг на пути к выпуску игры имел положительную обратную связь? Я позволю себе, не поднимая руки, с места ответить: на самом деле любое, даже бесконечно малое ваше действие имеет ее в самой своей сути - эту самую положительную с событиями будущего обратную связь. Так уж устроено (по крайней мере хотя бы на мой взгляд) мироздание.

Те, кто читал мою дебютную статью на Хабре "Семь итераций наивности...", возможно, помнят, что там в повествовании, ближе к концу, наступает такой момент, когда я говорю "Однако чем ближе был релиз, тем меньше мне требовалось моральных сил на то, чтобы закончить. Проект набрал вес и как снежный ком чуть ли не сам по себе катился к выпуску. Его по-прежнему надо было каждый вечер толкать, но выпуск был просто неизбежен."
Попрощаемся сразу с теми, кто, как и я, любит изучить явление с самых предтеч и сейчас ушел эту самую мою статью с самого-пресамого начала читать. Они к нам не скоро вернутся, уж поверьте. Да, тот проект в какой-то момент набрал такую критическую массу, что совокупная обратная связь всех предыдущих шагов начала сама меня толкать садиться каждый день за работу над игрой. Но наша задача - получить этот эффект от всего-навсего одного-единственного, наименьшего шага. Для этого нам и понадобится обещанный мною вам про равноправие RGB и RYB ключ.

Я долгое время бился над этим вопросом в своей голове так и сяк, рассматривал градиент всех цветов на мониторе в виде квадрата и круга. Но в итоге решение оказалось до ужаса простым: чтобы увидеть нужную картину, достаточно было всего лишь передвинуть все три ползунка, отвечающих за один базовый цвет каждый, максимально вправо. Произведя эту нехитрую операцию, вы обнаружите, что шкалы теперь такие: желтая, розовая и голубая. Просто мы привыкли к тому, что #000000 - это черный, а #FFFFFF - это белый. Стоит же принять за точку отсчета полную противоположность, как, глядите ка, все встает на свои места - сотни поколений художников не могли ошибаться. Просто мы пляшем от черного монитора, а живопись - от белого листа.

Так же и с выбором нуля потенциальной энергии: при одном и том же результате (предмет в конце концов упадет на землю) в одном случае у тела есть изначальный заряд совершить это движение в конечную точку с течением времени, в другом - предполагая умозрительно итог - мы толкаемся от того, что событие это уже произошло, свершилось. И, да, самое логичное тут предположить, что - в проекции на нашу ситуацию - мы на старте находимся в единице, где есть горы желания и нет совершенно пока еще никакого выполненного в реальности действия, а приходим в итоге в ноль, в котором теперь объективно существует орда кода и графики, а делать больше нечего от слова "совсем". Но это как-то ситуацию не спасает, не находите? К тому же в этом случае по мере приближения к финалу делать что-либо хотелось бы все меньше и меньше, а это не так. Все дело в том, что система-то у нас трехточечная, поэтому и отрицание надо понимать не буквально, а избирательно - на свой вкус - лишь бы все в итоге получилось.

В тот момент, когда вы делаете первый шаг, вы оказываетесь не в единице, а в минус единице. Но шагаете вы при этом не из нуля. Позади вас минус бесконечность - это вся ваша предыдущая жизнь, из которой вы только что на оси разработки материализовались. А впереди - ноль - это момент выпуска вашего продукта. Расстояние до нуля из вашей минус единицы не так важно, главное в этой величине вовсе не объем, а одно-единственное свойство - оно конечно. Как только в объективной реальности было произведено инициализирующее процесс разработки действие, вы оказались на отрезке между -1 и 0 (чуть-чуть правее левой границы интервала) и теперь выпуск игры неизбежен, ведь вы скатываетесь в точку публикации сами собой. Вам осталось всего лишь плыть по течению в этом направлении. То, что по игре не сделано еще практически ничего превращается в то, что она уже готова. И открою вам секрет, ваша игра и вправду уже написана, нарисована и даже выпущена. В будущем. Или в вашей голове. Зависит от вашей точки зрения на всю эту ситуацию.

Чем меньше шаг в изначальной системе координат, тем больше он при отрицании - всем известно, что самое сложное - начать. Положительная обратная связь от этого действия вроде как вообще стремится к нулю; переворачиваем - стремится к бесконечности. И это действительно так, ведь, как я уже сказал, желания у вас на первых порах хоть отбавляй. Так вот расслабьтесь, игра уже выпущена. Если вы решились хоть на одно действие, вам теперь не отвертеться. Остается только максимально четко представить себе этот момент - момент явления вашей игры общественности - и с честью и мнимой горечью принять тот факт, что ноль в вашей системе координат существует: рано или поздно публикация произойдет.

Так ничего и не написалось?

Ну что ж, значит не было у вас никогда никакого нуля даже в мыслях. Или же релиз изначально был подспудно назначен вами куда-то в бесконечность во времени, вы не пользовались положительной обратной связью своих шагов на пути к мечте, разрывали день за днем установленный коннект с моментом публикации (кстати, все еще продолжаете разрывать), сопротивлялись изо всех сил желанию делать игру дальше, не позволили потоку собственной мотивации самому собой, без пинков, нести вас к выпуску игры. Выбрали не ту реальность. У вас по сути идет шахматная партия со всем остальным миром, в котором фигуры противника не двигаются, все, что нужно делать вам - это двигать свои. Как бы бестолково вы не ходили и сколько времени бы не тратили на каждый ход, рано или поздно вы перебьете весь стан врага. Смиритесь. Я знаю, да, что это называется техникой визуализации или даже "самоисполняющимся пророчеством" и всем такие трюки давно уже оскомину набили. Ну что ж, скажу я вам, когда любая идея в твоей голове мгновенно превращается в красочную иллюстрацию, становится как-то не до того, чтобы брезгливо воротить нос.

Дело все в том, что вы должны представлять не деньги, которые принесет вам игра - так вы забегаете вперед при уже перевернутых понятиях (мысленно пропустили ноль) и в результате оказываетесь в минусе в изначальной системе координат (все уже сделано, всем уже понравилось, теперь вы мысленно тратите заработанные деньги). Не момент самого релиза, поскольку в нем вы со своей игрой никому не нужны, да и момент этот из-за премодерации сторами весьма размазанным получается (я писал об этом в дебютной статье).
Вы должны мысленно оказаться в моменте публикации новости о том, что вы свою игру наконец-то завершили. Где вы собираетесь об этом сообщить? Разместить на Youtbe'е ролик с геймплеем (это самое сложное пока что)? Рассказать друзьям в Facebook'е, что игру наконец-то дописали? Накатать простыню на Хабре о том, как семь раз спотыкались по неопытности об очевидные не вам вещи? Запостить на Reddit'е свою gamedev-стори? Или пожаловаться на Pikabu сколько вечеринок пропустили из-за своего каторжного труда? Да все вместе. А знаете как это сделать в один момент? Используйте китайскую трещотку.

Вы ведь, как и я, будучи программистом, наверняка любите мастерить всякое для души? Вот и создайте скрипт, который, подобно подожженной связке петард, за 12 секунд разошлет подготовленные вами материалы по всем интересующим вас площадкам. Бах, бах, бах, бах - с интервалом в 3 секунды китайская трещотка сделала свое дело, вы можете выдохнуть, дальше от вас ничего уже не зависит. Все произошло в один-единственный момент - в тот, в который вы нажали кнопку запуска скрипта. Но главное, что на самом деле вы можете не утруждать себя и никакую программу для этого не писать - зачем вам перебирать DOM в поисках поля ввода, преодолевать капчу и отлаживать свой скрипт пробными публикациями? Сделайте это вручную, ведь время можно легко сворачивать и разворачивать, главное чтобы материалы были у вас уже готовы. Пусть 12 секунд превратятся в 12 минут, все равно весь этот интервал времени в итоге равен одному моменту.
И самое интересное, что этот момент на протяжении всего пути из минус единицы в ноль будет вновь и вновь наступать. Вы успеете устать уже от собственной неопубликованной статьи и переписать ее снова и снова. Вы уберете то, от чего успели отказаться в своей игре и добавите то, что придумали добавить. Главное, что у вас уже будет с описанием игры статья.

Чтобы показать как это работает, я признаюсь вам честно, что прямо сейчас пишу эти строки (ноябрь 2020), хотя у меня еще даже не создан проект в IDE. Есть только четкое представление что и где я о нем расскажу, какой игра в итоге будет. Именно за счет отсутствия совершенной на данный момент работы, я легко могу встать на место того, кто никогда до этого момента ничего о моей игре не слышал. Я пока еще не вложился в нее, не полюбил каждую виньетку ее функционала и потому могу спокойно постулировать те особенности, которые у игры точно будут, самые крупные из них, мечтать по сути письменно, пребывая в уверенности что рано или поздно все это в жизнь воплощу. Я точно знаю, что даже начав с конца и написав сперва обзор еще не выпущенного релиза, причем так, будто он уже состоялся, обязательно в итоге приду в свой собственный ноль, где это окажется правдой. Статью-то мне теперь уже жалко будет выбросить.

Вы, может быть, не верите мне, когда я говорю, будто мироздание устроено так, что положительная обратная связь автоматически есть у любого вашего действия? Извольте. Чем больше вы играете в какую-либо игру, тем сильнее жалеете ее бросить. А если вы еще и задонатили, то теперь-то уж точно на крючке - не бросать же аккаунт, деньги вложены. А деньги - это энергия. Так просто они ниоткуда не берутся и никуда не пропадают, ведь все мы вместе с ними находимся в замкнутой системе (не считая некоторых оговорок по выпуску новых купюр). Поэтому было бы классно как-то автоматизировать шаги навстречу выпуску игры, чтобы с каждым днем положительной обратной связи становилось все больше. Еще лучше было бы приладить для этого внешний денежный поток, который бы работал на вас помимо собственной воли. Ну а уж кибернетизированная материальная лавина - и вовсе вполне реалистичная сказка, которую мы с вами можем легко себе изобрести.

Впрочем, можно не напрягаться в своих выдумках, все и так уже готово.

В своей дебютной игре я, сам того не подозревая, сделал систему алгебраической прогрессии, которая работала мне во вред. Лотерея с призами выпадала после первой победы, после двух подряд, затем после трех, после четырех и так до бесконечности. В итоге редко кто выбивал все подарки, исчерпав полностью сундук с сокровищами. Когда требование доходило до сплошной серии величиной в двадцать побед, у многих людей просто-напросто опускались руки. Но, сам того не подозревая, я использовал в этой ситуации древний вселенский паттерн, который, несмотря на свое засилье почти уже во всех сферах нашей жизни, все еще таит в себе немало загадок. Этот паттерн называется "Пирамида". Верхушка его - единица, второй слой - два элемента, третий - три, четвертый, не поверите, - четыре, думаю, дальше вы сами. Однако, бьясь в умственных конвульсиях, я вдруг понял, что у этой "пирамиды", имеющей в качестве горизонтальной оси сами элементы, есть и вертикальное измерение, смысловое. Единица - это господство, два элемента - противостояние, три - циркуляция, четыре - основание, дальше у меня в уме идет совсем уже мутная какая-то эзотерическая хрень, я пока с ней не разобрался.

Я предлагаю вам весь тот запас положительной обратной энергии, которую вы получите от первого шага, направить на незамысловатое действие - просто сделайте еще два. Ну что вам стоит? Игра ведь уже выпущена, не о чем беспокоиться. На этом втором, составном уровне почему бы нам с вами не задуматься о противостоянии двух ключевых понятий в нашем релизе? Маркетинг мы уже решили с помощью китайской трещотки, поэтому идем от обратного дальше: по моему сугубо личному мнению игра рождается в непрерывной борьбе двух начал - графики и геймплея. Вам повезло, если вы одинаково хорошо подкованы и в том, и в другом. Возможно, вы, как Фил Фиш, больше художник, а программирование для вас - прикладное увлечение.

Видели, кстати, фильм (в том числе) об этом Филе Фише? "Indie game" называется, там у этого художника-геймдизайнера спрашивают: "А в чем, собственно, смысл вашей игры? Что в ней можно делать?" А он такой: "Ну, понимаете, это как бы такой опыт, здесь можно пойти тудааа, сюдааа". И показывают нам как проект его виснет на каком-то gamecon'е раз за разом, что неудивительно - с разработчиком-то он незадолго до этого разругался. Сознаюсь: я искренне дал гению этого Фила шанс, купил его этот FEZ на своем Xbox 360, но игра чего-то у меня так и не запустилась, еще и сама консоль глюкнула как-то неприятно, хрустнула, я подумал "ну его" и от греха подальше удалил, так что созданный им для меня опыт я, несмотря на все свои, в том числе денежные, усилия, так и не получил в итоге.

Скорей всего вы, как и я, больше программист нежели художник. Не отчаивайтесь по этому поводу, графика имеет линейную ценность - на каждый типовой рисунок из ряда уходит одинаковое количество времени. Программирование же, на мой взгляд, интереснее - оно сложнее в силу того, что иерархично - чтобы сделать кучу объектов одного типа вам достаточно написать всего один родительский класс, а дальше клепайте сущности (хоть целые их классы) сколько вам влезет. Если бы художники могли так же, они бы озолотились. Хотя, подождите ка, вы знаете кто такой Энди Уорхол? На самом деле на заре игростроя так оно с графикой и было - вспомните Sub-Zero и Scorpion'а - самая знаменитая парочка двух графических потомков одного родительского экземпляра, различающихся лишь цветом. Но суть у них еще как разн. Функционал, смысловое наполнение, по моему скромному мнению, важнее внешней привлекательности.

Поэтому не отчаивайтесь если графики толком у вас нет и в ближайшем будущем она вряд ли появится. Вы же и в программировании так же пишете, с помощью абстракции: "Так, тут у нас получение координат" - вызвали пока еще не существующую getСoords() и пошли дальше, подробно распишете потом, внутри этой функции. Главное сейчас, что у вас есть идея, есть мечта, есть видение того какой ваша игра должна быть, представьте ее во всю силу своей фантазии, бросьте на это максимальное количество ресурсов своего воображения и смело ставьте галочку напротив первого шага - ноль обозначен, игра уже готова. Теперь можно расслабиться и позволить себе скатиться по шкале времени к моменту запуска китайской трещотки. Поздравляю вас.

Как думаешь, Хабр, это шизофрения?

Этот вопрос больше всего меня волнует, я буду задавать его в финале каждой части, он же будет и в самом конце всего цикла статей, так что если к текущему моменту желания нырять глубже у вас уже нету, можете смело считать, что дочитали всю мою эпопею до конца. Примите разве что напоследок мои искренние извинения за то, что зря потратил ваше время. Уж я-то понимаю, что все поведанное мною можно было донести куда проще - Егор Летов вон уложил целиком эту мысль в четыре строки (я привел их в качестве эпиграфа), а мне до него ничуть не меньше, чем до Ницше.

Подробнее..

Перевод Как мощность влияет на геймплей численный подход к дизайну игры для достижения ее честности

05.01.2021 12:12:21 | Автор: admin

В процессе прохождения игр пользователи стремятся к победе посредством достижения целей и задач, определяемых многими факторами. Навыки, мотивация, ресурсы и мощность аватара здесь играют решающую роль. Сравнение этих элементов важная задача геймдизайна для достижения честного геймплея.

Стоит заметить, что термин честность здесь более уместен, чем баланс, ведь последний чаще можно истолковать неверно. Честность подразумевается в том смысле, что опыт игроков должен быть выдержанным и правдоподобным. Честный геймплей должен быть приятным и увлекательным, даже если он не совсем четко сбалансирован. Идеальный баланс, в свою очередь, может сделать игру более скучной. По словам ведущего дизайнера Overwatch Джеффа Каплана:

Восприятие баланса гораздо важнее, чем сам баланс.

Во многих играх можно добиться хорошего игрового опыта, не задействуя при этом слишком много элементов, механик и правил. Это не означает, что такие игры обязательно будут простыми но их можно понять, изучив меньшее число сущностей. В шашках, в примеру, всего четыре правила, но это не делает их простыми.

Иными словами, во многих играх имеется широкий спектр элементов, дающих им больше возможностей и альтернатив. Сами по себе они не делают игры сложными и не подразумевают, что их сложнее освоить. Более того: многие из этих элементов могут даже не приниматься игроком во внимание в ходе игры. Однако достижение ощущения честности игры в данном случае может оказаться более сложной задачей, ведь при большем числе элементов их сложнее настроить для достижения согласованного, приятного и увлекательного опыта.

Во всех описанных случаях могут быть разные стратегии и отправные точки, которые можно использовать для достижения этой самой честности. Одна из них, на которой мы и сфокусируемся в данной статье, мощность (Power). Для ее определения прибегнем к термину, введенному Эрнестом Адамсом в Основах геймдизайна:

Мощность определяет непосредственную силу игрока: здоровье и возможности его аватара, размер и состав его армии, характеристики его гоночной машины или любые другие факторы.

Другими словами, мощность это мера возможностей игрока.

Далее в статье мы:

  • обсудим, как можно измерить мощность и как это влияет на решения по геймдизайну;

  • проанализируем, как мощность зависит от ресурсов игры и как связана с игровой экономикой;

  • проведем численный анализ, который можно использовать для понимания сложности и точек развития игры;

  • приведем пошаговый процесс поиска подходящего уравнения мощности, которое можно использовать для достижения честности игры, а заодно и баланса;

  • наконец, вкратце обсудим саму концепцию мощности.

Характеристика мощности через ресурсы

Концепция мощности очень субъективна не только для самой игры в целом, но и для ее цели. Для примера рассмотрим гипотетическую игру Run & Gun, в которой игроки сражаются на арене, гоняясь друг за другом на авто и стреляя друг в друга. Побеждает последний выживший, как это было в боевом режиме Mario Kart. В этой игре оружие и его свойства теснее связаны с концепцией мощности, чем скорость машины.

С другой стороны, если бы целью игры была обычная гонка, вероятно, скорость авто имела бы большую мощность, чем оружие и другие боевые элементы. Однако в обоих случаях любые факторы, участвующие в достижении цели игры, являются частью мощности игрока, даже если их вклад незначителен или почти не заметен.

Концепцию мощности будет легче понять, если мы будем рассматривать факторы ее измерения как игровые ресурсы. Ресурсы это любые элементы, которые можно измерить численно. В Run & Gun, у нас есть следующие ресурсы (или атрибуты):

  1. V Здоровье транспортного средства: сколько очков XP есть у вашего авто;

  2. F Сила оружия: сколько урона наносит ваша пушка одним выстрелом;

  3. A Количество боеприпасов: сколько раз вы можете выстрелить до перезарядки;

  4. S Скорость: насколько быстро вы движетесь;

  5. T Время перезарядки: сколько времени длится перезарядка.

Имея данные об этих ресурсах, можно определить формулы, по которым рассчитывается мощность транспортного средства. Суммирование всех этих ресурсов то есть, V + F + A + S + T является исходным (наивным) подходом. Проблема в том, что он предполагает, что более высокое время перезарядки приводит к более высокой мощности, хотя это, конечно же, не так. Самое простое решение этой проблемы принять максимальное время перезарядки к примеру, 60 секунд, и использовать его для инвертирования значения времени перезарядки. Например:

Поскольку 60 секунд максимальное время перезарядки, если T = 60, его вклад в значение мощности будет минимален: 60/60 = 1. С другой стороны, если T окажется совсем небольшим например, 1 или 2, его вклад в значение мощности будет 60 либо 30, что определенно гораздо больше. В дальнейшем мы будем использовать термин вклад для обозначения того, насколько атрибут увеличивает или уменьшает расчетное значение мощности.

В качестве полного примера предположим, что автомобиль Fusca имеет следующие атрибуты: V = 10, F = 2, A = 3, S = 10, T = 30. Тогда мощность Fusca равна 10 + 2 + 3 + 10 + 2 = 27. Для сравнения возьмем другой автомобиль Hilux со следующими атрибутами: V = 15, F = 3, A = 1, S = 7, T = 60. Отсюда мощность Hilux равна 15 + 3 + 1 + 7 + 1 = 27. Хотя эти две машины имеют разные характеристики, мощность их одинакова.

Поскольку ресурс V теснее связан с целью игры (меньшее его значение влияет на живучесть машины), более точная формула могла бы утяжелить его, увеличивая его вклад. Например, если умножить его на произвольное значение больше единицы.

Однако если наше уравнение правильно отражает игровой опыт, у нас, вероятно, будет честный (и даже сбалансированный) игровой процесс для обоих авто. Однако угадывать формулу не лучшая стратегия. В реальном сценарии эти числа и уравнение следует проверить, чтобы увидеть, насколько хорошо они отражают геймплей.

Как мощность влияет на экономику

Экономика игры управляет игровыми ресурсами: правилами и механиками, которые управляют, генерируют и уничтожают ресурсы. Поскольку мощность выражается через ресурсы, она также напрямую связана с экономикой игры.

Игровая экономика обычно связана с четырьмя столпами: Источниками (Sources), которые создают ресурсы; Стоками (Drains), которые уничтожают ресурсы; Преобразователями (Converters), конвертирующими одни ресурсы в другие; и Обмениками (Traders), которые обменивают ресурсы между различными объектами в игре, такими как игроки или NPC.

Поскольку мощность тесно связана с целью игры, она также имеет тенденцию управлять экономикой как с точки зрения ее устройства, так и воздействия на игру.

Основные экономические механики будут напрямую связаны с ресурсами, влияющими на мощность, но не ограничены ими. Для краткости будем называть ресурсы, участвующие в расчете мощности, ресурсами мощности.

На диаграмме ниже показан черновик игровой экономики для Run & Gun, где Fusca противостоит Hilux:

Количество боеприпасов можно превратить в пули (другой ресурс) при помощи стрельбы. Если пуля попадает в машину, та теряет здоровье пропорционально силе оружия выстрелившей машины. Игрок может перезарядиться, потратив время на перезарядку для генерации боеприпасов (машина действует как источник собственных боеприпасов).

Скорость ресурс, не связанный напрямую с экономикой, но тесно связанный с геймплеем. Поскольку автомобили для преследования друг друга должны двигаться, скорость будет определять их позицию. Их расположение напрямую связано с механикой движения и стрельбы.

В более подробную схему экономики мы могли бы включить другие ресурсы, такие как расстояние между игроками и механики преследования. Кроме того, если игроки смогут уклоняться от выстрелов, можно добавить еще такие неопределенности, как скорость пули и даже ее размеры.

Чтобы выявить ресурсы, влияющие на мощность, лучше всего составить схему игровой экономики и выяснить, какие ресурсы более тесно связаны с кор-геймплеем.

В изначальной версии Run & Gun кор-механика не меняется, так что мощность каждого игрока остается неизменной в течение всей игры. Даже когда у одного игрока заканчиваются боеприпасы, его расчетная мощность остается неизменной, ведь получение новых лишь вопрос времени.

Мощность, сложность и прогресс

Когда мощность меняется в течение игры, игровые элементы также должны адаптироваться к ее новому значению. В противном случае вызовы и трудности, которые предлагает игра, могут быть восприняты как банальные и даже скучные.

Этот процесс регулировки мощности не обязательно должен быть полностью адаптивным или автоматическим. Многие игры меняют мощность элементов от уровня к уровню. По мере того, как игрок завершает задачу, следующая становится все сложнее, а связанные с ней элементы труднее преодолевать.

Более современные игры, такие как Hellblade: Senua's Sacrifice, предлагают автоматический выбор сложности в зависимости от прогресса игрока. По мере того, как игрок путешествует по адскому скандинавскому ландшафту, игра автоматически адаптируется в соответствии с навыками и способностями игрока, чтобы поддерживать необходимый уровень стресса и азарта.

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

Если мощность не меняется в течение игры, различие между абсолютной и относительной сложностью можно игнорировать, как это имеет место в нашей гипотетической игре Run & Gun.

Процесс регулировки мощности с абсолютной сложностью

Предположим, что в Run & Gun есть однопользовательский режим кампании, в котором игрок сталкивается с последовательностью испытаний, чтобы стать королем арены. Если у всех машин стандартная начальная мощность будет 27 (как рассчитано ранее), начальные испытания должны либо иметь более низкое значение мощности, либо равное ему.

Например, первой задачей может быть победа над Pontiac, имеющим атрибуты V = 5, F = 1, A = 1, S = 5, T = 60 и мощность, равную 13. То есть, она составляет почти половину мощности стандартного автомобиля. Это должно помочь новым игрокам познакомиться с игрой и изучить элементы управления без чувства непосредственной угрозы или разочарования.

Однако по мере приближения к титулу короля арены игрок должен столкнуться с противниками с врагами с более высокими характеристиками, что способствует более сложному опыту. Конечным боссом может быть Volkswagen Braslia с атрибутами V = 30, F = 5, A = 3, S = 10, T = 10 и мощностью, равной 54. То есть, мощность босса в два раза превышает мощность стандартного автомобиля. Преимущество использования этого подхода заключается в том, что, если задача оказывается практически невыполнимой, мы можем прибегнуть к корректировке характеристик и затем еще раз сравнить значения мощности.

Обратите внимание, что в обоих случаях (и во всех остальных между ними) мощность игрока не меняется между боями. С другой стороны, тут становятся важны его опыт и навыки. По мере прохождения игры пользователи улучшают свои способности, лучше сражаются и осваивают игру.

С помощью числового анализа мы также можем планировать ход игры, нанося на график значения мощности. На приведенном выше графике показаны различные подходы к регулировке мощности в игровой кампании. Пунктирная черная линия стандартная мощность со значением 27 является лишь ориентировочной отметкой. Вот эти подходы:

  1. Линейный: мощность увеличивается на одно и то же значение на каждом уровне.

  2. Нелинейный: мощность увеличивается нелинейно на каждом уровне например, с умножением на некий коэффициент. На графике каждый уровень умножает предыдущее значение мощности на 1,25 (эквивалент увеличения на 25%).

  3. Скачкообразный (Steps): мощность увеличивается произвольно, включая повторение одной и той же мощности между уровнями в соответствии с определенным дизайном игры. На графике мощность увеличивается только после двух последовательных уровней. Этот подход помогает упростить прохождение игры.

  4. Пилообразный (Sawtooth): мощность последовательно колеблется: то увеличивается, то уменьшается. Такой подход снижает сложность после каждого более сложного испытания. Обратите внимание, что разрыв мощности между уровнями становится выше, но игрок может делать перерыв после каждого такого скачка из-за меньшей сложности следующего шага. Считается, что такой подход обеспечивает хороший темп в течение игры.

Подходы Steps и Sawtooth очень похожи, поскольку они не подчиняются стандартному математическому уравнению. Разница между ними в том, что Steps никогда не снижает мощность: он либо остается прежним, либо увеличивается, в то время как Sawtooth может либо увеличивать, либо уменьшать мощность для достижения хорошего темпа.

Процесс регулировки мощности с относительной сложностью

В предыдущем разделе обсуждалось, как можно численно проанализировать процесс регулировки мощности в игре с абсолютной сложностью то есть, когда мощность игрока никогда не меняется. Чтобы изучить этот процесс в условиях относительной сложности, предположим теперь, что в Run & Gun игрок получает некое число очков, которые распределяются между его характеристиками после каждого уровня.

Для наглядности на этот раз возьмем те же подходы, что и в предыдущем разделе. Игрок может получить больше очков линейно (приращение одного и того же числа), нелинейно (приращения подчиняются нелинейной формуле), пошагово (разные приращения на разных шагах) или пилообразно (приращения каждый раз варьируются от более высоких к более низким значениям). На графике ниже показано сравнение этих подходов с предыдущими:

Для приведенного выше графика линейная мощность предполагает увеличение на одно очко статистики за уровень, в то время как нелинейная мощность увеличивает статистику, умножая текущее значение на 1,15. Оба подхода представляют собой весьма экстремальные сценарии для приведенного выше примера.

В то время как линейная мощность мало влияет на сравнение мощностей по мере продвижения игрока по кампании, нелинейный подход превосходит мощность всех уровней с ошеломляющим показателем 63 к концу игры вот это настоящий король арены!

Хотя эти графики просто иллюстрируют численный анализ мощности и прогресса, они представляют собой более практичный и наглядный подход к процессу. Одновременно они могут быть полезны при изучении влияния непостоянных обновлений и других динамических характеристик изменения мощности.

В то же время этот анализ предполагает, что формула мощности, используемая для Run & Gun, точна, хотя, вероятно, и не верна. Чтобы это действительно было так, все характеристики должны в равной степени влиять на то, как игрок воспринимает мощность. В следующем разделе предлагаются практические подходы к этому вопросу.

Мощность исходит от людей

Ни одно решение по дизайну игры не стоит принимать в работу, пока оно не будет проверено на игроках. Для первого игрового прототипа вы должны сформулировать уравнение мощности, которое будет проверено с помощью плейтестов. Подобно тому, как это предлагалось для Run & Gun, обычное суммирование отличный начальный вариант. Это просто, легко и практически не требует математических знаний.

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

Если вы предпочитаете провести более тщательное планирование перед тестированием, вам следует самостоятельно провести анализ важности ресурсов, чтобы выявить те, что с большей вероятностью внесут больший вклад в уравнение мощности. Этот шаг может оказаться очень полезным, особенно для игр с большим количеством ресурсов.

В качестве альтернативы можете создать прототип игровой экономики и изучить, как можно точнее измерить мощность. Для этого можно либо создать ее примитивный прототип, используя ручку, бумагу и несколько игровых костей, либо изучить специальные инструменты, такие как Machination. Microsoft Excel или любое другое ПО для работы с электронными таблицами прекрасный инструмент вам в помощь.

Такой численный процесс представляет нам обобщенные ситуации и сводит их к числам, которые могут не полностью отражать игру. Рассмотрим ситуации, в которых задача игрока заключается в победе над несколькими врагами: должна ли измеряемая мощность учитывать сумму всех их способностей или среднее количество врагов, с которыми игрок сталкивается одновременно? Подобные ситуации требуют более тщательного тестирования для составления соответствующих формул и стратегий.

Этот подход также не охватывает непосредственно механики и требуемый уровень их навыков. Мощность некоторых элементов может быть очень высокой, но для их эффективного использования требуется такой высокий уровень навыков, что они не кажутся такими уж сильными. Тем не менее, эти механики, вероятно, продемонстрируют свой потенциал в ходе плейтестов. Более того, возможно, эти навыки не требуют балансировки, поскольку игровое мастерство уже является частью опыта. Для игроков может быть полезно порой иметь абсолютную власть, как сказал бы император Палпатин.

Пошаговый процесс вычисления мощности

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

  1. Составьте исходное уравнение для расчета мощности (например, суммирование).

  2. Рассчитайте мощность элементов на уровне, включая мощность игрока.

  3. Протестируйте уровень (как можно большее число раз).

  4. Проанализируйте сложность игры и трудности, с которыми сталкивается игрок.

  5. Если игроки считают, что уровень был честным (не обязательно сбалансированным), вы на верном пути, иначе:

  6. Адаптируйте уравнение, увеличивая/уменьшая вес характеристик, которые чаще всего упоминаются тестировщиками или наиболее тесно связаны с чувством несправедливости. Вернитесь к шагу 2.

Для процесса взвешивания самый простой подход умножить статистику на число, тем самым увеличив ее вклад. Например, если предположить, что сила оружия упоминается большинством тестеров, ее вклад можно удвоить:

В данном случае мощность Fusca станет 10 + 2 * 2 + 3 + 10 + 2 = 29, а мощность Hilux увеличится до 15 + 2 * 3 + 1 + 7 + 1 = 30. Из-за этого Hilux теперь немного превосходит Fusca. Мы можем уравновесить их, увеличив боезапас Fusca с 3 до 4 или уменьшив время перезарядки с 30 до 20.

Самая трудная часть этого процесса безусловно, анализ сложности для игрока. Очень часто игрокам не хватает контекста игры: они не знают всех переменных, которые влияют на их опыт. Используйте их мнение в качестве ориентира для решения проблемы, но протестируйте ее на других игроках, чтобы выявить настоящую причину ваших проблем.

Так, игроки могут спорить о силе оружия, но может статься, что настоящая проблема кроется в уровне здоровья машины.

Мощность через эмпатию

В конечном итоге настоящие результаты вам принесут плейтесты. Ваши игроки не только укажут вам на то, какие ресурсы кажутся им более важными, но и, безусловно, будут жаловаться на дисбаланс мощностей некоторых элементов. Более того, весь этот процесс предназначен для достижения чувства честности, которое может быть достигнуто только в том случае, если о нем упомянут тестировщики.

Мощность это не только инструмент прогресса и баланса. Это также источник мотивации. Поощрение игрока могущественным артефактом, который быстро выводит воспринимаемую мощность на новый уровень, несомненно, будет хорошим ходом. То же самое касается квестов и испытаний, обещающих расширить возможности игрока.

Тем не менее, этот процесс окажется бесполезен, если не уделить ему достаточно внимания, как это сказано в книге Джесси Шелла Искусство геймдизайна:

Самый важный навык для геймдизайнера умение слушать.

Понимать друг друга в том, что вы чувствуете в рамках своих взглядов, положения и опыта. По-настоящему общаясь со своими игроками, вы можете на мгновение перестать быть архитектором игры и стать ее гражданином. Это может помочь вам понять недостатки вашего дизайна и почувствовать на себе все трудности, которые вы создали для игроков.

Хотя в этой статье был рассмотрен пример боевой системы, то же самое можно применить к системе экономики таких игр, как Rise of the Industry, или, скажем, освоения космоса в Spore.

Другим любопытным примером может являться Sim City. Многим игрокам может показаться странным, что деньги здесь не являются основным ресурсом для победы. Действительно: в игре очень важно держать ваши финансы в хорошем состоянии, однако все высокоуровневые здания и сооружения открываются игроку только тогда, когда он набирает большое число здоровых, образованных, счастливых и финансово стабильных граждан. В некотором смысле это связано со следующей мыслью: настоящая мощь исходит от людей, а истинное мастерство от связи с ними. Будь то строительство мегаполиса или создание лучших игр.

Подробнее..

Перевод Как написать игру за месяц, не отвлекаясь от основной работы

14.01.2021 14:20:31 | Автор: admin
image

MoonGun игра в жанре экшен/стратегия о защите лунной базы от астероидов. Игра была создана Ивенсом Серпой автором множества статей о геймдизайне в рамках Github Game Off Game Jam в ноябре 2020 года. Занимался он ей в одиночку в свободное от работы время. Игра получила немало положительных отзывов, так что ее создатель решил поделиться опытом ее разработки: описать весь процесс создания и поделиться методами, которые он использовал, включая этапы концепции, планирования, непосредственно разработки и релиза.

Прежде чем перейти к теме статьи, стоит упомянуть несколько важных замечаний: этот материал больше касается дизайна игры, чем технической стороны ее разработки. Проект был разработан при помощи Unity 3D (версия 2020.1), с которой автор уже довольно хорошо знаком и в которой уже писал другие игры. Несмотря на то, что над проектом он работал в одиночку, ему все равно помогали друзья, тестируя игру и делясь своими мыслями на этот счет. Большая часть ассетов либо была взята в Интернете (например, с сайта Kenney.nl), либо была сделана моделером Калео Мендесом.


Игровые джемы, тема и идеи


Игровой джем соревнование по разработке игр, в котором участники пытаются разработать игру с нуля за некий короткий промежуток времени обычно от 24 до 72 часов. В ноябре GitHub проводил Itch.IO Game Off Game Jam, который продлился весь ноябрь. У таких джемов обычно есть основная тема, которая направляет творческий процесс разрабатываемых игр. В 2020 году эта тема касалась Луны.

Разработчики могут интерпретировать тему максимально свободно, креативность здесь ключевой фактор. Она же является одним из критериев ранжирования работ и выбора победителей.

Итак, фазу концептирования стоит начать с мозгового штурма игровых механик и идей, соответствующих теме.

В результате такого брейншторма у Серпы родилось три основных концепции:

  • Игра по сбору ресурсов, в которой игроки управляют лунной базой до тех пор, пока не будет достигнут определенный порог то есть, пока игрок не соберет определенное количество ресурсов;
  • Игра, основанная на физике, в которой игроку необходимо построить или запустить некий механизм на лунной базе;
  • Интерактивная история о персонаже, работающем на лунной станции.

Хотя все три идеи кажутся неплохими, возникала проблема с их масштабом: большинство основных функций, которые для них необходимы, просто нельзя было реализовать за столь короткий промежуток времени.

Вторая идея основана на физике и требует обширной кодовой базы для обеспечения реалистичности игры. Техническая осуществимость может поставить под угрозу проект и сделать первичное прототипирование слишком сложным. В результате можно рискнуть и потратить время на реалистичную игру, в которую неинтересно играть.

Что до интерактивной истории, технической осуществимостью здесь можно пренебречь, а вот творческим процессом нет. Взявшись реализовывать эту идею всего за месяц, вы рискуете получить увлекательную историю, которая была бы, по сути, просто визуальным романом без каких-либо примечательных элементов геймплея.

Помимо этих факторов, еще было неясно, какие механики здесь лучше использовать что будет основным движителем игры. Ведь лучше начать разрабатывать игру с прототипа одной механики, а затем работать над ней до тех пор, пока не добьетесь увлекательного геймплея и не доведете игрока до финиша.

Итак, за основу будущей игры была взята идея по сбору ресурсов. И поскольку просто щелкать по кнопкам довольно скучно, в качестве источника вдохновения была взята Space Invaders, а сама концепция игры была сформулирована следующим образом:

Игрок управляет пушкой (турелью), защищающей лунную базу от падающих астероидов, а также базовыми объектами (шахта, лаборатория и ангар), которые собирают лунную руду до тех пор, пока Луна не истощится (условие победы).

Ниже можно увидеть изображение первого рабочего прототипа:

image
MoonGun Version 0.1 не слишком красивый, но функциональный прототип


Прототип и гипотезы


Для проверки изначальных гипотез был сделан первые прототип игры. И поскольку ни одна из этих гипотез не была связана с графикой или производительностью, визуальные эффекты, как можно убедиться на изображении выше, были далеко не самыми впечатляющими.

Краткая версия этих гипотез звучала так:

  1. Стрелять в падающие астероиды интересно или увлекательно?
  2. Можно ли имитировать лунную поверхность с помощью большой 3D-сферы?
  3. Следует ли сделать управление пушкой с помощью клавиатуры или мыши?

Также нужно было проверить несколько технических гипотез, в основном связанных с выпуском игры в виде сборки WebGL с использованием Unity. В связи с пандемией имело смысл разместить игру прямо на Itch.io, чтобы облегчить тестирование и распространение ее версий. Беспокоило то, сколько времени потребуется, чтобы пройти весь цикл сборки-деплоя-тестирования на платформе Itch.io (в часах или минутах), а затем какого качества графики можно достичь, чтобы при запуске игры в браузере сохранялась приемлемая частота кадров.

Первый прототип оказался весьма успешным. Не то чтобы все гипотезы подтвердились, но все они получили свою оценку, а это и есть истинная цель прототипирования. Первая версия игры была размещена на сайте 3 ноября. Цикл сборки-деплоя-тестирования занял около 15 минут, что оказалось приятным сюрпризом.

Поскольку идея выглядела достаточно перспективной, чтобы продолжить над ней работать, прямо поверх скриншотов было сделано несколько концепт-артов: это позволило быстро увидеть некое приближение, как будет выглядеть финальная версия игры. Последнее облегчило демонстрацию идей другим людям для получения фидбека.

image
Концепт-арт для игры на основе скриншотов прототипа

14 ноября была выпущена уже более стабильная версия с подтянутой графикой, приличным скайбоксом и хорошей постобработкой. Большая часть времени работы над обновлением ушла на проработку аспектов, отмеченных в отзывах, и на улучшение графики, чтобы оценить, насколько производительной может оказаться сборка WebGL.

К тому времени уже сложилось более ясное представление о назначении турели и лунных сооружений. Турель будет генерировать ресурсы астероидов, сбивая их выстрелами из пушки. Задача шахт пассивная генерация минералов (для этого нужны астероиды). Ангар нужен для улучшения туррели (с использованием минералов). Лаборатории должны помочь привести игрока к победе (истощение Луны) с использованием обоих ресурсов: как астероидов, так и минералов.

Скриншот из этой версии (V0.4 Лунные сооружения) можно увидеть ниже:

image


Тесты, стабильная версия и геймплей


Во время разработки версий с 0.1 по 0.4 большая часть тестов проводилась самостоятельно либо с помощью близких друзей. Но начиная с версии 0.4 началось уже более активное продвижение игры для тестирования.

Версия 0.4 вышла на Itch.io уже со всеми основными функциями игры то есть, была так называемой стабильной версией: в ней были все необходимые функции, чтобы пройти игру до конца, и она уже могла вовлекать игроков по полной.

image

Отзывы, полученные во время тестирования, очень помогли с дальнейшим улучшением игры. Элементы управления были изменены с клавиатуры на мышь, визуальные эффекты тоже поменялись. Затем сборка WebGL была выставлена на самые высокие настройки, поскольку большинство игроков имели частоту кадров выше 60 FPS за исключением одного тестировщика, который пытался запустить ее на Chromebook.

Более того, теперь уже стало яснее, что люди действительно получали удовольствие от игры. Был даже один тестировщик, который просил больше обновлений и введение дополнительных действий. Это означало, что кто-то активно играл в игру до ее (текущего) конца!

В версии Лунные сооружения уже был реализован весь основной игровой цикл, каким он показан на схеме ниже:

image

Как упоминалось ранее, игра основана на сборе двух основных ресурсов: астероидов, собранных путем уничтожения их турелью, и минералов, которые время от времени собираются автоматически из шахт. Турель и шахты можно улучшить, используя противоположные ресурсы (минералы для турели, астероиды для шахт). Использование противоположных ресурсов позволило избежать сильных положительных циклов обратной связи в игровой экономике: когда механика улучшается при помощи того самого ресурса, который она генерирует.


Не (всегда) нужны сложные или дополнительные механики


На представленной выше схеме для обозначения основной цели игры используется термин основной квест (Main Quest). Она была реализована в виде простой кнопки, которая тратит запрошенные ресурсы. Чтобы выиграть, игрок должен тратить все больше ресурсов, пока полностью не исчерпает Луну.

Механика победы была разработана для достижения произвольно большого числа, которое активирует условие победы, и игроку присуждается статус победителя. После истощения Луны шахты перестанут генерировать минералы, и все конец игры.

image
Вариант основного квеста (Минеральный лазер) на объекте Лаборатория

Какой отсюда можно сделать вывод? Вам не всегда нужно усложнять свою игру (например, добавляя больше механик), чтобы обеспечить условия победы или сделать игру лучше. Для MoonGun, поскольку игроки уже получали от нее удовольствие, не было необходимости тратить больше времени на разработку новой механики только для условия победы его можно было сформулировать с помощью основной механики.

Также помните, что игру нужно было сделать в течение одного месяца, поэтому меньшее количество реализаций здесь означало больше времени на полировку и улучшение игры.


Залп! Баланс и честность игры


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

image
MoonGun, версия 0.7 лазер

Лазер был тепло принят тестировщиками и добавил игре дополнительную степень свободы. Однако он также дестабилизировал воспринимаемую мощность игрока. Из-за того, что лазер обладал большей дальностью и длительностью действия, обычная пушка теперь казалась слабой. Необходимо было сбалансировать процесс улучшения обоих видов оружия.

Так, в какой-то момент по мере прохождения игры пушка получит больше улучшений и превзойдет лазер. Тогда лазер получит собственные улучшения и вернет себе лидерство. Этот обмен предпочтительным оружием туда-сюда увеличивал динамику игрового процесса.

В то же время выбор оружия по-прежнему оставался за игроком. Игра не мешает использовать любое из представленных в ней видов оружия.

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


Лунные квесты


Фактически лазер был добавлен в версию 0.5. Тем не менее, его более стабильная реализация была представлена только в версии 0.7 под названием Лунные квесты, которая также включала:

  1. Дрожание камеры;
  2. Эффекты разрушения астероидов;
  3. Смену оружия (нажатием клавиши SHIFT);
  4. Изменение элементов управления для использования мыши и/или клавиатуры;
  5. Подзапросы на дополнительные ресурсы;
  6. Разнообразие астероидов (с разными скоростями, размерами и наградами за уничтожение);
  7. Улучшение средней частоты кадров.

image

Обратите внимание, что два пункта связаны с улучшением внешнего вида игры (1 и 2), два с добавлением/изменением элементов управления (3 и 4), еще два с дополнительными элементами игры (5 и 6). Один же предназначался для анализа и отладки. Это разделение было полностью преднамеренным.

Учитывая ограниченность отведенного на разработку времени, необходимо было сбалансировать свою рабочую нагрузку по многим аспектам, которые требовали улучшений.

Версия Лунных квестов была более полной и позволяла игрокам экспериментировать с игрой, а также взаимодействовать с большим количеством элементов управления. Это помогло увидеть, что хорошо работает в игре (например, астероиды и вариативность оружия), а чего не хватает.

В то же время стало приходить все больше комментариев, касающихся отсутствия объяснений и контекста игры. До сих пор это была просто аркадная игра без какой-либо четкой цели. Пришло время добавить в нее элементы повествования.


Встречайте Титана и Луну S/2009 S1


В начале игры появилась небольшая подсказка, которая должна была связать сценарий, мотивацию игрока и условия победы. Выглядела она так:

Луна S/2009 S1 полна богатым минералом флеботием, и вы, игрок, отвечаете за защиту объектов станции во время его добычи. База покрыта полем, который может защитить ее от слабых астероидов. Однако по мере того, как продвигается добыча, ядро Луны становится все тяжелее, привлекая к себе более быстрые и опасные астероиды, которые могут повредить щит и прервать работу на объектах.

Для помощи с повествованием в игру был введен Титан робот, сначала вводящий игрока в курс дела, а позже выступающий проводником по ходу развития сюжета. Титан был придуман, смоделирован и анимирован Калео Мендесом, который также занимался UI-дизайном игры.

На изображении ниже показана первая версия введения с Титаном, новым UI-интерфейсом и на заднем плане щитом, покрывающим всю Луну.

image

Версия V0.8, Лунное меню, была выпущена 26 ноября всего за несколько дней до дедлайна. Она включала в себя существенную переработку UI, а также информацию о щите.

image

Помимо этого, в игре были и другие улучшения: были изменены эффекты, и теперь игроку стало легче переключаться между оружием по правому щелчку мыши. Кроме того, был изменен интерфейс перезарядки оружия: теперь на туррели отображалась информация об обоих видах оружия сразу. Это позволило игрокам использовать их более продуманно, переключаясь с одного на другое, когда одно из них находилось на перезарядке.

Также было улучшено дрожание камеры, усиливающее ощущение мощности обоих видов оружия, и снова изменены эффекты разрушения астероидов. Обратите внимание, что большинство этих изменений было сделано для улучшения стабильной версии игры, и очень мало значительных изменений было внесено непосредственно в основной цикл игрового процесса.


Финальная версия и ее проблемы


Финальная версия V1.0a MoonGun была выпущена 29 ноября. В ней были реализованы все рабочие функции, еще больше настроек и более сбалансированный опыт для основного квеста. Были добавлены легкие астероиды в первые минуты игры и более смертоносные для поздних этапов. Уже имелись все звуковые эффекты и музыка для создания атмосферы и полноценного игрового опыта.

Также в игре были реализованы некоторые элементы управления настройками, такие как ползунки звука и музыки, а также ползунок для управления эффектами яркости как это было умно упомянуто одним из тестеров. И добавлено предупреждение на экран загрузки, уведомляющее игроков о сильных световых эффектах в игре.

image
MoonGun, версия 1.0a


Отзывы и (будущие) улучшения


Хотя игра получила весьма хороший фидбек, некоторые проблемы так и не было времени доработать. Самым существенным здесь оказалось то, что в игре нет четкого завершения: вы не можете ее проиграть. Если на Луну упадет множество астероидов, мины перестанут работать, пока вы не почините щит, потратив на это собранные астероиды, но при этом база никогда не разрушится.

По задумке игра должна была оказаться легкой и не наказывать игроков, пока они учатся в нее играть. И поскольку она основана на постоянном прогрессе, казалось слишком демотивирующим позволить игроку потерять все из-за того, что не удалось защитить базу. Судя по отзывам, пожалуй, следовало пересмотреть этот аспект и подумать о других решениях.

Кроме того, в игре нет заключительного ролика. После выполнения последнего основного квеста появляется Титан и передает последнее сообщение, но после этого игроки могут продолжать игру столько, сколько захотят. Некоторых тестеров это так разочаровало, что они даже написали об этом на странице игры.

Более того, оказалось, что многие игроки пропускают введение и начинают играть в игру, не понимая ее контекста и мотивации. Здесь тоже можно что-то придумать, чтобы это происходило как можно реже.

image


Процесс в ретроспективе


MoonGun определенно не станет следующим инди-хитом, но этого никогда и не планировалось. Скорее это был опыт создания игры, который оказался весьма положительным и позволил извлечь много уроков. Кроме того, в результате действительно получился готовый продукт. Несмотря на то, что в игре нет никакой сложности, она была тепло принята людьми, особенно за пределами круга друзей и семьи автора. А для такого проекта это уже успех.

Рабочий процесс строился на следующем: быстрое достижение стабильной версии игры, а затем ее улучшение. Оглядываясь назад на разработку за эти 4-5 недель, можно расписать основные шаги так:

  1. Концепция и прототип главной механики;
  2. Улучшение опыта и создание стабильной игры;
  3. Тщательное тестирование и внедрение обратной связи;
  4. Развитие механики, повествования, экономики и эстетики;
  5. Полировка.

Поскольку автор не мог (да и не хотел) бросать текущую работу, чтобы полностью отдаться этому делу, над разработкой приходилось работать поздно ночью и по выходным. Один метод, который в этом очень помог хранение трекера выявленных проблем в репозитории, куда можно было заносить всю работу, которую необходимо выполнить. Это помогало быстро вернуться к работе над проектом через некоторое время и выяснить, где ты в последний раз остановился.

Более того, автор стремился всегда идти по пути меньших усилий. Это не означает написание ленивого кода или поиск плохих решений (исходный код доступен здесь) это значило, что сначала проводилось тестирование простых подходов, прежде чем переходить к более крупным реализациям или рефакторингу.

Также не стоит пренебрегать действенными инструментами из Unity и сторами ассетов, чтобы ускорить процесс разработки. В данном случае самыми полезными оказались DOTween, LeanPool и Cinemachine.


Постобработка (магия, которую вы заслужили)


Добавление слоев эффектов постобработки помогает создать нужную атмосферу в игре и сформировать уникальный внешний вид. На изображении ниже показано сравнение одной и той же сцены с постобработкой и без нее:

image
Игра без постобработки (на оригинальной PlayStation) и с постобработкой (на ПК)

В частности, использовались следующие эффекты:

  1. Lift Gamma Gain: улучшение освещения;
  2. Искажение объектива (Lens Distortion): изображение, как если бы оно проходило через реальную камеру;
  3. Хроматическая аберрация: для создания атмосферы космического искажения;
  4. Зернистость пленки: добавление шума и динамики в сцену;
  5. Глубина резкости: размытие объектов вне фокуса для добавления реализма изображению;
  6. Виньетка: затемнение краев, чтобы игрок сосредоточился на центре изображения;
  7. Блум: чтобы свет выглядел волшебно!

Здесь вы можете увидеть, как эти эффекты накладываются друг на друга:

image


Вместо заключения


Каждый геймдизайнер и разработчик может подтвердить: создавать игры сложно, но, тем не менее, вдохновляюще само по себе. Каждый новый тестировщик, возвращающийся с положительными отзывами, дает вам энергию и подпитывает стремление довести проект до конца.

Более того, опыт работы с Unity 3D поможет быстрее перейти от прототипа к рабочему продукту за довольно короткое время. Во время разработки MoonGun в ход шли различные методы быстрого прототипирования для Unity 3D с использованием таких инструментов, как Unity Events, Scriptable Objects, и LINQ statements. Большинство материалов было сделано с помощью Unity Shader Graph и Prefab Variants.

Однако, эту игру вряд ли можно было бы сделать без четкого плана и стратегии. Поэтому стоит повториться язе раз, что важно сначала придерживаться простых механик, а затем уже развивать игру на их основе.
Подробнее..

Перевод Как создавать игры для тех, кто не хочет играть по правилам

04.08.2020 10:19:03 | Автор: admin
Чувствуете ли вы азарт, когда обнаруживаете в игре сбой? Когда, наконец, попадаете в скрытую область на карте, не предназначенную для игроков? Которая была заблокирована кажущимися непроходимыми горами и невидимыми стенами? Если ваш ответ да, поздравляем, вы исследователь.

Как исследователя, меня всегда восхищало то, что скрыто от глаз в играх, в которые я играю. До сих пор хорошо помню, как в первый раз попала под Штормград в World of Warcraft. Добраться туда нетрудно, и я, конечно, не была первой. Но когда я спустилась вниз под шумный город, мой восторг было не передать. Прямо надо мной стояли сотни людей: все куда-то спешили, продавали вещи на аукционе или болтали с друзьями, и я была как бы не с ними, но все еще там. С тех пор я всегда искала в играх что-то подобное. Мне все время хочется заглянуть за дым и зеркала и увидеть игру такой, какая она на самом деле. Это привело меня к размышлению о том, как разработчики создают игры для таких людей, как я, исследователей.

image


Кто же такие исследователи?


Если вы опросите тысячу поклонников The Elder Scrolls, что им больше всего нравится в игре, вы получите множество разных ответов. Однако это не будет тысячей разных ответов. Возможно, нам хотелось бы верить, что наши мотивы уникальны, но в действительности они часто следуют определенным схемам и могут быть определены по категориям. Так, в своем исследовании 1996 года Ричард Бартл поделил игроков на четыре психотипа: исследователей, карьеристов, коммуникаторов и киллеров.

Карьеристы (Achievers) традиционный тип игроков, стремящихся достигнуть определенных в игре целей: пройти игру до конца, прокачать персонажа, накопить богатство, побить рекорд или заработать награду.

Киллеры (Killers) получают удовольствие, причиняя неудобства другим игрокам и показывая свое над ними превосходство. Им особенно по душе шутеры от первого лица и прочий PvP-контент. Но речь не обязательно об убийствах: они также могут контролировать внутриигровую экономику, накапливая ресурсы и манипулируя спросом и предложением, и это тоже не будет противоречить типажу. Убийцы приходят в восторг, если кто-то другой им проигрывает.

Коммуникаторы (Socializers) любят общаться с другими игроками. Как правило, такие игроки преуспевают в роли лидеров гильдий, кланов или групп и наиболее эффективно проявляют себя при взаимодействии с другими игроками. Коммуникаторы наиболее комфортно чувствуют себя в мультиплеерных играх, где командная работа является ключевым элементом геймплея.

Исследователи (Explorers) мотивированы желанием открывать для себя новые вещи. Они любят открывать новые или скрытые области, обнаруживать сбои в игре или использовать творческие игровые механики. Им также по душе находить в играх спрятанные пасхалки.

Эти четыре типа помогают понять, как игрок взаимодействует с игрой. Киллеры любят воздействовать на других игроков, а карьеристы любят воздействовать на игровой мир. Коммуникаторы любят взаимодействовать с другими игроками, а исследователи любят взаимодействовать с игровым миром. Картинка ниже поможет лучше понять мотивацию каждого психотипа.




Как игры наказывают исследователей


Легко увидеть, как геймдизайнеры учитывают желания киллеров, карьеристов и коммуникаторов. Почти во всех современных играх есть система достижений, в соответствии с которой игроки могут получить награды или трофеи за выполнение определенных задач. Киллеры развлекаются как могут, пока дизайнеры дают им получить преимущество над другими. Коммуникаторы счастливы, пока в игре можно беспрепятственно общаться. Но что насчет исследователей?

Исследователей часто наказывают за то, что они играют в игры так, как они хотят. А они любят подходить к игре с фантазией, искать лазейки то есть, все, на что геймдизайнеры обычно не рассчитывают.


Скрытые области


Скрытые области это места на игровой карте, заблокированные невидимыми стенами или другими препятствиями. Дизайнеры оставляют в игре локации, к которым у игроков не должно быть доступа. Для исследователей стремление попасть в такие места делает игровой процесс чрезвычайно увлекательным. Раньше нередки были случаи, когда разработчики жестоко обходились с игроками, прорывающимися в такие области, но почему?

Существует три ситуации, когда это действительно должно быть наказуемо:

  • Игрок получает доступ к разрушающим качественный игровой опыт предметам и использует их. Мы могли это наблюдать в 2019 году, когда Bethesda заблокировала аккаунты игроков, получивших доступ в комнату разработчиков Fallout 76, где хранятся абсолютно все игровые предметы, включая броню и оружие.
  • Игрок получил доступ к чему-либо вразрез Пользовательскому соглашению (Terms of Service (ToS)). Обычно это значит, что игрок использовал некий чит-код например, удаляющий невидимые стены, ускоряющий героя или позволяющий ему летать там, где он хочет.
  • Доступ к скрытой области дает игроку явное преимущество над остальными. Такое часто встречается в шутерах от первого лица, где игроки могут попытаться проникнуть в скрытую область карты, откуда удобно убивать ничего не подозревающих противников.

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


Та самая комната разработчиков


Необычное использование игровых механик


Создатель YouTube-канала Archvaldors Warcraft Hacks недавно опубликовал видео под названием Как меня забанили за БОТОВ при отсутствии ботов. В этом видео он объясняет, как его забанили в World of Warcraft по запрету Activision-Blizzard. Этот запрет должен был решить проблему ботов, которая всегда преследовала игру. Единственная проблема заключалась в том, что Арчвальдор не использовал никаких ботов.

Как он думает, кто-то пожаловался на него, как на бота, потому что он пытался получить доступ к области, заблокированной воротами. Чтобы добиться своей цели, он бежал к воротам и пытался применить на них ряд различных способностей, чтобы посмотреть, сработает ли что-то из этого. Гейм-мастер (сотрудник Blizzard, которому поручено решать внутриигровые проблемы) уделил проблеме буквально несколько секунд, а затем исчез. Впоследствии он игнорировал все попытки Арчвальдора выйти на диалог, а спустя три недели тот оказался забанен на полгода без права обжалования после попытки подняться по местности в другой области игры.

Исследователи всегда были законной частью базы игроков. Некоторые люди не заинтересованы в том, чтобы проходить игру так, как это делают другие. Вместо этого они хотят заглянуть за кулисы. Они хотят достигнуть удовлетворения от выполнения последовательности сложных действий, которые приведут их туда, куда у других игроков нет доступа. Они хотят выйти на новый уровень и найти эксплойты, позволяющие подойти к геймплею с креативом. О таких игроках разработчики слишком часто забывают, а затем наказывают за их усилия.

Это не первый раз, когда Activision подвергается критике за чрезмерный бан. Они также получали негативную реакцию за то, что банили игроков на 10 лет в Call of Duty Mobile буквально ни за что. Похоже, что в попытке сделать игры честными для игроков античит-программы предпочитают избавляться от исследователей наряду с ботами. И если для того, чтобы избавиться от ботов, нужно перебанить и всех исследователей что ж, пусть будет так.


Что исследователи привносят в игры


Итак, исследователей часто наказывают за то, что они делают, но почему это так важно? Могут ли игры позволить себе их потерю? Нет, нет и еще раз нет. Считается, что исследователи в среднем составляют 10% от базы игроков.

Исследователи хороши тем, что составляют активную часть сообщества игр, в которые они играют. Они любят создавать контент и общаться на форумах. Это помогает привлечь новых игроков. Как правило, они имеют глубокое понимание игровой механики и того, как работает игра, а значит, хороши в обучении новичков. А созданием новых видов геймплея они помогают удерживать в игре тех, кому стало в ней скучно.


Как создавать игры для исследователей


Если исследователи являются законной частью игрового сообщества, которое разработчики не могут игнорировать, то как создавать игры, которые будут интересны для них? И как при этом сохранить целостность игры?


The Legend of Zelda: Breath of the Wild всегда поощряла игроков исследовать свой мир


Поддержка творческого использования игровых механик


Во-первых, разработчики игр должны расширить понятие того, как следует играть в их игры. В последние годы некоторые MMORPG обвинялись в том, что они стали MMO в духе тематических парков. Это означает, что все игроки движутся по одному и тому же игровому сценарию. Свобода игрока уже не столь важна на первый план выходит сюжетно-ориентированная составляющая игрового процесса. Так устроено большинство однопользовательских линейных игр, и этот подход показывает себя очень эффективно. Игроки The Last of Us не жалуются, что не могут исследовать открытый мир. Зачем им это? Они купили игру ради захватывающей истории и развития характеров героев. Но MMO совсем другой жанр, где исследование открытого мира и свобода игроков являются ключевыми понятиями.

Если разработчики пересмотрят то, как следует играть в их игры, исследователи тоже смогут повеселиться. До тех пор, пока действия игрока не идут вразрез с ToS и не ломают игру, какой вред в том, что исследователи играют в нее по-своему?


Сложность


Различия сложности в игре один из тех аспектов, что может порадовать исследователей. Как правило, их не интересуют награды в том смысле, в котором это привычно для карьеристов. То есть, обычные методы геймификации на них работают плохо. Чем больше элементов сложности в игре, тем больше у исследователей возможностей открывать новые вещи.


Пасхальные яйца


Стоит добавить в игру больше пасхалок. Это просто и очевидно, ведь исследователи любят находить пасхальные яйца, а разработчикам не нужно беспокоиться о том, что в их игру играют как-то не так. И все остаются в выигрыше.

Вот пара примеров таких пасхалок:

  • В Doom 2 есть секретная концовка, открывающаяся в случае, если игрок выстрелит боссу в лицо и затем пройдет по нему. В этом случае вы увидите голову геймдизайнера игры Джона Ромеро, насаженную на кол.
  • Если в Saints Row 2 вы отправитесь на скрытый прибрежный остров и побродите по его побережью, но увидите огромного фиолетового кролика, поднимающегося из глубин океана.




Удаляйте контент только в случае необходимости


Если область или контент не нарушают правил игры, лучше сохраните их. Многие разработчики тут же удаляют контент, как только понимают, что их невидимые стены не мешают игрокам. Если есть весомая причина, чтобы удалить его, например, если он даст игроку какое-либо преимущество, то да, следует контент удалить. Но если вреда в его обнаружении нет, почему бы его не оставить на радость исследователям.
Подробнее..

Бесплатный онлайн-Лекционный вечер по геймдизайну

08.09.2020 16:22:26 | Автор: admin
16 сентября (Среда), в 18:00, состоится бесплатный Лекционный вечер по геймдизайну, в онлайн-формате.



Вас ждут три интересные лекции:

1) Карьера геймдизайнера: как понять чего вы хотите на самом деле и достичь этого.
Спикер: Константин Сахнов совладелец издательства JustForward, игровой продюсер.

2) Геймдизайн: что делает игру интересной.
Спикер: Владимир Агарев Креативный продюсер в компании Gaming Point.

3) Работа геймдизайнером в игровой компании.
Спикер: Георгий Миронов Game Designer в 1C Game Studios.

Мы приглашаем инди-разработчиков, сотрудников игровых компаний, студентов, всех, кто хочет делать собственные игры или играет в игры.

Участие в мероприятии абсолютно бесплатно.

Все подробности и регистрация доступны по ссылке >>>
Подробнее..

Микрокосм, демоверсия

23.10.2020 18:08:20 | Автор: admin
Всем доброго дня, в какой бы галактике вы не находились.
После череды итераций прототип космической jrpg, разрабатываемый на Godot engine, дорос, наконец, до первой демоверсии. Доступны win64 и linux варианты. Ниже подробности о том, что было, что стало и куда летает маленький звездолёт.


Каркас


Наброски базового геймплея сформировались довольно быстро, когда я перешёл от продумывания основных положений концепции к сборке игрового прототипа внутри игрового движка. Сначала появился стартовый экран, сцена глобальной карты с движением и возможностью вызова инвентаря. Тогда же была продумана некоторая начальная архитектура как именно грузить отдельные модули и обмениваться информацией между ними.
Затем появился экран сражения, запускаемый сначала по отдельной кнопке, а позднее привязанный к столкновению с врагами. Позже добавился экран планеты, у планет к тому времени появился информатор на глобальной карте, куда и была добавлена кнопка посещения. От информатора в свою очередь отпочковались прочие виды интерактивных объектов, например станция, не подразумевающая входа на свой внутренний экран, но иногда имеющая какой-то внешний функционал с возможностью что-то нажать или выбрать. Или подбираемые ресурсы космическая пыльца.
Далее требовалось реализовать максимально возможную партию героев (выбирая между 3-мя либо 4-мя, я выбрал всё-таки концепцию партии из 3-х), что и было сделано. В процессе добавилось отображение повреждений, выбор целей для атаки, немного музыки.
На этом этапе можно было уже выкладывать мини-демку, но я решил сначала доработать проект до более комплексного состояния, чтобы было лучше понятно, что это вобще такое и как оно примерно должно работать. Попутно добавив немного контента и каких-то украшательств, типа озвучки действий, анимаций.

Почитать подробнее про концепцию и базовую реализацию можно в этих статьях:
Microspace project
Итеративный геймдизайн, Godot и мир маленьких планет



Развитие прототипа


Рассмотрим различные области, в которых происходило это развитие:

Бой

Количество доступных кораблей понемногу увеличивалось, как и количество доступных врагов, поэтому я шаг за шагом переписывал их боевое представление и управляющую логику в более универсальный вариант. Что было не так уж сложно, благодаря тому, что подобный ход событий был предусмотрен и что-то в коде оптимизировалось заранее.

Отображение повреждений поначалу было реализовано через 3д-представление вывод вьюпорта со строкой урона на обращённый к камере полигон. Это более менее работало, хотя реализация технически мне не очень нравилась, так как с вьюпортом всё немного заморочено нужно вешать его поближе к корню сцены, чтобы не возникало сбоев и проверять как выглядит эффект чуть сложнее, чем с просто выводимой 2д-строкой. Поэтому много вьюпортов заводить не хотелось, я обходился всего одним, перемещая выводящий его полигон куда нужно, попутно увеличивая/уменьшая. А ведь надо думать и о том, что когда-то появятся способности, наносящие массовые повреждения и потребуется выводить как минимум три значка с уроном одновременно (хотя и тут можно исхитриться, сделав как бы анимацию-волну из одного и того же объекта или уж завести ещё пару вьюпортов).
Однако, когда я добавил в прототип режим полного экрана, то там цифры повреждений стали заметно так размываться, поэтому ещё сильнее захотелось рассмотреть иные варианты отображения урона. В принципе я мог бы просто фиксировать камеру в бою, но я зачем-то продолжаю до упора сохранять возможность вертеть ею в моменты между ожиданием действия.
Поэтому в итоге я переписал вывод урона. Теперь 2д-строчки цепляются к проекции позиции 3д-объекта. Хотя тут тоже есть свои нюансы, например, если отвернуть камеру, то они продолжат показываться или если их выводить беспрерывно в каждом кадре, то есть возможность подвесить текущую камеру в одном положении, но это уже решаемо.

Для ускорения процесса тестирования давно была сделана специальная, как-бы неигровая, кнопка автоматической победы, если требовалось выйти из боя. Также долгое время не было возможности проиграть. Потом я добавил замораживание корабликов при обнулении их полоски и далее уже напрашивалась полноценная реализация проигрыша сражения. Для этого я сначала перевёл кнопку автопобеды в разряд полноценных игровых опций, с той лишь разницей, что теперь это стало экстренной кнопкой автоматического проигрыша, запускающей диалог выхода из боя. А затем дописал провырки для автоматического завершения сражения при нулевой прочности всех корабликов, также вызывающие этот диалог.
После поражения в сражении враг исчезает, а прочность каждого кораблика партии в следующем сражении будет равной 10. Кстати, верхней границы прочности пока нет и различным лечением можно повышать прочность сверх базовых значений.

Корабли и враги

Тут всё просто было три, стало десять. Каждому требовалось заводить параметры и свою иконку, а также постепенно включать их в игровой процесс и связанные с выбором кораблей опции. Сначала новые кораблики становились доступными на глобальной карте и в переборе на планетах, потом уже они постепенно интегрировались в сражение.

Противников тоже прибавлялось, к тому же с разными подходами. Один враг, пара разных врагов, пара одинаковых, более крупный враг с двумя атаками, мини-босс состоящий из нескольких частей.

У четырёх корабликов есть личные способности, которыми можно пользоваться в сражении. Это Скиталец (способность наносит урон и даёт прибавку к следующей атаке), Спира (улетает в будущее, на ход вперёд, получая по возвращении бонусный урон к следующей атаке), Тринити (просто наносит урон) и Отомо (раскладывает на всю партию лечащие прибавки к следующим атакам).
На применение способностей тратится некоторый процент энергии корабля (на данный момент эта энергия ничем не восстанавливается). У прочих кораблей на месте личной способности установлена способность-заглушка Щит, играющая анимацию, но не имеющая эффекта.

Способности и персонажи

Если корабли являются неким аналогом главных героев, то перевозимые ими персонажи являются неким аналогом оружия этих героев. Одним из важных моментов, который хотелось отразить в проекте это использование системы идентификаторов, которые дают эффект неслучайной случайности, а при более широком использовании могут работать на генерацию псведо-сюжета. Говоря по-простому, у персонажей, кораблей и врагов есть специальные ID, позволяющие рассчитать результат взаимодействия любых этих объектов и как-то его использовать.
На данный момент использование этого результата следующее. Во-первых, у каждого персонажа и корабля возникает эффект совместимости. То есть, оказавшись на борту корабля, персонаж может, например, начать паниковать, уснуть, или не понимать как обращаться с его системами. Сейчас просто в окошке инвентаря выводится результат связи корабль-пассажир и возможный дополнительный эффект, ею накладываемый. Но на участии персонажа в бою это пока никак не отражается.
Непосредственно в сражении персонажами можно атаковать через опцию Экипаж. Это не просто совершение персонажем какого-то конкретного действа, вроде конкретного магического заклинания или выстрела из оружия. Это некая ситуация, повлекшая за собой определённое количество потерь со стороны противника. Здесь работает уже связь пассажир-враг, которая интерпретируется окружающим миром (в данном случае космическим сектором) в одно из девяти последствий: #СВЕТ, #ТЬМА, #МУЗКА, #ТЕОРИЯ и так далее. То есть игрок может ассоциативно представить, что сделал персонаж, что получилось последствие с такой формулировкой (а может и не представлять ассоциации дело необязательное, тем более они всё-равно сами по себе работают где-то в фоне). У каждого врага соответственно есть уязвимости или стойкость к определённого вида последствиям. Возможно, в дальнейшем применение системы идентификаторов ещё более разрастётся. Например, на тех же планетах могут действовать их собственные ауры смыслов, видоизменяющие таблицу интерпретаций, но сначала нужно реализовать там какие-то события, в которых участвовали бы идентификаторы.

Некоторые редкие персонажи обладают активными способностями для кораблей определённого типа. Кстати, пока не у всех таких персонажей подписано, что они дают какую-то способность (в основном это касается тех, которых сейчас нет в основном режиме игры).
Как бы то ни было, на данный момент способности, получаемые от перевозимых персонажей, всего-лишь проигрывают эффект-пустышку (как и большинство предметов). Зато у одного героя, Лето, есть пассивная способность, без привязки к типу корабля, и она уже работает.
Спира и Скиталец кроме этого могут изучать способности персонажей своих типов (хотя у них пока и отсутствует эффект), проведя с ними одно сражение.

Предметы

До грузов всегда дело доходило во вторую очередь, после того как уже была готова реализация для персонажей. В основном всё сводилось к тому, чтобы показывать их ячейки и перемещать заглушки предметов между ними. Но позднее появился активируемый предмет, Жива, восстанавливающая 100 прочности корабля. К тому моменту я как раз начал делать боевую опцию Трюм и требовался хотя бы один предмет с каким-то реальным эффектом.
Что касается самого лечащего предмета, то изначально планировалось, что может быть у него будут какие-то заряды и их можно будет где-то восполнять. В итоге я оставил один заряд и сделал так, что этот предмет умеет разряжаться при использовании и заряжаться снова от собранной космической пыльцы.

Экран планеты и задания

На планетах можно обнаружить различные протекающие там процессы и события. Некоторые идут своим ходом с самого начала, некоторые запускаются когда исполнилось предыдущее или появляются в определённый световой день. Среди этих событий уже есть и пара задач, запускаемых при помощи игрока, если у него есть необходимое количество ресурса.

С информации о планетарных событиях можно переключиться на вкладку кораблей, где можно просматривать их трюм и экипаж, а также взять в активную партию от одного до трёх выбранных звездолётиков. Ещё на планетах есть небольшое место под персонажей и предметы, откуда их можно перемещать внутрь кораблей или наоборот, высаживать на планету.

Прочее

В открываемый во время космических перелётов инвентарь добавлена опция компас, помогающая долететь до выбранной точки. Появляется специальный указатель с расстоянием до места назначения. Этот навигатор работает только в основном игровом режиме.
Помимо этого в инвентаре можно включить/выключить звуки и музыку, поменять главный кораблик в текущей партии, включить/выключить полный экран, а также выйти из игры в стартовое меню.
Информация о членах экипажа и экипажа и грузах в инвентаре упрощённая и во время полёта их нельзя перемещать.

В некоторые световые дни теперь появляются специальные уведомления. Сами эти дни проматываются посещением любой планеты (в дальнейшем нужно будет летать между разными, для смены дня).

Постепенно были улучшены шрифты некоторых элементов. Появилось некоторое количество звуков для боя, для экрана планет, для инвентаря.

Также была сделана заготовка для специальных зон, с реалистичным полётом и масштабом объектов. В ней можно оказаться во время игры, коснувшись специального объекта. Внутри можно немного полетать на кораблике Тринити с немного изменившимся управлением, а чтобы выйти достаточно долететь до границы этой области.

Демоверсия


Уже непосредственно перед появлением демоверсии для неё был создан режим последовательного развития, как основной вариант игры здесь игрок получает один стартовый кораблик (Скиталец) и начинает исследовать сектор, открывая новые звездолётики для присоединения к партии. Таким образом в этом режиме можно открыть ещё два кораблика (Спира и Авангард). В стартовом секторе есть три планеты, которые можно посетить. Починив специальную станцию можно переместиться во второй сектор и найти там ещё одну доступную планету.

Ранний тестовый вариант локации, где различные планеты и враги размещены более плотно, доступен в альтернативном, менее отлаженном, режиме игры all ships test. Там сразу доступен выбор из 10 существующих кораблей (в активную партию можно брать до трёх), больше героев/грузов и распределены они иначе. Могут возникать некоторые наложения внутриигровых параметров после выхода из одного режима и переключения на другой.

Нововведения последнего обновления показаны в новом ролике, где помимо геймплея добавлены элементы тизера.

Видеонарезки некоторых предыдущих обновлений








Загрузить архив демки можно здесь (dropbox):

Win64 версия (50 Mb)

Linux версия (52 Mb)

Управление:

WASD полёт, мышь вращение камеры
Enter открыть/закрыть инвентарь во время полёта в космосе


Кораблики: 1 Скиталец, 2 Спира, 3 Авангард, 4 Дева Яга, 5 Мухх, 6 Стелла, 7 Тринити, 8 Отомо, 9 Аквамарин, 10 Гиибель.

Подробнее..

Из песочницы Геймификация в бизнесе. Основы

17.07.2020 14:11:33 | Автор: admin
image

Я с дества очень много играл в компьютерные игры. Но только недавно я стал задумываться о том, как игры работают и из чего состоят.

А связано это с моей профессией продуктового дизайнера, которая в основном состоит из улучшения показателей привлечения, вовлечения и удержания пользователей.

И вот уже как год я изучаю сферу игр той сферы, которая научилась управлять эмоциями пользователя лучше всего.

В этой серии постов я хотел бы раскрыть геймификацию (иногда ГМ) в дизайне и бизнесе.

Кому будет полезно?


Основателям бизнесов, в которых повышение вовлечения и удержания пользователей приводит к значительным увеличениям показателей бизнеса.

Сотрудникам, которые хотят повысить показатели своей зоны ответственности. Потому что изучение даже нескольких кейсов по геймификации добавит в продукт десятки новых гипотез.

Даже обычные люди внедряют игровые механики в свою жизнь для прививания привычек и увеличения продуктивности, становясь успешнее с каждым днем.

Что такое геймификация?


Геймификация это применение игровых механик для неигровых процессов.
Правильное применении этого инструмента позволяет повысить вовлечённость участников в решение прикладных задач, использование продуктов, услуг или усилить лояльность клиентов.

Этот термин содержит в себе такой же корень как и Game, под которым в наше время больше представляют компьютерные игры. И это не случайно, ведь эта сфера бизнеса лучше всех научилась вовлекать, развлекать и удерживать пользователей.

Ведь когда пользователь заходит в игру, то в большинстве своем единственная цель этого действия хорошо провести время.

Это то, к чему стремится любой бизнес. Чтобы продукт или определенная активность ассоциировалась с хорошим времяпрепровождением. Потому что без дешевого вовлечения и долгого удержания пользоваетля юнит экономика многих продуктов будет убыточной.

Для более глубокого понимания нужно понять, что такое игра, и почему люди играют

А что такое Игра (Game)?


Один философ Бернард Сьютс, высказал свое видение определения игры, которое я считаю коротким и достаточным:
Игра это добровольное преодоление необязательных препятствий.

Ссылаясь на Бернарда Сьюта, игра содержит в себе:

  1. Цель это конкретный результат игры, к которому стремятся игроки. Она направляет внимание игрока и координирует его действия, в результате у участников возникает ощущение цели. Если это забег на сто метров, то цель это пробежать от старта до финиша. Если это шахматы, то цель убить короля оппонента
  2. Правила, которые делают активность игрой. Правила устанавливают ограничения на способы достижения цели, что побуждает игроков исследовать неизведанные пространства возможностей. В шахматах вы не можете просто смахнуть все шахматы оппонента с доски. Вы не можете ходить пешками через всю карту. Конь это конь, королева это королева.
  3. Система обратной связи сообщает игрокам, насколько они близки к достижению цели. Эта информация может быть представлена в виде очков, уровней, счета или индикатора прохождения игры. В самом простом случае система обратной связи сводится к пониманию игроком целевого результата: Игра будет окончена, когда Обратная связь в реальном времени как бы уверяет игроков, что цель достижима, и мотивирует продолжать игру.
  4. И наконец, добровольное участие требует, чтобы каждый игрок осознанно и самостоятельно принял цель, правила и систему обратной связи. Осознание создает общую основу для совместной игры большого количества людей. Т.е. участники следуют правилам и делают это добровольно. Если участники принуждаются, то это уже не игра

Whoever who must play can not play
If you forced to do something, it's not a game


А раз геймификация происходит от игр, то она также должна содержать в себе:

  1. Добровольность участия
  2. Обучение чему-то или решение определенной проблемы.
  3. Цель и правила достижения этой цели
  4. Нарратив. А именно структура, которая объединяет фрагменты игры или игровую систему в единое целое. Иначе есть риск, что геймифицированная система будет просто кучей абстрактных вещей.
  5. Правильный баланс системы. Недостаток сложности сделает игру неинтересной, а большое кол-во правил и сложности увеличит порог вхождения и, соответсвенно, активную аудиторию вашей системы.

Геймификация это не попытка превратить все в игру.

Она используется не только для привлечения или вовлечения пользователей.

И это не только очки, бейджи и таблицы лидеров

Геймификация это изучение механики игр (не только виртуальных) с пониманием того, почему нам нравятся игры. Если разобраться в этом вопросе, то мы сможем сделать наши продукты почти такими же вовлекающими, как игры. Разобраться в этом поможет изучение геймдизайна, психологии и отношений между людьми.

Атомарная структура геймификации


Как и все системы, геймификацию тоже можно разобрать на элементы, из которых она состоит. Я взял фреймворк by Kevin Werbach, который придумал свою пирамиду элементов. Этот фреймворк даст вам понимание того, из чего состоят и как связаны разные элементы геймификации между собой.

Но нужно понимать, что нельзя взять элементы из списка ниже и собрать из них что-то, что сразу повысит показатели вашего бизнеса в несколько раз. Игры это не просто элементы, которые каким-то образом склеены друг с другом. Игры это абстракции, которые разработаны систематически, продуманно, с возможностью влиять на эмоции игрока и, главное они должны быть веселыми.
Fun makes games engaging
Пирамида элементов это структура стандартных элементов в геймификации и связь между этими элементами.

Эта пирамида не отражает все возможные элементы. И это не значит, что каждый элемент нужно внедрять в свою систему.

image

На верху пирамиды находятся Динамики. Это наиболее высокоуровневые концепции в играх или геймифицированных системах. Можете представить это как грамматику в языке, а именно спрятанные структуры, которые делают весь опыт связанным и имеют регулярные паттерны.

Этот уровень содержит:

  1. Сonstraints Каждая игра должна иметь ограничения. Искуственно ограничивая свободу, игры создают осмысленную цель и добавляют интересные проблемы, решение которых не раздражает игроков. Таким образом, представление о том, какие ограничения накладываются на пользователей, является важной динамикой, о которой должен думать любой дизайнер геймифицированных систем.
  2. Emotions Игры могут вызывать практически любые эмоции, от радости до грусти и всего, что между ними. Эмоциональная палитра геймификации, как правило, несколько более ограничена, потому что мы имеем дело с реальным миром, неигровым контекстом. Но все еще существует множество эмоциональных рычагов, которые можно использовать, чтобы сделать пользовательский опыт более насыщенным.
  3. Narrative структура, которая объединяет фрагменты игры или игровой системы в единое целое. Нарратив может быть явным, сюжетной линией в игре или неявным. Без нарратива есть риск, что геймифицированная система будет просто кучей абстрактных вещей.
  4. Progressive это значит что пользователь видит начало пути, у которого он сейчас находится, и то, куда он придет если будет следовать правилам. Прогрессия не обязательно требует присутсвие уровней, шкал прогресса и очков. Но это самые типичные компоненты, которые используются для создание данной динамики
  5. Relationships эта динамика рассказывает о том, как люди взаимодействуют друг с другом. Сюда входят друзья, члены команд и противники. Эти динамики очень хорошо развиты в таких играх как WoW, La2 и других ММО играх.

Затем идут механики набор правил и способов, реализующий определённым образом некоторую часть интерактивного взаимодействия игрока и игры. Все множество игровых механик игры формируют конкретную реализацию её игрового процесса

  • Challenges
  • Chance
  • Competition
  • Cooperation
  • Feedback
  • Resource Acquisition
  • Rewards
  • Transactions
  • Turns
  • Win states

И самый нижний уровень пирамиды, компоненты. С этими элементами пользователи взаимодействуют напрямую и, в основном, непосредственно наблюдают только этот уровень. Это определенные блоки, из которых собираются механики и динамики.

  • Achievements
  • Avatars
  • Badges
  • Boss fights
  • Collections
  • Combat
  • Content unlocking
  • Gifting
  • Leaderboards
  • Levels
  • Points
  • Quests
  • Social graph
  • Teams
  • Virtual goods

Например points находятся на самом низком уровне уровне компонентов. Из points можно построить структуру более высокого уровня механику прогрессии. И затем эта механика станет частью нарратива уровня динамики.

Нижний уровень пирамиды является основанием для постройки хорошего игрового опыта, в то время как верхние уровни влияют на то, какие именно элементы с нижнего уровня мы применим

Есть еще один уровень вне этой пирамиды это эстетика (Aesthtic). Она описывает желаемые эмоции, которые должны возникнуть у игрока, когда он взаимодействует с игрой.

Комбинация этих четырех элементов создает весь игровой опыт

На первый взгляд тут слишком много элементов. Но вы сталкиваетесь со многими из них каждый день и даже можете написать свои варианты:

Challenge (уровень механик)

Ежемесячные премии в отделе продаж за выполнение плана
Подарки в спортзале тем, кто проплывет 10км за месяц

Levels (уровень компонентов)

Карта лояльности с уровнями для часто летающих пассажиров.
Повышения на работе

Teams (уровень компонентов)

Читательские клубы
Армия
Фанатская символика

Reward (уровень механик)

Одна бесплатная мойка за каждые десять.
Кешбек за покупки

Badge (уровень компонентов)

Платиновая карта в банках или авиакомпаниях
Медали
Красивые номера на машине
Геймификация это не просто набор практик,
а один из способов решения стоящих перед вами задач

Чего не нужно делать при внедрении геймификации


Для геймифицированных систем, как и для игр, нет правил насчет того что правильно а что нет. Но есть моменты, которых лучше избегать, особенно если вы внедряете геймификацию первый раз.

  1. Принуждать пользоваться системой. Вспомните главное правило игра должна быть добровольной.
  2. Поощрять и наказывать материально. Я расскажу подробнее об этом в следующих постах, но основная проблема связана с тем, что деньги не мотивируют людей, а попытки наказать деньгами воспринимаются очень лично и негативно
  3. Внедрять геймификацию ради геймификации. Геймификация должна направлять людей и помогать им либо решать проблемы, либо учиться.
  4. Делать слишком много правил и ограничений. Чем больше правил, тем сложнее запомнить их, а чем больше ограничений, тем более ограничен игрок. А никто не любит, когда их ограничивают
  5. Не продумывать баланс. В игре должен быть баланс и прогрессия сложности, которая будет учитывать как интересы новичков, так и потребности мастеров

Когда вы немного погрузитесь в мир геймифицированных систем, вы можете подумать:
Великолепно, я вижу, что внедрение бейджей и наград в Nike Plus повысило показатели вовлечения на 10%. Что ж, я тоже добавлю эти элементы в свой продукт и люди начнут им пользоваться активнее.

Оказывается, это не так просто. Делать геймификацию правильно, этично и так, чтобы это соответствовало вашим конечным долгосрочным бизнес-целям это не самая простая задача.

Создание таких систем требует обдумывания и глубокого понимания таких областей как психология, дизайн поведения, игры и визуальный дизайн.

Но когда вы научитесь этому, то сможете создавать продукты, которые будут вызывать эмоции у людей и удерживать их у вас.

Вы станете думать не просто о том, как повысить определенные метрики продукта, но о том, как вызвать такие эмоции у пользователя, за которыми он будет возвращаться в ваш продукт снова и снова.

Учитесь управлять не метриками, а эмоциями пользователей


P.S.


Это первая статья из серии постов про создание геймифицированных систем. В следующих постах я буду разбирать психологию мотивации, эмоции и реальные примеры продуктов с удачным и неудачным внедрением ГМ

В статье я иногда использую материалы и цитаты из двух курсов:

Первый курс это Gamification от пенсильванского университета за авторством Kevin Werbach

Второй курс бесплатный и одновременно интересный это обучение геймификации в геймифицированном мире от Yu-kai Chou
Подробнее..

Microspace project

14.08.2020 22:08:54 | Автор: admin
Концепция игры жанра jrpg, в сеттинге сюрреалистического космоса. В качестве героев выступают разумные звездолётики. Они летают по миру маленьких планет, перевозят различных персонажей и грузы, помогают планеткам развиваться.




Название проекта условное и многие моменты не принципиальны, чем это обернётся в итоге уже дело практики. Сама идея появилась как некая точка пересечения сразу нескольких моих задумок, как способ раскрыть какие-то механики, повод заняться определённым видом геймплея, и в целом некое подходящее пространство, куда можно поместить разных своих персонажей, ситуации, и прочие наработки. Космос сам по себе достаточно благодатная тема, а уж с уклоном во всевозможные сказочно-фантастические направления, тем более.

Герои




Wanderer/Скиталец

Так как предполагается жанр jrpg, то подразумевается, что игрок управляет командой из нескольких героев. В партии ориентировочно могут находится до трёх корабликов. В режиме путешествия летает главный, а во время сражений на поле появляется вся команда.

У космических корабликов есть уровни, но их скорее всего будет немного (максимальный десятый, например).
Тип указывает на природу звездолёта, всего их четыре эволюционный, божественный, магический и технологический.
От класса зависит характер героя и то, как он привык обращаться с энергией. Классов тоже четыре излучатель, пожиратель, аккумулятор и трансформатор.
Способности кораблика базируются на сочетании типа и класса, но здесь всё упирается в конкретную реализацию самих этих способностей и ответа на вопрос, насколько способности кораблей будут уникальными и как появляются. То есть зашиты ли они внутрь самого носителя, и каким именно образом. Либо они полностью или частично могут быть получены любым звездолётиком. Может быть способности вовсе целиком и полностью определяются текущим составом экипажа.


Maiden Yaga. Концепт экрана инвентаря

На борту корабля могут находится различные персонажи, так сказать герои наши меньшие. По сути они выступают тут в роли некоего оружия для звездолётиков и могут дать кораблику те самые специальные способности, побывав на нём в нескольких сражениях.
Как вариант могут быть особо редкие уникальные персонажи, которых нужно найти один раз, а большую часть времени звездолёт может встречать различных неуникальных, но всё-таки именных личностей, которые сгенерированы игрой по некоторому шаблону.

Гостевые персонажи по-своему капризные могут заболеть и временно ослабить свои эффекты, устать и отказываться применять способности, не понимать устройство данного типа корабля, спешить по делам на какую-либо планету и отказываться до тех пор пересесть в другой корабль. Среди таких персонажей могут быть органические либо неорганические представители (различные разбиения по типам, даже простые, всегда дают некоторую пищу для геймдизайна, потому как появляются некие новые элементы, вокруг которых можно строить новые механики или обогащать ими уже существующие), которые будут по разному реагировать на всевозможные вражеские воздействия. У гостей, вероятно, можно будет пробудить и какие-то скрытые до поры силы, привозя их на определённые планеты, взяв определённый груз или собрав их на одном корабле с другими персонажами.

В трюме кораблика находятся какие-то грузы с полезными эффектами, квестовые артефакты, расходные предметы и так далее. И в этом моменте напрашивается важное отличие от классических представителей jrpg ограниченный, нерезиновый инвентарь. По крайней мере тут можно обдумать оба варианта и остановиться на более подходящем.

Сражения




Концепт экрана сражения

В местном космосе встречаются различные враги, в том числе, видимо, враждебные звездолётики. Бой со всеми этими агрессорами происходит по канонам jrpg, с накапливающейся по времени шкалой активности. Правда было немало игр, отображающих саму очередь сражающихся, но лично мне как-то милее накапливающиеся полоски (по крайней мере в рамках данного концепта).

У каждого кораблика есть прочность (здоровье, зелёная полоска), запас сил (степень усталости, желтая полоска), энергия (аналог маны, синяя полоска).

При достижении нулевого запаса сил кораблик входит в состояние перегрузки, позволяющей совершить особо мощный приём. После этого он может делать лишь стандартные атаки, пока жёлтая шкала не будет восстановлена, но она не растёт со временем и восстанавливается только редкими предметами. Запас сил можно тратить самостоятельно, на особо мощные способности, а также его понижают определённые вражеские атаки.

Основу боевой системы я решил взять из своей тактической настольной ролёвки, для которой ранее придумывал отдельный вариант компьютерной адаптации. Только здесь сражения будут ещё проще, чем тактические. То есть здесь не будет перемещения по клеткам, поэтому нужно будет переосмыслить структуру боя, способности и прочие принципы. С другой стороны нет надобности именно в полной адаптации, скорее я для начала взял оттуда некоторые ключевые элементы а в дальнейшем что-то останется, что-то поменяется, что-то можно будет убрать, сделав акцент на другие механики.

Планетки





Тут следовало бы ожидать подхода, скажем так, а ля Master of Orion захватываем планеты, строим на них всякое, развиваем свою межзвёздную империю и так далее. Тем более что в данной игре я хотел частично воссоздать атмосферу мира маленьких планет из своей настольно-ролевой системы Малая космическая симфония, где героями были сами планеты.

Тем не менее, вместо того, чтобы делать космосим от лица планетки, у нас более активные герои команда путешествующих по космосу звездолётов. Для компьютерной игры это более интересный ракурс на происходящее, как мне кажется. К тому же кораблики не владеют планетками, а просто различным образом участвуют в их жизни. То есть само строительство на планете будет присутствовать, но как у каждой планетки личный план развития, которому можно помогать либо мешать.

Планеты подразделяются на те же 4 типа, что и корабли.
На планетке могут находиться различные постройки. Кораблики помогают открывать саму возможность возведения этих новых сооружений, ищут специфические запчасти для них, различные способы ускорить постройку.

По идее кораблики могут сфокусироваться на помощи определёнными планеткам, чтобы развить их глубже и открыть их специфические артефакты, квесты, прочие возможности. При этом глобальный сюжет может даже отсутствовать и история может состоять из отдельных комплексных событий, которые привязаны к уровню развития конкретных планет. То есть больше такая самопишушаяся песочница, в которой тем не менее спрятаны какие-то штучные прописанные сюжетные ситуации.

Задания полученные у планетки могут быть разные привезти на неё определённого пассажира, доставить груз, найти что-то, уничтожить врага, передать сообщение, шпионить за прочими планетками и совершать диверсии. Возможны и текстовые, внутрипланетные квесты.

Вид самих межпланетных перелётов вопрос достаточно открытый. Может быть это полноценный космос со всеми степенями свободы и возможностью дополнительно пострелять по всяким мелким астероидам вне битв. Может быть какой-то вариант плоского, со своими особенностями.

Прочее



Ну вот, все основные моменты вроде бы озвучил. В проект подходят ещё некоторые концепции, но это либо уже совсем частности и мелочи, либо совсем необязательные фичи, либо сложные механики, которые хотелось бы предварительно протестировать и понять, стоит ли их комплексно встраивать в общий контур.

Например, можно реализовать разные виды урона и защит или же добавить переключатель режимов атак (прицельный, не прицельный). Также есть отдельная система идентификаторов, которую хотелось бы привязать к планетам, но можно распространить и на участников сражения, тогда в бою появится другая интересная система уязвимостей, которая может стать как основной, так и дополнительной (например, на ней могут быть основаны исключительно способности членов экипажа, но не самого звездолёта).

Бонусом ещё немного концептуальных картинок:











Что ещё можно почитать в продолжение темы:

Малая космическая симфония
Настольно-ролевая игра про мир маленьких планет, дающая чуть более полное представление о сеттинге. Описаны принципы и можно прочесть саму книгу правил.

Монстробой
Краткий разбор основных моментов куда более тяжеловесной тактической настольно-ролевой системы, принципы которой частично можно использовать в jrpg.

Вычисляемый сюжет или настольно-ролевая зараза
Варианты системы генерации сюжета через взаимодействие идентификаторов различных объектов мира. Хотелось частично использовать этот способ в вышеизложенной концепции.
Подробнее..

Итеративный геймдизайн, Godot и мир маленьких планет

01.09.2020 20:19:15 | Автор: admin

Итеративный подход

Существуют различные подходы к организации геймдизайна. Я предпочитаю использовать итеративный способ, вернее путь к итоговым механикам и структурам через прототипирование ядра неполной концепции, с последующим многократным тестированием и дополнением. То есть под итерациями понимаются не просто новые слои улучшений, а и сама суть концепции видоизменяется под влиянием результатов её практического применения.

Можно представить себе ситуацию с созданием некоего здания. В одном случае у нас есть уже готовый просчитанный чертёж, по которому остаётся только выстроить запланированный объект, зная чего и сколько понадобится. В случае итеративного подхода, вместо точного чертежа у нас примерный образ, с намётками иерархической структуры, и некий набор инструментов, с помощью которого мы собираемся как-бы вырезать наше здание внутри скал, следуя за конфигурацией породы и вновь открывающимися обстоятельствами.

Естественно, для такой задачи мы тоже могли что-то просчитать заранее, просто в данном подходе мы за свой предварительный чертёж не особо держимся, исходя из того, что в процессе многое может сильно поменяться и даже ожидая этого. Просто сам наш чертёж будет как-бы формироваться в процессе, проходить эволюции от одной формы к другой, вслед за образным прорубанием проходов в скалах. То есть базово мы понимаем, что у нас будет некая точка входа в пещеру, точка выхода и связующий их тоннель. Соответственно сосредотачиваемся на поиске этих нужных мест и построении пути между ними, и расчётах с этим связанных, а к прорезанию полноценных чертогов подземного короля мы придём уже потом, на каком-то из следующих шагов.

Таким образом, итеративный подход, он про эксперименты и как раз ожидает, что при соприкосновении концепта с реальностью будут возникать различные задачи, которые нужно будет решать, адаптируя идею, и в то же время получая через практику новые подсказки о том, в какую сторону её следует развивать.

Перейдём к большей конкретике. В разработке игры это всё означает, что приступая к более менее полноценному прототипу мы в первую очередь сфокусируемся на том, чтобы там работала какая-то самая стержневая механика и определимся с основными проблемами, которые требуют решения на ранних этапах. То есть, проектируя таким образом Марио, нам нужен условный объект-персонаж, который умеет прыгать и бегать в стороны, вот с его отображением и написанием кода прыжков-движения мы и будем разбираться. Для Квейка нам понадобится создать контроллер от первого лица и реализовать возможность создавать пули по нажатию кнопки. Для тактической стратегии - логику поведения фигурок-юнитов на поле сражения, возможность двигаться и атаковать.

Как видно, уже на данном этапе появляются различные вопросы и развилки. А так ли нужен Марио прыжок, должен ли он быть двойным (тройным, неограниченным), как быстро герой движется? Выстрелы в Квейке сделать в виде быстро летящих шариков или лучами, где закрепить камеру, как быстро она поворачивается? Всё тактическое поле боя представить в виде матрицы, хранящей все состояния клеток и положения юнитов внутри неё, или же сделать юниты полноценными отдельными сущностями, ограниченными картой, чтобы получить от такого подхода какой-то особый профит? Какой размер игрового поля, сколько участников?

Если ваше общее видение учитывало эти факторы или явно тяготеет к какому-то одному пути, то часть подобных вопросов решается сходу. В иных случаях вы можете исследовать те или иные варианты, чтобы лучше понять, на каком варианте остановиться. Какие-то вопросы можно отложить, как не особо важные на данном этапе (когда будет заготовка уровня, тогда и скорость движения настроим), или запланировать реализацию сразу несколько решений впоследствии (пусть оружие будет и бесконечное, и с патронами, и лучевое, и бензопила) а пока сделать то, которое проще. Либо упростить задачу и пойти по какому-то другому пути (вместо полноценной тактики на поле делать что-то более элементарное, с меньшим количеством героев, без передвижений и так далее).

Для того, чтобы в процессе разработки было проще маневрировать в ту или иную сторону стоит держать всё по возможности максимально простым, не ударяясь в написание какой-то там очень сложной структуры, которая никак не работает, пока не прописаны все её составные части. В первую очередь самый базовый функционал, с кубиками, пустышками, заглушками, который уже выполняется и передаёт данные, а визуал, декор прочие детали - вещи второстепенные, реализацию которых можно отложить.

Одна из первых целей - это собрать минимальную запускаемую вещь, с началом, серединой и концом. То есть банально окно входа в игру, основной игровой экран и кнопка/окошко выхода. Вход в пещеру, тоннель, свет в его конце. Минимальное приложение, которое уже работает, хотя внутри пока довольно пусто.

Что касается дальнейшей разработки - очень желательно всё фиксировать и записывать. Нет, это не только комментарии в коде, но и просто некий отдельный лог для себя, где-нибудь в элементарном блокноте. Например, я раньше вёл записи в отдельных текстовых файликах, а последнее время пользуюсь компактной опенсурсной CherryTree, где удобно создавать различные ветки и разбивать записи по категориям - сам лог изменений в проектах, лист для описания возможных багов и методов их решения, список различных приходящих в процессе идей, перечень того, что желательно реализовать в первую очередь, заметки по решению каких-то типовых задач в используемом игровом движке и так далее.

Среди приходящих новых идей отмечаем какие-то перспективные, на которые можно перейти сразу или в дальнейшем. Даже если они противоречат каким-то нашим векторам разработки и мы не будем ими пользоваться, всё-равно полезно их записать.

Прототипирование Microspace project в Godot engine

Итак, некоторое время назад я в общих чертах сформулировал концепцию rpg-игры, в которой можно собрать партию разумных звездолётиков и летать по секторам местного космоса, участвуя в жизни маленьких планеток. Подробнее тут:

Таким образом, требовалось собрать прототип, в котором на самом элементарном уровне были бы реализованы какие-то классические ингредиенты jrpg-жанра - режим глобальной карты, режим сражений. Чем я и занялся.

В качестве движка был выбран Godot engine, а конкретнее версия 3.2.1, язык GDScript и gles3 рендер. В целом данный проект относится к категории достаточно код-интенсивных, всё-таки это далеко не аркада, где можно обойтись вобще без программирования. Выбор GDScript'а не особо принципиален, просто на нём быстрее писать внутри редактора, без открытия лишних окон, а так - вся логика без каких-то особых проблем переносится на тот же C#. Gles3 тоже не принципиален, но я взял более мощный рендер в качестве целевой платформы, а на упрощённом всегда можно собрать отдельную версию, только потребуется переработать частицы.

Началось всё с набросков карты сектора и написания контроллера, чтобы добавить модель кораблика и полетать по получившемуся "космосу" (попутно придумалась музыкальная композиция для глобальной карты):

Да, я тут не ограничился совсем уж примитивами и уделил всё-таки некоторое время намёткам визуала. Далее стал добавляться уже более плотный код, касающийся параметров корабля и интерфейсных элементов, например, стало возможным открытие упрощённого окошка инвентаря. По задумке течение полёта с ним не подразумевались какие-то манипуляции, кроме просмотра текущего состояния, а возможность более основательно покопаться в инвентаре я хотел реализовать уже именно при посещении планет, внутри их интерфейса.

Прописывая скрипт для определения столкновений с планетками я подумал, что перед визитом будет сначала всплывать окошко с общими параметрами планеты (или прочего объекта, доступного для посещения), где можно согласиться на посещение либо пролететь мимо.

Подготавливая приблизительные иконки с персонажами/предметами для инвентаря я завёл пару текстурных атласов в формате png, размерами 512 на 512. Таким образом в каждом можно держать по 64 иконки размерами 64 на 64. Godot, кстати, сам умеет сшивать несколько выбранных картинок в атлас, но у меня почему-то эта его функция не срабатывает, поэтому набросал заготовки в графическом редакторе.

Далее был реализован экран сражения, а на карте появились видимые неподвижные враги, коснувшись которых кораблик переносится в сражение. Во время сражения у звездолётика накапливается шкала, после чего возникает пауза, пока не выбрано действие. У врага есть своя, скрытая шкала, к тому же они могут иметь не фиксированные промежутки для различных атак и приёмов. Кстати, отсюда выглядит интересной возможность для персонажа какими-то приёмами ускорять себе следующее действие - именно не разгон себе параметра "скорость" на несколько ходов, а конкретный бонус к скорости на следующее действие, когда совершаешь какую-то разовую утилитарную способность, которая сама по себе не несёт особого боевого эффекта, либо способность тратящую ресурс, которую ты не можешь делать часто.

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

Следующее обновление принесло ещё один важный момент, которого не хватало - собственно, партию героев, к основному звездолётику Wanderer добавились Spira и Vanguard. Появились новые враги, отображение получаемого урона, самописный ориентировочный трек сражения, доработки инвентаря и специальная станция, где можно отправить одного из героев с основного корабля на задние, а потом забрать его, после истечения срока.

Архитектура приложения

Теперь немного о том, как всё это устроенно за кадром. Godot представляет всё в виде иерархически связанных элементов, которые являются различными узлами либо сценами, в которые завёрнуты другие узлы и/или сцены. То есть, у нас, допустим, есть общая "сцена-океан", в которой содержится "узел-солнце" и "сцены-острова", в каждом из которых расклонированы "сцены-деревья" и так далее.

Собственно, про некоторые особенности движка Godot и я рассказывал вот в этой статье:

А внутренняя архитектура прототипа космической jrpg следующая: есть основная 2д сцена - стартовый экран, куда попадает пользователь. При выборе уровня к корню стартовой сцены крепится сцена космического сектора, в которую дочерним объектом крепится звездолётик и на него навешиваются слушатели некоторых сигналов. Сама стартовая сцена при этом скрывается, но её скрипт обрабатывает сигналы от кораблика - столкновение с врагом, открытие инвентаря, попадание в зону планеты. Когда игрок открывает инвентарь, то стартовая сцена снова показывается, но отображает не менюшку входа в игру, а окошко инвентаря.

В том случае, когда игрок решил посетить планету или вступить в сражение сцена с космическим сектором стирается и в корень крепится боевая сцена либо экран планеты. Внутри сражения свои менюшки и стартовую сцену интересует только сигнал об окончании сражения. А вот на экране планеты интерфейсное окошко снова идёт от стартовой сцены. В целом это продиктовано желанием не грузить каждый раз простой интерфейс в составе этих сцен.

Сам кораблик представляет собой объект, содержащий внутри себя сразу все возможные кораблики, и притворяясь то одним, то другим, в зависимости от того, какой кораблик выбран пользователем в качестве основного. По сути это такой элемент трёхмерного атласа звездолётиков. Вражеский объект - это тоже такая спрессованная общность всех возможных врагов, в её скрипте прописан идентификатор, глядя на который она показывает определённого врага.

Примерно таким же образом союзники и враги представлены внутри сражения, принимая вид корабликов партии и демонстрируя расстановку вражеских сил.

В Godot предусмотрена возможность заводить в отдельном окошке синглтоны, которые будут доступны глобально. Я использую один такой для простого хранения глобальных переменных и массивов.

Где брать идеи

Действительно, где геймдизайнеру находить идеи для концепций и механик. На самом деле, буквально в любом источнике, не только в играх, потому как если ты постоянно думаешь о различных системах, игромеханиках, смысловых иерархиях, применении всевозможных паттернов, то начинаешь видеть предпосылки к этому буквально повсюду.

Но в первую очередь это различные игры, в том числе полезно знакомство с достаточно базовыми - что-то вовсе из простых настольных, или текстовых, или карточных, или словесных. Это как раз те маленькие машинки, которые надо научиться разобрать и понимать, прежде чем переключиться на что-то более комплексное и большое. Тот самый базовый геймдизайнерский опыт.

В плане игр компьютерных полезно изучать их геймплей, понять общий смысл и думать над его возможными интерпретациями и областями применения. Отделять важное от второстепенного, видеть скрытую иерархию. Тем не менее в игре важны буквально все аспекты, даже не те, которые являются стержневыми и важными. Надо стараться раньше замечать подобные точки притяжения интереса игрока или вещи, с которыми он часто сталкивается, чтобы тоже уделить им внимание по возможности и просто лучше себе представлять какие второстепенные аспекты оказывают заметное влияние на общий игровой опыт.

Одна из практик - это смешивать механики из разных игр и смотреть, что каждая привнесенная механика может делать ещё, кроме первой своей функции, может ли стать стать более комплексной. В то же время не стоит тащить с собой чужие костыли, у нас и собственных образуется в процессе. То есть, имплементируя какую-то уже существующую механику в состав своей концепции стоит присмотреться - а так ли нужна она вся великом или достаточно лишь части. А может быть она будет использована для другого, чем это обычно принято.

Другая практика - ограничения. Можно пробовать убирать очевидные элементы, накладывая таким образом некие рамки, в которых может придуматься что-то оригинальное. Например, что если игра будет обходиться без текста, без стрельбы, без главного героя, без интерфейса, без определённых цветов, без смертей, без бонусов, без опыта, без перемещений, без смены локации, без прогрессии. Что если механика не поощряет привычные действия, что если игрок не контролирует персонажа и так далее. Из любой игры, кстати, довольно часто есть что убрать и упростить, даже не потеряв в геймплее. В то же время убранные вещи меняют так сказать, центр масс, игры и освободившееся место может быть дополнено чем то иным, развито в другом направлении.

На самом деле многие трюки геймдизайнеров и в целом разработчиков игр уже давно устоялись и используются довольно часто. Всё-таки игра - это во многом иллюзия, и многие задачи здесь не решаются в лоб, буквально, как это воспринимает пользователь. Поэтому и знание особенностей игрового движка, и знание того, как устроен вывод графики, и знание психологии, и любые прочие знания о технологиях используемых игрой и о самих пользователях, их интересах, особенностях мышления, поведения и так далее - это всё пригодится геймдизайнеру.

В плане разработки стоит сосредоточиться на том, что вы реально сможете сделать сами, хотя планировать и задумывать можно и довольно сложные конструкции. Но лучше быть реалистами и именно в реализацию на практике брать что-то, хотя бы частично и в общих чертах, достигаемое. То есть не говорить что "вот был бы у меня движок А, а не Б", или "вот сделают мне ролики и крутые модели, тогда я и сваяю нетленку". А просто взять и что-то сделать. Хотя бы в тетрадке нарисовать, хотя бы приблизительно, хотя бы общий план. Нарисовать одного персонажа, а не триста. Написать не рассказ, но диалог. Это всё вроде бы мелкие и незначительные шаги, но они раз за разом формируют новые условия, от которых можно оттолкнуться ещё дальше, ещё дальше и ещё дальше.

Вот нам нужна игра про партию героев, которые сражаются с врагами, исследуют различные города, имеют систему развития, разные предметы... Начните с одного героя. Одного врага. Сражение с одной только опцией - удар. Вместо города несколько примитивов изображающих дом. Отображение пустого окошка с информацией о герое. И так далее. Потом героев станет два. В статистике появится имя. Врагов станет двое. Кроме ударить, появится вторая опция, пусть она даже сначала не работает. Коробок-домов станет несколько. Появится отображение содержимого сумки, пусть сначала только одна ячейка. Затем героев станет три, и можно будет менять их местами. Враги станут попадаться группами по 2 или 3. Появятся ещё боевые опции. Появится вторая область с "домиками", до которой можно добраться. Итак далее.

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

Время от времени переключаться на разные виды деятельности - тоже немаловажно. Так сохраняется нужный уровень интереса и процесс не превращается в скучную рутину. В конце концов мысли и состояния приходят определёнными циклами и ритмами - если неудержимо тянет именно сейчас отвлечься от первостепенных задач и поработать над чем-то не таким важным, но более интересным, то почему бы и нет, пока есть желание.

Всегда записывайте идеи. Они пригодятся не сразу, и, возможно, не для этого проекта. Или даже вовсе не пригодятся в итоге сами по себе, но всегда есть шансы, что позднее они соединяются в нечто цельное или натолкнут на следующую мысль по цепочке. Само их существование воздействует на вас, когда идею записали - это уже не одно и то же, что просто её подумать. Пробуйте, кстати, применять какие-то свои старые идеи к новым проектам, вдруг они неожиданно раскроются в этом новом окружении.

Н

Подробнее..

Из песочницы Чему хорроры должны научиться у rogue-like

20.11.2020 18:16:58 | Автор: admin
Привет, Хабр! Представляю вашему вниманию перевод статьи Roguelike Lessons Horror Games Need to Learn автора Josh Bycer.



Я начал думать о том, как подойти к написанию четвертой книги по дизайну хорроров. Весь октябрь пытался найти новых представителей жанра, которые меня бы затянули, но в итоге я задумался о концепции ужасов, об игре-мечте и о том, как должен развиваться жанр в будущем. Итак, почему же хорроры должны вдохновляться рогаликами перевод статьи с Gamasutra.

Страх перед неизвестным


Ужас в любом виде связан с неизвестным факт того, что вы попадаете в ситуацию, в которой не знаете, что произойдет. Подобных знаковых моментов очень много: собака, прыгающая в окно в Resident Evil 1, первое появление Пирамидоголового в Silent Hill 2, или момент, когда понимаешь, во что вляпался герой Outlast.

Это не то же самое, что в игре вроде Amnesia, где разработчики используют амнезию как способ удержания игрока в неведении. История, как и память персонажа, в какой-то момент будет восстановлена либо для твиста, либо для завершения игры. Самый лучший ужас это не момент Ага!, когда все выясняется.

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

Именно здесь геймдизайн проектов жанра rogue-like может значительно улучшить хорроры. Стоит создать особый вид случайности.

Определение случайности


В моей книге, посвященной геймдизайну рогаликов, я говорил о популярном заблуждении мол, в жанре rogue-like будут работать любые случайные элементы. Это не так. Хороший дизайн рогаликов заключается в нацеленной форме рандомизации и процедурной генерации (в некоторых случаях).

Проблема многих скример-хорроров в том, что рандомизация фокусируется не на геймплее, а на том, чтобы напугать игрока. В серии Five Nights at Freddys вся строится вокруг пугающего скримера, который вот-вот нагрянет. Такого вида рандом не меняет стиль и подходы к игре, обычно геймплей очень механический и повторяющийся. Часто в таких проектах можно даже вычислить некие паттерны.

Лучшие геймдизайнеры рогаликов и их игры нацелены на конкретные геймплейные аспекты, в которых используется случайная или процедурная генерация. Речь идет не о создании чистого хаоса, а о том, чтобы иметь вариативность, которая даст разный опыт и ощущения. Есть хорроры, ориентированные на процедурную генерацию это самая базовая вариативность. Но простое изменение места, где игроку нужно находиться это не та случайность, которую мы ищем.

В моей концепции игры-мечты меняются не только позиции противников, но и то, какие противники будут появляться. Вдобавок, события, влияющие на игру, будут выбираться случайно это заставит игрока адаптироваться. Лучшие рогалики дают игроку базовое представление о том, чего ожидать, а затем заставляют их приспосабливаться к изменениям и ситуациям в каждом прохождении.

Идеальный темп


Игровая сессия еще одна область, в которой нужна синергия элементов рогаликов с ужасами. Длительность опыта другая проблема хорроров. Чувство страха трудно поддерживать долго, к тому же есть предел тому, сколько можно добавить, чтобы продлить его. Добавление большего количества врагов или квестов не помогут в погружении игрока. Скорее наоборот, повторение ситуаций и игровых циклов станет утомительным.



Чем продолжительнее хоррор, тем менее таинственным все становится. Вы можете только повторить сюжет это странный город, где происходят странные вещи так много раз, прежде чем людям станет скучно, или вы попытаетесь объяснить, почему все это происходит.

Пейсинг проблема трех последних Resident Evil, и главное причина беспокойства за RE 8. Седьмая ощущалась слишком затянутой для своего содержания, а 2 и 3 были слишком коротки и большую часть времени состояли из боевки.

Дизайн и пейсинг rogue-like идеально подойдут ужасам. Хорошим примером станет предстоящая игра World of Horror, она умело смешивает таинственность хорроров с укороченным темпом рогаликов. Типичная игровая сессия в ней длится менее часа, и как в любом хорошем рогалике каждая час отличается от предыдущего.

Микро-хоррор


Другой вариант за последнее время это идея микро-игр, сфокусированных на элементах ужаса. Серия Dread X Collection компиляции названий ужасов от известных инди-разработчиков. В каждой коллекции есть тайтлы, сделанные за короткий промежуток времени, построенные на определенной теме и с любым дизайном.

Качество и дизайн очень разнообразны. При этом из-за небольшого размера этих проектов все внимание сосредоточено на уникальных механиках. Их продолжительности достаточно, чтобы понять суть, насладиться геймплеем и не потерять чувство страха. И удобно, что их можно приобрести сразу паком, а не собираться по крупицам что-то из них точно понравится.

Сражения


Игры ужасов должны иметь способ сражаться. Одним из главных недостатков современных хорроров, на мой взгляд, стал удаление механики в пользу ничего. Многие разработчики, такие как Frictional с серией Amnesia, будут защищать это, говоря, что бой убивает страх и напряжение.

В каком-то смысле это правда, но все не так просто. Проблема с проектами вроде Resident Evil, Dead Space, Alan Wake и другими AA/AAA, заключается в том, что бой становится формой заполнения игры. Нельзя постоянно поддерживать ужас в игре с большим количеством боев он просто не будет работать. Такой же эффект случится, когда взаимодействие с игрой будет минимально.

Если игрок может только убегать, то каждая страшная ситуация будет завязана вокруг этого. Вместо того чтобы думать на лету, игра превращается в многократное повторение одного и того же что снова убивает чувство страха. Бой должен быть не бессмысленным, а тактическим. Игрок должен чувствовать, что есть очевидные компромиссы в борьбе с врагами. И дело не в том, чтобы заставить игрока постоянно сражаться, а в добавлении вес каждому такому опыту.



Хочется, чтобы в сочетании с коротким темпом ужас принял более интуитивную форму боя. Речь идет не об опасных боях сражения со 100 врагами, а просто о борьбе с одним. Вот почему мы часто вспоминаем альфа-антагонистов, таких как ксеноморф из Alien Isolation, Мистер X из Resident Evil 2 и, конечно же, встречи с Пирамидоголовым в Silent Hill 2.

Важное замечание: бои в хоррорах не всегда означают убивать. Вы можете стрелять в Мистера X сколько угодно раз, но убить не сможете до определенного боссфайта. Враги не должны триггериться игроком, но должны быть активными участниками геймплея и охотиться за ним во время игры. Опять же, цель всего этого сделать сессию игры более интересной и разнообразной. Также должны быть способы взаимодействия с врагами, не связанные с боем.

Я потерял счет количеству хоррор-игр, в которых главное избегать и скрываться без возможности отвлечь врагов.

Будущее страха


На днях я должен сесть и переписать ГДД для своей хоррор-идеи. И удивлен, что многие разработчики еще не пошли по этому пути. С выходом некстгена пришло время переосмыслить дизайн ужасов и объединить это с разнообразием и напряжением хорошего рогалика. Нам нужно перестать относиться к хоррор-играм как к восьмичасовому опыту, основанному на скримерах и скелетах в шкафах.

Есть золотая середина между короткими инди-хоррорами и крупными AAA-проектами. Нужно просто это объединить.

Если вас интересуют мои книги по геймдизайну, то сейчас вышли Game Design Deep Dive Platformers и 20 Essential Games to Study. Game Design Deep Dive Roguelikes выйдет в начале 2021 года.
Подробнее..

Recovery mode Как создаются интересные открытые миры ключевые принципы

03.02.2021 12:13:25 | Автор: admin

С развитием технологий и улучшением железа в ПК и консолях у разработчиков игр появилась возможность делать гигантские открытые миры, наполненные огромным количеством контента. Но это вовсе не значит, что внушительные размеры локаций автоматически делают игры интересными. Владимир Семыкин, энтузиаст геймдизайна, специально для Нетологии рассказал о принципах создания захватывающих открытых миров.

Разработчики гонки в открытом мире Fuel, вышедшей в 2009 году, хвастались, что площадь игровой карты составляет 14 тысяч км. На деле же в этом было мало смысла на этой территории было совсем мало активностей, из-за чего большая часть прохождения уходила на бессмысленные поездки по безжизненным лесам, полям и пустыням.

В Fuel огромный открытый мир, но в этом нет смысла ведь в игре мало активностейВ Fuel огромный открытый мир, но в этом нет смысла ведь в игре мало активностей

Чтобы открытый мир не наводил на игроков скуку, разработчики по-разному мотивируют пользователей исследовать окружение. В результате грамотного подхода к дизайну игры может получиться уникальное и интересное приключение, которое не надоест даже через десятки часов.

Открытые миры с точки зрения игровых активностей и геймплея

Чем больше игровых активностей, тем разнообразнее геймплей игрок может постоянно менять занятия, чтобы прохождение не ощущалось однотипным. Также пользователь может заниматься только тем, что ему по-настоящему нравится.

К примеру, в Grand Theft Auto: San Andreas игроку было доступно множество побочных занятий, которые никак не влияли на основной сюжет. Там можно было ходить на свидания, встречаться с друзьями, участвовать в войне банд, разрисовывать стены, учиться управлять разным транспортом, фотографировать, выполнять миссии полицейских, пожарных, скорой помощи и многое другое.

Кроме выполнения основных миссий в Grand Theft Auto: San Andreas, игроку доступно множество побочных занятий: можно кататься по городу и слушать музыку, встречаться с друзьями, фотографировать, ходить на свиданияКроме выполнения основных миссий в Grand Theft Auto: San Andreas, игроку доступно множество побочных занятий: можно кататься по городу и слушать музыку, встречаться с друзьями, фотографировать, ходить на свидания

При этом у большей части активностей была собственная прогрессия игрок выполнял задания, а процент прохождения возрастал. Это значит, что у таких активностей были конкретные финальные точки, до которых можно было легко дойти. Например, игрок мог захватить все районы или пройти все уроки в автошколе. Логика такого подхода очевидна игрок стремится увидеть весь контент и выполнить все задачи на 100%, поэтому у него сохраняется мотивация играть дальше, пока он не добьётся нужного результата.

И это не говоря о, пожалуй, самом популярном занятии в GTA погоне и перестрелке с полицией. Несмотря на то что этот игровой аспект никак не связан с прогрессом, он интересен для игроков по другой причине.

Если игрок начнёт пальбу на улице, горожане будут убегать в панике, а водители начнут разъезжаться по сторонам, игнорируя правила дорожного движения. К трупу приедет скорая помощь, а пожарные примчатся тушить взорванную машину. Конечно, чтобы утихомирить игрока, прибудут и полицейские стоит нарушить закон, как за игроком начнётся погоня. Чем больше сопротивления оказывает пользователь, тем сильнее ответ игры.

Погоня в Grand Theft Auto: San Andreas одно из самых интересных занятий, так как любые действия игрока провоцируют мир отвечать емуПогоня в Grand Theft Auto: San Andreas одно из самых интересных занятий, так как любые действия игрока провоцируют мир отвечать ему

GTA учитывает действия пользователя и отвечает ему в механиках игры заложена системность, которая формирует настоящий диалог между самой игрой и пользователем: он совершает действие она отвечает.

Именно это и мотивирует игрока раз за разом открывать стрельбу на улице. С одной стороны, так игрок пытается узнать уровень своего мастерства и проверить игру на прочность: Как долго я смогу кататься на одном лишь мотоцикле, пока меня не убьют?. С другой стороны, в ходе таких погонь он экспериментирует с искусственным интеллектом и игровыми механиками, чтобы узнать возможности системы: Что произойдёт, если я заберусь на военную базу и угоню истребитель?.

В результате, чем больше механик задействовано, тем больше вариантов для развития событий. Это разжигает в игроке любопытство и побуждает его исследовать и экспериментировать.

Тяга к открытиям это сильный мотиватор для игроков, который побуждает стремиться к новому. Открытый мир The Legend of Zelda: Breath of the Wild таит в себе огромное количество неизведанного. И дело даже не в квестах, сюжете или новых местах мир игры существует по собственным правилам, которые можно узнать лишь в ходе прохождения.

Мир The Legend of Zelda: Breath of the Wild помогает игроку решать задачи, но с ним нужно научиться взаимодействоватьМир The Legend of Zelda: Breath of the Wild помогает игроку решать задачи, но с ним нужно научиться взаимодействовать

Хайрул мир, в котором происходит действие игры, наполнен большим количеством взаимосвязанных систем, которые работают в любой точке мира. При этом само окружение диктует игроку условия для выживания и взаимодействует с ним: нужно менять одежду при входе в определённый регион, в грозу металлические предметы притягивают молнию, воду можно замораживать, подожжённая трава создаёт восходящие потоки воздуха, на которых можно взлетать, можно срубить дерево и использовать его в качестве моста. В результате сам игровой мир превращается в инструмент, который помогает игроку решать задачи.

Поиск закономерностей и знакомство с игровыми механиками делают игру интересной для пользователей. В The Legend of Zelda: Breath of the Wild в разных регионах мира работают разные правила и механики, поэтому у игрока всегда сохраняется мотивация продолжать изучение окружения.

Если в The Legend of Zelda: Breath of the Wild окружение это полезный помощник, с которым нужно научиться взаимодействовать, то мир Death Stranding это главный противник, в котором опасно совершать самые базовые действия. Даже просто ходить это занятие, которое может стоить жизни: стоит зацепиться за камень, как Сэм упадёт и кубарем покатится со скалы.

В игровом мире Death Stranding опасно совершать даже самые простые действия: один неверный шаг, и герой может получить серьёзные травмы В игровом мире Death Stranding опасно совершать даже самые простые действия: один неверный шаг, и герой может получить серьёзные травмы

Учитывая постоянные перепады высот, это легко может привести к серьёзным травмам. Если же не идти, а просто стоять на одном месте, то рано или поздно начнётся темпоральный дождь, разрушающий физические объекты ещё один признак того, что мир игры хочет вас убить.

Именно поэтому значительная часть геймплея Death Stranding посвящена обузданию этого хаотичного и бесконтрольного мира. Игрок постепенно строит инфраструктуру и превращает беспорядочное окружение в понятную систему, по которой удобно передвигаться и выполнять заказы.

Беспорядочное и опасное окружение Death Stranding превращается в удобную систему, которая помогает игроку выполнять заказыБеспорядочное и опасное окружение Death Stranding превращается в удобную систему, которая помогает игроку выполнять заказы

Неизвестность побуждает пользователя идти вперёд и открывать новые места. Тем не менее нет ничего более разочаровывающего и фрустрирующего, когда долго забираешься в дальний уголок карты, но ничего там не находишь. С другой стороны, если заранее сообщать пользователю, что он там найдёт, то исчезнет сюрприз и чувство первооткрывателя.

Разработчики из CD Projekt RED нашли компромисс и успешно реализовали его в The Witcher 3. Для этого они разместили по всему игровому миру небольшие активности и пометили их вопросами на карте. За каждым вопросом может скрываться небольшая история, квест, особенная битва с врагами и так далее. Заранее игрок не знает, чего ждать, но вопрос гарантирует, что на этом месте будет что-то интересное.

Создатели The Witcher 3 разместили по всему игровому миру небольшие активности и пометили их вопросами на карте так игроки могли понять, что их ждёт что-то интересноеСоздатели The Witcher 3 разместили по всему игровому миру небольшие активности и пометили их вопросами на карте так игроки могли понять, что их ждёт что-то интересное

Конечно, не CD Projekt RED изобрела эту систему. К примеру, в Grand Theft Auto V таким же образом обозначались случайные прохожие, с каждым из которых происходила интересная сценка. Но именно после The Witcher 3 система с вопросами начала появляться и в других action-RPG, к примеру в Assassins Creed Origins и последующих частях серии.

Открытые миры с точки зрения построения окружения

Игры с открытым миром дают игроку свободу исследования и позволяют пуститься в собственное приключение. Если в линейных играх пользователи вынуждены следовать тому пути, который придумали за них разработчики, то в открытых мирах можно идти практически в любую сторону. Тем не менее без грамотной навигации игроки рискуют затеряться. Чтобы этого не случилось, разработчики используют систему ориентиров и визуальный язык это помогает пользователю легко передвигаться по миру и находить нужные места.

Мир The Elder Scrolls: Skyrim наполнен множеством точек интереса если просто идти в сторону ближайшей башни-ориентира, можно наткнуться на что-нибудь занимательноеМир The Elder Scrolls: Skyrim наполнен множеством точек интереса если просто идти в сторону ближайшей башни-ориентира, можно наткнуться на что-нибудь занимательное

Создание открытого мира это очень сложная задача, так как игрок может пойти в любом направлении, поэтому разработчики должны предугадать каждый вариант развития событий. Левел-дизайнер MachineGames, который ранее работал в Ubisoft, Юлиус-Космин Ониску считает, что без ориентиров игрок вообще не будет понимать, куда ему идти у него не будет цели и желания исследовать окружение.

Чтобы изменить это, нужно добавить в пейзаж точку интереса, притягивающую внимание игрока. Когда в мире есть такое место, поведение пользователя становится более предсказуемым сразу же понятно, куда он пойдёт в первую очередь. Обычно на локациях располагается сразу множество ориентиров, притягивающих внимание игрока.

Такие визуальные магниты принято называть weenie, хотя это слово чаще всего ассоциируется исключительно со шпилями и башнями. Этот термин придумал Уолт Дисней для ориентиров в Disney World они привлекают внимание посетителей и позволяют точнее определить своё местоположение.

Каждый поход в The Elder Scrolls: Skyrim превращается в длинное путешествие, наполненное множеством интересных историйКаждый поход в The Elder Scrolls: Skyrim превращается в длинное путешествие, наполненное множеством интересных историй

По словам геймдизайнера Кортни Рейн, для ориентиров не обязательно всегда выдумывать что-то необычное. Наоборот, люди тянутся к знакомому, поэтому маяка, замка или башни будет достаточно. Только учитывайте, что точки интереса должны выделяться на фоне окружения: например, за счёт контрастного цвета, дополнительной подсветки, формы или силуэта.

Точки интереса конкурируют друг с другом за внимание игрока есть разные переменные, которые влияют на то, насколько интересным выглядит конкретная точка для пользователя: например, размер, удалённость, эстетичность. Создатели игры могут настраивать эти параметры для расстановки приоритетов. И это позволяет сделать поведение игрока более предсказуемым.

К примеру, весь мир The Elder Scrolls: Skyrim наполнен огромным количеством точек интереса если просто идти в сторону ближайшей башни-ориентира, можно легко наткнуться на какую-нибудь интересную точку: подземелье, пещеру, заброшенный дом, лагерь. В результате каждый поход до нужного места превращается в длинное путешествие, наполненное множеством небольших историй.

Разработчикам важно знать, куда пойдёт игрок, чтобы понимать, какой должна быть кривая прогрессии и сложности. В Skyrim для этого существует автолевелинг противников их уровень повышается вместе с силой героя. Но это не единственный способ решить эту задачу. Также можно разделить игровой мир на зоны, в каждой из которых будут свои точки интереса и определённый уровень сложности. В таком случае игрок будет развиваться и постепенно переходить в более трудные зоны, изучая окружение.

Разделение на зоны с разными точками интересаРазделение на зоны с разными точками интереса

В Skyrim тоже есть ограничения по зонам в некоторые места новичку лучше не соваться. Также убедитесь, что крупные ориентиры находятся далеко друг от друга лучше размещать небольшие ориентиры рядом с крупными, чтобы добавить разнообразия в окружение.

На карте игрового мира Skyrim видны зоны, куда новичку лучше не заходитьНа карте игрового мира Skyrim видны зоны, куда новичку лучше не заходить

Другая причина, по которой разработчикам важно понимать путь игрока это создание приятной и эстетичной композиции. Проблема открытых миров заключается в том, что пользователь может прийти к точке почти с любой стороны, поэтому с одного ракурса она может быть композиционно идеальной, а с другого хаотичной.

По мнению бывшего левел-дизайнера CD Projekt RED Матеуша Пьяскевича, для этого можно придерживаться общих принципов композиции выделить одну очевидную доминанту, добавить асимметрию и убедиться, что самые крупные элементы композиции сбалансированы между собой.

Кроме понятной навигации в игровом мире важно, чтобы игроку было интересно и удобно передвигаться по окружению. В ранних частях Assassins Creed разработчикам удавалось создавать города, в которых передвижение по крышам было быстрее и эффективнее бега по улицам.

Разработчики Assassins Creed создали мир, в котором игроку удобнее передвигаться по крышам, чем по улицамРазработчики Assassins Creed создали мир, в котором игроку удобнее передвигаться по крышам, чем по улицам

По мнению Ониску, чтобы добиться этого, команда следовала нескольким принципам: забираться наверх должно быть легко и весело, пути должны быть закольцованы, а сам бег по крышам должен быть основной стратегией игроков.

В результате команде удалось реализовать это при помощи множества незаметных, но действенных решений. К примеру, везде по улицам можно встретить цепочку восходящих объектов, которые постепенно ведут на крышу это позволяет взбираться наверх практически не сбавляя темп. Кроме того, на улицах постоянно ходят толпы людей, которые мешают свободно передвигаться, поэтому игроки автоматически стремятся взобраться наверх, чтобы спокойно перемещаться по карте.

Интересно, что некоторые правила создания городского пространства до сих пор встречаются в играх Ubisoft. К примеру, в Watch Dogs Legion все основные дороги тоже закольцованы это сделано для того, чтобы у игрока всегда была возможность двигаться вперёд. Именно поэтому в виртуальном Лондоне так мало тупиков. Также дороги всегда ведут к ориентирам и важным точкам, которые видны издалека.

Все дороги в Watch Dogs Legion закольцованы, чтобы игрок мог двигаться вперёдВсе дороги в Watch Dogs Legion закольцованы, чтобы игрок мог двигаться вперёд

Открытые миры с точки зрения повествования и сюжета

Открытые миры могут выступать в качестве отличного рассказчика они могут вмещать огромное количество небольших сюжетов или рассказывать одну глобальную историю. Horizon Zero Dawn это отличный пример игры, в которой окружение безмолвно рассказывает о событиях, произошедших за сотни лет до основного сюжета. По миру разбросаны останки гигантских роботов, которые участвовали в ожесточённых битвах с людьми, а на лугах пасутся робозвери, восстанавливающие экосистему после глобального катаклизма.

В Horizon Zero Dawn окружение рассказывает о событиях, которые произошли за сотни лет до основного сюжетаВ Horizon Zero Dawn окружение рассказывает о событиях, которые произошли за сотни лет до основного сюжета

Предположительно, термин повествования через окружение появился благодаря сотруднику Disneyland Дону Карсону, который стремился сделать так, чтобы пространство парка само рассказывало истории. Но в рамках геймдизайна определение появилось благодаря Харви Смиту и Маттиасу Ворчу. Они сформулировали это следующим образом: повествование через окружение это наделение игрового пространства свойствами, которые можно интерпретировать как осмысленное целое, расширяющее нарратив игры.

И это отлично работает в Horizon Zero Dawn. Разработчики грамотно дозировали информацию о лоре игры, благодаря чему большую часть времени пользователь остаётся в неведении он не знает, в чём заключается роль роботов в игровом мире. Конечно же, догадки появляются уже с первых минут прохождения, но этого недостаточно, чтобы связать все куски воедино.

Окружение игры Horizon Zero Dawn усиливает погружение игрока и помогает ему лучше понять события историиОкружение игры Horizon Zero Dawn усиливает погружение игрока и помогает ему лучше понять события истории

Чем больше игрок погружается в сюжет, тем больше смысла появляется в том, что его окружает. Повествование через окружение усиливает погружение игрока, а также даёт ему необходимый контекст для лучшего понимания событий истории. Исследование игрового мира позволяет чуть больше узнать о лоре игры.

С другой стороны, открытый мир отлично подходит для рассказывания небольших историй. К примеру, практически в любом путешествии в Red Dead Redemption 2 происходит какое-то небольшое событие: на героя нападают бандиты, устраивают ему засады, мирные жители просят отвезти в город и так далее. В результате каждая поездка превращается в приключение с собственной историей. К сожалению, в определённый момент эти ситуации начинают повторяться, поэтому они перестают быть уникальными.

В Red Dead Redemption 2 каждая поездка превращается в интересное приключение с собственной историейВ Red Dead Redemption 2 каждая поездка превращается в интересное приключение с собственной историей

Тем не менее даже без этого мир RDR 2 наполнен большим количеством повествовательного контента, который не относится к основной линии. Это касается линий с фотографом, директором зоопарка, возвращением долгов и многим другим. Каждая миссия это небольшая история, которая зачастую имеет комичную или драматичную развязку. И открытый мир позволяет правдоподобно вписать каждую из них в контекст окружения и эпохи.

В предыдущих примерах повествование заранее создано разработчиками. Но есть игры, в которых история генерируется исключительно благодаря действиям пользователя. К примеру, в Middle-earth: Shadow of War система Nemesis позволяет создать уникальную историю взаимодействия с орками. Любое столкновение в игре может закончиться по-разному, а результат влияет на то, каким будет следующий ход вашего заклятого врага.

В Middle-earth: Shadow of War историю создаёт сам игрокВ Middle-earth: Shadow of War историю создаёт сам игрок

В Shadow of War у игрока может получиться история про долгую вражду, которая в один момент перерастает в сотрудничество. И открытый мир позволяет сформировать эти отношения: благодаря элементу неожиданности игрок никогда не знает, как дальше будет складываться его история за любым поворотом его может ждать воскресший враг, желающий отомстить главному герою.


Большое преимущество открытых миров заключается в свободе, которую они предоставляют игроку. Благодаря этому пользователь может идти практически в любую сторону и заниматься только тем, что ему интересно. Тем не менее плохо созданный открытый мир может сделать прохождение унылым и неинтересным.

Разработчики должны позаботиться о том, чтобы в игровом мире было достаточно активностей, а механики были связаны друг с другом. Кроме того, нельзя забывать о точках интереса и визуальных магнитах без них игроки просто будут бесцельно бродить по локациям. Если же вы хотите, чтобы путешествие по миру было содержательным для игрока, сделайте так, чтобы само окружение рассказывало ему историю.

От редакции: где учиться создавать игры

  • Курс Геймдизайнер 92 часа теории и 103 часа практики, в портфолио прототип собственной игры на движке Unreal Engine и полный комплект проектной документации для запуска игры

  • Курс Разработчик игр на Unity 85 часов теории и 86 часов практики, поэтапное освоение Unity и C#, студенты работают над прототипами игр типа Runner, карточная игра, 2D-танки, аркадная гонка, RPG

  • Курс 3D-графика в Cinema 4D 26 часов теории и 40 часов практики, 2 проекта в портфолио

Подробнее..

Лекционный вечер по геймдизайну

30.03.2021 10:05:43 | Автор: admin

21 апреля 2021 года (среда) в Центре развития компетенций в бизнес-информатике Высшей школы бизнеса НИУ ВШЭ состоится Лекционный вечер по геймдизайну.

C 19:00 и до 22:00 наши преподаватели, эксперты игровой индустрии, будут делиться с гостями мероприятия своим опытом.

На мероприятии вас ждут три лекции:

  1. Как сделать интересную и прибыльную игру (Константин Сахнов, совладелец издательства JustForward).

  2. Как сделать интересную игровую механику (Владимир Агарев,креативный продюсер в компании Gaming Point).

  3. Как делается геймдизайн масштабной российской рпг (Юлия Черненко, гейм-дизайнер в Owlcat Games)

    Начало регистрации: 18:30. Начало мероприятия: 19:00

    Мероприятие пройдет в смешанном формате. Посетить его можно как очно, так и дистанционно. Если вы не сможете прийти очно или находитесь не в Москве, то сможете подключиться к лекциям в онлайн-формате: Zoom + трансляция нанашем канале на youtube.

    Более подробная информация и регистрация на мероприятие здесь>>>

Подробнее..

Recovery mode Как начинающему нарративному или левел-дизайнеру найти работу в игровой студии расспросили специалистов из индустрии

12.02.2021 18:18:50 | Автор: admin

Ранее мы расспросили опытных геймдизайнеров об особенностях трудоустройства в игровых студиях. В этот раз выяснили, какие навыки, портфолио и опыт нужны нарративным и левел-дизайнерам, чтобы найти работу.

Что необходимо левел-дизайнеру для трудоустройства в игровую студию

Кирилл Буянин, дизайнер уровней в RemedyКирилл Буянин, дизайнер уровней в Remedy

Во-первых, это, конечно, технические навыки: умение работать с 2D- или 3D-пространствами в движке. Дизайнер должен быстро прототипировать уровни и оперативно менять их по фидбеку. Для создания интересных уровней пригодятся знания композиции, перспективы и понимание негативного-позитивного пространства. Любые знания архитектуры или промышленного дизайна тоже будут плюсом.

Второе это коммуникативные навыки: устные и письменные. Одни нужны при общении с коллегами, другие для изложения своих идей на бумаге. Поэтому написание документации важное умение, не стоит о нём забывать.

Порог вхождения в левел-дизайн нельзя назвать очень высоким освоить базовые навыки достаточно просто, а вот овладеть ими в совершенстве уже гораздо сложнее.

Для трудоустройства геймдизайнеру необходимо портфолио. Нужно иметь минимум тричетыре работы. Например, какой-нибудь мод или карту в существующей игре. Написать, что в уровне происходит и почему, нарисовать схему и так далее. Если сделать такую работу, то можно смело добавлять это в портфолио.

Второе, что можно сделать небольшой уровень в популярном движке. Уровень можно собрать абсолютно без графики, только с геометрией (простейшими кубиками). В документе описать цель, сеттинг, приложить референсы и прочее. Не надо писать сотню страниц дизайн-документа: однойдвух страничек достаточно.

Портфолио можно представить в разных форматах. Например, завести блог на ArtStation, Medium или сделать сайт в каком-нибудь конструкторе Wordpress, Weebly, Wix и так далее. Важно, чтобы оно было максимально доступным и открывалось даже на телефоне. Также можно сделать видео с прохождением иногда трёхминутный ролик даст намного больше понимания, чем слишком подробная документация.

Например, это моя работа-блокаут:

Опыт можно нарабатывать, участвуя в разных геймджемах. При этом не обязательно создавать полноценную игру с работающими механиками. Достаточно сделать около десяти простых прототипов, написать к ним документацию и выложить на ArtStation это будет хорошее развитие навыков. Потом можно выбрать дватри лучших уровня и добавить их в портфолио.

Можно сделать прототип walking-симулятора, где надо пройти из точки А в точку Б. Но сделать это круто: со всякими серпантинами, переходами, пролазами, перепадами высот и прочим. Я посмотрю и скажу: Это крутая работа левел-дизайнера. Например, если добавить врагов и оружие, то он станет отличным уровнем для Call of Duty.

Или взять серию Метро. Некоторые уровни просто хождение по мирным станциям без оружия. И оно отлично играется! Поэтому городить сотню механик в прототипе вовсе необязательно. Такую работу может сделать любой в том же Unreal или Unity.

Ещё один полезный способ набраться опыта пройти специализированные курсы: студенты получают необходимый минимум, чтобы устроиться на работу.

Для зарубежных студий важно, чтобы соискатель умел общаться на английском языке. Без этого не может быть эффективной коммуникации в команде.

К тому же большая часть материалов о геймдеве публикуется именно на английском языке, поэтому человек не может их игнорировать, если хочет продолжать развиваться.

Скриншот из игры Frontline Commando 2, над которой работал КириллСкриншот из игры Frontline Commando 2, над которой работал Кирилл

В тестовое задание для левел-дизайнера чаще всего входит создание документации по уровню (mission-дизайн) или создание самого уровня. Иногда оба варианта сразу.

Задание для трудоустройства в ААА-студию может выглядеть так: Есть зомби-сеттинг, есть девочка-подросток и мужик с бородой. Они перемещаются из точки А в точку Б в городской местности. Придумайте геймплей и сделайте простой уровень, опишите свои мысли в документе.

Требования к кандидату и процесс рекрутинга меняются от студии к студии в каких-то требуется больше технических скиллов, а где-то больше коммуникативных.

Я как-то устраивался в одну студию в Англии. Они требовали знание C# для левел-дизайнеров, потому что у них свой движок и там всё скриптование на C#. На собеседовании мне дали задачку в духе школьных олимпиад по программированию. Надо было сделать её на время, за полчаса.

Я её успешно провалил, но это был единственный случай в моей практике с подобным заданием. Чаще всего серьёзные знания в программировании от левел-дизайнеров не требуются. Для работы хватает понимания базовых принципов, остальное можно спросить у коллег уже на месте.

Начинающим левел-дизайнерам сперва поручают самые простые задания. Если же новичок хорошо себя проявляет, то важность задач постепенно возрастает.

Например, моя первая задача на проекте Метро: Исход заключалась в том, чтобы расставить ворон на уровне. Их можно было разместить как попало, и ошибки бы не было на геймплей они не влияют. Это задача, которая даёт представление о работе с движком и объектами. Потом начинаешь двигать не ворон, а модельки на уровне, затем собираешь дополнительные локации. Постепенно зона ответственности растёт, и начинаешь работать уже с основными локациями, которые увидят 100% игроков.

Кстати, с воронами я в итоге просидел пару дней. Читал, где они обитают, где гнездятся, чтобы расставить их согласно биомам в существующей природе. Не думаю, что много игроков заметит, что вороны расставлены вручную и ведут себя как в реальной жизни. Но когда такие вещи делаешь с вниманием к деталям, то это усиливает погружение и атмосферу.

Что должен знать и уметь нарративный дизайнер, чтобы найти работу

Мария Кочакова, CEO НарраторикиМария Кочакова, CEO Нарраторики

В современной российской индустрии не до конца сформировано понимание профессии нарративного дизайнера, поэтому работодатели часто путают её со сценаристикой. Именно поэтому в вакансиях для нарративных дизайнеров можно встретить требования, которые относятся к сценаристам.

Нарративный дизайнер это подвид геймдизайнера, который отвечает за реализацию истории в игре, то есть это переходный человек между геймдизайнером и сценаристом.

Нарративный дизайнер должен обладать знаниями обеих профессий. При этом ему не обязательно углубляться в математику. Достаточно просто разбираться в механиках, понимать в общих чертах баланс, как он строится, что такое game loop, core-механика, мета, кривая обучения и так далее.

Нужно понимать, как вообще игра работает, что в ней fun, чтобы хорошо, красиво, аккуратно вставить туда историю. При этом история должна не конфликтовать с геймплеем, а, наоборот, максимально его поддерживать.

Надо представлять, как и по каким законам работает драматургия, что привлекает внимание в истории, что вызывает сочувствие, как лучше оформлять события, сцены, диалоги.

Соотношение навыков геймдизайнера и сценариста примерно 50/50. Но всё зависит от жанра игры и того, какую роль там занимает повествование.

Задачи нарративных дизайнеров на разных проектах могут сильно отличаться. Например, в CD Projekt RED нарративные дизайнеры (там они называются квест-дизайнерами) собирают квесты, а в закрывшейся Telltale Games они занимались стыковкой всех вариантов веток повествования.

Писатели готовят контент, а нарративные дизайнеры отсматривают, чтобы каждый выбор игрока складывался в логичную драматургическую историю.

Для трудоустройства в игровую студию обязательно нужно иметь портфолио, так как в последнее время значительно возросла конкуренция важно выделяться на фоне огромного потока кандидатов. При этом нужно показать именно игровые работы романы или киносценарии не подойдут.

Лучше всего, если в портфолио будет представлена игра: подойдут проекты с геймджемов или хакатонов. Или можно создать мод к какой-нибудь игре, например, к Ведьмаку. При устройстве на должность квест-дизайнера в CD Projekt RED это обязательное условие: кандидат должен сделать полноценный квест в редакторе для Ведьмака 3.

Оформить портфолио можно в виде отдельного сайта, например, в конструкторе Tilda там есть все необходимые функции, которые позволяют легко собрать красивый и понятный сайт.

Собеседование на должность нарративного дизайнера ничем особенным не отличается от других сфер. Но стоит серьёзно отнестись к сопроводительному письму если оно будет неграмотным и небрежно оформленным, то высока вероятность, что кандидат не дойдёт до следующего этапа.

Авторская игра Марии Кочаковой Message Quest вышла на Steam в 2015 годуАвторская игра Марии Кочаковой Message Quest вышла на Steam в 2015 году

Искать актуальные вакансии лучше через специализированные сайты, каналы и группы. Для поиска подойдёт hh.ru или агрегаторы. В Нарраторике мы постоянно всё это публикуем. Есть куча пабликов типа Работа в геймдеве, где тоже делают подборки вакансий.

Специализированные курсы по нарративному дизайну полезны: преподаватели способны дать необходимые знания, но очень многое зависит от самих студентов.

В педагогике есть классическое разделение на знания, умения и навыки. Знания это присвоенная информация, которую человек не просто прослушал, а проработал и запомнил. Умения это знания, подтверждённые практикой. Навыки это автоматизированные умения. Пока я не вижу способа перевести умения в навыки на курсах.

Курсы могут дать знания и умения, чтобы человек обработал информацию и подтвердил под присмотром ментора, что может ей пользоваться, получил обратную связь, выполнил упражнения, показал, что он понял. А следующий этап из умений сделать навыки. Это долгая работа, на которую уйдут годы.


Подводя итоги, можно сказать, что и левел-дизайнеры и нарративные дизайнеры должны обладать некоторыми навыками и знаниями геймдизайнеров. Но рабочие обязанности этих специалистов сильно отличаются друг от друга. Собственно, этим и обусловлено разделение на эти три дисциплины.

Процесс трудоустройства для всех примерно одинаковый:

  • важно иметь портфолио;

  • желательно, чтобы в портфолио были игровые проекты. Например, прототипы с геймджемов или полноценные релизы;

  • портфолио лучше всего оформить в виде отдельного сайта. Вы легко сможете сделать его в конструкторе;

  • получить необходимые для трудоустройства знания и умения можно на курсах;

  • искать вакансии лучше всего через специализированные ресурсы сайты с вакансиями, сообщества и каналы в соцсетях;

  • почти во всех студиях просят выполнить тестовое задание;

  • вам могут предложить решить задание прямо на собеседовании;

  • перед собеседованием важно подробно изучить игры студии. Если вы знаете, над каким проектом сейчас работает компания, изучите этот жанр как можно лучше.

Над статьёй работали: Владимир Семыкин, энтузиаст геймдизайна; Виталий Цура, координатор геймдев направления Нетологии; Надежда Осипова, аспирантка Нетологии.

От редакции: где учиться создавать игры

  • Курс Геймдизайнер 92 часа теории и 103 часа практики, в портфолио прототип собственной игры на движке Unreal Engine и полный комплект проектной документации для запуска игры

  • Курс Разработчик игр на Unity 85 часов теории и 86 часов практики, поэтапное освоение Unity и C#, студенты работают над прототипами игр типа Runner, карточная игра, 2D-танки, аркадная гонка, RPG

Подробнее..

Recovery mode История игровой графики от нескольких лампочек до миллиардов полигонов

26.06.2020 08:09:31 | Автор: admin
Современная игровая графика достигла невероятного фотореализма. Если сравнить скриншот из современной игры и реальную фотографию, может возникнуть сомнение, какое изображение настоящее, а какое компьютерное. И это заслуга не только мощного железа, которое может выдать такую картинку, но и опытных специалистов, которые отлично знают оптические особенности реального мира и понимают ограничения технологий.

Игровая графика прошла длинный путь от абстрактных геометрических фигур до современных высокополигональных моделей. Очевидно, что ключевое место в улучшении графики сыграло постепенное развитие железа, но от этогозависело далеко не всё. Параллельно художники искали и пробовали разные стили: вдохновлялись мультипликацией, комиксами, упрощали 3D-модели, добавляли видеовставки, а иногда уходили и в ностальгический даунгрейд. И аудитория поддерживала разработчиков в их поисках.

В тексте мы разберём основные вехи развития графики в видеоиграх, опишем технологии, которые влияли на этот процесс, а также расскажем о трендах, появившихся в инди-индустрии.

С чего всё начиналось: из лабораторий в аркадные залы и гостиные


Первые прототипы игр появились ещё в ранние годы существования компьютеров. У них не было экранов, поэтому информация выводилась с помощью лампочек. Примерно так работала одна из первых компьютерных игр в истории Nimatron, созданная в начале 1940-х годов на основе правил настольной игры ним.


Схема и изображение Nimatron

В 40-е и 50-е годы компьютеры не выходили за пределы научно-исследовательских лабораторий и выставок, поэтому у игр не было ни единого шанса стать массовым развлечением. Но постепенно технологии совершенствовались, и средства вывода информации всё больше стали напоминать привычные экраны.

Важным шагом на этом пути стала игра Крестики-нолики, которая выводила информацию с помощью электронно-лучевой трубки она формировала игровое поле размером 35*15 точек. Игра появилась в 1952 году, но никто за пределами Кембриджа её не увидел.


Крестики-нолики

Через шесть лет, в 1958 году, появилась игра Теннис для двоих, экраном которой выступал осциллограф. Функция экрана в игре была предельно утилитарной: ни одного лишнего элемента только поле и сам мячик. Даже ракетки не отображались.


Tennis for Two The Original Video Game

Следующим заметным шагом стала игра Spacewar! (1962) для компьютеров PDP-1. На первый взгляд кажется, что графика мало изменилась по сравнению с предшественницей, но это не совсем так. ЭЛТ-дисплей мог отображать до 20 тысяч точек в секунду, что позволяло не только показать главные игровые элементы, но и добавить побочные. Например, фон из звёзд, который не влияет на геймплей, но создаёт антураж космического сражения. Именно Spacewar! стала одной из первых игр, в которых графика это выразительное средство, поддерживающее фантазию игроков, а не просто функциональный инструмент вывода информации.


Restored PDP-1 Demonstration

Начиная с 1970-х годов, игры постепенно становились более доступными. Появились первые коммерческие игровые приставки и аркадные автоматы. Большим прорывом стала приставка Magnavox Odyssey, которая подключалась к телевизору. Но графика на ней оставалась предельно простой это всё ещё было монохромное изображение, состоящее из нескольких геометрических фигур.

Несмотря на скудность графики, разработчики постарались обойти эти ограничения внешними приспособлениями. Так, поверх экрана телевизора можно было повесить пластиковые накладки, которые добавляли игровое поле были варианты с полем для хоккея, футбола, бейсбола, игры в Кошки-мышки и так далее.


1972 Magnavox Odyssey promotional film

Несмотря на то, что до 3D-графики играм ещё было далеко, разработчики стремились сделать хотя бы имитацию объёмного мира. Одной из первых таких игр стала Maze War (1973) первый шутер от первого лица, в котором была воссоздана линейная перспектива, а игрок мог свободно перемещаться по окружению.


Maze War. Игроки перемещались по абстрактному лабиринту и сражались друг с другом. Несмотря на простоту графики, она отлично справлялась с главной задачей созданием трёхмерного виртуального пространства

Были версии Maze War как для векторных экранов, так и для растровых. Разница между этими типами двумерной графики заключается в следующем.

Двумерная растровая графика работает на основе сетки растров пикселей, каждый из которых обладает своим цветом, насыщенностью и яркостью. Из этих пикселей, как из мозаики, можно собрать полноценное изображение. Но недостаток подхода заключается в лесенках, которые образуются на границах каждого растрового объекта. Именно этот тип графики лежит в основе 8- и 16-битных игр, например, Pac-Man (1980), Super Mario Bros. (1985) и других.

Двумерная векторная графика устроена иначе: можно сказать, что в её основе лежат геометрические примитивы точки, прямые, окружности, прямоугольники. Каждый вектор обозначается координатами двух точек X и Y. Векторные объекты выглядят аккуратнее и качественнее, чем растровые.

Пионеры 3D-графики использовали векторные линии, чтобы показывать упрощённые объёмные объекты. Хороший пример игра Spasim (1974), в которой объекты состоят из 3D-каркасов.


Spasim. Из-за каркасного строения игроки могли видеть даже обратную сторону объектов. Всё изменилось, когда появилась возможность закрашивать полигоны

Эпоха цветных спрайтов


Другим важным рубежом стало появление цветной графики. Ранние компьютеры имели совсем небольшие объёмы оперативной памяти, поэтому графическая информация не должна была занимать слишком много места. Для монохромных игр было достаточно одного бита, для 16 цветов четырёх битов, а восемь бит позволяли увеличить количество цветов сразу до 256.

В конце 70-х и начале 80-х персональные компьютеры всё ещё были роскошью. Зато подскочила популярность аркадных автоматов. Там же появились и первые цветные игры, потому что у автоматов хватало памяти для отображения цвета.

Появление цветной графики стало очередным витком развития игр. Дело было не только в эстетике: это влияло на весь игровой процесс. Например, в Pac-Man каждый призрак обладал уникальным поведением, а цвет помогал отличать одного от другого.


Pac-Man

Для создания движущихся объектов в играх применялись спрайты двумерные изображения. В Pac-Man сам герой и его противники это спрайты. Сейчас такие изображения можно рисовать в разных графических редакторах. Но 40 лет назад разработчикам приходилось идти на всевозможные ухищрения, чтобы перенести рисунок в цифровой формат.


Пример отрисовки спрайтов на бумаге для Pac-Man

Например, изображения для Super Mario Bros. приходилось сперва рисовать на целлулоиде, раскрашивать, а лишь затем оцифровывать. Если для этой игры размеры листов были средними, то для Punch Out!!! (1983) приходилось использовать листы размером со стол.


Пример отрисовки спрайтов Марио на целлулоиде

Сканеры использовались далеко не везде: отсканированные изображения занимали слишком много места на жёстких дисках, которые в то время были слишком дорогими. Также сканеры не могли корректно передать цвета, поэтому художникам приходилось оцифровывать только контуры и общие черты изображения, а затем полноценно отрисовывать его на компьютере.

Другая проблема возникала с самим использованием компьютеров это были сложные устройства, поэтому даже художники должны были обладать навыками программистов. Например, при создании Solomons Key (1986) приходилось использовать шестнадцатеричную кодировку для оцифровки каждой клетки спрайта.


Solomons Key

С развитием технологий и ростом популярности видеоигр стали появляться более мощные игровые приставки. Сперва на рынок вышли 8-битные консоли, поддерживающие до 64 цветов, а следом и 16-битные консоли с палитрой из 512 цветов. Несмотря на такое развитие, технические ограничения давали о себе знать. К примеру, на игровой консоли SNES из 512 доступных цветов одновременно на экране можно было использовать только 64.

Вместе с этим в играх начали появляться разные визуальные эффекты. Super Speed Racer (1979) привнесла скроллинг, благодаря которому окружение перемещалось сверху вниз и создавало ощущение движения. Эффект параллакс-скроллинга в двумерной Moon Patrol (1982) делал так, чтобы при движении объекта дальний план передвигался медленнее переднего, из-за чего возникала иллюзия глубины пространства и корректной перспективы. А Zaxxon (1982) показала, какими могут быть изометрические игры с иллюзией свободного передвижения по трёхмерному пространству.


Zaxxon

Одновременно с традиционными способами создания графики существовали и альтернативные подходы. Один из них ASCII-графика, в которой использовались текстовые символы для отрисовки элементов. Простота метода позволяла создавать удивительные экспериментальные игры. Например, в Rogue (1980), родоначальнице жанра roguelike, использовалась ASCII-графику, чтобы случайным образом генерировать локации. Благодаря этому каждое прохождение игры было уникальным.


Rogue

Другой путь интерактивное кино, в котором использовались заранее записанные фрагменты кино или анимации. В Astron Belt (1983) игрок управлял космическим кораблём, который бороздил космос и вступал в перестрелки с противниками. При этом корабль изображался с помощью спрайта, а фон был записанным заранее видео.



Dragons Lair (1983) была полноценным интерактивным мультфильмом если игрок нажимал на правильную кнопку, включался новый фрагмент анимации и пользователь продвигался вперёд. Если же игрок допускал ошибку, то включался фрагмент, в котором главный герой погибал.


Dragons Lair

Но основная масса игр использовала именно спрайты, которые со временем становились всё более детализированными и сложными. Взгляните на пример из Street Fighter II (1991): персонаж это не просто набор пикселей, в котором угадываются черты героя, а полноценное проработанное изображение с множеством деталей и собственными тенями. Постепенно таких игр становилось всё больше и больше.


Street Fighter II

Но это не значит, что все игры были однообразными и похожими друг на друга. Были разные способы выделиться на фоне остальных проектов. Один из них анимация.

Анимирование объектов происходило по тому же принципу, что и в мультипликации художник рисовал несколько кадров с разным положением отдельных частей, а затем кадры последовательно выводились, что создавало иллюзию движения. Обычно игровые художники самостоятельно отрисовывали кадры, но некоторые разработчики применяли технику ротоскопинга они записывали видео движения объекта, а затем покадрово отрисовывали его. Благодаря этому в Prince of Persia (1989) настолько плавная и визуально приятная анимация.

А в Mortal Kombat (1992) в качестве спрайтов персонажей использовались оцифрованные кадры, и поэтому графика выглядела намного реалистичнее, чем в остальных файтингах того времени.


Mortal Kombat

Популяризация 3D


В первой половине 90-х стало появляться всё больше 3D-игр. Первые трёхмерные проекты возникли ещё в середине 70-х, но тогда они не стали популярными. Со временем ситуация изменилась.

В основе 3D-моделей лежит полигональная сетка набор треугольников, которые определяют форму объектов. Если закрасить треугольники, то получится непрерывная поверхность. Затем на получившуюся форму можно натянуть текстуру изображение, пиксели которого привязываются к вершинам полигонов.

Если взглянуть на устройство 3D-моделей более абстрактно, можно сказать, что они представляют собой пустое пространство, ограниченное полигональной сеткой. Это очень легко заметить из-за багов если камера случайно провалится сквозь объект, то там будет лишь пустота.

В I, Robot (1983) 3D-объекты наконец утратили каркасный вид полигоны были заполнены цветом, и игроки уже видели не абстрактные линии, а полноценные объекты. Кроме того, в игре присутствовало освещение, поэтому на объектах была собственная тень. Но 3D-игры всё ещё были редкостью, так как требовалось по-настоящему мощное железо, чтобы поддерживать их.



Значимым шагом для популяризации 3D-графики стал релиз Wolfenstein 3D (1992) и Doom (1993). Несмотря на то, что они позиционировались, как трёхмерные игры, это было не совсем так. Пользователь мог перемещаться по объёмному окружению, но все объекты были сделаны с помощью двумерных спрайтов.

Особенность движка этих игр заключалась в том, что он использовал метод рейкастинга, что позволяло рассчитывать только те поверхности, которые видны пользователю. Это позитивно сказывалось на производительности, поэтому Wolfenstein 3D и Doom могли запускаться на самых разных компьютерах.


Wolfenstein 3D

В играх начала 90-х нередко совмещались 2D- и 3D-элементы. Например, в Alone in the Dark (1992) окружение состояло из плоских изображений, а подвижные элементы из полигонов. Это позволяло экономить вычислительные ресурсы компьютеров.


Alone in the Dark

Для создания реалистичной картинки важна корректная модель освещения. Но у ранних компьютеров не хватало на это вычислительных ресурсов, поэтому разработчики искали другие способы решения проблемы. Например, они запекали освещение в текстурах тень создавалась не в реальном времени, а уже была нарисована на модели.

Со временем технология динамического освещения эволюционировала. Уже в Quake (1996) летящие снаряды освещали окружение в реальном времени.


Metal Gear Solid (1998). Все тени здесь статичные и зафиксированы прямо в текстурах. Единственное исключение под персонажами находятся тени, которые выглядят как тёмные пятна и всюду следуют за ними

Во второй половине 1990-х, как и в любое другое время, развитие графики не шло по какому-то одному пути. Многое зависело от технологий, которые были в распоряжении у компаний. Если на персональных компьютерах графика развивалась плавно и постепенно, то на консолях этот процесс происходил рывками поколения приставок обновлялись раз в несколько лет. Именно поэтому некоторые визуальные особенности присущи только определённым консолям. Например, в играх на PlayStation у всех 3D-объектов было специфическое подёргивание при любых движениях или смене ракурса.

Появление новых технологий в области 3D


Постепенно в индустрии появлялись новые технологии, которые улучшали отдельные аспекты графики. Многие из них актуальны и сейчас, поэтому часто появляются в современных играх.

В начале 2000-х широкое применение получил метод затенения по Фонгу, при котором грани полигонов сглаживаются, а на некоторых поверхностях появляются блики.


На этом скриншоте из Planet Harriers (2000) на костюме героя видны блестящие элементы

Появилась технология антиалиасинга, которая сглаживает лесенки на краях объектов.


Пример из Half-Life 2 (2004). Слева изображение без сглаживания, а справа с ним

Стало применяться рельефное текстурирование. Оно визуально усложняет строение объектов и имитирует неровности, но при этом не добавляет полигонов.


Doom 3 (2004). Стены выглядят объёмными из-за рельефного текстурирования. Этот эффект не везде выглядит хорошо

К 2007 году появилась модель затенения ambient occlusion, улучшающая освещение. С её помощью можно рассчитать интенсивность света, доходящего до поверхности.


Crysis (2007)

Разработчики начали применять технологию HDR, которая расширяет диапазон яркости на экране одновременно отображаются как очень тёмные, так и очень светлые участки сцены.


Half-Life 2: Lost Coast (2005).

В 2000-х стали популярны эффекты, придающие изображению реалистичности с помощью постобработки.


Эффект motion blur смазывает изображение при движении. Need for Speed: Most Wanted (2005)


Эффект bloom добавляет свечение самым ярким участкам кадра. Также вокруг них появляется ореол, что делает изображение кинематографичнее. Пример из Gears of War (2006)


Эффект depth of field (глубина резкости) размывает объекты, находящиеся не в фокусе. Это позволяет сконцентрировать внимание на самой важной части сцены. Пример из Silent Hill 3 (2003)

В 2010-х года прогресс в развитии графики замедлился: если раньше прорывы случались раз в пару лет, то сейчас это происходит значительно реже. Качество картинки в крупных высокобюджетных играх стало по-настоящему впечатляющим и приблизилось к фотореализму, хоть скриншоты до сих пор и сложно перепутать с реальными фотографиями.

Последнее поколение консолей вывело стандарты графики на новый уровень, пусть и не настолько сильно, как в предыдущие годы. Так как качество графики в ААА-играх поднялось примерно до одного уровня, студии переключили внимание на проработку отдельных аспектов, улучшающих общее впечатление от графики.

Например, всё чаще стала использоваться система частиц, которая важна для создания впечатляющих визуальных эффектов.


InFamous: Second Son (2014)

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


В Star Wars: Battlefront (2015) с помощью фотограмметрии создавались естественные объекты окружения


В Red Dead Redemption 2 (2018) разработчики уделили особое внимание влиянию погоды и облаков на освещение в игровом мире


Detroit: Become Human отличается проработанной системой отражения света у кожи. Взгляните на ухо андроида: оно просвечивает, из-за чего выглядит красноватым. Разработчики специально добавили этот эффект для реалистичности

Последний наиболее значимый прорыв в области графики появление видеокарт, которые поддерживают трассировку лучей. Эта технология позволяет имитировать реальное поведение лучей света, отражающихся от объектов.


Слева скриншот с трассировкой лучей, а справа без. Разница в отражениях очевидна. Пример из Control (2019)

Альтернативные пути


Игровая индустрия разнообразна и многогранна, поэтому далеко не все разработчики стремятся к реализму. Иногда это касается эстетических взглядов, а иногда финансовых ограничений. В середине 2000-х появились удобные цифровые магазины, через которые независимые студии могли продавать свои игры.

Это стало огромным толчком для развития инди-сцены. У маленьких студий, состоящих из одного или нескольких человек, не было ресурсов для разработки игр с реалистичной графикой. Поэтому они начали экспериментировать с визуальным стилем. Этим же занимались и более крупные студии.

Во второй половине 2000-х стали популярны игры, выполненные в стилистике пиксель-арта. Её преимущество заключается в том, что для получения качественной и эстетически приятной графики не нужны продвинутые художественные навыки. Другая причина популярности ностальгия по играм 80-х годов.


Undertale (2015)

В условиях ограниченных ресурсов некоторые разработчики пошли по пути упрощения. Игры в стиле low-poly используют простые низкополигональные объекты.


Grow Home (2015)

Также стали применяться некоторые непопулярные и практически забытые техники. Например, в основе всех объектов в Minecraft (2009) лежат не полигоны или спрайты, а воксели объёмные пиксели, из которых можно собирать целые игровые миры. Если в обычных 3D-объектах полигоны окружают пустое пространство, то воксельные объекты буквально состоят из вокселей, как из кирпичей. Эта особенность легла в основу геймплея Minecraft, потому что она позволила всячески менять окружение разрушать объекты и строить что-то новое.


Minecraft


На основе вокселей можно создать мир с продвинутыми разрушаемостью и физикой. Пример из Teardown (в процессе разработки)

В 2000-х для стилизации под комиксы и мультфильмы разработчики начали использовать технику cel-shading. Игры с таким стилем отличаются чистыми цветами без градиентов, отсутствием плавного затенения, а также обводкой на контурах объектов. Но соответствие всем этим критериям не обязательное правило.


Техника cel-shading в Okami (2006)

Поиск необычных визуальных стилей продолжается и сейчас. Приведём несколько примеров игр с интересной графикой.


Superhot (2016):стильная и минималистичная low-poly графика с интуитивно понятной цветовой индикацией игровых объектов


Cuphead (2017): графика игры создавалась под влиянием работ аниматоров 1930-х годов


Limbo (2010): чёрно-белая эстетика, напоминающая театр теней


Ape Out (2019): минимализм и отсутствие деталей, а также имитация напечатанного изображения и плакатной графики


Monument Valley (2014): простая изометрия, которая позволила реализовать главную особенность игры невозможную геометрию и оптические иллюзии

Отсутствие большого бюджета это ещё не приговор. С помощью современных инструментов даже один человек может создать игру с реалистичной графикой. Хороший пример независимый разработчик Цзэн Сяньчэн и его игра Bright Memory: Infinite (в процессе разработки).

Например, вместо того, чтобы вручную анимировать мимику персонажей, он отсканировал собственное лицо и использовал её в игре. А для создания деревьев с листвой Цзэн применял специализированную программу SpeedTree, в то время как студии обычно отрисовывают детали с нуля. Знание разных инструментов и вдумчивый подход помогли разработчику-одиночке создать впечатляющую графику, которая может тягаться с некоторыми высокобюджетными играми.


Bright Memory: Infinite

В будущем качество графики будете постепенно расти, хоть и не настолько быстро, как на рубеже XX и XXI веков. Будет увеличиваться поддерживаемое разрешение, а также количество и качество визуальных эффектов. Скорее всего, трассировка лучей распространится повсеместно новое поколение консолей уже должно поддерживать эту функцию.

Традиционно с развитием технологий растёт и количество полигонов в объектах чем мощнее железо, тем больше информации оно может обрабатывать. Нет сомнений в том, что этот процесс продолжится и дальше, но, вероятно, и его ждут изменения.

Например, в этом году компания Epic Games анонсировала новую версию своего движка Unreal Engine 5. Как говорят в Epic, он позволит работать именно с тем количеством полигонов, которое нужно. Разработчикам не придётся оптимизировать высокополигональные модели, снижать их качество и разбираться с уровнем детализации. Компания уже продемонстрировала сцену, в которой используется более 16 миллиардов полигонов.

Гонка за фотореализмом, скорее всего, будет длиться вечно. Но важно понимать, что далеко не всем играм необходима реалистичная графика. Есть множество проектов с уникальной эстетикой, которая появилась в результате творческих поисков и необычного видения авторов. Важность реалистичной графики неоспорима, но есть некоторые вещи, которые не зависят от количества полигонов и качества освещения.

Материал подготовил Владимир Семыкин.

Освоить профессию с нуля можно на курсе Геймдизайнер в Нетологии.

Вы пройдёте весь цикл разработки игр: создание концепции, проектирование игровых уровней и механик, психология игр, нарративный дизайн, специфика оформления игрового интерфейса, прототипирование, создание стратегии продвижения и вывод игрового продукта на рынок, аналитика игр.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru