Criador de while True: aprenda () sobre programação em desenvolvimento de jogos, problemas de RV e simulação de aprendizado de máquina

Há alguns anos, senti que Oleg Chumakov (então trabalhando no estúdio de jogos Nival) era o programador mais famoso da indústria de desenvolvimento de jogos. Ele estava discursando, hospedava Gamesjams e aparecia frequentemente no podcast Como os jogos são feitos .

Quando a VR chegou ao mercado, Oleg foi escolhido para liderar o novo departamento da empresa - NivalVR. Mas, como você provavelmente sabe, a VR não decolou tanto quanto as pessoas esperavam.

Eu meio que mudei para outro para outras coisas na vida e parei de acompanhar o desenvolvimento do jogo por um tempo, mas depois de entrar nele novamente, notei que as coisas estavam melhorando para a equipe de Oleg. Agora, ele se chama Luden.io, e seu simulador de especialista em aprendizado de máquina, enquanto True: learn () se tornou um enorme sucesso em seu nicho reconhecidamente pequeno. Muitas histórias legais estão acontecendo ao redor do jogo e da equipe.

Decidimos fazer uma entrevista com Oleg, mas eu não pude manter um tópico - a vida dele até o momento foi, pela falta de uma palavra melhor, “interessante”. Ele viu tudo. E, para garantir que um programador possa falar sobre programação sem medo de parecer "nerd" demais, a entrevista foi conduzida por meu amigo, colega e um desenvolvedor experiente de seu próprio pacote de preenchimento .


O próprio Oleg Chumakov

Eu fiz check-out enquanto True: learn (). Um ótimo jogo, a propósito, eu simplesmente não conseguia parar de jogá-lo.

Até onde você foi?

Não muito longe. Comecei a tocar à noite e imediatamente fiquei preso em uma missão paralela. Não consegui dormir até que eu resolvesse. Como estão as coisas no jogo, a propósito?

Muito bem. Não podíamos nem imaginar que cresceria assim. Planejamos apenas um projeto pequeno. Veja desta maneira: pegue todos os jogadores e depois aqueles que jogam apenas jogos de quebra-cabeça e nada mais. A partir daí, leve aqueles que estão prontos para se envolver em programação. E, a partir daí, leve as pessoas que gostam especificamente de aprendizado de máquina. Esse foi o nosso público-alvo. Mas é claro que não foi exatamente assim.

Só na primeira noite, conseguimos mais jogadores do que esperávamos atrair em meio ano. Então, obviamente, as semanas seguintes foram bem divertidas. Tentamos adicionar suporte para idiomas diferentes e, em geral, mantemos o jogo à tona enquanto conversamos com milhares de pessoas ao mesmo tempo no Discord.


Tenho a sensação de que o seu bate-papo do Discord está muito engajado, pois todos os que estão lá realmente gostam de aprender máquina. Você tem algumas histórias legais sobre seus jogadores?

Temos um jogador chamado Sr. Floppy (não faço ideia do nome dele na vida real). Ele se juntou ao projeto durante o alpha fechado, quando distribuímos o jogo para um número limitado de pessoas para obter feedback.
No jogo, você (o programador) tem um gato, fica no monitor e mia o tempo todo. Mas, inicialmente, era para distraí-lo ativamente do processo. Chegaria um momento muito inoportuno e exigiria que você brincasse com ele, sente-se diante do monitor, esse tipo de coisa. Foi idéia do Sr. Floppy: quando ele estava jogando, seu gato sempre o distraía, então ele tirou uma foto, publicou no Discord e todos imediatamente souberam o próximo recurso que adicionaríamos.

Ele realmente se envolveu na comunidade. Ele começou a imprimir em 3D esses gatos do jogo com roupas diferentes e os enviou aos melhores jogadores. Essencialmente, ele lidava com nossa mercadoria gratuitamente. Ele estava apenas dando um chute nisso. É uma lembrança muito calorosa sobre como nossa comunidade surgiu por conta própria - não tivemos isso em nossos projetos até agora. Tínhamos pessoas fazendo cosplays, artes dos fãs, mas objetos de impressão 3D do jogo para presentear um ao outro - foi o primeiro.

Havia alguns jogadores que esperavam mergulhar no aprendizado de máquina e o jogo suavizou a barreira notoriamente alta de entrada para eles. Depois de jogar, eles foram para o Coursera, procuraram competições de vários níveis ... E estamos de olho neles, apostando em quem seria o primeiro a conseguir um emprego de verdade no aprendizado de máquina. Quando esse dia chegar, provavelmente celebraremos.

Então, isso significa que ninguém fez isso ainda?

Eles estão no meio de seus cursos no momento. O jogo saiu em março, ainda não houve tempo suficiente. Mas geralmente, muitas coisas legais aconteceram com o jogo. O YouTubers o usou para ensinar aprendizado de máquina, por exemplo. Atualmente, o jogo é usado nas escolas - na Rússia, Reino Unido, EUA, Austrália, em todo o lugar. Por isso, não posso citar exatamente a história mais legal que aconteceu conosco - temos alguns candidatos a cada semana.


Stanislav Semenov - um cientista de dados e um dos principais usuários do Kaggle - joga WTL

OK, voltaremos ao aprendizado de máquina mais tarde. Diga-me o que exatamente você faz no projeto, descreva seu dia normal de trabalho.

