Menús de plugins con Geyser: qué probar en Java y Bedrock

Antes de aceptar un plugin a medida para una comunidad de Minecraft Java y Bedrock, comprueba que ambas ediciones permiten completar las mismas acciones, cancelar sin efectos inesperados y recibir un resultado correcto. Entrar mediante Geyser y ver un menú de inventario no basta. Acordad los dispositivos y controles admitidos y después probad el recorrido completo con permisos de jugador normal.

Si encargas un selector de equipos, un menú del lobby o una inscripción para un evento, la entrega debe incluir una interacción utilizable en cada cliente previsto. No tiene por qué verse igual. El ejemplo de esta guía es una propuesta de aceptación; no describe pruebas realizadas por Mineando.

Detecta los gestos que hacen dos cosas distintas

Pide al desarrollador una lista de las acciones que dependen del tipo de clic, de un atajo de teclado o de una interacción con el chat. Las limitaciones actuales de Geyser incluyen distinguir clic izquierdo y derecho en inventarios, los enlaces pulsables del chat y detectar que el jugador está escribiendo o autocompletando dentro del chat. Tenlas en cuenta al revisar el diseño.

Un requisito como «clic izquierdo en el estandarte para ver el equipo; clic derecho para unirse» necesita otro recorrido para Bedrock. La etiqueta «compatible con Geyser» no explica cómo llega el jugador a ambas acciones. Pide una demostración desde que abre el menú hasta que se comprueba su pertenencia al equipo.

Describe las acciones con palabras del jugador: consultar, elegir, confirmar, volver y cancelar. Así separas la intención de cada paso del gesto que lo activa. La guía general de aceptación de plugins trata el acuerdo de entrega completo; aquí nos centramos en la interfaz entre ediciones.

Elegid un diseño de interacción explícito

Hay tres opciones útiles para discutir antes de implementar el menú:

Diseño	Qué pedir	Qué falta comprobar
Menú de inventario compartido	Entradas distintas para acciones diferentes	Que se puedan encontrar y usar con cada control admitido
Menú Java y formularios Bedrock	Dos interfaces que apliquen las mismas reglas	Validación, cancelación y resultados equivalentes
Recorrido mediante comandos	Alternativa breve y fácil de encontrar para las acciones esenciales	Uso real en el dispositivo y permisos normales

Los formularios de Bedrock son una opción de desarrollo, no una conversión automática de un menú Java. Geyser documenta el acceso a Cumulus mediante Geyser o Floodgate, con los tipos SimpleForm, ModalForm y CustomForm. Su documentación de formularios distingue respuestas válidas, cierres y respuestas no válidas. El desarrollador debe decidir qué hace la aplicación en cada caso.

Solicita un prototipo pequeño del recorrido más delicado antes de construir todas las pantallas. Si elegir equipo resulta incómodo con mando, añadir diez menús más no resuelve esa decisión. Un comando alternativo solo ayuda si el participante puede descubrirlo y escribirlo en el dispositivo previsto.

Registra el alcance real de la compatibilidad

Anota la compilación del servidor Java, la versión del plugin, la compilación de Geyser y la de Floodgate si se utiliza. Incluye el proxy y los componentes de traducción de protocolos cuando existan. Consulta las versiones compatibles al preparar el ensayo y conserva las versiones utilizadas junto al resultado. Una demostración anterior no acredita la compatibilidad después de cambiar componentes.

Define cada combinación de cliente y control acordada: por ejemplo, Java con teclado y ratón, Bedrock táctil y Bedrock con mando. Es una matriz de ejemplo, no una obligación de admitir todos los dispositivos. Utiliza los dispositivos de destino cuando las diferencias de plataforma sean relevantes. Conectar un mando a un ordenador no demuestra que un participante de consola pueda completar todo el acceso al servidor.

Prueba por la entrada pública, con una cuenta de participante y en los idiomas previstos para el evento. Registra la escala de interfaz cuando afecte a la lectura. Los permisos de administrador y los atajos que conoce el desarrollador pueden ocultar un recorrido inaccesible para un jugador normal.

Ejemplo: elegir equipo sin inscribirse por accidente

Imagina un evento con dos equipos. Cada participante puede leer una descripción, solicitar una plaza, confirmar o cancelar. El equipo puede llenarse mientras alguien consulta el menú. Estas son reglas propuestas para acordar con el desarrollador:

1. Abrir una descripción no cambia de equipo al jugador. Cerrar esa pantalla tampoco modifica nada.
2. Elegir «Unirse» abre una confirmación que identifica el equipo. La pantalla anterior no debe completar la inscripción de forma silenciosa.
3. Al confirmar, el servidor comprueba las plazas y si el jugador cumple los requisitos en ese momento. La información mostrada antes puede haber quedado desactualizada.
4. El mensaje de éxito aparece después de completar la inscripción. Si ya no queda plaza, se muestra una negativa comprensible y una forma de volver.
5. Repetir la pulsación no genera una segunda inscripción ni repite una recompensa asociada a entrar en el equipo.

En Java, el prototipo podría tener entradas separadas de «Detalles» y «Unirse». En Bedrock, botones seguidos de un formulario de confirmación. Son propuestas de diseño; no afirmamos que un plugin de menús concreto ya las implemente.

Conserva el estado del equipo antes y después de cada caso. Si el jugador ve un mensaje de éxito pero el personal sigue sin verlo inscrito, la prueba falla aunque la animación sea correcta. Cuando se permita vincular cuentas, añade las comprobaciones de identidad de Floodgate acordadas por separado. La interfaz no determina por sí sola qué perfil recibe el resultado.

Ensaya las salidas incómodas

Repite el recorrido con cada combinación admitida. Cierra el menú antes de confirmar, vuelve atrás, reconecta con una confirmación pendiente e intenta confirmar después de que el personal cierre la inscripción. Haz también que otro participante ocupe la última plaza mientras el primer menú sigue abierto. Realiza estos ejercicios en un entorno de ensayo controlado.

Acordad de antemano el resultado esperado de cada interrupción. En este ejemplo, reabrir debe mostrar la inscripción actual y una confirmación antigua nunca debe saltarse el cierre de inscripciones ni el límite de plazas. Evita que una pantalla cancelada reaparezca indefinidamente: el jugador necesita una forma clara de abandonar el recorrido.

Para cada fallo, guarda una grabación breve, las versiones, la secuencia de acciones y el estado resultante en el servidor. Una captura estática no permite saber si una pulsación seleccionó, confirmó o canceló. No incluyas datos privados de las cuentas ni credenciales en las evidencias compartidas fuera del equipo.

Convierte la aceptación en una decisión clara

Aprueba la función cuando todas las acciones esenciales sean accesibles, cancelar sea seguro, el resultado del servidor coincida con el mensaje y haya evidencias de la matriz acordada. Registra por separado las diferencias visuales. Si un control admitido no permite una acción esencial, cambia el diseño o limita expresamente el público compatible antes de abrir.

Para plantear un proyecto de desarrollo de Minecraft a medida, trae la lista de acciones, la matriz de dispositivos y un recorrido de ejemplo. Mineando presupuesta individualmente proyectos de pago; el mantenimiento, las futuras adaptaciones y la cobertura del evento se acuerdan por separado.