Cómo No Construir un Videojuego

Solo estoy aquí para hacer otra rifa. ¿Quieres hacer otra rifa? No.

Oye, esta conferencia fue increíble. Hay tanta gente detrás del escenario, en todas partes haciendo los MCs, están los organizadores, hay Así que solo demos un aplauso a todas las personas que hicieron esto posible.

Así que esta charla es un poco diferente. Solo quiero que todos se relajen, y solo quiero entretenerlos. No estoy aquí para vender nada, no estoy aquí para convencerte de que lo que estoy haciendo es mejor que lo que todos los demás están haciendo. Todo lo contrario. Lo más probable es que lo que estoy haciendo sea mucho peor de lo que deberías estar haciendo. Hoy voy a hablar sobre cómo no construir un videojuego y voy a mostrarte tecnologías que usas todos los días en tu trabajo como ingenieros de front end, pero en un contexto en el que probablemente nunca las has visto utilizadas. Y espero inspirarte a hacer las cosas tal vez de manera diferente. A pensar más en soluciones específicas de dominio en lugar de construir otro formulario de 11 pasos.

Déjame mostrarte el videojuego que estoy construyendo. Aquí hay un video. Se llama Athena Crisis. Es un juego de estrategia por turnos 2D retro moderno. De hecho, espera un minuto, falta algo aquí. Creo que falta música. Déjame abrir VS code. Déjame poner la música. ¿Tienes música? ¿No? Oh... Sí, eso es Athena Crisis. Supongo que notaste que todo esto es React. Y no es solo React, este juego se ejecuta dentro de la presentación de diapositivas que está escrita usando MDX, que es un fork de React. Lo siento, que es un fork de Markdown que te permite poner componentes de React en tus presentaciones. Así que tengo el juego ejecutándose dentro de una presentación de diapositivas que está toda escrita en JavaScript, React y CSS. Déjame deshacerme de VS code de nuevo. Una vez que me di cuenta de que podía poner una versión del juego en mi presentación, también podría poner tres en ella. Y puedo tener a la IA jugando contra mí y esto es como estar sentado en Central Park en Nueva York y jugar ajedrez rápido, jugando múltiples juegos. Así que puedo esperar aquí hasta que la IA termine.

Esperemos un segundo. La IA está tratando de vencerme. Ahora puedo entrar aquí y realmente puedo ir y jugar el juego simultáneamente en todos estos mapas. Entonces me di cuenta de que también puedo simplemente traducir este juego a cualquier idioma y tener el juego funcionando dentro de esta presentación en cualquier idioma al que se traduzca el juego. Aún más, me di cuenta, hagamos uno diferente, me di cuenta de que puedo poner el editor de mapas que construí en la presentación. Así que puedo simplemente entrar aquí y hacer un nuevo mapa. Y solo hay dos restricciones aquí para hacer que todo esto funcione, para hacer que todos los mapas sean automáticamente hermosos. Una es, ¿puedes colocar esta baldosa en esta ubicación? Y dos, dependiendo de las baldosas a mi alrededor, ¿cómo debería verse esta?

Así que, por ejemplo, puedes poner cualquier combinación de árboles juntos. Puedes ir al editor de escenarios, puedes elegir el personaje que te guste, elegir su foto de perfil digamos. Y luego desde allí, puedes entrar directamente al juego y probar los mensajes en el modo campaña. Así que este es Athena Crisis. Todo lo que has visto está construido desde cero con JavaScript, React y CSS. La pila está usando Vite, PMPM, TypeScript, React, Relay, Emotion, Prisma, GraphQL, GraphQL Pothos, Socket.io, y estructuras de datos persistentes.

Escribí una publicación en el blog. Saqué las piezas principales sobre las que tengo una opinión, como Vite, PMPM, TypeScript, las puse en una plantilla, y expliqué cómo armar una experiencia de front-end realmente rápida. La restricción que me impuse cuando comencé esto es que solo se me permite usar herramientas en la capa directamente debajo de mí que entiendo tanto que podría construir una versión muy básica y compatible de ella si tuviera que hacerlo. No entiendo los motores de juego, así que la única manera de usar uno era construir uno por mí mismo. He trabajado en infraestructura de pruebas en el pasado. ¿Cómo pruebas un videojuego? Si estás jugando videojuegos, son juegos triple A, y se lanzan, lo primero que haces es descargar un parche de 10 gigabytes porque, desde el momento en que lo enviaron y el momento en que lo lanzaron, encontraron tantos problemas que tuvieron que parchearlo. No hay muchas pruebas, y luego comienzas a jugarlo y hay tantos errores, tantos problemas visuales, todo tipo de problemas, ¿verdad? Y así, me gusta probar. No escribo muchas pruebas, pero quería averiguar cómo puedo asegurarme de que cuando cambio el juego, no estoy rompiendo algo todo el tiempo. Y recientemente exhibimos este juego en Tokio en una feria de videojuegos y tuvimos gente jugando en dos estaciones desde las 10 AM hasta las 6 PM durante todo el día y no experimentamos un solo error de juego. No digo que no haya errores, pero ese día nadie encontró uno. Pero de todos modos, lo que haces, tienes este videojuego y tienes estados de juego. ¿Cómo verificas que funciona? Podrías escribir pruebas para verificar, ¿está esta cosa aquí, está esta cosa allá? ¿Tiene este una salud de 50 y este una salud de 77? Y luego cambias el equilibrio y todo simplemente se rompe, ¿verdad? O cambias los gráficos y las cosas se rompen. Y entonces pensé, está bien, tal vez simplemente renderizaré mi estado de juego a texto. Hago una instantánea de gest o algo así y hago un renderizador que toma mi estado de juego y lo convierte en texto. Luego terminas teniendo dos implementaciones de tu renderizador. Una para el juego real y otra para tu prueba. Y si estás usando texto para representar el estado de tu mapa, te das cuenta de que apesta porque se desincroniza.

No tiene el mismo nivel de fidelidad. No obtienes la misma información de ello. Entonces, ¿qué tal si simplemente hacemos una instantánea del juego y la convertimos en imágenes y tenemos instantáneas que se verifican dependiendo de cómo se vea el juego. Y si estás usando iterm o terminales similares, puedes simplemente imprimir el mapa real del juego, el en el terminal mientras estás desarrollando.

Te lo mostraré. Tengo el conjunto de pruebas ejecutándose aquí ahora mismo. Puedes ver que verifica que el estado del juego es correcto en cada etapa y simplemente imprime el estado del juego en ese estado en el terminal. Así que mientras estoy desarrollando, puedo ver esto para ver si las cosas se ven correctas. Y si algo cambia, como si una unidad pierde una habilidad o una unidad simplemente falta, puedo señalar el commit exacto donde algo salió mal.

Solo como ejemplo, esta es la infraestructura de pruebas que construí. Básicamente, simplemente ejecutas un montón de estados del juego contra el mapa. Recibes un nuevo estado y luego capturas ese estado del juego como una captura de pantalla y lo comparas con una instantánea de imagen. Muy bien. Creo que eso fue mucho. ¿Verdad? Mucho JavaScript. Mucho JavaScript realmente mal escrito. Y mucho más CSS. ¿Por qué alguien escribiría un juego con CSS, el DOM y JavaScript? Una de las cosas es que obtuve tiempos de carga instantáneos. He estado jugando este juego todo el tiempo mientras estoy en el escenario aquí. Todo está en vivo. Puedo recargar este mazo de luces. Está justo ahí. Puedo tocar esto. Obtengo estas increíbles transiciones suaves. Todo esto es CSS. Esto es solo un CSS. Hay un montón de variables CSS y automáticamente determina cómo disponer este círculo. ¿Y puedes ver esa transición suave cuando lo toco? Salta un poco para verse realmente pulido. Accesibilidad.

Puedes simplemente conectarte a esas APIs y hacer que este juego funcione para personas con varios grados de daltonismo, por ejemplo. Modo claro y oscuro. Una de las cosas geniales es que no sé por qué harías eso. Pero puedes soportar el modo oscuro con el videojuego. Así que por alguna razón, porque construyo todo desde cero aquí, toda mi presentación de diapositivas está ahora en modo oscuro. Y el juego también está en modo oscuro. Así que simplemente cambiaré de nuevo.

La desventaja es, como todos saben con JavaScript y DOM y CSS y React, es que a veces luchas con el rendimiento. Y antes mencioné estructuras de datos persistentes para describir declarativamente el estado del juego. JavaScript es muy adecuado para eso porque puedes moverte tan rápido y obtienes recargas instantáneas y recarga de módulos en caliente. Y luego tienes estructuras de datos persistentes para simplemente evolucionar el estado del juego con el tiempo. Y si tienes estructuras de datos persistentes, lo bueno de esto es que es muy barato. Por ejemplo, estoy hablando de Immutable.js. Es muy barato copiar el estado actual del juego, cambiar solo una pequeña cosa sobre él, y no usar demasiada memoria. Así que puedo mantener muchos estados del juego alrededor. Y luego tomo este estado del juego, y lo coloco en la parte superior de mi árbol de componentes para declarativamente decirle a cada componente qué deben renderizar. Déjame mostrarte. Aquí acabo de cargar un mapa y le dije a la IA que produjera 30 estados del juego y ver qué hace. Y tengo un medidor de FPS aquí. Y lo genial es que puedo saltar aquí y simplemente jugar el juego en cualquier lugar, dependiendo de lo que quiera hacer. Pero ya sabes, 30 mapas no es genial. ¿Qué tal 848 mapas? En realidad, no creo que eso sea muy genial tampoco, así que veamos si podemos obtener algunos más si rehacemos todo. Podría tomar un tiempo. Así que la cosa es que esto no está guionado, no tengo idea de lo que hace la IA. No es completamente determinista. Y simplemente estoy diciendo a dos IAs que jueguen entre sí hasta que una de ellas gane y luego dame todos los estados. Vamos a quedarnos con 1507. Y de nuevo, puedo simplemente saltar aquí y jugar el juego en cualquier momento. Veamos quién gana al final. No tengo idea.

Okay. Terminó en empate. Demasiado en juego. Hagamos uno más. 1461. No puedo llegar al final. Creo que el rojo gana en este. Okay. De todos modos, eso es Athena Crisis.

Así que ahora, quiero jugar un pequeño juego contigo. Es realmente aburrido, porque el juego se llama is-that-CSS y excepto por una vez, es siempre CSS. Déjame demostrártelo. Solo toca esto, ve al panel de elementos. Estos son todos divs. Todos divs. La única cosa aquí que no es CSS, en realidad, es esta flecha. Esa está usando SVG. Sin embargo, esta animación de hormigas marchando está usando una animación CSS. Si estás mirando este fondo allí, este radio azul donde las unidades pueden moverse, esos son todos diffs, rectángulos con un borde alrededor de ellos y una imagen de máscara rotada encima de ellos que es como un patrón de rayas para enmascarar cada otro píxel.

Para mostrarte esta infraestructura, déjame abrir VS Code de nuevo. Ve a la unidad. Aquí puedes ver las unidades con las que puedo interactuar, tienen este contorno rojo, y se anima un poco. Sale. Déjame acercar aquí. Sale cuando tocas una unidad. ¿Lo ves? Es como una transición realmente suave, pequeña de 200 milisegundos porque quiero que sea lo más pulido posible. Lo bueno de mi infraestructura es que puedo simplemente cambiarla, y se recarga en caliente inmediatamente. No hay retraso. Esta es la infraestructura. Si miras los edificios aquí, este edificio, hay una unidad detrás de él.

El edificio se desvanece hacia la parte superior para que puedas ver lo que hay detrás. Eso también es una imagen de máscara con un degradado lineal que simplemente desvanece progresivamente esa imagen. Déjame simplemente apagar ese degradado y entonces se ve así. Muy bien.

La niebla, este tipo de juegos tienen un sistema llamado niebla donde no puedes ver lo que hay detrás hasta que mueves una unidad cercana que tiene un cierto rango de visibilidad. Si me muevo por aquí, partes de esta niebla serán reveladas. Pasé por algunas iteraciones de esto, pero la más divertida que encontré es renderizar un montón de rectángulos negros en el DOM, añadiendo un filtro de desenfoque y luego usando Mix Blend Mode con el atributo de saturación para fusionarlo en la capa debajo de él. También puedo cambiarlo. Así es como se ve Mix Blend Mode. Así es como se ve el filtro de desenfoque.

Una de las cosas interesantes sobre la niebla es que, debido a que este juego es una experiencia híbrida, no es solo un juego de un solo jugador. Es un juego híbrido en línea de un solo jugador y multijugador donde otras personas podrían invadir tus mundos y podrías tener que invadirlos cuando el juego salga. Pero si simplemente puedes tomar este nodo DOM con una niebla en el panel de elementos en tus herramientas de desarrollo y simplemente eliminarlo y es como ja ja te tengo, veo todo lo que está pasando y voy a hacer trampa, eso no sería muy divertido, ¿verdad? Así que aquí está la cosa, en Athena Crisis, todo el estado del juego que no se te permite ver está en el servidor y el servidor decide qué puede ver cada cliente. Es como cuando vas a una red social y estás publicando algo solo para tus amigos y alguien carga tu feed de noticias, entonces los mensajes que no se les permite ver estarán ocultos para ellos desde el lado del servidor. Excepto que aquí, cada campo tiene esa regla de visibilidad aplicada a él. Así que aquí en este ejemplo hay dos mapas, tienen el mismo estado del juego, pero el jugador rosa aquí no puede ver nada que esté oculto aquí en la niebla. Déjame simplemente hacer que la IA haga los mismos movimientos aquí. Y así en el cliente solo verás los estados del juego que se te permite ver. Así que, por ejemplo, aquí abajo hay una nueva unidad que fue creada durante el turno de la IA o del enemigo. Así que puedo tomar esta, moverme por aquí, y una vez que llegue aquí me mostrará lo que está pasando por aquí, dependiendo de lo que se me permite ver, recibo esos estados del juego. Así es como funciona la niebla.

Otra cosa es que quiero que este juego funcione realmente bien en móviles, en IOS y Android, y con dispositivos táctiles específicamente. ¿Alguna vez has escrito en tu teléfono y estás escribiendo una palabra y el siguiente carácter es una E y luego tocas ligeramente la W cerca de la E y aún así sale como una E? Eso es porque los botones que ves en los teclados de tu teléfono móvil están realmente dimensionados de manera diferente dependiendo de lo que el teléfono móvil predice que probablemente estés escribiendo a continuación. Y entonces pensé, ¿cómo puedo aplicar esto a un videojuego donde hay una cuadrícula y son todos bastante pequeños y quiero asegurarme de que siempre estés escribiendo lo correcto? Así que construí un pequeño motor predictivo para averiguar con qué es más probable que el jugador interactúe, y lo más probable es que vayas a interactuar con tus propias unidades. Así que si soy el jugador rosa aquí y voy a esta playa y simplemente me acerco a esa casilla donde está la unidad, donde está este jet, tomará el enfoque inmediatamente. Así que puedo hacer clic aquí, aunque no esté en ese campo, para enfocar ese. Así que una vez que enfoco esa unidad, cambia las áreas táctiles dependiendo de lo que probablemente vaya a hacer a continuación. Así que lo más probable es que quiera ir a esta unidad. Así que incluso si estoy aquí en esta casilla de bosque y me muevo solo un poco más cerca de eso pero no estoy en el campo del helicóptero, aún lo enfocará. Pero como dije, hay algunas trampas alrededor del rendimiento.

Uno de ellos es que el juego se renderiza así. Puedo jugarlo, pero no creo que sería una experiencia muy agradable si tienes una pantalla grande. Entonces, ¿cómo escalamos las cosas en la web? Simplemente añadimos transform scale three y luego el juego se ve así. Puede que tengas que entrecerrar un poco los ojos porque estoy presentando aquí en una pantalla grande, pero todos los colores están realmente desvaídos aquí. Ya no es pixel perfect cuando estoy haciendo zoom. ¿Lo ves? Y añadí como este pequeño efecto 3D al mapa para que parezcan como si estuvieran flotando en el aire. Y cuando haces eso, se desvanecen los colores cuando usas transform scale three.

Una de las grandes cosas es cuando tienes pixel art y quieres que las cosas se vean pixel perfect, hay una propiedad CSS llamada image rendering donde puedes decirle que debería verse pixelado, así que cuando se escala, la nitidez del pixel art se mantendrá igual. Sin embargo, todavía tenía colores desvaídos debido a ese problema que mencioné sobre la rotación 3D. Y me di cuenta de que una propiedad CSS no estándar de 25 años que fue construida para Internet Explorer es justo la solución. Y cada píxel es simplemente perfecto.

Construí una canalización de imágenes. Cada vez que hay un sprite y lo cambio o mi artista lo cambia, pasa por la canalización de imágenes para comprimir la imagen al tamaño más pequeño posible, y luego pensé, no quiero descargar 300 imágenes. Quiero descargar un archivo. Y, idealmente, puedo simplemente poner mis imágenes en un archivo CSS y codificarlas en base 64.

Y has visto todas esas pequeñas unidades que se mueven hacia arriba y hacia abajo. Esa es la animación de inactividad. Es como respirar. Todos ustedes se están moviendo mientras los observo. Y entonces lo que hice fue que tenía mi bonita canalización de renderizado de imágenes. Tenía un archivo CSS con todos los sprites dentro de ellos, y funcionaban genial en Chrome, pero luego abrí Safari, y de alguna manera estaba a 20 fotogramas por segundo o 15 fotogramas por segundo más lento que Chrome. Y me pregunté, ¿qué está pasando aquí? Y entonces me di cuenta de que si estás cambiando tus imágenes de fondo, como la posición, el tamaño, o con qué frecuencia se repite, si haces eso con bastante frecuencia y usas imágenes codificadas en Base64, que a menudo hacemos para pequeños iconos o algo así, Safari no lo tendrá en caché. Así que cuando Safari mira esa URL con una imagen codificada en Base64 directamente allí, es como cada 180 milisegundos en el juego, sería como, nunca he visto este arte en mi vida, nunca he visto esta unidad en mi vida, y luego simplemente va y decodifica toda esa cadena Base64 de nuevo. Así que no hay almacenamiento en caché allí.

Lo que hice como solución fue eliminar mi renderizado de imágenes, la canalización de procesamiento de imágenes, y simplemente volver a usar PNG normales. Otro fue que tengo una hija de cinco años, su nombre es Mia, y ella viene a mí bastante a menudo y me dice, oye, papá, ¿puedo trabajar en el juego contigo? Y así le di el editor de mapas. Y ella dijo, está bien, voy a poner una casa en cada campo. El mapa era más disperso. Así que tenía alrededor de 150 de esas entidades en él. No son tantas. No es un escenario real. Pero de alguna manera encontró un error. El juego se renderizaba a siete fotogramas por segundo después de que hizo eso. Y aprendí que hay filtros malos y filtros buenos. Se supone que la propiedad CSS filter está acelerada por GPU. Algunos de ellos lo están. No todos.

Viste antes cuando estaba explicando cómo esa sombra paralela alrededor de las unidades se está desvaneciendo solo un poco. La única manera de lograr eso es estableciendo una sombra paralela en todas ellas que sea transparente para que cuando cambies el color, se desvanezca. Porque si no lo configuras al principio y luego lo estableces en un color específico, no hará la transición. Todos ustedes han experimentado eso probablemente si están usando transiciones CSS en un elemento que simplemente se inserta en el DOM.

Puse cuatro de esas sombras paralelas en cada una de las entidades en el juego porque quería que fuera pixel perfect, no borrosas como normalmente son. Una a la izquierda, una arriba, una a la derecha y una abajo. Y eran transparentes porque están ahí por si necesito desvanecer ese contorno. Y me di cuenta de que aunque eran transparentes, la GPU estaba haciendo mucho trabajo y en lugar de 60fps, solo obtuve siete. Así que ten cuidado, incluso si alguien dice que esta propiedad está acelerada por GPU, algunas partes de ella podrían estarlo, no todas las partes. Así que brillo, saturación y escala de grises siempre están acelerados y son rápidos.

Un día, ni siquiera tenía un problema de rendimiento, así que no sé cómo sucedió esto, pero me desperté y vi esta cosa llamada will change. Y la descripción de la propiedad decía, así es como puedes decirle al navegador que omita algunas optimizaciones porque le estás diciendo al navegador qué propiedades CSS cambiarán. Y pensé, maldición, soy mucho más inteligente que los navegadores, sé exactamente qué va a cambiar. Y así lo puse, no lo evalué porque simplemente confié en lo que leí allí. Dos días después, me di cuenta, oh, tengo un problema de rendimiento de nuevo. Así que bisecté a través de mi historial. Y luego me di cuenta, está bien, en realidad no uses will change. Los navegadores son realmente inteligentes. Cuando leí esta página de documentación, hay una parte de esa página que no leí y esa es la parte roja.

Otro aprendizaje que hice es que deberías, ya sabes, o si quieres, por favor usa un FPS Meter. No quiero hacer ninguna declaración prescriptiva aquí. Puse un FPS Meter. Lo viste antes y idealmente estaba casi siempre a 60 FPS. Puedo mostrarte que esto está en vivo abriendo y cerrando y causando reflows. Sí, está en vivo. Lo que me di cuenta es que puse mi FPS Meter en el nivel superior de mi árbol de React y estaba mirando mi juego y estaba depurando algo y me preguntaba, ¿por qué mi juego se está re-renderizando cada segundo? No estoy haciendo nada. Y eso es porque mi FPS Meter estaba en el nivel superior de mi árbol de componentes. Así que mi recomendación es, usa un FPS Meter. Sé que hay uno dentro de Chrome. Tienes que habilitarlo.

Nunca lo miras. Si siempre está ahí en desarrollo, tal vez incluso en tu entorno de staging, y cae, sabrás inmediatamente que algo está mal. Y el consejo profesional aquí es ponerlo en un árbol de React separado en tu página para que no vuelva a renderizar el resto de tu aplicación real.

Una cosa que he aprendido es a hacer pruebas de rendimiento temprano pero solo optimizar lo que importa. Construí una IA desde cero para este juego basada en cómo jugaría el juego. No tengo absolutamente ninguna idea de cómo construir una IA. De alguna manera construí una IA. La construí usando programación funcional, estructuras de datos inmutables, y no hice pruebas de rendimiento. Parecía bien, parecía rápida, pero luego de alguna manera estaba jugando en el editor de mapas donde la IA se ejecuta localmente, no en un servidor, y mi juego se bloqueó por dos segundos, y pensé, ah, solo pondré un web worker en él y simplemente sacaré esto del hilo principal, pero luego comencé a medir el rendimiento, y me di cuenta de que si estás usando programación funcional para cosas que haces un millón de veces durante un turno de la IA, probablemente no sea una gran idea con JavaScript. JavaScript es rápido cuando se parece más a C y menos a un lenguaje de programación funcional. Así que hice pruebas de rendimiento, pero solo optimicé — hay otras partes lentas, pero optimicé la IA para que fuera aproximadamente 20 veces más rápida.

En términos de rendimiento de herramientas, viste que algunas de estas unidades, son las mismas para diferentes facciones, diferentes equipos, pero tienen diferentes colores, para que puedas distinguir entre ellas. Construí una pequeña biblioteca de intercambio de paletas, que no es en absoluto una gran implementación, pero funciona para mí. Y me di cuenta — cuando la hice open-source, primero tengo que decir, construí todo eso mientras cargaba un bebé. Y luego me di cuenta de que era muy lenta. Así que simplemente la miré y la reescribí para que fuera 23 veces más rápida. El aprendizaje aquí es simplemente que no confíes en alguien que hace open-source mientras carga un bebé dormido. Eso es algo que hice. Estoy tratando de hacer open-source tanto como pueda mientras avanzo en este viaje. Hay una cosa más. Como viste, toda esta presentación de diapositivas estaba usando MDX y construida específicamente para esta presentación. Así que justo hoy, hice open-source de re-MDX, que es el código exacto que estoy usando para esta presentación de diapositivas. Puedes revisarlo. Es muy minimalista. Por favor, haz un fork si hay una característica que te gustaría agregar. Pero eso es re-MDX. Si estás de acuerdo, te molestaré con otra cosa más. Así que comencé este proyecto hace un año y medio para meditar, para ver hasta dónde podía llegar. Para simplemente traer equilibrio a mi día. Así que en lugar de dormir, pasé cada noche codificando por una hora, tal vez dos.

A veces tal vez cuatro. Pero se sentía mejor que solo dormir, porque traía equilibrio a lo que estaba haciendo. Pero luego, con el tiempo, sentí que tenía algo. Es realmente divertido. Así que si le daba mi laptop a un amigo, o a alguien de mi familia, la robarían por una hora y jugarían el juego. Y luego perderían. Y luego querrían jugar de nuevo. Así que pensé, algunas personas quieren que este juego exista. Yo quiero que este juego exista. Y así es como comencé hace 22 años, cuando quería aprender programación para hacer video juegos.

Así que construí videojuegos y redes sociales. Pasé un montón de tiempo trabajando en una red social. Y entonces pensé, quiero volver a eso. Tal vez esto sea algo divertido de hacer. Y tal vez no funcione. Pero cuando sea viejo, no quiero arrepentirme de no haberlo hecho. Y así, la semana pasada anuncié que estoy comenzando una empresa, se llama Nakazawa Tech. Que es un estudio de juegos indie con sede en Japón, pero también una empresa de código abierto. Y estoy muy emocionado de anunciar, hay un nuevo editor de videojuegos llamado Null Games, que es súper amigable para los desarrolladores y está trabajando con juegos indie. Y acabamos de firmar una asociación. Y ellos publicarán Athena Crisis el próximo año.

¿Puedo decir simplemente Kristof, esta es la segunda conferencia en la que te veo este año, y tú siempre eres una persona increíblemente encantadora para estar cerca. Realmente, realmente disfruto de ti y de todo lo que haces. Y solo quiero decir, te aprecio, hombre. Aprecio todos los besos que recibo de ti en las conferencias. Sí, lo sé. Muy bien, genial. Así que tenemos un par de preguntas. Una pregunta, que no sé si sabes la respuesta a esto. ¿Cuánto tiempo has dedicado hasta ahora a todo esto? Sí.

Una hora y media todos los días durante los últimos 1.4 años. Así que si haces las cuentas, tendrás una respuesta. Sí. Sí. Tienes que hacer las cuentas tú mismo. Este hombre es un enigma.

¿Tienes formación en arte? ¿Creaste este pixel art tú mismo? Oh, bueno, quitamos las diapositivas en la última diapositiva. Di crédito a todos los artistas. Así que Nakazawa Tech está trabajando con seis artistas increíbles que están trabajando en el arte. Aprendí que soy un buen director de arte, no un buen artista. Puedo modificar lo que hacen, pero son increíbles. Y tengo suerte de tenerlos.