Minha responsabilidade agora é conversar com a equipe principal, falar sobre seus planos (o que vai fazer nos próximos 2-3 meses) e manter esse plano em mente para todos com quem trabalhamos. Integrando o jogo em várias atividades, ajude a vendê-lo para aquela escola ou para esta escola. Em suma, sendo a ponte entre os desenvolvedores e o mundo exterior.

Às vezes, contribuo com algo do meu profundo interesse - desenvolvimento de clientes. Por exemplo, ao integrar o jogo em um curso escolar, encontramos um problema: as crianças frequentam os cursos de programação e depois voltam para casa, os pais lhes perguntam “o que você fez nessas aulas” e eles respondem “realmente nada”. E os pais se perguntam - eles simplesmente não querem contar a eles ou realmente não fazem nada. Por isso, automatizamos os relatórios de progresso: por exemplo, os pais podem receber mensagens "seu filho aprendeu o perceptron hoje" ou "seu filho programou um rnn" e assim por diante. Esses recursos acontecem graças às interações entre o jogo e o mundo - principalmente através de mim.

Além disso, como CEO, meu trabalho é inspirar todos com um objetivo comum e abrangente, tornar o trabalho de todos confortável, eliminar as complicações e fazer as pessoas simplesmente trabalharem e não se preocuparem com as necessidades básicas.

Tudo bem. Então você não está se programando agora?

Sim, mas apenas ocasionalmente. Atualmente, trabalho em reformular startups no jogo. Eu tive uma idéia de como fazer isso por um longo tempo, no entanto, para o nosso próximo projeto dedicado ao marketing na Internet, mas não tive tempo para isso. Eu fazia essas coisas em uma semana, agora demoro um mês e ainda não está pronto.

Sobre programação no desenvolvimento de jogos

Vamos relembrar os bons velhos tempos. Você poderia me contar sobre sua vida como programador?

Bem, o maior projeto em que participei, o que moldou minha futura carreira, foi o jogo Prime World. Foi um grande projeto em Nival, um MOBA com um elemento social (chamado Castle, acredito). Eu estava no time do castelo e tinha mais de 20 pessoas - por uma pequena parte do jogo! E, bem, ele tinha todos os problemas do multiplayer sincronizado que existem neste mundo.

Quando você se juntou ao projeto, como era a essa altura?

Quando entrei, "Castle" praticamente não existia.

Mas, apenas para informar os leitores que não jogaram - o jogo teve duas partes: a que tem batalhas reais no estilo MOBA e o Castle, onde o jogador sobe de nível, contrata heróis, os desenvolve, os desenvolve, depois escolhe um herói e entra em batalha . A parte da batalha estava quase completa nesse ponto, mas a parte social estava nos estágios iniciais do desenvolvimento.

E como Nival o contratou?

Eu vim como programador regular. Lembro-me de criar um novo projeto do Unity - começamos do zero e tivemos que criar o castelo e integrá-lo à parte da batalha, em desenvolvimento ativo.

OK, então era a Unidade. Qual linguagem de programação, então? C ++, C #?

A parte da sessão foi em C ++, nossa parte foi no Unity e a lógica principal foi em C #. Mas, como era um projeto complexo, digamos, com muitas tecnologias se cruzando, também colocamos tudo no Thrift para traduzi-lo para Python, porque foi nisso que o servidor foi escrito.

Uau, fale sobre despesas gerais para o desenvolvimento de C #.

E isso é para dizer o mínimo. Mas ainda encontramos uma maneira elegante de fazer isso. Nossos colegas de trabalho mais velhos eram caras muito experientes, por isso, adaptamos o código especificamente para esses tradutores e tudo foi bastante bonito - praticamente sem necessidade de arquivamento manual.

Acredito que estava de volta durante o tempo em que tecnologias como Thrift, Protobuf e outras estavam apenas decolando. Consideramos um milagre tecnológico - eles pegaram seu código em vários idiomas e resolveram o problema de juntar tudo.

Eu só posso imaginar. Quando você ingressou no projeto, você já conhecia o C # e o mundo do .NET em geral?

Sim, eu era bastante familiar. Eu também conhecia o Unity 2.6 (se bem me lembro), mas esse era um produto estranho por si só. Eu poderia escrever no .NET, mas no Mono, em algum estágio inicial. Foi o momento em que o Xamarin ainda não estava em desenvolvimento.

Lembro-me de Mono ser um animal bastante selvagem que as pessoas raramente viram, mas foi incorporado ao Unity, que foi o maior projeto a incluir o Mono. Portanto, ele tinha todos os pequenos problemas que as VMs tiveram em suas infâncias. Vazamentos de memória insanamente altos em todas as plataformas, diferenças imprevisíveis do .NET nas coisas mais comuns, alocações desnecessárias em todo o lugar ...

Então, antes disso, você trabalhava com o .NET normal e recebia um tempo de execução diferente e mal documentado (na época).

Já trabalhei no Unity antes, mas isso, por falta de um termo melhor, “período de transição” - quando você trabalhou no Unity e agora precisa trabalhar em Mono - foi difícil. Não posso dizer que fui um desenvolvedor .NET particularmente experiente. Eu tinha uma compreensão geral e até alguns projetos concluídos, mas não me importava com o desempenho, então provavelmente cometi muitos erros de otimização em meus projetos. Todas as partes que exigiam desempenho estavam em C ++, o .NET não tinha nada a ver com elas.

Conte-me sobre sua primeira semana de trabalho. Você passou na entrevista, recebeu uma oferta e boom - você é um desenvolvedor. O que vem a seguir?

Bem, é importante mencionar que não começamos com o Prime World. Havia outro projeto antes disso, mas ele não foi lançado e um dia fomos transferidos para o Prime World para trabalhar no castelo. Aconteceu tão rapidamente - nossos designers delinearam uma ideia muito rudimentar do que eles queriam: “Deveria haver um castelo e um jogador dentro dele, ele o constrói, aumenta o nível etc.”.

Lembro que, na primeira semana, construímos o contorno básico de um castelo com alguns blocos básicos, apenas para mostrar aos designers o que poderia ser. E então, depois que a interatividade básica foi concluída, tivemos que descobrir como deveria funcionar no lado do servidor - como visitar o castelo de um amigo para conferir, como motivar o jogador a fazer a transição para a batalha. Então o jogador contratou heróis, elevou o nível deles, comprou os talentos certos, como ele precisa ir para a batalha com esse herói. Mas para ir para a batalha, precisamos transferi-lo da parte do castelo para a parte da sessão. E as partes são baseadas em diferentes idiomas e tecnologias - não foi uma ponte rápida para construir. Mas isso foi há muito tempo.

Cronograma de desenvolvimento do Luden.io

• Em 2014, a Nival forma uma equipe separada para trabalhar em jogos educacionais de realidade virtual - NivalVR.
• Em janeiro de 2015, seu primeiro projeto foi lançado: InMind - um jogo sobre viajar ao cérebro de uma pessoa em um nível microscópico para encontrar neurônios que causam problemas psicológicos.

• No mesmo ano, o InCell foi lançado. Ele se expandiu com a mesma idéia, mas parecia um chatbot enlouquecido - um jogo educacional com elementos de corrida e estratégia, com geração processual, para dispositivos de realidade virtual. O jogo era sobre viajar para o mundo celular de uma pessoa.
• Na Epic Games MegaJam 2016, o Luden.io criou o VRobot - "um jogo inútil, mas divertido", onde você esmagava uma cidade com um robô gigante. Em 2017, foi lançado no SteamVR e em 2018 no Playstation VR.

• Em 2016, o NivalVR se separou da empresa e foi renomeado para Luden.io.
• Em 2017, o ARrived foi lançado - um simulador de deus em realidade aumentada baseado em várias tecnologias: Google ARCore, Apple ARkit e CoreML.

• Em março de 2018, enquanto True: learn () - um simulador de expectativa de aprendizado de máquina, mas sem VR e AR - entrou no acesso antecipado.

Liderando uma empresa de tecnologia

Então, agora você é o chefe do Luden.io. O que é mais difícil: codificar puramente ou fazer todas essas coisas de gerenciamento, sendo uma ponte entre o mundo e os desenvolvedores?

Acredito que depende de que tipo de pessoas você trabalha. Tive muita sorte de ter as pessoas que faço e estou muito empolgado em gerenciar e codificar.

Mas, se compararmos os trabalhos de um programador e CEO teoricamente, a programação é um trabalho muito mais lento. Você tem uma idéia, planeja, faz. Distrações externas são raras e pequenas. Essencialmente, na codificação, você sempre tem uma decisão “certa” e métricas estritas e quantificáveis ​​de sucesso: uma decisão certa significa que você executa essa função em menos de 2ms e paraleliza em N threads. Você conhece os seus objetivos, se os acertar - tudo é bom.

O CEO não tem nada parecido. Neste mundo, não existe uma métrica formal de sucesso, mesmo que você as defina constantemente para os seus negócios. Você deve sempre pensar no que pode fazer melhor ou de maneira diferente. Também não há regras. Mas certamente tem seu charme.



Você acha que sua experiência como desenvolvedor ajuda você com suas responsabilidades de CEO?

Eu acredito que sim. Eu não acho que haverá muitas empresas de tecnologia no futuro que não têm um líder com um entendimento claro das rotinas de desenvolvimento em mente. Mal posso imaginar como isso funcionaria. Mas tenho certeza de que o líder deve, no mínimo, ter um diploma STEM para permitir que a empresa avance como um trem descontrolado - que é a velocidade mínima aceitável para uma empresa de tecnologia sobreviver nos dias de hoje. Não posso dizer que é o único caminho, mas acho que é o mais correto em termos de evolução.

Você faz a revisão do código?

Na verdade não. Quando trabalhamos no Prime World, um projeto enorme, eu fiz, mas na época tínhamos processos muito diferentes. Lá, revisamos toda a base de código para que ela adere a um padrão comum. O Prime World era tão grande que podíamos simplesmente esquecer que uma parte da base de código estava sendo usada em outra seção do jogo. Nós até lutamos para testar o projeto localmente, que era tão grande. Portanto, tínhamos padrões muito rígidos de revisão de código.

Mas lá, embora os programadores tomem emprestado código um do outro, é principalmente para integração, quando coletamos todos os recursos em uma única ramificação. Eu não vi pequenos estúdios de desenvolvimento de jogos, onde você tem 5-6 programadores, no máximo, faz um gigantesco processo de revisão de código. Geralmente não é necessário - o produto é o primeiro e não pretendemos apoiá-lo nas próximas décadas.

Existe uma abordagem consolidada para o desenvolvimento? Você força isso a todos?

