Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML

в 9:08, , рубрики: .net, AR и VR, C#, c++, Luden.io, Mono, NivalVR, VR, vr/ar, датасеты, Дизайн игр, интервью, машинное обучение, Олег Чумаков, разработка игр

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 1

Несколько лет назад мне казалось, что Олег Чумаков (тогда еще из Nival) был самым известным программистом геймдева. Постоянно выступал, проводил Gamesjam, был частым гостем подкаста Как делают игры.

С появлением на рынке VR, Олег возглавил в компании новое подразделение — NivalVR. Но вы все знаете, с виртуальной реальностью что-то пошло не так, как хотелось.

Я на долгое время отвлекся от геймдева, а взглянув снова, увидел — у команды Олега дела стали только интереснее. Теперь она называется Luden.io и их симулятор специалиста по машинному обучению while True: learn() стал хитом в своей нише, вокруг него творится куча крутых историй.

Мы поговорили с Олегом, но я не смог выбрать только одну тему — слишком уж насыщен и разнообразен был его путь. А чтобы программист говорил о программировании не боясь быть непонятым, беседу поддержал мой друг, коллега и опытный разработчик fillpackart.

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 2
Олег Чумаков

Я поиграл в while True: learn(). Классная игра, я прямо залип.

Далеко прошел?

Нет. Я начал играть ночью и застрял на сайдквесте. Сидел, не мог лечь спать, пока не решу. Как у вас вообще дела с ней?

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

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

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

Там есть игрок, его зовут Мистер Флоппи (как его зовут в реальности — не знаю). Он к нам пришел на закрытой альфе. Мы пускали определенное количество людей, чтобы они поиграли, и мы получили примерный фидбек, могли скорректироваться.

У нас в игре есть кот — сидит на мониторе, мяукает. А по изначальной задумке, кот должен был мешать. Когда программируешь, он постоянно приходит, там «погладь меня», в монитор лезет. В общем, Мистер Флоппи когда играл, к нему приходил его реальный кот, живой, мешать ему программировать в игре. Он прислал эту фотографию, с нее все и началось.

Потом он увлекся, стал активным членом нашего комьюнити. Начал производить на 3D-принтере у себя дома этих котов в разных внутриигровых одеждах и рассылать их лучшим игрокам сам. Он, условно говоря, бесплатно делал мерч. Ему просто нравилось. И это очень теплое воспоминание про то, как у нас комьюнити самоорганизовалось. На наших проектах такого никогда не было. Бывали косплеи, фанарты, но чтобы люди сами печатали игрушки по игре и друг с другом делились — это впервые.

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

То есть, пока не получали?

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

Станислва Семенов — Data scientist и один из топовых юзеров Kaggle — играет в WTL

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

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

Иногда и я что-то привношу из любимого Customer Development. Например, выяснили такую проблему: дети ходят на курсы по программированию — их родители спрашивают «ну что на занятиях было?», дети такие говорят «да ничего». Родитель не понимает, толи ребенок рассказывать не хочет, толи и правда ничего не делали. Поэтому у нас в игре в игре отчеты автоматизированны. То есть родители получают сообщения — «ваш ребенок сегодня изучил перцептрон», «ваш ребенок обучил rnn-ку» и так далее. Такие фичи появляются благодаря моему взаимодействию между внешним миром и игрой.

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

Ясно. То есть, ты сам не программируешь сейчас?

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

О программировании в геймдеве

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 3

Ну давай про старые добрые времена вспомним. Расскажешь про себя как программиста?

Ну, самый крупный проект, на котором школу жизни получил, это игра Prime world. Это был очень крупный проект компании Nival. Моба с социальной частью (она назвалась Замок). В нашей команде, которая как раз им занималась, было больше 20 человек — и это только для одной маленькой части игры. Проект был чудовищных размеров, ну и там были все проблемы синхронного мультиплеера, какие существуют в этом мире.

