Desarrollando un videogame: revision 20

Livianas:

  • El usuario puede definir su password.
  • Información cuando hay errores de creación.
  • Información cuando hay errores de acceso.
  • Eliminar simbolo de dolares.
  • Eliminar funciones de conversión a dólares.
  • (Tuna) Nueva animación de player en llamas.
  • (Tuna) Variación de color ínfima en él header.
  • (Tuna) Diseño de información (kills, compra de powerup, so on)
  • Armar los 3 iconos de los 3 powerups nuevos.
  • Modificación de colores en munición.
  • Crear gráficos balance con información.
  • Los graficos se llenan ambos sin problemas, se sacó el color de fondo.
  • Cambiar fondos del gráfico segun corresponda.
  • Remplazar los sonidos por los nuevos, con urgencia.
  • Añadir clase de animación.
  • Animación explosiones nuevas.

Pesadas:

  • Nueva modalidad opcional:
    • Game runs cuando hay 4 players online.
    • Game ends, cuando queda solo 1 player en el campo.
    • 20 powerups por usuario, sin cargo.
    • Cada player pone 4,000 el que gana se lleva la banca.
    • Zombies desde las esquinas, cerrandose hacia el medio.
    • Para eliminar a uno de los dos cuando se cuelgan.
    • Duración máxima de la ronda operada por zombies.
  • Creación de Game menu
  • Modificaciones serias en canvas previo a empezar.
  • Rearmar la versión con BTC.
  • Desarrollo de AI.

Vinculadas:

  • Armar logo de Psychedelic Games
  • Armar web de Psychedelic Games
  • Armar emails de Psychedelic Games
  • Presencia en redes sociales

Opcionales:

  • Expandir los mapas?
  • Generación de muros al azar?
  • Creación de rondas?
  • Comenzar ronda cuando hay 5 players ready?

 

 

 

 

Desarrollando un videogame: revision 19

Revisión 19

Solucion al problema de las animaciones en el canvas. El canvas no puede usar SVG dado que no cumple las policies (no funciona en Firefox y es probable que luego no funcione en demás browsers).

Resolver el problema por medio de Canvas Sprites animations: https://jlongster.com/Making-Sprite-based-Games-with-Canvas

Creo que el drone del link podría remplazar a el drone que usamos. Lo mismo con las explosiones y quizás la munición?

(1) ✓ Apenas se crean un usuario, hay que logearlo de una, y quizás aún, incluso spawnearlos. Razon: anuncie en algunos lados para ver que pasaba, y algunos usuarios fallaron al memorizar el password, y o no pudieron logearse después de crear el usuario (crearon el usuario, nunca se logearon).

(2) ✓ hacer de alguna forma que FA funcione con el nuevo dominio… ¿no habrá manera de darle un wildcard?

3) verificar que la dirección de email sea válida en JS previo a enviarla al servidor, y revisar del mismo modo en el servidor que sea válida… Razon: usuarios llenando el campo con “asd|@fasd” y “pmdit.dev bitofwar@gmail.com”

La verificación del mail se puede hacer por medio la clase email en el HTML y creo que debería de ser hecha de esa manera. Habría que informar cuando el mail es válido o invalido en el diseño, y habría que prevenir el envío el formulario si posee campos inválidos. la clase email posee propiedades css :valid e :invalid, habría que aplicarlas.

(4) ✓ Sacar el ruido de las monedas cuando los usuarios mandan feedback, el ruido de las monedas debería de pasar solo cuando hay un cambio de balance para los usuarios, en un solo lugar, la app (cside) debería de verificar cuando se mueve el balance, y si subio reproducir a, si disminuyó reproducir b, si es el mismo, nada. Razon: usuarios mandando feedback varias veces porque escuchan ruido de monedas.

(5) ✓ Corregir la sombra del drone, razón: recomendado por varias personas… debería de ser más chica, y más pegada a la unidad para no dar la impresión de que se mueve la cámara.

Bien, se pueden hacer algunas cosas copadas usando SVG por lo que parece! Sería bueno coordinar una reunión más con Tuna para ponerle varios SVG a las unidades. Se podría usar un marcador como:

(5.1) ✓ Me fui por las ramas: los usuarios que se quedan sin fondos, respawnean como drones, si salen de la aplicación y vuelven a ingresar, pueden volver a ingresar como drones sin problemas.

Los drones ahora se mueven a 0.5 vmag, en comparación de las unidades convencionales que se muven a 0.3 vmag. Al hacer click izquierdo los drones ahora suben de velocidad, para desplazarse a un indice de 3, lo cual equivaldria a 1.5vmag, si no me equivoco.

(6) ✓ Se hicieron varios cambios en el servidor de brasil, quizás sea una buena idea crear una AMI nueva desde ahí.

La versión final de la AMI fue clonada y replicada en los servidores necesarios.

(7) ✓ Muy necesario organizar una nueva prueba en LAN como hicimos, las pruebas online no son fáciles de coordinar. Las pruebas en LAN parecen darnos mucha información en solo un día.

Procurando hacer una prueba en LAN a la semana, comencé a armar una red de 8 equipos en casa para poder probarlo.

(8) ✓ En caso de que la nueva prueba en LAN funcione bien, es necesario realizar una prueba en LAN, pero usando el servidor libre de san pablo, para ver como funciona el servidor y la conexión… creo que con un modem de 30 megas deberíamos poder correr 8 conexiones a la vez.

Encaminado. Los servidores quedaron con nuevos nombres, los cuales luego mencionaré.

(9) Hacer que se pueda poner el password de una en la creación de usuario.

(10) ✓ hacer que el cuadro de usuario se vea solo cuando el usuario ya accedio, user online.

(11) ✓ hacer que el cuadro de información de usuario se cargue con el leaderboard o bien el re-scan blockchain.

(12) hacer que la función leaderboard y rescan blockchain sean la misma, quedando una sola función que realice las 3 acciones (información del usuario, leaderboard, y balance).

(13) remplazar los iconos de los poderes por boxes para que no se sepa lo que poseen.

(14) ✓ acomodar la bronca de los powerups para que sean, por lo general, menores a los poderes del suelo.

Sería ideal ver como funcionan los powerups en una prueba real en área local, la cual debería de ser coordinada una vez finalizada la ronda de desarrollo.

Hecho! Ya funcionan bien, el game balance looks good! Se hicieron varios cambios en las armas y los valores a fin de buscar un equilibrio.

(15) ✓ solapa de rooms nueva en ambos lados.

(16)  Al hacer click en el icono de bow de la izquierda, en la app, debería de ir hacia la página principal.

(17) colocar SSL sobre el S3, index.

(18) ✓ Colocar los dos modulos que quedan en el index. (live video y servidores).

(19) remplazar la imágen del index por videos en vivo, para hacer eso es necesario filmar un par de videos en full screen y subirlos.

(20) ✓ incorporación de información sobre el canvas, como se ve en la imagen. Es posible que aún queden más incorporaciones necesarias, pero hemos logrado armar la base. El servidor usa los mismos socks para comunicar cuando pasa algo! funciona!

(21) ✓ Darle un drone al usuario apenas empieza y darle la opción de spawnear una unidad? El usuario ahora puede spawnear un drone si es que no dispone de fondos. Es válido en especial para la versión paga, ya que pueden usar un drone para mirar un poco en vivo.

(22) El dialogo de respawn debería de aparecer cuando el usuario es un drone. Debería de buscar la manera de modificar la condición del usuario para que no de el error “User already online”.

(23) ✓ En caso de hacerle un hack y agregarle funds, o bien, añadiendo de nuevo la solapa cashier, pero solo con los giros de usuario a usuario, y dandole dinero, el usuario podría volver a spawnear como unidad sin problemas. El drone debería desaparecer del mapa.

(24) ✓ La sidebar: debería de aparecer de una apenas el usuario accede. Debería de salir de una, apenas el usuario crea una unidad.

La sidebar solo es visible cuando el usuario no posee un player, osea, apenas comienza. En el campo, el usuario puede ver una versión reducida de la sidebar.

(25) ✓ Considerar subirles la vida inicial a las unidades. Ahora en 10, quizás 20?  Se realizaron cambios, la vida ahora es de 20 y se modificó la visualización, creo que es más claro y revela más información.

(26) solucionar problema con las keys que no se van… el usuario puede quedar colgado, girando en círculos.

(27) ✓ Modificaciones en user/balance, el value aparece como undefined… que le pasa?

Solucionado, había algunos problemas con los nombres de variables que no concordaban y unas variables que nunca se calculaban (difference vs diference)…

(28) ✓ Hacer que funcione el 2FA… ya viene así desde hace unas 10 revisiones lol. Genial, me animé, lo hice, al fin… ya no se podía posponer más!

El único problema es que solo armé el mecanismo y no lo enchufé a la API, pero bueno, eso ya es más simple… por lo que parece va a ser necesario crear una columna en la db para almacenar el password del google_au, luego el usuario solo pone el número y si el numero concuerda con las llaves, las cosas validan para el.

Las operaciones en PHP se ven simples de verdad, no parece que fuera a ser complicado.

(29) Dimensiones de visibilidad máxima en 2500 pixeles, revisar dimensiones del usuario, y aplicarlas como máximo, solo en caso de que sean inferiores. Enviando así, siempre, como máximo 2500 pixeles de información. Como excepción, se enviará menos para reducir el consumo de recursos en el servidor y usuario.

(30) Creación de paredes y muros, defensas. Si disponen de un área de choque, se pueden usar.

(31) ✓ La musica puede lograr enloquecer un poco al usuario. ¿Quizás ponerle un music player?

Genial, Tuna ya le incorporó un menú desde donde se pueda sacar la música sin problemas.

(32) Considerar nueva modalidad, que espere a unos 10 players previo a comenzar. Haciendo uso de un mecanismo que cuando se sume un player real, mande 1 AI cada 6 a 12 segundos. De manera que en menos de 60 segundos se llene un room.

(33) ✓ Ok, cambio de planes, quizás sea preferible sacar los servidores del home, y enviarlos de una para los servidores de prueba, habría que subir 3, uno en brasil, uno en londres, y uno en usa. De hecho, habría que comenzar solo por el servidor de pruebas de USA.

(34) ✓ Lanzar publicidad usando solo el servidor de pruebas de USA y ver como responden los usuarios, después de haber realizado las pruebas a nivel de área local. Para decirlo aún más claro: una véz que Bow sea a rich videogame, enriquesido en muchas, pequeñas posibles acciones y funcionalidad. Se debería de hacer publicidad como videogame.

(35) ✓ Para luego lanzar la versión en BTC. Claro que eso no es más que un plan, y en verdad no se cual es la forma más sencilla de darle popularidad a la aplicación.

Se crearon y definieron los servidores:

  • play: normal con blockchain
  • playground: normal sin blockchain, se dan 30,000 al ingresar.
  • research: research ubicado en brasil, se usa para probar cosas nuevas.
  • powerless: versión normal con blockchain, libre de powerups.
  • ai: sala de guerra de maquinas, para probar AIs.

(36) Incluir civiles o zombies que avancen corran por el mapa y puedan ser eliminados disparandoles o pisandolos.

Desarrollando un videogame: revision 18

Problemas localizados en las pruebas del Sabado 01/09/2018

Después de las pruebas realizadas el sábado pasado, el día de ayer, se pusieron en evidencia varios problemas y errores. Dado que la reunión se hizo un poco más larga de lo planeado, volví a casa preparado para dormir, y mi primera observación fue hoy domingo después del medio día. Hagamos un repaso de los problemas que observamos:

1) El balance a veces se iba a cero y nadie podía acceder. El problema se da por la conexión con la API del blockchain, en especial, porque pasamos las máximas de la API haciendo más de 8 operaciones por segundo. Hay que reducir los pedidos a la API y subir de plan.

2) No se pudo usar el servidor de Sao Pablo. Desconozco las razones, puede ser que haya sido porque la conexión local andaba muy exigida, o bien, porque el servidor no alcanzaba con los recursos, o ambas cosas a la vez.

3) Cuelgues generales de la app donde el balance no se iba a cero, pero no se podía mover las unidades. Sospecho que fue la conexión de área local de nuevo, pasada por la exigencia de información que enviamos por segundo, y es probable el hecho de que el servidor corriera desde una placa inalambrica no ayudara.

El servidor debería de llevar una conexión por cable para que eso no pase, y sería bueno que la conexión de los usuarios al servidor sea más rápida, el wifi conlleva mucha perdida de información. Asumo que vimos boundaries propias de la red de área local vs los 2 servidores que usamos auxiliares.

4) El dinero en el blockchain en sí. Muchos se quedaban sin fondos y no podían probar el game… hay que hacer una versión libre de prueba, y una versión en blockchain, clonando las dbs y generando una API auxiliar para evaluar sin la red. Los players deberían de empezar con 50 vidas en el servidor de research.

5) Feedback e información visual. La aplicación debería de explicar más claro:
– porque el usuario salió.
– cuando eliminas a alguien
– cuando sos eliminado.
– la compra de poderes.
– y algunas cosas más que no se explican bien.


La manera más fácil de sacar el *card sobre AWS es con:

sudo certbot -d *.bitofwar.com -d bitofwar.com –manual –preferred-challenges dns certonly


Breve plan de acción

  • Creación de una versión blockless
    • ✓ Se saca el dinero que quedó en block.io
    • ✓ Armar una replica 100% funcional en local.
    • ✓ La creación de una versión que no use blockchain.
    • ✓ Se saca la solapa de cashier dado que se vuelve innecesaria.
    • ✓ Los usuarios reciben 50,000 dolares al comenzar.
    • ✓ Los poderes se conservan a fin de evaluarlos.
    • ✓ Se duplica la API, sacando las operaciones con block.io
    • ✓ Se duplica la db, simplificándola.
    • ✓ En fin, se arma una versión clonada de la app, pero sin blockchain.
    • ✓ La versión se crea y será usada para hacer cambios de diseño
    • ✓ Evaluar la lógica de la aplicación, hacer pruebas,
    • ✓ Hacer posible que los usuarios prueben el game sin dinero.
    • ✓ Armarlo y hacerlo correr de modo local.
  • ✓ Poner en linea servidor
    • ✓ Poner en linea opensaopaulo.
    • ✓ Con la versión más fresca.
    • ✓ Probar la aplicación buscando posibles errores.
    • ✓ Armar nueva revisión en base a las correcciones necesarias.
  • ✓ Modificaciones gráficas y funcionales.
    • ✓ Barra de vida visible (main frame),
    • ✓ Barra de escudo visible (main frame),
    • ✓ Dinero visible (main frame)
    • ✓ Compra de poderes (main frame),
    • ✓ Anunciar compra de poderes
    • ✓ Anunciar eliminación de enemigo,
    • ✓ Dar más visual feedback
    • ✓ Dar más audio feedback
  • Pruebas LAN. Sabado 08/09/2018
    • Considerar armar una LAN
    • Considerar armar un cronograma de pruebas.
    • Probar con 6 personas es de verdad muy eficaz.
    • Sería posible aplicarlo a más negocios.

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.

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: