Para poder contestarla, aprovecharemos que sabemos los procesos que debe realizar nuestro juego y así poder comparar que ventajas ofrece cada una de las posibilidades a nuestra disposición para implementarlos. Las ventajas las mediremos como la cantidad de trabajo y la eficiencia, que no tienen porque estar relacionadas. Medir el volumen de trabajo se basará en determinar cuanto trabajo no relacionado con el juego en si, sino a nivel de tecnología, debemos realizar. La eficiencia se basará en ver en que sistema funcionará más rápido nuestro juego, considerando que funcionarian en la misma máquina.

El primer proceso que se realizaba en nuestro bucle era la lógica de interacción con el jugador, es decir, controlar el input de los diferentes dispositivos de control. En este caso evaluaremos si el sistema bajo el que queremos desarrollar nos ofrece los mecanismos necesarios para recibir las pulsaciones de los dispositivos de control que necesitemos para nuestro proyecto. En este caso la velocidad no será tan importante ya que prácticamente dependerá totalmente del dispositivo en si.

El segundo proceso es la lógica del juego. Para desarrollar este proceso necesitamos operadores lógicos para comprobar condiciones, además del resto de mecánismos de programación que debe incluir cualquier lenguaje moderno. En este caso la velocidad pueda que dependa de la naturaleza del lenguaje, por ejemplo, un lenguaje interpretado de scripts no puede ejecutarse a la misma velocidad que uno compilado. Entre lenguajes de la misma naturaleza las diferencias de eficiencia serán mínimas, y muy poco representativas en comparación con otras tareas como el dibujado.

El tercer proceso era la lógica de representación, que en nuestro modelo genérico la dividimos en representación grafica y sonora. El proceso que más recursos consume es la representación gráfica, ya sea en 2D o en 3D, en concreto la operación de pintado. Gran parte de la eficiencia de un videojuego vendrá determinada por la eficiencia gráfica, que limitará el número de ciclos por segundos. Por tanto, determinar que lenguaje ofrece las mejores herramientas de pintado (si las ofrece) será importante para poder añadir el máximo de elementos a nuestro juego. En cuanto al sonido, también tiene un impacto importante, sobretodo en consumo de memoria al igual que los mapas de bits, la eficiencia del cual depende en gran medida del sistema que se implemente. En este caso no bastará con saber si un sistema nos permite reproducir sonido, sino que sistema nos ofrece el conjunto de herramientas que más se ajuste a nuestras necesidades, no es lo mismo reproducir una canción de fondo que un gran grupo de efectos de sonido y una banda sonora.

Otro aspecto que no está directamente relacionado con el juego, es la facilidad de portar el videojuego a otras plataformas. El poder portarlo con el mínimo esfuerzo es una característica muy deseable que normalmente se implementa a partir del engine o frameworks que permiten abstraer las caracteristicas tecnológicas del propio desarrollo de la lógica de juego y el renderizado.

Por último, deberemos tener en cuenta nuestros conocimientos sobre los diferentes sistemas que barajamos, y en caso de que sean limitados, ver si la curva de aprendizaje y el tiempo que nos llevará llegar a los conocimientos necesarios es aceptable dadas las características de nuestro videojuego.

Por tanto, cuando elelijamos las herramientas para implementar nuestro videojuego deberemos tener en cuenta su eficiencia, la portabilidad, si dispone de librerías para el renderizado de gráficos y la reproducción de sonido, los diferentes dispositivos de control que puede procesar y por último la curva de aprendizaje o nuestras conocimientos sobre esas herramientas.

Siguiendo la primera linea vamos a explicar las características positivas que los pedagogos han deducido tras ver videojuegos en movimiento, y por supuesto jugarlos. Debemos tener en cuenta que hasta este punto consideramos juegos que no han sido creados con la idea de ser pedagógicos ni beneficiosos, sino que estas características se pueden considerar comunes y propias de los videojuegos de géneros similares.

La interfaz de juego más habitual es la compuesta por un mando controlado por las manos y una pantalla que envía información visual. Esto establece una conexión directa entre la mano y los ojos de forma que para conseguir el objetivo se deberán coordinar con la mayor precisión posible. La coordinación oculomanual no es precisamente trivial, la destreza y habilidad de nuestras manos dependen de ella, y las situaciones en que hacemos uso de las manos son incontables. Típicamente esta coordinación se mejoraba practicando deportes que hace uso de pelotas o similar, no es difícil ver que entre estos deportes y los videojuegos hay bastantes nexos de unión en cuanto a reacciones requeridas por parte del jugador. Siguiendo esta linea, encontramos que al jugar debemos identificar los diferentes componentes del mundo del juego eso implica que a mayor agudeza visual y capacidad para distinguir colores y objetos en movimiento, mayor capacidad para entender el mundo del juego y conseguir los objetivos.

La mayoría de los juegos de acción, conducción (género también conocifdo como velocidad) presentan mecánicas de juego muy rápidas donde el jugador debe reaccionar en tiempos muy reducidos. Para poder responder a tiempo el jugador debe tener unos reflejos mínimos, es decir, reducir su tiempo de reacción al máximo para aumentar sus posibilidades para conseguir el objetivo. Pero con responder más rápido no basta, también se debe responder bien, esto lleva la necesidad de buscar soluciones a ciertas situaciones de forma rápida y a veces esto implica desarrollar una táctica en un tiempo reducido. Complicando más aún al jugador, aunque desarrolle una táctica que le permita deshacerse de todos los problemas, todavía le falta el paso crucial, llevarla a cabo y para ello deberá realizar sus movimientos con gran precisión, y como no, a la velocidad apropiada. Esto se traduce en una mejora de la motricidad fina, movimientos de pequeños grupos musculares como pueden ser las manos, la cara y los pies, en este caso principalmente las manos.

Siguiendo con aspectos motrices, durante los últimos años (principalmente desde el lanzamiento de Nintendo WII) se han popularizado nuevos tipos de control basados en el movimiento del usuario. Estos requieren posturas y movimientos de cada vez más partes del cuerpo al mismo tiempo y de forma coordinada. Por tanto, tenemos que fuerzan a que el usuario trabaje con grupos grandes de músculos en posturas concretas, es decir trabaja la motricidad gruesa. Conscientes de que cada vez se puede hacer que el usuario interactue con más partes de su cuerpo han llegado a aparecer juegos que se encargan de mejorar esa motricidad y el estado de forma de los jugadores.

El trabajo en equipo también es importante en el desarrollo intelectual de cualquier persona. Así muchos videojuegos presenta retos de mayor envergadura que no se pueden acometer de forma individual. Estos juegos suelen ser del género RPG o RTS, aunque también en algunos de acción aunque no suela ser imprescindible el juego en grupo, que además suelen exigir una estrategia conjunta para el grupo, lo que implica una comunicación de igual a igual en el que se deberán discutir las ideas para obtener una estrategia común que convenza a todos los miembros del grupo o que al menos no tenga argumentos en contra. Si fallase esa estrategia común, se volvería a la comunicación para comentar los errores, de forma que no se vuelvan a cometer. Aquí entra otro beneficio de este tipo de videojuegos, que se trabaja con un volumen de información acerca del mundo enorme, y conocer esa información realmente supone una ventaja. Eso implica que el jugador memorizará gran parte de la información del mundo, mejorando poco a poco y sin darse cuenta, su memoria y sus métodos de memorización.

Una de las características con más potencial es que los videojuegos mejoran la voluntad de superación personal de forma que si un juego tiene la calidad necesaria el jugador no lo abandone hasta que no haya completado los retos que incluye. Esto a veces lleva una gran cantidad de horas de juego (sobretodo en RPG o MMO) en los que el jugador prueba una y otra vez diferentes estrategias. Eso lleva también a una mejora del pensamiento divergente, ya que el jugador al fracasar tras efectuar una táctica sobre una estrategia, tiene dos opciones, o seguir intentandolo o pensar nuevas soluciones que le permita llegar al problema. Sobre la voluntad de superación hay una relación con el resto de beneficios, el usuario desea obtener las habilidades que le permitan superar el juego (esto incluye las habilidades consideradas beneficiosas pedagogicamente) debido a su voluntad de superación personal. Por ejemplo, el jugador no pensaría soluciones alternativas a un problema si no tuviese voluntad de superación, ya que sin ella, en los primeros fracasos lo dejería sin dedicarle mayor esfuerzo.

Por último, debemos tener en cuenta que los videojuegos presentan un mundo, y que ese mundo en ocasiones es una modelización del mundo real o similar. En esos mundos fictiocios donde se imita la realidad, muchas veces se presentan principios o ideas a través de la conducta de las entidades que intervienen o simplemente por el propio contexto del mundo. Esto presenta un doble filo: si las conductas son buenas o socialmente aceptadas se puede considerar un beneficio, pero si son malas y de dudosa moral pueden ser perjudicial. Este es un problema propio no sólo de los videojuegos sino también de otro tipo de obras como la literatura, el cine o la música. La solución pasa por dejar claro que es una obra ficticia y que tan sólo deberían ser disfrutada por aquellas personas que tengan claro eso. Hasta ciertas edades es muy díficil que la gente no se vea afectada, por eso una práctica habitual es la creación de códigos de control de edad en función de los contenidos que permiten a los tutores legales determinar que obras son apropiadas para sus hijos (aunque muchos ni siquiera los tengan en cuenta).

En conclusión, un videojuego puede ser beneficioso en términos pedagógicos en muchos aspectos que se podrían clasificar en mejoras de las habilidades motoras o mejoras de las habilidades intelectuales. Cada característica se presenta en diferentes géneros de videojuegos en general, aunque algunas dependen del contenido del propio juego como son la transmisión de principios o conductas socialmente aceptadas. Por último, se debe tener en cuenta que este análisis se ha realizado sobre juegos que no han sido directamente desarrollados con la intención de incluir esos beneficios, sino que son propios del gameplay sin más. El problema al que haremos frente será precisamente el de crear un videojuego pedagógico y educativo que no pierda su esencia como videojuego, intentaremos darle solución partiendo de la idea de que podemos controlar que información llegará al usuario y por tanto procesará.

La estructura del código de un videojuego presenta un esquema básico que se aleja en cierta forma del de otro tipo de software. Este esquema es fácil de deducir si tenemos en cuenta las particularidades de un videojuego. También se comentarán las posibles diferencias respecto a un programa habitual de escritorio.

En primer lugar debemos tener en cuenta que un videojuego representa un mundo con sus propios normas. Este mundo se representa por una serie de atributos con diferentes estados, de forma que en cada frame (cambio de estado representado en pantalla) este conjunto de atributos en conjunción forma el estado del mundo. El estado del mundo sólo podrá cambiar según un conjunto de normas establecidas durante el diseño del gameplay, que se denominan lógica de juego. Además otro aspecto clave es que el estado se debe actualizar n veces por segundo mostrando así n frames por segundo (fotograma/segundo).

En segundo lugar, está la interactividad con el usuario, cuyo alcance también se especifica junto con el gameplay. De hecho, la interactividad es la seña de identidad de los videojuegos respecto de otras artes y productos de ocio, una obra que cambia en respuesta a las señales que recibe de los usuarios. Así, un subconjunto de las entidades del mundo debe responder a los estimulos del usuario según la lógica de juego. Esto se realiza mediante el chequeo del input de los controles.

Entiendase por entidad un elemento que conforma el mundo y que se comporta según las normas del mismo. Podemos decir que el mundo se conforma de un serie de entidades con atributos y comportamiento, que además interactúan con el mismo según las normas de la lógica de juego y los propios atributos del mundo. Así estas entidades también deberán actualizar su estado en cada frame. El comportamiento de una entidad viene dado por las normas del mundo y sus propias normas de cambio de estado. Las entidades que son capaces de responder a los estímulos del usuario de una forma coherente con las normas del mundo y sus propias normas, se dice que tienen una inteligencia artificial (IA). Así en cada frame se deberá actualizar el estado de las entidades.

Por último, el usuario debe recibir una representación del mundo por los dispositivos de salida que comprenda el estado y pueda interactuar de forma que consiga acometer los objetivos del juego. Las formas más usadas (prácticamente siempre) para representar el mundo son la información visual (render en pantalla) y la sonora (reproducción de sonidos por los altavoces).

Ahora que ya sabemos que procesos básicos realiza un videojuego, podemos pasar a estructurarlo. En primer lugar se comprobará la interacción con el usuario. Después, la lógica de juego actualizará los atributos del mundo y sus entidades según la interacción con el usuario. Una vez se haya actualizado el estado del mundo, se presenta al usuario por los dispositivos de salida (render de gráficos, sonido, vibración). Este esquema se repite hasta que la ejecución del juego finaliza.

En conclusión, la estructura básica de un juego suele presentar un bucle principal que se repite hasta que termina el juego, en el que se realizan las tareas antes comentadas. A este bucle se le denomina game loop:

Mientras juego_en_ejecucion hacer
comprobar_input_jugador;
logica_de_juego;
render_gráficos; reproducción_sonidos;
fin_mientras;

Esta estructura contrasta con la estructura de un programa de escritorio habitual en que diferentes componentes responden a eventos generados por el sistema operativo, y salvo que se realicen proceso de background, estos componentes no cambian su estado sin los eventos. Además los videojuegos son un tipo de software muy exigente en cuanto a recursos, ya que estas tareas se deben repetir (el render 3D es muy costoso) n veces por segundo, y a veces conseguir ese frame rate es todo un desafío que recae principalmente en la tecnología.

No todos los juegos necesitan esta estructura, existen casos en los que el mundo sólo debe ser actualizado si el usuario realiza una interacción (genera un evento dentro del videojuego). Este es el caso del tres raya, ya que el tablero (mundo) sólo cambia cuando el jugador pone una nueva pieza, sino no pasa nada. Podemos pensar que si limitamos el tiempo ya no estamos en ese caso, sino que volvemos a necesitar un gameloop en el que se compruebe a cada ciclo si se ha cumplido el tiempo, o este evento podría venir dado por el lenguaje. De todas formas, debemos tener en cuenta que aunque el juego no sea el que comprueba si se han producido eventos, hay un componente de software a un nivel de abstracción inferior que lo hace, la única diferencia es que el proceso es transparente al videojuego que sólo deberá preocuparse cuando le avisen de que ha ocurrido un evento. Por tanto, al final todas las tareas comentadas anteriormente siempre se realizán ya sea en un loop general o en diferentes componentes de software.

Analizando un ejemplo: El Tetris

Para ver lo comentado vamos a analizar un ejemplo conocido ya por cualquier jugador, el tetris.

Empezamos nuestro análisis determinando el mundo, que en este caso, es la matriz de cuadrados en la que se colocan las fichas. Las entidades del mundo son las fichas, que se comportan según una norma del mundo que dicta que deben caer a una velocidad proporcional al nivel en que se juega. Las normas del mundo dictan que cuando en una linea horizontal de la matriz todas los huecos están ocupados por piezas estas desaparecen sumando puntuación, y si alguna pieza no puede entrar completamente en la matriz la partida acaba. La normas de juego se pueden expresar como operaciones lógicas o de cambio de estado.

La interacción del jugador afecta a la lógica del juego de forma que la entidad que está cayendo cambia su posición según las teclas establecidas. Si se pulsa a derecha, la ficha se debe mover a la derecha (o hacia donde se decida), si se pulsa otra tecla que afecta al gameplay se procesará de la misma forma. Esta interacción se ha definido sobre un paradigma tradicional de comando físico con botones, actualmente hay versiones de tetris táctiles o por acelerometro por ejemplo.

Por último, la presentación al jugador se dividirá en gráficos y sonido. El render de los gráficos se realizará en 2D, se deberán dibujar las entidades (piezas, fichas) y la matriz del mundo, además de otros elementos de feedback al usuario como mostrar la puntuación o el nivel. El sonido consistirá en la música de fondo, más los sonidos al acoplas piezas o a completar piezas.

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.