Lección 30 de 170

Analiza un escenario sintético de pago duplicado y define, para cada obligación de recompensa, una única ruta de pago que actúe como fuente de autoridad.

Curso de desarrollo de videojuegos con IA

Analiza un escenario sintético de pago duplicado y define una única ruta de pago que actúe como fuente de autoridad para cada obligación de recompensa.

431. Identidad de la lección

Módulo
1.10 — Progresión
Lección
Recompensas que se activan dos veces
Tipo académico
Estudio de caso
Tipo de esquema
estudio de caso
Orden
2 del módulo
Tiempo estimado
25–35 minutos, incluida la práctica

Esta lección utiliza un escenario sintético proporcionado en el que dos rutas de recompensa pueden procesar el mismo evento. Las etiquetas «ruta de baja etiquetada» y «ruta de pago ambiental» son términos de análisis para este ejercicio; no describen un caso publicado ni una implementación verificada.

El propósito no es repetir 1.10 — Los desbloqueos son predicados. El objetivo es reconocer cuándo varios observadores se convierten en autoridades de pago duplicadas y definir, para cada obligación de recompensa, una única ruta de pago que actúe como fuente de autoridad.

432. Objetivo de aprendizaje

Al terminar esta lección, el estudiante podrá identificar un patrón de pago duplicado a partir del escenario sintético proporcionado y especificar una única ruta autorizada para recompensar un evento.

Este es un ejercicio de sistemas con un ejemplo hipotético o explícitamente etiquetado. No es historia de producción documentada de CONTRABAND salvo que se nombre un tema verificado.

433. Por qué importa

Una recompensa contribuye a la progresión solo cuando su activador, su obligación y su autoridad están claros. Varios sistemas pueden observar legítimamente un mismo evento. La observación por sí sola no constituye una duplicación. El problema aparece cuando más de una ruta acredita la misma obligación de recompensa por el mismo evento.

La IA puede ayudar a enumerar rutas posibles u organizar un trazado, pero el desarrollador debe decidir:

  • qué evento ocurrió;
  • qué obligación de recompensa corresponde;
  • qué autoridad puede satisfacerla;
  • qué evidencia demuestra que un procesamiento repetido no concede otro crédito.

434. Conocimientos previos

Debes poder:

  • describir un predicado de progresión de 1.10 — Los desbloqueos son predicados;
  • distinguir una condición de la recompensa concedida cuando se cumple;
  • utilizar el bucle de Stage 1: ACTUAR → RESPONDER → CAMBIAR → OTRA VEZ.

435. Concepto central

Un evento puede tener varios observadores, pero cada obligación de recompensa definida debe tener una sola ruta de pago autorizada.

Usa este contrato:

Para cada evento y obligación de recompensa definida, una sola autoridad puede conceder el crédito. El procesamiento repetido del mismo evento no debe conceder otro crédito por esa obligación.

El contrato separa tres preguntas:

  1. ¿Qué ocurrió? Identifica un solo evento, no sus callbacks, notificaciones u observaciones secundarias.
  2. ¿Qué se debe conceder? Nombra la obligación exacta en lugar de hablar vagamente de «la recompensa».
  3. ¿Quién puede concederla? Selecciona una autoridad para esa combinación de evento y obligación.

Dos consecuencias no son automáticamente duplicadas. Si satisfacen obligaciones distintas y documentadas de forma explícita, ambas pueden ser intencionales. El análisis debe distinguir entre obligaciones separadas y dos rutas que pagan la misma obligación.

436. Caso sintético

Supón el siguiente escenario para el ejercicio:

Un evento: K-17
  ├─ La ruta A observa K-17 y puede conceder la recompensa R
  └─ La ruta B observa K-17 y también puede conceder la recompensa R

El trazado proporcionado registra lo siguiente:

Saldo inicial: 10 R
La ruta A procesa K-17: el saldo pasa a 15 R
La ruta B procesa K-17: el saldo pasa a 20 R

Para este ejercicio, la obligación definida es conceder 5 R una sola vez por K-17. Por tanto, el saldo final esperado es 15 R. El trazado permite diagnosticar un pago duplicado porque ambas rutas satisfacen la misma obligación para el mismo evento.

No generalices las etiquetas, los valores ni la estructura de rutas más allá de este escenario sintético.

437. Modelo de diagnóstico

Una secuencia de análisis útil es:

UN EVENTO IDENTIFICABLE
        |
        v
UNA OBLIGACIÓN DE RECOMPENSA DEFINIDA
        |
        v
UNA AUTORIDAD DE RECOMPENSA IDENTIFICADA
        |
        v
UN CRÉDITO
        |
        v
EL PROCESAMIENTO REPETIDO NO AÑADE NADA

Este es un modelo de diagnóstico, no una arquitectura de implementación obligatoria. Un identificador de evento es una posible forma de evidencia, no una solución técnica impuesta.

Pregunta Respuesta sólida Señal de alerta
¿Cuál es el evento? K-17 se trata como un solo evento Sus callbacks o notificaciones se cuentan como eventos nuevos
¿Qué obligación corresponde? Conceder 5 R una sola vez por K-17 «Pagar lo necesario para que el total parezca correcto»
¿Qué rutas lo observan? Las rutas A y B se rastrean por separado Se ignora una ruta sin comprobar su comportamiento
¿Quién controla la obligación? Una autoridad identificada Ambas rutas pueden conceder 5 R por K-17
¿Qué ocurre al repetir? No se conceden R adicionales Cada intento concede otros 5 R

438. Aplicación de ACTUAR → RESPONDER → CAMBIAR → OTRA VEZ

  • ACTUAR: la acción del jugador produce el evento K-17.
  • RESPONDER: las rutas A y B observan K-17.
  • CAMBIAR: la autoridad seleccionada concede 5 R una sola vez y el saldo pasa de 10 R a 15 R.
  • OTRA VEZ: la otra ruta o un procesador repetido trata K-17; el saldo permanece en 15 R para esta obligación.

El paso OTRA VEZ pone a prueba el contrato; no se limita a repetirlo con otras palabras.

439. Regla de decisión

Una decisión completa nombra el evento, la obligación, la autoridad y el resultado del procesamiento repetido:

«Para el evento K-17, la ruta A es la autoridad que puede conceder 5 R una sola vez. Si la ruta B u otro procesador trata K-17 para la misma obligación, concede 0 R adicionales».

Seleccionar la ruta A es solo una decisión del ejercicio; el escenario proporcionado no establece una arquitectura preferida para un producto real. También podría elegirse la ruta B si el contrato la nombrara como única autoridad y la evidencia demostrara el mismo resultado de un solo crédito.

440. Errores comunes

Corregir únicamente el total visible

Cambiar el saldo mostrado de 20 R a 15 R puede ocultar el síntoma y dejar activas las dos autoridades de pago. Hay que diagnosticar las rutas que modificaron el estado real de la recompensa.

Considerar inválido a todo observador

Varios sistemas pueden necesitar observar un mismo evento. El defecto no consiste en observarlo, sino en compartir indebidamente la autoridad sobre la misma obligación.

Suponer que toda segunda consecuencia es un duplicado

Una segunda consecuencia puede ser intencional si satisface una obligación distinta y claramente identificada. No combines obligaciones diferentes solo porque parten del mismo evento.

Decir únicamente «evitar duplicados»

Esa frase no identifica quién paga, qué se concede ni qué debe ocurrir al repetir el procesamiento. Escribe un contrato que pueda ponerse a prueba.

441. Práctica guiada

Utiliza exclusivamente la evidencia sintética proporcionada.

Paso 1 — Define el evento

Escribe una frase:

«La acción del jugador produce el evento K-17».

No redefinas las notificaciones de las rutas A y B como eventos independientes que merezcan otra recompensa.

Paso 2 — Rastrea las dos rutas

Crea una tabla de dos filas. Para cada ruta, registra:

  • el evento que observa;
  • la obligación que intenta satisfacer;
  • la cantidad que concede;
  • el saldo resultante;
  • si es la autoridad según tu contrato propuesto.

Paso 3 — Diagnostica el patrón

Compara el resultado esperado proporcionado, 15 R, con el resultado observado, 20 R. Indica si la evidencia muestra varios observadores, un pago duplicado o ambas cosas. Explica la diferencia.

Paso 4 — Toma la decisión

Selecciona una autoridad y completa este contrato:

«Para [evento], [autoridad] puede conceder [recompensa definida] una sola vez. El procesamiento repetido por [otra ruta o procesador] concede [resultado] para la misma obligación».

Paso 5 — Comprueba OTRA VEZ

Añade una fila final con un intento de procesamiento repetido. Registra el saldo anterior y posterior. Con un contrato válido de pago único, el saldo no cambia.

442. Validación y evidencia

Un análisis suficiente contiene:

  1. un evento identificado con claridad;
  2. dos rutas observadoras rastreadas por separado;
  3. una obligación de recompensa definida con precisión;
  4. los saldos inicial, observado y esperado proporcionados;
  5. una autoridad de recompensa seleccionada;
  6. un contrato de un evento y un pago;
  7. un resultado de OTRA VEZ que demuestre que no hay un segundo crédito para la misma obligación;
  8. una nota que explique que una recompensa separada exigiría una obligación distinta y explícita.

Otro desarrollador debe poder revisar el trazado y determinar por qué el segundo crédito es duplicado y no intencional.

443. Ideas clave

  • Tener varios observadores no implica que existan varias autoridades de pago válidas.
  • El pago duplicado se define con respecto al mismo evento y la misma obligación de recompensa.
  • Un contrato útil nombra el evento, la obligación, la autoridad, la cantidad y el comportamiento ante un procesamiento repetido.
  • Valida el estado real de la recompensa, no solo el total mostrado.
  • Mantén la evidencia sintética separada de cualquier afirmación sobre un juego o una implementación reales.

444. Próxima lección

La siguiente lección introduce los límites de la dificultad. Conserva la misma disciplina contractual: la dificultad solo puede afectar a las superficies permitidas de forma explícita y no debe duplicar ni reasignar silenciosamente una obligación de recompensa de progresión.

445. Comprobación

Responde estas preguntas por tu cuenta antes de leer las respuestas.

En el escenario sintético proporcionado, ¿qué permite diagnosticar un pago duplicado?

  • A. El saldo mostrado utiliza un formato poco habitual.
  • B. El umbral de progresión tiene que ser incorrecto.
  • C. Dos rutas observan el evento, aunque solo una conceda la recompensa.
  • D. Dos rutas conceden 5 R por el mismo evento y la misma obligación de recompensa.
Mostrar respuesta y explicación

Respuesta: Dos rutas conceden 5 R por el mismo evento y la misma obligación de recompensa.

Por qué: La observación múltiple no basta para demostrar una duplicación. La evidencia relevante es que ambas rutas acreditan la misma obligación definida para K-17.

¿Qué contrato expresa mejor un evento y un pago en el escenario sintético?

  • A. Cualquier ruta puede pagar si el total mostrado se corrige después.
  • B. El sistema debe evitar duplicados sin identificar una autoridad ni una obligación.
  • C. Cada ruta puede conceder 5 R cuando observe K-17.
  • D. La ruta A puede conceder 5 R una sola vez por K-17; el procesamiento repetido para la misma obligación concede 0 R adicionales.
Mostrar respuesta y explicación

Respuesta: La ruta A puede conceder 5 R una sola vez por K-17; el procesamiento repetido para la misma obligación concede 0 R adicionales.

Por qué: El contrato identifica el evento, la autoridad, la recompensa, la cantidad y el resultado del procesamiento repetido, por lo que la decisión puede ponerse a prueba.

Si el saldo es de 15 R después del pago autorizado, ¿qué debe mostrar el paso OTRA VEZ cuando otra ruta procesa K-17 para la misma obligación?

  • A. El saldo permanece en 15 R.
  • B. El saldo aumenta a 20 R.
  • C. El saldo se oculta sin comprobar el estado de la recompensa.
  • D. La recompensa se sustituye por un desbloqueo no relacionado.
Mostrar respuesta y explicación

Respuesta: El saldo permanece en 15 R.

Por qué: OTRA VEZ comprueba el procesamiento repetido. Para el mismo evento y la misma obligación, otro intento no debe añadir ninguna recompensa.

Apoyar