Há um estilo de código padrão e algumas diretrizes básicas sobre o que combinar com o que, algumas regras de arquitetura. Existe um esqueleto de projeto no qual trabalhamos. Ele é experimentado e testado, então sabemos que não nos permitiria dar um tiro no pé (pelo menos não de uma espingarda). Há um conjunto básico de módulos que são usados ​​em vários projetos. Alguns deles foram escritos anos atrás, outros apenas recentemente. Isso - reutilizar a arquitetura, aderir a um estilo de código - não nos permite deslizar até o abismo.

Você participa pessoalmente do processo de contratação?
Claro.
Todos eles?
Todos eles.

Sua empresa não deve ser muito grande, é?

Bem, não milhares de pessoas, então eu tenho a oportunidade de conversar com todos os entrevistados por pelo menos 10 minutos - apenas para descobrir o que ele vê na indústria de jogos, quais jogos ele joga pessoalmente.

Mas você não entrevista os desenvolvedores como desenvolvedores?

Você sabe, eu tenho um pouco de sorte. Acho que o pessoal que faz, digamos, o software bancário não é tão fácil quanto nós. Nossa indústria de língua russa é muito pequena e, quando você trabalha lá por alguns anos, conhece muitas pessoas. Essencialmente, todo candidato, se não for um estudante recém-saído da faculdade, tem uma recomendação de alguém e um entendimento aproximado do que ele pode fazer.
Mas se eu tivesse que contratar 100 pessoas em uma semana, obviamente não poderia estar tão envolvido. Mas não preciso contratar isso rapidamente e, na maioria das vezes, se contratar pessoas, já estou familiarizado com elas.

Desenvolvimento de jogos vs desenvolvimento de negócios

Você tem pessoas vindas de outras indústrias?

Existem alguns, mas não frequentemente. As pessoas entram no desenvolvimento de jogos por uma razão muito simples - elas gostavam de fazer jogos quando eram crianças e apenas continuavam fazendo isso.

Tivemos algumas entrevistas marcantes com pessoas do setor bancário. Tivemos uma boa entrevista, concordamos verbalmente com algo, eles pareciam gostar e diziam: “Trabalho em um banco, sou pago muito, mas não gosto muito. Eu gostaria de seguir minha paixão, e isso é jogar ”.

Vocês gostam um do outro, fazem uma oferta e ... a pessoa desaparece. Às vezes você pergunta o porquê e ele diz: “Vim registrar uma carta de demissão, o chefe perguntou onde, eu respondi e ele se ofereceu para aumentar meu salário para me manter”. Muitas vezes, as pessoas recebiam o aumento salarial e permaneciam em seus setores.
Mas houve outros casos também. Muitas pessoas muito competentes vieram de outras indústrias, incluindo bancos.

Sim, lembro-me de ouvir essa história em um podcast - um programador de banco diz “Quero criar algo”, depois ele recebe um pedaço de papel com um número e fica. Você tinha esses pedaços de papel em sua vida?

Como todo mundo, eu tinha ofertas de emprego de todo o lugar. Eu nem olho muito neles, honestamente. É bom que eu esteja em demanda, mas quero me dedicar a esta empresa.

As pessoas dizem que os bancos, o código comercial é muito melhor que o código do jogo.

Eu gostaria de me sentar com alguém que trabalhou no setor bancário e no desenvolvimento de jogos. Mas teoricamente, no desenvolvimento de jogos, existem muitos casos em que o projeto decolou inesperadamente.

Por exemplo, há uma empresa, Kefir, e eles têm um projeto, O Último Dia na Terra. Provavelmente está muito bem feito. E decolou instantaneamente, ganhou mais popularidade do que eles jamais poderiam imaginar. Acho que nessa situação a última coisa que você pensa é na qualidade do código.

O processo de manter a base de código limpa repousa principalmente na consciência dos desenvolvedores. Especialmente desenvolvedores seniores que são usados ​​para escrever código bem-educado e manter tudo sob controle. Porque o estágio "vamos acabar com isso e depois repassar o código" não acontece. Ever.

Eu me envolvi em desenvolvimento de negócios - nossa empresa tinha um culto ao código de qualidade. Realmente não resolvemos tarefas, escrevemos um bom código - essa era a nossa tarefa inteira. Nós, como departamento de desenvolvimento, não pudemos discutir sobre como o produto funciona ou se ele existe. Vejo que você tem uma abordagem completamente oposta: seu trabalho é fazer as coisas.

Obviamente, colocamos o produto e seu sucesso em primeiro lugar. Pensamentos, às vezes, há situações semelhantes às que você descreveu. Vamos imaginar que estamos produzindo um produto em um IP famoso e existente e sabemos como será o futuro dele. Digamos, sabemos que será suportado por 15 anos. Obviamente, há valor comercial para garantir que o suporte não fique mais caro a cada ano. Mas há muito poucos projetos de jogos suportados por 15 anos - é assim que o setor funciona. Quantos anos tem o World of Warcraft? Com cerca de 15 anos, a Blizzard pode ter problemas com isso. Mas acredito que, mesmo há 15 anos, a Blizzard queria concluir o projeto e cortar alguns cantos ao longo do caminho.

Parece mais que em um projeto de jogo, você não pode prever quanto tempo vai durar, ao contrário dos projetos de negócios.

Sem dúvida.

Nos negócios, as pessoas estão acostumadas a criar uma base de código que dura 15 anos, mas você não faz isso, correto?

