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?

 

 

 

 

Megalomanía

Se lanza BOW y funciona bien, sale en la prensa, en páginas inmensas. Todos lo conocen. El equipo, sale en diarios y prensa local. Sale bien lo de las Visas, sale bien el negocio del Club, sale bien el negocio de los Renders, sale bien el negocio de seguridad con el gobierno, se consiguen empresas más grandes que prueban la aplicación, el empresario ya es conocido!

El empresario comienza a hacer varias apariciones públicas en radios y emisoras públicas, revelando información desconocida y maravillosa para la audiencia quienes disconformes y sin saberlo esperan un cambio.

El empresario luego se anuncia para la presidencia con un programa de clonación humana avalada por el gobierno, dando recursos a la experimentación con ingeniería genética, flexibilizando las leyes que la demoran.

Se organizan grandes pools de AI para procesar información en vivo sobre la seguridad, los indices de defunciones y incorporaciones, enfermedades, salud, economía y consumo de recursos.

Indices de cualquier clase rebalsan de información por cada uno de los barrios del pais, en cada uno de los leds ubicados para la rápida mirada diaria.

Un ordenador principal ahora supervisa las operaciones económicas, se propone unificación de una moneda única basada en blockchain.

Se propone un sistema de polls periódico donde cada ciudadanos pueda elegir que quieren aprobar y que no, la información de las elecciones es procesada y enviada en vivo a los inmensos displays que supervisan la información de la población por zonas.

Gana las elecciones después de hacer miles de apariciones descabelladas en la TV. Los planes comienzan a llevarse a cabo, la clonación…

Sobre las opiniones

Toda opinión es, de algún modo, una buena opinión, favorable para el que sabe escuchar. Creo que siempre se las puede aprovechar para comprender algo de uno mismo y algo de quien opina. Cada frase revela un poco sobre el emisor, sobre su personalidad, sobre lo que observa y su modo de observar.

Desarrollando un videogame: revision 19

Revisión 19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(17) colocar SSL sobre el S3, index.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Se crearon y definieron los servidores:

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

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