Alguns anos atrás, parecia-me que Oleg Chumakov (então ainda da Nival) era o programador de jogos mais famoso. Ele se apresentava constantemente, hospedava o Gamesjam e era um convidado frequente do podcast.Como os jogos são feitos .

Com o advento da VR no mercado, Oleg liderou a empresa em uma nova divisão - NivalVR. Mas todos vocês sabem, com realidade virtual, algo deu errado.

Por um longo tempo, fiquei distraído com o desenvolvedor do jogo e, olhando de novo, vi que o time de Oleg se tornou mais interessante. Agora ele se chama Luden.io e seu simulador especialista em aprendizado de máquina, enquanto True: learn () se tornou um sucesso em seu nicho, muitas histórias interessantes estão acontecendo ao seu redor.

Conversamos com Oleg, mas não pude escolher apenas um tópico - o caminho dele era muito rico e variado. E para que o programador falasse sobre programação sem medo de ser mal interpretado, a conversa foi apoiada por meu amigo, colega e experiente desenvolvedor de fillpackart .


Oleg Chumakov

Joguei enquanto True: learn (). Jogo legal, estou bem preso.

Longe?

Não. Comecei a tocar à noite e fiquei preso em uma missão paralela. Ele se sentou, não poderia ir para a cama até que ele decidisse. Como você está com ela?

As coisas estão muito boas, não esperávamos que ela fosse desse tamanho. Planejamos um pequeno projeto. Nós imaginamos assim: pegue todos os jogadores do mundo, corte aqueles que jogam apenas quebra-cabeças. A partir daí, interrompa aqueles que estão prontos para lidar com a programação. E depois outro aprendizado de máquina ... resultou em uma parte muito pequena da audiência. Mas, de fato, aqui.

A primeira vez que mais jogadores vieram correndo do que planejávamos em dois meses. No início - na primeira noite, mais do que queríamos por seis meses. Portanto, desde então, tivemos uma vida muito divertida. Nós localizamos, tentamos de alguma forma manter-se à tona e conversamos com milhares de pessoas em Discord ao mesmo tempo.


Seu bate-papo no Discord - como eu o entendo, todas as pessoas estão interessadas lá, tudo está relacionado ao aprendizado de máquinas. Conte uma história legal sobre um dos jogadores.

Há um jogador lá, o nome dele é Sr. Floppy (eu não sei qual é o nome dele na realidade). Ele veio até nós em alfa fechado. Permitimos que um certo número de pessoas jogasse, e recebemos um feedback aproximado, poderíamos nos ajustar.

Temos um gato no jogo - sentado no monitor, miados. E de acordo com a ideia original, o gato deveria interferir. Quando você programa, ele vem constantemente, "acaricia-me", sobe no monitor. Em geral, o Sr. Floppy, quando estava jogando, seu verdadeiro gato veio até ele, vivo, para impedi-lo de programar no jogo. Ele enviou esta foto, tudo começou.

Então ele se interessou, tornou-se um membro ativo da nossa comunidade. Ele começou a produzir esses gatos em várias roupas do jogo em uma impressora 3D em casa e enviá-los para os melhores jogadores. Relativamente falando, ele fez mercadorias de graça. Ele apenas gostou disso. E esta é uma lembrança muito calorosa de como nossa comunidade se organizou. Isso nunca aconteceu em nossos projetos. Havia cosplay, fanart, mas para as pessoas imprimirem brinquedos no jogo e compartilharem entre si - é a primeira vez.

Havia jogadores que queriam aprender diretamente sobre o aprendizado de máquina. O jogo removeu o medo de um limiar difícil para entrar no ML. Após o jogo, eles foram para o Coursera, procuraram competições que seriam difíceis para eles no nível de conhecimento. E agora estamos seguindo-os ativamente, estamos todos esperando o primeiro conseguir um emprego no campo de aprendizado de máquina. Neste dia, aparentemente estaremos comemorando

Ou seja, ainda não recebeu?

Eles ainda estão no meio do treinamento. O jogo foi lançado em março, ainda não havia tempo suficiente. E assim, em geral, muitas coisas aconteceram. As pessoas no YouTube também usaram o jogo para ensinar aprendizado de máquina. Nas escolas, é constantemente usado agora - na Rússia, na Grã-Bretanha, nos Estados Unidos, na Austrália. Portanto, não tenho mente suficiente para escolher a história mais bonita. Há dois deles toda semana.


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

Bem, vamos voltar ao aprendizado de máquina. Por enquanto, diga-me exatamente o que você está fazendo no projeto, suas responsabilidades, seu dia.

Minha responsabilidade agora é descobrir da equipe principal o plano deles - o que eles farão nos próximos dois a três meses - e com esse plano na minha cabeça trabalhar com todos que vierem até nós. Integre o jogo para frente e para trás, nesta escola, nessa escola. Ser uma ponte entre desenvolvedores e o mundo exterior.

Às vezes, trago algo do meu amado Customer Development. Por exemplo, eles descobriram um problema: as crianças frequentam cursos de programação - seus pais perguntam “o que havia na sala de aula?”, As crianças dizem “nada”. Os pais não entendem, a criança não quer contar os feltros de cobertura, os feltros de cobertura realmente não fizeram nada. Portanto, temos relatórios automatizados no jogo. Ou seja, os pais recebem mensagens - “seu filho aprendeu o perceptron hoje”, “seu filho ensinou rnn-ku” e assim por diante. Tais recursos aparecem devido à minha interação entre o mundo exterior e o jogo.

Bem, eu, como CEO, tenho uma tarefa para que todos sejam inspirados por um grande objetivo, todos se sintam à vontade para trabalhar, não haja dificuldades, tudo avance sem pensar em coisas básicas.

Eu vejo. Ou seja, você mesmo não programa agora?

Isso acontece, mas não com muita frequência. Eu tenho um grande recurso para refazer startups dentro do jogo. Eu vim com isso há muito tempo, embora como parte de nosso próximo projeto sobre marketing na Internet, mas minhas mãos se estendem lentamente. Em vez de fazê-lo nos bons velhos tempos da semana, já o faço há um mês.

Sobre a programação no Game Dev

Bem, vamos lembrar dos bons velhos tempos. Conte-me sobre você como programador?

Bem, o maior projeto em que eu tenho uma escola da vida é o jogo Prime World. Este foi um projeto muito grande da Nival. Multidão com uma parte social (foi chamada de Castelo). Nossa equipe, que estava apenas lidando com isso, tinha mais de 20 pessoas - e isso é apenas para uma pequena parte do jogo. O projeto era de tamanho monstruoso, bem, havia todos os problemas do multiplayer síncrono que existem neste mundo.

Phil: E em que estágio você se conectou ao projeto? Em que posição ele estava naquele momento?

O castelo, mas quando cheguei não havia nada lá.

Bem, para que os leitores entendam - o jogo consiste em duas partes: onde a batalha ocorre e o castelo - onde o desenvolvimento ocorre, o jogador constrói, contrata heróis, desenvolve-os e depois pega o herói e entra em batalha com ele. Essa parte da guerra já estava em certa medida pronta, e a parte social estava apenas começando.

F: E quem você veio até ele, como quem?

Cheguei à posição de programador regular. Lembro bem como criei um projeto vazio do Unity. Começamos desde o começo. Era necessário criar e integrar tudo à ogiva, que estava se desenvolvendo ativamente naquele momento.

F: Sim, isso é a Unity. Ou seja, o que é? Prós, c #?

A parte da sessão estava nos trunfos. Nossa parte foi na Unity. A lógica principal estava em c #. Mas, devido ao fato de este ser um projeto, por assim dizer, de uma complexa combinação de tecnologias, ele também foi gerado através do Thrift em Python, porque o servidor estava em Python.

F: Ah, e é claro que impôs sua sobrecarga no desenvolvimento em C #.

Bem, para dizer o mínimo. Mas nós saímos disso elegantemente. Os colegas de equipe seniores eram caras muito experientes, então tivemos a geração de código nos lugares certos e, em geral, tudo foi gerado de maneira bastante agradável. Não era necessário começar tudo diretamente com as mãos.

Pelo que entendi, era o auge de tecnologias como Thrift, Protobuf, como aqui. E então eles foram percebidos como uma invenção incrível da humanidade científica - uma vez e resolvem seu problema com o fato de que várias linguagens diferentes e os dados devem ser enviados, e tudo deve funcionar da mesma maneira em todos os lugares

F: Eu posso imaginar quantos problemas são esses. Quando você chegou ao projeto, você já conhecia o C # e o mundo .net?

Sim, eu estava familiarizado. Eu ainda estava familiarizado com o Unity 2.6 (se não confuso), era um produto muito estranho. Eu próprio escrevi no .net, mas havia o Mono em algum estágio inicial. Estes são os momentos em que Miguel de Icaza nem sequer lidou com Xamarin.

Lembro que o mono era um animal tão raro que poucas pessoas viam, mas foi incorporado ao Unity, e o Unity era quase o maior produto usado pelo mono. Consequentemente, havia tudo de monstruoso que acontece no mundo das máquinas virtuais nos estágios iniciais. Um enorme vazamento de memória obscura em todas as plataformas, diferenças imprevisíveis do .net nas coisas básicas. Qualquer alocação extra o tempo todo.

F: Ou seja, antes que você trabalhasse com o .net habitual, mas aqui eles forneceram outro tempo de execução, o que, em essência, ainda não está devidamente documentado.

Eu comecei a trabalhar com o Unity antes, mas esse período de transição sobre o qual você está falando - funcionou no .net e agora em mono - foi, mas um pouco antes. Não posso dizer que eu era muito experiente em .net. Eu tinha uma idéia e vários projetos concluídos, mas em nenhum lugar surgiu a questão do desempenho, mesmo se eu tivesse feito tudo errado nesses projetos. Todas as peças carregadas nesses projetos estavam em vantagens, e o .net não tinha nada a ver com isso.

F: Você pode falar sobre sua primeira semana no projeto. Então você passou por uma entrevista, você é um desenvolvedor. O que vem a seguir?

Bem, pela pureza da história, vale a pena dizer que não fizemos o Primeiro Mundo no início. Antes dele ainda havia um projeto. Infelizmente, ele não chegou ao lançamento e um dia nos transferimos para a PW para criar o castelo. Tudo foi tão rápido lá - aproximadamente os designers nos descreveram a idéia do que deveria acontecer: "Deve haver algum tipo de castelo, um jogador no castelo, ele o desenvolve, constrói, bombeia".

Na primeira semana, lembro-me, montamos uma câmera, construção com unidades básicas, construímos como tudo deveria ficar, tudo era único. E após a primeira semana, quando a imagem básica e a interativa básica foram montadas, tivemos que começar a descobrir como funcionaria arquitetonicamente usando servidores, como ir ao castelo de um amigo, ver que tipo de castelo ele tinha, como transferir esse contexto para a ogiva. Ou seja, os heróis foram contratados, montados, compraram os talentos certos, agora você precisa lutar contra esse herói em batalha. E para entrar em batalha, você deve, de alguma forma, transferir do nosso castelo para a parte da sessão. Existem outras línguas, outras tecnologias - essa ponte não foi construída rapidamente. Aqui estão algumas dessas memórias. Mas isso foi há muito tempo.

Timeline Development Luden.io

• Em 2014, a Nival formou uma equipe separada para desenvolver jogos educacionais em realidade virtual - NivalVR.
• Em janeiro de 2015, seu primeiro projeto, o InMind, foi lançado - um jogo sobre viajar para o cérebro humano em nível microscópico para procurar neurônios que causam doenças mentais.

• No mesmo ano, o InCell foi lançado. Ela desenvolveu a ideia, mas soou como o texto de um chatbot que disparou - um jogo educacional com elementos de corrida e estratégia, com geração de procedimentos, para dispositivos de realidade virtual, sobre viajar para o mundo celular humano.
• Na Epic Games Mega Jam 2016, Luden.io criou o VRobot - um "jogo inútil, mas divertido", no qual você tem que destruir uma cidade com um robô gigante. Em 2017, ela lançou no Steam VR, em 2018 - no Playstation VR.

• Em 2016, o NivalVR foi renomeado Luden.io.
• Em 2017, o ARrived foi lançado - um simulador de Deus em realidade aumentada nas tecnologias Google ARCore, Apple ARkit e CoreML.

• Em março de 2018, ela entrou no acesso antecipado enquanto True: learn () - um especialista em Sim para ML, mas sem VR e AR.

Sobre o gerenciamento de uma empresa de tecnologia

Bem, agora você é o chefe da Luden.io. E como você - o que é mais difícil? É puro desenvolver ou gerenciar tudo isso, ser uma ponte entre o mundo e os desenvolvedores?

Eu acho que depende de que tipo de pessoas você faz isso. Eu tive muita sorte, com pessoas como eu lá e há super interessantes e super legais.

E se você comparar teoricamente duas profissões - CEO e apenas um programador? Eu acho que o programador é mais atencioso e mais lento. Inventado, planejado, feito. Fatores externos aparecem com menos frequência e não estão nesse volume. Lá, relativamente falando, sempre existem as decisões corretas, há indicadores concretos, claros e mensuráveis ​​de que as decisões corretas são quando seu cálculo não leva mais de dois milissegundos e é executado em N threads. Você definitivamente conhece esses parâmetros, se você se encaixa neles, está tudo bem.

Obviamente, não existe tal coisa no trabalho do CEO. Normalmente, não existem coisas formalizadas claras neste mundo, embora você rodeie seus negócios com indicadores mensuráveis ​​direcionados. O tempo todo você precisa pensar em como fazê-lo melhor ou pode ser completamente diferente. Também não há regras claras. Mas esse é o seu próprio charme



F: Você acha que a experiência do desenvolvedor ajuda a gerenciar?

Eu tenho certeza que sim. Eu não acho que no futuro haverá muitas empresas de tecnologia criadas sem entender o contexto de desenvolvimento na cabeça do gerente-chefe. É difícil para mim imaginar como isso pode ser. Estou certo de que pelo menos uma pessoa deve ter uma formação técnica para que a empresa de tecnologia avance com a velocidade do trem, que agora é minimamente necessária para sobreviver. Eu não diria que esse é o único caminho, mas provavelmente um dos mais evolutivamente corretos.

Você mesmo faz uma revisão?

Bem, não é isso. Em um grande projeto de PW, sim - havia outros processos lá, não como o nosso. Lá, é claro, todo o código parecia ter tudo em um único padrão. O PW era de tal escala que se podia esquecer que uma parte é usada em outro lugar. Até mesmo testar localmente era difícil, quão grande era o projeto. Portanto, a revisão do código tinha bons padrões.

E aqui os caras olham para o código um do outro, mas principalmente durante a integração, quando coletamos todos os recursos em um único brunch. Não vi no gamedev que quando você tem de 5 a 6 programadores, existem grandes processos de revisão de código. Na maioria das vezes isso não é particularmente necessário, o produto é primário e o período de suporte não é de dezenas de anos.

F: Existe alguma abordagem consolidada para o desenvolvimento? Ele é imposto?

Há um estilo de código padrão e conceitos básicos do que combinar, regras de arquitetura. Existe uma estrutura de projeto em que sempre trabalhamos. Foi testado pelo tempo e sabemos com certeza que não nos permitirá dar um tiro no pé (pelo menos com uma espingarda). Existe um conjunto básico de módulos que se deslocam de um projeto para outro. Alguns foram escritos há muito tempo, outros recentemente. Devido à grande reutilização de padrões arquitetônicos, devido à observância do estilo de código, não estamos entrando completamente no abismo.

F: Você participa da contratação de novos funcionários?
Sim claro.

F: Todo mundo?
Tudo.

Você provavelmente não é uma empresa muito grande, certo?

