Vendiendo visas para USA

Turismo es un rubro donde hay dinero por hacer, y siempre es posible brindar soluciones o simplificar algún proceso a fin de hacer las vacaciones o los vuelos más fáciles.

Además, cuando las personas salen de vacaciones, por lo general, suelen despreocuparse un poco más sobre el dinero.

Por lo que  www.usavisawaiver.com.ar ya funciona. No solo que funciona, sino que hemos probado con Adwords y los números cierran, y además de eso, al parecer hay usuarios que acceden por búsqueda orgánica.


Resumamos lo que hay hecho

  • Se creo una web para procesar visas para USA.
  • Se armó la programación del backend en PHP y Mariadb.
  • Se armó el diseño.
  • Se corrió publicidad a fin de evaluar el negocio.
  • Los números prueban que el negocio es viable.

Lo que ya añadimos:

  • Enviar un segundo mail cuando el comprador finaliza la compra. ✓
  • El mail debería confirmar el pedido. ✓
  • El mail debería de incluír un link hacia el money back. ✓
  • Las visas deberán llevar un money back de 6 meses, para quien lo pida. ✓
  • Mover mails a /visual/ de modo que pueda ser rediseñada a necesidad. ✓

Lo que queda por hacer:

  • Crear mecanismo de refund.php
  • Colocar pagos por medio de paypal.
  • El usuario debería de poder pagar con cc o paypal.
  • Compra de un nombre de dominio para cada país donde se opera.
  • Especificar en la db por medio de que dominio realizaron la compra.
  • Comunicarse con paypal para cerrar los 8 usuarios que se crearon a priori.
  • Conseguir un banco nacional o americano para pagar por las visas.

  • Fase 2: Crear fork bomb.
  • Fase 2: Correr el negocio como mínimo 5 años.
  • Fase 2: Crear modelo comercial de franquicia o doc similar

División de áreas:

Paso a mencionar diversas divisiones de área, para que quede en claro el rol de cada persona, organización o programa en y de cada una de ellas.

Se definen las funciones que realizan y cumplen y algunos lazos y dependencias, como donde el área de cobranzas requiere del área de publicidad para poder cobrar, las ordenes que la publicidad genera.

Del mismo modo, la publicidad requiere de las cobranzas para pagar el dinero que la publicidad demanda.


Area 1: publicidad y promoción:

Se encarga de que accedan los usuarios a diario a la web y compren. En caso de usar Adwords debería de haber una persona a cargo de hacerlo. En caso de correr campañas de SEO, del mismo modo debería haber una persona a cargo de supervisarlas.

Previo a la publicidad y la promoción fueron necesarios diversos acciones, incluyendo, desarrollo y evaluación del negocio, diseño y programación de la web, llevados a cabo por el área 4 y área 5.

  • Recursos: delegado, se le paga a una empresa por cada conversión.
  • Requiere: negocio ya armado y funcional ✓
  • Requiere: personal dedicado a la publicidad y promoción de la web.
  • Requiere: acuerdo con empresa a cargo del área.

Area 2: cobrar las visas:

Debería de ser mecanizado al 100%, ya bien sea si el usuario paga por medio de paypal o usando una cc, el cobro de la visa debería de mecanizarse y no depender de un empleado para hacerlo.

  • Recursos: mecanización al 100%.
  • Requiere: ingreso de compradores generado por el área 1
  • Requiere: acuerdos y conexiones hacia 2 procesadores de pagos.

Area 3: procesar las visas:

De manera inicial es recomendable que lo haga una persona, una vez que la visa es cobrada, pasado el mes el área debe ser mecanizada al 100% por medio del uso de Selenium (en cuyo caso sería bueno usar la librería facebook/php-webdriver) o similar.

  • Recursos: mecanización al 100%
  • Requiere: cobranzas generadas por el área 2
  • Requiere: personal para realizar las primeras operaciones de forma manual.
  • Requiere: Banco con dinero disponible en dólares a fin de pagar por las visas.

Area 4: dirección y desarrollo:

  • Recursos: inhouse, humanizado al 100%
  • Requiere: negocio funcional y operacional (cíclico y funcionando solo)

Más que dirección y desarrollo debería de llamarse R&D ‘research and devel’ dado que el área se ocupa de crear ideas para que el negocio siga creciendo. El área se considera a cargo de: expansión y compras de nombres de dominio, expansión por países, definir cambios en el diseño o la programación de la web, incorporación de nuevos servicios, expansión de marca y expansión de negocio.


Area 5: diseño y programación:

  • Recursos: inhouse, humanizado al 100%
  • Requiere: negocio funcional y operacional (cíclico y funcionando solo)

Considerando que el laburo inicial ya fue realizado al programar y diseñar la web, ahora solo queda la supervisión de la misma a cargo del área.

Diversas modificaciones de diseño y programación en la web, al servicio de subir las ganancias y expandir el negocio. Creación y evaluación de nuevas versiones del diseño, creación y evaluación de ideas generadas por el área de dirección y desarrollo.


Fork bomb

A fin de crear presión y mayor dominancia sobre el mercado. Se decide al día de hoy realizar diversas replicas y variaciones de la unidad de negocio, creando webs análogas, replicas de menor y / o mayor calidad, a diversos precios (comenzando por inferiores, pero incluyendo superiores).

Más allá de los dividendos de la empresa, cada unidad replica, debería de llevar un supervisor o dueño, de quien cae a cargo la responsabilidad de cuidar el negocio.

De modo similar a como funciona una franquicia, solo que sin conservar la marca, se le provee al responsable, el acceso a los procesadores de pago y a diversos recursos comunes.

A la vez, se le pide que se encargue de cambiar el diseño, realizar la compra del nombre de dominio, y algunas responsabilidades más, por las cuales se le concede un beneficio sobre las ganancias de ese domino o negocio.

El cual, como ya se mencionó, en caso de que el responsable posea responsabilidades o dividendos en la empresa principal, no posee correlación alguna con sus dividendos o acciones en la misma.

Se considera a la empresa madre de cada una de las pequeñas páginas web del mismo rubro, como dueña principal de cada una de las unidades.

Se considera necesario la creación de al menos 3 replicas por cada dominio o área funcional.

 

Desarrollando un videogame: revision 5

Tercera revisión de la aplicación, haciendo foco en el diseño gráfico.

Se describe el proceso general, desde ahora, al fin:


  1. Realizar cualquier cambio que sea necesario a fin de finalizar el diseño.
  2. Una vez finalizado, hacer las conexiones necesarias hacia la API.
  3. Realizar las modificaciones necesarias en Node.
  4. Incorporación de las operaciones con BTC sobre la API.
  5. Fin de la fase de desarrollo.
  6. Comenzar las pruebas privadas a fin de localizar y solucionar problemas.

Se podría considerar que una vez finalizados los 6 pasos mencionados, la aplicación quedó funcional, y solo queda ver como funciona el negocio.

Comencemos por ver la primera versión del diseño final:


Aún no se ha creado una unidad, por lo que no se puede ver el mapa en la primera versión. Las próximas versiones deberían incorporar una camara que siga a diversas unidades en acción.


La unidad ya creada, buscando guerra para ganar monedas! La acción comienza cuando el usuario hace click en spawn.


  1. Barra superior:
    1. A excepción del link al index, cada una de las secciones abre un modal.
    2. Los modales pueden ser copiados de la web de referencia.
    3. Es necesario crear un usuario para poder ver las secciones.
    4. La secciones se componen de:
      1. Link al index
      2. Cashier
      3. Perdidas y ganancias.
      4. Leaderboard
      5. Anuncios
      6. Ayuda
      7. Balance
      8. Usuario
      9. Cerrar sesión
  2. Canvas:
    1. Sin unidad:
      1. Previo a spawnear, los usuarios deben hacer click.
      2. Solo por ahora, se anula el “self-respawn”.
      3. El usuario requiere un click para cada spawn.
      4. Se pone una imágen de fondo para el usuario sin unidad.
      5. Se añade “spawn / respawn”
      6. Se deberá crear una función para spawnear y correrla onclick.
    2. Con unidad:
      1. Se superpone un div / layer que genera una oscuridad en los bordes.
      2. Se cambia el color de la barra de vida a un verde más claro.
      3. De ser posible, cambiar el color del nombre del usuario a la vez.
  3. Iconos inferiores al canvas.
    1. Se forman por medio de un <ul>
    2. Siempre visibles (con y sin unidad)
    3. El color no cambia.
    4. No se les puede hacer click (por ahora)
    5. Quedan solo como referencia o guía.
    6. Se cambiaron los colores de fondo.
    7. Se realizaron leves cambios en los iconos usados.
  4. El leaderboard de la derecha:
    1. Se clona del diseño, no es necesario hacer aclaraciones.
    2. Lee la información disponible.
    3. En la próxima fase pedirá información a la API.
    4. Se añade un background de color #FF7C00 para la linea del usuario.
    5. Quedan los 20 principales.
    6. Ordena la información por kills.
  5. La conversación inferior:
    1. Se añade una scroll bar en grises al final a la derecha.
    2. Cuidado: un borde de un pixel al lado de la scrollbar.
    3. La información quizás debería organizarse al revez.
    4. Ubicando el dialogo más nuevo arriba.
    5. Es necesario el campo para crear un nuevo dialogo.
    6. Se creo un cuadro de 3 columnas.
      1. Hora: definida en 12px, color #929191
      2. Usuario: definida en 13px, color #FF7C00
      3. Dialogo: definida en 13px, color blanco.

Diseño en resoluciones menores:

Se creó de manera adicional, una versión del diseño, la cual se debería correr cuando no alcance la resolución:


Si la resolución fuera menor a 800 píxeles, en verdad, por ahora no hay mucho que se pueda hacer.

Es necesario crear una versión de la aplicación que haga posible moverse sin usar keyboard y disparar sin mouse.


Navegación superior (dialogos, modales)

Algunas secciones se hayan disponibles sin acceder a la aplicación y las secciones de crear nuevo usuario y acceder, por obvias razones, solo se ven previo a que el usuario acceda. Revisemos las secciones.

#1 Link al index Siempre disponible
#2 Cashier Solo con usuario
#3 Perdidas y ganancias Siempre disponible
#4 Leaderboard Siempre disponible
#5 Anuncios Solo con usuario
#6 Ayuda Siempre disponible
#7 Balance Solo con usuario
#8 Usuario Solo con usuario
#9 Cerrar sesión Solo con usuario
#10 Crear nuevo usuario Solo anónimos
#11 Acceder Solo anónimos

#1 link al index:

  • No hace nada más que refrescar la web.
  • Nada de nada por ahora.

#2 Cashier:

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia.
  • Hace posible enviar y sacar dinero bow
  • De manera adicional, se le puede pagar un café a un player.
  • No es necesario remover ningúna sección ni realizar cambios.


#3 Perdidas y ganancias:

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia.
  • Solo carga información que será pedida a la base.


#4 Leaderboard

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia
  • Dada las dimensiones no fue posible copiarlo al 100%


#5 Anuncios

  • Clonar leaderboard.
  • Referencia
  • Funcionará realizando un pedido a la db en búsqueda de news.

#6 Ayuda

  • Clonar leaderboard.
  • Referencia
  • Funcionará sin pedir información a la db.
  • Solo un poco de información ordenada.
  • Solo HTML.

#7 Balance

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia
  • A fin de que la sección procese el gráfico, es necesario realizar operaciones.
  • No es necesaria la incorporación del gráfico por ahora.


#8 Usuario

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia


#9 Cerrar sesión

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia


#10 Crear nuevo usuario

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia


#11 Acceder

  • Una simple clonación alcanza, no es necesario realizar cambios.
  • Referencia

Banderas quemadas, sobre el nacionalismo y la guerra

195 banderas quemadas

Si una persona de cada país del mundo, quemara una bandera de su propio país, una emisión en vivo de 195 banderas, una de cada país, siendo quemadas por sus propios ciudadanos.

Como un símbolo, de la caída de las naciones, para dar comienzo a un nuevo gobierno mundial, creado por 195 personas, sin lugar a dudas, sería preferible eso, a una nueva guerra, para que luego sea solo una bandera, quizás inglesa, quizás rusa, quizás india, quizás china, la que se alce en cada una de las regiones del mundo.

Serían muchas vidas a pagar, por solo una bandera, un orden de colores, y algunas meras preferencias. Asumo que, quien fuera que pueda prevenirlo, serían verdaderos héroes de guerra.

¿Quien haría el honor de quemar su propia, primer bandera y que corra la voz?

De alguna manera, en cualquier caso, la guerra ya empezó hace miles de años, previo a que vuelva a empeorar.

Desarrollando un videogame: revision 4

Al día de la fecha, (27 de Julio del 2018) el progreso viene así:

La versión en vivo, la pueden ver desde www.bitofwar.com aúnque en verdad no creo que dure muchos días del mismo modo, por lo que no creo que sirva a modo de referencia.

He aquí los próximos pasos y cambios a ser realizados:

  1. Ver la guerra desde afuera:
    1. El usuario debería poder ver la guerra en curso previo a crear una unidad.
    2. Para eso se sugiere que el usuario haga “follow” de un usuario al azar.
    3. O bien follow del primer usuario del leaderboard a la derecha.
  2. Acceso:
    1. El login no debería aparece apenas se accede a la web.
    2. El debería hacerse visible al clickear sobre login.
    3. Los usuarios inválidos no podrán acceder o crear unidades.
    4. Los usuarios con menos de una unidad no podrán crear unidades.
    5. El login debería de clonarse de acá.

  1. Tipografía:
    1. Podemos definir “Questrial” de manera global y general.
    2. Por lo que va a ser necesario incluír el link de google.
  2. Leaderboard derecha:
    1. La barra de la derecha debería usar el leaderboard de la app
    2. Con la información ya disponible en la misma.
    3. Luego, de alguna manera debería de vincularse a la db.
  3. Diseño generales:
    1. Algunas palabras poseen errores de fácil corrección.
    2. Incorporación de iconos a las secciones superiores.
    3. Creo que podría realizarse con glyphicons o algo similar.
    4. El diseño, debería de buscar el final del window.size
    5. Finalizando la sección de dialogo a 10 pixeles del final.
    6. La resolución mínima, debería de ser igual a la del canvas, frame included.
    7. Colocando el leaderboard below
    8. Finalizando con la sección de dialogo.
  4. Mariadb
    1. Es necesario la creación de un nuevo espacio para bow
    2. Para almacenar las veces que eliminaron y fueron eliminados.
    3. Las ganancias.
  5. Vender “Rapid power ups”
    1. En medio de una guerra un player podría comprar un powerup.
    2. El valor de el heal powerup debería de ser 1/3 del valor de la unidad.
    3. Los power ups podrían comprarse con keywords.
    4. La compra no requeriría confirmación
    5. La compra requeriría que el usuario disponga los fondos.
    6. Por lo cual un nuevo llamado a la API es necesario.
  6. Creación de usuarios
    1. La creación de usuarios, debería clonarse de acá:

Sería recomendable conservar la aclaración sobre el gambling, aunque en verdad no lo sea, solo por si las dudas.

  1. Creación de usuarios:
    1. El password debería de generarse solo del mismo modo.
    2. Analizarse la posible craeción de password más simples y seguros.
    3. Para comenzar alcanzaría con que genere 12 símbolos al azar.
    4. Al final, debería de mandar la información para la API.
    5. Al finalizar, debería de hacer login solo, del mismo modo.
  2. Creación de unidades.
    1. Aplicable al spawn y respawn
    2. Solo aquellos players con usuarios válidos pueden crear un unidad.
    3. La API informa el saldo disponible del usuario.
    4. Informando en caso de que sea menor a la unidad mínima.
    5. En cuyo caso no podrá spawnear o respawnear.
  3. Cuadro de dialogo
    1. Parece que se lee solo desde el browser.
    2. Será necesario guardarlo en la db para preservarlo.
    3. Al acceder a la aplicación, por medio de un pedido a la API
    4. Se deberían de leer los 100 o 50 más nuevos.
    5. Es necesario un usuario para escribir.
    6. Pero no es necesario un usuario para leer.
  4. Record de acciones:
    1. Creación de un log de acciones
    2. Donde se pueda leer:
    3. Nacho a golpeado a Chris infingiendo 20 de daño.
    4. Nacho a golpeado a Chris infingiendo 20 de daño.
    5. Chris a golpeado a Nacho inflingiendo 20 de daño
    6. Chris a eliminado a Nacho.
    7. El mismo log debería de ser una solapa sobre el box de dialogo.
  5. Solapa de cashier
    1. El ingreso de dinero deberá realizarse por medio de al API.
    2. La API deberá procesar dinero que ingresa a un usuario.
    3. Un usuario deberá poder sacar como máximo, el dinero que dispone.

  1. Cargando dinero en blockchain:
    1. Se crea una dirección al azar y se le asigna al usuario
    2. A fin de realizar el envío de dinero.
    3. Una vez que se ve la operación en el blockchain, se informa.
    4. Cuando la operación dispone de 2 confirmaciones, se dispone del dinero.
  2. Sacando dinero:
    1. Similar al modo previo, pero aún más simple:
    2. El diseño, una vez más, se roba

 

  1. Sacando dinero en blockchain:
    1. El usuario especifica la dirección a donde lo quiere enviar.
    2. El usuario especifica el valor a enviar.
    3. El usuario hace click y sale un pedido a la API.
    4. Si el usuario dispone del valor específicado, se envía.
    5. La operación se guarda una vez más en la db.
  2. Información que quedaría guardada en db:
    1. Usuarios
      1. Email
      2. Username
      3. Password
      4. Balance
      5. Killed
      6. Was_killed
      7. Ganancias
      8. Creación
    2. Conversaciones
      1. Username
      2. Message
      3. Creación
    3. Operaciones en blockchain
      1. Username
      2. Accion (puso / saco)
      3. Value
      4. Dirección usada
      5. Txid
      6. Creacion
    4. War_logs
      1. Username_a
      2. Accion (eg: killed, harm, found_heal, paid_heal)
      3. Username_b
      4. Creación

Relevancias

Ayer nació mi beba.

Me dio la impresión de que ya la conocía. Cómo la primera vez que ves en persona a alguien, después de haber hablado algunos año. Más que conocer, diría reconocerla, que curioso.

La vida se pone unas horas en pausa y lo que parecían prioridades desocupan relevancia, la devuelven.

Desarrollando un videogame: revision 3

Comencemos una nueva publicación para darle follow up al proceso de craeción y publicación fichin.


Como habíamos mencionado, los pasos a seguir son:

  1. Servidor en linea funcional (AWS).  ✓
  2. Creación del operador para usuarios y balances (main backend) ✓
  3. Localizar y descargar videogame open source. ✓
  4. Comprar nombre de dominio, único por aplicación. ✓
  5. Modificaciones en el diseño general de la aplicación. ✓
  6. Conexión del videogame con el main backen
  7. Evaluación y consumo
  8. Publicidad y promoción
  9. Análisis, correcciones y evaluación de negocio.

#1 Servidor en linea funcional ✓

Se creo un usuario en AWS y se armó el servidor.

Dicho sea de paso, zarpado las AMI! Ya disponen de decenas de servidores pre-configurados, que se lanzan con un par de clicks! Hay disponible una gran publicación sobre la selección de la maquina indicada para cada caso, que no leí.

Seleccionando la AMI indicada:

Comenzamos por discriminar las maquinas preparadas para “deep learning”, no es el caso. Después sacaría cualquiera que sea Windows, y en los linux disponibles, buscaría el que venga con menos aplicaciones precargadas.

Debo reconocer que primero probé con uno de los sabores de linux de amazon:  Amazon Linux AMI 2018.03.0. que parecía ser la indicada y ya preparada para mi clase de guerra. La relación no funcionó y pasé a seleccionar el sabor clásico de Linux.

Próximo paso, T2 micro es la única versión que viene incluida sin cargo en el freemium saas, vamos por esa. Conservamos el disco en SDD porque queremos velocidad, y porque 1998 ya pasó.

Creo y descargo el PEM para la comunicación, lo salvo en una llave usb.


Es aquí cuando la ocurrencia de que podría crear y guardar cada una de mis ideas en una llave usb, coleccionando así muchas llaves usb con negocios que en su mayoría no funcionaron.


#2 Creación del operador para usuarios y balances (main backend) ✓

La idea se simplifica en crear una única db que almacene los balances de los usuarios y la cual pueda ser operada por diversas aplicaciones a la vez. La misma aplicación es responsable de recibir y enviar los pagos en BTC.

Para referencia se expone un diagrama básico de la API:

 


#3 Localizar y descargar videogame open source. ✓

Decididó, probado y hecho! Para hacer que la aplicación corra sin problemas fueron necesarios algunos cambios.

Descargar la versión 3 desde acá

Con la versión, comenzar la secuencia de comandos indicada:

  • npm install
  • bower install
  • gulp

Dependencias deprecadas:

Se localizaron varias dependencias que ya quedaron deprecadas hacía algunos años, sería bueno revisarlas para que no causen problemas, parece haber alguna de ellas vinculada a problemas de seguridad. Las dependencias son:

npm

gulp

Sobre Node o la versión de Node usada.

La versión de node que requiere la aplicación, parece la aplicación funciona sin problemas corriendo desde Py 2.7.15 sin embargo, algunas expresiones no fueron válidas y causaron problemas en 3.7.0.

Muchas cosas a considerar acá en lo que refiere a las modificaciones que habrá que hacerle al fichin. Llegado acá podemos cerrar el episodio con un link:

54.185.56.27


#4 Comprar nombre de dominio, único por aplicación ✓

Llegado acá, es un placer darles la bienvenida a un poco de guerra .com!


#5 Modificaciones en el diseño general de la aplicación ✓

Comencemos enumerar un poco las modificaciones gráficas que deberían de realizarse, las que son más fáciles de realizar, y las que no:

Para comenzar el diseño gráfico se podría decir que es necesario comenzar por el nombre de dominio y la idea de la empresa.

Un poco de guerra hace una referencia a guerra, pero la palabra poco en inglés, hace una simple conexión a la palabra información y a la palabra pagos.

Por lo cual, de alguna manera decimos “un poco/información/dinero guerra”.


Diseño del logo:


Yes, know, se ve un poco parecido al de una empresa de videogames online. Bueno, que se le va a hacer, es solo la versión preliminar, y quedan algunos cambios por ser realizados.

Segunda versión del logo, creo que quedamos acá. Solo quedaria hacer un concurso de diseñadores que puedan cambiar un poco la forma de las cosas, en lo principal, conservando los colores, pero comenzando desde esa base, sumandole su personalidad a la idea.


Diseño de la aplicación


Por ser la primera versión, se realizan varios cambios, desde la versión original, los cuales, voy a procurar describir uno a uno, cambios realizados:

  • Fondo “negro”: la aplicación se vuelve más oscura.
  • Espaciado de 10 pixeles dividiendo bloques.
  • Navegación superior, incluye:
    • Izquierda: Nombre con link a index
    • Izquierda: Cashier
    • Izquierda: Bankroll
    • Izquierda: Leaderboard
    • Derecha: nombre de usuario
    • Derecha: dinero
    • Derecha: cerrar sesión
  • Scores de los usuarios online a la derecha

Modificaciones necesarias en diseño:

En lineas generales, ya se creo un panorama de lo que podría ser una base del diseño, vale la pena mencionar algunos de las acciones necesarias en el área:

  • Definir las dimensiones finales del mapa.
  • Un diseñador gráfico freelancer debería de diseñar:
    • Los mapas.
    • Las unidades (Tanques).
    • Las municiones.
    • Los power ups.

Modificaciones mínimas indispensables en app:

  • Pedir nombre de usuario y password para comenzar ✓
    • Enviar pedido a la API para buscar información ✓
    • Verificación del usuario vs db ✓
    • Cargar información del usuario en aplicación
  • Definir “unidades” en la configuración ✓
  • Ganancias de usuario (variable) ✓
    • Ganancia por eliminación causada: 1000 unidades ✓
    • Ganancia por daño causado
  • Perdidas de usuario (variable) ✓
    • Perdida por eliminación: 1100 unidades ✓
    • Perdida por daño recibido
  • Ganancias de la casa
    • 10% sobre cada eliminación ✓
  • Los packs de vida se conservan ✓
  • Considerar precio de aparición
  •  La casa en cambio cobra un 10% por cada eliminación
  • Crear usuario de prueba en db ✓
  • Probar de a dos para evaluar los mecanismos ✓

#8 Publicidad y promoción


Tired of fixed rigged games where odds are your only enemy?
Say no more! Join us in a real war for coins! A Real Time Warfare game where logic always wins over luck.


Las salas deberían de pedir un mínimo de dinero para usarlas, de manera que quienes recienes comienzan, no se vean amenazados por players de mayor experiencia.

Cuando un nuevo usuario se crea, comienza en la primera arena. Al alcanzar sus primeras x ganancias y cuando su dinero supera y, debería forzarlo a ingresar a la segunda arena.

  • Ƀ warfield.
  • 10 Ƀ warfield.
  • 100 Ƀ warfield.
  • 1,000 Ƀ warfield for serious players only!
  • 10,000 Ƀ warfield for advanced players only!
  • 100,000 Ƀ warfield for professional players & A.I. only!

Warfield Ganancia x eliminación Dinero mínimo * Mapa
1 Ƀ arena Ƀ 0.000,002 Ƀ 0.000,200 Hello shapes.
10 Ƀ arena Ƀ 0.000,020 Ƀ 0.002,000 The middle class.
100 Ƀ arena Ƀ 0.000,200 Ƀ 0.020,000 The circle.
1,000 Ƀ arena Ƀ 0.002,000 Ƀ 0.200,000 There’s no circle.
10,000 Ƀ arena Ƀ 0.020,000 Ƀ 2.000,000 Keras dreams in Pi
100,000 Ƀ arena Ƀ 0.200,000 Ƀ 20.000,000 The red pill

Llegado acá, creo que no es bueno conservar el orden de la publicación para no frenar las ideas por no poseer una simple correlación con la idea previa o los pasos mencionados.

Por un lado me da la impresión de que debería de analizar la lógica de la aplicación de forma cuidadosa, previo a comenzar a programar, sin embargo, comienzo a considerar que no hay forma más simple de crear algo bueno y dinámico que hacerlo a medida que lo pruebo, realizando cambios a medida que se se consideran.


  • La aplicación podría incluir algunas radios en vivo.
  • Debería de haber polls para regular el dinero x daño.
  • Diversas variables deberían de ser, de algún modo, definidas por los usuarios.

Sigo en una nueva publicación!

 

Desarrollando un videogame: revision 2

Decidí empezar a diagramar la composición de un negocio donde los usuarios puedan viciarse con videogames, ganando y perdiendo dinero a medida que ganan o pierden.

A diferencia de una sala convencional de azar, donde los usuarios pueden poner fichas a que un valor va a salir o no, los videogames proponen dos cambios cruciales en la mecánica:

No dependen del azar, es posible predecir quien ganará.

El primero es que un usuario no depende del azar! Lo cual ya es mucho! Un usuario puede ganar gracias a su habilidad y sus experiencias previas. Con lo cual, quien más gane, será en mayor medida gracias a su habilidad.

No es necesario la creación de una banca.

Dado que la mecánica de los videogames seleccionados, implican que el usuario perdedor, pierda dinero, a fin de que el usuario ganador, gane, no es necesaria la creación de una banca. El dinero que se usa en la aplicación proviene de los mismos usuarios.

Es muy fácil ganar y perder dinero en el blockchain!

El dinero en blockchain se mueve en verdad muy rápido, es mucho más fácil de ganarlo y de perderlo, incluso las compras, son en verdad, solo algunos clicks y segundos para que el pago se realice y le llegue al vendedor.

A diferencia de las operaciones bancarizadas, el vendedor, recibe su pago ‘acá y ahora’ sin días ni semanas de esperas con el procesador de pagos. La operación pareciera ser como pagar con verdaderas monedas físicas, las cuales son enviadas en segundos, no como balances que demoran en acomodarse.


Recursos

Paso ahora a recuperar algunos recursos ya publicados hace unos días, con aplicaciones open source que podrían ser usadas de base, y solo añadir la magia del blockchain en ellas:

Referencia Nombre Código Demo
#1 Tank Anarchy Source code Demo
#2 Agar.io Source code Demo
#3 Wordchain Source code Demo
#4 Tic-Tac-Toe Source code
#5 Snake Source code Demo
#6 Curvas Source code Demo
#7 Tanks (oldie) Source code Demo
#8 Space Source code Demo
#9 Space 2 Source code Demo
#10 Mozilla BQ Source code Demo
#11 Sli Source code Demo

Una sola unidad para enviar y recibir los pagos:

Reformulé algunas veces el proceso final de creación y las piezas del rompecabezas a fin de eliminar redundancias.

No veo necesidad alguna de que cada videogame realice sus propias operaciones con el dinero y los usuarios. De esa manera una sola db podría almacenar la información y los saldos de los usuarios, los cuales se irían modificando a medida que realizan acciones en las aplicaciones.

Un nuevo usuario, sería válido para cada una de las aplicaciones o videogames publicados, y el mismo, podría recibir un correo cuando un nuevo videogame sea publicado. El mismo usuario serviría para cada una de las aplicaciones y conservaría su saldo en ellas.


Pasos y piezas a crear:

Eliminación de redundancia

Me fue posible imaginar algunas de la cosas necesarias para llevar a cabo el negocio, como ya mencioné, eliminando algunas redundancias, quizás queden más procesos los cuales podrían ser simplificados o eliminados, analicemos:

En la primera ronda sería necesario:

  1. Servidor en linea funcional (AWS).
  2. Creación del operador para usuarios y balances (main backend)
  3. Localizar y descargar videogame open source.
  4. Comprar nombre de dominio, único por aplicación.
  5. Modificaciones en el diseño general de la aplicación.
  6. Conexión del videogame con el main backen.
  7. Evaluación y consumo
  8. Publicidad y promoción
  9. Análisis, correcciones y evaluación de negocio.

Una vez armado el primero

Las cosas se vuelven un poco más rápidas, dado que los primeros 2 pasos son exclusivos para el caso. Donde luego el negocio, quedaría reducido:

  1. Localizar y descargar videogame open source.
  2. Comprar nombre de dominio, único por aplicación.
  3. Modificaciones en el diseño general de la aplicación.
  4. Conexión del videogame con el main backen.
  5. Evaluación y consumo
  6. Publicidad y promoción
  7. Análisis, correcciones y evaluación de negocio.

Los 6 pasos deberían alcanzar, no solo para crear una nueva unidad de negocios, incorporando incluso su propio “procesador de pagos”, sino que a la vez, deberían dar información clara de la performance del mismo: incluyendo las ganancias promedias generadas por cada usuario, y el cac de los mismos.


Cada una de las piezas:

#1 Servidor en linea funcional

Acá no parece ser muy difícil considerar un servicio como AWS. La mayoría de las aplicaciones corren sobre NodeJS, requieren un servidor dedicado, y escalabilidad.

Sobre cualquier cosa, la escalabilidad y la dinámica, de manera de pagar menos dinero al comenzar sin ningún usuario, y luego poder expandir con facilidad los recursos del servidor a medida que la demanda sube.

Las opciones acá consideradas aún son:

  • Amazon web services
  • Heroku
  • Azure
  • Google cloud

Las razones para que la balanza ahora mismo se incline por Amazon, son varias y no dispongo las ganas de analizarlas.


#2 Backend para usuarios y balances

Una aplicación corriendo en el mismo servidor, con la seguridad adecuada, y nunca conservando más de un 10% o 20% del dinero en el mismo.

El backend debería de usar una API para recibir “dialogo de área local” con cada una las aplicaciones armadas. En principio, podría ser creada usando PHP y Mariadb, dada la organización necesaria en la base.

Sin embargo, vale la pena considerar opciones. Quizás se pueda localizar algo más o menos formulado, y funcional ya armado.

De no ser así, no es más que un simple mecanismo de usuarios, con balances que los cuales, en lo que refiere a la versión más básica de la aplicación, solo pueden subir, cuando un usuario decide cargar o descargar su saldo.

Luego la API, se encargaría de hacer las “micro operaciones” demandadas y generadas por las aplicaciones, para lo cual no creo que sean necesarias más de una o dos funciones principales.


#3 Videogame open source.

La manera más simple de achicar la inversión inicial, usando fichines open source de una y sumarles el blockchain. No creo que haya mucho que aclarar acá.

Si la empresa crece como confiamos, llegará el día en que sea necesario o buena idea, la creación de fichines propios hechos a medida. No ahora.


#4 Compra de nombre de dominio

Creo que no es necesario describir el proceso de compra de un nombre de dominio, pero debería de poseer alguna clase de relación con la aplicación o el fichin que se va a asignar al mismo.


#5 Modificaciones en el diseño de la aplicación

Las modificaciones en el diseño de la aplicación puede que sean uno de los procesos más complicados y puedan llevar más horas de laburo.

Se consideran por solo las modificaciones que comprenden al diseño de la aplicación y no a los vinculos a ser realizados con el backend.

Algunos de las incorporaciones necesarias, implican:

  • Hacer que los fichenes corran en full screen.
  • Una barra a la derecha debería de dar un scoring general
  • La barra superior debería llevar:
    • Home
    • Cashier
    • Bankroll
    • Leaderboard
    • Help
    • Usuario y balance
    • Cerrar sesion

Muchos de los gráficos usados en el código open source podría ser reformulado, dándole un lavado de cara a la aplicación.


#6 Conexión del videogame con el main backen

El proceso no debería de ser ni simple, ni demasiado complicado. Es necesario comenzar por definir cuando un usuario va a ganar y cuando un usuario va a perder dinero.

Dado que se va a comenzar solo por videogames MP, las reglas deben ser claras y deberían de anunciarse  en algún lugar previo a comenzar una ronda.

Una vez que se definnan los vinculos de acciones y operaciones con el dinero, las funciones de conexión con la API, como podría ser:

  • 127.0.0.1/backend/index.php?uid=72124&value=+10
  • 127.0.0.1/backend/index.php?uid=98324&value=-10

Los mismos pedidos podrían ser realizados por una función wrapper que podría verse así

  • api_push(72124, +10);
  • api_push(98324, -10); 

Simulando que el usuario 72124 le gana una ronda al usuario 98324, sin pago de comisiones (0% margen).

La comunicación nunca debería de salir de la red de área local por razones de seguridad, por lo que es en realidad el backend en NodeJS, ubicada en el servidor local que se comunica con el backend en PHP en el mismo servidor.

De ningúna manera se deberá procesar un pedido por la API para reducir o subir el dinero de un usuario de no provenir desde si mismo, a excepción de las cargas y descargas de dinero que son realizadas por los usuarios mismos.

En caso de usar PHP, las variables:

$_SERVER["REMOTE_ADDR"]
$_SERVER['HTTP_CLIENT_IP']
$_SERVER['HTTP_X_FORWARDED_FOR']

Deberían de ser analizadas a fin de confirmar que el dialogo es local, previo a realizar cualquier operación. Ahora mismo, considero que el uso de llaves, más allá de las mismas llaves usadas por el HTTPS no deberían de ser necesario, siempre y cuando la comunicación sea local.


#7 Evaluación y consumo

Una vez finalizado cada uno de los pasos, con la aplicación en linea, funcional, con sus gráficos refrescados, es hora de probarla, para hacer la experiencia lo más agradable, y viciosa posible.

No es recomendable empezar la promoción sin haber llevado al máximo el proceso de evaluación. La aplicación se debería de probar varias veces por un grupo de usuarios conocidos, quienes puedan informar con sinceridad sobre su experiencia. Haciendo las modificaciones necesarias después de cada análisis en base al feedback de los usuarios.

Es probable que sea posible conseguir usuarios de prueba en los foros.


#8 Publicidad y promoción

Hecha la prueba creo que la promoción y publicidad es crucial para el negocio, creo que lo más recomendable, sería realizar un poco de “spamming” en comunidades del palo.

De donde sacar los usuarios, enumeración de recursos:

  • https://www.bitcointalk.org
  • https://www.bustadice.com
  • https://www.bustabit.com
  • https://www.bitsler.com
  • https://www.fortunejack.com
  • https://www.luckygames.io
  • https://www.primedice.com
  • https://www.fairlay.com
  • https://www.satoshidice.com
  • https://www.coinroll.com
  • https://www.777coin.com
  • https://www.swcpoker.eu
  • http://luckyb.it
  • https://duckdice.io/

Habiendo finalizado con los recursos creo que por ahora no me queda nada sin mencionar. Los pasos deberían de llevarse a cabo uno por uno, asegurándose de que las bases vayan quedando siempre sólidas.

Casino vs Keras: creación de una red LSTM.

Prediccionador 6

Las primeras 5 versiones fueron eliminadas/ no consideradas.

Ronda número 6 queriendo ganarle al casino usando AI. Para ser más específico una RNN creada por unidades LSTM.

Dado que los hechos fueron hace más de un 1 meses, voy a comenzar por el guión:

Parece que la explicación y una breve opinión personal vienen incluídas en el guión! Genial, reciclemos!

*La red del modelo puede no ser la misma a la creada por prediccionador_6 dado los diversos cambios que se fueron realizando en el proceso de creación.


El mecanismo devuelve valores que varian del 5 al 6.

Los valores cercanos al 6 suelen ser más seguros,  sin embargo, el verdadero indicador es si el valor asciende o decae en relación al valor previo.

Si el valor anda en en rangos de 6, y se desplaza hacia el 5, es recomendable no hacer nada, # a la inversa, cuando anda en rangos de 5 y avanza hacia el 6, es recomendable posicionarse.

Las unidades de LSTM suben el valor de prediccion (ynew) cuando consideran que la chance subio, del mismo modo, el valor disminuye, cuando la probabilidad desciende.

Addendum: la variación parece ser relevancia, del mismo modo que el número, quizás sería bueno hacer <ynew_previo – ynew ahora> para que calcule la diferencia.

Se usan los mecanismos del prediccionador 5 buscando mayor performance y se añade inserción de información a mariadb para análisis y revisión.

El modelo señaló como mayores: 979 valores, de los cuales:

  • Valore mayores: 556 | (56,79%)
  • Valore menores: 423 | (43,20%)
  • Diferencia: 133 | (13.59%)

Aclaraciones: al día de la fecha de edición, si bien el modelo logró hacer algunas buenas clasificaciones, al largo plazo, por lo que recuerdo falló.

El modelo, con ayuda del guion clasifico (más allá de que el modelo por si sólo no realiza clasificaciones), 979 predicciones de números mayores a 2 (el volúmen de números que fue clasificado como menores no es mencionado, sin embargo, podría recordar que serían al menos dos veces más).

De las 979 predicciones, el 56,79% fueron válidas, y el 43,20% equivocas, con una diferencia de 133 predicciones válidas, las cuales equivaldrían a la ganancia de 133 unidades.

Si alguien deseara re-evaluar el guión o el modelo creado por el mismo a fin de realizar cambios en el mismo, véase libre de hacerlo.


Download now!


Prediccionador 8

Se realizan varios cambios, pasando a usar un modelo supervisado, y cambiando de manera crucial la forma en la que las unidades de LSTM aprenden. Si mal no recuerdo no fue favorable.


Prediccionador 9

Se crea un modelo supervisado, análogo al prediccionador 8, se cambia la selección realizada a la db, y se modifica el guión a fin de realizar pruebas sobre la información ya guardada en la db, a fines de probar los modelos a mayor velocidad, sin necesidades de esperar a la próxima ronda.

Las pruebas con ai, duraron más de 3 semanas, y sin embargo, creo que podrían haber sido muchísimas más, en especial hacer uso de las redes neuronales LSTM para buscar formas, o figuras, que después podrían haber sido empleadas en las selecciones sobre los mapas de azar.

Valdría la pena profundizar con el análisis. Diversas pruebas realizadas con Orange y R no fueron incluidas dado que se consideraron de menor relevancia.

Creación y análisis de mapas de azar

Aún sigo en la búsqueda de una forma válida de reducir el azar, una insuficiencia del mismo. CWE-331.

Creo que es posible llegar a algún lado, pero más allá de eso, por ahora parece no haber nada más en que ocupar las horas… el mismo proceso de búsqueda emociona un poco!


Veamos un nuevo mapa:

El archivo css al cual hacen referencia:

Creo que ya no es necesario aclarar que no busco diseñar una aplicación, por lo que en verdad, la armonía y organización del código me dan igual.


Visualizando la información:


Simulando las perdidas y ganancias:

Una analogía del buscaminas.

Cada una de las veces que sale un valor superior a 1,000, se arma una selección, la cual en la imagen se ve en amarillo.

Los círculos colorados, corresponden a las selecciones que fallaron, las cuales no dieron en proximidad con ningún valor superior a 1,000.

La simulación de la primera ronda, nos da:

  • 32 grupos perdidos * 56 valores por grupo = 1,792 perdidas.
  • 6 grupos ganados * 1000 de ganancia = 6,000 ganadas.
  • 6 grupos ganados * 56 (perdida máxima de grupo) = 336 perdidas ~
  • Lo cual nos queda en: 3,872 unidades ganadas en 40,000
  • Aproxima a un +10%

Breve análisis del código:

  1. Se selecciona de la db los primeros 40 mil valores.
  2. Lo cual equivale a las primeras 40 mil rondas, vale la pena aclarar.
  3. Lo cual aproximan un 8% a 10% de la información disponible.
  4. Se les asigna el color negro a cualquier valor mayor a 1,000.
  5. Cualquier valor menor a 1,000 queda en blanco.
  6. El primer cuadrado corresponde al primer valor de la base.
  7. La grilla se compone de 700 pixeles de ancho.
  8. Cada linea posee 116 unidades
  9. Siendo la unidad final de la primera fila, la ronda 116.
  10. Cada selección posee 56 valores.

Expandiendo el grupo

Dado que por ahora las conclusiones parecen ser favorables, es hora de probarlo sobre el 100% de la información, lo que componen más de 600,000 rondas en la db.

Para hacer eso, veo dos opciones posibles, usando código, por medio de una selección SQL, o bien, siguiendo por el camino visual y pidiendo el 100% de la información disponible.

Por más obvio que parezca, es más fácil hacerlo por medio de SQL, pero más difícil de visualizar. Por lo que voy a pasar a crear una mapa con los más de 600,000 valores.


Primeros 100,000 valores:

Los primeros 40,000 no se veían nada mal, no? Al expandir un poco el mapa podemos ver como varias perdidas se avalancha sobre los grupos de 56 unidades, y un valor superior a 1,000 que casi, se podría decir que acaricia un grupo muy cercano, de manera que casi sería recomendable cambiar la forma.

Como se darán una idea corroborado que la selección y el mapa no funcionaron, he decidido considerar la prueba como fracasada.

Aunque a la vez, inconclusa, dado que para confirmar al 100% la invalidez, se deberían seguida aún muchos más pasos, comenzando por probar cada uno de los valores, y variar las formas.

Sin embargo, mi opinión personal, es que las probabilidades de que eso funcione de algún modo, acaban de reducirse de manera considerable.


Conclusiones:

Predecible o impredecible? Al día de la fecha, y  considero el mecanismo como impredecible, habiéndolo probado por diversos modos.

Alguna manera de sacar un pequeño margen a favor?

Es quizás, de alguna manera probable, por medio del uso adecuado de la probabilidad y gran información acumulada, alcanzar alguna forma de balance en las probabilidades de ganar, un pequeño margen.

Es posible descargar una copia de la db desde aquí.

