Diferencias entre Minecraft: Bedrock Edition y Minecraft: Java Edition

Por fuera, Bedrock Edition y Java Edition parecen muy similares, pero, al entrar en los detalles, vemos que no es tan así. Las bases de código diferentes crean distintos entornos de desarrollo. En este tutorial, se describen las principales diferencias que debes tener en cuenta como creador de contenido.

Con este tutorial, aprenderás lo siguiente:

• Una breve historia de estas dos ediciones: Java Edition y Bedrock Edition.
• En qué se diferencian las dos ediciones y qué significan para la creación de contenido.

Hay dos versiones principales de Minecraft.

Minecraft: Java Edition

Esta versión se lanzó originalmente en 2009. Esta versión solía llamarse Minecraft hasta que pasó a llamarse Minecraft: Java Edition en septiembre de 2017. Como su nombre lo indica, está desarrollada en Java y, en su mayor parte, no es compatible con la versión actual de Minecraft. Por lo general, a esta edición se la suele llamar simplemente Java.

Minecraft: Bedrock Edition

Bedrock Edition se lanzó el 20 de septiembre de 2017 y se basó en Minecraft: Pocket Edition, que se lanzó en 2011. Reunió nueve de las principales plataformas de dispositivos en una misma base de código llamada Bedrock Engine. Se reescribió Minecraft desde cero e incluyó algunos cambios fundamentales en la plataforma, lo cual allanó el camino para una comunidad de desarrollo nueva y prometedora. Por lo general, a esta edición se la suele llamar simplemente Bedrock.

Diferencias en los mundos

La diferencia más obvia entre ambas versiones es el formato de los mundos. Bedrock Edition usa el formato LevelDB para almacenar los mundos, mientras que Java Edition usa el formato Anvil. Debido a esto, la mayoría de las herramientas de terceros creadas para editar los mundos de Java Edition no funcionarán en Bedrock Edition.

Además, las dos versiones utilizan un formato de bloque bastante diferente. En Java Edition, se redujo el formato de bloque y se utiliza una cadena única para cada bloque individual; el estado de ese bloque se almacena por separado. De manera similar, Bedrock Edition se trasladó a un sistema basado en cadenas con estados de bloque, pero mantuvo algunos bloques agrupados definidos por valor de datos. Básicamente, esto significa que los bloques se nombran de manera diferente entre las versiones. En Bedrock Edition, el granito sería stone 1 mientras que en Java Edition es simplemente granite.

Otra diferencia clave es cómo se genera el mundo. Aunque ambas versiones usan un proceso similar para generar terreno, emplean un generador de números aleatorios diferente. Esto significa que las semillas no son compatibles entre las versiones. Una semilla que se usa en Bedrock Edition se generará de manera diferente a como lo haría en Java Edition. Esto hace que sea un poco más difícil crear contenido en Java Edition para utilizarlo en Bedrock Edition.

Diferencias entre Redstone y Comando

La estructura e implementación de comandos entre las dos versiones también son diferentes. La estructura de comandos de Bedrock Edition es similar al sistema utilizado en las versiones de Java Edition anteriores a la 1.13. También dejan de usarse las cadenas JSON sin procesar dentro de los comandos para utilizar un sistema basado en componentes. En lugar de usar cadenas JSON largas y complejas para personalizar las entidades, puedes convocar una entidad con un evento para que se active y también nombrarla mediante un solo comando.

summon <entityType: EntityType> [spawnPos: x y z] [spawnEvent: String] [named: String]

Actualmente, no hay forma de darles (/give) a los jugadores elementos personalizados en Bedrock Edition tal como se puede hacer en Java Edition. El elemento deberá crearse de antemano y teletransportarse al jugador. La forma más común de hacer esto es colocar el artículo en un cofre y romperlo o hacer que una entidad lo suelte al morir mediante la mesa de botín.

Aparte de eso, los comandos deberían resultar muy familiares entre las versiones Bedrock Edition y Java Edition anteriores a la 1.13. El formato de ejecución introducido en Java Edition 1.13 no es compatible con Bedrock Edition.

Los marcadores funcionan de la misma manera entre las dos versiones, pero Bedrock Edition actualmente no admite la amplia gama de criterios que sí tiene Java Edition. Actualmente, el único criterio compatible con Bedrock Edition es el de dummy. Bedrock Edition no ha implementado ninguno de los otros criterios disponibles en Java Edition. Tampoco admite comandos tales como /stats o /team.

Los comandos relacionados con el Calendario son diferentes entre las ediciones. En Java Edition, el comando /schedule tiene la siguiente sintaxis:

/schedule function <function> <time> [append|replace]
/schedule clear <function>

Se programará una función para ejecutarse después de que pase un período de tiempo, con la opción de programar la misma función nuevamente usando "append" (anexar) o cancelar programaciones anteriores de la función usando "replace" (reemplazar) antes de programar la nueva. Además de eso, las funciones programadas se pueden desprogramar con la opción "clear" (borrar).

En Bedrock Edition, el comando /schedule tiene la siguiente sintaxis:

/schedule on_area_loaded add <from: x y z> <to: x y z> <function: filepath>
/schedule on_area_loaded add circle <center: x y z> <radius: int> <function: filepath>
/schedule on_area_loaded add tickingarea <name: string> <function: filepath>

En lugar de ejecutar una función después de un cierto período de tiempo, las funciones se pueden programar para que se ejecuten cuando se carga una determinada región del mundo. La opción "tickingarea" (área activa) ejecutará la función especificada cuando se cargue un área activa del nombre especificado. Si esa área ya está activa, la función se ejecutará inmediatamente. Sin embargo, si el área activa aún no existe, la función permanecerá en espera hasta que se cree el área activa, por ejemplo, mediante el comando /tickingarea, después de lo cual se ejecutará la función.

Se pueden programar múltiples funciones para la misma ubicación o área activa. Sin embargo, a diferencia de Java Edition, las funciones programadas no se pueden borrar.

Redstone funciona ligeramente diferente también. A diferencia de Java Edition, Bedrock Edition no es compatible con la cuasi conectividad. Los sistemas que utilizan mecanismos como los interruptores Block Update Detector (BUD) no funcionarán. Los pistones también requieren un tic para retraerse y no dejarán bloques por ahí si se les da un pulso de un tic. Incluso la forma en que ocurren las actualizaciones es ligeramente diferente. Si bien la gran mayoría de los circuitos de Redstone funcionan bien entre las dos versiones, es posible que los circuitos más complejos no lo hagan.

Packs de recursos

Hay muchas similitudes entre Bedrock Edition y Java Edition cuando se trata de packs de recursos, pero tienen algunas diferencias. La más obvia es el cambio de archivos .mcmeta por archivos .json en Bedrock Edition. Estos archivos se utilizan para definir las propiedades de diferentes partes de la interfaz y se utilizan en gran medida de la misma forma con distintas diferencias de sintaxis entre los dos formatos. También verás diferencias importantes en los formatos de archivo de textura; la principal es en el uso de archivos TGA para trabajar con canales alfa en lugar de PNG. Algunas texturas (principalmente entidades) también se presentan de forma ligeramente diferente.

Packs de comportamiento

Una de las mayores diferencias entre Bedrock Edition y Java Edition es el uso de packs de comportamiento. Aunque funcionalmente es similar a los packs de datos en Java Edition, la implementación real y el uso de los packs de comportamiento varían bastante.

Los packs de comportamiento aportan nuevas funcionalidades, ya sea para crear sus propias entidades desde cero, agregar nuevos bloques y elementos o acceder a eventos mediante la API de JavaScript. Permite gran flexibilidad y control y es uno de los aspectos más poderosos de Bedrock Edition en comparación con Java Edition.

Juego y entrada del jugador

Una diferencia importante que tiende a olvidarse es el tipo de plataforma que usan los jugadores de diferentes versiones. Para Java Edition, puedes estar razonablemente seguro de que el jugador usa un teclado y un mouse; en Bedrock Edition, lo más probable es que no sea así.

Actualmente, los controles de la consola son el método de entrada más común en Bedrock Edition, mientras que el uso táctil ocupa el segundo lugar. Los controles del teclado y el mouse están en un tercer lugar lejano y constituyen un pequeño porcentaje de tu base de jugadores.

Eso significa que, al diseñar experiencias en Bedrock Edition, debes tener en cuenta los diferentes tipos de entrada que utilizarán los jugadores. Además, ten en cuenta cómo juegan tus jugadores. Si bien hacer muchos clics rápidos puede ser fácil con un mouse o incluso con un control, esto representaría una mala experiencia para los jugadores táctiles. Los jugadores que usan el teclado y tienen un arco pueden tener una puntería perfecta, pero es mucho más difícil cuando se usa un control o controles táctiles. El parkour complejo podría incluso impedirle jugar a un jugador móvil.

Siempre recuerda quién está jugando tu contenido. Si bien la tendencia demográfica de Java Edition puede ser de una edad un poco mayor, en Bedrock Edition tu público objetivo es mucho más joven. Lo más probable es que nunca hayan jugado Bedrock Edition en una PC.

Rendimiento

Aquí es donde las cosas se vuelven un poco más confusas y difíciles de definir. Debido a que Bedrock Edition Engine está diseñado para reproducirse en PC, dispositivos móviles y consolas, generalmente es una plataforma más tolerante y funciona mucho mejor en hardware de baja gama que Java Edition. Sin embargo, no está exento de fallas.

Además de los errores normales que causan problemas (¿y qué es Minecraft sin sus errores?), las funciones avanzadas que ofrece la plataforma también representan más formas posibles de romper el juego. Muchas entidades con comportamientos complicados pueden ralentizar algunos dispositivos. Las entidades personalizadas que utilizan modelos demasiado complejos pueden consumir demasiada RAM. Incluso la cantidad de piezas que se pueden cargar a la vez puede ser marcadamente menor en dispositivos de gama baja como los móviles.

Para combatir muchos de estos problemas de rendimiento, Bedrock Edition dividió el renderizado y la activación de las piezas. En lugar de una relación directa entre ellos como en Java Edition (es decir, todo lo que ves está cargado), Bedrock Edition te permitirá establecer una distancia de renderizado (hasta qué distancia se puede ver) con un valor diferente a la distancia de simulación (hasta qué distancia se activan las piezas). Esto te brinda la capacidad de renderizar visualmente áreas lejanas sin activar esas piezas. Las piezas activas tienen un impacto directo en el rendimiento y cuantas más piezas estén activas en un momento dado, mayor será el potencial de problemas en los dispositivos de gama baja.

---

En general, el cambio de Java Edition a Bedrock Edition es bastante sencillo si estás preparado adecuadamente y comprendes las diferencias. Muchas de las características en las que los creadores de Java Edition solían confiar mediante los comandos se trasladaron a los packs de comportamiento. La mayoría de los aspectos del juego se están rehaciendo para que se basen en datos, con un gran enfoque en la flexibilidad. A medida que el juego continúa evolucionando, la experiencia de juego se sentirá igual, pero lo que impulsa esa experiencia funcionará de manera muy diferente.

¿Cuál es el siguiente paso?

Si vienes recientemente de Java Edition, tus primeros pasos en Bedrock Edition estarán destinados a desarrollar complementos. Esto te abrirá muchas puertas necesarias para la creación de contenido en Bedrock.

Introducción al desarrollo de complementos