Os programadores geralmente não se concentram na criação de código fácil de suportar por 15 anos. Mas eu vi alguns projetos muito limpos, onde claramente muito tempo foi dedicado à qualidade do código, as pessoas eram muito responsáveis ​​e gostaram.

Se todo mundo gosta de manter as coisas limpas, isso se traduz em um produto de fácil manutenção, mas nossos negócios nem sempre exigem isso - estamos focados em fazer o produto funcionar.

Embora eu mal possa imaginar uma situação quando estamos criando um software bancário e não tenho idéia se ele decolará. As indústrias são muito diferentes para comparar.

Como fazer jogos para você e para as pessoas

Eu olho para os jogos do Luden.io e sinto que eles foram criados pelos desenvolvedores tanto para eles quanto para o público. Não levando em consideração nenhuma prática comercial e tal, não direcionando nada para o público específico.

É uma pergunta dupla, como sempre. Vamos imaginar que você crie um software que resolva um problema específico para o usuário. Vamos ao usuário e perguntamos "Qual é o seu problema?". Vamos aprofundar sua indústria, executar os números - o usuário está pronto para pagar por resolver esse problema ou não. E então criamos um produto que resolve esse problema.

Os jogos também podem ser considerados como software que resolve o problema de um jogador. Ele quer se divertir - no nosso caso, aprender alguma coisa. Mas não é como "minhas costas doem, tomo esse remédio e não dói mais". O jogador quer jogar algo bonito, algo com uma alma. Precisamos desenvolver química entre um usuário e o jogo. Ele quer "fazer amizade" com o jogo. Se houvesse uma maneira infalível de desenvolver essa química, da mesma forma que a solução de problemas no setor de negócios, talvez criar jogos para nós mesmos não fosse tão importante.

Se dissermos que não podemos realizar pesquisas detalhadas sobre o assunto, a única maneira de descobrir se o jogo estabelece esse relacionamento com o jogador é esse jogador. Se gostamos do jogo, se achamos bonito, interessante - então podemos deduzir que provavelmente há mais de um de nós, que outras pessoas que gostam deste jogo também existem.

Mas há uma vantagem muito boa lá. Precisamos olhar para o produto como fazemos por nós mesmos, mas meio que na terceira pessoa. Como uma pessoa que não joga há 5 anos vê o jogo? Que tal uma pessoa que só interpreta Destiny? Ou alguém que tem mil horas em Dota? Portanto, precisamos analisá-lo de diferentes perspectivas, mas também com a motivação comercial adicional de reproduzi-lo para seu próprio prazer.

A motivação mental é simples - os jogos são difíceis de criar e levam muito tempo; portanto, no final, você invariavelmente desenvolverá algo semelhante ao ódio por isso. Você já viu tantas vezes que se cansa disso. Mas se, entre tudo isso, você não gostar do jogo, inevitavelmente ficará relaxado no final do desenvolvimento. Não há outra maneira de desenvolver jogos a não ser fazê-los por si mesmos, caso contrário, você não fará o lançamento.

Mas, ao mesmo tempo, você concorda que seus jogos são bastante específicos?

Claro! Esse é o principal benefício do que fazemos. Queremos ser um nicho. Não estamos tentando entreter todos os homens de 20 a 40 anos - o mundo inteiro já faz isso.

Queremos que os jogos digam às pessoas algo útil, para serem os companheiros do jogador na vida. Certamente não é um nicho tão grande como, por exemplo, simuladores de esportes, onde o público é enorme e diversificado, mas nem pretendemos tentar capturar tantas pessoas.

O trabalho por esses princípios é lucrativo?

Eu acho que pode ser rentável (bem, nós conseguimos), mas você precisa, pela falta de uma palavra melhor, "preparar" um mercado primeiro. Trabalhamos há 4 anos e descobrimos em quais gêneros e formatos devemos trabalhar para ganhar dinheiro. Podemos fazer isso, mas ninguém diz que nossa marca é o dinheiro máximo que você poderia ganhar com esse setor.

Somente agora desenvolvemos um entendimento sobre como trabalhar nesse mercado, como criá-lo. Não é muito bem desenvolvido. Os próximos 10 a 15 anos serão gastos para tornar esse mercado mais acolhedor para desenvolvedores de terceiros que compartilham nossos objetivos - que os jogos precisam ser úteis.

Nosso objetivo é garantir que, em 20 anos, os jogos ajudem as pessoas a aprender e fazer algo que desejam fazer. Algo que também é procurado nesse mundo futuro, algo em que eles são mais eficazes. Então, universidades e escolas existiriam apenas para fins de pesquisa.

No geral, vejo um tema comum entre seus interesses - jogos, jogos, palestras, acredito que você até ensina ...

Muito raramente. 10 horas acadêmicas por ano, no máximo.

Quando esse interesse pela educação se originou?

Há algo de belo em ajudar jovens especialistas a serem melhores e mais felizes do que nós. A experiência ajuda com isso. Mas há também uma motivação menos "visionária". Qual é o seu jogo favorito? Vamos determinar quem você é pelos jogos que joga.

Favorito de todos eles?
Todos eles. Qualquer gênero. Apenas a primeira coisa que vem ao tipo.
Digamos Mass Effect.
OK, é uma boa escolha, eu também gosto. E o segundo?
Gótico, provavelmente.
Inferno, o gótico também é excelente. Gostaria de saber se nossos interesses se alinham. Também gosto dos dois, mas sou um grande fã de simuladores e magnatas. Mini Metro, por exemplo, considero uma conquista engenhosa do design de jogos modernos. Você já jogou?