Sí. Entonces, una pregunta es, ¿por qué no construir un juego de esta manera? Quiero decir, obviamente ya has, ya sabes, como, ya sabes, hablado de muchas de las trampas de rendimiento y lo que sea, pero, como, ¿por qué es una mala idea? Sí. Sí. Creo que realmente es el rendimiento lo que, como, me está dando más dolores de cabeza donde estoy, como, genuinamente, como, asustado. Donde a veces las cosas son simplemente de repente lentas y estoy como, está bien, tal vez no sea tan inteligente hacer lo que estoy haciendo. Pero ya sabes, también es divertido llamarlo charla así, porque creo que lo llamé así antes de comenzar una empresa para hacer esto. Y como dije, era solo un proyecto de meditación. Y ahora tengo que cambiar para ser mucho más pragmático sobre realmente lanzarlo, lo cual es un poco de un cambio. Entonces, si hubieras, quiero decir, obviamente aquí, el viaje era el objetivo en sí mismo. Sí. Pero, como, si realmente hubieras decidido crear un juego de producción, ¿qué habrías hecho de manera diferente? Tal vez pregúntame en unos años. Tengo que tener algo de experiencia con, como, lo que podría hacer de una manera diferente. Sabes, lo bueno de esto y de usar un stack que conoces, es que puedes aprender mucho al descubrir todas las otras cosas que no sabes. Y si te lanzas a un nuevo stack, no sabes nada, y luego nunca llegas a esas cosas donde realmente estás aprendiendo algo. Así que creo que esa fue principalmente la razón por la que quería intentarlo de esta manera y ver hasta dónde puedo llegar.

Genial. ¿Qué biblioteca usaste para la interacción multijugador? Mencionaste Socket.IO, pero ¿hay algo más detrás de eso? No, no hay inteligencia. Solo mi propio código, que no usaría, que no me gusta usar.

Ojalá eso fuera algo que pudiera usar. Eso es mejor. Sí. ¿Cuánto pesaba ese bebé en ese momento? Seis kilos. Oh wow. Genial. Muy bien. Estas preguntas son tontas.

Muy bien. OK, aquí hay una pregunta que suena realmente inteligente pero podría ser una pregunta tonta. No sé nada sobre motores de juego. No sé si tenemos tiempo para eso. Quiero decir, puedo decir que ECS significa sistema de componentes de entidad. No, no lo hice. Solo uso JavaScript y mapa inmutable. Genial. Bueno, quiero decir, estas preguntas son demasiado tontas. No perdamos nuestro tiempo aquí. ¿Hay algo, ves algo en la pantalla que realmente quieras?

Oh sí. Quiero decir, nosotros, como, ya sabes, el último es bueno. Ahora, ¿cómo podrías publicar esto en otras plataformas? Oh, sí. Eso es divertido. Bueno, responde la pregunta entonces. Sí, primero que nada, puedes. Bueno, tengo que leer las preguntas, así que sabemos cuál es la pregunta. Podríamos al cambiar todo el renderizador para no usar CSS y el DOM, lo cual es tal vez mucho trabajo pero luego, ya sabes, hay ventajas y desventajas, ¿verdad? Lo que dije antes, creo que una de las verdaderas ventajas y, lo siento, tal vez fui un poco sarcástico sobre cómo no construir un videojuego, pero simplemente obtienes mucho al confiar en tecnologías web y el DOM y React y CSS. Obtienes todo eso gratis, mientras que otros motores de juego tienen problemas para soportar el juego en línea donde es como, ya sabes, si estás construyendo frontend, es como, ni siquiera sé cómo no hacerlo en línea, ¿sabes? Y así hay muchas cosas que obtienes de la plataforma web. Y si quisieras soportar algo fuera de la plataforma web, podrías tomar todo el motor y simplemente reemplazar el renderizador para renderizar a otra cosa. Sabes, es algo en lo que estoy pensando, pero no para la primera versión del juego. Muy bien. Creo que fue una gran respuesta para terminar. Todos, den un gran aplauso a Christoph.