El equipamiento cambia la capacidad mediante un contrato

684. Identidad de la lección

Módulo

2.5 — Inventario, equipamiento y fabricación

Lección

El equipamiento cambia la capacidad mediante un contrato

Tipo académico

Construcción guiada

Tipo de esquema

Práctica

Orden

Lección 2

Tiempo estimado

30–40 minutos

685. Objetivo de aprendizaje

Después de esta lección, podrás convertir las selecciones de equipar y desequipar en efectos de juego mediante ranuras, modificadores, estados vacíos y capacidades derivadas, sin duplicar la autoridad entre el inventario y los sistemas de juego.

686. Por qué importa

El inventario puede registrar que el jugador posee un objeto, pero poseerlo no significa que esté activo. El equipamiento introduce otro estado: qué objeto poseído, si hay alguno, está seleccionado para una ranura de capacidad. Después, una etapa de interpretación separada deriva el efecto que utilizará el juego.

La expresión si hay alguno forma parte del contrato. Una ranura puede estar vacía antes de equipar un objeto, después de una solicitud explícita para desequiparlo o cuando otra regla elimina una selección inválida. Si no se define el estado vacío, el juego puede conservar un modificador obsoleto aunque la interfaz no muestre ningún objeto equipado.

Separar la posesión, la selección y la interpretación hace que las implementaciones sean más fáciles de revisar, probar y ampliar.

687. Conocimientos previos

Debes poder describir el inventario como autoridad sobre la posesión y la cantidad, tal como se estableció en El inventario controla la posesión, no todo el significado de los objetos. También debes conocer la práctica de asignar una única autoridad a cada hecho del juego. Usa el ciclo de implementación entrada → regla → presentación → respuesta perceptible para describir cómo las solicitudes de equipar y desequipar se convierten en capacidades observables.

688. Concepto central

El equipamiento es un contrato entre tres capas:

1. Estado de selección: qué ID de objeto, o qué valor vacío explícito, ocupa una ranura determinada.
2. Datos de modificador: qué cambios de capacidad declara el objeto equipado.
3. Capacidad derivada: el resultado de juego producido al interpretar las selecciones actuales.

El sistema de equipamiento controla el estado de selección. No controla las cantidades del inventario, las descripciones de los objetos ni todos los cálculos de juego. Un sistema de capacidades consulta la selección y los datos del objeto para derivar un resultado, como fuerza de herramienta, capacidad de movimiento o protección.

Un contrato útil es:

Selección de equipamiento + datos de modificador → capacidad derivada

En una ranura tool, el valor seleccionado puede ser un ID de objeto o none:

tool slot = fold_cutter | rusty_cutter | none

none representa un estado de equipamiento válido, no un error ni una función sin implementar. También debe definirse su resultado. En este ejemplo, una ranura de herramienta vacía deriva cuttingPower = 0.

Por tanto, un mismo objeto puede estar:

• en posesión, pero sin equipar;
• equipado en una ranura válida;
• sustituido por otro objeto válido; o
• de nuevo en posesión pero sin equipar cuando se vacía la ranura.

El inventario sigue siendo la fuente para saber si el jugador posee el objeto. El equipamiento registra la elección activa o su ausencia. La interpretación de capacidades consulta ese contrato sin crear un segundo inventario.

689. Modelo mental

Usa el modelo SELECCIONAR → INTERPRETAR → APLICAR:

Mantén explícito el mapa de autoridad:

El jugador proporciona la entrada al solicitar equipar o desequipar. Una regla de selección acepta o rechaza la solicitud y comunica el resultado. Una solicitud aceptada cambia el estado del equipamiento, recalcula la capacidad y expone el resultado mediante la presentación y una respuesta perceptible. Otra solicitud permite volver a poner a prueba el contrato.

690. Ejemplo concreto

Supón que el jugador posee dos herramientas:

rusty_cutter:
  slot: tool
  cuttingPower: 1

fold_cutter:
  slot: tool
  cuttingPower: 3

El jugador comienza con la ranura de herramienta vacía:

equipment.tool = none

Seleccionar fold_cutter produce esta transición:

solicitud: equipar fold_cutter
→ el inventario confirma la posesión
→ los datos del objeto confirman slot = tool
→ el equipamiento asigna fold_cutter a la ranura tool
→ la interpretación deriva cuttingPower = 3
→ la interacción de corte usa cuttingPower = 3

Desequipar produce otra transición válida:

solicitud: desequipar tool
→ el equipamiento asigna none a la ranura tool
→ la interpretación deriva cuttingPower = 0
→ la interacción de corte usa cuttingPower = 0

Desequipar no elimina el objeto del inventario. Solo borra la selección activa. Si se repite desequipar tool cuando la ranura ya está vacía, debe seguir vacía y no debe reaparecer un modificador anterior.

El inventario no almacena cuttingPower, y la interacción no busca en el inventario para adivinar qué herramienta está activa. Cada sistema consulta el contrato que necesita.

691. Flujo de trabajo con IA

Usa la IA como colaboradora de implementación, no como autoridad arquitectónica.

1. Declara el contrato antes de pedir código: el inventario controla la posesión; el equipamiento controla un ID de objeto o un valor vacío por ranura; los datos del objeto controlan los modificadores; y la interpretación de capacidades deriva el valor activo.
2. Pide a la IA que proponga un modelo de datos pequeño e indique la autoridad de cada hecho.
3. Revisa la propuesta para detectar estados duplicados. Rechaza diseños que almacenen tanto equippedItem como un activeCuttingPower editable por separado, salvo que el segundo valor sea explícitamente derivado y se actualice mediante una única regla definida.
4. Comprueba que la propuesta represente deliberadamente la ranura vacía. No aceptes código que trate una clave ausente, un ID obsoleto y una acción intencional de desequipar como estados indistinguibles sin explicar la política.
5. Pide a la IA que implemente el flujo mínimo para equipar y desequipar con una ranura válida y dos objetos.
6. Prueba la implementación con las evidencias indicadas abajo. Si el comportamiento falla, pide primero un diagnóstico de la infracción del contrato antes de solicitar una reescritura.

Un prompt útil es:

Implementa un contrato mínimo de equipamiento para una ranura tool. El inventario controla la posesión. El equipamiento controla el ID del objeto seleccionado o un valor vacío explícito. Los datos del objeto proporcionan cuttingPower. Una función de capacidad deriva el poder de corte activo a partir de la selección actual y devuelve 0 cuando la ranura está vacía. Rechaza las solicitudes de equipar si el jugador no posee el objeto o si este no corresponde a la ranura. Una solicitud de desequipar vacía la ranura sin eliminar el objeto del inventario. Indica la autoridad de cada valor antes de escribir código.

692. Errores comunes

Duplicar el efecto de un objeto

Una pantalla de equipamiento puede establecer cuttingPower = 3, mientras un script de interacción busca otra herramienta y calcula un valor distinto. Estas rutas pueden contradecirse cuando un objeto se sustituye, elimina, modifica o desequipa. Guarda la selección una sola vez, declara el modificador una sola vez y deriva la capacidad mediante una única ruta de interpretación visible.

Vaciar la interfaz, pero no el contrato

Ocultar el objeto seleccionado en la interfaz no basta para desequiparlo. Si el equipamiento todavía almacena fold_cutter, el juego puede seguir usando su modificador. Desequipar debe cambiar el estado del equipamiento al valor vacío explícito y volver a interpretar la capacidad. Después, la presentación refleja el nuevo estado.

693. Práctica guiada

Construye o adapta una sección de equipamiento con una sola ranura.

Paso 1: Declara el contrato

Escribe una tabla breve de autoridad que incluya:

• IDs y cantidades de objetos poseídos;
• ID del objeto seleccionado o valor vacío de la ranura tool;
• datos que relacionan objetos con modificadores;
• capacidad cuttingPower derivada;
• texto presentado para el objeto y la capacidad.

Para cada entrada, nombra exactamente una autoridad. En esta sección, define de forma explícita que una ranura vacía produce cuttingPower = 0.

Paso 2: Define las reglas para equipar y desequipar

Implementa o describe comandos con este comportamiento:

• rechazar una solicitud de equipar un objeto que no esté presente en el inventario;
• rechazar una solicitud de equipar un objeto cuya ranura declarada no sea tool;
• aceptar un objeto válido y sustituir la selección actual de tool;
• aceptar una solicitud de desequipar y asignar a tool el valor vacío explícito;
• mantener la posesión del objeto al desequiparlo;
• derivar de nuevo la capacidad después de cambiar la selección o vaciar la ranura.

No añadas una segunda cantidad de inventario al estado del equipamiento. No conserves el modificador anterior cuando la ranura quede vacía.

Paso 3: Conecta la presentación y la respuesta perceptible

Haz que la presentación del equipamiento muestre el ID o el nombre del objeto seleccionado. Si la ranura está vacía, muestra una etiqueta deliberada, como Ninguna herramienta equipada, en lugar del nombre obsoleto de un objeto.

Haz que la respuesta de juego exponga el cuttingPower resultante cuando el jugador intente la interacción correspondiente. Ese dato debe proceder de la capacidad derivada, no de un valor fijo escrito en la interfaz.

Paso 4: Toma una decisión sobre la eliminación del inventario

Elige qué ocurre cuando un objeto equipado se elimina del inventario:

• vaciar automáticamente la ranura;
• impedir la eliminación; o
• marcar la selección como inválida hasta que el jugador la resuelva.

Esta política de eliminación es distinta de la acción explícita de desequipar. Desequipar borra la selección activa y conserva la posesión. Eliminar un objeto del inventario cambia la posesión y obliga a reconciliar cualquier referencia del equipamiento.

Elige una política, indica qué sistema la aplica o coordina y explica cómo evita selecciones o modificadores obsoletos. La lección no impone una solución universal; exige un contrato explícito.

694. Validación y evidencias

695. Comprobación de conocimientos

696. Puntos clave

• El inventario controla la posesión; el equipamiento controla el ID activo o el valor vacío de cada ranura.
• Desequipar borra la selección sin eliminar el objeto del inventario.
• Una ranura vacía es un estado válido con un resultado derivado definido.
• Los modificadores describen la contribución de un objeto; no constituyen otro estado de inventario o equipamiento.
• La validación de selección protege la posesión y la compatibilidad de ranura.
• Las políticas explícitas para el estado vacío y la eliminación evitan selecciones y modificadores obsoletos.

697. Próxima lección

Continúa con 2.5 L3 — La fabricación es una transacción, no una segunda economía.

698. Comprobación