Crear una incursión cooperativa contra un monstruo

Este ejemplo crea una incursión en tiempo real en la que varios miembros atacan al mismo monstruo y comparten los resultados hasta que su salud llega a cero. El procesador común shared-resource de Webspace gestiona en el servidor los ataques, los cambios de salud y las recompensas por acción.

Antes de empezar

• Necesita permiso para desplegar esquemas y API.
• Los miembros participantes deben disponer de los permisos en tiempo real Send y Receive.
• Limite a los administradores el uso de la API que crea el objetivo de la incursión.

Empezar con el esquema completo

Descargue el esquema del juego con recursos compartidos (.sfn). Incluye las columnas y los permisos de las tres tablas utilizadas en este documento, además de la configuración del procesador shared-resource. Todas las versiones de esta guía utilizan el mismo archivo, con las descripciones de tablas y columnas en inglés.

1. Descargue el archivo, súbalo a una carpeta personal o de equipo y ábralo en el editor de esquemas.
2. En la configuración de despliegue de API Build, revise Database identifier. Cambie el valor predeterminado resource_game por un identificador nuevo, como monster_raid_team_a, para evitar conflictos con una base de datos existente.
3. Revise los permisos y la configuración del procesador y despliegue el esquema.

Este archivo es un ejemplo de estructura de backend para un recurso compartido. Como includeClient es false, no genera automáticamente la interfaz del juego ni incluye los datos iniciales del monstruo. Cree por separado una interfaz que use las siguientes API y eventos WebSocket y cree también el objetivo de la incursión.

Separar los datos en tres tablas

La estructura de recursos compartidos separa tres tipos de datos.

El ID de acción de game_actions permite identificar los reintentos. Aunque envíe de nuevo el mismo ID de acción, los cambios de salud y las recompensas no se aplicarán dos veces.

Configurar el procesador en tiempo real

Active la función en tiempo real y seleccione shared-resource como procesador de eventos. Si usa los nombres de tabla predeterminados, la configuración del procesador tendrá esta estructura:

{
  "resourcesTable": "game_resources",
  "actionsTable": "game_actions",
  "inventoryTable": "game_inventory",
  "actionPower": 1,
  "rewardPerAction": 1,
  "maxClientAmount": 1,
  "broadcast": "namespace"
}

Cuando broadcast es namespace, todos los clientes conectados al mismo espacio de nombres en tiempo real de Webspace reciben el evento de resultado. Configúrelo como actor para enviar el resultado solo al miembro que realizó la acción.

Crear el objetivo de la incursión

Llame a game_resources/create con permisos de administrador para crear el monstruo.

{
  "code": "RAID-1",
  "kind": "monster",
  "status": "active",
  "current_value": 10000,
  "max_value": 10000,
  "version": 0,
  "reward_item_code": "monster-core"
}

Al abrir la pantalla, consulte en la API de game_resources la salud y la versión actuales. Vuelva a consultarlas después de establecer o recuperar una conexión para sincronizar la interfaz con el estado actual del servidor.

Enviar un ataque mediante WebSocket

Después de que un miembro que haya iniciado sesión se suscriba a la conexión en tiempo real, envíe un evento resource-game.act.

{
  "type": "webspace:send",
  "data": {
    "dbName": "monster_raid_team_a",
    "event": "resource-game.act",
    "payload": {
      "actionId": "attack-00000001",
      "resourceCode": "RAID-1",
      "amount": 1
    }
  }
}

En dbName, use el valor de Database identifier elegido durante el despliegue.

Cree un actionId de entre 8 y 80 letras ASCII, números, guiones bajos o guiones. Si omite amount, su valor será 1; si lo incluye, use un número entero dentro del límite maxClientAmount del procesador.

El servidor envía resource-game.action-applied después de procesar la acción.

{
  "actionId": "attack-00000001",
  "resourceId": 1,
  "currentValue": 9999,
  "version": 1,
  "rewardQuantity": 1,
  "duplicate": false
}

Actualice la salud en la interfaz solo después de recibir este resultado. Se rechazarán las solicitudes del cliente que envíen directamente resource-game.action-applied.

Mostrar la salud y las recompensas

1. Confirme que resourceId corresponde al monstruo mostrado actualmente.
2. Confirme que version es posterior al resultado anterior.
3. Actualice la indicación de salud con currentValue.
4. Cuando currentValue llegue a 0, muestre el estado de derrota conjunta del monstruo.
5. Vuelva a consultar los objetos personales en game_inventory/list.

Aplique permisos de lectura solo para el propietario a game_inventory, de modo que cada miembro pueda leer únicamente sus propios datos. No deduzca las existencias de otros miembros a partir del campo rewardQuantity de un evento compartido.

Información útil

• La fuerza de ataque y las recompensas se determinan mediante la configuración del procesador del servidor, no con valores del cliente.
• La modificación del recurso, el registro de la acción y la acumulación de la recompensa se procesan en una sola transacción.
• La estructura compartida actual ofrece recompensas por acción. Las clasificaciones por derrotar al monstruo y las recompensas exclusivas para quien lo derrote requieren un diseño aparte.
• No considere que una respuesta retrasada equivale a una operación correcta. Vuelva a comprobarla con el mismo actionId para evitar que la acción se aplique dos veces.

Documentos relacionados

• Crear un juego de Gomoku en tiempo real
• Crear una API y desplegar una base de datos
• Rendimiento y escalabilidad