Cuando uno escucha hablar a personas como Harvey Smith, se da cuenta de lo mierda que son los juegos en primera persona “populares” de hoy en día.

Dishonored es una de las apuestas más fuertes del próximo año; seguramente pasará desapercibida por el teenager que gusta de Modern Warfare.

Hoy se liberó el SDK de Crysis 2 y de inmediato lo instalé. La primera impresión es que el Sandbox Editor 3 sigue siendo igual de intimidatorio que su antecesor (etiquetas al por mayor, iconos, etc.).

Si a alguien le interesa aprender a usarlo, el mejor lugar para empezar es con la documentación oficial. El SDK pesa 1.4GB e incluye plugins para 3DS Max y Maya, así como las herramientas FMOD Designer y Poly Bump.

Puede descargarse desde MyCrysis y es necesario tener la versión 1.9 del juego para poder ejecutarlo.

Link: The Crysis 2 Editor is available now! (MyCrysis)

Lo logré, justo antes de cerrar el 2010 terminé la estructura del mapa con una escala que parece ser aceptable. Ahora viene el testing con bots y distribución de las armas para balancearlo.

Debido a que es un mapa pequeño y rápido la idea es tener armas de corto alcance, un Flak Cannon con Enforcers y otra de mediano alcance (Link Gun o Shock Rifle) podrían ser la opción.

El próximo año será de mucho trabajo.

Segundo update. Tuve que cambiar el layout inicial, no estaba contendo con el flujo y perdía demasiado tiempo en idear salidas y pasillos. El nuevo layout es igual para un deathmatch para 2-4 jugadores y hasta ahora va a un 80%, lo estoy sometiendo a pruebas para checar la escala.

Una vez listo pediré opinión en MapCore y con mi amigo Alex Galuzin para ver qué ajustes se hacen. La idea de hacerlo en bloques y sin detalle es para asegurarse de que el nivel es jugable antes de comenzar con el modelado de todos los assets.

Las texturas usadas son del editor Hammer del Source Engine, adaptadas por Dale Broadbent a UDK,

Estoy bastante cansado de la modalidad en equipo en los juegos de hoy en día. Verán, hoy en día el multijugador se gesta bajo esta premisa y se exploran diferentes caminos para explotar este tipo de interacción con otros individuos. Desde la simple eliminación grupal hasta la partida basada en objetivos, el multijugador y todo elemento de nuestro mundo se construye en base a la socialización.

¿Qué hay de aquellas partidas donde se competía uno contra todos para medir su habilidad? Parece que ha quedado en el olvido y cuando se incluye es más por mero trámite que otra cosa. Esto me llevó a construir un pequeño nivel en UDK basándome en la teoría multijugador que se escribió por ahí de finales de los noventa.

El proceso ha sido un tanto difícil ya que no tengo el tiempo que quisiera para poder desarrollarlo. Cada día dedico una hora a trabajarlo y para la ejecución utilizo un poco de la metodología de 11-Day Level Design de Alex Galuzin.

Después de hacer algunos trazados en papel cuadriculado levanté un pequeño mockup en Google Sketchup de lo que deseaba para la primer planta (son 3 en total). Me di cuenta que el programa es fácil de usar, sin embargo es todavía más fácil hacer el blocking out de inmediato en UDK, sirve que pruebo en tiempo real y mido la escala.

El layout está basado en el deathmatch circular, el cual Tim Willits define como “mapas que están construidos de tal modo que el jugador no necesitará detenerse y cambiar de dirección”. Hay ajustes que se están haciendo al momento y trato de documentar cada cambio que hago para que quede de referencia, lo cierto es que mucho del trabajo está saliendo por inspiración.

Me gustaría ponerme una fecha estimada, pero es complicado cuando se tiene un trabajo que te absorbe gran parte del día. La parte fuerte vendrá a la hora de generar el contenido en 3D, menos mal que las referencias que escogí no involucran modelado o texturas hiper-detalladas. El objetivo del mapa es centrarse en la jugabilidad de la vieja escuela, mantener la velocidad constante y distribuir de modo inteligente las armas para que el juego sea atractivo.

Hace unos seis o siete meses conocí a Daniel Rodríguez por medio de Twitter. 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án los próximos proyectos.

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 viagra 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.

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

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]