Hace unos seis o siete meses conocí a Daniel Rodríguez por medio de Twitter gracias a un Follow Friday. De inmediato hicimos clic y tuvimos la oportunidad de charlar en persona en Diciembre del año pasado. Daniel hizo una visita relámpago a la Ciudad de México y aprovechamos para comer y tomar unas cervezas mientras discutíamos del estado de desarrollo de juegos en nuestro país.

Ambos coincidimos que sería bueno arrancar un proyecto a corto plazo, un juego casual desarrollado con un motor gráfico existente. Daniel propuso Unity ya que tenía experiencia trabajando con él en Kaxan Publishing a lo que acepté de inmediato. Durante las primeras semanas de Enero nos metimos de lleno a la pre-producción y por medio de llamadas en Skype y charlas en GTalk llegamos a la conclusión de que trabajaríamos en un juego de acción (shoot’em up) con un control y mecánica simples. A estas sesiones se integró otro miembro del equipo llamado Dorian Mastin, el cual sería encargado de diseñar todos los sonidos del juego.

Durante los siguientes meses establecimos una rutina de trabajo basada en desarrollo ágil de software, con juntas cada lunes vía Skype y el uso de Pivotal Tracker y SVN para llevar el registro de todo el proyecto. Todo este tiempo sufrimos de varios contratiempos, algunas veces ocasionados por nuestro trabajo o por la partida de miembros del equipo de desarrollo, curiosamente Daniel, Dorian y yo jamás dejamos de realizar juntas, algunas veces no teníamos trabajo que mostrar sin embargo charlamos de posibles implementaciones, de planes personales y demás cosas.

Después de un mes de suspenso decidimos enfocarnos de lleno para tener lista nuestra primera beta. Dorian aprovechó para tomar parte en el diseño de juego y sugerir varias implementaciones, Daniel le metió turbo trabajando en las madrugadas y yo encontré el tiempo necesario para combinarlo con mi trabajo. Dos semanas de rush concluyeron el sábado pasado con nuestro primer cliente liberado en www.Deathmosphere.com

Durante estos dos días he realizado un balance de pros y contras del proceso de trabajar vía remota. En conclusión, para que un proyecto funcione es necesario mantener una comunicación constante vía mail y VoIP. Lo primero sirve para tocar propuestas sencillas, correcciones o enviar algunos archivos, mientras que lo segundo es esencial para discutir del proyecto con mayor detalle.

Trabajando todos en el mismo lugar (físico) y al mismo tiempo se traduce en un proceso de desarrollo más transparente. Es más fácil corregir errores, implementar opciones y obtener resultados en menor tiempo, cosa que se dificulta trabajando a distancia. En nuestro caso, Daniel y yo tuvimos que establecer días y horarios adecuados para trabajar con el archivo de Unity.

A final de cuentas violamos el deadline inicial, de hecho nos pasamos por bastantes semanas, pero todo este tiempo nos sirvió para darnos cuenta de cómo se llevará el proyecto en los meses siguientes. Todavía queda mucho por hacer, hay que esperar el feedback de los que jueguen nuestra beta y evaluar los cambios que haremos.

Links:

• Deathmosphere
• Silent Kraken

Después de una semana infernal haciendo ajustes a la parte gráfica y algunas cosas de programación por fin tenemos la primer beta de Deathmosphere. Esta versión cuenta con tres misiones, un boss y un escenario donde podrás moverte en todas direcciones. Deathmosphere se está desarrollando con la versión indie de Unity 3D y pueden jugarlo en su navegador, solo necesitan descargar el plugin de Unity (que se hace en automático) y listo.

El juego funciona las versiones más recientes de Chrome, Firefox, Safari y Opera en PC y Mac. Estoy implementando un botón de feedback y haciendo ajustes todavía a la página web para mejorar el diseño.

El juego es una beta y el propósito es que ustedes lo jueguen y nos den sus comentarios para poder mejorarlo. Pueden dejar sus comentarios en este link o a mi correo lmiranda [@] doruku.com

Si usted pensó que estaba en la cárcel, me había ido de mojado a los esteits o que estaba sumido en la depresión por culpa de un desamor, temo informarle que no. Desde Enero he estado desarrollando un juego con dos amigos de Guadalajara. Deathmosphere es un shooter casual en 3D donde tomas el papel de un piloto que tiene que cumplir múltiples misiones para acabar con los enemigos que acechan tu territorio.

El juego se está desarrollando en Unity 3D y está pensado para aparecer en web y Facebook. A pesar del tiempo que ha tomado desarrollarlo debido a las múltiples obligaciones que tiene cada integrante del equipo, no hemos perdido la fé en el proyecto y en esta etapa estamos pegándole más duro que nunca para terminarlo.

Como dato extra, el proyecto se ha trabajado a distancia en su totalidad, con mucha comunicación vía Skype, mail y messenger. Deathmosphere estará listo el siguiente mes y se podrá jugar gratuitamente.

Más detalles en los próximos días.

El domingo me encontré con este concurso de cajas para UnityPrefabs y decidí entrar aprovechando que estaba trabajando con 3DS Max. La idea era modelar tres cajas en 3D para usarlas como representación visual de los productos que se descargarán en la página. Las restricciones eran 350 polígonos (max) y se debía incluir el archivo fuente de textura en PSD.

Me tomé algunas horas para modelar y texturizar todo. Hubiera querido dedicarle más tiempo pero lo importante es que lo terminé y envié antes de la fecha límite. Con esto aprendí que debo perfeccionar mis tiempos y técnica para modelar en 3D, así como un mayor cuidado a la hora de texturizar. Afortunádamente estoy trabajando en algunos prefabs para un escenario (edificios, caminos, etc) por lo que podré seguir practicando.

Si quieren votar por ellas pueden hacerlo en los foros de The Unity Artist.

Uno de los pasos en la etapa de preproducción de un nivel es buscar material de referencia. En Internet hay cientos de páginas, tan solo Flickr o Google pueden sacarte del apuro, sin embargo hay veces que la necesidad es muy específica. En mi caso requiero de arquitectura mexicana del siglo XIX (para Call of Juarez BiB) y me he topado con algo en el librero de la casa.

Tierra, Piedra y Sol es un libro que editó uno de mis tíos hace un par de años, recuerdo que fui a la presentación pero borré de mi memoria que le había regalado una copia a mi mamá. Este libro cuenta con fotografías de varios poblados de Jalisco, en resumen me saqué la lotería.

Hay veces que Internet es la solución inmediata, pero el librero familiar siempre tendrá algo que nos sorprenderá.

Posted via email from .plan

¿Qué fue lo mejor del 2009? A continuación la lista:

5. Steam

Las tiendas de juegos son una burla: traen los títulos tarde, te venden al precio que se les da la gana y tienen un pésimo servicio al cliente. La distribución digital es algo que está pasando y que por más que lloren los retailers, tarde o temprano será estandar en todas las plataformas. Este año di mi voto de confianza a Steam por muchas razones: No tiene candados regionales como otros sistemas, ofertas todo el año y una comunidad bastante nutrida.

Tal vez Gamerush o Gameplanet ofrecerán este sistema de distribución en un futuro, pero será muy tarde y seguramente vendrá acompañado de bugs.

4. ChromED

Probé bastantes editores de niveles este año, de hecho un vicio que tengo es comprar juegos solo para jugar con el editor un rato. Uno de los que me impresionó fue ChromED, el editor de Call of Juarez: Bound in Blood. Esta herramienta es facil de usar pero requiere de tiempo para explotarla a fondo, lo mejor es que puedes levantar un escenario en menos de una hora y probarlo en el juego.

Las herramientas dependen del soporte que les de la comunidad y los desarrolladores, en el caso de ChromED hay una serie de tutoriales en video bastante buenos. El soporte en los foros de CoJmodding o CojFans es notable, de hecho es de los pocos casos en que la gente del estudio (Techland) se ofrece para probar tu mapa y decirte en donde está el bug.

Kudos para el LD Mateusz “Seir” Piaskiewicz, siempre está pendiente de todos los posts.

3. World of Level Design

A principios de año me encontré con World of Level Design y de inmediato me enganchó. Alex Galuzin es el LD responsable de todo el contenido y tiene artículos indispensables para todo aquel que desee iniciarse en el diseño de niveles. Uno de los problemas de esta posición es que buscar “Level Design” en Google siempre arroja ligas a tutoriales de tal o cual software; los pocos libros de Amazon también se enfocan en la parte técnica.

Los artículos de Alex se tiran más al conocer flujo de trabajo de un diseñador, cómo planear un mapa o dónde buscar inspiración. También hay referencias en los foros, entrevistas con otros diseñadores y algunos tips de productividad para no perder meses con un solo mapa.

Por último, Alex trabajó hace poco con Techland en una serie de tutoriales para ChromED.

2. Unity3D

Unity3D se liberó y muchos indies saltaron de gusto (menos los que lo acababan de comprar). Es una plataforma sencilla y hay bastantes sitios con documentación para iniciarse en el desarrollo de juegos. A pesar que todos los medios le dieron más importancia a UDK, Unity3D es multiplataforma; Win, Mac o web e incluso portear a iPhone o Wii siempre y cuando pagues unos dólares extra por la licencia.

1. Twitter

Twitter es mi herramienta favorita del 2009; por ella conocí a muchas personas de la industria de las cuales he aprendido bastante. Es sorprendente la cantidad de cosas que puedes conseguir siguiendo a las personas adecuadas, en mi caso he optado por dejar atrás a aquellos que twittean a detalle su vida (”voy al baño”, “estoy comiendo doritos”, “me cortó mi novio”) no solo porque me vale, sino porque saturan tu timeline y te pierdes de información más interesante.

El 2010 arranca en unas horas, espero que les vaya tan bien como este año.

Willay Clément es un programador independiente con amplia experiencia usando Multimedia Fusion 2 para desarrollar juegos. Sky Invader es su última creación y utiliza el esquema del shooter en side-scrolling, sin embargo le agrega el componente táctico gracias a un menú de acciones, similar al que vemos en interfaces de juegos de consola. El objetivo de Sky Invader es pelear contra los humanos destruyendo tanques y helicópteros evitando que dañen tu nave.

¿Qué llama la atención de este proyecto? Varias cosas, la primera es el tratamiento visual que hace Clément utilizando poca luz para la nave, enemigos en silueta y fondos en HDR. Esto le da una buena sensación de profundidad y corriendo a 720p le da mayor impacto a la parte gráfica.

Otra cosa que me intriga es el menú de acciones, faltará ver como se desempeña en la versión final pero me atrevería a decir que el juego podría aparecer en consola con este esquema de control.

¿Como ven la nave? Le da un parecido a aquella de District 9 ¿no?

[Project: [MMF2] Sky Invader, vía Pixel Prospector]

Aprovechando que el tema de los JRPGs está caliente por el post anterior y por esta entrada en Niubie, me permito reproducir una serie de recomendaciones que hace Jordan Mechner para diseñar juegos basados en una historia. Este artículo ya es algo viejito, se publicó en la revista Next Generation en 1996, sin embargo Mechner lo puso disponible en su blog hace un mes:

1. La historia es lo que el jugador hace, no lo que mira.
   
   

2. Haz una lista de las acciones que realiza el jugador y analízalas fríamente. ¿Suenan divertidas?.
   
   

3. Las únicas acciones significativas son aquellas que afectan a la capacidad del jugador para llevar a cabo acciones futuras.
   
   

4. Diseña una interfaz clara y sencilla. La tarea principal de la interfaz es presentar al jugador una selección de acciones disponibles en cada momento, así como proporcionar información al instante cuando el jugador realiza una elección.
   
   

5. El jugador necesita un objetivo en todo momento, incluso si es errado. Si no hay nada específico que lograr, pronto se aburrirá, incluso si el juego es rico en gráficas y sonido.
   
   

6. Mientras más sienta el jugador que los eventos del juego son causados por sus acciones, mejor — aun cuando se trate de una ilusión.
   
   

7. Analiza los acontecimientos de la historia en términos de su efecto sobre los objetivos del jugador. Para cada evento, pregúntate: ¿Este movimiento acerca o aleja al jugador del objetivo? ¿Le ofrece uno nuevo? Si no, es irrelevante para el juego.
   
   

8. Cuanto más tiempo pase el jugador sin ser interrumpido, mayor será su sentido de la realidad del mundo que se construye. Cada vez que muere o tiene que reiniciar desde una partida guardada, se rompe el hechizo.
   
   

9. Rutas alternativas, errores recuperables, múltiples soluciones al mismo problema u oportunidades perdidas que se pueden hacer más adelante; todas son buenas.
   
   

10. No introduzcas obstáculos porque sí solo para crear un puzzle.
    
    

11. A medida que el jugador se mueve a través del juego, debe tener la sensación de que está pasando caminos potencialmente interesantes de la exploración. El resultado ideal para él es ganar el juego habiendo hecho el 95% de lo que hay que hacer, pero sintiendo que habría otro 50%, el cual se perdió.

El primer punto es vital y debería ser entendido tanto por los diseñadores como los jugadores de JRPG, si quiero una historia a base de cinemáticas mejor me voy a ver una película. El tercero va de la mano con el sexto y es una de las cosas que explota muy bien BioWare, permitiendo que el jugador sienta que sus acciones tienen consecuencia en la historia, de hecho han sido la punta de lanza para promocionar sus títulos durante esta década.

El octavo es escencial en la cuestión de balance, algo en lo que erró BioWare con Dragon Age Origins, al ofrecer batallas frustrantes en ciertas partes de juego. Este fenómeno también se da en los juegos que incluyen mucho texto al comienzo de la historia o pop ups que brincan de la nada y que no pueden deshabilitarse en las opciones de juego.