Claro, eu sei disso.

Se traçarmos paralelos com a arte, é a mesma "forma nula" que Malevich gostava de imaginar - onde algum material enorme, escondido em um sistema profundo, é apresentado com o mínimo esforço.

Magnatas e simuladores são o tipo de jogo criado para que façamos algo e vejamos imediatamente as consequências. Jogos, se olharmos mais profundamente, é uma maneira livre de risco de ganhar experiência, o que significa que os jogos são a forma mais pura de educação. Nossa empresa é chamada Luden.io. Se olharmos para ele, “Ludus” traduz do latim de duas maneiras - jogo e escola. Há restos de um lugar chamado Ludus Magnus perto do Coliseu de Roma. Era um lugar onde os gladiadores jogavam e se preparavam para lutas na arena.

Assim, os simuladores são magnatas, projetados para proporcionar aos jogadores experiência em áreas onde é muito difícil obtê-lo naturalmente - muito caro ou absolutamente impossível dentro dos limites do planeta Terra. Eles preparam as pessoas para situações que possam surgir no futuro, permitem que elas “ensaiem”.

A educação que temos agora e que existe há 20 a 30 anos se tornou muito ineficaz. As crianças têm telefone, têm acesso ao YouTube, Twitch - tudo isso é muito mais interessante do que ler um livro que é cheio demais e nem mesmo bem escrito. Se combinarmos essas formas - educação e jogos -, todos ganharão.

O que aconteceu com a VR

Essas idéias foram a força motriz que levou sua empresa a se concentrar em VR?

VR é um tópico interessante. Quando nos separamos do Nival, o VR acaba de ser lançado. A RV certamente escala a parte mais forte dos jogos - a experiência sem riscos, pois adiciona um efeito de imersão muito forte. O cérebro acredita mais facilmente que está acontecendo de verdade, embora seja apenas mais uma ilusão de ótica. Mas o mercado está lutando no momento. Ninguém criou um aplicativo de VR que todos gostariam de ter em casa.

Por isso, decidimos avançar com nosso objetivo final, mas a VR ... Temos projetos em todas as plataformas. Além disso, temos alguns projetos de RV em desenvolvimento que pretendemos integrar nas escolas. Se uma plataforma realmente "move" o mercado e se torna a plataforma VR que a torna grande, obviamente trabalharemos em nossa presença lá, mas por enquanto temos muitos jogadores felizes em VR e, embora True: learn () seja tradicional , jogo não VR.

Após a E3, houve aquele gráfico circulando na Internet que há menos menções à realidade virtual na imprensa do que há um ano atrás.

Infelizmente isso é verdade.

O que você acha que aconteceu?

Você, pessoalmente, quer comprar um capacete VR?

Não.

Bem, essa é a sua resposta. As pessoas não querem isso. Depois que você - sim, você - acorda e decide que quer um capacete de realidade virtual, algo muda na direção certa.

Por que as pessoas não querem isso? Quando foi lançado, as pessoas estavam em êxtase, dizendo que em 5 a 10 anos a VR estaria em todo lugar, no estilo Ready Player One.

Primeira coisa: não ouça avaliações de negócios, apenas relatórios de consumidores. Um cliente, diferentemente de um empresário, poderia responder sua pergunta de forma simples e concisa. Então, pessoal, se você não quer um capacete de realidade virtual, sua motivação descreveria a situação muito melhor do que meus pensamentos de negócios.
É sempre assim - quando o jogo não está vendendo bem, basta ir a um Gamestop e perguntar a uma pessoa que não o comprou. Ele explicaria isso muito melhor do que todos os vendedores juntos.

Eu acho que é uma extensão de um problema de galinha e ovo. Você poderia comprar um capacete de realidade virtual, com certeza, mas há uma pergunta sobre o que fazer com ele. Mas as pessoas que criam conteúdo em RV se perguntam: por que desenvolvo jogos para esse tipo de hardware quando poucas pessoas o possuem? Não vou ganhar meu dinheiro de volta! E esse ciclo vicioso ainda não quebrou no mercado de RV.

Mas alguns segmentos surgiram e continuarão a melhorar. Começando com nichos menores e depois ficando cada vez maior. Como o surgimento de consoles de jogos nos anos 80 e 90, a melhor hora do VR levará algum tempo. Certamente não viria em 3 anos.

Então você acredita que a VR decolará, um pouco mais tarde?

Depende do formato. Seria um dispositivo VR-AR universal ou produtos separados é muito difícil de prever. Minha opinião é que a VR terá um nicho grande, mas especializado, como os tablets hoje. Muitas pessoas os têm em casa, mas poucas compram novas e ainda assim resolvem um problema definido. Eu acredito que a VR acabaria na mesma linha. Há um segmento de mercado para isso, a questão é: qual o tamanho.

Há outro uso para isso, no entanto. Um dos meus amigos me disse que ele comprou um capacete de realidade virtual para assistir filmes porque ele tem 4 filhos. O caso de uso é perfeitamente claro, eu acho.

Foi tecnicamente difícil trabalhar com VR?

O VR tem problemas de desempenho gigantes e exige muito das plataformas que o suportam. Um de nossos jogos antigos - VRobot - acaba de ser lançado no Playstation VR. Requer desempenho estável de 60 FPS. O Oculus Rift (incluindo a versão móvel) precisa de 75 FPS. Mesmo que caia 20-30 FPS durante cenas específicas - isso é inaceitável, você precisa otimizar o jogo melhor.

