De sistemas de juego a owners de runtime

963. Identidad de la lección

Módulo

3.1 — Arquitectura de runtime

Tipo académico

Sistemas

Orden

1

Tiempo estimado de contenido

20 minutos

Tiempo estimado de práctica

15 minutos

Tiempo total estimado

30–40 minutos

964. Objetivo de aprendizaje

Al finalizar esta lección, podrás asignar un owner, una responsabilidad de ciclo de vida y un límite de ejecución a cada parte de una arquitectura pequeña de juego.

965. Por qué importa

Un documento de diseño puede describir el inventario, los encuentros, la progresión y la interfaz como sistemas separados. Un juego en ejecución necesita objetos o servicios concretos que creen, coordinen, actualicen y liberen esas responsabilidades. Cuando el ownership queda implícito, el orden de inicialización se vuelve frágil y varios componentes pueden tomar decisiones contradictorias.

Un ownership de runtime claro ofrece a quien desarrolla —y a un asistente de programación con IA— un objetivo arquitectónico explícito: quién tiene autoridad, cuándo está activa esa autoridad y qué mutaciones no deben cruzar directamente un límite.

966. Conocimientos previos

Debes poder describir un sistema pequeño de juego según su responsabilidad de cara al jugador: qué puede hacer el jugador, qué decide el juego y qué resultado observa. No necesitas un proyecto terminado ni conocimientos de un motor concreto.

967. Concepto central

Un sistema definido en diseño describe una responsabilidad del juego. Un runtime owner es el objeto, servicio o coordinador concreto que tiene autoridad sobre las decisiones, los datos o las tareas de ciclo de vida correspondientes.

Un sistema definido en diseño puede involucrar a varios owners de runtime, pero cada decisión o mutación importante debe tener una autoridad clara. Por ejemplo, el combate puede incluir un adaptador de entrada, un resolvedor de combate, el estado del jugador y un presentador de salud. El resolvedor de combate tiene la autoridad sobre la decisión de reglas; la interfaz no.

Un límite de ejecución establece qué puede decidir o modificar directamente un owner y qué debe cruzar hacia otro owner como solicitud, comando u observación. Este límite evita que un componente de interfaz cambie directamente el estado de dominio o que un controlador de escena termine apropiándose de todas las responsabilidades del sistema.

El estado autoritativo y la presentación aparecen aquí solo como ejemplos de límites. El modelo completo de ownership del estado corresponde al módulo 3.2.

968. Modelo Owner–Lifecycle–Boundary

Plantea cuatro preguntas para cada componente de runtime propuesto:

Usa estos artefactos durante la práctica:

1. Mapa de ownership: Responsabilidad | Owner | Autoridad | Solicitud u observación entre owners | Evidencia.
2. Franja de lifecycle: Crear → Inicializar → Activo → Reiniciar/Desactivar → Liberar si aplica.
3. Comprobación de límites: una acción directa permitida y una mutación directa prohibida para cada owner.

Un owner de composición o de sesión puede conectar sistemas y coordinar sus ciclos de vida sin poseer todas las reglas de dominio. Los owners de dominio toman las decisiones de runtime que les corresponden. Los owners de presentación observan o muestran resultados sin adquirir autoridad sobre el estado subyacente.

969. Ejemplo concreto

Considera un pequeño encuentro de infiltración:

Estas asignaciones ilustran límites; no prescriben una arquitectura completa del estado. La autoridad sobre las decisiones de las reglas del encuentro corresponde al resolvedor. El estado y la presentación siguen siendo responsabilidades separadas. Permitir que HudPresenter conceda directamente un recurso vulneraría el límite.

970. Flujo de trabajo nativo de IA

Usa la IA como apoyo para redactar y criticar, no como autoridad arquitectónica final ni como editora del proyecto.

Ejemplo de prompt:

Redacta un mapa de ownership de runtime para esta arquitectura: el jugador emite Search; la ubicación actual determina si una búsqueda puede revelar un objeto; una revelación exitosa actualiza el inventario; la interfaz muestra el resultado y la cantidad de objetos; una sesión nueva borra el estado temporal. Usa como máximo cinco owners. Para cada owner, indica su autoridad, su responsabilidad de ciclo de vida, una acción directa permitida, una mutación directa prohibida y una evidencia concisa. Identifica una solicitud u observación entre owners cuando corresponda; si no corresponde, marca no aplica y explica por qué ese owner no inicia trabajo a través del límite. Señala todos los supuestos que no estén en el enunciado. No proporciones un recorrido completo de la acción ni el orden detallado de mensajes.

Revisa el borrador fila por fila. Conserva una propuesta solo si el enunciado respalda su autoridad y su ciclo de vida. Rechaza supuestos no justificados sobre clases del motor, persistencia, buses de eventos, red o estructura de escenas. Revisa el mapa hasta que cada decisión y mutación importante tenga un único owner autoritativo.

La decisión final de arquitectura corresponde al estudiante. No pidas a la IA que edite archivos ni que genere código de implementación para este ejercicio.

971. Error común

Un error habitual es asignar ownership según la visibilidad en lugar de la autoridad. Una pantalla puede mostrar un temporizador, pero eso no la convierte en dueña del tiempo. Un controlador de escena puede saber cuándo se carga una escena, pero no debería apropiarse automáticamente de las reglas de combate, las mutaciones del inventario y los umbrales de progresión.

Pregunta qué componente tiene permiso para tomar la decisión, no cuál está activo cuando el resultado se hace visible. Tampoco inventes interacciones solo para que todos los owners envíen una solicitud. Algunos owners únicamente reciben comandos, exponen observaciones o gestionan su propio estado autoritativo.

972. Práctica guiada

Crea un mapa de ownership de runtime para esta arquitectura pequeña:

• El jugador puede emitir el comando Search.
• Una búsqueda puede revelar un objeto solo si la ubicación lo permite.
• El inventario registra el objeto después de una revelación exitosa.
• La interfaz muestra el resultado y la cantidad actual de objetos.
• Al comenzar una sesión nueva se borra el estado temporal de la sesión anterior.

Usa como máximo cinco owners. Para cada owner seleccionado, registra:

1. La responsabilidad que posee.
2. Cuándo se crea o activa y cuándo se reinicia o desactiva.
3. Una acción que puede realizar directamente.
4. Una mutación directa que tiene prohibida.
5. Una solicitud u observación entre owners cuando corresponda. Si no corresponde, marca no aplica y justifica por qué ese owner no inicia trabajo a través del límite.
6. Una evidencia concisa de que cumplió su responsabilidad.
7. El límite de liberación, desuscripción o desacoplamiento cuando sea relevante; de lo contrario, marca no aplica.

No produzcas un recorrido completo de Search, un orden detallado de mensajes ni un procedimiento de teardown. Esos temas corresponden a la próxima lección.

Si utilizas un borrador de IA, anota cada fila como respaldada, rechazada o revisada. Después decide si la comprobación del permiso de la ubicación pertenece al handler del comando de búsqueda, al owner del inventario o a un owner separado de reglas. Defiende tu elección en dos o tres frases basadas en la autoridad y el ciclo de vida, no en la conveniencia.

Distribución sugerida del tiempo:

• 8 minutos: redactar y refinar el mapa de ownership.
• 4 minutos: completar las entradas de lifecycle y límites.
• 3 minutos: revisar conflictos de autoridad y entregar la evidencia práctica.

973. Validación y evidencia

974. Ideas clave

• Los sistemas de diseño describen responsabilidades; los owners de runtime permiten ejecutarlas.
• La autoridad, el ciclo de vida y la visibilidad son aspectos arquitectónicos distintos.
• Cada decisión o mutación importante necesita una autoridad clara.
• Los límites de ejecución identifican acciones permitidas y mutaciones directas prohibidas.
• El trabajo entre owners solo debe registrarse cuando realmente corresponda.
• La IA puede proponer un mapa de ownership, pero el estudiante debe verificar los supuestos y asignar la autoridad final.

975. Próxima lección

Continúa con 3.1 L2 — Rastrear una acción por la arquitectura.

976. Comprobación