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:

 

 

Leer y escribir el manual

La mayoría de los programadores, sabe que es recomendable leer el manual previo a usar una aplicación.

La mayoría sabe que es preferible escribir el manual o la idea, previo a empezar a programar, o al menos, ir avanzando un poco, a medida que se programa.

No se si hay muchos que además de leer y escribir manuales, deciden escribir sobre ellos mismos, hacer su propio manual, una idea un poco rara.

 

Capas codicionales

Puedo ver las cuerdas. Son cuerdas condicionales, son cuerdas del así es, de lo normal, de lo que es, son las cuerdas que dicen si no me rompés, no podés salir de la condición. Esas cuerdas que hacen que las cosas solo puedan ser True o False. Esas cuerdas que le asignan un valor a las cosas. Esas cuerdas que cuando se rompen, las cosas vuelven a ser opcionales, vuelven a ser indefinidas.

Como un fumador se encarga de crear sus propias cuerdas alrededor de la adicción, cambia la variable indefinida, y comienza a definirla.

Y ahora es necesario hacer un esfuerzo para romper esa cuerda. Y ahora no depende más, solo del deseo.

Esa nueva cuerda de definición, esa capa de rigidez. La semana pasada perdí algunas de esas capas, mi esfuerzo, mis palabras, mis acciones, rompieron algunas cuerdas.

Ahora puedo hacer que el negocio de las visas, funcione o no funcione, casi sin esfuerzo. El esfuerzo ya fue hecho y es pasado.

Ahora, si lo deseo, puedo hacer que el negocio de las visas suceda, casi con solo pensarlo o dar mi “ok” a la persona a cargo de disparar la primera acción para que el negocio suceda.

Ya se probó el negocio y se sabe que va a andar, por lo cual, no hay si quiera dudas. A medida que escribo, se llenan en una mariadb, capas de información financiera de mis compradores, a fin de que sus visas sean procesadas.

El negocio ya es online, funciona a medida que escribo, y funcionará cuando duerma. El negocio es independiente de mi, funciona por si mismo, no me requiere.

Ahora puedo vender o no vender los equipos, adquirir o no adquirir dólares. Ahora puedo cambiar los muebles de luegar, o no cambiarlos, acomodar o no hacerlo, reformular o no reformular.

A medida que se pierde la necesidad de hacer esfuerzo por realizar algo, las cosas quedan en un plano de indefinición. El mañana pasa a ser miles de posibilidades.

La familia siempre funciona como un ancla, o una cuerda, que lo ponen a uno sobre un grupo de posibilidades iniciales.

Se podría decir que uno hace esfuerzos para romper esas cuerdas. Liberarse de esas cuerdas que a uno lo anclan a posibilidades, cuando la cuerda se rompe, solo es necesario el deseo para que la acción se cumpla.

Podríamos decir:

Como ya mencioné, el negocio de las visas, ahora parece solo depender de deseo, en consecuencia, es posible o no posible con solo desearlo.

Podríamos formular que uno pone deseo + esfuerzo en una empresa, luego la empresa solo depende del deseo. Cuando la empresa solo depende del deseo, la empresa es indefinida, es y no es.

Si se perdieran cada una de esas capas de condicionales, esas cuerdas, esas capas de rigidez, moriría.

O por decirlo desde un nuevo angulo, la única forma, de perder cualquier condición, cualquier cuerda, y volver a la infinidad de posibilidades, es morir.

En las profundidades de una emulación o un sueño lúcido ideal, sería posible acercarse mucho.

Acomodar la casa

Quizás sea hora de acomodar la casa, lo que habría que hacer, es:

  • Segundo piso:
  • Eliminar la pared divisoria, de modo que quede solo un espacio.
  • Luego se puede dividir de cualquier forma.
  • Colocar piso de madera en el espacio, o bien una replica de madera.
  • Remover la pared del final, quizás debería de haber unos paneles corredisos.
  • Comprar alfombras.
  • Ver de que funcionen y ubicar bien los 7 equipos que aún quedan.
  • Ver como ahorrar un poco más en energía.
  • Armar librería.
  • Armar un invernadero parcial.
  • Primer piso:
  • Hacer que los dos placares queden en fila
  • Revelando la escalera.

 

 

 

Desarrollando un videogame: revision 10

#1 Acabo de enviar un mail para sacarme algunas dudas sobre como cobrar las comisiones de la casa:


 

Realizando los pagos así, podemos observar algo cercano a un 15% de perdida por cada unidad creada, y no son pagadas al saas (block.io), sino a la red de la moneda.


Si volvemos a correr la prueba:

Podemos observar como los fees cambian como si fuera mágia de 1442 a 618, Lo que para el caso equivale a una variación de %14 a %6, que no es para nada poco. Debe de haber una forma ideal para realizar esas operaciones.

Veo que es necesario que alguien cree una solucion a los “micropagos” porque las comisiones a veces son caras cuando los pagos son pequeños:

Quizás pueda buscar un servicio preferible a block.io. Al día de la publicación el servicio anunciado en coindesk no se ha finalizado…  🙄


#2 Se creo un nuevo record en la db para supervisar las xferencias, dado que seguir el dinero es algo más complicado de lo que pensé.

Volvemos a las bases, al suelo. Comenzamos por lo que es imposible de evadir: los usuarios deben poder crear sus direcciones, enviar y recibir pagos desde las mismas.

Se crea xfers en la base, y se reune la información de las operaciones en blockchain.

  1. ✓ Al crear un nuevo usuario se le genera una dirección.
  2. ✓ Se busca si la dirección posee nuevas operaciones / o información
  3. ✓ Cuando el usuario envía dinero a esa dirección
  4. ✓ Se añade la nueva operación a mariadb.xfers con la información del usuario.
  5. ✓ Se realiza la conversión a micro, simple pero crucial.
  6. ✓ Solo una vez que la operación dispone de 3 confirmaciones,
  7. ✓ Se le suma el balance al balance que posea en mariadb.users
  8. ✓ Ahora solo esperamos 20′ y hacemos la operación inversa
  9. ✓ El usuario pide un envío del 100% de su dinero a su dirección personal.
  10. ✓ Revisamos si el usuario posee los fondos que pide.
  11. ✓ Marcamos la operación en mariadb.xfers.
  12. ✓ Reducimos el dinero pedido del balance en mariadb.users
  13. ✓ Enviamos de el dinero de nuevo a la dirección personal del usuario.
  14. ✓ Llegado acá es necesario analizar como realizar los pagos “in game”.

  1. ✓ Llegado acá es necesario hacer la misma prueba al menos 3 veces más
  2. ✓ A fin de resolver diversos bugs que quedaron.
  3. ✓ Archivar las direcciones creadas
  4. ✓ Creando una nueva dirección única por usuario.
  5. ✓ De ser necesario, eliminar diversos usuarios, o bien,
  6. ✓ Vaciar mariadb.users
  7. ✓ Vaciar mariadb.xfers
  8. ✓ Crear nuevo usuario, analizar proceso de creación de address.
  9. ✓ Realizar una nueva xfer, analizar proceso de validación.
  10. ✓ Confirmar desempeño en localización de una nueva xfer sin confirmar.
  11. ✓ Confirmar desempeño en supervisión de una xfer esperando confirmar.
  12. ✓ Confirmar que el dinero se marque en balance.
  13. ✓ Modificar el guión para pedir el envío del dinero disponible.
  14. ✓ Pedir el dinero una vez que no pueda superar user.balance
  15. ✓ Crear un segundo usuario y enviar el dinero desde una green address.
  16. ✓ Supervisar de nuevo el proceso.
  17. ✓ Analizar posibles diferencias.
  18. Como era de esperarse, usando greenaddress con segw
  19. Las comisiones son infimas, y las confirmaciónes muy rápidas.
  20. Podemos usarlo en vivo  😎
  21. Resolví el problema de las operaciones!

#3 Añadir cuadro inferior para que los usuarios nos den ideas!

En verdad no se relaciona para nada con la programación del blockchain en sí, pero sería bueno añadir un pequeño div inferior, una barra, para que los usuarios manden feedback e ideas.

18 formas para ganar mucho dinero

1. corruption, corrupt your way to listening on exchanges indexes. like ripple did that, but you have to be very rich for that. crypto has in general a huge issue with opening the door for rich to stay rich or get even richer.

2. find a group of people that works for free, like satoshi did, with the bitcoin sect/cult in this forum

3. be persistent.

Hard work pays off one way or another. If you won’t succeed in that particular ICO, you gonna gain experience and improve you future steps. Not everyone is looking for shortcuts, some people genuinely enjoy the whole process of pursuit of success.

Desarrollando un videogame: revision 9

Chris, alrededor de las 7:00 PM

Al día de la fecha, el primer videogame casi concluído y online. Solo queda la conexión final al blockchain, que sería usada de manera exclusiva cuando un usuario quiere enviar o sacar dinero de la aplicación.

De esa manera, los balances de cada usuario no son más que información almacenada en el servidor, sin realizar operación alguna sobre la red de P2P, a excepción del ingreso y el egreso de la misma.

Se comienza a diseñar la infra usando los servicios de blockchain.info

Porque las personas prefieren publicaciones con imágenes a leer! Una imagen del dialogo de ayuda del videogame.


#1 Creación de direcciones rápidas para cada usuario:

Las direcciones rápidas se crean una vez para cada vez que el usuario desea ingresar dinero. Cada vez que un usuario desea hacer un nuevo ingreso de dinero, una nueva dirección rápida debe ser generada y nunca eliminada.

Sin embargo, considero que nunca debe ser creada una nueva dirección rápida para un mismo usuario, sin haber usado la previa.

Se crea una dirección rápida única para cada usuario, cualquier dinero que ingrese a la dirección rápida de un usuario, será considerado dinero de ese usuario.

Función: Las direcciones rápidas de cada usuario esperan a recibir dinero de un usuario, para luego reenviar el saldo a la dirección rápida principal.

Ubicación: nubes de blockchain.com + servidor


#2 Creación de dirección rápida principal usada por el videogame.

El dinero de la dirección rápida principal llega desde las direcciones rápidas generadas para cada usuario. Es el lugar donde se reúne el dinero de cada uno de los usuarios.

El dinero no se mueve de ahí, y debería de poseer la mayor seguridad posible, por obvias razones. Hay dos opciones posibles para que el dinero salga de aquí:

  • Usuarios: un usuario desea sacar dinero de su balance disponible.
  • Empresa: la aplicación envía su margen de ganancias hacia la dirección fría.

Ubicación: nubes de blockchain.com + servidor. En caso de robo: se pierde el dinero de los usuarios y se daña la imagen de la empresa.


#3 Creación de dirección fría de cobranzas:

Quizás la razón, quizás el porque, quizás no debería escribir poesía acá, ¿por que no? pienso, porque no es la convención, porque no es adecuado.

So, la dirección fría de cobranzas es la dirección final, donde va el dinero de cada una de las cosas que la casa cobra, como la creación de una nueva unidad, que al día de la fecha, equivale a 100 unidades.

En caso de que el día de mañana se incorpore una compra rápida de powerups, ese mismo dinero, primero sería deducido del balance del usuario, y luego saldría de la dirección rápida principal, hacia la dirección fría.

Nunca saldría el dinero de la dirección fría, salvo para cobrar el dinero, o las ganancias de la empresa. Es igual al banco de la empresa de videogames. Es el banco de la empresa de videogames.

Ubicación: La memoria de un cablemodem surfboard sb5100, escondido en una pila de hardware desarmado, un pendrive, y la página de algún cuaderno.

En caso de robo: se pierden las ganancias acumuladas de la empresa y los usuarios no lo percibirían, y podría pasar a la vez que los usuarios siguen usando la aplicación.


Comenzamos: problema #1

Chris, alrededor de las 9:00 PM

Dado que la conexión a blockchain.com requiere de un pequeño dimen“daemon”, un mini servidor en node, el cual procesa pedidos solo recibidos desde 127.0.0.1, es necesario poner la API en PHP y el servidor de node, en el mismo lugar.

Considerando que he venido usando dos servidores (uno en américa y uno en europa), creo que será más fácil migrar ahora mi servidor europeo, y ubicar el API en PHP, al igual que el dimen en AWS, quedando el 100% del código en AWS.

Previo a hacer eso, considero más simple hacer lo mismo, pero en mis propios equipos, para luego hacer un gran push hacia las dos EMIS de AWS.

Procedo a descargar una copia del API en PHP y la información en la mariadb, a fin de crear una copia 100% funcional desde mi propia maquina.


Modificaciones : problema #2

Chris, alrededor de las 3:00 AM

Después de descargar y armar cada una de las piezas en mi maquina, me vi forzado de alguna manera a cambiar algunas funciones y crear algunas variables para resolver algunos problemas que ya había.

A fin de separar el acceso de un usuario, del spawn y el respawn, fue necesario cambiar algunas funciones, variables y el orden del programa. También se modificó la API,

Más allá de las diversas modificaciónes que se pueden ver, solo quedaría agregar una función que corra la función de desconexión, cuando un usuario no se mueve desde hace más de 1 min.

Habiendo mencionado eso, espero volver en unas horas a los hechos y añadir la función, pasemos ahora al dimen de blockchain.


Primeras medidas

  • ✓ Armar el servidor API de blockchain.com en el equipo <manual>
  • ✓ Maldición, la API de blockchain.info & blockchain.com fallan.
  • ✓ Muchos casos mencionando lo mismo.
  • ✓ Al día de hoy, no anda el formulario para pedir una llave.
  • ✓ Vamos a crear un usuario con block.io
  • ✓ Creación de usuario en block.io
  • ✓ Creación de la dirección principal aka ‘main_address’ <manual>
  • ✓ Creación de una dirección para cada uno de los usuarios previos.
  • ✓ Las direcciones deben corresponder al user_id.
  • ✓ Almacenar direcciones en la db, para luego usarlas.
  • ✓ Por medio de la API:
    • ✓ Creación de una dirección para usuario,
    • ✓ Debería de pasar en a la creación de usuario.
    • ✓ Hace posible que los usuarios envíen dinero a la app.
    • ✓ Se crean direcciones usando bech32 pubkey hash (bc1)
  • ✓ Enviar dinero a una dirección de usuario de forma manual para evaluar.
    • ✓ La primera xferencia fue grandiosa!
    • ✓ Primera validación y confirmaciones muy rápidas en block.io!
    • ✓ Parece no haber cobrado comisión alguna!
  • ✓ Probar xferencia hacia ‘main_address’ una vez que accede el dinero.
    • Se puede apreciar que funciona bien.
    • Es necesario evaluar diversos mecanismos para pagar menos comisiones.
  • Por medio de la API:
    • Sacar dinero de ‘main_address’ hacia dirección especificada
    • Siempre y cuando el dinero sea igual o menor a su balance.

Comencemos por eso…

Desarrollando un videogame: revision 8

Comunicación browser, node, servidor, db:

Acá un breve repaso de como se crean los enlaces y la comunicación de principio a fin. Escribo dado que creo que podría servir ahora y luego para la programación y desarrollo de más aplicaciones similares.


#1 Desde el browser el usuario:

El mismo modal donde el usuario llena la información:

Los ids del nombre de usuario, password y dirección de email son leídos:

  • user-new-email
  • user-new-password
  • user-new-username

Es claro que a ser ids deben ser llamados por un nombre único, a fin de poder localizarlos luego desde el guión cside.


#2 Guión (cside):

La función user_new() se corre al hacer click en enviar el formulario.

Busca la información de los ids que llenó el usuario y envia la misma información hacia la función user-new que corre en el servidor node.


#3 Servidor en node (sside):

La función user-new() recibe la información enviada desde el cside, la organiza y la manda hacia la API:

Dado que la comunicación se realiza desde la aplicación (server) en node, hacia la API, las direcciones de la API nunca son visibles para el usuario, el cual solo podría observar la comunicación hacia el servidor.


#3 API en segundo servidor:

Recibe la información enviada por el node, procesa la información, realizando operaciones sobre mariadb, envía un email y devuelve información.

Para finalizar el ciclo, la información que es enviada desde el API, es procesada de nuevo por el servidor en node, el cual luego, reenvía la información al cside.