Desarrollando un videogame: revision 17

Revisión 17, una versión simplificada de la revisión 16.

Comienzo por los problemas de uno en uno:

  • Previo a servidor. Viernes 31/09
    • ✓ Recrear nuevos cambios gráficos en la sidebar.
    • ✓ Crear la funcionalidad de enviar feedback.
    • ✓ Hacer que la imagen de discord lleve al canal.
    • ✓ Hacer que el nombre de usuario sea clickeable y abra el modal.
    • ✓ Hacer funcionar ese modal.
    • ✓ Solapa de cashier con QR, colocar la info a la derecha.
    • ✓ Balance, acomodar código, db, y luego acomodar modal.
    • Hacer andar el mfa y el modal del mfa.
    • ✓ Hacer andar el modal de eliminación de usuario.
    • Invalidar al usuario cuando se queda sin dinero.
  • Servidores. Viernes 31/09
    • Conseguir un subdominio que corresponda a la zona.
    • Hacer andar una copia en el subdominio.
    • Poner un index en el dominio principal.
    • Conseguir una segunda copia en un segundo subdominio.
    • Acomodar el modal de rooms.
    • En caso de que no sea posible por el horario.
    • Solo hacer pull en el server de la versión final.
  • Pruebas online. Sabado 01/09
    • Los usuarios deberán usar el servidor de Sao Pablo.
    • Los usuarios deberán grabar el gameplay para publicarlo luego.
    • Definir un máximo de usuarios en linea sin lag.
    • Definir el máximo de usuarios por API.
    • haciendo que no se posible que haya más de X usuarios en linea.
    • No podemos cobrarle a nadie, no corresponde que pongan dinero.
    • Ellos deberían de cobrarnos por probar el videogame.
    • El videogame debería de verse finalizado
    • O bien el equipo de QA (los usuarios de prueba)
    • Deberían de clasificar la experiencia como 7/10
    • Y darnos feedback necesario para corregir y avanzar.
    • Cuando ellos den el ok, se debería de comenzar la fase de publicidad.
  • Transmisión en vivo 
    • Hacer un guion que haga al usuario girar alrededor de mapa.
    • Arrancar un equipo.
    • Crear de nuevo el usuario cameraman.
    • Enviando la imagen en vivo a el canal.
    • Poner la imágen del video en vivo como fondo de la aplicación.
    • Remplazando el fondo gris.
    • Llegado acá las cosas deberían de verse con más onda.

Mal humor

Parece que el cannabis, puede hacer que uno se de cuenta, o pueda observar, las razones por las cuales, uno mismo está de mal humor.

Y algunas cosas más. Alguna forma de claridad producida por el THC, alguna forma de paz “energica” producida por la mezcla indicada con CBD.

Desarrollando un videogame: revision 16

Revisión 16. Bueno… cuando se finalice con cada una de las cosas marcadas en la revisión 16, podríamos decir que hemos lanzado.

La revisión 16 propone ser la revisión final, aunque no quiero darle ese nombre aún (sin embargo quizás al día de hoy el nombre sea revisión final), dado que aún desconozco si habrá más cambios a ser realizados.

Previo a armar la revisión 16, probé el videogame y la aplicación por al menos unos 40′, por lo que espero que no me haya quedado nada sin mencionar.



Duele un poco saber que queda mucho por hacer, aquí la revisión final:

  1. 30% o 20% de referral bonus
    1. 20% de las ganancias de la casa van para socios.
    2. Válido solo por el primer mes.
    3. Las xfers se realizan al alcanzar los 10,000
  2. ✓ Removemos el AFK… es un problema y no añade nada.
  3. ✓ Creación de avisos por medio de divs
  4. ✓ Hacer andar las 4 solapas del menú final.
    1. ✓ hacer funcionar la solapa de usuario.
    2. ✓ hacer funcionar la solapa de balance.
    3. ✓ hacer funcionar el 2FA
    4. ✓ hacer funcionar la eliminación de usuario.
    5. ✓ conexiones armadas.
    6. revisión necesaria.
  5. Añadir las 15 versiones de cada sonido.
  6. ✓ Más feedback:
    1. ✓ Feedback cuando un usuario spawnea.
    2. ✓ Feedback cuando compra un poder.
    3. Feedback cuando elimina a un enemigo.
  7. Procesar los passwords usando SHA256.
  8. Crear nuevo password en proceso de recuperación.
  9. ✓ Sacar al usuario cuando el balance es mínimo.
  10. Salvar los pedidos que se hacen afuera en db
    1. Incluyendo el usuario, el pedido, la hora y el feedback
    2. correr una prueba a fin de crear información
    3. enviar la información para que sea analizada
    4. por el equipo de block.io por mail.
  11. Crear dos usuarios con AI que corran fuera del servidor
    1. para usar más AI
    2. conservando liviando el servidor.
    3. hacer la conexión al servidor que se especifique.
    4. llenar la información de acceso.
    5. comenzar a circular
    6. cooperar, y no abrir friendly fire.
    7. con un un balance inicial de 50,000
  12. Replicar servidor en varias ubicaciones.
    1. Mover el index, y ponerlo de lado.
    2. crear subdominios para cada servidor.
    3. colocar los enlaces para cada subdominio en el index.
    4. cada servidor deberá disponer de un mapa único.
  13. hacer andar links en /war/ de manera que los links queden:
    1. …com/cashier/
    2. …com/cashier/receive
    3. …com/cashier/send
    4. …com/cashier/xfer
    5. …com/leaderboard/
    6. …com/advices/
    7. …com/profile/
    8. …com/profile/overview
    9. …com/profile/balance
    10. …com/profile/mfa
    11. …com/profile/erease
  14. de forma adicional, debería crearse:
    1. …com/user/chris
    2. …com/clan/ccc
  15. considerar la creación de un wordpress para crear más links.
  16. revisar las palabras claves y variables de seo en la web principal.
  17. ✓ El leaderboard o la sidebar, debería de medir:
    1. ✓ 520 en una resolución de 1920 o mayor
    2. ✓ Anclado, creando un espacio visible de 1400
    3. ✓ Considerar dimensiones y movilidad en resoluciones menores.
    4. ✓ Incorporar discord a la barra.
    5. ✓ Incorporar “send feedback” en la barra.
    6. ✓ Haciendo cambios de diseño
  18. Remplazar la imagen de espera con imágenes de acción
    1. Las imagenes deberían de ir cambiando
    2. del mismo modo que las recomendaciones.
    3. Considerar la posibilidad de que sea un video
  19. Redes sociales deberían de incluirse en index.
    1. mencionar Discord.
    2. mencionar Facebook.
    3. mencionar…
  20. Realizar pruebas.  Sabado 01/09
    1. Definir un máximo de usuarios en linea sin lag.
    2. Definir el máximo de usuarios por API.
    3. haciendo que no se posible que haya más de X usuarios en linea.
    4. No podemos cobrarle a nadie, no corresponde que pongan dinero.
    5. Ellos deberían de cobrarnos por probar el videogame.
    6. El videogame debería de verse finalizado
    7. O bien el equipo de QA (los usuarios de prueba)
    8. Deberían de clasificar la experiencia como 7/10
    9. Y darnos feedback necesario para corregir y avanzar.
    10. Cuando ellos den el ok, se debería de comenzar la fase de publicidad.
  21. hacer que funcione sin problemas la versión mobile del videogame.
    1. incorporando las funciones necesarias
    2. evaluación de la versión mobile, única para mobile.
  22. Realizar inversiones en publicidad
    1. Conseguir al menos 1,000 usuarios en db.
    2. considerar al menos una inversión de $5,000 usd.
    3. evaluar los ingresos generados por los usuarios
    4. y el feedback recibido por los mismos.

Desarrollando un videogame: revision 15

Una conversación por email sobre la API.

Algunas cosas que no llegué a mencionar en el blog porque preferí resolverlas, sin hacer demasiadas menciones. Quizás a veces, se vuelve más fácil, resolver el problema o salir del paso sin hacer incapié, reflexiones o menciones del problema.

Claro que no es siempre, algunas veces parece ser necesario expresar la idea, escribirla y mirarla un poco desde afuera, poniendo a la idea esa, en algun lado donde se pueda leer, observar, que no sea la propia imaginación.

En fin, acá algunos mails:


I can’t tell anything precisely about the calls I’m executing as I have many, in a 1,500 lines PHP API, connected to another 1,500 lines game made in Node, which is multiplayer… so basically 1 player could be executing some calls thru the API in some specific order as another one is doing something else completely different.

We’re gonna need some kind or report system, if you have something already done, please let me know as it will be really useful to analyse and optimize once we have more players.

Kind regards;
Chris C. Russo

El 24/08/2018 a las 06:55 p.m., Block.io Team escribió:

Hi Chris

Can you tell us how you’re executing the calls? What calls are you executing? What is the timing in between calls? What responses do they return and what did you expect them to return?

Support Team
Block.io, Inc.

On Thu, Aug 23, 2018 at 6:24 PM, Chris C. Russo wrote:

Hi,

At this moment I’m working on the integration with your webhooks in order to reduce the amount of requests as much as possible.

The mentioned issue happens, when there’s at least 4 to 5 players, and each one is doing requests into our API, which goes to yours. Perhaps we can schedule a day during the next week in order to test this trying to reproduce it?

Kind regards;

Chris

El 23/08/2018 a las 07:50 p.m., Block.io Team escribió:

Hi Christian

We’ll need more information to replicate the issue you see. Is this happens once, it should happen again (should be replicable). Are you able to reproduce this? How?

Support Team
Block.io, Inc.

On Wed, Aug 22, 2018 at 9:38 PM, Christian C. Russo wrote:

Hi,

We have been testing a game using block.io as background, to process all the bitcoin transactions. We have found that at some point the API doesn’t longer return the expected data, and all user’s balances go directly to zero.

We have now upgraded our plan and I’m trying to find where we could optimise. I understand I could now get the balances using web hooks instead of making a request from our end, however I’m not sure if the problem previously described was caused by balance requests or by the multiple small transfers that could be done during the game play.

Do you have any kind of records where we could look up which queries overwhelmed the previous plan in order to know where we should optimise?

Thanks in advance for your help, and let’s hope for a long term partnership! Kind regards; Chris

Desarrollando un videogame: revision 14

Bueno, ya casi andamos, y ahora no es muy claro como seguir, diversas de las fallas que se ubicaron fueron corregidas, solo quedan hacer que accedan miles de usuarios… de algún modo.


Revisión 14:

  • ✓ Reducir los pedidos a la API para no perder conexión.
  • ✓ Corregir cálculos de ganancias.
  • ✓ División y revisión de la API.
  • El canvas en vivo para usuarios offline.
  • Revisión de links en /war/
  • Menciones:
    • Nombre y apellido de cada uno.
    • Sería bueno que sean muchos.
  • Incorporación de sonidos.
    • Comprar un poder.
    • Cuando se pueda.
  • Simples:
    • Hacer funcionar el feedback
    • Cashier: incorporación del QR.
    • Anuncios podría haber más info.
    • Balance: devolver cada una de las xfers del usuario.
    • Usuario: devuelve información del usuario.
  • Sacar al usuario cuando se queda con poco dinero.
  • Remover la desconexión del usuario.
  • Anunciar en los foros para buscar más cooperación.

Desarrollando un videogame: revision 13

Preludio.

Bien, se resolvieron varios problemas que se daban a la hora de calcular el balance del usuario. La API realizaba los cálculos de balance a medida que realizaba las operaciones sobre la red de blockchain, pero solo considerando los valores de cada operación y aplicando los mismos sobre los valores ya definidos en la db.

Ahora la aplicación revisa los valores en el blockchain, para luego escribir los mismos en la db, de manera que aunque se pierda la sincronización, el próximo refresh de la aplicación, volverá a poner la db con los valores del blockchain.

