> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-es/scenes-sdk7/arquitectura/data-oriented-programming.md). # Programación orientada a datos La programación orientada a datos es un enfoque potente para programar que saca el máximo partido del rendimiento. La Programación orientada a datos es un enfoque de programación muy potente que produce grandes mejoras en el rendimiento. Se centra en tratar *datos* como el elemento central; todo lo demás se organiza a su alrededor, ya sea para acceder a esos datos o modificarlos. Este enfoque también es muy amigable con multiplayer, ya que facilita y agiliza el acceso a los datos que deben sincronizarse entre jugadores. La Programación orientada a datos te anima a pensar en todo lo que hay en tu scene como datos que deben copiarse y mutarse a lo largo de los distintos systems. El principal beneficio de este enfoque es optimizar la velocidad a la que los datos pueden leerse desde la memoria, que a menudo es el principal cuello de botella al ejecutar aplicaciones y juegos modernos. Debido a esta notable mejora en el rendimiento, gran parte de la industria de la creación de juegos se ha ido orientando a adoptar este enfoque en los últimos años. El SDK de Decentraland ejecuta scenes en JavaScript, y una desventaja de este language es que no ofrece control sobre la asignación de memoria. El engine que ejecuta Decentraland, sin embargo, usa C#, y sí se beneficia mucho de seguir principios orientados a datos. El SDK y el engine se envían mensajes constantemente entre sí. Para que esta comunicación sea lo más eficiente posible, tiene sentido mantener las estructuras de datos en ambos lados lo más similares posible, para evitar tener que reorganizar estos datos constantemente. ## Cómo se ve La Programación orientada a datos es diferente de la Programación Orientada a Objetos, un enfoque con el que muchos desarrolladores están familiarizados actualmente. En la Programación Orientada a Objetos, el código se estructura siguiendo abstracciones que intentan replicar constructos del mundo real: objetos. Cada uno de estos objetos puede contener tanto datos como funcionalidad. Las aplicaciones que usan este enfoque suelen ser fáciles de planificar conceptualmente, pero también más ineficientes de ejecutar. En la Programación orientada a datos, los datos no se estructuran en torno a objetos; se estructuran para optimizar su facilidad de acceso. Los constructos del mundo real que representan los datos no intervienen en los distintos flujos que mutan esos datos. El modelo Entity Component System (ECS) en el que se basa el SDK de Decentraland es muy compatible con el enfoque de Programación orientada a datos. Cada component forma parte de una colección estructurada de datos. Los components pertenecen a una entity por referencia, pero los datos no se estructuran en torno a la entity; los datos se estructuran como una colección de components similares. Por ejemplo, todos `Transform` los components en una scene son iguales. Uno de estos transforms podría pertenecer al modelo de tu edificio principal, otro a un vaso que es hijo de una mesa. Luego, los systems en la scene procesan la lista de `Transform` components uno por uno, sin hacer distinciones. Todos `Transform` los components tienen los mismos fields y pasan por las mismas comprobaciones. ![](https://1216664193-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-2f8795b95cc1b4e9f2a9e37cdb54e9841d123b46%2Fcomponent-stacks.png?alt=media\&token=48e03f10-ead9-4cbd-b4c8-f1ff708c1c13) Imagina una scene que tiene una docena de puertas que pueden estar abiertas o cerradas. Puedes representar el estado de todas estas puertas como un simple component "isOpen" que contiene un valor booleano. Si "isOpen" es true, la puerta debe estar abierta; si es false, la puerta debe estar cerrada. Si un player hace clic en una puerta, debería alternar de estado, y los demás players también deberían verla alternar. Mientras tu scene está procesando un cambio en el estado de una puerta y sincronizándolo con otros players, a la scene realmente no le importa qué representa "isOpen". Todo el conjunto de components es solo una colección de booleanos que deben sincronizarse con otros players. Luego, un system separado en tu scene puede encargarse de hacer coincidir regularmente el estado de cada "isOpen" con la rotación correspondiente de la puerta. La Programación orientada a datos no es necesariamente más difícil, pero sí es un enfoque distinto que hay que aprender y adoptar. Los desarrolladores que no están acostumbrados a este enfoque pueden necesitar algo de tiempo para familiarizarse con él; te animamos a explorar y probar ejemplos para hacerte una mejor idea. ## Por qué funciona Para entender por qué la Programación orientada a datos marca una diferencia tan grande, necesitamos echar un vistazo al hardware. Cuando el procesador necesita recuperar datos de la memoria, trae a la caché un bloque completo de datos, incluidos datos que casualmente están escritos en la memoria junto al valor que queríamos. Cuanto más pueda tu código aprovechar datos que ya están en la caché, más rápido se ejecutará. Imagina que la memoria de la máquina es un almacén literal, donde los datos se guardan en muchas cajas apiladas. Cada vez que necesitamos una cierta porción de datos, tenemos que llamar a una carretilla elevadora para que vaya a buscar la caja donde se encuentran esos datos y la lleve al mostrador para inspeccionarla. Ese mostrador solo puede albergar un par de cajas a la vez, así que no puedes guardar muchos datos allí. La carretilla elevadora tarda mucho en ir hasta el fondo del almacén y traernos una caja. Si los datos que quieres de estas cajas están dispersos, eso significará pedirle a la carretilla elevadora que haga muchos viajes. La mayor parte del tiempo estarás de brazos cruzados junto al mostrador, esperando a que llegue la siguiente caja que pediste. Puedes evitar gran parte de ese tiempo perdido si apilas estas cajas de forma inteligente y organizas los datos de modo que las cosas que probablemente necesites al mismo tiempo estén mayormente agrupadas. Si agrupas los datos con inteligencia, a menudo descubrirás que lo siguiente que necesitas ya está en una de las cajas del mostrador. Podrás usarlo de inmediato sin molestar al operador de la carretilla elevadora. Por ejemplo, si tienes una scene que necesita recuperar el estado de una puerta para comprobar si está abierta o cerrada, el hardware no solo está recuperando el valor del booleano concreto que describe el estado de esa puerta, sino que también está recuperando un montón de otros datos que pueden ser relevantes o no. Supongamos que tu scene tiene un system que necesita actualizar el estado abierto/cerrado de una docena de puertas, en cada frame. Si tu código está organizado siguiendo un enfoque de Programación Orientada a Objetos, no hay forma de saber cómo podrían agruparse los distintos fragmentos relevantes de información. Quizá una "caja" de nuestro almacén contiene el estado "isOpen" de la puerta A y también su textura y el audio que reproduce al abrirse. Puede que tengas que hacer un viaje para recuperar una nueva "caja" de datos por cada una de las doce puertas. Y, por supuesto, todo este proceso debe volver a ocurrir en cada frame. Así que eso supone 360 (30 x 12) viajes metafóricos al fondo del almacén por segundo, incluso cuando ninguna de las puertas ha cambiado de estado. Si tu código sigue un enfoque orientado a datos, por otro lado, es muy probable que esos 12 booleanos estén en la misma caja. Esto se debe a que todos esos booleanos forman parte de un único array que se registró en la memoria de una sola vez. Nunca organizas explícitamente cómo encaja este dato en la memoria, así que, en el peor de los casos, el array podría terminar dividido en dos cajas. Pero incluso en ese peor escenario, 2 viajes es mucho mejor que 12. Comprobar el estado de cada puerta en cada frame parece mucho trabajo, pero en realidad es rapidísimo si todos los datos ya están en la caché de memoria. Si tus datos están bien organizados, tu scene puede ejecutar procesos como estos sobre muchas entities y aun así correr muy rápido. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.decentraland.org/creator/content-creator-es/scenes-sdk7/arquitectura/data-oriented-programming.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.