Alguna manera de ganar varias veces seguidas o una buena chance de ganar mucho dinero rápido con menos riesgo?

Comenzando a poner fichas una vez que salieron un mínimo de 8 valores menores a 2 en fila, sin números mayores en el medio, y duplicando las fichas por dos cada vez que se pierde, sin fin.

Considerar un mínimo de 12 posiciones: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512  y recuerde que para perder 2es necesario un bankroll de (210 ) -1, lo cual equivale a 1023 unidades.

De modo que si uno deseara ganar un promedio de 10,000 unidades diarias, debería de disponer de 1,023000 BTC disponible de bankroll.

Mi recomendación se basa en que la cadena más larga de números menores a dos en secuencia, observada al día de la fecha es de 19 números menores seguidos, por lo cual:


Comenzando una vez que se hayan acumulado al menos 8 valores inferiores a 2 de forma seguida, con el dinero necesario para duplicar la primera posición (1 unidad) al menos 12 veces en caso de perder, lo cual correspondería a una cadena de 20 unidades seguidas, lo cual, de acuerdo a la db, aún nunca ha sucedido en más de 663061 rondas.


Sin embargo, para ser sincero, el hecho de que no haya sucedido nunca, en mi opinión personal, no implica que su probabilidad sea del 0%, ni que de manera necesaria, su probabilidad sea reducida.

Aquí, vale la pena mencionar dos cosas:

La primera es que una cadena de 19 valores seguidos ya ha sucedido, y que si bien desconozco el generador de numeros pseudorandom usado y la semilla del mismo, diría con mucha seguridad que llegada la hora, el generador es capaz de crear una cadena aún más larga, por lo cual, quizás sea considerable modificar los valores de demora previa y el mismo bankroll disponible.

La segunda, y quizás de mayor relevancia, es que las cadenas mayores a 7, las cuales promedian de 7 a 12, y son el comienzo del mecanismo que menciono, no suelen suceder con mucha frecuencia, por lo cual no se podría esperar ganar más de 10 unidades en un día normal.

Salir una vez alcanzado el doble del dinero inicial, si es que lo ha logrado hacer. La probabilidad de ganar el doble del dinero inicial desde ya no es favorable, por lo cual se puede considerar en menos del 10% de los usuarios, sin embargo vale la pena considerar que muchos no poseen ni idea alguna de como reducir sus riesgos.

No es para nada lógico creer es posible aplicar el mecanismo por siempre, dado que llegada una ronda, el generador romperá su propio record de 19 números inferiores en fila, y creará el próximo, el cual, vale la pena mencionar, no posee necesidad alguna de ser igual a 20, bien podría ser, 21, 22, ó 23.

Qué sucede con las redes neuronales?

Si bien el avance de las redes neuronales es increíble, y en especial algunas ramas como las redes LSTM, una vez más, mis disculpas, parece que aún nadie pasó wikipedia al español….

En mi experiencia no fue posible conseguir más que algunas risas cuando mi ordenador decidió que la opción ideal era poner fichas a favor del casino!

Quizás el día de mañana las redes neuronales sean capaces de desglosar información de una forma que al día de hoy no podamos ni imaginar, sin embargo, por ahora, sin la configuración adecuada, podría asegurarles que no me fue posible conseguir que mis modelos realicen predicciones algo azarosas.

En breve subiré copias de los 3 guiones armados en py, los cuales pueden ser usados, para crear 3 modelos los que a la vez, hacen uso de selenium para observar los valores que van saliendo y realizar predicciones en vivo.

Wisdom of crowd?

Tampoco. Usé una versión del crawler para sacar información sobre cada una de las rondas y el dinero de cada player. Logré comprobar que la mayoría pierde y al igual que su promedio.  Mis disculpas, wikipedia sigue en inglés!

 

Desayunando azar

Equipado con la información de cada uno de los “números ganadores”, o una db con la información de miles de rondas de un casino, es posible realizar diversas queries en búsquedas de secuencias o ordenes en la información.


Analizando el azar.

Sobre George Marsaglia y Diehard

Algunas colecciones o librerías fueron creadas hace algunos años, a fin de analizar secuencias, que a simple observación parecen ser generadas al azar.

Al día de la fecha, no hay disponible información en español sobre las librerías Diehard, ni mucho menos TU01lease “Prueba U. versión 01”, creada por el señor George Marsaglia – de las cuales solo es imposible localizar información en Inglés, Ruso y Japonés.

En lineas generales, dichas librerías, se componen de un grupo de pruebas las cuales hacen posible evaluar la calidad de una secuencia de valores “al azar”. Como sería obvio esperar, las librerías son por lo general usadas para corroborar y verificar secuencias de valores al azar, a fin de crear secuencias más seguras. Del mismo modo, las librerías son capaces de localizar “fallas” o algunas formas en las secuencias dadas.

Sería recomendable que cualquier casino online realice dichas pruebas a fin de corroborar que en verdad no hay riesgo que de un usuario pueda predecir los próximos números.


 

Analizando la información con imágenes

Pasando la información a un mapa

Dado que como seres humanos nos es más simple analizar una imagen que una secuencia de miles de números, decidí usar un mecanismo clásico para visualizar las secuencias, asignando pequeños pixeles blancos a los valores inferiores y pixeles negros a los valores superiores.

De esa manera, pasemos a analizar una secuencia de 100 unidades, donde los valores menores a 2, son considerados píxeles claros, y los mayores a 2, píxeles oscuros:

  • 15.49, oscuro
  • 7.42, oscuro
  • 1.04, claro
  • 2.71, oscuro
  • 1.95, claro
  • 4, oscuro
  • 4.4, oscuro
  • 1.52, claro
  • 28.69, oscuro
  • 7.44, oscuro
  • 1.1, claro
  • 1.1, claro
  • 1.41, claro
  • 1.04, claro
  • 1.66, claro
  • 8.44, oscuro
  • 1.55, claro
  • 2.39, oscuro
  • 2.9, oscuro
  • 1.66, claro
  • 2.7, oscuro
  • 7.53, oscuro
  • 2.04, oscuro
  • 1.97, claro
  • 1.35, claro
  • 1.83, claro
  • 2.63, oscuro
  • 2.81, oscuro
  • 1.06, claro
  • 2.81, oscuro
  • 21.74, oscuro
  • 1.53, claro
  • 2.04, oscuro
  • 3.94, oscuro
  • 1.9, claro
  • 1.26, claro
  • 1.61, claro
  • 1.31, claro
  • 49.3, oscuro
  • 16.9, oscuro
  • 2.05, oscuro
  • 1.85, claro
  • 15.22, oscuro
  • 1.12, claro
  • 1.57, claro
  • 1.51, claro
  • 7.58, oscuro
  • 1.73, claro
  • 1.17, claro
  • 1.46, claro
  • 1.64, claro
  • 6.72, oscuro
  • 18.69, oscuro
  • 8.95, oscuro
  • 19.9, oscuro
  • 2.98, oscuro
  • 54.82, oscuro
  • 3, oscuro
  • 3.06, oscuro
  • 1.66, claro
  • 1.03, claro
  • 1.03, claro
  • 10.57, oscuro
  • 1.4, claro
  • 1.98, claro
  • 1.05, claro
  • 2.44, oscuro
  • 1.29, claro
  • 1.21, claro
  • 3.72, oscuro
  • 6.18, oscuro
  • 4.41, oscuro
  • 1.25, claro
  • 3.25, oscuro
  • 2.46, oscuro
  • 6.75, oscuro
  • 2.11, oscuro
  • 1, claro
  • 1.58, claro
  • 1.02, claro
  • 1.99, claro
  • 2.3, oscuro
  • 2.14, oscuro
  • 3.46, oscuro
  • 1.58, claro
  • 1, claro
  • 1.23, claro
  • 2.16, oscuro
  • 3.63, oscuro
  • 2.43, oscuro
  • 1.71, claro
  • 3.27, oscuro
  • 1.23, claro
  • 2.18, oscuro
  • 1.87, claro
  • 1.76, claro
  • 1.55, claro
  • 2.56, oscuro
  • 1.14, claro
  • 1.66, claro

Por más absurdo que parezca, es posible simplificar esa serie en solo un puñado de pixeles:

El pequeño cuadrado, conformado de 10 unidades de largo por 10 unidades de ancho, brinda información sobre 100 rondas. Es claro que uno podría asignar un abanico de grises, a fin de visualizar aún más información sobre los valores.

 Analicemos ahora un mapa más grande:

La imagen que vemos, posee información sobre 9,000 rondas. De ser de alguna manera necesario, enumeraría cada uno de los números, a fin de que puedan apreciar el largo de la información, y lo muy comprimida que se observa.


Buscando posibles operaciones

Claro perdemos, oscuro, ganamos.

Ahora que ya vimos como podemos condensar la información en un mapa, podemos considerar algunas secuencias para ganarle al dichoso casino.

Lo primero a considerar, que podría ser obvio, es que los espacios claros nos hacen perder, y es en los oscuros donde ganamos.

Dicho eso, asumamos que vamos a realizar una Martingala, solo que en vez de duplicar a la próxima ronda, haremos uso de diversas formas y espacios para colocar las fichas, veamos de nuevo el video del comienzo:

El encuadre: los valores fueron localizados, de manera inicial, y sin demasiado análisis, en una grilla de 600 x 600 pixeles, y cada unidad, fue definida en 6 pixeles, incluyendo los bordes, de manera que cada fila, dispone de 100 valores.

Considerando que hay 100 valores por fila, podemos decir con seguridad que serán 90 filas de 100, generando así el mapa de 9,000 unidades, más allá de lo difícil que pueda ser visualizarlo de esa manera.

La selección: esos pequeños cuadrados de color son el modelo con el cual vamos a realizar la progresión, de manera que si el cuadrado cae sobre un espacio blanco, perdemos, y duplicaremos las fichas para la próxima posición de la selección / el modelo seleccionado.


Revisando el modelo por medio de la imagen:

Es posible revisar el modelo de selección desde la imagen, solo a fines de darnos una idea de como funciona el mecanismo. Es claro que el proceso debe de ser llevado a una función, para luego analizar millones de formas usando ecuaciones sobre la db.

Primera imagen: Las posiciones 1, 2 y 3, de las 9 posiciones que conforman el grupo, al caer sobre casilleros blancos (casilleros inferiores a 2), son consideradas rondas perdidas. La posición se gana una vez que se alcanza la ronda #4, por lo que el final de la secuencia no se lleva a cabo.


Segunda imagen: no es más que una simulación válida de como se vería en realidad, dado que una vez que se ganó la ronda no es necesario seguir con la forma.


Tercera imagen: se puede ver una secuencia de secuencias, diversas formas siendo corridas a la par. Las formas/procesos no han sido cerradas al alcanzar el valor superior, por lo que la imagen no es una simulación válida, más que sirve para visualizar las posibles superposiciones y varias formas en paralelo.


Para finalizar: podemos una simulación más aproximada. Incluyendo un 32 (corresponde a 25 en poderes de dos). Y una superposición casi al final de la imagen, donde una posición es correspondida por dos secuencias, sumando 12, lo que corresponde a la suma de las dos secuencias 23 + 22

En caso de que la superposición persevere, las formas al cabo de unas rondas, bifurcaran sus caminos, anulando la superposición.

Llegado acá: quizás sea bueno recordar, que cada fila, dispone de 100 valores. De manera que la segunda posición, por más cerca que de la impresión de ubicarse de la primera, es en realidad, hecha, no 100, sino 200 rondas después (algo más de una hora después para el casino analizado). Del mismo modo , la #3 posición, posee un margen de 400 rondas, que sería calculable en un poco más de 2 horas de espera.


Traduciendo la forma a una ecuación.

Habiendo diseñado la primera forma, el próximo paso es pasarla a una función a fin de validarla, de corroborar las veces que gana y pierde al procesarla a la información previa. Comencemos:

  • #1 posición corresponde al round #1.
  • #2 posición, corresponde al round #201 (doble descenso)
  • #3 posición corresponde al round #401 (doble descenso)
  • #4 posición corresponde al round #403 (doble derecha)
  • #5 posición corresponde al round #405 (doble derecha)
  • #6 posición: corresponde al round #605 (doble descenso)
  • #7 posición: corresponde al round #805 (doble descenso)
  • #8 posición: corresponde al round #807 (doble derecha)
  • #9 posición: corresponde al round #809 (doble derecha)

Por lo que la forma se podría expresar como:

  1. x
  2. x + 200
  3. x + 400
  4. x + 402
  5. x + 404
  6. x + 604
  7. x + 804
  8. x + 806
  9. x + 808

En caso de perder el grupo, la perdida sería de 511 unidades, dada los nueve indices de la cadena. Fácil de calcular haciendo -1 sobre el próximo poder.


Pasando la función a SQL

Pasemos la operación a SQL para comenzar con las pruebas:

Lo que nos devuelve:

round value class creacion
1 15,49 high 2018-01-27 14:03:54
201 18,61 high 2018-01-27 15:59:57
401 69,42 high 2018-01-27 17:20:03
403 11,18 high 2018-01-27 17:21:47
405 2,3 high 2018-01-27 17:22:39
605 8,17 high 2018-01-27 18:36:23
805 2,5 high 2018-01-27 19:53:36
807 2 high 2018-01-27 19:54:33
809 1,41 low 2018-01-27 19:56:02

Se puede observar una diferencia de casi 6 horas desde la primera ronda hacia el final de la serie de 9. La aplicación que opere deberá usar una db para llevar la información bien organizada.


Simplificando la SQL:

Dado que con solo 1 valor mayor al dos, ya sabemos que la secuencia funcionó,  y considerando que la operación deberá de ser realizada más de medio millon de veces, podemos simplificar aún más la selección a fin de agilizar el proceso.

Lo que nos devuelve solo un valor!

round class_cadena
1 high, high, high, high, high, high, high, high, low

Ahora que ya creamos la selección en SQL, el próximo paso, es la creación de un guión que incluya la selección, y realice pruebas sobre cada uno de los 600,000 records, a fin de calcular, en primera medida, las veces que pierde, las veces que gana y la diferencia.


Evaluando el modelo:

La primera versión del código, a la cual decidí llamar “shape_eval.php” preparada para correr en cli php, se ve así:

Podemos correr el código sin más… “php -f shape_eval.php” y… llevarnos la agradable sorpresa de que la primera forma da mucha pelea! sin embargo, no logra ganarle en el largo plazo a la banca.


La primera secuencia perdida, se ve en la ronda 1675, para cuando lleva ganadas, 1,674 rondas (o bien el mismo número en dólares) y luego pierde 511 unidades.

En el largo plazo el dinero acumulado, crece y decrece, pero no alcanza valores considerables.

[round] => 1673
[class_cadena] => hi, hi, low, low, low, hi, low, low, low
[dinero] => 1673

[round] => 1674
[class_cadena] => hi, low, hi, low, hi, hi, low, low, low
[dinero] => 1674

[round] => 1675
[class_cadena] => low, low, low, low, low, low, low, low, low
[dinero] => 1163

Podemos confirmar la perdida, usando la seleccion SQL previa con el valor 1675.


Subiendo la velocidad del guión

A fin de probar una infinidad de formas posibles, queremos que el código corra y nos de la información lo más rápido que pueda.

Conservamos la primera versión, dado que nos da la información necesaria para una revisión manual y  pasamos a crear una nueva copia del código para realizar algunos cambios:

$ php -f quick_shape_eval.php
Ronda: 1675, Dinero: 1163

La nueva versión nos da la información sin demoras.


Nuevas figuras, creación de formas

El código que lo genera no es más que una nueva forma. Al parecer las formas en verdad producen grandes variaciones.

Observaciones: se aplica una variable desplazador, a fin de mover la segunda figura, varias posiciones, luego, se emplea una función rand a fin de generar variaciones azarosas en el desplazador.