Фил: А на какой стадии ты сам к проекту подключился? В каком положении он находился в этот момент?

Замок, но когда я пришел, там еще ничего не было.

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

Ф: И кем ты на него пришел, как кто?

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

Ф: Ага, это Unity. То есть, какой яп? Плюсы, C#?

Сессионная часть была на плюсах. Наша часть была на Unity. Основная логика была на C#. Но в силу того, что это был проект, так скажем, сложного сочетания технологий, через Thrift это генерировалось еще и в Python, потому что сервер был на Питоне.

Ф: Ох, и конечно это накладывало свой оверхэд на разработку на C#.

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

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

Ф: Представляю насколько это много проблем. Когда ты пришел на проект, ты уже был знаком с C# и миром .net?

Да, я был знаком. Я еще был знаком с Unity 2.6 (если не путаю), это был совсем странный продукт. Я сам на .net писал, но там был Mono на какой-то ранней стадии. Это еще времена, когда Мигель де Икаса даже не занимался Xamarin.

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

Ф: То есть до того ты работал с .net, обычным фреймворком, а здесь тебе дали другой рантайм, который по сути еще нормально не документирован.

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

Ф: А можешь рассказать про свою первую неделю на проекте. Вот ты прошел собеседование, ты разраб. Что дальше?

Ну для чистоты истории стоит сказать, что мы делали сначала не Prime World. До него был еще проект. Он, к сожалению, не добрался до релиза, и в один из дней мы перевелись на PW создавать Замок. Там было все так быстро — нам примерно дизайнеры описали идею, что должно получиться: «Должен быть какой-то замок, в замке игрок, он его развивает строит, прокачивает».

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

Таймлайн развития Luden.io

  • В 2014 году Nival сформировала отдельную команду для разработки образовательных игр в виртуальной реальности — NivalVR.
  • В январе 2015-го вышел их первый проект InMind — игра о путешествии в мозг человека на микроскопическом уровне для поиска нейронов, которые вызывают психические заболевания.

  • В том же году вышла InCell. Она развивала идею, но звучала совсем уже как текст поехавшего чат-бота — образовательная игра с элементами рейсинга и стратегии, с процедурной генерацией, для VR-устройств, о путешествии в клеточный мир человека.
  • На Epic Games Mega Jam 2016 Luden.io сделала VRobot — “бесполезную но веселую игру”, где надо крушить город гигантским роботом. В 2017 она вышла в Steam VR, в 2018 — на Playstation VR.

  • В 2016 году NivalVR переименовали в Luden.io.
  • В 2017 вышла ARrived — симулятор бога в дополненной реальности на технологиях Google ARCore, Apple ARkit and CoreML.

  • В марте 2018 вышла в ранний доступ while True: learn() — симулятор специалиста по ML, но без VR и AR.

О руководстве технологической компанией

Ну сейчас ты глава Luden.io. И как тебе — что труднее? Чисто разработкой заниматься или управлять всем этим, быть мостиком между миром и девелоперами?

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

А если теоретически сравнить две профессии — CEO и просто программиста? Я думаю программист — более вдумчивая и более медленная. Придумал, запланировал, сделал. Внешние факторы появляются реже и не в таком объеме. Там, условно говоря, всегда есть правильные решения, есть конкретные, четкие измеримые показатели, что правильные решения — это когда у тебя обсчет занимает не более двух миллисекунд и выполняется в N потоков. Ты точно знаешь эти параметры, если в них вписался — все хорошо.

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

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 4

Ф: Как по-твоему, опыт разработчика помогает тебе управлять?

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

Проводишь ли ты сам ревью?

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

А здесь ребята смотрят друг у друга код, но в основном при интеграции, когда мы собираем все фичи в единый бранч. Я не видел в геймдеве, чтобы когда у тебя 5-6 программистов, были большие процессы code review. Чаще всего это не особо нужно, продукт первичен, а срок поддержки не десятки лет.

