Desarrollando un videogame: revisión 25

  • Modificaciones en landing:
    • El landing debería ser revisado una vez que funcionen ambas versiones (26)
  • Modificaciones en versión libre:
    • Añadir background images, flipeando, igual a versión comercial.
    • Añadir header (Brand + mancha + laser), animación sería buena!
    • Rediseñar el módulo que pide nombre de usuario
    • Incorporar la “dead sequence” (igual a versión final)
    • Imagenes panzer previo.
    • Imagenes explosión previa
    • Incorporación de música de fondo.
    • Incorporación de sonidos.
    • Incorporación de player hub
    • Incorporación de sidebar (seguimos el psd por ahora)
  • Modificaciones versión final:
    • Analyze and fix XSS.
    • Fix dialog encoding issues.
    • Finish cashier (show previous xfers)

Finalización de bow.

Al finalizar las modificaciones, la aplicación se debería de probar, en búsqueda de cualquier fricción en el proceso, realizando las modificaciones necesarias en la landing page para generar el máximo engage posible. Una vez que la landing page, re-envíe más de 50% de los usuarios hacia la versión de prueba sin cargo, podríamos confirmar que: la landing page funciona de manera adecuada, que se ha dado con un público adecuado, y así ver los diversos canales de publicidad, donde hay mayor “adhesión”, considerando las diversas combinaciones de medios y canales de publicidad a fin de llegar al publico de mayor agarre del landing.

Una vez que el landing cumpla su función, debemos asegurarnos de que la versión de pruebas cumpla su función, dado que no es más que un eslabón más del embudo, con el único fin de enviar, de una manera pulida y armoniosa, el mayor número posible de usuarios hacia la versión con BTC.

La versión comercial, para finalizar, deberá cumplir su fin, y conseguir que los usuarios prueben con pequeños valores de dinero y pasen unas horas agradables.

Próximos pasos.

Asumiendo que el equipo logra hacer funcionar bow por si solo, considerando que genera ganancias mensuales, sería recomendable considerar una expansión hacia 2 direcciones principales:

Expandir las aplicaciones que funcionan bien, lo que sea que duren, con cuidado de no hacer esfuerzos o inversiones en hacer que algo siga, si es que pasa de moda o no posee el grip necesario.

Expandir la red: la idea de la red de aplicaciones donde solo se genera un único login, con una única dirección para enviar y recibir dinero, es sin dudas una gran idea y la base necesaria para el desarrollo de aplicaciones en escala, dado que agrupa cada una de las funciones principales y necesarias para cada app, poniéndolas en un solo pack que podría ser “include psychedelic-games”

Asumo que una de las formas más simples de llevarlo a cabo, sería haciendo primero la aplicación descargable y self-refreshing, para luego incorporarle el login, las diversas funciones ya creadas y el game luncher, que llevaría una landing propia del game, y alguna información del mismo, previo a lanzarlo full screen.

Poker es lo que sigue.

Sobre la información

Mi negocio es vender información. Compro información de la empresa A que quizás le pueda servir a la empresa B. Busco información por acá y allá sobre como hacer algo, incluso busco información sobre como buscar información…

Cuando busco información, uso programas e información, para buscar información, aplicaciones y espacios diseñados para buscar esa clase de información en esa red. A veces cuando busco información es necesario escribir algun programa para sacar esa información, y a veces la información es impossible and overwhelming de minar sin darle alguna función media.

A veces consigo la información solo para después usarla. A veces me paso meses buscando información. A veces empleo bien la información, a veces no. Con la información, a veces me pongo a crear algunos mecanismos, que consigan más información. A veces me sale, a veces no.

La información es como un Manual de cocinas. De hecho, un manual de cocinas es información: en sí misma no parecen más que un grupo de funciones ordenadas de una forma peculiar, definida por quien sea que lo escriba, a quien decidiremos si creerle o no, si seguirlo o no.

En cualquier caso, cuando se llevan a cabo los pasos de un manual de cocina del modo indicado, se consigue lo mismo que anuncia la formula, se llega siempre a la misma posición. El manual explica como hacerlo, y eso asumo que es información.

Desarrollando un videogame: revision 24: orden y canal.