$ php -f quick_shape_eval.php

  • Ronda: 3231, Dinero: -865, Desplazador: 18
  • Ronda: 18096, Dinero: 9904, Desplazador: 18
  • Ronda: 19703, Dinero: 7415, Desplazador: 18
  • Ronda: 24122, Dinero: 7738, Desplazador: 18
  • Ronda: 31079, Dinero: 10599, Desplazador: 18
  • Ronda: 38339, Dinero: 13763, Desplazador: 18
  • Ronda: 42237, Dinero: 13565, Desplazador: 18
  • Ronda: 43859, Dinero: 11091, Desplazador: 18
  • Ronda: 44135, Dinero: 7271, Desplazador: 18
  • Ronda: 62462, Dinero: 21502, Desplazador: 18
  • Ronda: 66130, Dinero: 21074, Desplazador: 18
  • Ronda: 67874, Dinero: 18722, Desplazador: 18
  • Ronda: 69164, Dinero: 15916, Desplazador: 18
  • Ronda: 77431, Dinero: 20087, Desplazador: 18
  • Ronda: 78524, Dinero: 17084, Desplazador: 18
  • Ronda: 78916, Dinero: 13380, Desplazador: 18
  • Ronda: 96787, Dinero: 27155, Desplazador: 18
  • Ronda: 96909, Dinero: 23181, Desplazador: 18
  • Ronda: 108596, Dinero: 30772, Desplazador: 18
  • Ronda: 108852, Dinero: 26932, Desplazador: 18
  • Ronda: 109057, Dinero: 23041, Desplazador: 18
  • Ronda: 111030, Dinero: 20918, Desplazador: 18
  • Ronda: 111478, Dinero: 17270, Desplazador: 18
  • Ronda: 119748, Dinero: 21444, Desplazador: 18
  • Ronda: 123396, Dinero: 20996, Desplazador: 18
  • Ronda: 124455, Dinero: 17959, Desplazador: 18
  • Ronda: 127590, Dinero: 16998, Desplazador: 18
  • Ronda: 133603, Dinero: 18915, Desplazador: 18
  • Ronda: 144724, Dinero: 25940, Desplazador: 18
  • Ronda: 145982, Dinero: 23102, Desplazador: 18
  • Ronda: 150853, Dinero: 23877, Desplazador: 18
  • Ronda: 157389, Dinero: 26317, Desplazador: 18
  • Ronda: 158789, Dinero: 23621, Desplazador: 18
  • Ronda: 164318, Dinero: 25054, Desplazador: 18
  • Ronda: 171312, Dinero: 27952, Desplazador: 18
  • Ronda: 172869, Dinero: 25413, Desplazador: 18
  • Ronda: 172954, Dinero: 21402, Desplazador: 18
  • Ronda: 175171, Dinero: 19523, Desplazador: 18
  • Ronda: 187356, Dinero: 27612, Desplazador: 18
  • Ronda: 189630, Dinero: 25790, Desplazador: 18
  • Ronda: 191617, Dinero: 23681, Desplazador: 18
  • Ronda: 200002, Dinero: 27970, Desplazador: 18
  • Ronda: 200229, Dinero: 24101, Desplazador: 18
  • Ronda: 212277, Dinero: 32053, Desplazador: 18
  • Ronda: 216709, Dinero: 32389, Desplazador: 18
  • Ronda: 222839, Dinero: 34423, Desplazador: 18
  • Ronda: 229282, Dinero: 36770, Desplazador: 18
  • Ronda: 229714, Dinero: 33106, Desplazador: 18
  • Ronda: 230079, Dinero: 29375, Desplazador: 18
  • Ronda: 230603, Dinero: 25803, Desplazador: 18
  • Ronda: 230704, Dinero: 21808, Desplazador: 18
  • Ronda: 244536, Dinero: 31544, Desplazador: 18
  • Ronda: 248401, Dinero: 31313, Desplazador: 18
  • Ronda: 254168, Dinero: 32984, Desplazador: 18
  • Ronda: 254246, Dinero: 28966, Desplazador: 18
  • Ronda: 258557, Dinero: 29181, Desplazador: 18
  • Ronda: 260179, Dinero: 26707, Desplazador: 18
  • Ronda: 262689, Dinero: 25121, Desplazador: 18
  • Ronda: 263019, Dinero: 21355, Desplazador: 18
  • Ronda: 265546, Dinero: 19786, Desplazador: 18
  • Ronda: 266976, Dinero: 17120, Desplazador: 18
  • Ronda: 267080, Dinero: 13128, Desplazador: 18
  • Ronda: 273700, Dinero: 15652, Desplazador: 18
  • Ronda: 277167, Dinero: 15023, Desplazador: 18
  • Ronda: 280853, Dinero: 14613, Desplazador: 18
  • Ronda: 304613, Dinero: 34277, Desplazador: 18
  • Ronda: 307634, Dinero: 33202, Desplazador: 18
  • Ronda: 308924, Dinero: 30396, Desplazador: 18
  • Ronda: 309982, Dinero: 27358, Desplazador: 18
  • Ronda: 314732, Dinero: 28012, Desplazador: 18
  • Ronda: 317613, Dinero: 26797, Desplazador: 18
  • Ronda: 319695, Dinero: 24783, Desplazador: 18
  • Ronda: 322440, Dinero: 23432, Desplazador: 18
  • Ronda: 330094, Dinero: 26990, Desplazador: 18
  • Ronda: 336068, Dinero: 28868, Desplazador: 18
  • Ronda: 339955, Dinero: 28659, Desplazador: 18
  • Ronda: 341990, Dinero: 26598, Desplazador: 18
  • Ronda: 349877, Dinero: 30389, Desplazador: 18
  • Ronda: 352397, Dinero: 28813, Desplazador: 18
  • Ronda: 359724, Dinero: 32044, Desplazador: 18
  • Ronda: 366472, Dinero: 34696, Desplazador: 18
  • Ronda: 375968, Dinero: 40096, Desplazador: 18
  • Ronda: 382842, Dinero: 42874, Desplazador: 18
  • Ronda: 382903, Dinero: 38839, Desplazador: 18
  • Ronda: 383146, Dinero: 34986, Desplazador: 18
  • Ronda: 388984, Dinero: 36728, Desplazador: 18
  • Ronda: 389027, Dinero: 32675, Desplazador: 18
  • Ronda: 390477, Dinero: 30029, Desplazador: 18
  • Ronda: 395623, Dinero: 31079, Desplazador: 18
  • Ronda: 398773, Dinero: 30133, Desplazador: 18
  • Ronda: 403242, Dinero: 30506, Desplazador: 18
  • Ronda: 404540, Dinero: 27708, Desplazador: 18
  • Ronda: 405695, Dinero: 24767, Desplazador: 18
  • Ronda: 416663, Dinero: 31639, Desplazador: 18
  • Ronda: 417750, Dinero: 28630, Desplazador: 18
  • Ronda: 417885, Dinero: 24669, Desplazador: 18
  • Ronda: 423093, Dinero: 25781, Desplazador: 18
  • Ronda: 423322, Dinero: 21914, Desplazador: 18
  • Ronda: 425134, Dinero: 19630, Desplazador: 18
  • Ronda: 427026, Dinero: 17426, Desplazador: 18
  • Ronda: 431638, Dinero: 17942, Desplazador: 18
  • Ronda: 436953, Dinero: 19161, Desplazador: 18
  • Ronda: 439344, Dinero: 17456, Desplazador: 18
  • Ronda: 448850, Dinero: 22866, Desplazador: 18
  • Ronda: 449248, Dinero: 19168, Desplazador: 18
  • Ronda: 449290, Dinero: 15114, Desplazador: 18
  • Ronda: 451003, Dinero: 12731, Desplazador: 18
  • Ronda: 454174, Dinero: 11806, Desplazador: 18
  • Ronda: 458870, Dinero: 12406, Desplazador: 18
  • Ronda: 461360, Dinero: 10800, Desplazador: 18
  • Ronda: 468043, Dinero: 13387, Desplazador: 18
  • Ronda: 468505, Dinero: 9753, Desplazador: 18
  • Ronda: 479012, Dinero: 16164, Desplazador: 18
  • Ronda: 483270, Dinero: 16326, Desplazador: 18
  • Ronda: 484982, Dinero: 13942, Desplazador: 18
  • Ronda: 486061, Dinero: 10925, Desplazador: 18
  • Ronda: 486824, Dinero: 7592, Desplazador: 18
  • Ronda: 487129, Dinero: 3801, Desplazador: 18
  • Ronda: 490896, Dinero: 3472, Desplazador: 18
  • Ronda: 491291, Dinero: -229, Desplazador: 18
  • Ronda: 505451, Dinero: 9835, Desplazador: 18
  • Ronda: 517919, Dinero: 18207, Desplazador: 18
  • Ronda: 517920, Dinero: 14112, Desplazador: 18
  • Ronda: 524365, Dinero: 16461, Desplazador: 18
  • Ronda: 526280, Dinero: 14280, Desplazador: 18
  • Ronda: 535773, Dinero: 19677, Desplazador: 18
  • Ronda: 540430, Dinero: 20238, Desplazador: 18
  • Ronda: 544392, Dinero: 20104, Desplazador: 18
  • Ronda: 548472, Dinero: 20088, Desplazador: 18
  • Ronda: 557763, Dinero: 25283, Desplazador: 18
  • Ronda: 565300, Dinero: 28724, Desplazador: 18
  • Ronda: 568509, Dinero: 27837, Desplazador: 18
  • Ronda: 573013, Dinero: 28245, Desplazador: 18
  • Ronda: 574357, Dinero: 25493, Desplazador: 18
  • Ronda: 575661, Dinero: 22701, Desplazador: 18
  • Ronda: 580807, Dinero: 23751, Desplazador: 18
  • Ronda: 586002, Dinero: 24850, Desplazador: 18
  • Ronda: 588750, Dinero: 23502, Desplazador: 18
  • Ronda: 591143, Dinero: 21799, Desplazador: 18
  • Ronda: 591243, Dinero: 17803, Desplazador: 18
  • Ronda: 591644, Dinero: 14108, Desplazador: 18

Será resumido…


Creo que a fin de finalizar la idea, o al menos la publicación, a modo de darle un cierre a la visualización de azar, sería bueno poner la imagen final que logré generar procesando cada uno de los valores, desde el comienzo, al día de hoy.

La imágen posee buena resolución y pesa alrededor de los dos megas, asumo que puede ser usada como referencia si se desearan buscar formas en el mapa. Cada unidad se compone de 6 pixeles.