12MP (12 Meses, 12 Proyectos) es una iniciativa que hace un tiempo intentamos llevar a cabo un pequeño grupo de desarrolladores. Se trata de realizar un proyecto en un fin de semana, empieza y se acaba obligatoriamente en esos escasos 3 dias. El objetivo es tener algo que funcione para el lunes, aunque por ahora la verdad es que siempre se nos ha hechado el tiempo encima.

La idea es crear algo que sea sencillo y divertido de realizar. De esta manera ya que nos pasamos todo el fin de semana programando, por lo menos lo pasamos bien, francamente bien.

Este mes se nos ha ocurrido hacer un remake del juego Volfield (o el tipico juego de recreativa de descubrir japonesas en bikini xD) Estoy seguro de que lo conoceis.

Decidimos que sería interesante usar alguna tecnología mas afín al mundo de los videojuegos que WPF o Silverlight, asi que decidimos embarcarnos con Microsoft XNA 3 y ademas así, podriamos jugar en la XBOX, lo cual siempre es interesante.

Yo me ocupo de el “arte” del juego, es decir, el diseño conceptual, modelos, texturas y un poco del diseño de interacción. Al tener tan poco tiempo, normalmente no sigo los pasos ordinarios de este tipo de proyectos, y modelo directamente sin hacer diseños conceptuales. Pero en esta ocasión me pareció interesante seguirlos para ver las mejoras que traia consigo.

Diseño conceptual de un videojuego en 48 horas.

En primer lugar y como es natural debemos partir de una idea, en este caso el remake de volfield pero en un espacio tridimensional esferico (por usar las 3D de XNA). Para empezar vamos con…

El paso de la Servilleta.

Este paso nos ayuda a pensar de una manera grafica, ya que podemos dibujar al tiempo que nos imaginamos la escena.  Nostromo, tendria un planeta centrado en la pantalla. Una nave extraterrestre sería nuestro personaje-jugador y nuestra misióm será limpiar un contaminado planeta tierra. Si, como en Wall·e.

Este paso nos da una idea general del juego, tanto en cuestiones de desarrollo como de arte e interacción. La nave se moverá radialmente por el planeta partiendo de los polos y podremos girar la camara a voluntad independientemente de donde este la nave. Habra 2 tipo de enemigos, los de tierra (que estarán estaticos y lanzarán cohetes si nos acercamos y los de mar, que son moviles. Para el resto mantememos la jugabilidad del juego original.

El Diseño Conceptual.

Esta es la fase más artistica de todas, donde vamos a decidir el estilo grafico del juego. Decimos los efectos de luces, estilos de modelado, texturas etc.. En resumidas cuentas diseñamos la “cara” del juego. Este es el boceto que resultó

Jugariamos con el sol y el movimiento de la camara para simular amaneceres y atardeceres. los edificios serán modelos y no simplemente texturas. El planeta debe tener una pequeña simulacion de atmosfera pero sin nubes. Encuanto a los enemigos quedamos tal que así.

En este paso es importante no perder mucho tiempo, es decir, es un paso muy importante pero hay que tener en cuenta que todos los graficos que hagais aquí, no quedarán reflejados en el videojuego. No es importante que los dibujos sean muy buenos, lo importante es que sean descriptivos, expresivos y definan bien la idea. Si detallais demasiado o dibujais perpetivas mas artisticas que utiles, estareis perdiendo el tiempo. Lo importante del diseño conceptual es el concepto!

Modelado en 3D dimensiones.

Ahora si que vamos a empezar a trabajar. El modelado 3D debe ser lo mas parecido posible al concepto, siempre mirando eso si, la parte tecnica (poligonos, calidad de las texturas, shaders…). Si el diseñador ha hecho algo que es imposible o muy costoso de hacer (recordad que estamos en un desarrollo rapido) tendreis que hablar con él y llegar a algún punto medio.

En este Caso como la tecnología nos lo permitia, no hemos reparado demasiado en poligonos n_n.

Texturizado.

Las texturas, es en mi opinion mas parte mas compleja, larga e importante de todo el proceso, eso si, es muy agradecida. Este es un paso muy importante ya que es el que mas estilo va a darle a nuestro juego. Aqui si debemos ser detallistas y cuidadosos. Debemos tambien ser despiertos y habiles ya que nos va a permitir ahorrar muchos recursos si somos listos.

Que os parece? Creo que queda bastante resultón sin siquiera usar ningun Shader. Nos hemos pasado un poco el los poligonos, pero en un fin de semana tampoco vamos a ponernos a optimizar mucho! y ademas XNA podrá moverlo sin problemas en un ordenador medio. (por no hablar de la Xbox360)

Ahora solo queda dar estos modelos a los desarrolladores y que lo integren en la aplicación!

Y bueno, nada mas por hoy. Falta el tema de Shaders pero no os preocupeis que pronto hablaremos largo y dendido sobre shaders y hasta donde podemos llegar con ellos con nuestras aplicaciones.

En breve colgamos lo que tengamos del juego!

Hay una Relato muy curioso en el libro “El hombre que confundio a su mujer con un sombrero” (del Dr. Oliver Sacks) que cuenta la historia de un profesor de Musica con una extraña enfermedad cerebral degenerativa, la cual le atrofió el pensamiento abstacto y otras capacidades cognitivas.

El Profesor P. (este curioso profesor de musica aleman) presentaba un extraño comportamiento a la hora de reconocer objetos visualmente. Él poseia una vista de lince. Podia ver incluso un alfiler al otro lado de la habitación. Siembargo, el profesor P. no era capaz de reconocer algunos objetos o incluso personas.

Mirando retratos de su familia solo conseguía reconocer a aquellos que tenían rasgos faciales o corporales notables; – Ah sí, Paul!- decia al ver una foto de su hermano. Esa mandibula cuadra, esos dientes tan grandes.. Reconoceria a Paul en cualquier parte!.

Desgraciadamente no podia reconocerse a si mismo o a su mujer. Cuenta Sacks en el libro, que no solo no la reconocia, si no que la llego a confundir con un sombrero e intento ponersela en la cabeza.

Este hombre no era capaz de relacionar las formas que veian sus ojos con objetos de la realidad. Cuando el Doctor Sacks le enseña una rosa, esta fue su reaccion:

“La cogió como un botánico o un morfologo al que le dan un especimen, no como una persona a la que le dan una flor.

-Unos quince centrimetros de longitud – comentó- una forma roja enrollada con un añadido lineal verde.

– Exacto - ¿Y que cree que es?

-No es facil de decir.. Carece de la simetria simple de los solidos platonicos, aunque quizas tenga una simetría superior propia.. creo que podria ser una inflorescencia o una flor. 

- ¿Prodria ser? – inquirí. Huélala. Y de nuevo pareció sorprenderse un poco, como si le hubiese pedido que oliese una “simetria superior”. Pero accedió y cortés se la acerco a la nariz. Entonces bruscamente exclamo:

-Que maravilla, una rosa temprana! “

(extracto del libro)

La verdad es que al leer esto supe que aunque el doctor Sacks no lo supiera, habia dado con el principal problema del interfaz de usuario. – La abstraccion -

Seguramente habeis visto iconos y aplicaciones las cuales al mirarlas os habeis quedado como el Profesor P. al ver la rosa, traspuestos. Y el problema es que el interfaz (o el icono) no es capaz de comunicaros con una parte de vuesta realidad. Vemos formas, colores incluso sonidos. pero no somos capaces de extraer la información o el significado. Con lo cual estamos, literalmente, perdidos.

Los colores, las formas, las animaciones y sonidos no son solo recursos esteticos, de hecho esto debe ser (desde un punto de vista funcionalista) el ultimo de nuestros requisitos. Son en su lugar poderosas herramientas de comunicación. Son el vinculo entre la “utilidad” de la aplicacion y el cerebro del usuario.

Debemos saber comunicarnos con él. Para eso debemos dar un significado “real” a nuestro interfaz. Por real no me refiero a que tengamos que evocar objetos en todos nuestros iconos. Si no que debemos conectar con el usuario, y disparar en él un recuerdo, un significado en su mente, que él pueda asociar a algo cognitivo.

El un futuro post, abordaremos una de las mejores maneras de llegar a esto: La metafora como herramienta sinestesica.

En esta pagina se recojen los crimenes mas bestias que se pueden cometer (y de hecho se cometen) en la experiencia de usuario de web. La web esta realizada por expertos, asi que todo lo que podeis encontrar esta hecho aposta para que entendamos en nuestras propias carnes los problemas de hacer las cosas mal.

Un fondo demasiado contrastado, animaciones repetitivas, musica que empieza directamente al entrar en la web, sobredosis de contenido o la falta de él, son algunos de los ejemplos que nos ponen los chicos de angelfire.

Que lo disfruteis.

Con motivo de mi reciente cambio de empresa he diseñado junto con Luis Guerrero este pequeño jueguecito en Silverlight 2. Con esto, empieza un nuevo ciclo (otro mas!) en mi vida.

A la gente de ilitia les mando un gran abrazo! y mil disculpas por no haberme podido despedir como dios manda. Pero al fin y al cabo las cervecerías siguen abiertas y daremos buena cuenta de ello (Por no hablar de los "Parrondos!").

No me olvido de los temas pendientes! Dani, algún día tendré tiempo de hacer tu dibujo! y Sergio! nuestros gadgets dominarán el mundo! (skynet!?). Fernandito! cuídate esa pierna!!, Myr! muchísima suerte en tu nueva etapa y dales fuerte con el látigo!. Antón, dios te pille confesao! que las "despedidas" son duras!. Esteban! aun tengo la pegatina en la moto!! che!!, Vicente! felicidades por el MVP!, Blanquita! a ti que te voy a decir que no te susurre todas las noches al oído!?, Fer, Agus y demas ilitios importantes, ha sido una gran experiencia trabajar en ilitia, a pesar de estos últimos sucesos, espero que entendáis la situación en todo su contexto! y bueno, por supuesto me gustaría desearle mucha suerte a Migs  sin el cual, no estaría aquí. Espero que medites todo lo que hemos hablado, que ha sido largo y tendido! y recuerdes las noches por death valley con Justice a todo trapo xD. A todos los demás que me dejo en el tintero os deseo muchísima suerte y buena caza!

Me prometí no hacer ningun post personal pero os lo debía a todos! Hasta mas ver Mendrugos!! ;)

foto : Designing interaction de Bill Moggridge.

Una de las mayores diferencias que encontramos con Flash, es que Silverlight y WPF no son “un programa” sino que son una tecnología en sí misma. Expression Blend es tan solo un programa que nos ayuda a “moldear” esa tecnología de una manera sencilla.  Por poner un ejemplo, Blend es a XAML lo que Dreamweaver es a HTML. La tecnología es HTML pero Dreamweaver nos ayuda a, sin tener que tocar código, componer nuestro HTML.

Si habéis usado Dreamweaver, sabréis que esto es una verdad a medias. Porque o bien dreamweaver acaba metiendo código “basura” o no hace exactamente lo que queremos que haga. Así que lo más conveniente saber HTML y corregir a mano muchas cosas, incluso a veces hacerlo todo a mano desde 0.

Con Blend pasa exactamente igual, a veces Blend nos generará un código XAML que tendremos que cambiar a mano, así que voy a explicar brevemente…

¿Que es XAML?

Xaml es un lenguaje declarativo de Decorado (Markup) basado en XML. (Para que nos entendamos, es un HTML muuuy avanzado.)  En él, se definen elementos y acciones que se representarán en el programa. Estos elementos, tienen una serie de propiedades que definen su forma, estado, color, tamaño, etc... Voy a poner un ejemplo.

<Button Height="57"  Width="100"  Content="mi Boton"/>

Como veis, con una sola línea, podemos hacer un botón. Exactamente como HTML.  Los elementos o controles de usuario se definen como he dicho por propiedades. En este caso, el botón tiene un ancho “100”, un alto “57” y un contenido “mi botón”. Estas son propiedades simples. Donde una propiedad tiene un valor sencillo, como “40”, “Hola”, “#ffffffff”, etc...

Pero existen propiedades que son más complejas y no se podrían expresar como una palabra o numero. Esas, como es el caso de los rellenos degradados se escriben de esta forma.

<Button Height="57"  Width="100"  Content="mi Boton">

            <Button.Background>

                <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">

                    <GradientStop Color="#FFFFFFFF"/>

                    <GradientStop Color="#FFFF0000" Offset="1"/>

                </LinearGradientBrush>

            </Button.Background>

        </Button>

Abrimos el Nodo del elemento y metemos un hijo con esta nomenclatura <Elemento.Propiedad> y dentro metemos la información. Esto nos da un boton tal que así.

No os asustéis! como os he dicho, no tenéis que escribirlo vosotros. De hecho si todo va bien, apenas veréis el código, tan solo la interfaz grafica de Blend tal y como pasa en Flash.

Con XAML podéis hacer todo tipo de cosas, Dibujos vectoriales, Animaciones, Videos, Fotos, meter sonidos, hacer un Layaout dinámico, hacer gran parte de la interacción, meter incluso 3D (en WPF). No tenéis ningún limite os lo aseguro.

No obstante tal y como pasa en flash, llega un momento en el que la interacción se vuelve compleja y necesitamos programar que es lo que va a pasar. Por ejemplo, que pasa cuando hago clic en un botón. En flash es sencillo, nos vamos a la ventana de acciones y escribimos miboton.mouseDown = function(){}

En Blend, no tenemos ventana de acciones pero tenemos algo mejor e infinitamente más potente…

El Code Behind

Todos los archivos XAML tienen un “compañero” que se llaman igual pero terminan en XAML.CS (en el caso de C#). Si empezamos un proyecto de Silverlight veréis que hay un archivo Page.Xaml y otro Page.Xaml.cs

Estos son los archivos de “Code Behind” o Código trasero. Aquí estará toda la funcionalidad de nuestro elemento que no podamos hacer directamente en XAML.

En nuestro XAML, en el botón que tenemos en Page.Xaml hacernos referencia a una función que está escrita en su Code Behind, es decir en Page.Xaml.cs

Page.Xaml

<Button Height="57"  Width="100"  Content="mi Boton" Click="Button_Click"/>

Page.Xaml.cs

private void Button_Click(object sender, RoutedEventArgs e)
       {
           this.Background = new SolidColorBrush(Colors.Blue);
       }

Lo bueno del tema, es que los Archivos CS podemos editarlos con VisualStudio 2008 lo que nos da una potencia increíble, y además vuestro programador estará muy contento. Ya que es un lenguaje que seguramente conozca (se puede programar en C#, Visual Basic, Phyton o Ruby) lo cual no está nada mal.

Bueno creo que hasta aquí los conceptos que menos se parecen a flash y pueden ser un poco más complicados. El resto será mucho más visual y divertido.

Próximo: Blending Flash Parte 3: Interfaz de Blend ~ Flash.