Orden y progreso desde acá:

Seguir la revisión 25 para ver los diversos cambios a ser realizados.


  1. Finalizar de la versión libre.
  2. Finalizar de la versión comercial.
  3. Nueva versión de landing.
  4. Inversiones en publicidad.

Sobre el canal de conversión

El landing es donde va a caer la publicidad. Acá la consigna es muy simple, y considero no más de 3 pilares principales:

Primero: que sea increíble. La primera impresión debería de ser un vídeo de fondo, con acción, animado, que sorprenda y a la derecha, un encabezado, 3 pequeñas descripciones y un play now.

Segundo: que sea real! creo que salvo que la conversión sea mucho mayor, es preferible y poner una animación del gameplay, a poner un png de un panzer que nunca se verá en el gameplay. Es válido decir que es análogo, y que podría corresponder, de hecho corresponde con la idea en sí, sin embargo, creo que unas buenas escenas de acción, con un poco de Adobe AA podría rendir muy bien.

Tercero: incorporar algunos bloques adicionales en el 1 pager, con más CTA, e información sobre la app, la red y demás cosas que puedan servir, en espacial menciones que sirvan para comenzar con el SEO.$

La publicidad debería dirigirse solo a personas que usen o bien ya posean BTC, por lo cual, cuan más cerca podemos ir de ese público, creería que la publicidad será más eficaz.

Se podrían considerar foros de BTC, o incluso esas redes de publicidad, donde solo podes pagar con BTC para anunciar en redes de webs que reciben pagos en BTC y hablan solo de BTC. No recuerdo el nombre ahora, pero recuerdo que alguién me lo mencionó en los foros de BTC.

En lo personal, considero que es de esperarse que anunciar en esas redes, genera mayor conversión que anunciando en google. Sin embargo, vamos a realizar inversiones diversificadas en diversas redes para examinar bien las variables de conversión.

Se debería de explorar una diversificación de medios, incluyendo publicidad en vídeo, quizás 2 o 3 vídeos, banners, los cuales habría que ir variando y explorando para conseguir una eficacia ideal.

Se recomienda comprar news en Magazines de BTC o webs de BTC de las más conocidas, debería de haber una compra de links, o un volúmen de menciones cada mes un poco más grande. Quizás sea recomendable, buscar una empresa que organice la campaña de SEO, y una empresa que organice una campaña de SEM.

Desde el lado económico, el SEM bien aplicado, podría pagar, las inversiones, por lo general, más a largo plazo del SEO, que se podría decir que es más similar a sembrar y esperar. Aunque quizás algunas publicaciones en blogs, podrían generar grandes conversiones.

El embudo de conversión, o el camino que va a recorrer el usuario, pasa a ser:

Es recomendable realizar variaciones, dirigiendo los usuarios desde la landing a la versión free vs la versión comercial, analizando así cual rinde más. También es recomendable correr pruebas de A/B sobre la misma landing, mapas de calor, y las posiciones por donde se mueve el mouse del usuario.

De modo que podamos ver por donde hace click, por donde no hace click, por donde se mueve y que considera hacer.

La realidad como un plano

Es acá y ahora. Para mi, es lo más lógico, pensar en acá y ahora como una posición en un plano, un espacio bidimensional, y definir ese acá y ahora como posición inicial, para luego imaginar una segunda posición, dimensionarla y posición ideal.

Pensar en la linea que va desde la posición inicial, desde ahora, hacia la posición ideal de algo, es pensar en cada una de las modificaciones que deberían de aplicarsele al “ahora”.

Ahora, el ahora, la posición inicial no es más una posición en un plano bidimensional, dado que no me sirve la analogía, y pasa a ser un array, con millones de propiedades y una infinidad de arrays formando vínculos, y referencias imposibles, hacia profundidades de información que desconocemos.

Para simplificarlo, podríamos imaginar un zoom sobre la posición inicial, de manera que se puedan ver esas propiedades mayores, sus funciones, y las funciones de sus childs.

Analizando ambos grupos, quizás lo único que queda analizar, es:

  1. ¿Que modificadores debería aplicar en A para llegar a B?
  2. ¿Que funciones de A podría usar?
  3. ¿Que propiedades de A y B son iguales, cuales cambian?
  4. ¿Que personas podrían modificar una propiedad de A por una de B?
  5. ¿Cómo se verían diversas posiciones en le medio de A y B?
  6. ¿Que propiedades cambiarían primero de A hacia B?
  7. ¿Cual sería el orden?

So on…

Desarrollando un videogame: revision 23

Revisión final previo a comenzar la promoción.

Hecho:

  •  red cuando lo dañan ✓
  •  recrear mismo FX armado por canvas ✓
  •  lineas de ganancia ✓
  •  función de respawn ✓
  •  manchas en el piso al eliminar unidad ✓
  •  linea proyección munición ✓
  • máximo de 5 powerups por vida ✓
  • powerups sin cargos adicionales ✓
  • cobrar por cada spawn ✓

En curso:

  • menú inicial nuevo, sonido y videos.
  • link creds
  • separación cs
  • modificar de daño
  • reincorporar blockchain

Por hacer:

  • animaciones diversas de av
  • animaciones canvas
  • animaciones player_hub
  • ai

Después del cierre:

  • Trailer videos para publicidad
  • Versiones para Windows, Linux y Mac
  • Revisión general, concurso por una Rx580

Fecha de cierre deseada: 31/10/2018

Desarrollando un videogame: revision 22

Limbo

En búsqueda del balance, es necesario darle al usuario la chance de salir sin perder más dinero del que desea perder. Creo que en especial, aplica al usuario que pierde, dado que el que viene ganando y sigue ganando dinero, no posee la misma necesidad de abordar una salida, como el que viene perdiendo.


Transcripción:

Una de las cosas que hay que hacer para llegar a donde queremos llegar, es hacer que el player clickee en respawn o en cancel, previo a respawnear…

Es decir, que pueda elegir lo que hacer después de perder. El problema acá es que en lo que refiere al player, Game posee dos condiciones: hay player o no hay player.

Si no hay player, no puede ver las balas que se aproximan a él, ni las balas que hay cerca de él, ni los powerups cerca de él, o los demás players, porque, incluso haciendo un bypass de las funciones, el player no dispone de posición ni nada de manera que me es imposible clavarlo.

Si hay player, por lo general, era una unidad y ya… osea, no hay diseñada, forma alguna donde el player no pueda moverse, no sea visible, no hay modo alguno para que el usuario pueda ver, sin presencia.



Opción inválida: desconexión:

Una opción, que es la primera que abordé, es sacarle la presencia al player, osea, desenchufarlo, hacer una desconexión.

El problema acá es, más bien… los problemas acá, son varios, empezando porque si el player quiere hacer un respawn, debería de crear una nueva conexión, y en segundo lugar, la información que va y viene desde el player va hacia la nada, y el browser queda esperando información la cual no va a llegar nunca porque la conexión al sock fue eliminada.


Opción válida:

Lo que diseñamos, del drone, para que el usuario pueda ver cuando se queda con poco dinero, corresponden a funciones de la misma función respawn.

Es quizás lo más cercano a lo que habría que hacer. El problema con eso, es que apenas lo liquidas aparecería un drone donde había una unidad…

Lo que buscamos acá es que si la “vida/energia” es inferior o igual a 0, sea una sombra… una vara clavada en el piso, invisible, imposible de moverse quizás… esperando que el usuario seleccione si quiere respawnear o no.

Si el usuario no quiere respawnear, habría que reenviarlo a la selección de servidores, que debería de verse en el menú principal.

Las imagenes que ponemos cuando el usuario pierde, la calabera, habría que dividirla en 2. Haciendo que corra la primera función y que luego el usuario seleccione si quiere volver o salir.

Si quiere volver, ahí corremos respawn, respawn mismo revisa el dinero del usuario y le daría una nueva unidad o un drone, dependiendo del dinero disponible del usuario.

Si quiere salir, ahí si puedo correr la función de desconexión y llevarlo de nuevo al main menu. Eso, debería de verse… más o menos así:

La propiedad player.is_drone deberia de remplazarse por algo así como player.class de forma global, a fin de hacer posible incorporar diversas clases de player, los cuales conllevarían propiedades no siempre iguales.

Con algunas modificaciones a fin de que no sea visible para los demás, y modificando la clase player, porque cuando creamos los drones, esperabamos un boolean (es drone, si o no), sin embargo, ahora debería de haber, al menos 3 clases:

  • panzer
  • drone
  • shadow

Hecho eso, player quedaría en shadow esperando que decida si quiere o no respawnear y un clock de 5′ para que reaparezca como un panzer o un drone.

En lo gráfico, eso debería de verse así…

 

Donde esa escena debería de quedar esperando que el player defina si quiere seguir o no, unos 5 segundos y respawnearlo solo en 5 segundos o bien, 8 segundos si no hace nada.

Tenerlo en espera ahí, es un sock más, recibiendo y enviando información que no hace nada…

El foco debería de sacarse del canvas, y llevarlo hacia el menú superior, incluso quizás el menú ese debería de ser un canvas full screaneado.


Yeap, eso debería de funcionar. Para sumarle esencia a eso, se podría mandar información al usuario para que cambie la música de fondo y darle un poco más de drama…

Desarrollando un videogame: revision 21

Bueno señores, revisión final, previo a poner a un nuevo equipo a cargo del área de publicidad y ver como funciona en vivo.

  • Mapas para 10 usuarios ( 2500 pixeles cada 2 usuarios).
  • Acomodar disparo de 2.
  • Main_ammo de nuevo a common al finalizar poder.
  • Kill devuelve valores sin ceros.
  • Sacar Blockchain rescan.
  • Poner creds.
  • Armar creds.
  • Respawn con demora de 3 secs cancelable.
  • Reincorporar vibración del cavas con mayor elegancia.
  • Procesar el balance real en las lineas de dinero.
  • Aun el problema del keydown.
  • Icono Full screen inferior izquierda.
  • Achicar un poco el icono de discord.

Usuario de prueba: desconexion22.

Misphonia

La wikipedia dice, yo lo re-organizo:

 

Explorar la relación sonido vs emociones.

Debo reconocér que incorpórar los sonidos de Broncoespasmos, Tachycardia, acúfenos y algunas cosas más, me fue difícil.

El hacedor

 

Desarrollando un videogame: revision 20

Livianas:

  • El usuario puede definir su password.
  • Información cuando hay errores de creación.
  • Información cuando hay errores de acceso.
  • Eliminar símbolo de dolares.
  • Eliminar funciones de conversión a dólares.
  • (Tuna) Nueva animación de player en llamas.
  • (Tuna) Variación de color ínfima en él header.
  • (Tuna) Diseño de información (kills, compra de powerup, so on)
  • Armar los 3 iconos de los 3 powerups nuevos.
  • Modificación de colores en munición.
  • Crear gráficos balance con información.
  • Los gráficos se llenan ambos sin problemas, se sacó el color de fondo.
  • Cambiar fondos del gráfico según corresponda.
  • Acomodar la vibración del canvas o body.
  • Sonidos:
    • Remplazar los sonidos por los nuevos, con urgencia.
    • Los sonidos de la munición solo cuando disparas.
    • Cambiar sonidos dependiendo del ammo usado.
    • Sonidos para daño recibido
    • Sonidos eliminación.
    • Sonidos corzarón.
  • Todas las armas deberían disparar con mouse_up
  • A excepción de Assassin MK1, que reconoce hold.
  • Añadir clase de animación.
  • Animación explosiones nuevas.

Pesadas:

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

Vinculadas:

  • Armar logo de Psychedelic Games
  • Armar web de Psychedelic Games
  • Armar emails de Psychedelic Games
  • Presencia en redes sociales, en progreso.
  • Se avisa revisión previo a lanzar cualquier cosa más sería.

Opcionales:

  • Añadir imágen para cada usuario, opcional.
  • Sacandola desde facebook. O subiendola.
  • Conexión a facebook
  • Expandir los mapas?
  • Añadir zombies o cualquier clase de enemigo simple
  • Generación de muros al azar?
  • Creación de rondas?
  • Comenzar ronda cuando hay 5 players ready?