Sería ideal que, previo a lanzar, se resuelvan:

  • ✓ División y revisión de la API.
  • ✓ Página de bienvenida o index.
  • ✓ La conversación en vivo para usuarios offline.
  • ✓ La conversación en vivo es prorrogable.
  • ✓ El leaderboard en vivo para usuarios offline.
  • ✓ Si se lograra poner en fullscreen sería ideal.
  • ✓ Incorporación de más voces y sonidos
  • Sacar al usuario cuando se queda con poco dinero.
  • Realizar pruebas con al menos 5 usuarios en linea.
  • Realizar pruebas con al menos 10 usuarios en linea.

Segunda revisión, casi finalizado:

  • ✓ Página web principal.
  • ✓ Full screen
  • ✓ Remover discord
  • Revisión de links en /war/
  • Iconos:
    • Icono de Discord.
    • Icono de SW.
    • Icono de Green Address
  • Menciones:
    • Nombre y apellido de cada uno.
    • Sería bueno que sean muchos.
  • ✓ Incorporación de sonidos.
    • ✓ Comprar un poder.
    • ✓ Cuando se pueda.
  • Simples:
    • Hacer funcionar el feedback
    • Cashier: incorporación del QR.
    • Anuncios podría haber más info.
    • Balance: devolver cada una de las xfers del usuario.
    • Usuario: devuelve información del usuario.
  • Sacar al usuario cuando se queda con poco dinero.
  • Remover la desconexión del usuario.

Después de lanzar:

  • Acción en vivo para usuarios offline
    • Los usuarios sin player deberían ver la acción.
    • Quizás se pueda seguir a algún enemigo.
  • Servidores auxiliares:
    • Servidor mayhem: balas sacan 50% de vida, precios x 1000
    • Servidor profesional: balas iguales, precios al x 100
    • Versión libre, sin blockchain.
  • Información general:
    • Jugadores profesionales / drones
    • Rescan blockchain quedó legacy.

 

Desarrollando un videogame: revision 12

Al alcanzar las 10 kills, los usuarios suben a level 1, en level 1, las municiones son 10% más rápidas y causan 3% más de daño.


Previo a anunciar (cambios finales)

  • ✓ Creación de usuario
    • ✓ El usuario, email y password con el mismo orden.
    • ✓ No es gambling, no es necesario anunciarlo.
    • ✓ El password generado al azar.

  • ✓ Explosiones!
    • ✓ Añadir explosión de unidad previo a desaparecer.
    • ✓ Añadir animación de fuego al ir avanzar dañada.
    • ✓ Añadir explosión al final de las balas.

sudo certbot certonly --webroot -w /var/www/ bow3 -d bitofwar.com -d www.bitofwar.com

sudo certbot certonly --webroot -w /var/www/bow3/web -d bitofwar.com -d www.bitofwar.com

Vale la pena mencionar que es necesario crear primero el espacio de verificación usando:

Parados sobre la dirección /web/


  • ✓ Mucha relevancia:
    • ✓ La carencia de HTTPS!
    • ✓ Modificaciones en el servidor, correr sobre 443.
    • ✓ Generación de llaves y credenciales de prueba
    • ✓ Que los emails no sean clasificados como spam.
    • ✓ Armar el SSL.
    • ✓ Para verificar el SSL es necesario que el servidor corra en 80.
    • Sacar al player cuando no dispone del balance mínimo