Bem, sim, não muito grande, nem milhares de pessoas. Portanto, graças a Deus, pelo menos uma vez, mas com cada novo funcionário na fase de entrevista de 10 minutos, falarei sobre como uma pessoa se relaciona com a indústria de jogos e o que ela representa. Apenas para entender.

F: Mas você mesmo não entrevistará desenvolvedores como desenvolvedores?

Você sabe, de alguma forma tenho muita sorte. Então, acho que os envolvidos em software bancário não têm uma prerrogativa e sorte como a nossa. Toda a nossa indústria de língua russa é pequena. E quando você trabalha há vários anos, você faz amigos e conhece pessoas. Para quase qualquer funcionário, se este não é um aluno, sempre há algum tipo de recomendação, uma compreensão aproximada do que ele está fazendo na produção.

Mas se eu precisasse contratar cem pessoas em uma semana, é claro que não poderia fazer isso. Não preciso contratar nesse ritmo e, provavelmente, quando contratar pessoas, já as conheço.

Gamedev vs desenvolvimento de negócios

F: E há casos em que pessoas de outras indústrias seguem em frente?

Isso acontece, mas não com muita frequência. No gamedev, o histórico geralmente é assim - as pessoas gostam de fazer jogos na infância e só então continuam.

Houve várias entrevistas marcantes quando as pessoas foram retiradas dos bancos. Na fase da entrevista, nós meio que concordamos, eles pareciam gostar, tipo "aqui, eu trabalho no banco, pago muito, mas eu realmente não gosto. Eu gostaria de fazer o que a alma mente. E a alma está nos jogos.

Você gosta dele, ele gosta de você, negocia, faz uma oferta e a pessoa desaparece. Às vezes você pergunta “como vai” e eles lhe dizem: “aqui vou parar, o chefe pergunta para onde estou indo. Eu digo aqui. E ele - bem, vamos aumentar seu salário e você não vai a lugar algum. " Muitas vezes, as pessoas sucumbiam a motivação monetária adicional e permaneciam em seus setores.

Mas havia outros casos, é claro. Pessoas muito boas vieram de várias indústrias, incluindo software bancário.

Sim, eu lembro que você contou essa história em um podcast - um programador de um banco diz "Quero ser criativo", um número está escrito em um pedaço de papel e ele permanece. Você já teve esses pedaços de papel em sua vida?

Sim, como todo mundo, as ofertas vêm constantemente de diferentes ângulos. Você sabe, eu nunca realmente olho para eles. É ótimo, é claro, que em outro lugar eles estejam ligando. Mas não é isso que eu gostaria de construir na vida.

F: Eles dizem que no setor bancário, nos negócios, a qualidade do código é maior do que no desenvolvimento de jogos.

Eu acho que seria legal colocar um oponente que trabalhou tanto em software bancário quanto em desenvolvimento de jogos. Mas, do ponto de vista da parte teórica, acho, em situações de desenvolvimento de jogos, muitas vezes acontecem quando um projeto voa de repente.

Por exemplo, a empresa Kefir wonderful tem o jogo The Last Day on Earth. Feito certamente de alta qualidade e ótimo. E ela voou muito rapidamente, tornou-se muito popular. Acho que a última coisa para a qual você tem mãos suficientes quando começa a decolar dessa maneira é vasculhar a qualidade do código.

Todo o processo de manutenção da limpeza em um projeto depende principalmente da conscientização dos desenvolvedores, desenvolvedores seniores, que em qualquer estágio do projeto observam boas maneiras e mantêm tudo sob controle. Porque o estágio "vamos terminar, depois pentear tudo" nunca chega.

F: Eu próprio trabalhei muito no desenvolvimento de negócios - construímos a qualidade do código em um culto. , — . , (, ). , , . — .

Aqui, é claro, o produto e seus indicadores são primários. Às vezes, existem situações semelhantes às que você descreve. Suponha que estejamos realizando um projeto com IP conhecido, sabemos qual é o seu futuro. Com alguma precisão, podemos prever que ele será suportado por 15 anos. Obviamente, temos imediatamente um valor comercial, pois seu suporte não aumenta a cada ano. Para fazer isso, ele deve ser bem documentado e escrito claramente para o novo programador. Mas existem poucos projetos desse tipo que são suportados por 15 anos - específicos do setor. World of Warcraft quanto? Em tempo há 15 anos, será em breve. Não, teoricamente, sim. Mas acho que 15 anos atrás, os desenvolvedores da Blizzard estavam com pressa de finalizar o produto e nem tudo foi feito perfeitamente.

F: Parece mais aqui que, nos projetos de jogos, inicialmente você pode menos imaginar quanto tempo dura, ao contrário dos projetos de negócios.

Claro.

F: Nos negócios, por padrão, eles criam códigos que devem ser suportados por 15 anos, e você não faz isso, certo?

Nem sempre a principal tarefa do programador é criar código que seja facilmente suportado por 15 anos. Mas conheci projetos muito limpos, onde as pessoas e o desenvolvedor central são muito responsáveis, eles gostam de tudo.

Se você gosta de monitorar a limpeza, o projeto geralmente é bonito e bom. Mas, obviamente, os negócios nem sempre exigem essa pureza; nem sempre têm uma correlação com o sucesso do produto.

Ao mesmo tempo, é bastante difícil para mim imaginar uma situação em que fabricamos software bancário e não sabemos se ele vai voar ou não. Indústrias muito diferentes.

Como criar jogos para você e o público

Olhando para os jogos luden.io, parece-me que eles são feitos como se fosse para mim. Geralmente não confia no que as pessoas de negócios costumam dizer, sem contar com um público específico.

Essa é sempre uma pergunta dupla. Imagine que fabricamos software que resolve um problema específico do usuário. Vamos a esse usuário, perguntamos a ele "qual é o problema?" Entendemos, descobrimos, consideramos a economia - é uma pessoa pronta para pagar por resolver esse problema. Criamos um produto que resolve esse problema.

O jogo também pode ser considerado como um software que resolve o problema do jogador. Ele quer se divertir ou - como no nosso caso - aprender alguma coisa. Mas aqui não é que dói, eu peguei o software - ele parou de doer. O usuário quer tocar algo com alma e agradável. É necessário que uma pessoa tenha química com o jogo. Ele deve fazer amizade com ela. Se houvesse uma maneira de estudar a mecânica da formação dessa química com um jogador, bem como estudar um problema na esfera dos negócios, provavelmente não seria importante criar jogos para si mesmo.

Se dissermos que não podemos realizar essa pesquisa com detalhes suficientes, a única maneira de descobrir que o jogo realmente faz amizade com o usuário é ser esse usuário. Se o jogo nos parece excelente, bonito, interessante, podemos supor que existem mais de um como nós, que essas pessoas ainda existem e que também gostarão.

Mas aqui está uma linha tênue. Você precisa poder olhar o produto como a si mesmo, mas com olhos ligeiramente diferentes. Como é que uma pessoa que não joga há 5 anos percebe? E a pessoa que agora toca apenas em Destiny? Como o homem que passou mil horas no bunker verá. É isso - mas com a centelha de que você deve se divertir - essa é a motivação dos negócios.

E a motivação lírica é simples - leva muito tempo para criar um jogo e, até o final do desenvolvimento, qualquer jogo terá um sentimento próximo ao ódio. Você já a viu tanto, ela está tão cansada de você. E se você ainda não gosta, como beber, no final, soltará as mãos. Não há outra maneira senão fazer um jogo que você gosta. Caso contrário, você não chegará ao fim com boa motivação, ficará cansado demais.

Bem, você concorda que seus jogos ainda são de nicho?

Claro!Esta é a principal vantagem do que fazemos. Nós realmente queremos ser um nicho. Não tente entreter homens de 20 a 40 anos - o mundo inteiro é divertido.

Queremos que os jogos transmitam um novo assunto a uma pessoa, digam algo a ele, sejam um companheiro útil em sua vida. Esse nicho definitivamente não é tão amplo quanto os jogos de futebol, onde há um público muito maior. Mas não apontamos nessa direção.

Trabalhar nesse princípio é lucrativo?

Eu acho que isso é rentável (bem, no nosso exemplo), mas requer uma expansão do mercado. Por quatro anos, chegamos a um ponto em que percebemos que gêneros, em que formato e como enviar, para que fosse rentável. Fazemos isso, mas não diz que esse é o ponto de maior lucro que pode ser extraído desse nicho.

Somente agora adquirimos uma compreensão de como trabalhar com esse mercado, como criá-lo. É pouco desenvolvido. Agora, dentro de 10 a 15 anos, temos que transformá-lo em algo mais aberto a outros desenvolvedores que também compartilham nossos objetivos - que os jogos sejam úteis.

Nossa tarefa é garantir que, depois de 20 anos, com a ajuda de jogos, as pessoas aprendam e façam coisas que lhes tragam prazer, sejam relevantes nesse mundo do futuro e nas quais elas sejam tão eficazes quanto possível. Em seguida, universidades e escolas podem se envolver exclusivamente em atividades de pesquisa.

Em geral, uma linha comum é visível entre os jogos, suas aulas - jogos, palestras, você parece ainda ensinar ...

Muito raramente. 10 horas por ano, na melhor das hipóteses.

Por que existe tanto interesse em educação, ensino?

Existe alguma beleza em ajudar os especialistas mais jovens a serem muito mais legais e felizes do que nós; a experiência deve funcionar. Mas há menos motivação visionária. Qual é o seu jogo favorito? Agora, identificaremos alguém diretamente por gênero.

De todos eles?

De tudo. Qualquer ano. Bem de imediato, você ainda se lembra de algo.

Vamos Mass Effect.

Ok, Mass Effect é bom, eu também gosto. E o segundo nosso ...

F: Gótico, provavelmente.

Porra, bem, gótico também é bonito. Agora eu me perguntava se deveria chamá-los. Eu também amo muito o gótico e gosto do Mass Effect, mas sou apenas um fã louco do gênero de simuladores e taikuns. Mini Metro, em geral, considero uma conquista brilhante da arte dos jogos modernos. Não jogou?


Sim, sim, eu a vi.

Se traçarmos um paralelo com a arte, essa é uma "forma zero" como a de Malevich - quando uma enorme camada de um sistema profundo é alimentada com o mínimo esforço.

Taikuns e simuladores são um modelo de domínio no qual interativamente fazemos algo e vemos as consequências. Jogos, se você olhar mais fundo, é exatamente o caminho para obter experiência sem riscos. Ou seja, o jogo é a forma mais natural de treinamento. Aqui nós temos uma empresa chamada Luden.io. Se decomposto, Ludus do latim é traduzido de duas maneiras - um jogo e uma escola. Perto do coliseu, existem essas ruínas, chamadas Ludus Magnus. Este é o lugar onde os gladiadores estudaram, eles jogaram lá, lutaram e estão preparados para batalhas na arena.

E aqui estão simuladores, taikuns - projetados apenas para oferecer experiência em áreas onde é muito difícil ou muito caro obtê-lo, ou não é possível chegar ao planeta Terra. Preparar uma pessoa para uma situação que ela enfrentará no futuro, ensaiá-la.

A educação, que estava no formato de 20 a 30 anos atrás, tornou-se pouco praticada. A criança tem um telefone nas mãos, tem Youtube, Twitch, algum tipo de jogo, e tudo isso é muito mais interessante do que ler um livro obscuro e não empolgante.
Se combinarmos essas formas - jogar e aprender, venceremos de todos os lados.

O que aconteceu com a VR

No mesmo princípio, os primeiros projetos tiveram uma ideia para focar na realidade virtual?

Com a VR, um tópico interessante ... quando começamos, ele apenas começou. A RV, é claro, dimensiona os pontos fortes dos jogos - experiência sem riscos, adiciona o efeito da presença. O cérebro acredita ainda mais que isso está realmente acontecendo, embora este seja apenas um ensaio extra. Mas o mercado está enfrentando algumas dificuldades com a taxa de crescimento agora. Não foi possível encontrar o formato VR que todos gostariam de ter em casa.

Portanto, decidimos que continuaremos avançando em direção ao nosso objetivo, mas a VR ... Lançamos projetos em todas as plataformas. Além disso, temos em produção projetos de RV integrados às escolas. Se algo se mover em uma das plataformas, e será uma realidade virtual que ajudará a produzir jogos úteis, certamente fortaleceremos nossa presença lá. Enquanto isso, temos muitos jogadores lá, todos estão felizes e felizes, mas enquanto Verdadeiro: aprende () - sem realidade virtual.

Após a E3, essa imagem acabou de aparecer na Internet, que há catastroficamente menos referências à RV na imprensa do que antes.

Bem, infelizmente sim.

O que você acha que aconteceu?

Deseja comprar um capacete de realidade virtual para você?

Não.

Bem aqui. Foi o que aconteceu. As pessoas não querem. Assim que você acorda e percebe que deseja VR por si mesmo, o ponto de inflexão está próximo.

Por que eles não querem? Afinal, tudo foi tão legal. Quando apareceu, todo mundo ficou encantado, todo mundo disse que daqui a 5 a 10 anos estará em todo lugar, geralmente nos mudaremos para lá para viver.

Você não pode ouvir respostas analíticas complexas de empresários, apenas respostas personalizadas. O Cliente responderá a essa pergunta em um idioma simples muito melhor. Portanto, pessoal, se você não quiser um capacete para sua casa, sua motivação descreverá a situação muito melhor do que todas as minhas conclusões obscuras de negócios.

Isso sempre acontece - se o jogo não estiver à venda, vá para o jogo e pergunte à pessoa que não o comprou. Ele explicará muito melhor do que todos os profissionais de marketing juntos.

Eu acho que há um problema de frango e ovos. Um capacete pode ser comprado em casa, mas surge a questão do que fazer com ele. E quem produz o conteúdo deste capacete pensa no que vou produzir para ele; se não houver pessoas lá, pararei o desenvolvimento por dinheiro. Esse problema ainda não encontrou equilíbrio no mercado de RV.

Mas segmentos apareceram e acho que serão fortalecidos. Primeiro, mercados estreitos, depois um mercado cada vez maior será retirado. Como foi a formação de consoles nos anos 80, 90, a formação de VR pode acontecer. Mas em três anos fracassou - não caiu na escala dos telefones celulares.

Ou seja, você acredita que ele decolará logo depois?

A questão está em que formato. Será difícil prever se será um dispositivo universal que permita a criação de RA e VR ou de dispositivos separados.

Minha opinião pessoal é que ele ocupará um nicho especializado, como, por exemplo, tablets hoje. Muitas pessoas têm casas em casa, mas poucas compram novas. E ainda estão resolvendo algum problema. Com VR, pode ser o mesmo. Ele definitivamente ocupará algum segmento do mercado. A única questão é o tamanho desse segmento.

Parece que há um uso excelente, Sergei Galenkin. Uma pessoa comprou um capacete para assistir a um filme porque ele tem quatro filhos. O caso de uso é imediatamente limpo.

Foi difícil trabalhar com realidade virtual? Tecnicamente.

Com a VR, existem enormes problemas com o desempenho, e os requisitos da plataforma costumam dar suporte a ela. Agora estamos com o nosso jogo antigo - VRobot - no Playstation VR. Lá, por exemplo, é necessário manter 60 fps estáveis. No Oculus (incluindo dispositivos móveis), você precisa suportar 75 fps. Mesmo que em certos momentos caia de 20 a 30 quadros - é isso. Você precisa otimizar o jogo para que ele não caia.

Mas temos uma equipe muito forte em termos de otimização gráfica de baixo nível. Temos Nikita, que é super profissional nisso.

F: Então você tem um cara separado para otimizações?

Bem, ele não apenas faz isso, mas é sua principal habilidade. Eles ainda estão trabalhando juntos com o Dima, que pode montar qualquer cena 3D nos indicadores de desempenho desejados. Portanto, com eles tudo estava bem e maravilhoso.

Sobre o aprendizado de máquina no desenvolvimento de jogos

Para aqueles que estão interessados ​​em desenvolvimento de jogos e aprendizado de máquina, Oleg mostra uma foto de Demis Hassabis em busca de inspiração. O prodígio do xadrez, neurocientista e fundador da DeepMind, também começou sua carreira como desenvolvedor de jogos.

Ele programou inteligência artificial para Black & White de Peter Moulinje. E então, em sua própria empresa, a Elixir Studios lançou, por exemplo, o simulador do super-vilão bond Genius.

E só então se tornou um dos mais famosos pesquisadores de IA do mundo.

Enquanto True: learn () mostra sua experiência real?

Sim, sim, tudo é construído sobre ele. Na indústria de jogos, como - se você começar a fazer algo, definitivamente deverá ter uma referência, um ponto de referência no qual olhará para trás. Estamos fazendo a simulação, na simulação existem muitas pequenas coisas, essas pequenas coisas precisam de um ponto de referência para não voar para algum tipo de abstração.

E enquanto True: learn (), tomamos como referência nenhum outro projeto - tínhamos uma realidade. Se você está fazendo algo e não sabe como fazê-lo, é como na vida real. A economia do jogo é o aluguel de servidores de computação. Se você resolver o problema de processar uma enorme quantidade de dados, aluga um servidor, considera, aluga e interrompe o aluguel.

Queríamos mostrar no jogo uma cronologia do desenvolvimento de aprendizado de máquina dos anos 50, desde o primeiro perceptron e terminando com carros autônomos modernos, todos os tipos de redes de cápsulas e assim por diante.

Estabelecemos todos esses pontos de referência, Vanya coletou especialmente uma tabela do Google - os principais blocos de transição do aprendizado de máquina, como a indústria mudou, o que foi trazido de novo. E com a ajuda de missões, isso é servido nessa ordem.

Em algumas versões do jogo, tivemos um ano especificado. Por várias razões, nós o removemos, talvez voltemos. Mas a pessoa segue o caminho - lança o jogo, passa por várias missões com o perceptron, ganha algum dinheiro com isso.

A cada ano, algo era interessante. Foi refutado pelo desenvolvimento futuro da tecnologia ou, pelo contrário, confirmado.



Você pode clicar em cada bloco, ver como funciona no jogo, como funciona na vida real.

Sempre existem dois links, um para um vídeo do YouTube sobre esse bloco, em que alguém fala sobre isso de forma fascinante. E algum artigo para entender ainda mais, se você quiser entender até os detalhes de como isso funciona.

Em uma equipe, as pessoas fizeram aprendizado de máquina antes?

Sim enquanto True: learn () fizemos paralelamente ao lançamento do VRobot, então nossa equipe de VR estava focada em migrar para o Playstation. E a nova equipe pequena consistia em especialistas em aprendizado de máquina.

E conte a eles sobre eles, que tipo de equipe, em que trabalharam antes?

Sim, eles de alguma forma coletaram. Quando a idéia surgiu, eu escolhi uma equipe de amigos, amigos e estudantes.

F: Você contratou especialistas em ML?

Sim, mas lá temos todos os jovens, eles certamente não têm 20 anos de experiência em aprendizado de máquina. Todos jogaram no Kaggle pelo menos várias vezes, eles resolveram alguns problemas. Muitos já passaram por isso no instituto.

F: E eles fizeram um jogo. Mas o desenvolvimento de jogos não é aprendizado de máquina, certo? Ou seja, eles são fullstacks - cientistas e desenvolvedores de produtos reunidos em um.

Bem, como você responde. São pessoas que entendem o aprendizado de máquina e entendem como ele funciona. E eles desenvolvem um jogo no Unity, escrevem código de jogo, interfaces de tipos e assim por diante.

Para criar algum tipo de missão e colocar tudo em cronologia, você precisa entender o contexto. Mas obviamente eles não iniciaram o ipython notebook para cada missão.

Temos uma biblioteca especial que considera redes convolucionais e algumas coisas muito básicas no sharpe que funcionam no Unity. Também lançou nosso jogo de desenho AIDraw. Lá, o jogador desenha e a rede neural adivinha o que ele desenha. Esta biblioteca calcula a coisa toda, e em torno dela um jogo inteiro está empatado.

F: ML e game dev recentemente começaram a se sobrepor. Por exemplo, eu tenho um jogo com aprendizado de máquina. Qual pilha é adequada?

Não vi muitos projetos que cruzam o aprendizado de máquina e o desenvolvimento de jogos - especificamente o uso de produtos, para que algo aconteça no cliente do jogo.
A unidade possui seu próprio sistema de aprendizado por reforço. Ele permite que você faça um pequeno número de coisas, mas é construído diretamente no Unity, portanto, o limite de entrada é baixo.

Existem várias bibliotecas, as mesmas de outras áreas, além de estruturas para redes neurais.

Nas tecnologias móveis, eles costumam usar o CoreML da Apple, que permite calcular o dispositivo diretamente na GPU. Nós pegamos o modelo, treinamos no mesmo TensorFlow ou no Yandex CatBoost, empacotamos em um arquivo especial - e agora ele já pode ser iniciado diretamente na GPU em um iPhone e receberemos a previsão resultante de volta para nós.

Nós o usamos, por exemplo, no jogo ARrived com realidade aumentada, onde era necessário reconhecer a imagem das câmeras e dizer o que havia nelas.

Se não estamos falando sobre o uso do produto, não no cliente do jogo - tudo é clássico por lá. Nos servidores, as pessoas dirigem as tecnologias mais comuns, que estão em todo o ML. Mas lá é usado para análise ou personalização da oferta.
O famoso caso - eles tentaram prever quando um jogador sairia do World of Tanks e o que fazer com essa informação.

Ou prever o momento em que oferecer ao jogador algum tipo de oferta - compre dois cavalos pelo preço de um. Ele comprará com uma alta probabilidade e ficará feliz mais tarde. Essas são coisas do servidor, e a pilha não é de forma alguma limitada.

E a coleção de dados pode estar no centro do design do jogo?

Bem, esse é um conceito do westworld. Talvez ela tenha direito à vida, mas não vejo imediatamente que tipo de conjunto de dados das ações dos jogadores pode ser útil.

Bem, por exemplo, estamos fazendo um jogo com você sobre dirigir em um ambiente urbano, estamos criando um modelo real de estradas de Moscou. Aqui vemos - muitos jogadores aqui constantemente travam, aqui eles violam o modo de velocidade. Nesse conjunto de dados, você pode entender onde estão os problemas.

E se é um jogo abstrato, não um simulador de domínio? Talvez o conjunto de dados ajude a resolver os problemas da empresa. Se ela faz jogos do mesmo tipo, o conjunto de dados do comportamento dos jogadores nesses jogos pode ser útil para eles. Mas, para isso, foram criados projetos separados, que ainda não encontrei.

Isso foi um problema no AIDraw?

Ah, bem, aqui está. Poderíamos sair disso, se tivéssemos uma escala de 300 mil vezes maior. O Google, por exemplo, coletou um conjunto de dados em um jogo semelhante, ele faz algo com ele. Eu acho que para fins de pesquisa. Aqui eles podem ser uma tarefa.

F: Digamos que você tenha concebido um jogo que usará ML de alguma forma, e no processo de desenvolvimento você entende que como você o concebeu não funcionará, mas acontece algo completamente diferente. Você já teve esses casos?

Por exemplo, sabíamos que, enquanto True: learn () seria uma grande atualização sobre carros autônomos. O jogador vai ensinar a máquina a andar, andar em outros carros, trocar de marcha, dar gasolina, acionar o freio.



Normalmente, em um desenvolvedor de jogos, o designer do jogo escreve um dzdock; o conteúdo é produzido no dzdok (bem, em termos de requisitos técnicos em outras áreas). Mas com a máquina de escrever que entendemos imediatamente - teremos várias etapas, várias tecnologias. A genética aprenderá. O jogador entenderá que a genética está estudando, mas não é muito boa. Então haverá reforço de diferentes tipos. O jogador entenderá que certo reforço para esta tarefa é mais eficaz.

Essas são coisas mal gerenciadas. Sabendo que tudo pode dar errado, primeiro escrevemos uma demo tecno - crua, feia, incompreensível. Deu para designers de jogos. Os designers de jogos brincaram com ela, escreveram um dzdok, que terminaremos e poliremos.

Mais precisamente, não apenas os gamedisaners, temos uma comunidade fechada de amigos mais próximos no Discord, podemos oferecer a eles um recurso em qualquer estado, eles jogam e dizem o que pensam. Agora eles estão jogando esses carros há mais de duas semanas e dizendo.

Com carros chegamos a quê? Inicialmente, indicamos qual entrada de dados usar para ensinar o carro a dirigir, quais parâmetros podemos alterar (todo tipo de limiar, perda. Na genética, por exemplo, tamanho da geração, mutações). E acabou algo não muito interativo. Um homem entra, muda alguns parâmetros e depois fica estúpido, observa como o carro dirige. Para desenvolvedores que estão no contexto, isso é divertido. E para uma pessoa de fora, de alguma forma, não é interativo.

F: Não sente a contribuição dele?

Sim, sem feedback instantâneo. Portanto, alteramos um pouco o design. O jogador irá dirigir. Como ensinar um carro, dirija você mesmo. E ela repete depois de você, como você a ensinou.

Se um jogador está sendo reconstruído constantemente apenas para a direita, a máquina não pode ser reconstruída para a esquerda, porque ele não a ensinou dessa maneira. Tornou-se imediatamente interativo. Então, mais algumas iterações e algo pode dar certo,

Ou seja, estamos afirmando que algo sempre pode dar errado com o ML. É quase impossível pensar com antecedência na fase de design.

F: Ou seja, você está impondo o fato de que precisa criar um protótipo, ver como ele se comporta e essencialmente refazê-lo novamente?

Claro que sim.

F: Mas isso não é padrão para o desenvolvimento. Esse recurso é ML, certo?

Você pode dizer que sim. Porque em outras áreas e jogos, podemos prever aproximadamente. Este não é o primeiro ano em que fazemos isso, então entendemos que o que o jogador fará, que tipo de emoção ele experimentará.

Nossa base preditiva, que temos em mente, lida com essa tarefa.
Mas ML ainda não está lidando.