Llegamos a la quinta parte del capitulo 6 en el que seguimos desarrollando el menú de nuestro juego, y ya queda poco para terminarlo. Realmente el capitulo 6 es tan largo debido a que hemos ido introduciendo conceptos importantes sobre la marcha que quizás nos han desviado de la programación en si, en este capitulo hablamos de las variables locales y su ámbito de visibilidad.

Como habréis comprobado, el proceso de diseño descendente sigue las pautas que hemos seguido hasta el momento a la hora de razonar los datos y elementos que necesitaríamos para programar así como la metodología y las soluciones que hemos dado a los problemas que se han ido presentando.

A estas alturas del curso y después del ejemplo anterior, muchos os habréis dado cuenta de que una función es un programa en si mismo (sucesión de instrucciones y acciones con el propósito de resolver un problema), pero se podría decir que por si solos no podrían existir o serían de poca utilidad (de ahí el término subprograma). En general lo que queremos es dar forma de instrucción a lo que es un programa o conjunto de tareas, que necesitamos ejecutar en un determinado orden para alcanzar un objetivo, ya sea hacer un suma de vectores o comprobar si cierta estructura compleja cumple cierta condición.

Volviendo a nuestro juego, nos quedamos en la conclusión de que necesitabamos una función para alternar la selección entre los elementos de nuestro menú. Ahora que ya sabemos como programarla, manos a la obra.

A esta función la llamaremos AlternarSeleccion, y su trabajo consistirá en dados 3 valores booleanos que representen la información de los botones pulsados (2 de la pulsación actual y 2 de la pulsacion anterior), una diferencia y una variable numérica, modificará el valor de dicha variable hacia arriba o hacia abajo la diferencia según se pulse un botón o otro. Es decir, si se pulsa la tecla del primer argumento se incrementará el valor en la diferencia, y si se pulsa la del segundo, se decrementará la diferencia.

El orden de los parámetros es muy importante, ya que las declaración y la llamada coinciden en nombre, en orden y tipo de parámetros. Así si un parámetro A de tipo número está el primero, en la llamada el primer valor que pasemos como argumento se asignará a A. Por llamada entendemos el código necesario para ejecutar una función pasando una serie de parámetros definidos que llamaremos argumentos.

Por tanto para llamar a una función deberemos introducir la firma substituyendo los parametros por valores concretos del tipo que corresponda en el orden marcado. En el ejemplo anterior se llama a la función SumaVector, por tanto no perderemos tiempo en crear otro programa y seguiremos con la programación de la función que necesitamos para nuestro juego.

A la función de alternancia de opciones, valores, en función de dos botones que realicen funciones contrarias de adición y disminución, la denominaremos AlternarOp. Por tanto la firma de la función será la siguiente:

function Alternar(B1, B2, OldB1, OldB2, Elemento, Diferencia)

Recordad que B1, B2 son el valor de pulsación de los botones, b1 para el que sube, b2 para el que baja, y OldB1, OldB2 los valores de pulsación del ciclo anterior (para evitar que el desfase entre los botones que ya comentamos y resolvimos). Elemento es el valor inicial de la variable que contiene la información de la opción, y la diferencia lo que se incrementará a cada pulsación (2, 3 … N opciones).

A continuación os dejo el código de la función con las explicaciones en comentarios. Pero no tiene ninguna dificultad si has seguido hasta ahora el contenido del curso, ya que solo se hace un pulsación de botones con un incremento sobre una variable que será el valor de retorno de una función:

--Funcion para alternar el estado en funcion de las pulsacones
function Alternar(B1, B2, OldB1, OldB2, Elemento, Diferencia)
if B1 and OldB1 ~= B1 then-- Si se pulsa el botón 1 y no hay repeticion
Elemento = Elemento+Diferencia--aumentamos la diferencia
elseif B2 and OldB2 ~= B2 then-- Si no se pulsa el botón 1 y el botón 2 es pulsado y no --hay repeticion
Elemento = Elemento-Diferencia--Disminuimos la diferencia
end
return Elemento--Devolvemos el valor de Elemento tras la funcion
end

Antes de pasar a implementar esta función el código de nuestro juego, es conveniente remarcar un aspecto que hemos comentado de pasada dejandolo para más adelante, y puesto que ya es más adelante, hablemos de variables locales.

Pese a que no es un concepto muy difícil de asimilar, he preferido dejar las variables locales hasta este momento porque una vez habituados a las funciones, su comprensión es más sencilla. Hemos comentado que “Lua tampoco nos permitirá modificar el valor de las variables introducidas como parámetros, sino que se realizará una copia a una variable local de ámbito de visibilidad la función”, lo que significa que esas variables “modelo” que pueden recibir cualquier valor del tipo especificado para trabajar, y que conocemos como parámetros, solo pueden ser accedidas dentro de la función: desde la firma hasta el end (visualmente).

Por tanto, podemos afirmar que las funciones son un ámbito local para los parámetros. Si fuera de nuestra función alternar intentásemos acceder a la variable parámetro Elemento, resultaría que esta no existe, es decir que sólo existe dentro de la función y mientras esta se ejecuta. Puesto que no existía antes de que la función fuese ejecutada (su valor era nil) al salir de ella el valor tampoco existirá (volverá a ser nil) aunque durante el transcurso de la ejecución de la función haya recibido varios valores.

Hasta ahora hemos trabajado tan sólo con variables globales que declarábamos justo antes de un bucle principal de nuestro juego. Ahora tendremos un nuevo criterio que será el trabajar con variables locales siempre que nos sea posible. El motivo es sencillo: las variables locales no dejan información basura ni afectan directamente a otros componentes del programa, y es que básicamente nos interesará que cada parte de nuestro programa deje todo como lo encontró antes de ponerse a trabajar.

Pero hasta ahora tan sólo hemos visto un caso concreto de variables locales, como son las funciones y sus parámetros, como para poder hacer un uso eficiente de ellas. Por tanto, ahora que tenemos una pequeña comprensión de lo que son, podemos pasar a entenderlas en todos ámbitos. Y es que una variable local es aquella cuyo valor se mantiene tan sólo dentro de un ámbito local de visibilidad, y existen varios elementos que definen esos ámbitos.

Dentro de esos ámbitos locales las variables locales serán visibles por todas las estructuras y entidades que se ejecuten dentro de él, pudiendo así acceder a ellas aunque dichas entidades conformen por si mismas otro ámbito local. Por tanto podemos hablar de algo así como un orden o jerarquía, en el que encontraremos ámbitos locales más restrictivos dentro de otros ámbitos locales. Algo que se ilustra en el siguiente esquema:

Por eso antes de pasar a la declaración de variables locales me gustaría comentar las entidades que generan un ámbito local en Lua. El primero de ellos es el propio script del programa, la diferencia es que puesto que cualquier estructura dentro de ese script podrá acceder a la variables locales del mismo (tal y como hemos comentado), las denominaremos globales. Sin embargo, el sistema PSP si que contemplará esas variables como locales pero al programa en que se ejecuta nuestro script (sin ser esta afirmación del todo precisa).

Las estructuras condicionales (if, elseif, else) y las iterativas (while y for) también determinan ámbitos locales, desde su inicio hasta el end que concluye las acciones que realizarán:

Las funciones también determinarán un ámbito local, como ya hemos comentado al introducir las variables locales, y este no se limitará sólo a los parámetros sino también a otras variables locales auxiliares o necesarias que necesite la función para realizar correctamente su trabajo.

function Firma
-- Ambito Local
end

Para declarar una variable local debemos hacerlo como cualquier otra pero con la palabra clave local precediendo la expresión normal:

local Variable = Valor

Y después de mucho camino recorrido y varios conceptos clave, volvemos a trabajar en nuestro menú allí donde lo dejamos. Para aquellos que hayan perdido el hilo y todavía tengan la cabeza en funciones y variables locales, recapitulemos. Seguramente más de uno estará disgustado por el hecho de que después de todo lo andado, aún no hemos dotado de ninguna funcionalidad al menú y lo único que hace es mostrar opciones y datos sobre los que no podemos “navegar”. Pero no es del todo cierto, hemos allanado el terreno con los últimos conceptos dados hasta el punto de que la interacción con el menú se basará en la pulsación de dos botones y una función que nos permitirá movernos por ellas según la pulsación de otros dos. Es por eso que antes de programar la función juego dotaremos de funcionalidad a nuestros menús para así recoger parte de la “cosecha sembrada” y que de alguna forma se intuya el avance. También porque es poco ordenado y poco recomendable dejar una parte a medias cuando podemos dejarla lista sin esfuerzo.

Pues manos a la obra, lo primero que debemos añadir a nuestro programa principal es la declaración e inicialización de las variables pad y oldpad que nos servirán para recibir información de los controles, elemento fundamental para la interacción con el usuario.

Ahora que ya disponemos de la información relativa a los controles, podemos cambiar el estado del juego en consecuencia. Empezaremos por el cambio de selección, para ello creamos una función llamada Alternar a la que pasábamos por parámetro la información de los controles además de otros argumentos.

Por último en el menú principal deberemos tener en cuenta que no hay ningún menú superior, por tanto no habrá una opción “atrás” sino que tan solo deberemos preocuparnos de cuando se selecciona la selección. El botón asignado para la selección, como es habitual en la plataformas PlayStation, será el X. Pese a que de momento no sea necesario, determinaremos que el botón por defecto para volver atrás o cancelar una operación será el O.

Como último apunte antes de implementar lo comentado a nuestro menú, será especificar que las funciones que creemos se almacenarán en una carpeta llamada “DATOS”. En esta carpeta crearemos 3 scripts uno que llamaremos “Interfaz.lua” que contendrá las funciones relacionadas con los menús y interacciones comunes con el usuario, otro que llamaremos “Juego.lua” que contendrá las funciones que programaremos para que el juego funcione y un último llamado “Otras.lua” en el que meteremos el resto. Esta división en 3 ficheros nos ayudará a organizarnos, para Lua el efecto será el mismo que si estuvieran en un mismo fichero o dentro del mismo programa principal.

Con lo comentado el código del menú principal y del fichero “Interfaz.lua” respectivamente será:

while Juego.Menu == 1 do
     screen:clear()
     pad = Controls.read()
     --Funcion para alternar el estado en funcion de las pulsacones
     Juego.OpcionMenu = Alternar(pad:down(), pad:up(), oldpad:down(), oldpad:up(), Juego.OpcionMenu, 1)
     for n = 1,4 do
         screen:print(50, 50+20*(n-1),OpMenuPrincipal[n],Blanco)
     end
     screen:print(50,50+20*(Juego.OpcionMenu-1),OpMenuPrincipal[Juego.OpcionMenu], Azul)
     oldpad = pad
     screen:flip()
     screen.waitVblankStart()
 end

--Funcion para alternar el estado en funcion de las pulsacones
function Alternar(B1, B2, OldB1, OldB2, Elemento, Diferencia)
if B1 and OldB1 ~= B1 then-- Si se pulsa el bot�n 1 y no hay repeticion
Elemento = Elemento+Diferencia--aumentamos la diferencia
elseif B2 and OldB2 ~= B2 then-- Si no se pulsa el boton 1 y el boton 2 es pulsado y no --hay repeticion
Elemento = Elemento-Diferencia--Disminuimos la diferencia
end
return Elemento--Devolvemos el valor de Elemento tras la funcion
end

Una vez que lo hemos probado detectamos un error que nos impide la ejecución “attemp to call global ‘Alternar’ (a nil value)”. Esta es la primera vez que hablamos de los mensajes de debug que nos proporciona Lua, y en realidad son realmente importantes porque entender su significado nos ayudará mucho a la hora de resolver errores de sintaxis o de accesos “prohibidos” por así llamarlos. Este error nos informa de que cuando se ha ejecutado la función Alternar no se ha encontrado ninguna declaración valida. Esto tiene mucho sentido, sobretodo porque en nuestro programa principal no hay ni una sola linea de código que parezca hacer referencia a una declaración de esta funcionalidad, y no la hay. Para hacerlo tendremos que hablar de la funcionalidad dofile que será nuestro primer acceso a un fichero externo que no sea un gráfico.

PlayStation 3 está pensada como una máquina de ocio multimedia, por tanto, además de para jugar dispone de muchas más funcionalidades con las que disfrutar de otro tipo de contenidos como películas, fotos, música, etc.

Uno de los problemas, es que pese a la gran capacidad de su disco duro no nos viene cargados con estos contenidos, sino que los agregamos nosotros. Normalmente los almacenamos en el ordenador y de ahí los grabamos a discos, cosa que puede ser incomoda. Pero PlayStation 3 nos brinda la posibilidad de acceder a servidores multimedia DNA.

Nuestro ordenador por defecto no dispone de capacidad de servidor multimedia, sino que debemos habilitarlo y configurarlo nosotros para que actue como tal. Para ello disponemos de multiples posibilidades, pero en este tutorial por su sencillez y carácter estandarizado para todas las máquinas con Windows, úsaremos Windows Media Player 11. Es importante mencionar, que mientras que para Windows Xp los pasos descritos en este tutorial no dan lugar a error, en las nuevas versiones puede dar problemas, incluso no funcionar, debido a que la creación de este tipo de servidores se ha vuelto más compleja.

Tutorial escrito para LivingPs3, lee la versión comple aquí.

Después de un tiempo sin nuevas entregas, os dejo con la cuarta parte del capítulo 6, que es más larga de lo habitual para compensar con la tercera. Esta vez introducimos conceptos muy importantes como pueden ser las funciones, el diseño descendente o la programación estructurada.

Para empezar a entender la utilidad de las funciones veremos un caso directo en nuestro programa. Cuando hemos diseñado el menú tan sólo nos hemos preocupado de la faceta visual, no le hemos dotado de ninguna utilidad ya que tal y como está ahora el usuario no puede navegar entre las opciones del menú. Para navegar entre ellas, deberemos comprobar la pulsación arriba o abajo y incrementar o decrementar el elemento del array Juego.OpcionMenu. Nos encontramos con que esta tarea será necesaria en varios menús, y si generalizamos aún más, en cualquier tarea que implique moverse o modificar el valor de algo en función de la pulsación. Entonces, la cuestión es, ¿deberíamos repetir el código cada vez que lo necesitemos o existe alguna forma de evitarlo?

Ahí es donde aparece el concepto de función, y en general el de subprograma. Antes de pasar a crear e implementar una función, debemos aclarar aún más este concepto, porque hasta el momento lo que nos ha llevado a pensar en ellas es un caso muy limitado que nos presenta sólo una de sus utilidades (la reutilización de código sin caer en repeticiones), cuando su importancia ni mucho menos se limita a eso, sino que es uno de los pilares de la programación estructurada y muy importante para el diseño descendente.

Después de haber programado nuestra escena de entrada y de parte del menú, llevamos suficientes lineas de código a la espalda como para habernos dado cuenta de ciertos hechos, que en parte hemos comentado. La más evidente es que el orden de las instrucciones y su ejecución (flujo) es secuencial, las primeras se ejecutan primero y así sucesivamente, esta es la estructura o el esquema secuencial. Y que a la hora de controlar el orden de ejecución, encontramos condicionales (p.e:if) o estructuras iterativas (p.e:while), es decir el esquema condicional y el esquema iterativo respectivamente. La existencia de estas tres estructuras nos lleva a uno de los teoremas fundamentales de la programación, el de Böhm y Jacopini:

Todo algoritmo propio puede ser expresado en términos de sólo tres tipos de estructura: secuencial, condicional y repetitiva.

No vamos a entrar a definir lo que es un algoritmo, sino que nos centraremos en lo que implica, que es que mediante estas tres estructuras podemos resolver cualquier problema que se nos presente a la hora de programar. Pero aún así nos encontramos con la imposición de cómo resolver el problema, y para eso existe una metodología para el diseño de programas llamada diseño descendente o método del refinamiento sucesivo, íntimamente relacionado con un paradigma de programación, la programación estructurada.

A grandes rasgos, el método del diseño descendente se basa en dividir un problema dado en problemas menores y de mayor facilidad de resolución. Cada vez que se simplifique un problema, en otro menor aplicamos un nivel de refinamiento, no pudiendo mezclar tareas de diferente complejidad en un mismo nivel.

Por ejemplo, si queremos buscar un punto en un texto, podemos dividir esa tarea en subtareas para acometerlo. Primero desplazaríamos la mirada al texto, leeríamos, y una vez identificado el punto almacenaríamos su posición o en nuestra cabeza o apuntándolo. Pues si extrapolamos al diseño de un programa que debe buscar un punto en un string: leeríamos el string carácter a carácter, encontraríamos o no el punto, almacenaríamos su posición en RAM o en MS y posiblemente lo mostraríamos en pantalla.

La programación estructurada es un paradigma de programación que mezcla que los tres esquemas iterativos junto con la posibilidad de componer un programa con subprogramas menores, reutilizables y de aplicación generica a un mismo problema. Esos subprogramas suelen implementarse como funciones o como procedimientos dependiendo del lenguaje (en lua serán sólo funciones). El carácter génerico lo conseguimos mediante el paso de parametros, que en la practica son variables de ámbito local que en lugar de declararse e inicializarse dentro del subprograma obtienen sus valores en la llamada del mismo.

La relación entre el diseño descendente y la programación estructurada, es que el diseño descendente nos permite diseñar los programas, su estructura, y la programación estructurada nos permite implementarlos (llevarlos a cabo). Así vemos que ciertas tareas en el diseño descendente serán apropiadas para convertirse en funciones (por ejemplo leer un carácter de un texto dado), otras deberán ser aún más refinadas (por ejemplo sumar un vector) y otras las podremos implementar directamente con las herramientas que nos proporciona el lenguaje o con funciones ya programadas (sumar 2+2, o comprobar si el carácter leido es igual a punto).

Tras esta pequeña introducción ya debemos ser conscientes de que estamos trabajando dentro del paradigma de la programación estructurada, pero tampoco nos vamos a preocupar demasiado por eso. Son aspectos técnicos de programación a los que sería lo correcto ceñirse, sobretodo porque son las herramientas que nos permitirán realizar programas más complejos y que nos simplificarán la tarea de diseñar software, pero que en general no comentaremos pese a que se estén aplicando. También se dan casos en que me he tomado pequeñas licencias ya que es un curso introductorio y a veces el diseño correcto pasa por complicar más el problema a nivel técnico, y la intención es explicar de una forma sencilla y global el diseño de un videojuego.

Los últimos párrafos han sido muy teóricos, pese a que eran prescindibles a este nivel de complejidad, considero que es muy importante introducir estos conceptos para entender las herramientas de las que disponemos y como funcionan hasta cierto punto. Por eso, ahora que ya hemos introducido el diseño descendente junto con la programación estructurada, podemos introducir que mecanismo ofrece Lua y en otros muchos lenguajes para la implementación de subprogramas: las funciones y los procedimientos.

Los procedimientos son una serie de tareas que se ejecutan en sucesión (secuencialmente) al ser invocados y que pueden recibir parámetros. Algunos lenguajes permiten que la función reciba datos y envie datos por parámetro, esto quiere decir que los parámetros pueden ser leídos, modificados o ambos.

La funciones son instrucciones que se ejecutan secuencialmente al ser llamadas, que pueden recibir datos por parámetros, y que además devuelven un valor que normalmente se especifica mediante la palabra clave return. Esto hace que las funciones representen valores, mientras los procedimientos sólo realizan una serie de tareas, así debemos concebir la llamada a una función como el valor que devuelve allá donde la usemos. Por ejemplo, si una función devuelve siempre un entero de valor 2, debemos pensar que la llamada a la función representa un valor 2.

Por tanto tanto funciones como procedimientos son conjuntos de instrucciones que se realizan secuencialmente para solventar un problema mayor o ejecutar un trabajo, de forma que este quede resuelto en una llamada a la misma, en lugar de realizar todo el conjunto de instrucciones reiteradamente cada vez que se necesite llevar a cabo la tarea. La diferencia entre ambas está en que los procedimientos realizan esas tareas, y las funciones además devuelven un valor de forma que dicha función representa dicho valor dentro del código. Una vez que acaba su ejecución el flujo del programa vuelve al punto donde fue llamado el subprograma.

declaración de una función en Lua empieza con la palabra clave function, seguida del nombre de la función y los argumentos, acabando con un end. El nombre y los argumentos se conocen como firma de la función y será lo que nos permita llamarla en otra parte del código. Como hemos comentado el valor de retorno se especificará con la palabra return, una vez que se devuelve el valor la función para su ejecución y vuelve al lugar desde que fue llamada. Lua no distingue entre procedimiento y función, sino que para declarar un procedimiento bastará con crear una función sin sentencia return, es decir que no devuelva ningún valor. Lua tampoco nos permitirá modificar el valor de las variables introducidas como parámetros, sino que se realizará una copia a una variable local de ámbito de visibilidad la función.

Un pequeño Ejemplo

Antes de continuar haremos un paréntesis en el curso, y nos olvidaremos por un momento del juego que estamos desarrollando para crear un pequeño programa que nos permita ver la aplicación del diseño descendente, la programación estructurada y la programación de funciones. El programa sumará dos vectores cualquiera, para no distraernos con problemas ajenos a los conceptos que queremos poner en practica los declararemos y no serán introducidos por el usuario. Los vectores será considerados dentro del espacio euclidiano en 3D, es decir que tendrán 3 componentes que expresaremos como un array de enteros.

En primer lugar vamos a pensar en los pasos que seguimos al sumar dos vectores nosotros mismos, en el papel o mentalmente. Primero vemos los valores de los vectores, es decir los leemos, lo que en el programa se traducirá en la inicialización de las variables. En caso de que fueran introducidos por el usuario, estos serían introducidos por él. Después realizamos la suma, pero nos damos cuenta que es una tarea compleja, y nosotros mismos en nuestra mente la subdividimos o refinamos en sumar componente a componente del vector. Por último escribimos el resultado en el papel, análogamente en nuestro programa lo visualizaremos en pantalla. Por tanto ya hemos analizado el problema, y lo podemos expresar en forma algorítmica:

Algoritmo Sumar Vector Es
                  Inicializar;
                  SumaVector;
                  Visualizar;
Fin

Como hemos comentado, la tarea de sumar vector debe ser refinada, puesto que no la podemos realizar directamente con una instrucción. Para ello escribiremos el algoritmo de la misma:

Algorimo SumaVector ES
                 SumarPrimerasComponentes;
                 SumarSegundasComponentes;
                 SumarTercerasComponentes;
Fin

Ya no debemos refinar nada más, ya que las componentes de un vector son enteros, y el lenguaje nos permite realizar suma de enteros, es decir, el lenguaje nos ofrece una solución directa al problema. Es interesante mencionar, que a veces estas soluciones directas nos las ofrecerán las librerías o paquetes, de forma que aunque estas tareas esten refinadas nos llegan en forma de función cuya forma de funcionar (implementación) nos es indiferente ya que las veremos como cajas negras que realizan una tarea especifica.

Una vez creado el algoritmo, debemos decidir que refinamientos son apropiados para constituirse en subprograma. En esta fase estamos relacionando directamente el diseño descendente con la programación, y aplicamos el diseño a la arquitectura e implementación de nuestro programa. La unica tarea refinada es SumaVector. La suma de vectores es una tarea habitual y genérica, sirve para todos los vectores, por tanto nos será muy útil que sea un subprograma. Existen varios criterios para decidir que refinamientos crear como subprogramas, pero el de reutilización es quizás el más absoluto. Crear un subprograma de la suma de vectores nos permitirá disponer de una herramienta para sumar cualquier vector en cualquier programa, es decir, nos proporcionará la posibilidad de reutilización que nos ahorrará tiempo y trabajo.

El lenguaje en el que se expresan los algoritmos se llama pseudo-código y consiste en usar el lenguaje normal de forma que posteriormente puedan ser traducidas a código. Esta forma de diseñar un programa nos ayuda a entender mejor nuestro código, nos facilita la resolución del programa y reduce el tiempo de programación, ya que la programación dejará de ser un proceso completamente creativo para acercarse más a algo así como una traducción.

Por último programaremos el algoritmo. En este ejemplo la función Suma Vector estará en el mismo fichero Lua, pero en posteriores explicaremos como ubicarlas en otros ficheros para mejorar el orden y la legibilidad del código. Esto nos lleva a mencionar algo que parece evidente: antes de llamar a una función, esta debe haber sido declarada.

--Declaracion de la funcion encargada de sumar vectores
function SumaVector(Vector1, Vector2)
local V = {0,0,0}--Vector que contendrá el resultado
	for i = 1, 3 do--Iteramos sobre las 3 componentes
              V[i] = Vector1[i] + Vector2[i]
	end
return V
end

-- Este programa no tendrá bucle principal ya que solo hace la suma, la visualiza en pantalla y espera

--Incializacion
V1 = {5,3,9}--Vector 1 declarado y incializado, cambia los valores para ver el resultado
V2 = {89,1,7}--Vector 2 declarado y incializado, cambia los valores para ver el resultado
VR = {}--Vector para almacenar el resultado
Blanco = Color.new(255,255,255)
--Suma de Vectores
VR = SumaVector(V1,V2)--Le asignamos a VR el valor devuelto por SumaVector(como funcion representa un valor que puede ser asignado)

--Visualizacion
screen:print(50,50,"El Resultado es:", Blanco)
screen:print(70,60, "(" ..VR[1].. "," ..VR[2].. ","..VR[3].. ")" , Blanco)
screen.flip()
screen.waitVblankStart(10000)

El mercado de videojuegos, y en especial el de consolas, tiende a dividir su actividad en tres principales territorios: Europa, EEUU y Japón/Asia. Estos tres territorios son los más significativos en cuanto a ventas y beneficios, lo que no impide que existan otros como América del Sur.

La PSStore y la PSNetwork también divide su actividad en territorios, creando 3 modelos independientes que no tienen porque ofrecer los mismos contenidos. Esto se debe en parte a que es muy difícil distribuir juegos multiregión y más que los incluyan todos los idiomas, así se realizan
lanzamientos escalados en los que normalmente los europeos salimos poco favorecidos.

Ir a LivingPs3 para ver el tutorial completo

Visualizar Versión PDF

Entrega corta, pero los examenes de febrero se acercan y eso combinado con otras circunstancias personales me impiden escribir y programar. En esta tercera parte del capítulo 6 definimos dos elementos de nuestro menú y analizamos los elementos necesarios para la configuración del juego, dejando las puertas abiertas a las funciones para la próxima entrega que pondrá fin este capítulo.

Puesto que el menú de configuración de juego además de ser más complicado, es el paso previo a entrar al juego en si, seguiremos diseñando el apartado de instrucciones y créditos. Estos dos apartados serán muy sencillos, básicamente mostraran texto y esperaran a que el usuario interactue para volver al menú principal.

while Juego.Menu == 3 do
 screen:clear()
 screen:print(10,10,”Este juego...”, Azul)
 screen:flip()
 screen.waitVblankStart()
end

while Juego.Menu == 4 do
	screen:clear()
	screen:print(10,10,”Parejas por Francisco M.C.”, Azul)
	screen:print(10,10,”Sitio Web: http://fmcdev.es”, Azul)
	screen:flip()
	screen.waitVblankStart()
 end

Como veréis he obviado gran parte del código en lo que el mostrado del texto se refiere, pero lo podéis encontrar completo en los archivos fuente.

Pasamos ahora al menú de configuración del juego, en el que se elegirá el modo y los parametros que se asocien al mismo. Recordemos que en el ámbito de este curso el juego tendría tres parametros que el jugador definirá para configurar la partida de la forma que prefiera: limite de movimientos, limite de tiempo, penalización por fallo. Con estas tras variaciones o funcionalidades el usuario puede crear o configurar los modos de juego que hemos comentado antes sin la necesidad de predefinirlos.

Añadiremos estas tres variables a nuestro array de Juego, ya que son los valores que definen la partida y que por tanto servirán de control del juego, objetivo del vector Juego. Sin embargo, los datos actuales de la partida como el tiempo desde que ha empezado o la puntuación, se almacenarán en un array aparte llamado Partida. Como su nombre indica en este vector se almacenarán los datos referentes a una partida concreta, por tanto será necesaria una estructura independiente que desaparecerá una vez finalice la misma.

NOTA: En posteriores capítulos nos encargaremos de almacenar las máximas puntuaciones, ello podría significar la pesistencia de estos datos, pero en ficheros externos y no dentro de la memoría.

Juego = {Estado = 0, Menu = 1, OpcionMenu = 1, Tiempo = false, TMax = 0, Puntuación = false, PuntMax = 0, Penalizacion = false, PenMax = 0}

Partida = {Tiempo =0, Puntuacion = 0} 

La estructura juego recibe dos nuevas variables por parámetro que define el juego. Esto tiene su explicación en que debemos saber si el modo está activado (variable booleana) y si lo está la configuración exacta del valor. Que el usuario pueda elegir el tiempo que tiene para acabar la partida, o la puntuación que debe alcanzar o cuanto le penalizan por cada fallo, aumentará aún más las posibilidades de juego y de personalización, algo que siempre es beneficioso.

Ya sólo nos queda programar el menú de juego. En este caso será algo más complejo que el principal pero seguirá los mismos principios. Para ahorrar código seguiremos usando estructuras array y introduciremos una de las entidades de programación más importantes dentro de la programación estructurada (y en muchos otros ámbitos) que se estudia en este curso: la función o subprograma.

Living Ps3 es una web dedicada a el mundo online de la consola PlayStation 3, es decir, se centra en su servicio PsNetwork. Además de eso, dispone de una gran comunidad de foros en la que recibir soporte, charlar o dar opinión sobre la actualidad de esta máquina. En general una web muy recomendada, en la que he comenzado a colaborar y con la que me gustaría establecer una relación duradera.

Empiezan las vacaciones, por lo que el blog estará inactivo hasta el dos de enero.

Nueva versión de este interprete de Lua para psp. En esta nueva versión se han añadido importantes mejoras sobre el zip, además de haberse reescrito parte del sistema de dialogos osk y el sistema de mensajes. Para ver la lista de mejoras lee la entrada completa.

Lista de cambios y mejoras:

[+] Added Zip file System.
[+] Wrote a new IntraFont system.
[+] Wrote a new Sony osk system.
[+] Wrote a new Sony Message Dialog system.
[+] Added Zip lua samples
[*] Updated intrafont, osk and Dialog lua samples
[*] Blit image to image fixed. (Note you need to un-swizzle your images prior to blitting or it won’t work.

Se ha abierto el wiki de LPE

Segundo artículo de la serie en la que explicaremos las filosofía básica del juego web a un nivel más especifico pero con generalizaciones. Nos centraremos en esta filosofía y en el beneficio al videojuego Indie o Alternativo.

La filosofía del juego y su repercusión en el desarrollo indie

Tras una breve introducción acerca del mundo del juego web, debemos comenzar definiendo los principios y bases que lo conforman, es decir su filosofía para después estudiar los posibles beneficios que ofrece tanto al juego Indie como Alternativo, destacando de nuevo el papel que juegan las comunidades de usuarios en su extensión y su gran eficiencia como canal de distribución y publicidad. Cabe mencionar que existirán excepciones que más adelante puntualizaremos, pues en este capítulo nos referiremos al primer tipo de juego web que surgió y que ha evolucionado durante los años, excluyendo del mismo el MMO y las nuevas formas.

La filosofía del juego web se basa en la premisa de hacer disfrutar al jugador con conceptos originales implementados con un sencillez extrema, reduciendo su uso a una muy reducida serie de controles. El porqué es sencillo: el usuario que se dedica a jugar en su navegador en general lo hace por un tiempo limitado, por un desinterés en juegos de mayor complejidad o por no disponer de una máquina potente para jugar. Se podría decir que es el perfil de un jugador casual, que busca diversión sin parafernalias técnicas.

Así la mayoría de juegos desarrollados para funcionar en el navegador no dedican apenas tiempo en exponer un argumento, sino que el concepto del juego cobra el protagonismo desde el primer momento, concepto que además será sencillo ya que si el usuario no puede disfrutar sin complicaciones excesivas del juego en toda su funcionalidad, este no dudará en cerrar la pestaña sobre el que está funcionando y seguir buscando otro que se ajuste más a lo que busca o al tiempo del que dispone.

Por tanto ya hemos encontrado la que quizás sea la principal premisa a día de hoy en el juego web: la sencillez. No puedo evitar especificar “a día de hoy”, puesto que lo que el futuro parece deparar es una mayor integración de las funcionalidades de los ordenadores en el navegador y con ellas los videojuegos. También es evidente que al ritmo al que avanzan las velocidades de linea y dadas pruebas de lo que clasificamos como juegos navegador-discoduro, los videojuegos web ganarán en complejidad progresivamente. Sin embargo, ese momento aún dista considerablemente del actual.

Esta sencillez de la que hablamos es posiblemente la principal motivación que tiene un jugador para hacer uso de su navegador y la web como plataforma de juego. En la mayoría de desarrollos del tipo de juego que nos ocupa, alguno de sus apartados incluirá esta sencillez, puede ser en su concepto, en su gameplay, en su aspecto o en todos los apartados, pero esta será la principal herramienta para conseguir el objetivo: que el mayor número de usuarios juegue al producto resultante.

De la sencillez, del concepto reducido que podríamos calificar de simple y el poco tiempo del jugador sumado a su habitual poca paciencia (comprensible sabiendo que lo que buscan es diversión sencilla o instantánea) se deduce la fugacidad o lo efímero de este tipo de entretenimiento. La mayoría de desarrollos adquiere un tiempo de relevancia directamente proporcional al tiempo que queda publicado en las portadas de las diferentes comunidades, así tiene un tiempo de vida bastante corto que una vez vencido lo condenará al uso esporádico de algunos jugadores más dedicados.

Estos tiempos de vida tan corto favorecen la aparición de modelos o mecánicas predefinidas que al final resultan en productos en apariencia nuevos pero que no son más que leves mejoras de los anteriores. De esta forma se evita que el tiempo de desarrollo anterior se realice en balde.

Así pues queda prácticamente descartado el juego en 3D ya que el reducido tiempo de popularidad no compensa su complejidad de desarrollo y no reporta demasiados beneficios. Otro motivo es que pese a que la velocidad de las lineas ha aumentado, los precios de mantenimiento del hosting siguen estando presentes y a mayor tamaño del juego, mayor gasto por la carga del mismo reduciendo el ya de por si reducido margen de beneficio. Sin embargo, esto no ha impedido que aparezcan iniciativas interesantes, la mayoría campañas de publicidad todo sea dicho, centradas sobretodo en simples y poco jugables juegos de conducción, shooters y algún que otro RPG.

Debemos puntualizar que la argumentación antes expuesta no es válida para juegos Massive Multiplayer Online (MMO) tratándose estos como un aparte dentro del juego web por sus peculiaridades como por ejemplo la necesidad de una dedicación constante. También debemos tener en cuenta el caso del emergente pero aún poco eficiente y atractivo juego convencional por web. Estos juegos intentan llevar al navegador videojuegos que convencionalmente se cargan en el disco duro por su enorme tamaño, más adelante dedicaremos tiempo a este tipo de desarrollo.

La web ofrece una gran plataforma de popularización y distribución a los desarrolladores indie y a los aficionados, convirtiéndolos en los pioneros de la distribución digital. Esto permite que entorno a juegos específicos de estos grupos de desarrollo más modestos se conformen comunidades de fieles y colaborativos usuarios que ayudan y empujan a los proyectos a llegar a buen puerto. Entre las posibilidades que ofrece internet está el juego por web: por su sencillez permite mostrar conceptos que atraigan a los usuarios a la compra.

Una simple prueba de concepto en web a modo de demostración puede ser jugada por miles de usuarios (gracias a las comunidades que generalmente publican los mismos juegos con escaso tiempo de diferencia) y por tanto tiene un gran potencial propagandístico. Este hecho ofrece la posibilidad de crear campañas publicitarias con el mínimo gasto de adaptar una parte del juego a la jugabilidad del navegador, algo sumamente atractivo para compañías que suelen tener presupuestos modestos.

Cabe puntualizar que el éxito de las campañas dependerá de si la demostración adaptada a la web ofrece una experiencia similar al producto final y de como se realice la publicación de la misma. Incluso en el supuesto de que la campaña no remita compradores, (factores como la situación económica, el método de pago o la relación calidad/precio pueden acabar de golpe con el efecto llamada conseguido por la demostración) cada jugador que haya jugado a la versión reducida y adaptada es un potencial comprador futuro que conocerá a la empresa y la tendrá más presente en un futuro.

Se han visto varios casos de videojuegos indie, sobretodo los desarrollados para moviles con pantallas táctiles que permiten nuevos conceptos, en que tras una campaña web con demostraciones flash, shockwave y java han conseguido llegar a un gran número de usuarios y aumentar notablemente sus ventas. Quizá el mejor ejemplo sea Draw Race, un original juego para Iphone que decidió publicar una versión demo en flash y que consiguió aumentar las ventas dado que fue jugado por muchos más potenciales compradores.

No podemos olvidar que dentro del juego web, la mayoría de ellos son desarrollos alternativos de grupos desinteresados, básicamente desarrolladores alternativos sin más objetivo que hacer disfrutar a la gente. De nuevo encontrarán en las herramientas de creación disponibles para el navegador una gran forma de crear grandes juegos de forma fácil y con una extensión superior. Y es que en general alrededor de todo el juego alternativo e indie, sea cual sea su expresión, la comunidad es un factor clave para su éxito.

Como conclusiones acerca de la filosofía del juego por web encontramos la sencillez y la diversión como atributos por excelencia, sobretodo para un público de corte más casual. Este hecho no quita que siga evolucionando hacía conceptos cada vez complejos, llegándose a ver en la actualidad videojuegos que poco tienen que envidiar a los convencionales. Sin duda, otra de las grandes ventajas del juego por web es que a conexiones de velocidad suficiente ofrece diversión casi intantanea, sin embargo, aún encontramos fuertes limitaciones debido a los costes de servidor y las habitualmente insuficientes velocidades de subida. La gran comunidad que tiene a las espaldas el juego web en conjunción con la sencillez y la facilidad que ofrece para crear juegos originales y divertidos, hace que sea una gran opción para publicitar y extender juegos indie, habiendose creado campañas de éxito gracias a demostraciones de este tipo.

]]> http://fmcdev.es/blog/2009/12/10/jugando-en-el-navegador-ii/feed/ 0 http://fmcdev.es/blog/2009/12/03/en-defensa-de-los-derechos-fundamentales-en-internet/ http://fmcdev.es/blog/2009/12/03/en-defensa-de-los-derechos-fundamentales-en-internet/#comments Thu, 03 Dec 2009 14:34:55 +0000 FMC http://fmcdev.es/?p=334 Este blog, y yo personalmente como su redactor, se suma al manifiesto: En defensa de los derechos fundamentales en Internet.

Manifiesto: En defensa de los derechos fundamentales en Internet

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de Internet manifestamos nuestra firme oposición al proyecto, y declaramos que:

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

Si estas de acuerdo con su contenido, ayuda extenderlo.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.