El mejor modo de introducir al jugador es por medio de acciones. Cliff Bleszinski dice que el primer minuto es vital en un juego así que es mejor introducir al jugador a la aventura para hacerlo sentir que es parte de algo, en lugar de aburrirlo con hermosas gráficas CG con nula interacción.

Estas recomendaciones también son muy buenas para aquellos que desean diseñar niveles en modo de un jugador. Llevar una historia interactiva a base de scripts es algo que volvió famosos a sagas como Half Life o Call of Duty.

[Link: Designing story-based games]

Si la gente lo pide, los japoneses seguirán haciendo juegos lineales con la misma fórmula de siempre. Lo saco a colación porque acabo de ver los primeros 10 minutos de Final Fantasy XIII, un título que no tiene la más mínima intención de innovar en su género. El juego tiene la misma calidad de intros sorprendentes en CG, el clic clic clic interminable de texto que interrumpe la jugabilidad y una diseño de personajes a base de clichés, idéntico a las 12 entregas anteriores.

En Japón parece no haber terreno para la innovación, los juegos son iguales que hace 10 o 12 años y lo increible es que los consumidores siguen defendiendo esta forma de diseñarlos a capa y espada. A mi gusto es un insulto que estudios como Polyphony lleven años trabajando en un proyecto como Gran Turismo 5, un juego que ha costado más de 60 millones de dólares, el cual no ofrece nada diferente a lo que jugamos en 1998 (excepto las gráficas).

Algunos diseñadores han escapado del país y se han involucrado en proyectos en Europa o América, argumentando que la industria japonesa está en el hoyo y que no motiva diseñar juegos bajo esa dinámica. Tienen razón, pero mientras haya filas interminables por comprar juegos reciclados (como FF XIII), publicaciones que prostituyen su trabajo y directivos con miedo de arriesgar, las cosas no cambiarán.

¿Por qué los lectores siguen pidiendo reseñas divididas en Jugabilidad, Gráficas y Sonido? La escencia de un juego es la experiencia del usuario; si bien esta se logra haciendo uso de los elementos que menciono, es necesario analizarlos como un todo.

Por vicios o modas, los editores tienden a ofrecer reseñas divididas y en cada sección hacen comparaciones que están fuera de lugar (ej. No es un Gears of War pero se juega parecido). Pocos son los que se enfocan en ofrecer detalles de cómo cada elemento ayuda o perjudica el modo como el usuario percibe el juego. Por ejemplo:

- El nivel de daño en tu personaje obligará a que cambies la táctica de juego. Esto es digno de reconocerse ya que el juego respeta el planteamiento de ser un simulador de guerra – Operation Flashpoint: Dragon Rising.

¿Por qué hay que poner énfasis en esos detalles que parecen insignificantes? Porque jugar es una experiencia previamente diseñada por un equipo de desarrolladores. Cada jugador la vivirá de modo distinto, sin embargo hay parámetros útiles para comparar si un elemento falla.

A nadie le importan los términos como anti-aliasing, physX o bump mapping si no van acompañados de una frase que justifique su uso para aumentar o joder esta experiencia.

Las reseñas divididas lo único que provocan es que haya cientos de personas hablando de cosas que no entienden y generando polémica o guerritas estúpidas de “gráficos vs jugabilidad” cada que pueden.

A medida que juega, el editor debe partir de lo general con preguntas como:

• ¿De qué trata?
• ¿Cómo se juega?
• ¿Por qué debería jugarlo?
• ¿Qué necesito hacer para ganar?
• ¿Cuál es mi recompensa?

Para después pasar a lo particular con:

• ¿Es necesario que el control sea así?
• ¿En qué ayudan las gráficas al resto de elementos?
• ¿Por qué la narrativa va implícita en el diseño de los escenarios?
• ¿Hace falta tener un menú tan extenso? ¿En qué ayuda o perjudica?

En esta última sección pueden surgir miles de preguntas y será su trabajo separar aquellas que le sean útiles para redactar y calificar la experiencia.

Una comparativa sería lógica si los dos juegos propusieran la misma experiencia, algo que difícilmente ocurre. Por eso, comparar Killzone 2 con Halo 3 o Modern Warfare 2 está fuera de lugar; los tres tienen planteamientos diferentes, a pesar de ser del mismo género.

Sería bueno que la prensa especializada se enfocara más en estos puntos al analizar un juego, pero sería todavía más bueno que el lector no fuera tan flojo como para exigir que le desmenucen una reseña en tres partes o que incluyan una calificación final para evitar leerse todo el artículo.