deltaDNA para Unity introducción al SDK, deltaDNA te permite enviar información sobre las acciones de los jugadores de tu juego a deltaDNA para su análisis, informes, CRM y personalización del juego.
Los eventos se almacenan en caché en el cliente para evitar pérdidas mientras se juega sin conexión y se envían a la plataforma deltaDNA a intervalos regulares como objetos JSON. Los eventos varían en complejidad, pero todos se derivan de un esquema de eventos común. Este documento y la aplicación de demostración que lo acompaña proporcionan ejemplos de eventos cada vez más complejos.
El código fuente del SDK, escrito en C#, se proporciona como un activo de Unity empaquetado y no tiene dependencias externas. Los juegos envían datos con éxito a deltaDNA utilizando el SDK de Unity desde una amplia gama de plataformas de destino de Unity, incluidas Xbox, Playstation, PC, Web GL, iOS, Android, etc. Cabe señalar que deltaDNA no es actualmente un socio tecnológico certificado de Xbox o Sony, por lo que puede haber algunos escenarios de soporte en los que no podremos replicar o depurar implementaciones individuales de clientes.
Cambios a tener en cuenta para esta versión de deltaDNA para Unity
Cambios importantes: las versiones anteriores del SDK y las notas de la versión están disponibles en la página Notas de la versión y a partir de la versión 4 en el registro de cambios de nuestra página de GitHub.
Inicialización del SDK: El SDK debe importarse a tu proyecto de Unity como un paquete configurado con los siguientes detalles.
Configuración del SDK
Clave de entorno (Dev): una cadena única de 32 caracteres para enrutar los datos a su entorno DEV.
Entorno (en vivo): una cadena única de 32 caracteres para enrutar los datos a su entorno LIVE.
Clave seleccionada: elija DEV o LIVE en la lista desplegable para asegurarse de que los datos se enrutan al entorno correcto para su juego. Utilice el entorno DEV para las pruebas y el control de calidad, luego recuerde cambiar a activo antes de enviar una compilación de producción a la tienda.
Recopilar URL: la dirección del servidor que recopilará sus eventos.
EngageURL: la dirección del servidor que proporcionará pruebas A / B y orientación en tiempo real. Esto solo es necesario si tu juego utiliza estas funciones.
Estos detalles de configuración se pueden encontrar en la página de detalles del juego. Tenga en cuenta que existen diferentes valores de environmentKey para sus entornos DEV & LIVE. Deberá cambiar la clave de entorno con la que inicializa el SDK a medida que pasa del desarrollo y las pruebas a la producción.
Parámetros de configuración en deltaDNA para Unity
Ingresa estos parámetros en el panel de configuración al que se accede desde el menú deltaDNA -> Configurar dentro del Editor de Unity y Aplica tus cambios.
Ahora puedes agregar un script a un objeto de juego nuevo o existente para iniciar el SDK de deltaDNA.
Ejemplo de código de inicialización:
Código:
using UnityEngine;
using System.Collections;
using DeltaDNA;
public class MyBehaviour : MonoBehaviour {
// Use this for initialization
void Start()
{
// Start collecting data
DDNA.Instance.StartSDK();
}
}
Esta es la cantidad mínima de código necesaria para inicializar el SDK de Unity y comenzar a enviar eventos. Enviará automáticamente el evento newPlayer la primera vez que se ejecute el SDK, el evento gameStarted y clientDevice cada vez que se ejecute el juego y el evento gameRunning cada minuto.
Siga leyendo para descubrir cómo ir más allá de la grabación de algunos eventos automatizados y comenzar a desbloquear el poder de deltaDNA con eventos adicionales, parámetros, sus propios eventos personalizados, pruebas A / B y campañas específicas.
De forma predeterminada, el SDK de deltaDNA generará su propio ID de usuario anónimo, pero puede elegir usar su propia identidad, una proporcionada por otro proveedor de servicios de juego o inicio de sesión, simplemente colóquelo en el método StartSDK, por ejemplo. DDNA. Instancia. StartSDK(«ABCD-1234-GG-5678-ETC…»);
El ID de usuario se conservará en el cliente y se utilizará en todos los eventos posteriores durante la instalación de los juegos, a menos que lo cambie usted mismo (¡no se recomienda!)
Anatomía de un evento
Todos los eventos se registran como documentos JSON con un esquema básico compartido. El documento será diferente para cada tipo de evento, pero todos ellos deben cumplir con el siguiente esquema mínimo:
Código:
{
"eventName": "gameEnded",
"userID": "a2e92bdd-f59d-498f-9385-2ae6ada432e3",
"sessionID": "0bc56224-8939-4639-b5ba-197f84dad4f4",
"eventUUID": "60c4ccdf-1604-11e6-9906-b083fea450b0",
"eventTimestamp":"2016-03-18 11:09:42.491",
"eventParams": {
"sdkVersion": "Unity SDK v4.0.0",
"platform": "IOS_MOBILE"
}
}
El SDK de Unity rellenará automáticamente los parámetros userID, sessionID, eventTimestamp, eventUUID, platform & sdkVersion para cada evento que envíes. Al agregar parámetros a un evento, todos se colocarán dentro del objeto eventParams.
El orden de los parámetros en su evento JSON no importa, pero tenga cuidado ya que no admiten mayúsculas y minúsculas y deben coincidir con el tipo definido en el Administrador de eventos
Inspeccionar parámetros en deltaDNA para Unity
Puede inspeccionar los parámetros que cada evento espera, su tipo y cualquier regla de formato o enumeración en el Administrador de eventos.
Los parámetros pueden ser opcionales o obligatorios. Los parámetros que son opcionales no tienen que incluirse en tu evento si no tienes un valor válido para ponerlos. Es mejor dejarlos fuera por completo, que establecer su valor en nulo o vacío.
Esta estructura básica de eventos proporciona una gran flexibilidad para registrar eventos con diferentes niveles de complejidad, desde eventos simples como el anterior hasta eventos complejos que contienen matrices anidadas. Los siguientes ejemplos de código mostrarán una variedad de eventos, desde simples hasta complejos.
Tenga en cuenta que todos los eventos se validan y se rechazarán si no coinciden con el esquema del Administrador de eventos.
Configuración
El código de inicialización simple, copiado de la página de detalles del juego y que se muestra arriba, es el código mínimo requerido para comenzar a recopilar datos analíticos de sus jugadores. Rápidamente querrá comenzar a agregar más eventos y ajustar su implementación. Aquí está el mismo código de inicialización con un par de configuraciones útiles agregadas.
Código:
using UnityEngine;
using System.Collections;
using DeltaDNA;
public class MyBehaviour : MonoBehaviour {
// Use this for initialization
void Start()
{
// Configure the SDK
DDNA.Instance.SetLoggingLevel(DeltaDNA.Logger.Level.DEBUG);
DDNA.Instance.ClientVersion = "1.0.0";
// Start collecting data
DDNA.Instance.StartSDK();
}
}
Dos configuraciones adicionales
Indique al SDK que genere una depuración detallada de los eventos que está recopilando y las comunicaciones con deltaDNA. Esto es particularmente útil cuando se usa junto con QA – Interactive Validator durante el desarrollo, ya que le ayudará a resolver cualquier problema que esté causando que cualquiera de sus eventos falle en la validación.
Establece la clientVersion de tu juego. Esto es aconsejable y puede ser muy útil para identificar las diferencias de comportamiento entre los jugadores en diferentes construcciones de su juego. Especialmente cuando una actualización de la versión del cliente es una opción con la que muchos usuarios móviles no se molestan.
Es posible que incluso haya detectado una advertencia sobre la versión del cliente que no se estableció cuando ejecutó el código de inicialización simple, la configuración de ClientVersion lo resolverá. N.B. El SDK de Unity también puede extraer la versión de compilación de su página configuración del reproductor y usarla para rellenar clientVersion automáticamente por usted. Establece la casilla de verificación en la página Configuración de DeltaDNA en el Editor de Unity para habilitar esta función.
Hay muchas otras configuraciones útiles que lo ayudarán con los mensajes de notificación push, id de dispositivo, hash de eventos, recopilación automatizada de eventos y comunicaciones automatizadas, asegúrese de consultarlas en la aplicación de ejemplo que se incluye con el SDK o la información sobre herramientas incorporada.
Ejemplo 1 – Un evento simple
El código de inicialización que ya hemos visto enviará los eventos newPlayer, clientDevice, gameStarted y gameRunning a deltaDNA automáticamente. En el siguiente código añadiremos un evento nosotros mismos en código.
Cuando agregamos nuestro juego a deltaDNA, algunos eventos predeterminados se agregaron automáticamente, estos eventos tienden a ser estándar en todos los juegos y se utilizan para impulsar muchos de los paneles. Por ahora solo usaremos uno de esos eventos estándar, el evento options. Otros eventos estándar se pueden ver visitando Configuración > Ver eventos y cualquiera de estos eventos se nos puede enviar siempre que el esquema de su juego coincida con el esquema de la plataforma.
Código:
using UnityEngine;
using System.Collections;
using DeltaDNA;
public class MyBehaviour : MonoBehaviour {
// Use this for initialization
void Start()
{
// Configure the SDK
DDNA.Instance.SetLoggingLevel(DeltaDNA.Logger.Level.DEBUG);
DDNA.Instance.ClientVersion = "1.0.0";
// Start collecting data
DDNA.Instance.StartSDK();
// Build a game event with a couple of event parameters
GameEvent optionsEvent = new GameEvent ("options")
.AddParam ("option", "Music")
.AddParam ("action", "Disabled");
// Record the event
DDNA.Instance.RecordEvent (optionsEvent);
}
}
Se cargaría el siguiente evento JSON
Código:
{
"eventName": "options",
"userID": "4c1e9486-5477-42e4-8b0e-d3df9d173e60",
"sessionID": "7a9beb72-02be-4623-83c1-c99a16bfb08f",
"eventUUID": "7b451223-160d-11e6-9906-b083fea450b0",
"eventTimestamp": "2016-03-18 16:41:37.724",
"eventParams": {
"option": "Music",
"action": "Disabled",
"platform": "PC_CLIENT",
"sdkVersion": "Unity SDK v4.0.0"
}
}
Ejemplo 2 – Agregar un nuevo evento de plantilla
El ejemplo anterior utilizó uno de nuestros eventos estándar, esta vez haremos algo un poco más ambicioso, agregaremos un parámetro personalizado a un evento, luego activaremos el evento desde nuestro código.
Vaya a la página SETUP > Manage Events en su entorno DEV y busque el evento missionStarted, si no lo ve, es posible que deba agregarlo haciendo clic en el botón Crear evento y agregándolo de la lista desplegable de plantillas de eventos.
Haga clic en el botón Editar del evento missionStarted, seleccione el objeto eventParams y, a continuación, agregue un nuevo parámetro missionDifficulty del tipo STRING.
El código para desencadenar el evento missionStarted:
Código:
// Build some event parameters.
GameEvent missionStartedEvent = new GameEvent("missionStarted")
.AddParam("missionName", "Mission 01")
.AddParam("missionID", "M001")
.AddParam("isTutorial", false)
.AddParam("missionDifficulty", "EASY");
// Record the missionStarted event event with some event parameters.
DDNA.Instance.RecordEvent(missionStartedEvent);
Se cargaría el siguiente evento JSON:
Código:
{
"eventName": "missionStarted",
"userID": "4c1e9486-5477-42e4-8b0e-d3df9d173e60",
"sessionID": "e7e9c4dd-f220-43cb-bd84-f5990b444852",
"eventUUID": "7b451223-160d-11e6-9906-b083fea450b0",
"eventTimestamp": "2016-03-18 17:44:27.301",
"eventParams": {
"missionName": "Mission 01",
"missionID": "M001",
"isTutorial": false,
"missionDifficulty": "EASY",
"platform": "PC_CLIENT",
"sdkVersion": "Unity SDK v4.0.0"
}
}
Pegar JSON de eventos en el Validador de eventos interactivos puede ayudar a resolver errores, nuestro evento missionStarted pasó la validación por primera vez.
Ejemplo 3 – Un evento complejo
Los ejemplos anteriores han sido bastante sencillos y no han requerido mucha explicación. Sin embargo, el siguiente es un poco más complejo, ya que introduce anidamiento, matrices y algunos objetos especiales que encontrará cuando el jugador compre, intercambie, gane, cambie moneda. La buena noticia es que la estructura para esto es bastante estándar, hay algunos métodos auxiliares y esto es tan complejo como se pone.
Vamos a desencadenar un evento de transacción que registra al jugador usando alguna moneda del mundo real para comprar un cofre del tesoro que contiene alguna moneda virtual y múltiples artículos. También aprovecharemos la validación de ingresos de deltaDNA con la tienda de Apple para comprobar que la transacción es válida.
Como puede ver, la estructura del evento de transacción es un poco más compleja. Contiene un par de objetos Product para registrar productosSpente y productosReceived.
Nuestro evento JSON terminará pareciéndose a
Código:
{
"eventName": "transaction",
"userID": "4c1e9486-5477-42e4-8b0e-d3df9d173e60",
"sessionID": "d03fa7a4-b87e-43c8-8130-4c6aead89c4c",
"eventUUID": "7b451223-160d-11e6-9906-b083fea450b0",
"eventTimestamp": "2016-03-18 20:07:04.994",
"eventParams": {
"transactionName": "IAP - Large Treasure Chest",
"transactionID": "0AF9D5CE-52EC-402E-BE65-933525FF6472",
"productID": "4019",
"transactionServer": "APPLE",
"transactionReceipt": "ewok9Ja81............991KS==",
"transactionType": "PURCHASE",
"productsReceived": {
"virtualCurrencies": [
{
"virtualCurrency": {
"virtualCurrencyName": "Gold",
"virtualCurrencyType": "PREMIUM",
"virtualCurrencyAmount": 100
}
}
],
"items": [
{
"item": {
"itemName": "Golden Battle Axe",
"itemType": "Weapon",
"itemAmount": 1
}
},
{
"item": {
"itemName": "Mighty Flaming Sword of the First Age",
"itemType": "Legendary Weapon",
"itemAmount": 1
}
},
{
"item": {
"itemName": "Jewel Encrusted Shield",
"itemType": "Armour",
"itemAmount": 1
}
}
]
},
"productsSpent": {
"realCurrency": {
"realCurrencyType": "USD",
"realCurrencyAmount": 499
}
},
"platform": "PC_CLIENT",
"sdkVersion": "Unity SDK v4.0.0"
}
}
Y se requiere el código siguiente para crearlo utilizando la clase auxiliar Transaction
Código:
Transaction myTransaction = new Transaction(
"IAP - Another Large Treasure Chest",
"PURCHASE",
new Product() // Products Received
.AddItem("Golden Battle Axe", "Weapon", 1)
.AddItem("Mighty Flaming Sword of the First Age", "Legendary Weapon", 1)
.AddItem("Jewel Encrusted Shield", "Armour", 1)
.AddVirtualCurrency("Gold", "PREMIUM", 100),
new Product() // Products Spent
.SetRealCurrency("USD", Product.ConvertCurrency("USD", 4.99m)))
.SetTransactionId("100000576198248")
.SetProductId( "4019")
.SetServer("APPLE")
.SetReceipt("ewok9Ja81............991KS==");
DDNA.Instance.RecordEvent(myTransaction);
O puedes usar un ayudante de GameEvent
Código:
GameEvent transactionEvent = new GameEvent("transaction")
.AddParam("transactionName", "IAP - Large Treasure Chest")
.AddParam("transactionID", "100000576198248")
.AddParam("productID", "4019")
.AddParam("transactionServer", "APPLE")
.AddParam("transactionReceipt", "ewok9Ja81............991KS==")
.AddParam("transactionType", "PURCHASE")
.AddParam("productsReceived", new Product()
.AddItem("Golden Battle Axe", "Weapon", 1)
.AddItem("Mighty Flaming Sword of the First Age", "Legendary Weapon", 1)
.AddItem("Jewel Encrusted Shield", "Armour", 1)
.AddVirtualCurrency("Gold", "PREMIUM", 100))
.AddParam("productsSpent", new Product()
.SetRealCurrency("USD", Product.ConvertCurrency("USD", 4.99m)));
DDNA.Instance.RecordEvent(transactionEvent);
Tenga en cuenta: No puede simplemente multiplicar el valor decimal de una moneda por 100 para obtener el valor en la unidad monetaria más pequeña, algunas monedas no tienen 2 unidades monetarias después del punto decimal.
Hay un método en el SDK que puede ayudarle con esto. La clase Product contiene un método ConvertCurrency (códigode cadena, valor decimal) que devuelve una representación entera que se puede utilizar con el método SetRealCurrency. Este método también funcionará para monedas que no utilizan una unidad monetaria menor, por ejemplo, como el yen japonés (JPY).
Alternativamente, verifique la documentación del código de moneda ISO-4217,de 3 caracteres y confirme el factor de multiplicación que debe aplicar a cada realCurrencyType.
Código:
"realCurrency": {
"realCurrencyType": "USD",
"realCurrencyAmount": 499
}
Podemos crear eventos más complejos
Este evento puede ser más complejo, pero la estructura es lógica, flexible y proporciona un mecanismo para que los jugadores gasten o reciban cualquier combinación de monedas y artículos.
Los tres términos que se enumeran a continuación son nuestras pautas de mejores prácticas para los tres tipos generales de moneda virtual, definidos por su fuente.
GRIND = moneda que se gana a través del juego o las características del juego.
PREMIUM = moneda que se puede comprar a través de compras con moneda del mundo real.
PREMIUM_GRIND = moneda que puede provenir de cualquiera de las fuentes anteriores.
El currencyType no tiene un efecto en los paneles de ingresos, solo están ahí para distinguir las transacciones al realizar un análisis adicional de los datos. Puedes enviar estos tipos predeterminados o se puede agregar otra enumeración si hay algo más apropiado para tu juego.
Validación de transacciones
La plataforma puede llevar a cabo la validación de recibos de transacciones con varias tiendas para garantizar que cualquier ingreso que se muestre en sus paneles sea un ingreso genuino y no el resultado de un juego pirateado o jailbreak.
Si desea utilizar la validación de transacciones, deberá agregar un par de detalles a la página «Editar detalles del juego» a la que se puede acceder desde el enlace «Administrar juegos» a la izquierda de la pantalla de bienvenida.
Por ejemplo, para Apple, establecería su Apple StoreID de 9 dígitos. 971883677 y la URL del servicio de validación de recibos de Apple para validar con el servicio de validación de recibos de producción. N.B. – Si está enviando recibos de prueba, establezca su StoreID en 0 y establezca la URL de validación en: https://sandbox.itunes.apple.com/verifyReceipt.
También debe enviar parámetros adicionales junto con cada evento de transacción para decirle a deltaDNA que la transacción debe validarse.
Por ejemplo, para validar un IAP de Apple Store
Código:
"transactionServer": "APPLE", "transactionID":"100000576198248", "transactionReceipt": "ewok9Ja81............991KS==",
El transactionReceipt son los datos de recibo codificados BASE 64 que fueron devueltos por Apple. Consulte el sitio web para desarrolladores de Apple para obtener detalles sobre la validación de recibos de Apple.
Para validar google play IAP, envíe la transacciónServidor,los datos de compra como la transacciónReceipt y la ‘firma de datos en la aplicación’ como transacciónReceiptSignature
Código:
"transactionServer":"GOOGLE",
"transactionReceipt":"{
\"orderId\":\"GPA.1234-5678-9012-34567\",
\"packageName\":\"com.example.app\",
\"productId\":\"exampleSku\",
\"purchaseTime\":1345678900000,
\"purchaseState\":0,
\"developerPayload\":\"bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ\",
\"purchaseToken\":\"opaque-token-up-to-1000-characters\"
}",
"transactionReceiptSignature ":"rNvoHwiBdLSW+........VncbYVJ61fmfsQ=="
Dado que la transacciónReceiptSignature se genera a partir del recibo de la transacción y una clave privada para validar la recepción, esta deberá ser exactamente la cadena proporcionada por Google y pasada como una cadena, no un objeto JSON anidado.
Eventos de transacción en deltaDNA para Unity
deltaDNA validará sus ingresos y agregará un parámetro revenueValidated adicional, que contiene los siguientes valores potenciales, a su evento de transacción.
- 0 – no se realiza ninguna validación.
- 1 – verificación de validación de ingresos pasados.
- 2 – comprobación de validación fallida de ingresos.
- 3 – se intentó la validación de ingresos, pero se desconoce el resultado (el servicio de validación puede no haber estado disponible).
Las transacciones que no se validen con el código de estado 2 o 3 se excluirán de los gráficos de measure revenue y de las métricas de usuario.
Dado que las transacciones de sandbox en realidad no generan ingresos, estas no se muestran de forma predeterminada en los gráficos de ingresos, pero si desea que aparezcan, puede elegir la URL de sandbox en la página «Editar detalles del juego» (https://sandbox.itunes.apple.com/verifyReceipt), usar 0 como Apple StoreID y omitir el envío del transactionID ya que esto no es parte del recibo de sandbox. Le recomendamos encarecidamente que realice una prueba final con una transacción real en Apple Store, ya que solo dicha transacción tiene todos los campos configurados correctamente.
Ejemplo 4 – Participar en campañas de puntos de decisión
Los juegos pueden recuperar información sensible al tiempo de Engage para modificar o personalizar el juego para jugadores individuales en tiempo de ejecución, en función de los resultados de una campaña en el juego o una prueba A / B definida en la interfaz de usuario de deltaDNA.
Tu juego puede realizar solicitudes de Engage en puntos de decisión predeterminados en tu juego y la respuesta te permitirá personalizar el juego o anular la configuración predeterminada para ese usuario al instante.
En el ejemplo siguiente se muestra cómo se puede utilizar una campaña engage decision point para cambiar una oferta de IAP realizada al jugador:
- Crear una campaña de Punto de Decisión en la plataforma deltaDNA.
- Realiza una solicitud de Engage en tu código. Y reaccionar a la respuesta en una devolución de llamada.
- Para obtener fragmentos de código relacionados con las llamadas de Engage, consulte nuestra página de documentación de GitHub.
Para todas las llamadas de engage se le devolverá una respuesta JSON. Tu juego debe estar estructurado de tal manera que no se detenga si el usuario está en una conexión de alta latencia.
Estructura del juego en deltaDNA para Unity
Código:
{
"transactionID": 1725229742665236500,
"parameters": {
"creditPackPrice": 99,
"creditPackSize": 1
}
}
La respuesta engage contiene un transactionID y un objeto parameters que contiene cualquier parámetro relevante para este jugador en este momento.
Si el dispositivo no tiene conectividad a Internet en el momento de la solicitud de Engage, una respuesta en caché de la última solicitud de Engage exitosa para el mismo punto de decisión se incluirá en la respuesta. El parámetro isCachedResponse indicará que se trata de una respuesta almacenada en caché.
Código:
{
"transactionID": 1725229742665236500,
"isCachedResponse": true,
"parameters": {
"creditPackPrice": 99,
"creditPackSize": 1
}
}
Es posible que reciba una respuesta que contenga un id de transacción, pero sin parámetros. Esto indica que el jugador no ha cumplido con ningún criterio de calificación o ha sido asignado a un grupo de control.
Si hubo un error al procesar su solicitud de Engage en el servidor, su respuesta contendrá un parámetro statusCode que contiene el código de estado correspondiente.
400: entradas mal formadas o incorrectas de alguna manera, o está enviando parámetros en tiempo real que no se han agregado a su lista de parámetros de juego.
403 – clave hash secreta incorrecta o Engage no está habilitado en su cuenta.
Compruebe que tiene habilitado el paquete»On-Demand»en su página de Paquetes de Game ->, es posible que deba obtener el Propietario de la cuenta de su cuenta deltaDNA para que lo haga por usted.
404 – URL incorrecta o clave de entorno desconocida.
Mensajería de imagen
Engage Campaigns puede entregar mensajes emergentes a tu juego en tiempo de ejecución. Los mensajes de imagen reutilizables se crean en el Action Manager (Engage->Actions)y se asignan en el Campaign Manager (Engage->Campaigns). El SDK de Unity tiene una clase Popup que dibuja el mensaje de imagen sobre tu juego. La ventana emergente está impulsada por eventos, por lo que puede controlar cuándo se descarga la imagen de nuestros servidores y cuándo se presenta al reproductor.
Cada mensaje consta de dos partes, un mapa de sprites contiene imágenes para el fondo y una serie de botones, y un diseño que describe cómo mostrar estas partes. El diseño utiliza restricciones para entrenar cómo escalar y dónde colocar la ventana emergente. Esto significa que no tenemos que preocuparnos por los tamaños de pantalla, pero también podemos proteger partes de la pantalla para que no se cubran. La imagen se dibuja lo más grande posible dentro de esas limitaciones sin dejar de mantener la relación de aspecto original.
Una solicitud de participación de mensajería de imagen es la misma que cualquier otra solicitud de campaña de Participación.
Código:
{
"decisionPoint": "missionDifficulty",
"userID": "12344-232121-122144-11d32345",
"sessionID": "9098213--12312---41255--512555",
"platform": "IOS_MOBILE",
"version": "4",
"parameters": {}
}
El mensaje de respuesta contiene la imagen y la información de diseño de la ventana emergente, así como información sobre cualquier acción asignada a las imágenes.
Acciones asignadas a imágenes
Código:
{
"transactionID": 1842299243025399800,
"image": {
"width": 512,
"height": 256,
"format": "png",
"spritemap": {
"background": {
"x": 2,
"y": 74,
"width": 320,
"height": 180
},
"buttons": [
{
"x": 2,
"y": 38,
"width": 160,
"height": 34
},
{
"x": 2,
"y": 2,
"width": 160,
"height": 34
}
]
},
"layout": {
"landscape": {
"background": {
"contain": {
"halign": "center",
"valign": "center",
"left": "25%",
"right": "25%",
"top": "0px",
"bottom": "0px"
},
"action": {
"type": "dismiss"
}
},
"buttons": [
{
"x": 0,
"y": 146,
"action": {
"type": "dismiss"
}
},
{
"x": 160,
"y": 146,
"action": {
"type": "action",
"value": "POWERUP"
}
}
]
}
},
"shim": {
"mask": "dimmed",
"action": {
"type": "dismiss"
}
},
"url": "https://download.deltadna.net/engagements/429c686a43484befb611f4826312e835.png"
},
"parameters": {
"powerUpName": "MoHawk"
}
}
La url es la ubicación del archivo de imagen de mapa de sprites. El ancho y el alto son el tamaño de la imagen, y el formato es el formato de la imagen.
Objetos opcionales
El objeto spritemap describe la ubicación de los activos de imagen en el mapa de sprites. Los botones son opcionales dependiendo del número de botones en el mensaje.
El objeto de diseño describe cómo debe aparecer el fondo en la pantalla. Contiene teclas horizontales y / o verticales dependiendo del diseño preferido. Si solo hay una tecla presente, las reglas se aplican independientemente de la orientación. La orientación de diseño contiene reglas para el fondo y la ubicación de los botones.
Para el fondo son válidos dos modos: cubrir que escala la imagen de fondo para que sea lo más grande posible, y contener que hace que la imagen sea lo más grande posible de tal manera que se satisfagan todas las restricciones.
Cada objeto de fondo y botón puede tener una acción. El tipo de acción puede ser ninguno, descartar, vincular o acción.
Si el tipo es vínculo o acción, un campo de valor proporcionará un valor de cadena para devolver a la devolución de llamada asociada con el botón. Si es un enlace, el SDK abre automáticamente el navegador.
Código:
"action": {
"type": "action",
"value": "POWERUP"
}
Código:
"action": {
"type": "link",
"value": "https: //www.deltadna.com"
}
El campo shim describe cómo se debe manejar el resto de la pantalla detrás del mensaje. La máscara puede ser ninguna, en cuyo caso no se agrega nada, por lo que aún se puede hacer clic en los botones detrás de la ventana emergente, borrar, lo que tendrá el efecto de evitar que se haga clic en los botones de fondo, y atenuar lo que oscurece la pantalla. El shim también admite acciones, por lo que hacer clic en él también puede descartar la ventana emergente.
Consulta nuestra página de GitHub sobre cómo implementar la interacción de la imagen y manejar los parámetros opcionales devueltos junto con la imagen.
Notificaciones push de Android
El SDK de deltaDNA puede solicitar un ID de registro de Android para el dispositivo de un jugador y comunicarlo a la plataforma deltaDNA mediante un evento notificationServices, aunque es posible que deba agregar este evento a su juego en el Administrador de eventos. DeltaDNA puede utilizar este ID para enviar mensajes de notificación push dirigidos al dispositivo.
DeltaDNA utiliza el servicio Firebase Cloud Messaging para enviar notificaciones push como parte de una campaña fuera del juego.
Antes de que el SDK se pueda usar para registrar el dispositivo para las notificaciones push, hay un par de pasos que primero debe completar.
Recupera el ID de remitente y el ID de la aplicación de Firebase. Puede encontrar más información sobre cómo recuperar estos valores y configurar FCM en nuestra guía de configuración de FCM )
Configura estos valores en tu proyecto en la pantalla de configuración: se puede acceder a ello desde el menú del Editor de Unity en DeltaDNA > Notificaciones > Configurar Android
La siguiente línea de código se puede utilizar para registrar el dispositivo para las notificaciones push
Código:
DDNA.Instance.AndroidNotifications.RegisterForPushNotifications();
Esto recuperará el ID de registro de Android del dispositivo y lo enviará a la plataforma deltaDNA para ser utilizado como destino para notificaciones push. Para que la plataforma utilice este ID de dispositivo como destino, debe configurar su clave de API de Google en la plataforma; el proceso para esto se puede ver en la Guía fcM en Recuperación de valores de configuración.
Puede encontrar más información sobre las notificaciones push de Android y la integración del SDK de Unity en general en nuestra página de GitHub del SDK de Unity.
Se recomienda que hagas uso de Firebase Cloud Messaging, sin embargo, algunas aplicaciones más antiguas pueden seguir utilizando Google Cloud Messaging: puedes encontrar información sobre cómo recuperar valores de configuración de GCM en nuestra guía de configuración de GCM.
Notificaciones push de Apple (iOS)
El SDK de deltaDNA para Unity puede almacenar el token de notificación push de Apple y enviarlo a deltaDNA, lo que permite que la plataforma deltaDNA envíe mensajes de notificación push dirigidos a los jugadores. Tu aplicación será la encargada de solicitar una notificación push a Apple.
Para solicitar un token de notificación push de Apple:
Código:
DDNA.Instance.IosNotifications.RegisterForPushNotifications();
El token se enviará a deltaDNA en un evento notificationServices. Es posible que debas agregar el evento notificationServices a tu juego mediante el Administrador de eventos.
También deberá cargar su certificado iOS en la plataforma deltaDNA para que Apple acepte solicitudes de notificaciones push de deltaDNA, puede hacerlo en la página Configuración -> Herramientas – Notificaciones -> Administrar identidad. Su certificado de Apple debe contener tanto su certificado como su clave y guardarse como un archivo .p12.CertificateIcon
Consulte nuestra Guía de certificados de Apple,para obtener más información sobre cómo aprovisionar su aplicación para recibir mensajes de notificación push,crear un certificado y guardarlo en el formato correcto.
Identificadores de Apple
Apple Advertising Identifier y VendorID deltaDNA no registran el identificador de publicidad ni el vendorID.
Si desea registrar estos parámetros en deltaDNA, es responsable de recuperarlos del dispositivo y enviarlos como parámetros personalizados con cualquier evento al que desee adjuntarlos. También deberá agregar estos parámetros personalizados en la herramienta de administración de eventos.
Marcas de tiempo del evento
El SDK de Unity marca automáticamente los eventos mediante el reloj del dispositivo cliente. Esto puede causar imprecisiones cuando el dispositivo no está configurado en la hora o fecha correctas e incluso hacer que los eventos se rechacen si el tiempo está demasiado lejos. Sin embargo, el comportamiento de marca de tiempo local se puede anular y puede proporcionar su propio método de sellado de tiempo que se utilizará para los eventos de marca de tiempo.
Código:
// Override Default Timestamp
DDNA.Instance.SetTimestampFunc(() =>
{
DateTime dt = DateTime.UtcNow.AddSeconds(localTimeDelta);
return dt;
});
También es posible deshabilitar completamente la marca de tiempo en el dispositivo y enviar eventos sin una marca de tiempo, esto dará como resultado que el evento tenga una marca de tiempo con la hora del servidor Recopilar cuando se reciba el evento. Sin embargo, no recomendamos este enfoque, ya que hay un par de efectos secundarios indeseables.
El SDK de Unity almacena en caché los eventos del reproductor localmente para garantizar que no se pierdan si los dispositivos pierden conectividad. Por lo tanto, es posible que los eventos se reciban muchos días después de que ocurrieron.
Cargando eventos por lotes en deltaDNA para Unity
Los eventos se cargan en lotes que contienen varios eventos, ya que esto es mucho más eficiente que enviarlos de uno en uno. Si tuviera que usar la marca de tiempo del servidor Collect, esto haría que pareciera que el jugador está jugando en ráfagas frenéticas. Los eventos se verían como si todos ocurrieran dentro de unos pocos milisegundos entre sí y luego nada hasta que se cargue el siguiente lote.
Si debe utilizar la marca de tiempo del servidor Recopilar, puede hacerlo configurando DDNA. Instancia. UseCollectTimestamp(true);
Tienes todos los archivos necesarios en GitHub, también más información sobre el SDK de deltaDNA en el foro, sigue leyendo…