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.

 

Desarrollando un videogame: revision 7

Diseño:

Se realizaron cambios generales sobre el diseño, el leaderboard ocupa su propia columna, quedando la conversación al inferior del canvas. Los grises se oscurecieron un poco.

  • Full screen:
    • Si la resolución es mayor o igual a 1380 pixeles
    • El canvas debería de ocupar un máximo de 800 pixles.
    • El leaderboard debería de ocupar un máximo de 570 pixeles.
    • Espacios en blanco de 10 pixeles
  • Medium screen:
    • Si la resolución es mayor o igual a 1150 pixeles y menor a 1380 pixles
    • El canvas debería de ocupar un máximo de 800 pixles.
    • El leaderboard debería de ocupar un máximo de 340 pixeles.
    • Espacios en blanco de 10 pixeles
    • Dimension final full screen 1150 pixeles
  • Small screen
    • Si la resolución es mayor o igual a 800 pixeles y menor a 1150 pixeles
    • Cargar nuevo css
    • Dimension final mínima de 800 pixeles
    • Canvas 800 pixeles.
    • Leaderboard después del canvas, 800 pixeles.
    • Conversación, después de leaderboard, 800 pixeles.

Modificaciones en Node:

Creo la publicación a fin de enumerar cada uno de los cambios que realizo al día de la fecha, o, por decirlo más claro, los cambios que voy a realizar ahora mismo y aquellos que observo, pero quedarán para modificar luego.

  • ✓ Se corrigen varias palabras y links
  • ✓ Cada pedido a la API debería de ser imprimido en consola (sside)
  • ✓ Acceso de usuario
  • ✓ Acceso de usuario funcional.
  • ✓ Se consigue visualizar la información del usuario sin problemas.
  • ✓ Se crea una cookie con la información del usuario desde la función.
  • ✓ Si le damos un usuario inválido, el canvas no carga.
  • ✓ La función  send_name() se encarga de procesar el acceso
  • ✓ La unidad es creada desde (lib/game) por medio de la función addNewPlayer
  • ✓ Usuario inválido: no se observan modificaciones en canvas.
  • ✓ Usuario inválido: no se observan modificaciones en barra superior.
  • ✓ Se elimina welcome de admin cuando se crea un usuario.
  • ✓ Se elimina welcome y explicación de como moverse.
  • ✓ Creación de cookie en caso de usuario válido.
  • ✓ Los usuarios válidos reciben una cookie con su información y acceden.
  • ✓ Los usuarios inválidos reciben un warning.
  • ✓ Llenar campos con la información de las cookies.
  • ✓ El usuario sigue con la información en cookies y puede resumir.
  • ✓ Respawn de usuario funcional.
  • ✓ Demorar de cierre de sesión
  • ✓ Se espera de 10 segundos para eliminar el player, despues de que se va.
  • ✓ Cierre de sesión funcional.

Modificaciones en la API

  • ✓ Crear usuario
  • ✓ Eliminar usuario
  • ✓ Iniciar sesión
  • ✓ Cerrar sesión
  • ✓ Recuperar password
  • ✓ Enviar dinero
  • ✓ Sacar dinero

Creación de usuario

Hace posible la creación de un nuevo usuario, el campo de email es opcional, haciendo posible una creación rápida de usuarios. Los passwords deberían ser pregenerados.

  • model: user/new
  • email: opcional, dirección de email.
  • username: requerido, nombre de usuario.
  • password: requerido, password.

www.lafinex.com/bow/index.php?model=user/new&email=warhead@codefen.com&username=warhead&password=xxx

 


Eliminación de usuario:

Esconde la información del usuario para que ya no sea indexable, no clasifique en el leaderboard, no se pueda acceder y demás. La información se preserva en caso de que sea necesaria para revisiones.

  • model: user/del
  • username: requerido, nombre de usuario.
  • password: requerido, password.

www.lafinex.com/bow/index.php?model=user/del&username=chris&password=xxx


Iniciar sesión

Revisa si el nombre de usuario y password son válidos, devuelve como siempre el usuario, marca el usuario como ‘online’.

  • model: user/access
  • username: requerido, nombre de usuario.
  • password: requerido, password.

www.lafinex.com/bow/index.php?model=user/access&username=chris&password=xxx


Cerrar sesión

Revisa si el nombre de usuario y password son válidos, y devuelve como siempre el usuario, marca el usuario como ‘offline’.

  • model: user/close
  • username: requerido, nombre de usuario.
  • password: requerido, password.

www.lafinex.com/bow/index.php?model=user/close&username=chris&password=xxx


Recuperación de usuario

Especificada una dirección de email, envía el nombre de usuario y el password a la misma, sin más razones ni acciones, no informa si la dirección es válida o no.

Vale la pena aclarar que los emails no son clave única, por lo que es posible crear cualquier número de usuarios con solo un email. Además, si no fuera así, sería posible analizar que emails son válidos, por medio de la creación de nuevos usuarios.

En caso de que la dirección de email posea más de un usuario, se le enviará un email por cada usuario válido que posea, excluyendo los usuarios eliminados.

  • model: user/recover
  • email: requerido, dirección de email.

 

 

 

Desarrollando un videogame: revision 6

Se proponen algunos cambios en el diseño de la versión 3

Se oscurecen más el cuadro de leaderboard y las conversaciones. Se realizan modificaciones en la barra superior.

Considero que quizás sea preferible que la barra superior vuelva a cubrir el 100% del ancho.

El cambio de colores hace lucir mucho más el canvas.


Se realizan modificaciones en el backend:

Se incorporan campos a la db, y se guarda nueva información.

1 id id del usuario
2 email dirección de mail opcional
3 username nombre de usuario
4 password password
5 won veces que ganó
6 lose veces que perdió
7 difference diferencia de dinero, ganancias
8 balance el dinero que dispone
9 online online o offline
10 eliminado no se elimina de verdad
11 creacion fecha de creación

La nueva información disponible en usuarios hace posible crear el leaderboard de la derecha, con los usuarios online, y la sección de leaderboard, la cual devuelve los 100 primeros usuarios, online y offline.


Pidiendo el leaderboard:

www.lafinex.com/bow/index.php?model=view/leaderboard

Params requeridos:

  • leaderboard_online: zero o uno, cualquier usuario o solo online (uno).
  • leaderboard_size: 30 o 50, el máximo de usuarios que devuelve.

Los usuarios se devuelven ordenados por ganancias (difference), aunque no se vea eso en el código simplificado que he publicado.

Insomnio

Esos días, aquellos días, muchos son los días, días como hoy, días como ahora, en los que no me puedo dormir. Me cambio, voy a la cama, apago las luces, y no me puedo dormir, giro sobre el lugar, muevo la almohada y no me puedo dormir.

Agarro el celular pongo un audiolibro, y lo escucho, lo escucho con ganas, para dormirme, pero no me duermo. Voy por un clonazepam, un refuerzo de dosis, pongo de nuevo el audiolibro, no me duermo. Un cigarrillo, pero aún no me duermo.

No me duermo porque se me ocurrió una nueva empresa, una nueva idea, no me duermo porque hay algún problema que resolver, no me duermo porque no hay ningún problema que resolver, o porque me olvidé de hacer algo, algo que debería haber hecho pero no hice, por eso no me duermo.

Bien quizás no me duermo porque una empresa salio bien, o quizás porque salió mal, porque la idea funcionó, o quizás no me duermo porque me quedo pensando, me quedo pensando cualquier cosa que creo que debería de haber hecho, o creo que debería de hacer ya, apenas pueda.

No quiero esperar, no quiero esperar mucho, porque pienso que si no las hago quizás me olvide, o porque pienso que si no lo pienso y me voy a dormir, quizás, mañana no lo piense.

Así que me quedo pensando, y sigo pensando que debería pensar, y después me acuerdo que debería dormir, y empiezo a dudar sobre si en verdad quiero dormir, o si solo quiero dormir porque alguien quiere que quiera dormir. Pero que no me puedo dormir. No me duermo porque se me ocurren cosas, no me duermo porque la ansiedad no quiere que me duerma.

La necesidad de repasar las cosas que se hicieron en el día y las cosas que se van a hacer mañana. O que más se podría hacer, previo a finalizar el día.

Ahora sí me voy a dormir.

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