Mas temos uma equipe de otimização gráfica de baixo nível muito forte. Nikita, por exemplo, é especialista nisso.

Então você tem um cara de otimização dedicado?

Ele não está apenas fazendo isso, mas é sua principal habilidade. Ele trabalha em conjunto com Dima, que pode construir qualquer cena em 3D para quaisquer requisitos de desempenho. Então, estamos definidos nesse sentido.

Aprendizado de máquina no desenvolvimento de jogos

Para pessoas fascinadas pelo desenvolvimento de jogos e aprendizado de máquina, Oleg mostra uma foto de Demis Hassabis em busca de inspiração. Um prodígio do xadrez, um neurobiólogo e fundador do DeepMind, ele também iniciou sua carreira no desenvolvimento de jogos.

Ele programou sua própria IA para o jogo de Peter Moulineux, Black & White, e então, como chefe de sua própria empresa, Elixir Studios, lançou um simulador de super-vilão de Bond - Evil Genius.
E só então ele se tornou um dos mais famosos pesquisadores de IA do mundo.

Enquanto True: learn () é baseado em sua própria experiência?

Sim, o jogo é construído principalmente sobre isso. Como a indústria de jogos funciona é que, se você começar a fazer algo, precisará ter um ponto de referência para olhar para trás. Estamos fazendo uma simulação - há muitos detalhes que precisam ser cuidados e, para isso, precisamos de um ponto de referência, apenas para evitar sair completamente dos trilhos de forma criativa.

Enquanto True: learn (), tomamos nossa própria realidade como ponto de referência. Se você faz algo e não sabe o que fazer - veja como isso é feito na realidade. A economia do jogo está alugando farms de servidores. Se você tentar resolver uma tarefa de processar um grande cluster de dados, alugue um pouco de poder de computação, execute seus números, envie a tarefa e pare seu aluguel.

Queríamos mostrar como o aprendizado de máquina se desenvolveu desde a década de 1950, desde o primeiro perceptron até carrinhos de condução, redes de cápsulas e assim por diante.

A Vanya manteve especificamente uma planilha do Google com todos os pontos de referência - principais marcos do aprendizado de máquina, como a indústria mudou ao longo do tempo e quais novas tecnologias foram desenvolvidas. E é assim que é apresentado ao usuário - através de missões.

Algumas versões de jogos chegaram a mencionar um ano. Nós o removemos por vários motivos; talvez voltemos a fazê-lo em algum momento no futuro. Mas o jogador viaja pelo mesmo caminho - completa algumas missões com o perceptron e ganha um pouco de dinheiro.

Todo ano acontecia algo interessante que era confirmado ou repreendido pelo desenvolvimento futuro.



Você pode clicar em qualquer bloco e descobrir como ele funciona no jogo e, na realidade, existem dois links: um para um vídeo do YouTube que conta sobre isso de maneira concisa e o outro para um artigo detalhado para aqueles que quer realmente entrar nisso.

A equipe já trabalhou no aprendizado de máquina?

Claro. enquanto True: learn () foi feito ao longo do VRobot, a equipe de VR estava focada em transferir o jogo para o Playstation, e a nova equipe menor consistia em especialistas em aprendizado de máquina.

Conte-me sobre eles: como é a equipe, no que trabalharam antes?

Nada de especial, realmente. Quando surgiu a idéia de criar um simulador de ML, escolhi uma equipe com as recomendações de amigos e alunos.

Especialmente especialistas em ML?

Sim, mas todos eles são bem jovens, ninguém tem 20 anos de experiência em aprendizado de máquina. Todo mundo jogou Kaggle pelo menos duas vezes, resolveu algumas tarefas. A maioria deles estudou na universidade.

E eles fizeram um jogo. Mas, novamente: desenvolvimento de jogos não é realmente aprendizado de máquina, certo? O que significa que são pilhas completas - cientistas de dados e desenvolvedores de jogos em um?

São pessoas que, em primeiro lugar, entendem o aprendizado de máquina, sabem como ele funciona. E então eles desenvolvem um jogo no Unity, escrevem código, projetam interfaces e assim por diante. É só que, para desenvolver missões e colocá-las ao longo de uma linha do tempo, você precisa entender o contexto primeiro. Obviamente, eles não criaram um notebook ipython para todas as missões.

Temos uma biblioteca específica que executa redes convolucionais e algumas coisas básicas na Sharp que funcionam no Unity. Também foi usado para criar o AIDraw - um jogo de desenho: o jogador desenha alguma coisa e a IA precisa adivinhar o que está sendo desenhado. Essa biblioteca faz a maior parte do trabalho e o jogo inteiro é construído em torno dela.

Não faz muito tempo que o aprendizado de máquina e o desenvolvimento de jogos começaram a se unir. Digamos que eu tenho um jogo que utiliza aprendizado de máquina. Que tipo de pilha eu preciso?

Não vi muitos projetos que combinassem desenvolvimento de jogos e aprendizado de máquina, estritamente falando - onde o trabalho de ML é visto no lado do cliente. O Unity possui seu próprio sistema de "aprendizado por reforço" que não faz muitas coisas necessariamente, mas é incorporado ao Unity, portanto a barreira de entrada é bastante baixa.

Existem muitas bibliotecas para isso, assim como para outros campos: estruturas C ++, redes neurais ...
Os dispositivos móveis costumam usar o CoreML da Apple, que pode executar seus cálculos diretamente no chip gráfico do dispositivo. Pegamos um modelo, “ensinamos” no TensorFlow ou no CatBoost da Yandex, empacotamos em um arquivo especial e lá vamos nós - ele pode rodar diretamente na GPU do smartphone e retornar uma previsão resultante para nós. Nós o usamos, como exemplo, no nosso jogo de realidade aumentada ARrived, onde era necessário tirar uma imagem de uma câmera e descobrir o que era.

Se falamos sobre o uso de back-end, no entanto, tudo é muito clássico e direto. Os servidores executam tecnologias muito simples usadas em todo o aprendizado de máquina, mas são usadas para análise ou personalização - segmentação de anúncios, por exemplo. Um caso bastante famoso foi prever quando um jogador do World of Tanks se desconectaria do servidor e o que fazer com ele. Ou prever o tempo para oferecer ao jogador uma oferta - dois cavalos pelo preço de um - quando é mais provável que ele a compre e fique feliz com isso. Estes são aplicativos de servidor e o tamanho da pilha não é realmente um problema.

Mas a construção de um conjunto de dados pode estar no centro do design de um jogo?

Parece um conceito direto do Westworld. Pode ter seus usos, mas não vejo como um conjunto de dados de ações de jogadores pode ser benéfico para nós.

Por exemplo, fazemos um jogo sobre dirigir em um ambiente da cidade. Criamos um modelo realista de estradas de Moscou. Podemos ver que muitos jogadores travam nesse local ou excedem o limite de velocidade nesse trecho. Com um conjunto de dados como este, podemos descobrir onde estão os problemas.

Mas se é apenas um jogo e não um simulador? Talvez o conjunto de dados possa resolver os problemas da empresa e não os dos jogadores. Se a empresa cria jogos de um tipo semelhante, os conjuntos de dados de comportamento do jogador podem ser úteis para eles, mas não vi projetos construídos especificamente para esse fim.

Não era esse o objetivo do AIDraw?

A escala importa. Se tivéssemos 300.000 vezes mais jogadores, provavelmente algo poderia ter acontecido. Se o Google fizesse esse jogo, eles poderiam coletar dados valiosos e fazer algo com eles, para fins de pesquisa. Mas não para nós.

Vamos imaginar que você criou um jogo que usa ML em alguma capacidade e, durante o desenvolvimento, você percebe que não pode criar exatamente o que imaginava - criou algo diferente. Isso já aconteceu com você?

Por exemplo, sabíamos que queríamos lançar uma grande atualização enquanto True: learn () sobre carros autônomos. O jogador ensinaria um carro a dirigir, ultrapassar outros carros, mudar de faixa, acelerar e frear.



Normalmente, o designer do jogo escreve um documento de design, e o conteúdo é criado com base nisso (como em outros setores). Mas com carros entendemos desde o início que não seria assim. Tivemos vários estágios, cada um com sua própria tecnologia. O jogador aprenderia genética; entenda que não é muito bom para os propósitos dele. Então haveria reforço de várias formas. O jogador entenderia que um método de execução específico é mais eficaz para sua tarefa.

Não é uma experiência que possa ser controlada. Sabendo que algo pode dar errado, primeiro escrevemos uma demonstração técnica - uma versão bruta e técnica da experiência que queríamos criar. Em seguida, entregamos aos criadores de jogos, que o jogaram, escrevemos um documento de design e finalizamos e finalizamos o jogo com base nisso.

E não apenas os designers de jogos também - nós temos uma comunidade dos amigos mais próximos do Discord, podemos dar a eles uma demonstração do recurso e eles podem nos dar feedback. Atualmente, eles jogam a demo de carros autônomos por algumas semanas e estão constantemente nos contando suas experiências.

Com o que acabamos, no final? Primeiro, declaramos que tipo de entrada de dados deve ser usada para ensinar um carro a dirigir, quais parâmetros podemos alterar (limites, perdas; em genética, tamanho de geração, mutações). E o que saiu foi algo não muito interativo. O jogador efetua login, define alguns parâmetros e depois olha para a tela enquanto o carro dirige sozinho. É legal para os desenvolvedores que conhecem o conceito, mas não para o jogador que não conhece.

O jogador não sente sua contribuição?

Exatamente, não há feedback. Então, mudamos um pouco o design. O jogador dirigia o carro, ensinava. E então repetiria depois que você baseasse em como o treinou.
Se o jogador mudar apenas para a faixa da direita, o carro não saberia como mudar para a esquerda, porque você não o ensinou. Tornou-se interativo. Então talvez não estejamos longe do produto final.

Em essência, entendemos que, com o aprendizado de máquina, algo pode dar errado. É praticamente impossível explicar tudo no estágio de design.

Então você planeja criar um protótipo e refazer algo do zero, afinal?

Essencialmente sim.

Mas não é assim que os desenvolvedores de jogos fazem as coisas. É uma coisa exclusiva de aprendizado de máquina, certo?

Você pode dizer sim. Em outros jogos e indústrias, podemos prever coisas. Não somos novatos nisso, portanto podemos entender o que o jogador fará, que emoção ele experimentará. Nosso "banco de dados de previsões" que construímos ao longo dos anos pode lidar com isso. Aprendizado de máquina, no entanto? Toda convenção sai pela janela.