Construyendo Juegos de Pensamiento en Equipo en Synthesis

Rate this content
Bookmark

La misión de Synthesis es crear una generación de supercolaboradores a través de juegos. Aprende cómo aprovechamos el poder de las bibliotecas de desarrollo de juegos de código abierto como Pixi.js y Colyseus para construir juegos multijugador de alta calidad que los niños disfrutan.

16 min
28 Sep, 2023

Video Summary and Transcription

La charla de hoy trata sobre la construcción de juegos de pensamiento en equipo en Synthesis, un programa de enriquecimiento que tiene como objetivo construir una generación de supercolaboradores. La idea clave es que el diseño es la principal restricción, no los gráficos ni la inteligencia artificial. Synthesis utiliza software de código abierto y desarrolla sus propias herramientas para el diseño de juegos y la conexión en red. La arquitectura de los juegos de Synthesis involucra un enfoque nativo del servidor y un modelo de autoridad del cliente para el movimiento. El enfoque modular permite una rápida iteración y flexibilidad en el desarrollo de juegos, e invertir en herramientas de canalización de contenido permite la creación de contenido fresco cada semana.

Available in English

1. Introducción a los juegos de pensamiento en equipo en Synthesis

Short description:

Hoy voy a hablar sobre la creación de juegos de pensamiento en equipo en Synthesis. Synthesis es un concepto que se explicará en un video rápido. El juego implica la toma de decisiones estratégicas y el trabajo en equipo.

Hola a todos. Mi nombre es Vivek Vidyasagaran. Y hoy voy a hablar sobre la creación de juegos de pensamiento en equipo en Synthesis. Así que, primero que nada, ¿qué es Synthesis? Y aquí hay un video rápido para explicar el concepto.

Dos. Uno. ¿A dónde vamos chicos? Necesito que todos estén aquí. Esperen chicos, creo que sé lo que está pasando. No se trata de la longitud de la línea, sino de la ruta más rápida para volver al planeta. ¿Cuál es tu idea, Tag? Sí, describiría el púrpura. Tiene el beneficio estratégico más grande para nosotros. Oh sí, sí, sí. Haruun tuvo una idea increíble. Oh Dios mío. Este es el mejor lugar para Tag. Vamos muy rápido. Queríamos correr un riesgo extremo o queríamos jugar seguro. Phoenix bloquea la flecha. Vamos Phoenix. Adelante. La cadena está funcionando. La cadena. Adelante. Adelante. Oh, esto va bien. Sí, sí. Sí. Tristan, Tristan. ¿Qué estás haciendo? Oh Dios mío, eso es suerte. Somos los primeros.

2. Introducción a los juegos de Synthesis

Short description:

Lo estamos haciendo muy bien en esto. Synthesis es un programa de enriquecimiento para niños, con el objetivo de construir una generación de supercolaboradores. Tenemos una amplia variedad de juegos en producción, incluyendo juegos deportivos y de construcción de ciudades. Para construir los mejores juegos, hemos establecido restricciones de diseño que aseguran que cada jugador tenga un impacto, la colaboración multiplique el impacto y los jugadores puedan tomar decisiones complejas. La idea clave es que el diseño es la restricción principal, no los gráficos o la IA.

Lo estamos haciendo muy bien en esto. Hola, Rahat. Hola, hola. Hay otros invasores. Otros invasores. ¿Qué? ¡No! No, deberíamos volver todo el camino atrás. Oh sí, cuando lleguemos aquí. Sí. Esto va a ser increíble. Oh sí, esto es genial. Tenemos a este mocoso, chicos. Tenemos esto, chicos. Vamos a ganar esto. Y esto no es una escuela, es mejor que una escuela. Genial.

Entonces, eso es Synthesis. Esencialmente, es un programa de enriquecimiento para niños. Y como viste allí, todos están jugando juntos y aprendiendo sobre trabajo en equipo, colaboración y cosas así. En pocas palabras, lo que estamos tratando de hacer es construir una generación de supercolaboradores. Estas son personas que pueden trabajar juntas en un equipo y lograr resultados realmente buenos.

Estos son algunos de los juegos que tenemos en producción en este momento. Puedes ver que es una amplia variedad de géneros y estilos de juego. Tenemos juegos deportivos, tenemos juegos de construcción de ciudades. Y por lo tanto, necesitamos un marco que pueda construir todo esto rápidamente. Cuando construimos el estudio de juegos de Synthesis y hablamos sobre en qué queremos enfocarnos nos dimos cuenta de que nuestro producto es único y que necesitamos un conjunto específico de restricciones de diseño para poder construir los mejores juegos.

Así que llegamos a estos principios. Asegurarse de que cada jugador tenga un impacto, la colaboración multiplique ese impacto, permitir a los jugadores tomar decisiones complejas y consecuentes, proporcionar oportunidades para reflexionar e iterar, y equilibrar cuidadosamente la mente, la boca y las manos de cada jugador. Puedes ver que estas son principalmente restricciones de design. Y esa fue una idea clave que tuvimos, que lo que realmente nos limita aquí es el design. No estamos tratando de hacer los juegos más gráficamente complejos o agregar una IA muy potente o algo por el estilo.

3. Iteraciones y Optimización del Diseño de Juegos

Short description:

Queremos crear juegos que cumplan nuestros objetivos de aprendizaje y sean divertidos. Un ejemplo es nuestro primer juego con el que lanzamos la compañía. Lo rediseñamos con nuevas mecánicas y muchas iteraciones en el diseño del juego. Nuestro objetivo es optimizar las iteraciones del diseño de juegos.

Simplemente queremos crear juegos que cumplan nuestros objetivos de aprendizaje y sean divertidos. Como ejemplo, este es uno de nuestros primeros juegos con los que lanzamos la compañía. Y puedes ver que es bastante simple. Y luego, una vez que establecimos estos principios y rediseñamos el juego con eso en mente, obtuvimos Proxima v2. Entonces puedes ver, visualmente, obviamente, se ve mucho mejor. Pero realmente, lo que fue realmente diferente entre estos dos juegos son todas las mecánicas y cosas que sucedieron detrás de él. Y hubo períodos de meses en los que cada dos semanas, estábamos como creando nuevos sistemas, probándolos, verificando que funcionen y eliminando otros sistemas. Básicamente, hubo muchas iteraciones en el diseño del juego. Y ese es el enfoque del estudio. Nuestro objetivo principal es optimizar las iteraciones del diseño de juegos.

4. Herramientas para Desarrolladores y Arquitectura de Software

Short description:

Confiamos en software de código abierto como Kubernetes, Corsius y Pixie para el diseño de juegos y la conexión en red. También desarrollamos nuestras propias herramientas, como Play para el emparejamiento y Synthesis A V para la comunicación de audio y video. Nuestros equipos de ingeniería brindan flexibilidad en la selección de equipos y cambios durante el juego. En cuanto a la arquitectura de software, utilizamos una arquitectura nativa del servidor para los juegos multijugador. Los clientes envían la entrada del usuario al servidor, donde se aplica la lógica para actualizar el estado del juego. El estado actualizado se envía luego a todos los clientes para la sincronización.

Y lo hacemos en tres áreas principales: herramientas para desarrolladores, arquitectura de software y creación de contenido. Veamos cada una de ellas con más detalle.

Comencemos con las herramientas para desarrolladores. En primer lugar, sería negligente si no mencionara algunos de los increíbles software de código abierto en los que confiamos. Obviamente, hay cosas regulares que todas las compañías de software usan hoy en día, como Kubernetes y otras cosas. Pero en cuanto al diseño del juego y su aspecto, estas dos herramientas, Corsius y Pixie, nos han sido de gran ayuda. Corsius es una red multijugador y Pixie es una biblioteca gráfica que utilizamos para renderizar nuestros juegos. Dependemos mucho de estas herramientas de terceros, pero también hemos estado desarrollando estratégicamente nuestras propias herramientas donde sentimos que necesitamos más flexibilidad. Por ejemplo, Play es una herramienta para el emparejamiento, los lobbies y también tenemos servicios de amigos. Esto nos brinda mucha flexibilidad para poder juntar a los niños adecuados para que todos se diviertan y nadie se sienta excluido, entre otras cosas. También hemos construido nuestra propia versión de Zoom, básicamente, el sistema de audio y video, que llamamos Synthesis A V, y eso es lo que se muestra aquí a la derecha. Así que puedes ver que mientras juegan, también pueden interactuar con sus amigos y compañeros de equipo y planificar qué deben hacer a continuación, entre otras cosas. Construir estas cosas nosotros mismos le da a los juegos mucha flexibilidad para decidir qué equipos deben ir juntos y cambiar los equipos a mitad del juego, entre otras cosas. Ha sido muy útil contar con equipos de ingeniería que puedan desarrollar todo esto y que los juegos puedan... Y que puedan soportar los juegos.

Esa es la parte de las herramientas para desarrolladores, ahora veamos la arquitectura de software. Básicamente, en cuanto a la arquitectura multijugador, seguimos una arquitectura nativa del servidor, que es bastante común en los juegos. Y para aquellos que no lo sepan, aquí hay una breve introducción, pero básicamente tienes todos estos clientes que están conectados a algún servidor. Y cuando recibes alguna entrada del usuario a través del teclado o el mouse, el cliente... Básicamente, la idea aquí es que el cliente es un cliente muy ligero, por lo que no realiza demasiada lógica. Simplemente toma tu entrada y la envía directamente al servidor. Y luego en el servidor se ejecutan estos sistemas, que explicaré en un momento. Pero básicamente es toda la lógica para actualizar algo. Por ejemplo, supongamos que quieres mover la nave espacial hacia adelante, entonces presionarías la tecla de flecha hacia arriba en tu teclado, y el cliente simplemente lo enviaría al servidor. Y luego el servidor realmente movería la nave espacial y también decidiría si colisionó con algo. Entonces, si la nave espacial estuviera justo al lado de un planeta o algo así, se produciría esa colisión, se decidiría qué le sucede al planeta y a la nave espacial, y luego se resolvería eso. Y luego ese nuevo estado se pasa a todos los clientes para que todos estén sincronizados y podamos seguir adelante. Este ciclo se repite una y otra vez. Y esa es la idea principal de la conexión en red autoritativa del servidor. Pero hay algunos casos en los que no queremos eso, como por ejemplo, el movimiento de la nave espacial.

5. Arquitectura Cliente y Servidor

Short description:

Cuando presionas una tecla, necesita llegar hasta el servidor y regresar, lo cual es demasiado lento para el movimiento. En esos casos, utilizamos un modelo de autoridad del cliente para actualizar el estado local y mostrar un movimiento inmediato. Luego, el nuevo estado se envía al servidor y se pasa a todos los clientes para la sincronización. Intentamos mantenerlo con autoridad del servidor para simplificar la arquitectura. El estado del juego se captura en una clase llamada 'state', que contiene todo y se sincroniza entre el servidor y los clientes. Las naves espaciales tienen sus propias clases con datos como posición y velocidad. Los sistemas manejan el código de actualización en el servidor, resolviendo los cambios del fotograma anterior. En el lado del cliente, tenemos el manejo de entrada utilizando una declaración de caso de cambio para las entradas del teclado.

El problema aquí es que cuando presionas una tecla, necesita llegar hasta el servidor y hacer algo y luego regresar, y solo entonces puedes ver ese cambio en tu pantalla. Así que eso es demasiado lento, especialmente para algo como el movimiento. Por lo tanto, en esos casos, en realidad utilizamos un modelo de autoridad del cliente, donde cuando tienes la entrada, actualizamos el estado local que tiene el cliente y también lo mostramos así. Así que se siente como si se moviera inmediatamente. Y luego enviamos ese nuevo estado al servidor. Y el servidor no es tan pesado aquí, porque todo lo que necesita hacer es tomar ese estado y pasarlo a todos los demás clientes para que todos estén sincronizados. Así que usamos ambos modos. Solo usamos el modo de autoridad del cliente cuando necesitamos que algo responda rápidamente. Por lo tanto, en la medida de lo posible, intentamos mantenerlo con autoridad del servidor. Y eso en realidad nos ayuda a simplificar la complejidad de la architecture. Y te mostraré cómo funciona. Entonces sí, esta es la única sección con un poco de código. Así que ten paciencia. El código es bastante simple. Solo estoy aquí para explicar ese diagrama que te mostré. Así que solo intento mostrar el estado del juego aquí. Lo interesante de esta architecture es que tienes este único estado que captura todo sobre tu juego. Entonces, en este caso, todos los equipos, todos los jugadores, planetas, naves espaciales, todo lo que le importa al juego está en esta gran clase llamada 'state'. Y contiene todo. Y esto solo necesita sincronizarse entre el servidor y los clientes. Dentro de esto, si miras las naves espaciales, por ejemplo, son solo más clases con más data. Entonces, en este caso, son todas las cosas que esperarías que tenga una nave espacial. Así que tenemos posición, velocidad, el equipo al que pertenece, etc. Y los sistemas son como el código de actualización. Entonces aquí tenemos un montón de sistemas. Y en cada fotograma, básicamente ejecutamos estos sistemas para resolver cualquier cambio que haya ocurrido durante el fotograma anterior. Aquí es donde realmente se encuentra toda la lógica en el servidor. Y en el lado del cliente, solo tenemos dos cosas. Como mencioné, tenemos el manejo de entrada y solo puse este código aquí para mostrar lo sencillo que es. Esto es literalmente una declaración de caso de cambio para todas las entradas de tu teclado.

