El inventario controla la posesión, pero no define todo el significado de los objetos | Curso de desarrollo de videojuegos con IA

669. Identidad de la lección

Módulo: 2.5 — Inventario, equipamiento y creación
Lección: 1
Tipo académico: Sistemas
Tiempo estimado: 30–40 minutos, incluida la práctica
Capacidad central: Modelar un contrato de inventario pequeño

670. Objetivo de aprendizaje

Después de esta lección, podrás definir un contrato de inventario pequeño que almacene cantidades fungibles por identificador de definición, aplique un límite explícito de posesión por definición, valide las mutaciones, comunique sus resultados y separe la posesión de la interpretación del objeto.

671. Por qué importa

El equipamiento, la creación, las recompensas, las tiendas y los datos guardados pueden depender del estado del inventario. Si cada sistema modifica ese estado con supuestos distintos, pueden aparecer cantidades negativas, límites superados o mensajes de éxito aunque la posesión no haya cambiado.

Una autoridad de inventario acotada proporciona una sola respuesta sobre lo que posee el jugador y una única vía para modificarlo. Esto no convierte al inventario en responsable de los efectos de equipamiento, las recetas, los precios, la progresión ni el significado narrativo.

672. Identidad: definiciones e instancias

Esta lección distingue dos formas de identidad:

Un identificador de definición del objeto identifica un tipo reutilizable, como bandage o scrap_metal. Varias unidades intercambiables pueden compartirlo.
Un identificador de instancia identifica un objeto concreto cuando posee estado individual, como durabilidad, propiedades generadas, historial de propiedad u otro valor propio de esa unidad.

El contrato pequeño de esta lección solo admite cantidades fungibles asociadas al identificador de definición:

cantidadPorIdDeDefinicion[idDeDefinicion] = cantidad

No almacena identificadores de instancia, registros de pilas ni posiciones en casillas. Por tanto, no puede representar dos pilas separadas de la misma definición ni dos copias con características distintas. Un juego que necesite esas distinciones requiere otro modelo de almacenamiento o una ampliación explícita.

673. Autoridad y límites del inventario

El inventario tiene autoridad sobre:

si existe una cantidad positiva de un identificador de definición;
la cantidad almacenada de esa definición;
si una adición o retirada cumple el contrato;
la aplicación o el rechazo de la mutación;
el resultado que recibe quien realiza la solicitud.

Otros sistemas conservan la autoridad sobre:

si un objeto puede equiparse y qué efecto produce;
si sirve como ingrediente de una receta;
los precios y su interpretación económica;
las decisiones de progresión o desbloqueo;
el significado narrativo;
los datos de definición, como la información visual y el límite configurado de posesión.

Otros sistemas pueden consultar la posesión y solicitar cambios, pero no deberían escribir directamente en el mapa de cantidades.

674. Modelo de almacenamiento y capacidad admitido

En esta lección, cada definición tiene una sola cantidad agregada y un límite de posesión por definición opcional:

estado almacenado: identificador de definición → cantidad agregada
cantidad válida: de 0 al límite de posesión, ambos incluidos

El límite restringe la cantidad total poseída bajo ese identificador. No es un límite de pila, de casillas, de peso ni de capacidad total del inventario.

Ejemplos:

bandage      cantidad: 3   límite de posesión: 5
scrap_metal  cantidad: 4   límite de posesión: 10
key_fold     cantidad: 1   límite de posesión: 1

Los datos de definición son responsables del valor configurado del límite. El inventario consulta ese valor al validar cambios de posesión. Las cantidades iguales a cero pueden omitirse del almacenamiento si el contrato declara que una entrada ausente equivale a cero.

675. Contrato de mutación

Usa esta secuencia:

SOLICITAR → VALIDAR → MUTAR O RECHAZAR → INFORMAR DEL RESULTADO

Una solicitud mínima indica:

la operación: añadir o retirar;
el identificador de definición;
una cantidad solicitada positiva.

Reglas de validación para este modelo:

El identificador debe corresponder a una definición conocida.
La cantidad solicitada debe ser mayor que cero.
Una adición solo es válida si actual + solicitada <= limiteDePosesion.
Una retirada solo es válida si actual >= solicitada.
Un rechazo deja intacto el estado almacenado.

El resultado visible para quien llama debe incluir, como mínimo:

aceptada: true o false
motivo: aceptada, definicion_desconocida, cantidad_invalida, limite_superado o cantidad_insuficiente
cantidadResultante: cantidad autoritativa después de la solicitud

Comunicar la cantidad resultante evita que otros sistemas tengan que adivinar si el estado cambió.

676. Ejemplo concreto

Estado y definiciones iniciales:

bandage      cantidad: 3   límite de posesión: 5
scrap_metal  cantidad: 4   límite de posesión: 10
key_fold     cantidad: 1   límite de posesión: 1

Solicitud	Resultado	Estado posterior
Añadir 2 `bandage`	Aceptada	`bandage = 5`
Añadir 3 `bandage` cuando hay 3	Rechazada: `limite_superado`	`bandage = 3`
Retirar 2 `scrap_metal`	Aceptada	`scrap_metal = 2`
Retirar 2 `key_fold`	Rechazada: `cantidad_insuficiente`	`key_fold = 1`
Equipar `key_fold`	No es por sí mismo una mutación del inventario	La posesión no cambia

La adición rechazada de vendas no se divide en varias pilas porque este modelo carece de registros de pila. Para admitir pilas separadas harían falta una identidad para cada pila y una estructura de contenedor adecuada.

677. Tabla de responsabilidades

Hecho o decisión	Sistema responsable
Existe la definición `bandage`	Sistema de definiciones
El límite de posesión de `bandage` es 5	Sistema de definiciones
El jugador posee actualmente 3 `bandage`	Inventario
Añadir 3 superaría el límite	Validación del inventario
`bandage` recupera salud	Sistema de uso de objetos o de salud
`scrap_metal` sirve para una receta	Sistema de creación
`key_fold` abre una puerta concreta	Sistema de interacción o narrativa

El inventario puede aportar evidencia de posesión sin convertirse en responsable de esas interpretaciones.

678. Errores comunes

Llamar límite de pila a un límite agregado

Un límite de pila se aplica a un registro de pila. Esta lección no almacena esos registros, por lo que su regla es un límite de posesión por definición.

Confundir una definición con una instancia

bandage identifica un tipo compartido por unidades intercambiables. No distingue una venda de otra. La durabilidad individual o las propiedades generadas exigen registros de instancia.

Dejar la capacidad sin definir

La palabra «capacidad» es ambigua si el contrato no aclara si se refiere a casillas, peso, pilas, cantidad total o cantidad por definición. Este contrato solo admite la última opción.

Permitir escrituras directas

Quien modifica directamente el mapa de cantidades puede saltarse la validación. Las adiciones y retiradas deben pasar por operaciones explícitas.

679. Práctica guiada

Crea un contrato y una tabla de decisiones para estas definiciones:

ration         límite de posesión: 4
copper_wire    límite de posesión: 10
access_token   límite de posesión: 1

Usa esta plantilla:

Modelo de identidad admitido:
Estado almacenado:
Significado de una entrada ausente:
Propiedad y significado del límite:
Validación de adición:
Validación de retirada:
Comportamiento ante un rechazo:
Resultado visible para quien llama:
Características de almacenamiento no admitidas:
Responsabilidades ajenas al inventario:

Resuelve estos casos:

Añadir 4 ration cuando la cantidad es 0.
Añadir 1 ration más después del caso 1.
Retirar 2 access_token cuando la cantidad es 1.
Decidir si copper_wire es un ingrediente válido para una receta.
Explicar qué debe cambiar en el almacenamiento si dos unidades de ration necesitan valores de durabilidad diferentes.

Para cada mutación, registra si fue aceptada, el motivo, la cantidad resultante y si cambió el estado.

680. Validación y evidencia

Entrega el contrato y la tabla de resultados mediante la evaluación práctica asociada. Comprueba que:

distingues explícitamente los identificadores de definición de los posibles identificadores de instancia;
limitas el modelo admitido a cantidades agregadas y fungibles;
defines el límite como una cantidad máxima por definición;
ninguna respuesta depende de dividir pilas, usar casillas o calcular peso;
las adiciones y retiradas se validan antes de mutar;
las solicitudes rechazadas dejan intacto el estado;
los resultados incluyen aceptación, motivo y cantidad resultante;
asignas la creación u otra interpretación a un sistema ajeno al inventario;
reconoces la necesidad de registros de instancia cuando las unidades tienen estado individual.

681. Puntos clave

Este inventario almacena cantidades fungibles agregadas por identificador de definición.
Un identificador de definición representa un tipo; un identificador de instancia representaría un objeto concreto.
El modelo usa un límite de posesión por definición, no pilas, casillas ni peso.
El inventario controla la posesión y sus cambios validados, no todas las interpretaciones del objeto.
Toda mutación debe validarse primero y devolver un resultado explícito.

682. Siguiente lección

2.5 L2 — El equipamiento cambia la capacidad mediante un contrato mantiene al inventario como autoridad sobre la posesión mientras el equipamiento controla el estado equipado y la interpretación de sus efectos.