Ф: А есть какой то консолидированный подход к разработке? Навязывается ли он?

Есть стандартный codestyle и базовые понятия, что куда комбинировать, архитектурные правила. Есть каркас проекта, в котором мы всегда работаем. Он проверен временем, и мы точно знаем, что не позволит нам выстрелить себе в ногу (по крайней мере из дробовика). Есть базовый набор модулей, которые из проекта в проект путешествуют. Некоторые написаны давно, некоторые недавно. Мы за счет большого переиспользования архитектурных стандартов, за счет соблюдения codestyle не скатываемся совсем в бездну.

Ф: Ты сам принимаешь участие в найме новых сотрудников?
Да, конечно.

Ф: Всех?
Всех.

У вас наверное не очень большая компания, да?

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

Ф: Но разработчиков ты сам не собеседуешь как разработчиков?

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

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

Геймдев vs бизнес-разработка

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 5

Ф: А бывают кейсы, когда люди из других индустрий переходят?

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

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

Он вам нравится, вы ему нравитесь, договариваетесь, выставляете оффер и человек пропадает. Иногда спрашиваете, «как там дела», и тебе говорят: «вот я пришел увольняться, начальник спрашивает, куда иду. Говорю, вот сюда. А он — ну давай мы зарплату тебе поднимем, и ты никуда уходить не будешь». Очень часто люди поддавались на дополнительную денежную мотивацию и оставались в своих индустриях.

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

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

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

Ф: Говорят, в банковских сферах, в бизнесе, качество кода повыше, чем в геймдеве.

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

Например у компании Кефир замечательной есть игра The Last Day on Earth. Сделана наверняка качественно и здорово. И она очень быстро полетела, стала очень популярной. Я думаю, последнее, до чего хватает рук, когда вот так начинает взлетать — это прочесать качество кода.

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

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

У нас, конечно, продукт и его показатели первичны. Иногда бывают ситуации похожие на то, что ты описываешь. Предположим, мы с тобой делаем проект, который по известной IP, мы знаем какое у него будущее. С некоторой точностью можем предсказать, что он будет поддерживаться 15 лет. Очевидно у нас сразу появляется business value в том, чтобы его поддержка не дорожала с каждым годом. Для этого нужно, чтобы он был хорошо задокументирован и понятно для нового программиста написан. Но таких проектов немного, которые поддерживаются по 15 лет — специфика индустри. World of Warcraft сколько? Как раз к 15 годам скоро будет. Вот там теоретически да. Но я думаю, что и 15 лет назад разработчики в Blizzard очень спешили доделать продукт и не все сделали идеально.

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

Безусловно.

Ф: В бизнесе по умолчанию делают код, который надо поддерживать 15 лет, а вы так не поступаете, верно?

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

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

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

Как делать игры и для себя, и для аудитории

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 6

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

Это всегда двоякий вопрос. Представим что мы делаем софт, который решает конкретную проблему пользователя. Мы к этому пользователю идем, спрашиваем у него «в чем проблема?» Разбираемся, находим, считаем экономику — готов ли человек платить за решение этой проблемы. Создаем продукт, который эту проблему решает.

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

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

Но тут тонкая грань. Нужно уметь посмотреть на продукт как для себя, но немножко другими глазами. Как воспримет человек, который не играл 5 лет? А человек который сейчас играет только в Destiny? Как посмотрит человек, который тысячу часов провел в доте. Вот так — но с той искоркой, что ты и сам должен играть — это бизнесовая мотивация.

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

Ну ты согласен, что ваши игры все-таки нишевые?

Конечно! Это основной плюс того, что мы делаем. Мы очень хотим быть нишевыми. Не пытаться развлечь мужчин от 20 до 40 лет — весь мир этих мужчин развлекает.

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

Работать по такому принципу прибыльно?

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

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

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

Вообще, видна общая линия между играми, твоими занятиями — gamesjam, лекции, ты, кажется, еще преподаешь…

Очень редко. Часов 10 в год, в лучшем случае.

Откуда такой интерес к образованию, преподаванию?

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

Вообще из всех?

Из всех. Любого года. Ну навскидку, все равно вспомнишь что-то.

Ну давай Масс Эффект.

Ок, Масс Эффект хорошая, мне тоже нравится. А у второго нашего…

Ф: Готика, наверное.

Блин, ну Готика тоже прекрасная. Я теперь задумался, а не назвать ли их. Готику я тоже люблю очень, и Масс Эффект мне нравится, но я прямо безумный фанат жанра симуляторов и тайкунов. Mini Metro я вообще считаю гениальным достижением современного игрового искусства. Не играли?

Да, да, видел ее.

Если проводить параллель с художественным искусством, то это такая «нуль форм», как у Малевича — когда минимальными усилиями подается огромный пласт глубокой системы.

Тайкуны и симуляторы это модель предметной области в которой мы интерактивно что-то делаем и видим последствия. Игры, если посмотреть глубже, это именно способ получить опыт без рисков. То есть игра — самая натуральная форма обучения. Вот у нас компания называется Luden.io. Если разложить, Ludus с латыни переводится двумя способами — игра и школа. Около колизея такие развалины, они называются Ludus Magnus. Это место, где учились гладиаторы, они там играли, боролись и так готовились к сражениям на арене.

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

Образование, которое было в формате 20-30 лет назад стало слабоосуществимо. У ребенка в руках телефон, на нем есть Youtube, Twitch, какая-нибудь игра, и все это гораздо более интересное, чем читать заумную и не увлекательно написанную книгу.
Если мы эти формы соединим — играть и познавать, то выиграем со всех сторон.

Что случилось с VR

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 7

По такому же принципу у первых проектов была идея делать упор на VR?

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

Поэтому мы решили, что к своей цели мы продолжим идти, но VR… У нас на всех платформах выпущены проекты. Кроме того у нас в производстве VR проекты, которые интегрируются в школы. Если на какой-то из платформ что-то сдвинется с места, и это будет виртуальная реальность, которая поможет производить полезные игры, то мы обязательно усилим там свое присутствие. А пока у нас там много игроков, все рады и счастливы но while True: learn() — без виртуальной реальности.

После Е3 как раз ходила эта картинка по интернету, что упоминаний VR в прессе катастрофически меньше, чем раньше.

Ну к сожалению, да.

Как думаешь, что случилось?

Хотите домой себе купить шлем виртуальной реальности?

Нет.

Ну вот. Вот это и случилось. Люди не хотят. Вот как только вы проснетесь и поймете, что хотите себе VR, значит переломный момент близок.

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

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

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

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

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

То есть, ты веришь, что он взлетит, просто позже?

Вопрос в каком формате. Будет ли это универсальное устройство, которое позволяет и AR и VR сделать, или раздельные устройства — сложно прогнозировать.

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

Есть одно отличное использование, кажется, Серегей Галенкин, мне рассказал. Один человек купил шлем смотреть кино, потому что у него четверо детей. Use case понятен сразу.

Работать было трудно с виртуальной реальностью? Технически.

С VR огромные проблемы есть с перфомансом, и требования платформ часто в том, чтобы его поддерживать. Мы сейчас вышли с нашей старой игрой — VRobot — на Playstation VR. Там, например, нужно обязательно поддерживать стабильные 60 фпс. На Oculus (в том числе на мобильном) нужно поддерживать 75 фпс. Даже если в определенные моменты на 20-30 кадров падает — все. Ты должен игру оптимизировать, чтобы не падало.

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

Ф: То есть, у вас есть отдельный чувак для оптимизаций?

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

Про машинное обучение в геймдеве

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

Он программировал искусственный интеллект для Black&White Питера Мулинье. А затем в собственной компании Elixir Studios выпустил, например, симулятор бондовского супер-злодея Evil Genius.

И только потом стал одним из известнейших исследователей ИИ в мире.

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 8

В while True: learn() отображен ваш реальный опыт?

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

А в while True: learn() мы брали за референс не другой проект — у нас референс был реальность. Если делаешь что-то и не знаешь, как сделать — посмотри как в реальной жизни. Экономика игры — это аренда вычислительных серверов. Если ты решаешь задачу по обработке огромного массива данных, ты арендуешь себе сервера, считаешь, сдаешь, прекращаешь аренду.

Мы хотели показать в игре хронологию развития машинного обучения с 50-х годов, с первого перцептрона и заканчивая современными self driving cars, всякими капсульными сетями и так далее.

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

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

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

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 9

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

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

В команде люди занимались раньше машинным обучением?

Да. while True: learn() мы делали параллельно с запуском VRobot, поэтому VR команда у нас была сконцентрирована на портировании на Playstation. А новая небольшая команда как раз состояла из специалистов по машинному обучению.

А расскажешь про них, что за команда, над чем они работали раньше?

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

Ф: Ты подбирал ML специалистов?

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

Ф: И они делали игру. Но разработка игры — это же не machine learning, правильно? То есть это фулстеки — дата саентисты и продуктовые разработчики в одном лице.

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

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

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

Ф: ML и геймдев не так давно начали пересекаться. Вот, например, у меня игра с машинным обучением. Какой стек подойдет?

Я не видел много проектов, которые пересекают машинное обучение и геймдев — именно продуктового использования, чтобы в клиенте игры что-то происходило.
В Unity есть собственная система reinforcement learning. Она позволяет делать небольшое количество вещей, но встроена прямо в Unity, поэтому порог входа невысокий.

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

В мобильных технологиях часто используют CoreML от Apple, который позволяет вычислить прямо на GPU девайса. Берем модель, обучаем ее в том же TensorFlow или в яндексовском CatBoost, упаковываем в специальный файлик — и вот она уже может на айфоне запускаться прямо на GPU и нам выдавать результирующий prediction обратно.

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

Если говорить не о продуктовом использовании, не в клиенте игры — там все классическое. На серверах люди гоняют самые обычные технологии, которые во всем ML. Но там это используется для аналитики или персонализации оффера.
Знаменитый кейс — пытались предсказать, когда из World of Tanks отвалится игрок, и что с этой информацией сделать.

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

А может ли в центре дизайна игры встать сбор датасета?

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

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

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

А в AIDraw это не было задачей?

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

Ф: Допустим ты задумал игру, которая будет как-то использовать ML, и в процессе разработки понимаешь, что как задумал — не получится, а получается что-то совсем другое. У тебя бывали такие случаи?

Например, мы знали, что в while True: learn() будет выпускаться большой апдейт про self driving cars. Игрок будет обучать машинку ездить, огибать другие машинки, перестраиваться, газ поддавать, тормоз нажимать.

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 10

Обычно в геймдеве геймдизайнер пишет диздок, по диздоку производится контент (ну как по ТЗ в других областях). Но с машинкой мы сразу понимали — у нас там будет несколько этапов, несколько технологий. Будет учить генетика. Игрок поймет, что генетика учится, но она не очень хороша. Потом будет reinforcement разных типов. Игрок поймет, что определенный reinforcement для этой задачи эффективнее.

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

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

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

Ф: Не чувствует своего вклада?

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

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

То есть, мы закладываем, что с ML всегда что-то может пойти не так. Заранее продумать это на этапе дизайна практически невозможно.

Ф: То есть, вы закладываетесь на то, что вам придется сделать прототип, посмотреть как он себя поведет и по сути переделать заново?

Безусловно, да.

Ф: Но это нестандартно для разработки. Это фича именно ML, верно?

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

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

Создатель игры while True: learn() о программировании в геймдеве, проблемах с VR и симуляции ML - 11

Автор: Артем Малышев

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js