6. Lógica del Juego, Renderizado y Oferta de Contenido

Short description:

En este caso, el cliente envía instrucciones al servidor basadas en las teclas presionadas. El servidor maneja la lógica del juego, como la construcción de estructuras y la gestión de recursos. En el lado del cliente, el renderizado y la actualización de texto se realizan a través de listeners. Agregar nuevos elementos al juego, como meteoritos, solo requiere cambios en tres áreas: agregar la clase al estado del juego, implementar el sistema y renderizar el elemento. Este enfoque modular permite una iteración rápida y flexibilidad. Los juegos de Synthesis funcionan como una plataforma con contenido personalizable.

En este caso, los números son el número de teclas 1, 2, 3. Y en cada caso, simplemente enviamos alguna instrucción al servidor. Entonces, si presionan 1, construye un extractor. Si presionan 2, una base. Y si presionan 3, una mina. Entonces, esto es todo lo que el cliente necesita hacer. El resto de su código es como, ¿pueden construir una base? ¿Tienen suficientes recursos para construir una base? Todas esas cosas suceden en el servidor. Y luego, el otro lado del cliente es el renderizado. Básicamente, cuando inicializas el cliente, ejecutamos esta función de renderizado para cada objeto. Y así configuramos todos los sprites, que básicamente son solo imágenes a través de PNG aquí. Y luego también configuramos estos listeners, que es el patrón que sigue Coliseus. Entonces, básicamente, cuando configuramos la nave espacial, estamos escuchando cualquier cambio en los puntos de acción. Y si hay algún cambio, inmediatamente se activaría esta función. Y simplemente cambiaríamos el texto para reflejar ese nuevo cambio. Así que es muy simple, al menos lógicamente, cuando intentas pensarlo.

Entonces, como ejemplo, imaginemos que queremos agregar meteoritos o algo así a este juego, porque no puedes tener un juego espacial sin meteoritos, ¿verdad? ¿Cómo lo haríamos? Realmente solo necesitamos cambiar el código en tres lugares. El primero, queremos agregar la clase de meteorito al estado del juego. Y luego queremos implementar el sistema de meteoritos. Entonces aquí es donde realmente pondrías el código de cómo se mueve el meteorito, y qué sucede cuando golpea un planeta, cosas así. Y luego queremos agregar la función renderMeteor en el código del cliente para renderizar este meteorito. Así que las imágenes y la animación y cosas que van con eso. Entonces puedes ver, es muy simple. Y esto es realmente lo que nos permite poder sacar elementos del juego y luego agregar cosas y cosas muy rápidamente, porque todo es tan modular. Así que eso es la architecture de software. Ahora pasemos a la oferta de contenido. La forma en que se crean los juegos en Synthesis, es casi como una plataforma. Y luego tienes todo este contenido que se puede agregar encima. Y eso es lo que nos da mucha flexibilidad. Así que podemos hacer nuevos mapas, hacer nuevo contenido cada semana.

7. Herramientas de la canalización de contenido y configuración del juego

Short description:

Invertir en herramientas de la canalización de contenido nos permite crear contenido fresco cada semana. Utilizamos Google Sheets para la creación de mapas, lo que proporciona flexibilidad para cambiar varios aspectos del mapa. Los diseñadores pueden trabajar en Google Sheets y exportar los datos a JSON para realizar pruebas. El esquema de configuración establece la configuración del juego y se puede instanciar rápidamente con nuevos datos. Esta optimización nos permite crear una amplia variedad de experiencias de juego y construir los mejores juegos de pensamiento en equipo del mundo.

Y así los niños tienen una experiencia fresca cada semana. Y la forma en que podemos hacer tanto contenido es invirtiendo realmente en las herramientas de la canalización de contenido.

Así que aquí, por ejemplo, esto es en realidad solo Google Sheets. Y esto es lo que usamos para hacer mapas para Proxima. Así que puedes ver que es solo una gran tabla. Y tenemos todos estos fragmentos de código, supongo, que usamos para especificar qué debería haber en el mapa. Y verás, hay mucha flexibilidad aquí. Podemos cambiar muchas cosas sobre el mapa.

Y lo genial aquí es que la persona que diseña estos mapas no necesita saber nada de código. Simplemente trabajan en Google Sheets y luego lo exportan a JSON, que luego se coloca en el juego. Y luego puedes probar el nuevo mapa allí. Así que podemos generar muchos mapas incluso en el transcurso de un solo día.

Y luego el otro lado de eso es el esquema de configuración. Así es como se configuran todas las opciones junto con el mapa que establece un juego. Así que aquí, por ejemplo, esto es para Proxima. Puedes ver que tenemos este campo de mapa personalizado. Básicamente, todo lo que hiciste en esa hoja de cálculo de Google, simplemente copiarías todo ese JSON aquí. Y simplemente instanciaría tu juego con estos nuevos data. Así que es muy rápido de probar. Es muy rápido de instanciar un juego, incluso en producción real también. Y en este lado, tengo el esquema de configuración para otro juego llamado Constellation. Y aquí, ofrecemos mucha más flexibilidad en las cosas que puedes cambiar. Por ejemplo, el tiempo que tienes para colocar las sedes centrales o la profundidad del acero o el número de aceros. Esto realmente cambia el juego significativamente al cambiar estos números. Así que podemos obtener mucho más juego de un solo juego.

Sí, en resumen, todo esto lo hacemos para optimizar las iteraciones de design de juegos. Y la razón por la que queremos hacer eso es porque queremos construir los mejores juegos de pensamiento en equipo del mundo. Y la razón por la que queremos hacer eso es porque queremos construir una generación de super colaboradores. Eso es lo que hacemos aquí en Synthesis. Muchas gracias. Puedes obtener más información visitando Synthesis.com. Mi nombre es Vivek Vidyasagran y puedes encontrarme aquí en Twitter, RX. Sí, gracias. ♪♪ ♪♪

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Building Fun Experiments with WebXR & Babylon.js
Top Content
During this session, we’ll see a couple of demos of what you can do using WebXR, with Babylon.js. From VR audio experiments, to casual gaming in VR on an arcade machine up to more serious usage to create new ways of collaboration using either AR or VR, you should have a pretty good understanding of what you can do today.
Check the article as well to see the full content including code samples: article. 

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
116 min
Make a Game With PlayCanvas in 2 Hours
Featured WorkshopFree
In this workshop, we’ll build a game using the PlayCanvas WebGL engine from start to finish. From development to publishing, we’ll cover the most crucial features such as scripting, UI creation and much more.
Table of the content:- Introduction- Intro to PlayCanvas- What we will be building- Adding a character model and animation- Making the character move with scripts- 'Fake' running- Adding obstacles- Detecting collisions- Adding a score counter- Game over and restarting- Wrap up!- Questions
Workshop levelFamiliarity with game engines and game development aspects is recommended, but not required.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
JS GameDev Summit 2022JS GameDev Summit 2022
121 min
PlayCanvas End-to-End : the quick version
Top Content
WorkshopFree
In this workshop, we’ll build a complete game using the PlayCanvas engine while learning the best practices for project management. From development to publishing, we’ll cover the most crucial features such as asset management, scripting, audio, debugging, and much more.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)