Hacer juegos casuales se ha vuelto más fácil que nunca, pero configurar el modo multijugador todavía requiere que escribas código de red, manejes websockets, equilibres la carga de servidores, coloques servidores y demás.
Estoy construyendo Playroom para resolver esto, una sincronización de alto rendimiento que maneja la conexión en red y la gestión de las salas para que puedas concentrarte en construir tu juego.
This talk has been presented at JS GameDev Summit 2023, check out the latest edition of this JavaScript Conference.
FAQ
Asad Nehman es un desarrollador con más de 10 años de experiencia en la creación de herramientas para desarrolladores y fundador de una empresa de IDE en línea. Además, tiene un interés particular en el desarrollo de juegos multijugador.
Los desafíos incluyen la gestión de conexiones de múltiples jugadores, almacenamiento de estados de juego en un backend, sincronización de estados entre jugadores, y problemas de escalabilidad y latencia al alojar juegos en servidores distribuidos globalmente.
Existen plataformas como Photon de Unity, Hathora, Revit y Snapser que ofrecen servicios de alojamiento y gestión de servidores de juegos. También se puede utilizar Firebase para juegos más simples.
Playroom es un marco de trabajo que gestiona automáticamente el sistema de lobby, perfiles de jugadores y la sincronización de estados del juego, permitiendo a los desarrolladores concentrarse únicamente en la lógica del juego sin preocuparse por el código de servidor.
Playroom utiliza Cloud Play y DurableObjects para garantizar una baja latencia y un almacenamiento consistente a nivel global, optimizando así la experiencia del jugador en diferentes ubicaciones geográficas.
Playroom ofrece interfaces para que los jugadores elijan avatares, colores y nombres, permitiendo así una personalización completa y diferenciación entre jugadores dentro del juego.
Asad Nehman analiza los desafíos de crear juegos multijugador y sugiere formas de simplificar el proceso. Destaca la necesidad de un backend, como un servidor Node.js con Socket.io, para manejar las conexiones de los jugadores. Se introducen las salas para conectar a los jugadores y sus amigos, permitiendo la comunicación dentro de cada sala. Opciones de alojamiento como AWS EC2, Vercel y Netlify pueden ayudar a escalar el juego a nivel global. El marco de Playroom elimina la necesidad de código de servidor, sistemas de lobby y gestión de perfiles de jugadores.
1. Introducción a la Creación de Juegos Multijugador
Short description:
Asad Nehman habla sobre los desafíos de crear juegos multijugador y sugiere formas de simplificar el proceso. Destaca la necesidad de un backend, como un servidor Node.js con Socket.io, para manejar las conexiones de los jugadores. Se introducen las salas para conectar a los jugadores y sus amigos, permitiendo la comunicación dentro de cada sala. Los códigos de sala se utilizan como identificadores de canal únicos para la comunicación, incluyendo el estado y la posición del jugador. Se necesita una interfaz de lobby para compartir los códigos de sala, permitiendo que los jugadores se unan a la misma sala. Las opciones de personalización, como avatares y colores, ayudan a diferenciar entre los jugadores.
Hola a todos, soy Asad Nehman. Voy a hablar sobre por qué es tan difícil crear juegos multijugador y qué podemos hacer para facilitarlo. Un poco de lo que quiero decir. Soy un desarrollador. Hago cosas. Específicamente, me gusta crear herramientas para desarrolladores y lo he estado haciendo durante más de 10 años. También fundé una empresa de IDE en línea en el pasado. También me gusta jugar juegos multijugador con mis amigos. Así que naturalmente me gusta hacer juegos multijugador. Digamos que quiero hacer un juego multijugador. Comencemos con el juego multijugador más simple y veamos qué desafíos enfrentamos. Lo primero que probablemente quieras hacer es obtener un juego de un solo jugador base, que luego convertirás en un juego multijugador. Este juego base probablemente tendrá un bucle de juego con él, y las partes multijugador pueden ser agregar más jugadores y alguna lógica al respecto, algunas competiciones y cosas así. Y lo primero que probablemente harías para convertir esto en un juego multijugador es agregar un backend a él. Y en el contexto de los juegos web, esto suele ser un servidor Node.js con algún tipo de framework de web socket como Socket.io. Entonces, probablemente quieras manejar las conexiones de los jugadores y almacenar esos jugadores en una matriz global dentro de tu aplicación Node.js, y de esta manera todos los jugadores pueden conectarse entre sí utilizando este backend de web socket, y esto funciona. Pero pronto te das cuenta de que también necesitas tener algún concepto de Salas en tu juego, en tu servidor. Entonces, lo que harían las Salas es asignar algún código de sala a algunos jugadores y lo que esto te permite hacer es conectar a cada jugador y a sus amigos entre sí. Entonces, todos los jugadores en todos tus juegos no están en la misma sala. Están en sus propias salas y las salas pueden comenzar y terminar en sus propios tiempos dependiendo de cuándo comiencen sus juegos. Así que suena como que estos dos jugadores están en sus propias salas y estos dos jugadores están en sus propias salas y solo pueden comunicarse dentro de sus propias salas. No pueden comunicarse con los jugadores de otras salas. Bastante simple. Y sí. Pueden usar este código de sala como un identificador de canal único a través del cual pueden comunicarse entre sí. La comunicación puede ser el estado del jugador y la posición del jugador, puntuaciones, todas esas cosas. Ahora, necesitas... Una vez que introduces los códigos de sala, necesitas una forma de compartir estos códigos de sala con otros jugadores. Esto puede ser algún tipo de interfaz de lobby que necesitas crear. La interfaz de lobby puede ser que el anfitrión inicie el juego, comparta el código de sala, enlace de sala, código QR con otros jugadores, y ese código QR o enlace de sala tendrá el ID de la sala incrustado en él, y cuando el otro jugador abra esta URL, se conectará automáticamente a la misma sala, y de esta manera pueden comunicarse entre sí. También necesitas alguna forma, alguna interfaz de usuario para permitir a los jugadores elegir sus avatares, sus colores, sus nombres, para tener alguna personalización, y para que puedan diferenciarse
2. Transmitiendo el Estado del Juego y Desplegando Servidores
Short description:
Una vez que tienes la transmisión y sincronización del estado del juego en su lugar, necesitas desplegar tu juego. Opciones de alojamiento como AWS EC2, Vercel y Netlify pueden ayudarte a escalar tu juego a nivel global. Sin embargo, surge un desafío cuando tus servidores están aislados y los jugadores conectados a diferentes servidores no pueden interactuar. Para resolver esto, necesitas conectar los servidores a una base de datos central como Redis y desplegarlos en todo el mundo para una baja latencia.
entre los jugadores. Sí, y una vez que tienes eso, creas tu juego. Tu juego es esencialmente, transmites el estado del juego a los jugadores, y los jugadores transmiten su propio estado a los demás jugadores, y tu trabajo como creador de juegos es combinar esos estados, actualizaciones, y consumirlos, guardarlos localmente. Por ejemplo, un jugador puede moverse y compartir la posición al servidor WebSocket, y los otros jugadores pueden leer esa posición y actualizar al jugador en su propia pantalla, y viceversa. Entonces, básicamente lo que estás haciendo es mantener estas variables globales propias, que deseas sincronizar entre todos los jugadores. Y la mayor parte del código de red involucrado sería asegurarse de que estos estados estén sincronizados. Una vez que tienes eso, tienes un juego simple. Ahora, no puedes simplemente compartir este juego sin desplegarlo en algún lugar. Para desplegarlo, necesitas algún lugar para alojar este juego. Esto puede ser una instancia de AWS EC2, lo cual recomendaría. Puedes usar algún servicio como Vercel, Netlify, y lo que pueden hacer es alojar tu juego, escalar tu juego a nivel global, tener múltiples instancias ejecutándose de tu juego basado en el tráfico que llega a tu juego y una vez que eso sucede, te das cuenta del problema principal aquí.
3. Conexión de Servidores y Uso de Soluciones Alternativas
Short description:
Tus servidores están aislados, pero puedes conectarlos a una base de datos central como Redis para sincronizar los estados de las salas y las listas de jugadores. Desplegar servidores y réplicas de bases de datos en todo el mundo garantiza una baja latencia para los jugadores. En lugar de gestionar clústeres y bases de datos, considera utilizar soluciones alternativas como Photon o netcode de Unity, o servicios de alojamiento de servidores de juegos como Hathora, Revit y Snapser. Firebase también se puede utilizar como backend para juegos simples y no arcade. Además, es necesario implementar conexiones punto a punto.
El problema es que tus servidores están aislados. Supongamos que estoy conectado al servidor A aquí y uso algún código de sala para conectarme al servidor y comparto ese código de sala con mi otro amigo que está conectado al servidor B. Y ellos intentan usar el mismo código de sala pero no me ven. Eso se debe a que el servidor A y B no están interconectados entre sí. Por lo tanto, el estado que mantienen, bueno, los estados de las salas, la lista de salas que mantienen, no es la misma porque se ejecutan en un proceso completamente separado en todo el mundo. Y para resolver esto, lo que necesitas es básicamente conectarlos a una base de datos central, tal vez. Supongamos que los conectas a una base de datos. Redis es una buena opción para hacer esto. Entonces, Redis puede actuar como el backend del backend, que luego almacena todas las salas, los estados y las listas de jugadores y todo. Y todos estos servidores simplemente se sincronizan con esa base de datos central, Redis en este caso. Pero también necesitas desplegar este par de servidor y base de datos en todo el mundo porque tus usuarios pueden conectarse desde lejos y no deberían experimentar retraso en su juego. Entonces, lo que quieres es desplegar servidores cerca de ellos y también quieres desplegar la réplica de la base de datos cerca de ellos. Así que no ven retraso. Comienzas desarrollando un juego, pero ahora estás gestionando tu clúster y bases de datos. Eso no es lo que quieres hacer. Y cada desarrollador de juegos se enfrenta a una versión de esto al hacer juegos multijugador. Eso es mucho trabajo duplicado. No quieren gestionar todos estos servidores. Solo quieren hacer el juego. Afortunadamente, hay algunas alternativas mejores que simplemente escribir tu propio servidor. Por ejemplo, Unity tiene Photon o netcode para objetos de juego. Hay servicios como Hathora, Revit, Snapser que alojan un servidor de juegos para ti. Entonces, solo les das el código del servidor y ellos lo alojan por ti. También puedes usar Firebase como backend para juegos. Esto puede ser útil para juegos simples, juegos no arcade y juegos de fiesta. Estas opciones son geniales. Al menos son mejores que lo que hablamos antes. Pero aún así, tienes que escribir un montón de código no relacionado con el juego y código de servidor backend. También debemos hablar sobre otro código no relacionado con el juego que probablemente necesitarás hacer. Que es averiguar las conexiones punto a punto.
4. Simplificando la Configuración del Juego con Playroom
Short description:
La mensajería directa de jugador a jugador reduce la latencia en juegos de ritmo rápido. La predicción del lado del cliente garantiza un movimiento fluido del jugador durante las actualizaciones. Los estudios de juegos gastan tiempo y dinero excesivos en código no relacionado con el juego. El marco de Playroom elimina la necesidad de código de servidor, sistemas de lobby y gestión de perfiles de jugadores. Proporciona una variable global para sincronizar el estado de la sala entre todos los jugadores. Playroom simplifica la configuración del juego, incluyendo las conexiones del lobby y las invitaciones de los jugadores. La lógica del juego maneja automáticamente la entrada y salida de jugadores y las actualizaciones del estado del juego.
Las conexiones punto a punto. Por lo tanto, los mensajes no se envían a un servidor, en su lugar se envían directamente al otro jugador, lo que reduce la latencia para ti. Esto es absolutamente necesario para juegos de ritmo rápido. Probablemente también quieras agregar soporte para Gamepad para que los jugadores puedan jugar localmente, en pantalla dividida o en la televisión. También querrás hacer algún tipo de predicción del lado del cliente para los movimientos de los jugadores. Porque mientras se envía esta actualización, por ejemplo, para una posición a ese jugador, ese jugador no debería quedarse atascado en el espacio. Debería ver alguna forma de predicción sucediendo. Entonces, el jugador se mueve suavemente al siguiente paso.
Entonces, hablamos con algunos estudios de juegos sobre su opinión sobre lo que proporciona la infraestructura actual y cómo se sienten al respecto. Y vimos un patrón común de que están gastando mucho tiempo y dinero en hacer estos juegos multijugador. Y sí, no debería ser así. Debería ser así. Entonces, repensemos cómo sería si no tuvieras que lidiar con ningún código no relacionado con el juego en tus juegos. Eso significaría simplemente no escribir ningún código de servidor en absoluto. Y sí, tampoco quieres escribir tu propio sistema de lobby y interfaces de usuario y gestionar perfiles de jugadores y todas esas cosas. ¿Qué tal si solo llamas a una función y te da la lista de jugadores en esta sala actual y simplemente comienza un juego con esa lista de jugadores? Y no tienes que preocuparte por todas las conexiones del lobby, los códigos QR, el estado de la sala, qué estado de la sala quieres sincronizar. Es solo una variable global a la que puedes establecer y obtener y se sincronizará automáticamente entre todos los jugadores en esta sala, por lo que no tienes que preocuparte por cómo obtener este estado del dispositivo A al dispositivo B. Por ejemplo, establezco el estado PUNTUACIÓN3 en el dispositivo A en el jugador A, y luego puedo intentar obtener la puntuación en otro dispositivo y obtener el estado actualizado aquí. Esa es la premisa detrás del marco llamado Playroom en el que estoy trabajando. Sí, veamos cómo funciona. Entonces, primero que nada, para usar Playroom lo que quieres hacer es instalar playroom-get y después de hacer eso llamas a esta función init() que llamamos insertCoin. Esto le dice a Playroom que comience, esto le dice a Playroom que inicie el sistema de lobby para que muestre la interfaz de lobby y desde allí maneja automáticamente toda la creación, unión, perfiles de jugadores y que los jugadores elijan sus propios colores y avatares y todas esas cosas. ¿Cómo? Veamos. Entonces, cuando llamas a insertCoin, el jugador ve esta interfaz de pantalla completa que llamamos la interfaz de lobby y los jugadores pueden, como dije, elegir sus avatares y colores y todo y también pueden invitar a otros jugadores para que puedan compartir el enlace a tu juego con esa URL única o simplemente el otro jugador puede escanear este código QR para unirse a la misma sala. Y el siguiente paso que quieres hacer es escribir una lógica de juego para que los jugadores se unan al juego y abandonen el juego. Entonces, por ejemplo, cuando un jugador se une al juego probablemente quieras agregar algún sprite para ellos en la escena y cuando se van quieres eliminar ese sprite de la escena. Y eso es unirse y abandonar el juego. La otra cosa que quieres manejar es el estado del juego en sí. Entonces, digamos que quieres tomar alguna entrada, hacer algún cálculo y actualizar la posición del jugador y una vez que hagas eso, los otros jugadores verán automáticamente esa nueva posición y actualizarán la posición del jugador.
5. Playroom Backend y Ciclo de Vida de Roles
Short description:
Puedes configurar y obtener fácilmente posiciones, entrada de jugadores, salud, puntuación, ganador y clasificaciones utilizando las funciones de Playroom sin escribir ningún código de servidor. Playroom se basa en Cloud Play y DurableObjects para su backend, proporcionando almacenamiento de baja latencia en todo el mundo. El ciclo de vida de un rol implica crear una nueva sala para el primer jugador, conectar a otros jugadores a través de una URL única y gestionar el estado del juego. Playroom mantiene dos tipos de conexiones: un socket TCP confiable a través de los servidores de Playroom y una conexión UDP o WebRTC no confiable entre los jugadores. Este último es adecuado para estados como las posiciones de los jugadores.
En tu pantalla. Y esto sucede automáticamente. Solo tienes que configurar y obtener posiciones de las funciones de Playroom y esto es válido para las posiciones de los jugadores, la entrada, la salud, la puntuación, quién es el ganador, las clasificaciones y todas esas cosas. Y nuevamente, nunca escribiste ningún código de servidor para esto, solo instalas esto con npm e inicias en Playroom y luego estás configurando y obteniendo el estado. Eso es todo. Entonces, ¿cómo funciona esto detrás de escena? Supongo que el mayor secreto aquí es Cloud Play y DurableObjects. Cloud Play tiene nodos adicionales en todo el mundo y probablemente también tenga nodos adicionales dentro de tu ISP. Por lo general, estos están a unos 50 ms de distancia en términos de latencia. Y la otra cosa es DurableObjects, que es como un sistema de almacenamiento que Cloud Play proporciona y que te permite tener un almacenamiento consistente y de baja latencia en cualquier parte del mundo. Sí, eso es como el backend de Playroom.
Y repasemos el ciclo de vida de un rol. Cuando el primer jugador inicia un juego y el juego llama a insertCoin, lo que hace Playroom es mostrar la interfaz de CRM para el lobby y el perfil y todo. Y detrás de escena, Playroom crea una nueva sala para ellos y se conectan a esta sala. Y cuando comparten esta URL única con otros jugadores, ellos también se unen a la misma sala. Y luego, cuando el anfitrión hace clic en iniciar, simplemente se guarda la sala. Y Playroom gestiona el estado.
Y eso no es todo lo que hace Playroom. Playroom también proporciona una conexión secundaria para ti. Entonces, Playroom mantiene dos tipos de conexiones para ti. Uno es el socket TCP del que hablamos, que es confiable y pasa por los servidores de Playroom. Y tienen una latencia de 80 a 150 ms. El otro tipo de conexión es la conexión UDP o WebRTC que Playroom mantiene entre los jugadores. Entonces, en estas conexiones no se involucra ningún servidor de Playroom. Y estas utilizan WebRTC y son inherentemente no confiables. Eso significa que tu estado puede que no siempre llegue al otro extremo. Pero para algunos tipos de estados, esto está bien. Por ejemplo, para las posiciones de los jugadores, esto está bien porque probablemente estarás enviando la posición del jugador nuevamente en unos pocos milisegundos. Entonces, si te pierdes uno, no importa. Simplemente...
6. Sending Player Positions and Playroom Benefits
Short description:
Playroom te permite elegir el tipo de estado que enviar a través de diferentes conexiones, como websockets o WebRTC. Los comentarios de los desarrolladores de juegos que han utilizado Playroom han sido positivos. Su enfoque se centra en proporcionar un SDK sencillo que permite a los desarrolladores de juegos centrarse únicamente en el código relacionado con el juego. Para obtener más información sobre Playroom, visita Playroom.com o sigue al orador en Twitter.
Si intentas enviar las posiciones de los jugadores utilizando websockets, lo que sucederá es que habrá un efecto de enlace de números allí arriba. Donde recibirán un montón de posiciones y los jugadores se quedarán atascados y avanzarán rápidamente. Y eso no es lo que quieres. Pero Playroom te permite decidir qué tipo de estado quieres enviar a través de qué tipo de conexión. Y para cada estado establecido, puedes decidir si quieres enviarlo a través de websockets o WebRTC. De lo contrario, Playroom decidirá por sí mismo en función de la calidad de la conexión y todas esas cosas. Compartimos Playroom con un grupo de desarrolladores de juegos y los comentarios iniciales han sido excelentes. Supongo que el enfoque de Playroom es hacer el SDK de múltiples capas más simple posible y el enfoque es que los desarrolladores de juegos no escriban ningún código que no esté relacionado con el juego. Y sí, los comentarios han sido buenos. Eso es todo de mi parte. Muchas gracias. Puedes obtener más información sobre Playroom y unirte a Playroom.com. También puedes seguirme en Twitter o escanear este código QR para seguirme en Twitter. Muchas gracias.
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
Today's Talk discusses the future of performance tooling, focusing on user-centric, actionable, and contextual approaches. The introduction highlights Adi Osmani's expertise in performance tools and his passion for DevTools features. The Talk explores the integration of user flows into DevTools and Lighthouse, enabling performance measurement and optimization. It also showcases the import/export feature for user flows and the collaboration potential with Lighthouse. The Talk further delves into the use of flows with other tools like web page test and Cypress, offering cross-browser testing capabilities. The actionable aspect emphasizes the importance of metrics like Interaction to Next Paint and Total Blocking Time, as well as the improvements in Lighthouse and performance debugging tools. Lastly, the Talk emphasizes the iterative nature of performance improvement and the user-centric, actionable, and contextual future of performance tooling.
PlayCanvas is an open-source game engine used by game developers worldwide. Optimization is crucial for HTML5 games, focusing on load times and frame rate. Texture and mesh optimization can significantly reduce download sizes. GLTF and GLB formats offer smaller file sizes and faster parsing times. Compressing game resources and using efficient file formats can improve load times. Framerate optimization and resolution scaling are important for better performance. Managing draw calls and using batching techniques can optimize performance. Browser DevTools, such as Chrome and Firefox, are useful for debugging and profiling. Detecting device performance and optimizing based on specific devices can improve game performance. Apple is making progress with WebGPU implementation. HTML5 games can be shipped to the App Store using Cordova.
This Talk explores the use of Babylon.js and WebXR to create immersive VR and AR experiences on the web. It showcases various demos, including transforming a 2D game into a 3D and VR experience, VR music composition, AR demos, and exploring a virtual museum. The speaker emphasizes the potential of web development in the metaverse and mentions the use of WebXR in Microsoft products. The limitations of WebXR on Safari iOS are discussed, along with the simplicity and features of Babylon.js. Contact information is provided for further inquiries.
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
En esta masterclass, construiremos un juego utilizando el motor WebGL de PlayCanvas desde el principio hasta el final. Desde el desarrollo hasta la publicación, cubriremos las características más cruciales como la escritura de scripts, la creación de UI y mucho más. Tabla de contenido:- Introducción- Introducción a PlayCanvas- Lo que vamos a construir- Agregando un modelo de personaje y animación- Haciendo que el personaje se mueva con scripts- 'Falsa' carrera- Agregando obstáculos- Detectando colisiones- Agregando un contador de puntuación- Fin del juego y reinicio- ¡Resumen!- Preguntas Nivel de la masterclassSe recomienda familiaridad con los motores de juegos y los aspectos del desarrollo de juegos, pero no es obligatorio.
Construir aplicaciones web instantáneas a gran escala ha sido elusivo. Los sitios del mundo real necesitan seguimiento, análisis y interfaces y interacciones de usuario complejas. Siempre comenzamos con las mejores intenciones pero terminamos con un sitio menos que ideal. QwikCity es un nuevo meta-framework que te permite construir aplicaciones a gran escala con un rendimiento de inicio constante. Veremos cómo construir una aplicación QwikCity y qué la hace única. El masterclass te mostrará cómo configurar un proyecto QwikCity. Cómo funciona el enrutamiento con el diseño. La aplicación de demostración obtendrá datos y los presentará al usuario en un formulario editable. Y finalmente, cómo se puede utilizar la autenticación. Todas las partes básicas para cualquier aplicación a gran escala. En el camino, también veremos qué hace que Qwik sea único y cómo la capacidad de reanudación permite un rendimiento de inicio constante sin importar la complejidad de la aplicación.
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
En esta masterclass, construiremos un juego completo utilizando el motor PlayCanvas mientras aprendemos las mejores prácticas para la gestión de proyectos. Desde el desarrollo hasta la publicación, cubriremos las características más cruciales como la gestión de activos, scripting, audio, depuración, y mucho más.
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Veía una interacción lenta, probaba una optimización aleatoria, veía que no ayudaba, y seguía probando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Hacía una grabación en Chrome DevTools o React Profiler, la examinaba, intentaba hacer clic en cosas al azar, y luego la cerraba frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos cómo analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, cubriremos el rendimiento de interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Comments