Con las dimensiones del mapa en 2500 pixeles2, el número de usuarios en linea debería de rondas de 10 a 15, con un promedio de 12.


  • Cambios menores pero necesarios:
    • ✓ El blockchain rescan que debería correrse solo.
    • ✓ Balance en dólares.
    • ✓ El servidor procesa el balance en dólares.
    • ✓ El usuario lo lee desde el header.
    • ✓ Añadir barra inferior para recibir feedback de los usuarios.

  • Preloader.
    • Más recomendaciones  en el pre-loader.
    • Video de fondo en el pre-loader.

  • ✓ Comunidad en discord
    • ✓ Crear comunidad.
    • ✓ Añadir admins.
    • ✓ Debería haber una comunidad en discord, con la imágen del logo.

  • ✓ Transferencias de usuario a usuario
    • ✓ Programación en la API
    • ✓ Programación en Node
    • ✓ Programación de gráficos

  • ✓ Música y sonidos
    • ✓ Música de fondo.
    • Sonido con las balas.
    • Sonidos al recibir dinero.
    • Sonido con los powerups.

  • ✓ Cambio de imagen:
    • ✓ Cambiar imagen del escudo.
    • ✓ Cambiar imagen de fondo.
    • ✓ Cambiar imagen de la munición.
    • ✓ Cambiar imagen de la unidad.
    • Cambiar imagen del enemigo.
    • Animaciones usando SVG

  • ✓ Problemas con poderes
    • ✓ Precios y duración de los powerups.
    • ✓ Los poderes quedaron en 100 unidades
    • ✓ Igual que la creación de unidad,
    • ✓ Escudo, cien unidades, usando 1
    • ✓ Quickfire, cien unidades, usando 2
    • ✓ Peacemaker, cien unidades usando 3

Después de anunciar (cambios programados)

Clanes, equipos o grupos, como se quiera llamar.

Desarrollando un videogame: revision 11

Evaluación de cambios:

  • Corregir el bug que hace posible subir el balance
  • Dividir la API a fin de que sea más fácil su comprensión
  • Se pasaron las 1,000 lineas.
  • ✓ Alinear al medio.
  • ✓ Hacer que funcione el modal de cashier, simplificar diseño.
  • ✓ Que sea posible enviar dinero
  • ✓ Que sea posible sacar el dinero.
  • ✓ “Blockchain Sync” para buscar nuevas operaciones y calcular balance.
  • ✓ El balance debería de calcularse y recalcularse en “Real Time”.
  • ✓ Quizás la opción más simple sea pegarle a sync cada 5 segundos.
  • Después se puede cambiar y armar hooks.
  • ✓ Resolver problemas de email como spam.
  • Las unidades deberían aparecer con un buen shield.
  • ✓ Añadir barra inferior para recibir feedback de los usuarios.
  • Seria recomendable mover la API a AWS
  • Para que queden en LAN, pero no imprescindible.
  • ✓ Definir, duración y demás variables de los powerups comprados.
  • ✓ Sacar la sombra del canvas… no queda bien cuando se mueve.
  • ✓ Aunque quizás se pueda remplazar por un visor de alguna manera.
  • ✓ Creo que lo ideal es remplazarlo por 1 pixel invisible, por si las dudas.
  • ✓ Solo un div, se conservó.
  • ✓ Una vez finalizado el nuevo cashier y el “blocksync”
  • ✓ Se hace posible enviar y sacar dinero sin problemas.
  • ✓ Por lo cual es recomendable correr una prueba privada.

  • Creación de espacios sólidos:
    • Si fuera posible crear espacios sólidos
    • Sería posible armar mapas más avanzados.
    • Se podrían incluír algunas ciudades conocidas!
    • Se podrían enviar a diseñar basándonos en mapas.
  • Incorporación de música:
  • Incorporación de sonidos
  • AI based gamers
    • Al menos debería de haber unos 5 usuarios con AI:
    • Para que los primeros no se aburran,
    • De ser complicado será necesario evaluar
    • Como y a quienes se le puede pagar por usarlo.
  •  Moderadores:
    • Debería de haber usuarios moderadores,
    • Los cuales no puedan eliminar unidades.
    • Deberán llevar un escudo y dar paseos por el mapa.
    • No podrán sacar el dinero de la aplicación.

Evaluando los números:

Para responder algunas dudas que me surgieron, cree un cuadro calculando posibles ganancias:

Realizando cambios en las variables, se pueden ver algunos números increíbles: podemos asumir que compran menos poderes, pero a un precio algo mayor, digamos que cambiamos el promedio de 0,0001 a 0,00025 y disminuimos la compra a 8 por hora, y disminuimos a 32 usuarios: