Creador de while True: aprender () sobre programación en desarrollo de juegos, problemas de realidad virtual y simulación de aprendizaje automático

Hace unos años tuve la sensación de que Oleg Chumakov (que trabajaba en el estudio de juegos Nival) era el programador más famoso en la industria del desarrollo de juegos. Estaba dando discursos, organizó Gamesjams y apareció con frecuencia en el podcast Cómo se hacen los juegos .

Cuando la realidad virtual llegó al mercado, Oleg fue elegido para dirigir el nuevo departamento de la compañía: NivalVR. Pero, como probablemente sepa, la realidad virtual no despegó tanto como la gente esperaba.

Me mudé a otras cosas en la vida y dejé de seguir con el desarrollo del juego por un tiempo, pero después de volver a hacerlo, noté que las cosas estaban mejorando para el equipo de Oleg. Ahora se llama Luden.io, y su simulador experto de aprendizaje automático, mientras que True: learn () se convirtió en un gran éxito en su nicho ciertamente pequeño. Muchas historias interesantes están sucediendo alrededor del juego y el equipo.

Decidimos hacer una entrevista con Oleg, pero no pude apegarme a un tema: su vida hasta este momento ha sido, por falta de una palabra mejor, "interesante". Lo ha visto todo. Y, para garantizar que un programador pueda hablar sobre programación sin temor a parecer demasiado "nerd", la entrevista fue realizada por mi amigo, colega y un desarrollador experimentado de su propio fillpackart .


El propio Oleg Chumakov

He comprobado mientras True: learn (). Un gran juego, por cierto, simplemente no podía dejar de jugarlo.

¿Cuán lejos has ido?

No muy lejos en absoluto. Empecé a jugar por la noche e inmediatamente me quedé atrapado en una misión secundaria. No pude dormir hasta que lo resolví. ¿Cómo van las cosas con el juego, por cierto?

Bastante bien Ni siquiera podíamos imaginar que crecería así de grande. Solo planeamos un proyecto pequeño. Míralo de esta manera: toma a todos los jugadores, luego toma a aquellos que solo juegan juegos de rompecabezas y nada más. Luego, a partir de ahí, tome a aquellos que estén listos para incursionar en la programación. Y luego de ellos, tome a las personas que están específicamente en el aprendizaje automático. Ese era nuestro público objetivo. Pero, por supuesto, no resultó así.

Solo durante la primera noche, obtuvimos más jugadores de los que esperábamos atraer en medio año. Entonces, obviamente, las siguientes semanas han sido bastante divertidas. Intentamos agregar soporte para diferentes idiomas y, en general, mantener el juego a flote mientras hablamos con miles de personas a la vez en Discord.


Tengo la sensación de que su chat de Discord es muy interesante, ya que todos los que están allí están realmente interesados ​​en el aprendizaje automático. ¿Tienes algunas historias interesantes sobre tus jugadores?

Tenemos un jugador, llamado Mr. Floppy (no tengo idea de cómo se llama en la vida real). Se unió al proyecto durante el alfa cerrado, cuando distribuimos el juego a un número limitado de personas para recopilar comentarios.
En el juego, usted (el programador) tiene un gato, se sienta en el monitor y maúlla todo el tiempo. Pero inicialmente, se suponía que lo distraería activamente del proceso. Llegaría un momento muy inoportuno y exigiría que jugaras con él, te sientes frente al monitor, ese tipo de cosas. Fue idea del Sr. Floppy: cuando jugaba, su gato real siempre lo distraía, por lo que tomó una foto, la publicó en Discord, y todos supieron de inmediato qué siguiente característica íbamos a agregar.

Él realmente se involucró en la comunidad. Comenzó a imprimir en 3D estos gatos en el juego con ropa diferente y los envió a los mejores jugadores. Esencialmente, manejó nuestra mercancía gratis. Él estaba recibiendo una patada de eso. Es un recuerdo muy cálido acerca de cómo nuestra comunidad esencialmente surgió por sí sola: hasta ahora no hemos tenido eso en nuestros proyectos. Tuvimos gente haciendo cosplays, fan arts, pero imprimiendo objetos en 3D desde el juego para obsequiarnos, eso fue lo primero.

Hubo algunos jugadores que esperaban sumergirse en el aprendizaje automático y el juego suavizó la barrera de entrada notoriamente alta para ellos. Después de jugarlo, fueron a Coursera, buscaron competiciones de varios niveles ... Y los vigilamos de cerca, apostando sobre quién sería el primero en conseguir un trabajo real en el aprendizaje automático. Cuando llegue ese día, probablemente celebraremos.

Entonces, ¿eso significa que nadie lo ha hecho todavía?

Están a la mitad de sus cursos en este momento. El juego salió en marzo, aún no ha habido suficiente tiempo. Pero en general, pasaron muchas cosas geniales con el juego. YouTubers lo usó para enseñar aprendizaje automático, por ejemplo. El juego se usa realmente en las escuelas ahora: en Rusia, Reino Unido, Estados Unidos, Australia, en todo el lugar. Así que no puedo nombrar exactamente la mejor historia que nos sucedió: tenemos un par de contendientes cada semana.


Stanislav Semenov, un científico de datos y uno de los principales usuarios de Kaggle, juega WTL

Bien, volveremos al aprendizaje automático más tarde. Dime qué haces exactamente dentro del proyecto, describe tu día típico en el trabajo.

Mi responsabilidad en este momento es hablar con el equipo central, hablar sobre sus planes (lo que van a hacer durante los próximos 2-3 meses) y tener ese plan en mente para todas las personas con las que trabajamos. Integrando el juego en varias actividades, ayuda a venderlo a esa escuela o esta escuela. En resumen, ser el puente entre los desarrolladores y el mundo exterior.

A veces aporto algo de mi profundo interés: el desarrollo del cliente. Por ejemplo, al integrar el juego en un curso escolar, encontramos un problema: los niños van a los cursos de programación, luego vuelven a casa, los padres les preguntan "qué hiciste en esas clases" y responden "nada, realmente". Y los padres se preguntan: ¿simplemente no quieren decirles o realmente no hacen nada? Así que hicimos informes de progreso automatizados: por ejemplo, los padres pueden recibir mensajes "su hijo aprendió el perceptrón hoy" o "su hijo programó un rnn", etc. Estas características ocurren gracias a las interacciones entre el juego y el mundo, principalmente a través de mí.

Además, como CEO, mi trabajo es inspirar a todos con un objetivo común que lo abarque todo, hacer que el trabajo de todos sea cómodo, eliminar cualquier complicación y hacer que la gente simplemente trabaje y no se preocupe por las necesidades básicas.

De acuerdo Entonces, ¿no te estás programando ahora?

Lo hago, pero solo ocasionalmente. Actualmente trabajo en reelaborar nuevas empresas dentro del juego. He tenido una idea sobre cómo hacerlo durante mucho tiempo, aunque para nuestro próximo proyecto dedicado al marketing en Internet, pero no tuve tiempo para ello. Solía ​​hacer estas cosas en una semana, ahora llevo un mes y todavía no lo he hecho.

Sobre programación en desarrollo de juegos

Recordemos los buenos viejos tiempos. ¿Podrías contarme sobre tu vida como programador?

Bueno, el proyecto más grande en el que participé, el que dio forma a mi futura carrera, fue el juego Prime World. Fue un gran proyecto en Nival, un MOBA con un elemento social (llamado Castle, creo). Estaba en el equipo de Castle y tenía más de 20 personas, ¡para una pequeña parte del juego! Y, bueno, tenía todos los problemas del modo multijugador sincronizado que existen en este mundo.

¿Cuándo te uniste al proyecto, cómo era en ese momento?

Cuando me uní, "Castle" prácticamente no existía.

Pero, solo para informar a los lectores que no jugaron, el juego tenía dos partes: una con batallas reales al estilo MOBA y el Castillo, donde el jugador sube de nivel, contrata héroes, los desarrolla, luego elige un héroe y entra en batalla . La parte de la batalla estaba casi completa en ese momento, pero la parte social estaba en las primeras etapas de desarrollo.

¿Y cómo te contrata Nival?

Vine como programador habitual. Recuerdo haber creado un nuevo proyecto de Unity: comenzamos desde cero y teníamos que crear el Castillo e integrarlo con la parte de la batalla, luego en desarrollo activo.

OK, entonces fue Unity. ¿Qué lenguaje de programación, entonces? C ++, C #?

La parte de la sesión estaba en C ++, nuestra parte estaba en Unity y la lógica principal estaba en C #. Pero dado que era, digamos, un proyecto complejo con muchas tecnologías entrecruzadas, también pasamos todo por Thrift para traducirlo a Python, porque en eso estaba escrito el servidor.

Wow, hablemos de gastos generales para el desarrollo de C #.

Y eso es para decirlo suavemente. Pero todavía encontramos una salida elegante. Nuestros compañeros de trabajo mayores eran muchachos muy experimentados, por lo que diseñamos el código específicamente para estos traductores y todo fue bastante bonito, prácticamente no se requiere presentación manual.

Creo que fue durante el tiempo en que tecnologías como Thrift, Protobuf y otras estaban despegando. Lo consideramos un milagro tecnológico: simplemente tomaron su código, en varios idiomas, y resolvieron el problema de armarlo todo.

Solo puedo imaginarlo. Cuando se unió al proyecto, ¿ya estaba familiarizado con C # y el mundo de .NET en general?

Sí, estaba bastante familiarizado. También conocía Unity 2.6 (si no recuerdo mal), pero ese era un producto extraño en sí mismo. Podría escribir en .NET, pero en Mono en una etapa temprana. Era el momento en que Xamarin ni siquiera estaba en desarrollo todavía.

Recuerdo que Mono era un animal bastante salvaje que la gente rara vez había visto, pero se incorporó a Unity, que fue el proyecto más grande para incluir a Mono. Así que tenía cada pequeño problema que las máquinas virtuales tenían en sus infantes. Fugas de memoria increíblemente altas en todas las plataformas, diferencias impredecibles de .NET en las cosas más mundanas, asignaciones innecesarias en todo el lugar ...

Entonces, antes de eso, trabajó con .NET normal, y allí recibió un tiempo de ejecución diferente y mal documentado (en ese momento).

He trabajado en Unity antes, pero esto, por falta de un término mejor, "período de transición", cuando trabajabas en Unity y ahora tienes que trabajar en Mono, fue difícil. No puedo decir que haya sido un desarrollador .NET particularmente experimentado. Lo entendí bien e incluso un par de proyectos terminados, pero no me importaba el rendimiento en absoluto, por lo que probablemente cometí muchos errores de optimización en mis proyectos. Todas las partes que exigían rendimiento estaban en C ++, .NET no tenía nada que ver con ellas.

Cuéntame sobre tu primera semana en el trabajo. Pasaste la entrevista, recibiste una oferta y un boom: eres un desarrollador. Que sigue

Bueno, vale la pena mencionar que no comenzamos con Prime World. Hubo otro proyecto antes de eso, pero no logró su lanzamiento y un día nos cambiaron a Prime World para trabajar en el Castillo. Sucedió muy rápido: nuestros diseñadores esbozaron una idea muy aproximada de lo que querían: "Debe haber una especie de castillo, y hay un jugador dentro, él lo construye, lo nivela, etc.".

Recuerdo que en la primera semana construimos el esquema básico de un castillo con algunos bloques básicos, solo para mostrarles a los diseñadores lo que podría ser. Y luego, una vez finalizada la interactividad básica, tuvimos que descubrir cómo debería funcionar en el lado del servidor: cómo visitar el castillo de un amigo para verificarlo, cómo motivar al jugador para que haga la transición a la batalla. Entonces el jugador contrató héroes, los niveló, compró los talentos correctos, cómo debe ir a la batalla con ese héroe. Pero para ir a la batalla, tenemos que transferirlo de la parte del castillo a la parte de la sesión. Y las partes se basan en diferentes lenguajes y tecnologías: no fue un puente rápido para construir. Pero fue hace mucho tiempo.

Cronología de desarrollo de Luden.io

• En 2014, Nival forma un equipo separado para trabajar en juegos educativos de realidad virtual: NivalVR.
• En enero de 2015 se lanzó su primer proyecto: InMind, un juego sobre viajar al cerebro de una persona a nivel microscópico para encontrar neuronas que causan problemas psicológicos.

• El mismo año se lanzó InCell. Se expandió con la misma idea, pero sonó como un chatbot enloquecido: un juego educativo con elementos de carreras y estrategia, con generación de procedimientos, para dispositivos de realidad virtual. El juego se trataba de viajar al mundo celular de una persona.
• En Epic Games MegaJam 2016, Luden.io hizo VRobot: "un juego inútil pero divertido" en el que aplastaste una ciudad con un robot gigante. En 2017 se lanzó en SteamVR, y en 2018 en Playstation VR.

• En 2016, NivalVR se separó de la compañía y pasó a llamarse Luden.io.
• En 2017 se lanzó ARrived: un simulador de Dios en realidad aumentada basado en varias tecnologías: Google ARCore, Apple ARkit y CoreML.

• En marzo de 2018, True: learn (), un simulador de aprendizaje automático, pero sin VR y AR, entró en el acceso temprano.

Sobre liderar una empresa tecnológica

Entonces, ahora eres el jefe de Luden.io. ¿Qué es más difícil: codificar puramente o hacer todas estas cosas de administración, ser un puente entre el mundo y los desarrolladores?

Creo que depende de con qué tipo de personas trabajas. Tuve mucha suerte de tener a las personas que tengo, y estoy muy emocionado tanto por administrar como por codificar.

Pero, si comparamos teóricamente los trabajos de un programador y un CEO, entonces la programación es un trabajo mucho más lento. Se te ocurre una idea, la planeas, la haces. Las distracciones externas son raras y pequeñas. Esencialmente, en la codificación siempre tiene una decisión "correcta" y métricas estrictas y cuantificables de éxito: una decisión correcta significa que ejecuta esa función en menos de 2 ms y paralelizada en N subprocesos. Conoces tus objetivos, si los golpeas, todo está bien.

El CEO no tiene nada similar. En este mundo, no existe una métrica formal de éxito, a pesar de que usted los configura constantemente para su negocio. Siempre debe pensar en lo que puede hacer mejor o de manera diferente. No hay reglas tampoco. Pero ciertamente tiene su encanto.



¿Crees que tu experiencia como desarrollador te ayuda con las responsabilidades de tu CEO?

Yo creo que sí. No creo que haya muchas compañías tecnológicas en el futuro que no tengan un líder con una comprensión clara de las rutinas de desarrollo en mente. Apenas puedo imaginar cómo funcionaría eso. Pero estoy seguro de que el líder debería, como mínimo, tener un título STEM para permitir que la compañía avance como un tren fuera de control, que es la velocidad mínima aceptable para que una compañía tecnológica sobreviva en estos días. No puedo decir que sea la única forma, pero creo que es la más correcta en cuanto a evolución.

¿Revisas el código tú mismo?

En realidad no Cuando trabajamos en Prime World, un gran proyecto, lo hice, pero teníamos procesos muy diferentes en ese entonces. Allí revisamos todo el código base para que se adhiera a un estándar común. Prime World era tan grande que simplemente podíamos olvidar que una parte de la base de código se estaba utilizando en otra sección del juego. Incluso nos costó probar el proyecto localmente, era tan grande. Así que teníamos estándares de revisión de código muy estrictos.

Pero allí, a pesar de que los programadores toman prestado código entre ellos, es principalmente para la integración, cuando recopilamos todas las características en una sola rama. No he visto pequeños estudios de desarrollo de juegos, donde tienes 5-6 programadores como máximo, hacen un proceso de revisión de código gigante. Por lo general, no es necesario: el producto es lo primero y no tenemos la intención de respaldarlo en las próximas décadas.

¿Existe un enfoque consolidado para el desarrollo? ¿Lo obligas a todos?

Hay un estilo de código estándar y algunas pautas básicas sobre qué combinar con qué, algunas reglas arquitectónicas. Hay un esqueleto de proyecto en el que trabajamos. Está probado y probado, por lo que sabemos que no nos permitiría dispararnos en el pie (al menos no desde una escopeta). Hay un conjunto básico de módulos que se utilizan en múltiples proyectos. Algunos de ellos están escritos hace años, algunos solo recientemente. Eso, reutilizar la arquitectura, adherirse a un estilo de código, no nos permite deslizarnos hacia el abismo.

¿Participas personalmente en el proceso de contratación?
Por supuesto
Todos ellos?
Todos ellos

Tu empresa no debe ser muy grande, ¿verdad?

Bueno, no miles de personas, así que tengo la oportunidad de hablar con cada entrevistado durante al menos 10 minutos, solo para descubrir qué ve en la industria del juego, qué juegos juega personalmente.

Pero usted no entrevista a los desarrolladores como, bueno, ¿desarrolladores?

Sabes, tengo algo de suerte. Creo que los chicos que hacen, digamos, software bancario no lo tienen tan fácil como nosotros. Nuestra industria de habla rusa es muy pequeña, y cuando trabajas allí durante un par de años, conoces a mucha gente. Esencialmente, cada candidato, si no es un estudiante recién salido de la universidad, tiene una recomendación de alguien y una comprensión aproximada de lo que puede hacer.
Pero si tuviera que contratar a 100 personas en una semana, obviamente no podría estar tan involucrado. Pero no necesito contratar tan rápido, y la mayoría de las veces, si contrato personas, ya estoy familiarizado con ellas.

Desarrollo de juegos vs desarrollo de negocios

¿Tienes gente que viene de otras industrias?

Hay algunos, pero no a menudo. Las personas entran al desarrollo de juegos por una razón muy simple: les gustaba hacer juegos cuando eran niños y simplemente continuaron haciéndolo.

Tuvimos un par de entrevistas históricas con personas de la industria bancaria. Tuvimos una buena entrevista, acordamos verbalmente algo, parecía que les gustaba y dicen: “Trabajo en un banco, me pagan mucho, pero realmente no me gusta. Me gustaría perseguir mi pasión, y eso es jugar ”.

Se gustan, hacen una oferta y ... la persona desaparece. A veces le preguntas por qué, y él dice: "Vine a presentar una carta de renuncia, el jefe preguntó dónde, respondí, y él me ofreció aumentar mi salario para retenerme". Muy a menudo las personas tomaron el aumento salarial y permanecieron en sus industrias.
Pero también hubo otros casos. Muchas personas muy competentes provenían de otras industrias, incluida la banca.

Sí, recuerdo haber escuchado esa historia en un podcast: un programador del banco dice "Quiero crear algo", luego recibe un pedazo de papel con un número y se queda. ¿Tenías estos pedazos de papel en tu vida?

Como todos, tenía ofertas de trabajo de todas partes. Ni siquiera los miro mucho, sinceramente. Es bueno que tenga demanda, pero quiero dedicarme a esta empresa.

La gente dice que la banca, el código comercial es mucho mejor que el código del juego.

Me gustaría sentarme con alguien que trabajó tanto en la banca como en el desarrollo de juegos. Pero teóricamente, en el desarrollo de juegos hay muchos casos en los que el proyecto despegó inesperadamente.

Por ejemplo, hay una compañía, Kefir, y tienen un proyecto, The Last Day on Earth. Probablemente esté muy bien hecho. Y despegó al instante, ganó más popularidad de lo que podrían haber imaginado. Creo que en esa situación lo último que piensas es la calidad del código.

El proceso de mantener limpia la base del código se basa principalmente en la conciencia de los desarrolladores. Especialmente a los desarrolladores senior que se usan para escribir código bien educado y mantener todo bajo control. Porque la etapa “terminemos con esto y luego repasemos el código” no sucede. Nunca.

Yo mismo incursioné en el desarrollo comercial: nuestra empresa tenía un culto al código de calidad. Realmente no resolvimos tareas, escribimos un buen código, esa fue toda nuestra tarea. Nosotros, como departamento de desarrollo, no podríamos dar una idea sobre cómo funciona el producto o si existe. Veo que tiene un enfoque completamente opuesto: su trabajo es hacer las cosas.

Nosotros, obviamente, ponemos el producto y su éxito primero. Los pensamientos a veces hay situaciones similares a las que describiste. Imaginemos que estamos haciendo un producto en una IP existente y famosa, y sabemos cómo será su futuro. Digamos que sabemos que será compatible durante 15 años. Obviamente, hay un valor comercial para garantizar que el soporte no sea más caro cada año. Pero hay muy pocos proyectos de juegos que sean compatibles durante 15 años, así es como funciona la industria. ¿Cuántos años tiene World of Warcraft? Con solo alrededor de 15 años, Blizzard podría tener problemas con eso. Pero creo que, incluso hace 15 años, Blizzard quería terminar el proyecto y cortar algunas esquinas en el camino.

Se parece más a eso en un proyecto de juego, no se puede predecir cuánto durará, a diferencia de los proyectos empresariales.

Sin duda

En los negocios, las personas están acostumbradas a crear una base de código que dura 15 años, pero tú no haces eso, ¿correcto?

Los programadores generalmente no se centran en crear código que sea fácil de soportar durante 15 años. Pero he visto algunos proyectos muy limpios donde claramente se dedicó mucho tiempo a la calidad del código, las personas fueron muy responsables y les gustó.

Si a todos les gusta mantener las cosas limpias, eso se traduce en un producto fácil de mantener, pero nuestro negocio no siempre requiere eso: estamos enfocados en hacer que el producto funcione.

Aunque apenas puedo imaginar una situación en la que hacemos un software bancario y no tengo idea de si despegará. Las industrias son demasiado diferentes para comparar.

Cómo hacer juegos tanto para ti como para la gente

Miro los juegos de Luden.io y siento que los desarrolladores los crearon tanto para ellos como para su audiencia. Sin tener en cuenta ninguna práctica comercial y tal, sin apuntar a nada para el público específico.

Es una pregunta doble, como siempre. Imaginemos que crea un software que resuelve un problema particular para el usuario. Vamos al usuario y preguntamos "¿Cuál es tu problema?". Nos adentramos en su industria, ejecutamos los números: ¿está el usuario listo para pagar por resolver este problema o no? Y luego creamos un producto que resuelve ese problema.

Los juegos también pueden considerarse como un software que resuelve el problema de un jugador. Quiere entretenerse, en nuestro caso, aprender algo. Pero no es como "me duele la espalda, tomo ese medicamento y ya no". El jugador quiere jugar algo bonito, algo con alma. Necesitamos desarrollar química entre un usuario y el juego. Quiere "hacerse amigo" del juego. Si hubiera una manera infalible de desarrollar esa química, al igual que para resolver problemas en la industria de los negocios, tal vez crear juegos para nosotros no sería tan importante.

Si decimos que no podemos realizar una investigación detallada sobre el tema, entonces la única forma de averiguar si el juego establece esa relación con el jugador es ser ese jugador. Si nos gusta el juego, si lo encontramos hermoso, interesante, entonces podemos deducir que probablemente hay más de uno de nosotros, que también existen otras personas a las que les gusta este juego.

Pero hay una ventaja muy fina allí. Necesitamos ver el producto como si lo hiciéramos por nosotros mismos, pero desde una tercera persona. ¿Cómo miraría el juego una persona que no haya jugado durante 5 años? ¿Qué tal una persona que solo juega Destiny? ¿O alguien que tiene mil horas en Dota? Por lo tanto, debemos verlo desde diferentes perspectivas, pero también con la motivación comercial adicional de jugarlo para su propio placer.

La motivación mental es simple: los juegos son difíciles de hacer y lleva mucho tiempo, por lo que al final invariablemente desarrollarás algo similar al odio por él. Lo has visto tantas veces que te cansas de él. Pero si, entre todo eso, no te gusta el juego en absoluto, entonces inevitablemente te relajarás hacia el final del desarrollo. No hay otra forma de desarrollar juegos que hacerlo por sí mismos, o de lo contrario no lo lograrás lanzar en absoluto.

Pero al mismo tiempo, ¿estás de acuerdo en que tus juegos son más bien nicho?

Por supuesto! Ese es el principal beneficio de lo que hacemos. Queremos ser nicho. No estamos tratando de entretener a todos los hombres de 20 a 40, el mundo entero ya lo hace.

Queremos que los juegos le digan a las personas algo útil, que sean los compañeros del jugador en la vida. Ciertamente no es un nicho tan grande como, por ejemplo, los simuladores deportivos, donde la audiencia es enorme y diversa, pero ni siquiera pretendemos tratar de capturar a tanta gente.

¿Es rentable trabajar según estos principios?

Creo que puede ser rentable (bueno, lo logramos), pero es necesario, por falta de una mejor palabra, "preparar" un mercado primero. Llevamos 4 años trabajando y descubrimos en qué géneros y formatos debemos trabajar para ganar dinero. Podemos hacerlo, pero nadie dice que nuestra marca es el dinero máximo que podría ganar de esa industria.

Solo ahora desarrollamos una comprensión sobre cómo trabajar ese mercado, cómo crearlo. No está muy bien desarrollado. Los próximos 10-15 años se dedicarán a hacer que ese mercado sea más acogedor para los desarrolladores externos que comparten nuestros objetivos: que los juegos deben ser útiles.

Nuestro objetivo es asegurar que en 20 años los juegos ayuden a las personas a aprender y hacer algo que quieran hacer. Algo que también tiene demanda en ese mundo futuro, algo en lo que son más efectivos. Entonces, las universidades y las escuelas solo existirían con fines de investigación.

En general, veo un tema común entre tus intereses: juegos, Gamesjam, conferencias, creo que incluso enseñas ...

Muy raramente 10 horas académicas al año como máximo.

¿Cuándo se originó ese interés en la educación?

Hay algo hermoso en ayudar a los jóvenes expertos a ser mejores y más felices que nosotros. La experiencia ayuda con eso. Pero también hay una motivación menos "visionaria". ¿Cuál es tu juego favorito? Vamos a determinar quién eres por los juegos que juegas.

¿El favorito de todos ellos?
Todos ellos Cualquier genero. Solo lo primero que viene a especie.
Digamos Mass Effect.
OK, esa es una buena opción, a mí también me gusta. ¿Y el segundo?
Gótico, probablemente.
Demonios, el gótico también es excelente. Me pregunto si nuestros intereses se alinean. También me gustan ambos, pero soy un gran admirador de los simuladores y los magnates. Mini Metro, por ejemplo, considero un logro ingenioso del diseño moderno de juegos. ¿Lo has jugado?


Claro que lo sé.

Si dibujamos paralelos con el arte, entonces es la misma "forma nula" que a Malevich le gustaba imaginar: donde se presenta un material enorme, oculto en un sistema profundo, con un esfuerzo mínimo.

Los magnates y los simuladores son el tipo de juegos diseñados para que hagamos algo e inmediatamente veamos las consecuencias. Los juegos, si miramos más a fondo, son una forma libre de riesgos de ganar experiencia, lo que significa que los juegos son la forma más pura de educación. Nuestra empresa se llama Luden.io. Si lo miramos, "Ludus" se traduce del latín de dos maneras: juego y escuela. Hay restos de un lugar llamado Ludus Magnus cerca del Coliseo de Roma. Era un lugar donde los gladiadores jugaban y se preparaban para peleas en la arena.

Por lo tanto, los simuladores son magnates diseñados para brindar a los jugadores experiencia en áreas donde es muy difícil obtenerlo de forma natural, demasiado costoso o francamente imposible dentro de los límites del planeta Tierra. Preparan a las personas para situaciones que pueden venir en el futuro, les permiten "ensayar".

La educación que tenemos ahora y que ha estado allí hace 20-30 años se ha vuelto muy ineficaz. Los niños tienen teléfonos, tienen acceso a YouTube, Twitch, todo eso es mucho más interesante que leer un libro que está demasiado lleno y ni siquiera está bien escrito. Si combinamos estas formas, educación y juegos, entonces todos ganan.

¿Qué pasó con la realidad virtual?

¿Fueron estas ideas la fuerza impulsora que llevó a su empresa a centrarse en la realidad virtual?

La realidad virtual es un tema interesante. Cuando nos separamos de Nival, la realidad virtual acaba de lanzarse. La RV ciertamente escala la parte más fuerte de los juegos: una experiencia sin riesgos, ya que agrega un efecto de inmersión muy fuerte. El cerebro cree más fácilmente que está sucediendo de verdad, aunque es solo otra ilusión óptica. Pero el mercado está luchando en este momento. A nadie se le ocurrió una aplicación de realidad virtual que a todos les gustaría tener en casa.

Así que decidimos avanzar con nuestro objetivo final, pero VR ... Tenemos proyectos en todas las plataformas. Más allá de eso, tenemos algunos proyectos de realidad virtual en desarrollo que pretendemos integrar en las escuelas. Si una plataforma realmente "mueve" el mercado y se convierte en la plataforma de realidad virtual que lo hace grande, obviamente trabajaremos en nuestra presencia allí, pero por ahora tenemos toneladas de jugadores de realidad virtual felices, y si bien True: learn () es tradicional , juego no VR.

Después del E3, hubo ese gráfico que circulaba por Internet y que hay menos menciones de realidad virtual en la prensa que incluso hace un año.

Lamentablemente, eso es cierto.

¿Qué crees que pasó?

¿Personalmente quieres comprar un casco VR?

No

Bueno, esa es tu respuesta. La gente no quiere eso. Una vez que, sí, usted, se despierta y decide que quiere un casco de realidad virtual, entonces algo cambia en la dirección correcta.

¿Por qué la gente no lo quiere? Cuando salió por primera vez, la gente estaba extasiada, decían que en 5-10 años la realidad virtual estaría en todas partes, Ready Player One-style.

Lo primero: no escuche las evaluaciones de negocios, solo los informes de los consumidores. Un cliente, a diferencia de un hombre de negocios, podría responder a su pregunta de manera simple y concisa. Entonces, muchachos, si no quieren un casco de realidad virtual, entonces su motivación describiría la situación mucho mejor de lo que pensaba mi negocio.
Siempre es así: cuando el juego no se vende bien, solo ve a un Gamestop y pregúntale a una persona que no lo compró. Lo explicaría mucho mejor que todos los vendedores combinados.

Creo que es una extensión de un problema de huevo y gallina. Podrías comprar un casco de realidad virtual, claro, pero luego hay una cuestión de qué hacer con él. Pero las personas que crean contenido de realidad virtual se preguntan: ¿por qué desarrollo juegos para este tipo de hardware cuando tan pocas personas lo tienen? ¡No recuperaré mi dinero! Y este círculo vicioso aún no se ha roto en el mercado de realidad virtual.

Pero han surgido algunos segmentos y continuarán mejorando. Comenzando con nichos más pequeños y luego cada vez más grande. Al igual que el surgimiento de las consolas de juegos en los años 80 y 90, la mejor hora de la realidad virtual llevará algún tiempo. Ciertamente no vendría en 3 años.

¿Crees que la realidad virtual despegará un poco más tarde?

Depende del formato. Sería un dispositivo universal VR-AR o productos separados es muy difícil de predecir. Mi opinión es que la realidad virtual ocupará un nicho grande, pero especializado, como las tabletas tienen hoy. Mucha gente los tiene en casa, pero pocos compran otros nuevos y aún así resuelven un problema definido. Creo que la realidad virtual terminaría en la misma línea. Hay un segmento de mercado para tomar, la pregunta es: qué tan grande.

Sin embargo, hay otro uso para ello. Uno de mis amigos me dijo que compró un casco de realidad virtual para ver películas porque tiene 4 hijos. El caso de uso es perfectamente claro, creo.

¿Fue técnicamente difícil trabajar con VR?

La realidad virtual tiene grandes problemas de rendimiento y exige mucho de las plataformas que lo admiten. Uno de nuestros viejos juegos, VRobot, acaba de salir en Playstation VR. Requiere un rendimiento estable de 60 FPS. Oculus Rift (incluida la versión móvil) necesita 75 FPS. Incluso si cae 20-30 FPS durante escenas particulares, eso es inaceptable, debe optimizar el juego mejor.

Pero tenemos un equipo muy fuerte de optimización de gráficos de bajo nivel. Nikita, por ejemplo, se especializa en eso.

¿Entonces tienes un chico dedicado a la optimización?

No solo está haciendo eso, sino que es su habilidad principal. Trabaja en conjunto con Dima, quien puede construir cualquier escena 3D para cualquier requisito de rendimiento. Así que estamos listos en ese sentido.

Sobre el aprendizaje automático en el desarrollo de juegos

Para las personas fascinadas por el desarrollo de juegos y el aprendizaje automático, Oleg muestra una foto de Demis Hassabis como inspiración. Un experto en ajedrez, neurobiólogo y fundador de DeepMind, también comenzó su carrera en el desarrollo de juegos.

Él programó su propia IA para el juego de Peter Moulineux Black & White, y luego, como jefe de su propia compañía, Elixir Studios, lanzó un simulador de súper villano Bond, Evil Genius.
Y solo entonces se convirtió en uno de los investigadores de IA más famosos del mundo.

¿Es verdadero mientras: aprender () basado en su propia experiencia?

Sí, el juego se basa principalmente en eso. El funcionamiento de la industria del juego es que si comienzas a hacer algo, debes tener un punto de referencia para mirar hacia atrás. Estamos haciendo una simulación: hay muchos detalles que deben ser atendidos, y para eso necesitamos un punto de referencia, solo para evitar salir completamente de los rieles creativamente.

En while True: learn () tomamos nuestra propia realidad como punto de referencia. Si haces algo y no sabes qué hacer, mira cómo se hace en realidad. La economía del juego está alquilando granjas de servidores. Si intenta resolver una tarea de procesamiento de un gran grupo de datos, alquila algo de potencia informática, ejecuta sus números, envía la tarea y detiene su alquiler.

Queríamos mostrar cómo se ha desarrollado el aprendizaje automático desde la década de 1950, desde el primer perceptrón hasta los carros de conducción, las redes de cápsulas, etc.

Vanya mantuvo específicamente una hoja de cálculo de Google con todos los puntos de referencia: los principales hitos del aprendizaje automático, cómo la industria cambió con el tiempo y qué nuevas tecnologías se han desarrollado. Y así es como se presenta al usuario: a través de misiones.

Algunas versiones de juegos incluso mencionaron un año. Lo eliminamos por varias razones, tal vez volveremos a hacerlo en algún momento en el futuro. Pero el jugador viaja por el mismo camino: completa un par de misiones con el perceptrón y gana un poco de dinero.

Cada año sucedía algo interesante que fue confirmado o reprendido por el desarrollo futuro.



Puedes hacer clic en cualquier bloque y descubrir cómo funciona en el juego y, en realidad, hay dos enlaces: uno a un video de YouTube que cuenta sobre ello de manera concisa, y el otro a un artículo detallado para aquellos que quiero realmente entrar en eso.

¿Ha trabajado el equipo en aprendizaje automático antes?

Claro mientras que True: learn () se realizó a lo largo de VRobot, por lo que el equipo de realidad virtual se centró en transferir el juego a Playstation, y el nuevo equipo más pequeño estaba formado por especialistas en aprendizaje automático.

Cuéntame sobre ellos: ¿cómo es el equipo, en qué trabajaron antes?

Nada especial, de verdad. Cuando se me ocurrió la idea de crear un simulador de ML, elegí un equipo de recomendaciones de amigos y estudiantes.

Específicamente expertos en ML?

Sí, pero todos son bastante jóvenes, nadie tiene, como, 20 años de experiencia en aprendizaje automático. Todos jugaron Kaggle al menos un par de veces, resolvieron algunas tareas. La mayoría de ellos lo estudiaron en la universidad.

E hicieron un juego. Pero, de nuevo: el desarrollo del juego no es realmente aprendizaje automático, ¿verdad? Lo que significa que son pilas completas: ¿científicos de datos y desarrolladores de juegos en uno?

Estas son personas que, ante todo, entienden el aprendizaje automático, saben cómo funciona. Y luego desarrollan un juego en Unity, escriben código, diseñan interfaces, etc. Es solo eso, para desarrollar misiones y establecerlas a lo largo de una línea de tiempo, primero debe comprender el contexto. Obviamente, no crearon un cuaderno de ipython para cada búsqueda.

Tenemos una biblioteca específica que ejecuta redes convolucionales y algunas cosas básicas en Sharp que funcionan en Unity. También se usó para crear AIDraw, un juego de dibujo: el jugador dibuja algo, y luego la IA tiene que adivinar qué se está dibujando. Esta biblioteca hace la mayor parte del trabajo sobre eso, y todo el juego está construido a su alrededor.

No ha pasado mucho tiempo desde que el aprendizaje automático y el desarrollo de juegos comenzaron a unirse. Digamos que tengo un juego que utiliza el aprendizaje automático. ¿Qué tipo de pila necesito?

No he visto muchos proyectos que combinen el desarrollo de juegos y el aprendizaje automático, estrictamente hablando, donde el trabajo de ML se ve en el lado del cliente. Unity tiene su propio sistema de "aprendizaje de refuerzo" que no necesariamente hace muchas cosas, pero está integrado en Unity, por lo que la barrera de entrada es bastante baja.

Hay muchas bibliotecas para ello, al igual que para otros campos: marcos C ++, redes neuronales ...
Los dispositivos móviles a menudo usan CoreML de Apple que puede ejecutar sus cálculos directamente en el chip de gráficos del dispositivo. Tomamos un modelo, "lo enseñamos" en TensorFlow o CatBoost de Yandex, lo empaquetamos en un archivo especial y ahí vamos: puede ejecutarse directamente en la GPU del teléfono inteligente y devolvernos una predicción resultante. Lo utilizamos, como ejemplo, con nuestro juego de realidad aumentada ARrived, donde necesitaba tomar una imagen de una cámara y descubrir qué era.

Sin embargo, si hablamos sobre el uso del backend, entonces todo es muy clásico y directo. Los servidores se ejecutan en tecnologías muy simples que se utilizan en todo el aprendizaje automático, pero allí se utilizan para análisis o personalización, por ejemplo, la orientación de anuncios. Un caso bastante famoso fue predecir cuándo un jugador de World of Tanks se desconectaría del servidor y qué hacer con él. O para predecir el momento de darle una oferta al jugador, dos caballos por el precio de uno, cuando es más probable que lo compre y esté contento con él. Estas son aplicaciones de servidor, y el tamaño de la pila no es realmente un problema.

¿Pero podría construir un conjunto de datos ser el núcleo del diseño de un juego?

Suena como un concepto sacado directamente de Westworld. Puede tener sus usos, pero no veo cómo un conjunto de datos de acciones de jugadores podría ser beneficioso para nosotros.

Por ejemplo, hacemos un juego sobre conducir en un entorno urbano. Hacemos un modelo realista de las carreteras de Moscú. Podemos ver que muchos jugadores chocan en esta ubicación, o exceden el límite de velocidad en este tramo. Con un conjunto de datos como este podemos averiguar dónde están los problemas.

¿Pero si es solo un juego y no un simulador? Quizás el conjunto de datos pueda resolver los problemas de la compañía en lugar de los de los jugadores. Si la compañía hace juegos de un tipo similar, los conjuntos de datos del comportamiento de los jugadores podrían ser útiles para ellos, pero no he visto proyectos construidos específicamente para ese propósito.

¿No era ese el propósito de AIDraw?

La escala importa. Si tuviéramos 300,000 veces más jugadores, entonces probablemente algo podría haber salido de eso. Si Google creó ese juego, entonces podrían recopilar datos valiosos y hacer algo con él, con fines de investigación. Pero no para nosotros.

Imaginemos que se te ocurrió un juego que usa ML de alguna manera, y durante el desarrollo te das cuenta de que no puedes crear exactamente lo que imaginaste: creaste algo diferente. ¿Te ha sucedido eso alguna vez?

Por ejemplo, sabíamos que queríamos lanzar una gran actualización de while True: learn () sobre autos sin conductor. El jugador le enseñaría a un auto a conducir, adelantar a otros autos, cambiar de carril, acelerar y frenar.



Por lo general, el diseñador del juego escribe un documento de diseño, luego se crea contenido basado en eso (como en otras industrias). Pero con los autos entendimos desde el principio que no sería así. Tuvimos múltiples etapas, cada una con su propia tecnología. El jugador aprendería genética; entonces entiendo que no es muy bueno para sus propósitos. Entonces habría refuerzo en muchas formas. El jugador entendería que un método de aplicación particular es más efectivo para su tarea.

No es una experiencia que se pueda controlar. Sabiendo que algo podría salir mal, primero escribimos una demostración técnica, una versión técnica y cruda de la experiencia que queríamos crear. Luego se lo entregamos a los diseñadores de juegos, quienes lo jugaron, escribieron un documento de diseño y pulimos y finalizamos el juego basado en eso.

Y no solo los diseñadores de juegos también: tenemos una comunidad de los amigos más cercanos en Discord, podemos darles una demostración de características y nos pueden dar retroalimentación. Actualmente han estado jugando la demostración de autos sin conductor durante un par de semanas y constantemente nos cuentan sus experiencias.

¿Con qué terminamos, al final? Primero, declaramos qué tipo de entrada de datos debería usarse para enseñarle a un automóvil a conducir, qué parámetros podemos cambiar (umbrales, pérdidas; en genética, tamaño de generación, mutaciones). Y lo que salió fue algo no muy interactivo. El jugador inicia sesión, establece algunos parámetros y luego mira la pantalla mientras el auto se conduce solo. Es genial para los desarrolladores que conocen el concepto, pero no para el jugador que no.

¿El jugador no siente su contribución?

Exactamente, no hay comentarios. Así que cambiamos un poco el diseño. El jugador conduciría el auto él mismo, lo enseñaría. Y luego se repetiría después de ti en función de cómo lo entrenaste.
Si el jugador solo cambia al carril derecho, entonces el auto no sabría cómo cambiar a la izquierda, porque no le ha enseñado cómo hacerlo. Se volvió interactivo. Entonces, tal vez no estamos lejos del producto final después de todo.

En esencia, entendemos que con el aprendizaje automático, algo puede salir mal. Es prácticamente imposible dar cuenta de todo en la etapa de diseño.

Entonces, ¿planeas hacer un prototipo y luego rehacer algo desde cero?

Básicamente sí.

Pero no es la forma en que los desarrolladores de juegos hacen las cosas. Es algo exclusivo del aprendizaje automático, ¿verdad?

Puedes decir eso, sí. En otros juegos e industrias podemos predecir cosas. No somos novatos en esto, por lo que podemos entender qué hará el jugador, qué emoción experimentará. Nuestra "base de datos de predicción" que construimos a lo largo de los años puede manejar eso. ¿Aprendizaje automático, sin embargo? Cada convención sale por la ventana.