Undead Code: Internet, web 2.0, videojuegos y software » Win or Defeat

WoD, abierta beta pública

Eduardo Millán — Wed, 18 Feb 2009 10:41:18 +0000

Aunque desde hace varios días el registro en Win or Defeat era libre, hoy comunicamos de forma oficial la apertura de la beta pública. Hemos acelerado un poco el proceso, debido a que tenemos un especial interés en ir recibiendo feedback masivo de mejoras y nuevas funcionalidades deseadas. Tenemos ya muchas en mente, pero debido a la magnitud de la aplicación y otros factores, el avance de esas nuevas características no será inmediato. La depuración de todo el proyecto urge más, así que en unas semanas iremos ajustando cada parte de WoD, observando la coherencia lógica, la jugabilidad, el diseño…

¡Te esperamos!

Artículos recientes relacionados:

Ajustando el sistema de patrocinadores

Eduardo Millán — Thu, 22 Jan 2009 15:02:21 +0000

Estas últimas semanas hemos realizado importantes avances, tanto en temas de funcionalidad e interfaz, como en temas de intelegencia artificial y procesos automáticos. Una de las características que tocaba redefinir concretando su funcionamiento era el sistema de patrocinadores. A nivel de estructura interna, no ha habido cambios drásticos, pero sí hemos añadido detalles para ajustar aún más el sentido de los mismos.

WoDBot y usuarios reales. De forma inicial, todo el control / administración de los patrocinadores iba a ser llevado por nuestro bot. Eso era muy cómodo para contratar las campañas de publicidad de forma manual bajo precio fijo, impresiones…. pero la ficha de cada patrocinador se quedaría algo coja (o nos llevaría mucho trabajo cambiar manualmente los datos de cada patrocinador, cuando éste lo desee). Así, optamos por dar la posibilidad a los usuarios de que pudiesen crear (y editar) sus propios patrocinadores. (El proceso de creación / edición lleva un alto cargo en wodies (la moneda del juego) para entre otras cosas, evitar el spam masivo.
Derivado del punto anterior, teníamos el problema de que los datos de cada juego (CS, DoD y T34) son accesibles sólo cuando el usuario está manejando su clan asociado. De tal forma, un usuario que tuviera un patrocinador creado, no podría ver las fichas en las que sale su patrocinador, si no maneja un clan para cada juego. La solución estuvo es dejar mostrar los datos (pero negando la interactividad con ellos), pasándolo al menu general de la aplicación.
Tras esto, ampliamos la posibilidad de que un patrocinador sólo ejerciese en un juego, en lugar de en los 3 como hasta ahora. Ser un patrocinador activo en un juego, será más barato para el usuario que estar activo en los 3.

En cuanto a la parte no visual, también estamos haciendo ajustes, para controlar por ejemplo, qué pasa cuando un patrocinador no tiene créditos suficientes para dar a los clanes que patrocina. Un patrocinador paga una serie de créditos, de forma mensual, a cada clan que patrocina. Esta cantidad se resta de la cuenta del usuario que administra el patrocinador. Pero puede que el usuario no tenga crédito… y en este sentido…

Varios días antes del pago a cada clan (se realiza cada 30 días naturales desde la fecha del acuerdo de patrocinio entre clan y patrocinador), se comprueba la solvencia del usuario, reservan los créditos que hacen falta para pagar a todos los clanes que patrocina una entidad. Si no hay dinero suficiente… saltan las alarmas….
En el momento del pago… si no hay créditos en la reserva, se tira directamente de la cuenta de usuario. Si tampoco es suficiente, dependiendo de la cantidad debida… se rescinde el contrato al instante (WoDBot se encarga de los trámites) o se avisa a ambas partes de lo sucedido, dejando en manos del clan la decisión de abandonar o no el patrocinio.

Además se realizan otra serie de comprobaciones y cálculos, a fin de tener todo los procesos controlados relacionados con los patrocinadores, una entidad más del juego en el que basamos el modelo de negocio de WoD.

Por otro lado, se mantiene que el bot pueda manejar patrocinadores, estando reservado a empresas o anunciantes de mayor nivel o que deseen integrarse en el sistema sin llevar un control exhaustivo de lo que pasa en el juego.

Artículos recientes relacionados:

El sistema multi – idioma de Earwyn / WoD

Eduardo Millán — Wed, 17 Dec 2008 11:18:15 +0000

En la mayoría de aplicaciones, incluidas las basadas en entorno web, los detalles pueden complicar mucho el desarrollo / implementación de un proyecto. Cuanto más refinados están, más dificultades o trabas van apareciendo. E incluso algunas de ellas, se tornan insalvables. El sistema multi – idioma de Earwyn, que da soporte a Win or Defeat, es capaz de manejar un número ilimitado de idiomas conviviendo en el mismo servidor (o en diferentes, si se necesita), haciendo uso de base de datos, ficheros php, ficheros de texto…, pero para llegar a la versión actual, hubo que resolver varios problemas y optar por algunas soluciones a ellos.

La parte más básica del sistema que permite el multi – idioma no supuso mucha complicación. El sistema de plantillas reconoce tags asociados a literales, definidos en ficheros .php, donde a través de variables se declaran la traducción para ese idioma. Es decir…

Existe un fichero .php por cada idioma, llamado con el esquema cod.php, donde cod es el código de idioma. Earwyn sabe qué fichero cargar según el idioma marcado por el usuario, haciendo un include de él.

$GLOBALS["TXT_MY_TEXT"]=”Este es mi texto, definido en sp.php”;

En la plantilla .html escribimos algo como:

….¡txt_my_text!…

Y cuando la plantilla se carga, el framework sustituye el tag marcado entre exclamaciones por su texto equivalente, definido en el fichero de idioma incluido.

….Este es mi texto, definido en sp.php…

Todos los literales presentes en las plantillas, se traducen con este procedimiento. Pero un juego de idiomas también afecta a otros elementos, como literales más largos, mensajes y avisos del sistema, campos de la base de datos…. En muchas páginas, es corriente ver un formulario, en español, menos las opciones de un select, por ejemplo de países. Ese listado se genera a partir de leer una tabla, en la que se escribe el valor del campo en un idioma. Y no queda del todo bien leer todo en español menos ciertas partes. Para evitar este problema nuestra opción fue implementar un sistema de ficheros de texto asociado a los campos identificadores (id, campo clave), que tradujese en consecuencia. Es decir…

La tabla de países tiene un campo id, un número entero, único para cada registro.
Existe una carpeta, que a su vez contiene subcarpetas, donde según la naturaleza del dato se guardan los ficheros de texto asociados. En el caso de países, la carpeta es countries.
En esa carpeta existen tantos ficheros como países haya en la base de datos, nombrados como id.txt, donde id es el valor del campo id en la tabla. (1.txt, 2.txt, 3.txt…)
A través de Earwyn, cuando leemos la tabla y, por tanto, el id, leemos el fichero asociado, sacando el valor traducido para ese campo.

Para la traducción de entidades de la base de datos, usamos este método, siendo aplicable también a otros elementos. Cuando necesitamos un nuevo tipo de mensaje o entidad a traducir, creamos la carpeta con los ficheros de texto y usando las funciones del framework somos capaces de tener cualquier contenido en multi – idioma. Sin embargo, para el informe del resultado de un partido, estamos refinando más aún el proceso, al tratarse de algo especial, que contaremos más adelante.

En cuanto al proceso de inclusión de un nuevo idioma, es muy cómodo; basta traducir esos ficheros e indicarlo en la configuración del sitio.

Artículos recientes relacionados:

El simulador de partidos de WoD

Eduardo Millán — Fri, 12 Dec 2008 08:52:15 +0000

Estos días venimos avanzando a buen ritmo, metiéndonos hoy a refinar el simulador de partidos y todos los procesos relacionados con él, siendo uno de los núcleos del juego e implicando muchos cálculos y complejidad técnica, pues debemos tener en mente gran variedad de aspectos y puntos variables. Y al final del partido, también debemos ser conscientes de las repercusiones en entidades como jugadores, clanes y usuarios.

Fijación de un partido. En el primer prototipo, la fecha era elegida de mutuo acuerdo por los participantes, dentro de unas horas y días preestablecidos. Con el fin de evitar colapsos en el sistema, optamos por que fuera el sistema quién fijara la fecha del partido, repartiendo horarios en función de la carga del servidor. (Es decir, el script se encarga de velar porque no se jueguen muchos partidos a la misma hora, distribuyéndolos en fechas diferentes). Otra dificultad referente a esto es la frecuencia con la que el cron job es lanzado. De forma básica, cada cierto tiempo en función de esos horarios, el cron se lanza, comprobando los partidos que hay pendientes por jugar, de los que hace la simulación. Puesto que según el juego al que pertenezca el partido a disputar (Counter, Day of Defeat ó Team Fortress) las reglas, puntuaciones, clases de jugadores… son diferentes, disponemos de un simulador específico para cada uno. Sin embargo, estos días estamos reestructurando la base, migrando la funcionalidad común a una librería que sirva de fundamento para los tres simuladores, implementando las características extra aparte.

El simulador. Las primeras versiones del simulador apenas controlaban el nivel del equipo y las habilidades de los jugadores en un modo generalizado, haciendo una estimación numérica sencilla. En la actualidad y, todavía con algunos detalles que implementar, el simulador ya puede llamarse tal, dependiendo de:

Mapa. Win or Defeat recrea los mapas de los juegos a través de un mapa 2D, implementado en una matriz, como si se tratara de un ajedrez. En ese mapa, se mueven los jugadores de un lado a otro e interactúan entre ellos (disparando, huyendo, matando, capturando banderas / cumpliendo objetivos, volviendo a la vida con el respawn…). Cada mapa tiene características diferentes: dimensiones, muros, paredes, dificultad…
Habilidades. Los jugadores tienen ciertas habilidades (puntería, juego en equipo, moral…) y juegan mejor o peor en función de ellas. Durante toda la partida, estas habilidades van sufriendo cambios, según se desarrolle el encuentro y sus acciones. (Por ejemplo, si un mismo jugadores es matado varias veces seguidas sin llevarse a nadie por delante, su moral bajará… del mismo modo que si dispara muchas veces acertando a la primera, su puntería sufrirá un pequeño aumento…)
Armas. El simulador tiene un control de las armas de cada juego. No sólo controla quién a matado a quién y dónde, sino también con qué arma. Por si fuera poco, el daño a los jugadores es sensible al arma. (Un rifle hace más daño que una pistola). Y, para el futuro, tenemos en mente tenerlo en cuenta a nivel de puntuación, sumando más puntos según que armas (puntuando más si se mata a cuchillo que con un rifle de francotirador).
Niveles. El nivel del equipo, la media general de las habilidades de los jugadores…. se sigue teniendo en cuenta, aunque con menos peso.

Como en otros artículos hemos comentado, la IA es de los puntos fuertes del juego, y de los más complejos. Y lo que queda…

Repercusiones. Al finalizar un partido, la mejor puntuación dice el clan ganador. Con la nueva dimensión social del juego, el sistema da más importancia cuando se ha ganado a un clan enemigo (y todavía más si se trata de un partido oficial y no de un amistoso). Además, se actualizan los puntos y créditos de clanes y usuarios, las estadísticas, los informes… Toda la simulación del partido es guardada en un fichero de texto, que se puede consultar desde la ficha de partido, observando toda la funcionalidad comentada. Una mejora (ya estamos en ello) es hacer compatible el informe con el sistema de plantillas, dotándolo de mayor potencia visual, acorde con el resto de la página.

pd.- seguimos necesitando socios… ¡únete!

Artículos recientes relacionados:

El análisis técnico de WoD

Eduardo Millán — Thu, 23 Oct 2008 10:44:36 +0000

Comentado el aspecto lógico del juego en artículos anteriores de este post – mortem, toca revisar la parte técnica de Win or Defeat. Tecnologías, bases de datos, fundamentos técnicos… La base siempre ha sido la misma, pero según fue evolucionando la lógica, fue necesario optar por implementaciones más potentes. Así…

En la primera etapa del proyecto, todo el código fue desarrollado desde cero, con PHP, sin utilizar ningún tipo de framework o entorno. Puesto que urgía tenerlo cuanto antes, nos dividimos el trabajo en dos partes, haciendo reportes diarios de todo aquello que ibamos modificando. Al dar por finalizada esa parte, la estructura de la aplicación no era la adecuada, al menos para afrontar un proyecto de las dimensiones que tiene ahora. Al retomarlo y darle ese nuevo enfoque, nos dimos cuenta que habría que rehacer muchas cosas, desde el código de la parte front end, hasta las relaciones y tablas de la base de datos. ¿Cómo reestructurar entonces?

En este punto, comenzamos a analizar el futuro. Es decir, no se trataba simplemente de hacer algo funcional bien organizado, sino que esa organización, tanto de código como de datos, fuese muy flexible, reduciendo los costes de mantenimiento posterior lo más posible. Y, además, que las funcionalidades pudiesen ampliarse sin resultar una experiencia traumática. El resultado de la deliberación y, con vistas a que fuera un software corporativo, nació Earwyn. Ya no teníamos una prisa especial para terminar el juego, así que decidimos sacrificar varios meses (que se convirtieron en bastantes) ganando un mayor control sobre la aplicación… y la verdad es que a nivel de productividad, se nota mucho que un framework te de tantas facilidades: código más limpio, más ordenado, control de errores, logs… fue un trabajo impresionante, pero ha merecido la pena.

De php4 pasamos a php5 (entre otras cosas, por que Earwyn se diseñó para la versión 5 del lenguaje); de unas 20 tablas mySQL hemos pasado a 46 (y aumentando); de html usando tablas y embebido en los ficheros .php hemos evolucionado a diseño y datos separados, con plantillas xhtml / css2 sin código php; y nos hemos metido con AJAX.

Back end. La parte de los cron, jobs… también corre bajo PHP, aunque en determinados procesos hemos experimentado con algo de PERL y Python.

¿Por qué PHP? Tanto Thani como yo, teníamos una base sólida en esta tecnología… así que, simplemente, por el hecho de sentirnos más cómodos desarrollando. En cuanto al uso de mySQL, porque suele ser un complemento muy habitual de PHP (muy fácil de encontrar en las características de cualquier servidor) y es eficiente para el volumen de datos que pretendemos manejar. Si en unos años la cosa adquiere mucha más carga de datos… puesto que las operaciones se hacen a través de Earwyn, cambiando esa parte del framework, no tendríamos que tocar muchas cosas para que fuera compatible, por ejemplo, con Postgre. Sobre hacer uso de técnicas AJAX, vimos que era necesario actualizarse a las nuevas tendencias, además de dotar de espectacularidad, mejorando la experiencia de usuario en ciertas operaciones. Earwyn trae un motor de AJAX, pero también hemos utilizado librerías como jQuery o Prototype.

¿Flash? Tenemos en mente, para desarrollar más adelante, hacer un simulador virtual en flash de los partidos. De tal forma que además del resultado en texto (ambientado con CSS2) haya una animación que lo escenifique. Pero a falta de creativo web…

Servidor. Desde hace varios meses, el juego se aloja en un servidor compartido, alquilado a una compañía americana. Imaginamos que después de la beta abierta… habrá que plantearse migrar a un servidor dedicado, debido a que el volumen de datos (y la carga que conlleve al equipo) ya puede ser más que importante.

Y con esto y muchas horas…

Artículos recientes relacionados:

La dimensión social de WoD

Eduardo Millán — Mon, 20 Oct 2008 08:35:38 +0000

En los post anteriores (lógica del juego y su continuación) relacionados con la lógica de Win or Defeat, dejamos pendiente hablar sobre la dimensión social del juego, una dimensión que no se planteó en un principio, pero que ahora es parte esencial del proyecto. Así…

Cuando comenzamos a diseñar la lógica del juego, no se nos pasó por la cabeza añadir posibilidades sociales al sistema, aunque sí veíamos que el proyecto debía tener un aspecto que lo diferenciara de otros juegos web, algún detalle que hiciera WoD único (o, al menos, que enganchara por tiempo indefinido). Como usuario de juegos web, como ogame o ikariam, siempre he echado en falta algunos puntos que en WoD estamos tratando de evitar,

Tras el registro, te pones manos a la obra y creas los primeros edificios, vas aumentándolos de nivel, generas tropas, infraestructuras, atacas, te atacan…. pero llega un punto en que tu única opción se reduce a dedicar tiempo, tiempo y más tiempo (conectado, aunque no hagas mucho). Y si tienes algún despiste, todo aquello creado habrá sido destruido… quitándote las ganas de construir todo de nuevo… dejando el juego.
Cuando vas adquiriendo más nivel, subiendo en los rankings llega otro punto en el que te preguntas.. ¿y ahora qué? Soy demasiado grande para seguir progresando a buen ritmo.. y demasiado pequeño para enfrentarme en un guerra abierta…. en ese momento, sigues jugando, pero esperando a ver que vá pasando… y con un punto de desánimo… el vicio ha perdido tirón…
Si quieres dejarlo por un tiempo, puedes congelar la cuenta, pero no puedes tomarte vacaciones por tiempo indefinido.
Creas alianzas, pactos… pero más allá de los mensajes privados no puedes interactuar con otros usuarios.

Pensando en cómo solucionar estos puntos flojos que veníamos observando, se nos ocurrió la idea de embeber una red social, de tal forma que

El usuario se registra, pero no crea ningún equipo ni establece ningún paso que le obligue a jugar. Una vez dentro, puede crear sus clanes para competir en el juego, o utilizar sólo el ámbito social de la web. Del mismo modo, se puede dejar de competir… sin repercusiones en el sistema.
Los usuarios pueden definir amigos, enemigos… En función de esas relaciones, los efectos en el juego serán unos u otros. (Por ejemplo, los partidos ganados a enemigos puntúan más).
Sistema de microblogging: al margen de los mensajes privados, se puede compartir un mensaje con todos tus amigos, de tal forma que estos lo vean en su panel, desde su cuenta.
En el perfil se pueden indicar muchos datos, como parte de esa dimensión social. También se puede enlazar a tus perfiles en otras redes a través de un sistema de iconos….
Los usuarios tienen la posibilidad de modificar su avatar, de subir fotos, de organizar eventos… de crear comunidad.

Conseguir que un usuario entre y esté enganchado un par de meses… no es demasiado difícil. Lo complicado es hacer que se encuentre tan agusto que no desee marcharse, que adopte la plataforma como una más en su vida digital. La idea de socializar el juego fue esa, dotar al proyecto de una característica que lo hiciese algo más que un juego, una comunidad en donde se juega online. El tiempo y los primeros testers dirán si lo vamos consiguiendo…

Artículos recientes relacionados:

Continuando con la lógica de WoD

Eduardo Millán — Tue, 14 Oct 2008 12:49:52 +0000

En la primera parte dedicada a analizar la lógica del juego, comentamos una serie de conceptos (y la variación sufrida) sobre el planteamiento del proyecto. En este artículo, a modo de segunda parte, seguiremos contando todos esos aspectos lógicos del diseño de Win or Defeat.

Jugadores. Otro punto de inflexión, dada su complejidad, fue el diseño de todos los detalles relacionados con los jugadores, entidades que un usuario maneja, los gamers que forman la plantilla de cada equipo. Algo que quedaba claro en la idea inicial es que estas entidades, como los patrocinadores, habían de regirse por sí mismas, desarrollando una inteligencia artificial que se encargara de ello. Realizamos un conjunto de scripts, que controlaban las acciones, las decisiones y el estado de cada jugador:

Un gamer puede desear causar baja en el equipo, así como ofrecerse para ingesar en las filas de otro clan.
También decide ante las ofertas que cualquier equipo le haga.
Con la progresión del equipo y en base a otros valores, aumentará sus habilidades.. o puede que su moral baje si no está satisfecho con su rendimiento…

Programar tantas reglas, de modo que la reacción no sea previsible (en su totalidad), imitando un poco el comportamiento humano (dentro de las limitaciones evidentes) ha sido (y sigue siendo) una de las tareas más díficiles de llevar a cabo. De hecho, la dificultad radica en eso, en tener en cuenta muchos atenuantes para cada toma de decisión, añadiendo un componente que no sea mero cálculo, para que con situaciones muy similares, no siempre pase lo mismo. Al depender de muchos valores, cada opción tomada por el jugador la hace diferente a la de otro jugador, resultando un efecto más interactivo en el mundo virtual de WoD. En el desarrollo de esos algoritmos hemos invertido gran parte del tiempo…

Por otro lado, teníamos que solucionar un problema con la generación de estas entidades. Es decir, ¿quién metería los nuevos gamers? Desde un panel de administración podríamos meterlos a mano, pero llegamos a la conclusión (ya no sólo para esto) de que debíamos automatizar el 99.99% de los procesos para no volvernos locos con el mantenimiento de la base de datos. Se nos ocurrió programar un cron job, que todas las noches comprueba el número de jugadores que no tienen clan y, en caso de que haya pocos jugadores clanless, genera una tanda de ellos. El script genera nombres, de forma aleatorea, basándose en unas normas para evitar nicks impronunciables. Más tarde y todavía en implementación, nos vino la idea de realizar un creador de jugadores, de tal manera que los usuarios podrían generar sus propios jugadores, editando sus habilidades, su nick, su avatar o imagen….

El sistema de jugadores es un componente esencial del juego, así como los equipos en los que se integran. Pero los equipos no sirven de mucho si no tienen la posibilidad de competir. Y he aquí otro punto problemático, las competiciones. Tanto es así que seguimos dando retoques a este apartado, estando ya finalizado los partidos amistosos, pero no así la gestión automática de ligas. Cada liga tiene sus propias divisiones, y a su vez diferentes temporadas. Al término de una temporada, se ha de generar la siguiente, subiendo y bajando clanes de categoría. Además, hay que tener en cuenta el número de clanes en el juego, y en función de ello generar más competiciones, para no colapsarlas con muchos equipos ni que éstos se queden sin posibilidad de competir. Pero no sólo de ligas viven los trofeos, así que también se controlan torneos eliminatorios, copas… Total, mucho trabajo en el desarrollo del sistema que realiza los procesos relacionados con el control y organización de competiciones.

En cuanto al simulador de partidos, también ha sido un parte que ha sufrido muchos cambios y versiones. En la actual, el algoritmo está muy depurado, teniendo detalles como el arma con el que un jugador ha matado a otro. En nuestra mente está hacer sensible el algoritmo a cada mapa, hacer una versión flash del simulador (ahora el resultado se genera como texto) y depurar aún más su funcionamiento y eficiencia.

Otros aspectos interesantes son los relacionados con la socialización del juego, que dará para otro post… pues también está llevando un trabajo interesante….

Artículos recientes relacionados:

WoD: planteamiento lógico

Eduardo Millán — Wed, 08 Oct 2008 09:17:06 +0000

En este nuevo artículo perteneciente al post-motem del Win or Defeat, hablaremos del planteamiento lógico (cómo surgió la idea, aquello que deseamos hacer, sus cambios de concepto…) del juego, a lo largo de todo este tiempo. Hará varios días, publicamos una primera parte, titulada Idea y Evolución.

Una vez tuvimos decidido el tipo de proyecto (juego web), faltaba por decidir el tema o la ambientación de éste, para ir desarrollando las ideas en torno al reglamento de juego, la mecánica, la jugabilidad… Recuerdo que estuvimos alguna semana valorando temáticas, haciendo propuestas y votando por ellas. Y el óscar fue para… el mundillo gamer, un mundo que conocíamos (y que Thani todavía conoce bien, organizando ligas de TF2 y trabajando en eventos como la WCG) muy de cerca, formando parte activa de la comunidad y sintiendo una fuerte motivación por los shooters online cooperativos, en cuya gestión se basa WoD.

A nivel técnico, el hecho de recrear toda esa realidad suponía (y supone) un verdadero reto. Normalmente, el modelo de datos de un juego web no es muy complejo, y la dificultad de su inteligencia artificial radica en el simulador de batallas. En WoD, no sólo contamos con ese problema (simulador de partidos), sino que además había que pensar en todo el entramado de jugadores, patrocinadores, ligas… entes que el juego controla de forma automática, sin necesidad de que una mano humana esté pendiente.

Dejando la parte técnica (en próximos artículos hablaremos sobre ello) y volviendo a la lógica de juego, una de las cosas a definir era el juego real en el que basarnos para crear el mundo virtual. El Counter Strike, quizás el más famoso, era una apuesta segura que atraería a muchos gamers. Pero basarlo en un sólo juego, nos parecía algo pobre. Por afinidad con nuestros gustos, incluimos también el Day of Defeat y el Team Fortress Classic. De los tres, el último fue el que nos dio más problemas, debido a su estructura más compleja de juego. Mod Manager, el nombre anterior del proyecto, viene de ahí, de la intención de hacer un manager para mods del Half Life. Pero con la evolución del juego, convertido a 2.0, metidos en conceptos de redes sociales y mayor interacción con otros usuarios… decidimos desligarnos un poco de la base real. Sustituimos los nombres reales de los juegos por abreviaturas (para evitar conflictos de copyright, entre otras cosas) y dimos un pequeño vuelco al fundamento del juego. Ya no se trataría de administrar un clan de Counter o Team Fortress, sino de tener el control absoluto de equipos de e-sports. Aún así, y para no perder el sentido original, seguimos basándonos en el mundo real para emular ciertos aspectos, como por ejemplo los mapas o las clases manejadas por los gamers.

Otra entidad a la que cambiamos el diseño inicial fue los patrocinadores. En un principio, serían controlados en su totalidad por la IA, siendo éstos sponsors del panorama gamer. Esto suponía el problema de los derechos, no resultando factible que hibiese en el sistema, por ejemplo, un NGGN, sin contar con su permiso. Una opción que se nos pasó por la cabeza, era contactar con todos ellos y proponerles el asunto. Esa ahora es una vía, pero creíamos que no debía ser la única, pues no sería tarea fácil (hasta que el juego consiguiese cierta fama) llegar a acuerdos. Por ello pensamos en abrir el sistema, adquiriendo un sentido de publicidad. Los patrocinadores aparecerían en las fichas de clan, en los partidos… de un modo totalmente integrado, formando parte activa del juego, resultando así mucho más atractivo para las empresas y posibles anunciantes. Además, los usuarios podrían crear patrocinadores desde su cuenta, teniendo el control de su imagen, textos, enlaces… con un seguimiento de estadísticas de impresiones, partidos patrocinados…

El sistema de puntos y de créditos también fue cambiado. Por las nuevas dimensiones, hubo que ajustar los parámetros, los puntos que da el sistema, la valoración de los gamers…. creando el concepto de wodies. Los wodies son el dinero en el mundo virtual de WoD. Con ellos se puede comprar jugadores, invertir en entrenamientos, en servidores…. En el concepto inicial, esos créditos servían para ello. Poco a poco, decidimos aplicarlo a todos los elementos del juego, creando esa moneda oficial que sirviera para todo. Más tarde, pensando en el modelo de negocio, se nos ocurrió que hubiese una equivalencia entre wodies y dinero real, y que el usuario pudiese transferir fondos a su cuenta para realizar cierto tipo de operaciones “premium“. Si bien la idea de las cuentas premium siempre estuvo ahí, adquirió un nuevo planteamiento, con ese engranaje con el sistema de wodies.

Continuará…

Artículos recientes relacionados:

WoD: idea y evolución

Eduardo Millán — Tue, 30 Sep 2008 08:43:20 +0000

Anunciada ya la serie de artículos post-mortem del proyecto Win or Defeat, comenzaremos a meternos en materia analizando los inicios del proyecto, recorriendo su evolución hasta el estado actual de la aplicación.

La idea inicial. Tras nuestro nacimiento como grupo amateur, nos planteamos realizar un proyecto que sirviera como fuente de ingresos, para sufragar los gastos del servidor, asistencia a eventos y conceptos logísticos relacionados. Debatiendo sobre las posibilidades, sugiriendo proyectos, recopilando ideas… nos vino a la mente realizar un juego sencillo, basado en web, con el fin de insertar algo de publicidad y generar algunos fondos. Con la llegada de Agosto del 2006, decidimos ponernos las pilas… y en poco más de un mes, tuvimos lista una primera versión, llamada Mod Manager, que presentamos al Art Futura. MM estaba algo verde, pero era funcional. Por esas fechas, publicamos un conjunto de capturas.

La evolución. El desarrollo fue muy rápido. Tenía que funcionar para una fecha y no podíamos retrasarnos. Así que olvidamos muchos detalles técnicos, en relación a estándares, usabilidad…. Después de eso, avanzamos muy lentos, hasta aparcarlo. Pero tras retomarlo con fuerza en Febrero de este año, decidimos dar un giro radical al proyecto. Así,

Earwyn: desarrollamos un framework que fuera capaz de hacernos más fácil la vida. Dividimos el código del diseño, automatizamos procesos, limpiamos el código… toda la parte front end fue renovada, cambiando cada línea de código y adaptándola al nuevo sistema. Esta vez, no pusimos empeño en tenerlo operativo, sino en que estuviese bien hecho, de cara a una administración y actualización saludable.
Web 2.0. Hoy en día, con el boom de las aplicaciones 2.0, los sistemas web anticuados tienden a desaparecer. Renovarse o morir. Desarrollamos un motor de AJAX, complementario a jQuery y Prototype, y estudiamos las nuevas formas de presentar la información, de interacción con el usuario, creatividad en los interfaces…
Dimensión social. Una de las funcionalidades que, como jugadores, echamos en falta en los juegos web, es la dimensión social. Es decir, compatir fotos, administrar perfiles, crear eventos, definir relaciones con otros usuarios… Todo esto hace a la aplicación muy atractiva, pero también supone mucho desarrollo extra, que se ha ido (y está) notando en el espacio – tiempo…
Nombre. Para que el lavado de cara fuese completo, creamos un nuevo nombre. Win or Defeat, fue el resultado de muchas lluvias de ideas, adquiriendo el sentido que le hemos querido dar al juego: no hay opción a derrota, gana o vence, pero nunca pierdas.

Todas estas decisiones han supuesto muchos cambios en el código, en la manera de afrontar el proyecto, en el diseño de la aplicación… pero valoramos la situación y nos pareció que era un proceso necesario, vital para el éxito del juego. WoD pasó de ser un proyectillo eventual a convertirse en nuestra principal baza, en algo que hemos ido planificando (ejemplo de aquello que no se debe hacer) sobre la marcha. Ahora, está bien definido…

El estado. Aunque seguimos avanzando de forma progresiva (sin rapidez pero sin pausa), en breve daremos pasos más grandes, debido a que apostaremos por el proyecto y nos dedicaremos un par de meses en modo prácticamente exclusivo. Cada día nos surgen muchas ideas, que vamos anotando, para irlas desarrollando una vez estemos en marcha.

pd.- seguimos buscando creativo web… ¡únete a nosotros!

Artículos recientes relacionados:

La locura del WoD

Eduardo Millán — Mon, 29 Sep 2008 11:40:52 +0000

Con la apertura de la beta privada ya inminente (en su fase 1, es decir, el primer testeo por parte de colaboradores de Undead) iniciamos una serie de artículos a modo de post-mortem, donde contaremos nuestra experiencia y quebraderos de cabeza con el proyecto.

Cuando alguien cercano al grupo nos pregunta por el juego, nosotros contestamos con un típico “estamos en ello“, que suele llevar una reacción de “parece la obra de El Escorial“. El desarrollo de Win or Defeat, ha estado plagado de parones, giros, nuevas implementaciones, cambios… pero desde hace un tiempo, lleva un rumbo bien definido, alcanzando cada vez mayores proporciones y ambiciones. Para no seguir alargando, iremos abriendo con lo básico (realmente básico), agregando funcionalidad de forma progresiva, comprobando que todo va engranándose sin problemas.

Y, es que, la complejidad interna de WoD es más que importante. Por un lado, heredamos todos los puntos de un juego (diseño de una buena jugabilidad, adicción…); por otro, tenemos los problemas de un sistema web (estándares, diseño web, usabilidad, seguridad…) y, por último, tenemos las complicaciones de una red social (ficheros, perfiles, relaciones, datos personales…). Combinar estos tres ámbitos está siendo una tarea difícil, de ahí la marcha tan lenta en los progresos. Además, varios puntos innovadores en el mundo de los juegos web nos están retrasando un poco, en concreto, la inteligencia artificial de todas las entidades (jugadores, sponsors, simulador de partidos…). Lograr una interactividad real en el sistema vivo de WoD está costando muchas horas de sueño, teniendo la desventaja de que no es enseñable, de que no se nota su presencia hasta que no acumulas ciertas horas jugando. Así, la IA es uno de los puntos más fuertes, que se merecerá un artículo dedicado.

En cuanto a la parte comercial, también vamos progresando. Tenemos ya un plan de negocio estructurado, un resumen ejecutivo del proyecto (presentado a la mesa de proyectos organizada por el EBE) y estamos elaborando un plan de empresa. La idea es que el proyecto sirva como una buena fuente de financiación para sufragar todos los gastos de la posible start up. Desde las últimas semanas, venimos buscando apoyos, inversores, partners, un creativo web (para unirse al equipo) y en general cualquier tipo de ayuda. Si estás interesado… ¡escribe!

Artículos recientes relacionados: