Libros sobre desarrollo de videojuegos

Una recopilación de libros sobre Diseño y Desarrollo de videojuegos. Guión, Arte, Programación, Marketing... Tanto libros gratuitos en PDF como libros comerciales desde Amazon.

Sección de Documentales y Vídeos

Documentales, Making Offs, Reportajes, Conferencias y Entrevistas. Todo ello relacionado con los Videojuegos y o el desarrollo de los mismos. Enfocados principalmente al mundo Indie.

Cursos para crear Videojuegos

Aprende a crear Videojuegos con cursos de Diseño, de Dibujo, de Modelado y Animación, y de programación con diferentes motores y lenguajes. Ya no tienes excusa, ¡Crea!

Mostrando entradas con la etiqueta Artículos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Artículos. Mostrar todas las entradas

ARTÍCULOS - Formación Gratuita de Videojuegos

Artículos breves, pero muy interesantes, relacionados con el mundo del desarrollo de videojuegos. Todo ello disponible de forma gratuita en el blog del centro de formación Gametopia Learning; empresa que además, ofrece cursos muy completos de pago.
"Gametopia además, cuenta con diferentes cursos a precios muy módicos en los cuales te enseñan todos los entresijos del octavo arte"






Ir al blog: Artículos gratis


    Los artículos sobre desarrollo de videojuegos de Gametopia son de gran calidad, la mayoría de ellos firmados por Daniel González, profesor de Gametopia y todo un experto en guión y diseño de videojuegos, con varios libros publicados.

Nos son artículos muy amplios, sin embargo dan las pinceladas principales para que puedas seguir profundizando a partir de una buena base.
Los artículos tratan temas como, guión de videojuegos, diseño, programación, advergaming,  gamificación, marketing, etc...

ARTÍCULO - Conceptos Básicos para Desarrollar videojuegos 2D

Buscando libros sobre videojuegos me he encontrado con este minilibro, que por corto lo voy a llamar artículo. Pero en este caso, el tópico de que los buenos perfumes se venden en frascos pequeños, le va como anillo al dedo. Y es que nos habla de cosas que muchas veces damos por sentadas, pero que a veces están de pie. Nos habla de pixels, resoluciones, bits, monitores y tarjetas de vídeo, entre otras cosas.

"Si estás empezando a diseñar videojuegos, comienza con proyectos 2d, asimilar los conceptos es más sencillo. Ya saltarás al 3d..."








Escrito por: Roberto Albornoz Figueroa




   Una de las razones para comenzar a desarrollar primero videojuegos 2D, es que los conceptos involucrados son mucho más simples y fáciles de asimilar.
Además lo más probable es que varios de estos conceptos ya sean conocidos por quienes lleven un tiempo programando o trabajando con computadores.

Otra ventaja, es que obtendremos resultados más rápidos, a diferencia del desarrollo de videojuegos 3D, que involucra conocer tópicos más avanzados de matemáticas y de programación. Pero tampoco hay que asustarse, si queremos luego dar el próximo paso a las 3D, ya que hay que recordar siempre que todo lo podemos estudiar y aprender, nada es imposible.

En las próximas páginas conoceremos la terminología básica, que nos hará comprender de mejor forma los conceptos gráficos involucrados en un videojuego."

ARTÍCULO - Técnicas de guión aplicadas a videojuegos

Muchas veces, en el mundo de los videojuegos, el guión puede ser sacrificado, e incluso descuartizado, quemado, enterrado y rociado con agua bendita; todo porque los diseñadores han pensado en la jugabilidad relegando la historia a un segundo plano y o encajándola con calzador a posteriori, lo cual hace que el resultado final tenga lagunas por todas partes. Tampoco es bueno crear primero una historia y forzar una determinada jugabilidad para ella. 
Guión y jugabilidad deben nacer juntos, como unos gemelos siameses unidos por el dedo gordo del pie. Deben complementarse y completarse mutuamente. No olvidemos que lo que nos sumerge en el universo de un juego es la profundidad de su historia, y lo que nos hacer vivir en su interior es jugabilidad. Ambas cosas forman un todo: una experiencia de juego satisfactoria. 
Paranoias a parte, en esta entrada hablaremos de la parte de Guión. De diferentes técnicas que pueden ser empleadas para mejorar nuestras historias. 
"Aprender a escribir es clave para ser un buen diseñador de videojuegos"





Artículos escritos por: Javier Arche Canales
Sitio Original: CreadorVj



    Javier Arche es lo que yo llamaría un diseñador de videojuegos todoterreno, ya que posee conocimientos de todas las áreas que componen el desarrollo de un videojuego. Es un tipo que absorbe información como nosotros absorbemos aire y que continuamente expande sus conocimientos, y lo que es más importante: los comparte para que nosotros también podamos aprender. 
Una de las cosas que más me gusta de su blog es la sección de guión y en concreto su serie de artículos llamada "Técnicas de guión aplicadas a videojuegos", por la forma que ha tenido de extrapolar sus conocimientos sobre guión de cine y animación a los videojuegos. 

Sin más dilación, pongo a vuestra disposición los enlaces de cada uno de sus artículos al respecto, y os animo a visitar su blog y a seguirlo,  para continuar nuestro aprendizaje en este fantástico mundo de la creación de videojuegos.

Técnicas de guión aplicadas a videojuegos














ARTÍCULO - Por qué elegir el lenguaje C#

Si te has planteado aprender a programar, seguro que la primera duda que te ha surgido es el lenguaje a escoger. Yo, tras pensarlo mucho, decidí escoger C# y a continuación expongo las razones.

"Aunque tu objetivo sea ser diseñador, aprender un poco de programación te ayudará a entender las limitaciones técnicas para implementar lo que imaginas"







Artículo escrito por: Asensio López Fernández


   Sin duda el principal motivo para elegir aprender a programar con C# (pronunciado Si Sharp), es que se trata de un lenguaje de programación orientado a objetos.
Mucha gente anima a que se empiece aprendiendo con un lenguaje estructurado, y luego se pase a la programación orientada a objetos, pero otros tantos opinan que si primero aprendes con un lenguaje estructurado será más confuso a la hora de pasarte a la programación orientada a objetos, ya que son conceptos diferentes. Yo personalmente he elegido C# y la programación orientada a objetos porque me parece más sencillo.

    C# es un lenguaje diseñado por Microsoft para generar programas sobre la plataforma .NET. Es fruto de una evolución que partió con el nacimiento de C, que era un lenguaje en el que se trabajaba con programación estructurada, luego apareció C++ que ya permitía la programación orientada a objetos, y por último la evolución dio lugar a C#. Este último coge lo mejor de diferentes lenguajes de programación como C++, Visual Basic, Java o Delphi y lo mete en una coctelera, dando como resultado un lenguaje que combina a partes iguales potencia y sencillez. De este modo, además facilita la migración de los programadores de estos otros lenguajes a C#. En definitiva se trata de un lenguaje moderno, intuitivo y muy eficiente, que mejora la productividad en el desarrollo de software. Además es el lenguaje de la plataforma .NET con más y mejores ejemplos; es más, la propia plataforma fue desarrollada con este lenguaje.

Mucha gente elige otros lenguajes de programación alegando que las aplicaciones creadas con C# solo corren bajo la plataforma .Net, pero nada más lejos de la realidad. Hoy en día, gracias al  “proyecto Mono", se pueden compilar programas C# en plataformas como Linux, Mac o incluso Android, por lo que no veo un motivo por el cual renunciar a las mejoras que nos ofrece C#.

Además, se puede programar con lenguaje C# en Unity3d. Unity es un Game Engine de los más potentes e intuitivos del mercado; permite crear juegos para Windows, Mac, Xbox360, Playstation 3, Wii, Ipad, IPhone y Android. Además, también se pueden desarrollar juegos para navegador web con tecnología HTML5.

La plataforma .NET

La plataforma .Net es un conjunto estandarizado de conceptos y prácticas (framework) diseñada para que se puedan desarrollar componentes sobre software utilizando casi cualquier lenguaje de programación, de forma que lo que escribamos en un lenguaje pueda utilizarse desde cualquier otro de la manera más transparente posible. Esto es, en vez de estar limitados a un único lenguaje de programación permitirnos cualquier lenguaje de programación, siempre y cuando se adhiera a unas normas comunes establecidas para la plataforma .NET en su conjunto. De hecho existen compiladores de múltiples lenguajes para la plataforma .NET.
Nace como una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java y a los diversos framework de desarrollo web basados en PHP. Su propuesta es ofrecer una manera rápida y económica, a la vez que segura y robusta de desarrollar aplicaciones, permitiendo una integración más rápida y ágil entre empresas, con un acceso más simple y universal a todo tipo de información desde cualquier tipo de dispositivo.

El proyecto Mono

Se trata de un proyecto de código abierto basado en GNU/Linux y compatible con .NET, que consta de un grupo de herramientas que permiten desarrollar fácilmente aplicaciones para Linux con lenguajes basados en .NET como C#. Como mencionaba anteriormente, gracias al proyecto mono se pueden compilar programas C# en plataformas como Linux, Mac o incluso Android.

-¿Qué es un IDE?

Un IDE o “entorno de desarrollo integrado” básicamente es un programa que nos facilita la tarea de escribir, depurar y compilar código. Por poder podemos programar incluso con un editor de texto como notepad, pero obviamente un IDE nos va a facilitar mucho la tarea.

Visual Studio es el IDE que proporciona Microsoft para programar en su plataforma. La versión Community es totalmente gratuita.y es más que suficiente para crear cualquier tipo de programa, pudiéndose incluso vender sin tener que pagar nada a Microsoft.

Además de Visual Studio existe MonoDevelop (y otros), que es un IDE libre para el proyecto mono, que nos permite compilar programas en otras plataformas.

Podéis descargar la versión gratuita de Visual Studio en la página oficial: AQUÍ

Y con Monodevelop (ahora llamado Xamarin) tres cuartas de lo mismo, podéis descargarlo: AQUÍ 


ARTÍCULO - Los pilares de la programación orientada a objetos

En este artículo vamos a tratar de explicar brevemente qué es la programación orientada a objetos (POO) y por qué se ha convertido en la más popular, relegando a las antiguas formas de programar a un segundo plano. Cabe destacar que la POO no es un lenguaje de programación en si, sino una forma de afrontar la programación. Hoy en día existen muchos lenguajes que soportan este tipo de programación y algunos han sido creados especialmente para ello, pero remarco que, este método de programación no es una obligación, es una elección: la elección acertada.

"Lo que vemos en el mundo real son objetos, cosas. Así que, sin duda, la mejor manera de programar es partiendo de esa simple base"








Artículo escrito por: Asensio López Fernández

    La programación orientada a objetos se ha convertido en la más popular debido a sus grandes capacidades y ventajas respecto a las antiguas formas de programar. Básicamente, este tipo de programación nos permite crear auténticos objetos, que pueden ser cosas que aparecen en la pantalla, como botones o ventanas, o bien pueden ser objetos de la vida real, como una persona o un lápiz. 

Estos objetos poseen características que es lo que llamamos propiedades o atributos, como pueden ser: edad, velocidad, temperatura, color, altura, etc... 
También tienen capacidades, cosas que pueden hacer, a esto lo llamamos funciones o métodos, como pueden ser: andar, golpear, acelerar, envejecer…
Y pueden pertenecer a clases. Una clase es la definición de los elementos de los que está compuesto uno o varios objetos de un mismo tipo. Por ejemplo, mi padre tiene tiene una serie de características como son: ojos, nariz, boca, brazos, piernas, lo cual nos dice que pertenece a la "clase persona". La función de una clase en POO es la de definir las características y funciones de los que están compuestos los objetos de un mismo tipo.

A varios objetos de una misma clase de les llama instancias de esa clase. Por ejemplo, imaginemos que tenemos una clase que se llama coche, los objetos Ferrari F40 y Toyota Corolla serían instancias de esa clase. La clase coche marcará las características principales que tiene cualquier coche, y que compartirán todos los objetos/instancias que pertenezcan a esa clase.

 Los tres pilares del desarrollo orientado a objetos son la encapsulación, la herencia y el polimorfismo. Si... ya veo que en la imagen aparece también abstracción... no seas cansino.
La abstracción: 

Mucha gente considera que la abstracción en si no es más que una parte del proceso de la encapsulación, y por tanto no la tienen como  pilar independiente de la POO.

La abstracción es la capacidad de obtener y aislar toda la información y cualidades de un objeto que no nos parezcan relevantes, para poder encapsularlos. Para ello separamos "mentalmente" los objetos y nos centramos en su comportamiento fundamental. 
Gracias a ello, podemos representar las características esenciales de un objeto sin preocuparnos de las restantes.
Pongamos el ejemplo de un objeto llamado gato. El gato tiene propiedades o características (nombre, color, peso, precio, edad..) y métodos o comportamientos (andar, maullar, lamerse las pelotas...)
Gracias a la abstracción, otro objeto, por ejemplo el "objeto vendedor" puede manipular el "objeto gato" sin tener en cuenta algunas de sus propiedades y métodos, ya que solo le interesan  algunas, como el precio.

Poniendo un ejemplo de videojuegos. Si creamos un juego de coches tipo Arcade, lo único que necesitamos abstraer de un coche real serán cosas como, la forma, el color y la velocidad, por ejemplo. Pero, si queremos crear un juego de coches tipo simulador, deberemos abstraer muchas más cosas, como el peso, la potencia, el tipo de tracción, tipo de combustible, tipo de ruedas, etc...

La encapsulación: 

La encapsulación es la capacidad de ocultar los datos abstraídos,  aislarlos o protegerlos de quién no desees que tenga acceso a ellos; otro objeto o función por ejemplo. 
Cada objeto puede tener muchas cosas encapsuladas en su interior, propiedades, funciones o incluso otros objetos. 
Muchas veces no se necesita entender el funcionamiento interno de un objeto, sino tan solo sus funcionalidades: para que sirve o qué puede hacer. Por tanto un objeto puede ser cambiado por otro siempre que cumpla con la misma función.

Veamos un ejemplo del mundo real. Imaginemos que tenemos un objeto: una tarjeta de sonido. No sabemos cuál es el funcionamiento interno de la misma, sus propiedades se podría decir que están encapsuladas dentro. Lo que si sabemos es que cumple con la función de proporcionar el sonido a nuestro ordenador.  Podemos cambiar una tarjeta de sonido por otra, ya que cumplen la misma función, y no necesitamos saber nada más, a no ser que queramos trabajar para creative.

Para dejarlo aún más claro; el usuario no necesita saber cómo funciona internamente un coche, solo necesita saber que al pisar el acelerador (aplicar el método) el coche anda. 

Herencia y reutilización:


La Herencia lo que nos dice es que puede crearse una clase a partir de otra clase ya existente, heredando todas las cualidades de la clase de la que deriva y además pudiendo añadir nuevas funcionalidades o modificar las ya existentes.

Imaginemos que tenemos un ordenador con sus planos y queremos fabricar otro ordenador. En vez de crear uno de cero, sería mucho más sencillo basarnos en el ordenador que ya tenemos y añadirle o modificarle ciertas funcionalidades como podrían ser: aumentar su capacidad, su velocidad de procesamiento, etc…
Podríamos ejemplificarlo también con una clase llamada Vehículo y varias clases que heredan de ella, llamadas, moto, coche, barco, etc... Estas clases heredarían las propiedades y funciones de un vehículo, y podrían modificarlas o crear nuevas.

A la clase que se crea a partir de otra clase se le conoce como subclase o clase derivada.
En un último ejemplo, podríamos pensar en crear una clase persona, y una clase mujer que hereda todas las propiedades de la clase persona y que añade otras nuevas como las tetas, y podemos crear varios objetos de la clase mujer, como podrían ser Ana o Bernarda...

Polimorfismo:


 El polimorfismo es la capacidad para que varias clases u objetos derivados de otros, reaccionen de manera diferente ante los mismos métodos. El polimorfismo se puede aplicar tanto a objetos como a funciones, por lo que podemos hablar de objetos polimórficos y de funciones polimórficas.
Por ejemplo, cuando apretamos el acelerador de un coche no va a responder igual el que posee un motor diésel que el que tiene un motor de gasolina.

ARTÍCULO - Historia y evolución de los lenguajes de programación

No os asustéis, la palabra Historia puede sonar fuerte y a veces provoca somnolencia en quienes la escuchan. Tomen esto más bien como un “cuento” que trata de hurgar un poco en el pasado del ser humano, cuando crearon las máquinas y debieron aprender a comunicarse con ellas.
Para nada este artículo trata de ser algo estrictamente científico, nada más lejos de la realidad. Trataremos de enfocarlo como un acercamiento del público general al mundo de la informática, sin necesidad de tener ningún tipo de conocimiento previo.

"El lenguaje nos sirve para comunicarnos. Por desgracia algunas personas tienen un lenguaje bastante físico"










Artículo por: Asensio López Fernández



    Un lenguaje es un método de comunicación que nos permite comunicarnos con los demás. Si hablamos con un Inglés deberemos hacerlo en lenguaje inglés, si hablamos con un Japonés le hablaremos en lenguaje Japonés… pero, ¿y si lo que queremos es hablar con una máquina? Pues en ese caso debemos de hacerlo en un lenguaje que ella pueda entender: un lenguaje de programación.
En realidad estoy mintiendo un poco. Las máquinas solo entienden un lenguaje, el llamado lenguaje máquina, que no es otra cosa que: electricidad o no electricidad, apagado o encendido, unos o ceros. Entonces ¿no entiende los lenguajes de programación?, directamente no, primero han de ser traducidos al lenguaje máquina bien directa o indirectamente, pero vayamos paso a paso.

Origen de los lenguajes de programación:

Si las máquinas nacieron como una idea del hombre para automatizar trabajos rutinarios y repetitivos, la programación nació como un método eficaz de comunicación con dichas máquinas a modo de instrucciones.

La  primera computadora como tal, fue la “máquina analítica” inventada por Charles Babbage allá por el año 1823 y que continuó depurando hasta su muerte en 1872, por lo que se le considera “el padre de la computación”, aunque el artilugio nunca fue totalmente terminado. Se trataba de una máquina capaz de calcular tablas matemáticas, eliminando así los posibles errores humanos debidos a la fatiga o el aburrimiento que producía dicha tarea.
"Hola, soy Charles Babbage"


"Máquina analítica de Babbage















Pero fue Ada Lovelace, hija del poeta inglés Lord Byron, la primera persona que ejecutó un algoritmo para la “máquina analítica” y describió por primera vez un lenguaje de programación de carácter general interpretando las ideas de Babbage, además de solventar ciertos errores de su proyecto. Es por ello por lo que se la conoce como la primer programadora de la historia. Incluso el Ejército de los Estados Unidos llamó a uno de sus lenguajes de programación ADA, en homenaje a esta extraordinaria mujer.
"Esta máquina puede hacer cualquier cosa que sepamos cómo ordenarle que ejecute..."

Tipos de lenguajes:

-El lenguaje Máquina

El lenguaje máquina fue el primer lenguaje de programación, y es el único lenguaje que entiende una computadora. Está compuesto únicamente por unos (1) y ceros (0), es por ello que también se le conoce como lenguaje binario. Con estos dos dígitos (conocidos como bits), forma lo que se conoce como cadenas binarias, con las instrucciones que damos al microprocesador. Ejemplo de cadenas binarias:

110011001000
001001010101
111000111000

Este lenguaje es fácil de entender por una computadora, pero como podréis ver es difícilmente entendible por un humano. Es por ello que con el fin de facilitar el trabajo a los programadores se creó un tipo de lenguaje que sustituía las secuencias de unos y ceros  por palabras o letras provenientes del inglés, facilitando de este modo la lectura, escritura y posterior ejecución de los programas. A los primeros lenguajes de este tipo se les denominó lenguajes de bajo nivel.
Eso sí, una vez que se termina de escribir un programa, es necesario compilarlo o intepretarlo, es decir, volver a traducirlo al lenguaje máquina para que el ordenador lo entienda, ya que como bien he dicho al principio es el único lenguaje que entiende una computadora.

 - Lenguajes de bajo nivel

Los lenguajes de bajo nivel de abstracción, son los que están más cercanos a la forma de trabajar de un microprocesador, por lo que son fácilmente trasladados a lenguaje máquina.

El lenguaje ensamblador (Assembly) fue el primer lenguaje de programación que trató de “sustituir” el lenguaje máquina por uno mucho más parecido al de las personas. Lo que hace es sustituir las secuencias de código máquina por letras o palabras, por lo que en realidad escribir en lenguaje ensamblador es básicamente lo mismo que hacerlo en lenguaje máquina, pero las letras y palabras son más fáciles de recordar y entender que la secuencias de números binarios. Por ejemplo, para sumar se usa la letra A, de la palabra inglesa add (sumar).

La palabra bajo, no implica que el lenguaje sea inferior a uno de alto nivel, se refiere a la reducida abstracción (abstracción = grado de cercanía) entre el lenguaje y el hardware.
Actualmente se suele usar, entre otras cosas, para programar drivers. Entre sus ventajas se encuentran: mayor adaptación al equipo y mejor velocidad con un mínimo uso de memoria. Y entre sus desventajas: Mayor dificultad de comprensión e imposibilidad de escribir código independiente de la máquina.

Con el tiempo se hizo necesario simplificar aún más la tarea de los programadores, ya que la complejidad de las tareas que realizaban las computadoras iba en aumento. Así que se crearon los lenguajes de alto nivel, que entre otras cosas necesitan menos instrucciones que un ensamblador para realizar una misma tarea.

Si como hemos dicho antes, los lenguajes de bajo nivel son los más próximos a la arquitectura de hardware, los lenguajes de alto nivel son todo lo contrario: los más cercanos a los programadores.

 - Lenguajes de alto nivel

Un lenguaje de alto nivel es aquel que se aproxima más al lenguaje humano que al lenguaje binario, o lenguaje máquina. Utiliza palabras y expresiones del lenguaje humano (en inglés), por lo que al ser más fácilmente compresible por los programadores aumenta la sencillez y rapidez a la hora de crear programas, a la par que reduce las posibilidades de equivocarse.

En C# se usan palabras como: if, convert, write, etc… Ejemplo:

If (numero1 > numero2)  
 {   
 Console.Write (“gana el primero”);  
 }
Esto significa que, si el número 1 es mayor que el número 2, se va a escribir “gana el primero” en una ventana de consola.

La principal característica de un lenguaje de alto nivel es su independencia de un hardware determinado, por lo que un programa escrito en este tipo de lenguaje puede ser utilizado en distintas computadoras. Cierto es también, que la computadora debe disponer de un intérprete o compilador, que es el encargado de traducir dicho programa al lenguaje específico de cada máquina, ya que, como dije al principio,  las computadoras solo entienden el lenguaje binario o lenguaje máquina.


Cada nueva evolución en los lenguajes de programación ha traído consigo una simplificación de los mismos, por lo que, en muchos casos, varias instrucciones en lenguaje máquina pueden ser simplificadas en una sola instrucción en lenguaje de bajo nivel, y varias instrucciones en lenguaje de bajo nivel pueden ser  simplificadas en una sola instrucción en lenguaje de alto nivel.
En la actualidad existen gran diversidad de lenguajes de alto nivel (C, C++, C#, BASIC, PASCAL, JAVA, entre muchos otros)

Tipos de programación:

El tiempo hizo que los lenguajes de programación tuviesen que irse adaptando a las circunstancias cambiantes. El usuario final requería cada vez programas más potentes a la par que intuitivos y fáciles de manejar, y paradójicamente los programas sencillos de utilizar son los más difíciles de programar. A esto se sumó el nacimiento de la red de redes y la creación de nuevos dispositivos a parte de las computadoras.

Podemos dividir los lenguajes de alto nivel en tres tipos de acuerdo a su evolución y tipo de programación:
De programación de procesamiento, de programación estructurada y de programación orientada a objetos.

- Programación de procesamiento

La programación de procesamiento o programación lineal es aquella en que las instrucciones se ejecutan en el mismo orden en que han sido escritas. Se basa en una serie de procedimientos que se ejecutan uno tras otro y que actúan sobre los datos. A estos procedimientos también se les llama, funciones o métodos.

El principal problema de este tipo de programación queda en evidencia a la hora de realizar programas complejos, ya que ofrece poca flexibilidad.  Es especialmente complicado mantener una gran cantidad de líneas de código con superposición de funciones y se hace en extremo confuso para el programador..

- Programación estructurada

Con el tiempo los programas comenzaron a ser más complejos y ambiciosos por lo que la evolución lógica era la llamada programación estructurada. Básicamente en este tipo de programación lo que se hace es dividir el trabajo en partes, llamadas módulos o componentes.Esta forma de programación entiende un programa como un conjunto de tareas. Cada tarea compleja es dividida en módulos, y cada módulo complejo es subdividido en componentes. De este modo cada tarea es fácilmente entendible y puede ser mejor documentada internamente. Los módulos o componentes son ejecutados a medida que son requeridos, de este modo tenemos un diseño compuesto por módulos independientes que pueden comunicarse entre sí.

Pero este tipo de lenguaje se centra en los procedimientos (también se le llama programación procedimental), y crecía la necesidad de pensar en los datos, en lo que se puede hacer con ellos. Además se vio que  había funciones iguales que se copiaban una y otra vez en los módulos y se pensó que se podrían reciclar dichas funciones para distintas situaciones. Fue así como nació la programación orientada a objetos.

- Programación orientada a objetos

La programación orientada a objetos (POO) combina las mejores ideas de la programación estructurada con conceptos nuevos y potentes que nos hacen ver las tareas de programación desde un nuevo punto de vista: el de los objetos. Debo hacer hincapié en que no se trata de un lenguaje de programación en sí, sino de una forma de plantearse la programación, soportado por muchos lenguajes actualmente.

Se trata de una forma de programar mucho más cercana a como expresamos las cosas en la vida real; descompone los problemas en conjuntos de datos con estructura propia, que llamamos objetos. Su idea principal es llevar al mundo del condigo lo mismo que encontramos en el mundo real. Y en nuestro mundo, cuando miramos alrededor, ¿qué nos encontramos? La respuesta es sencilla: cosas, objetos.

Para entender la programación orientada a objetos debemos entender que es un objeto. En el mundo real, un objeto es cualquier cosa que vemos a nuestro alrededor, un lápiz, una televisión, un coche, etc… Podemos distinguir un objeto de otro porque son de una clase diferente, o incluso diferenciar objetos de una misma clase, como pueden ser dos coches de modelos distintos.
Un objeto puede estar compuesto por diferentes componentes, por ejemplo un coche está compuesto por: motor, radiador, frenos, ruedas, etc... Todo en conjunto forma parte del objeto coche. Internamente cada componente puede ser muy complicado y haber sido construido por distintas empresas, pero a nosotros nos basta con saber cuál es su funcionamiento y como se relaciona con los otros componentes.
Y lo mismo pasa en la programación orientada a objetos, todo el programa está construido en base a diferentes objetos, compuestos por diferentes componentes. Cada uno tiene un rol específico en el programa y todos pueden comunicarse entre sí de formas predefinidas.Me resta decir que todos los lenguajes compatibles con programación orientada o objetos deben cumplir con estos tres requisitos: Herencia, encapsulación, y polimorfismo; hay quién añade también la abstracción, pero ésta en realidad forma parte de la encapsulación.

Permítanme que no entre más en detalles sobre programación orientada a objetos en este tema, ya que redactaré otro artículo íntegramente dedicado a explicar todos los pormenores de esta forma de programar.

Intérpretes y compiladores

 Como ya dijimos anteriormente, un lenguaje de alto nivel no puede ser entendido directamente por una máquina, sino que debe ser traducido a su lenguaje, el lenguaje binario o lenguaje máquina, para que la computadora pueda entenderlo y ejecutarlo. Existen dos tipos de “traductores”: los Intérpretes y Compiladores.

Intérpretes:

El intérprete realiza la traducción del programa fuente (programa escrito en lenguaje de alto nivel) al lenguaje máquina directamente,  ejecutando dicha traducción al momento de ejecutar cada una de las instrucciones. Normalmente no guarda el resultado de dicha traducción. De este modo, el programa fuente siempre conserva su forma original, con la desventaja de que cada vez que es ejecutado debe ser traducido nuevamente. Este proceso puede hacer más lenta la ejecución del programa, por lo que los intérpretes suelen ser menos usados que los compiladores.Podríamos comparar la labor de un intérprete con la que realiza un traductor humano, que va traduciendo lo que escucha  a otro idioma en tiempo real, pero sin escribirlo ni dejar registro alguno.
"Terminator dispone de un programa interprete que traduce lo que le dice John Connor al lenguaje máquina"
Llamamos lenguaje interpretado a todo aquel que está diseñado para ser ejecutado por medio de un intérprete.Algunos de los más famosos pueden ser: PHP, ActionScript, LUA o JavaScript.

Compilador:

El compilador a diferencia del intérprete, no ejecuta el programa directamente, haciendo la traducción en tiempo real, sino que, tras analizar el programa fuente lo traduce a otro lenguaje equivalente, creando lo que llamamos un programa objeto. Para remarcarlo aún más, diré que un programa objeto es la traducción de un programa en lenguaje de alto nivel a un programa en lenguaje máquina, lenguaje que la máquina puede interpretar y ejecutar.
Una vez compilado el programa, el resultado en forma de programa objeto no puede ser directamente ejecutado. Debemos usar un programa conocido como enlazador  o linker, que combina todos los módulos del archivo objeto para formar un archivo ejecutable (un .exe por ejemplo), que ya sí que se considera un programa en sí mismo y no necesita hacer referencia al código fuente original.
Volviendo al símil del traductor humano, podríamos decir que lo que hace un compilador sería equivalente a la labor que haría un humano al coger un libro y traducirlo a otro idioma dejándolo por escrito para la posteridad.
Principales ventajas y desventajas de cada método:

- El compilador presenta la ventaja considerable de la velocidad de ejecución al no tener que traducir el programa fuente cada vez que es ejecutado.
- Usando un intérprete el programa se puede mover de una plataforma a otra más fácilmente, produciendo resultados iguales en (Windows, Linux, Mac, PS3, etc…)
- Se requiere un compilador para cada lenguaje de programación.
- En la actualizad, uno de los entornos más comunes de uso de los intérpretes es Internet, debido a la posibilidad que estos tienen de ejecutarse independientemente de la plataforma. . 

Eso es todo, espero no haberos aburrido con tanta teoría. En el siguiente artículo de programación indagaremos más profundamente en los lenguajes de alto nivel con programación orientada a objetos.

ARTÍCULO - El origen de las máquinas computadoras

Las máquinas existen desde que el hombre es hombre. Nos complementan como extensiones de nuestros propios cuerpos y nos permiten ir más allá de nuestros límites. Por ejemplo: una tenaza es una prolongación de nuestra mano que nos permite coger cosas con mucha más fuerza, una cerbatana es una extensión de nuestra boca y nos permite lanzar dardos a gran velocidad y abatir a un animal, un telescopio es una extensión de nuestro ojo, etc.…
Este tipo de máquinas que acabo de mencionar son las denominadas herramientas, que necesitan de una acción por parte del ser humano para funcionar.

"Las computadoras son una extensión de la mente del ser humano"









Artículo por: Asensio López Fernández 

    Nuestro cerebro al igual que nuestro cuerpo tiene límites, y de ahí nació la necesidad de hacer algo que nos permitiese calcular e incluso recordar. Haremos un pequeño paseo a través del tiempo parándonos tan solo en los hitos más importantes.

Al principio de los tiempos, con las primeras transacciones comerciales, el hombre tuvo la necesidad de calcular cantidades importantes de mercancía o del medio de pago utilizado. Para ello comenzaron usando el método más primitivo que se nos pueda pasar por la cabeza, hacían los cálculos a base de hacer montoncitos de piedras. Pero este método era complicado para mantener los datos y para transportarlos, fue por ello por lo que exprimieron sus primitivos cerebros e inventaron el ábaco. 
"Ábaco"
El ábaco se remonta a las civilizaciones Griega y Romana; consta de un marco rectangular en el que se montan diversas varillas. Dichas varillas contenían pequeñas piedras circulares agujereadas y ensartadas previamente. Las posiciones de las piedras representaban los valores almacenados. Sin embargo este elemento no puede ser considerado una computadora, ya que no dispone de su elemento fundamental: un programa.
Y para que veáis que no voy a ser demasiado pesado, vamos a saltar desde la época greco-romana directamente en vuelo Charter hasta la década de 1640, cuando el señor Blas Pascal inventó la Pascalina. 

Blas Pascal era hijo de un importante recaudador de impuestos en Francia. Debía ayudar a su padre con las cuentas continuamente en vez de estar por ahí de fiesta con sus colegas, así que Blas decidió crear una máquina de calcular que le ayudase a automatizar el trabajo y a asegurar la fiabilidad de los datos. Inspirado en el diseño de un sistema de engranajes diseñado siglos antes por Leonardo Da Vinci, el amigo Blas Pascal creó su máquina calculadora: la Pascalina. 
Los datos en la Pascalina se representaban mediante las posiciones en los engranajes, y se introducían manualmente estableciendo dichas posiciones finales de las ruedas, parecido a como leemos los números en el cuentakilómetros de un vehículo actual. 
"La pascalina"
Tras la Pascalina, muchos científicos se esmeraron en construir sus propias máquinas de calcular, pero como no son tan famosos y no hay ningún lenguaje de programación que lleve su apellido, nos teletransportaremos en el tiempo hasta el siglo diecinueve, cuando Charles Babbage, el llamado “padre de la computación”, creó la primera computadora.
"Charles Babbage"
Charles Babbage fue un profesor matemático de la Universidad de Cambridge. Consciente de que la elaboración de las tablas matemáticas era un proceso tedioso y propenso a errores, decidió crear la que sería la primera computadora de la historia: la máquina analítica. 

Allá por 1823 y con apoyo del gobierno británico se embarcó en la elaboración de un dispositivo mecánico capaz de efectuar sumas repetidas llamado la máquina de diferencias. 
Pero llegó a sus oídos que un fabricante de tejidos francés, apellidado Jacquard, había creado un telar que podría reproducir automáticamente patrones de tejidos leyendo información codificada en patrones de agujeros perforados en tarjetas de papel rígido. Fue entonces cuando decidió abandonar  la máquina de diferencias y dedicarse al proyecto de  la máquina analítica que se podría programar con tarjetas perforadas para efectuar cualquier cálculo con una precisión de veinte dígitos.
La tecnología de la época no estaba preparada para hacer realidad sus ideas. El mundo no estaría listo hasta cien años después, sin embargo el amigo Babage continuó perfeccionando su diseño hasta el día de su muerte en 1972.

Fue Ada Lovelace, hija del poeta inglés Lord Byron, la primera persona que ejecutó un algoritmo para la “máquina analítica” y describió por primera vez un lenguaje de programación de carácter general interpretando las ideas de Babbage. Aunque esto lo veremos en otro artículo dedicado a la historia de los lenguajes de programación.

En tiempos de guerra, la tecnología marca la diferencia


Es una verdadera pena ser conscientes de que cuando más se esfuerza el ser humano es cuando lucha contra si mismo.
Ya entrada la segunda guerra mundial, debido a la necesidad de obtener rápidamente los cálculos de las trayectorias de los proyectiles de artillería, se crearon máquinas calculadoras automáticas de las que cabe destacar la IBM ASCC, también conocida como Harvard Mark 1. Un verdadero monstruo de 17 metros de largo por 2 y medio de alto. Esta máquina no está considerada como computadora electrónica debido a que no era de propósito general y su funcionamiento estaba basado en dispositivos electromecánicos llamados relevadores.
"La Harvard Mark 1"
Ya en 1947 se construyo, en la universidad de Pennsylvania la ENIAC, que fue la primera computadora electrónica. Tenía la capacidad de realizar cinco mil operaciones aritméticas en un segundo.
El proyecto, patrocinado por el departamento de Defensa de los Estados Unidos, culminó dos años después, cuando se integró a ese equipo el ingeniero y matemático húngaro John von Neuman. Las ideas de von Neumann resultaron fundamentales para su posterior desarrollo.
" Hola soy Von Newman y me tapo la calva con el flequillo"
El equipo de la ENIAC con Von Neuman a la cabeza diseñaron la EDVAC. La idea fundamental de von Neumann fue permitir que en la memoria coexistan datos con instrucciones, para que entonces la computadora pueda ser programada en un lenguaje, y no por medio de alambres que eléctricamente interconectaban varias secciones de control, como en la ENIAC.
En realidad EDVAC fue la primera verdadera computadora electrónica digital de la historia, tal como se le concibe en estos tiempos y a partir de ella se empezaron a fabricar arquitecturas más complejas.

John Von Newman redactó una serie de reglas hoy conocidas como "el modelo Von Newman" para la creación de computadoras, que sigue siendo válido hasta nuestros días. De acuerdo con el, una característica importante de este modelo es que tanto los datos como los programas, se almacenan en la memoria antes de ser utilizados. Hay quién le considera el padre de la computación moderna junto con Babbage.
La UNIVAC fue la primera computadora producida comercialmente.


La UNIVAC no fue construida para un propósito militar, sino que fue diseñada para la oficina de Censo en 1951, por los ingenieros que crearon la ENIAC. La computadora no era de bolsillo, pesaba mas de siete toneladas y podía ejecutar unos mil cálculos por segundo, además era capaz de procesar los dígitos en serie.

Y llegó el transistor

No me refiero al que tiene papá para escuchar la radio, sino a ese pequeño dispositivo electrónico semiconductor que cumple las funciones de amplificador, oscilador, conmutador o rectificador.
"Esto es un transistor"
Allá por la década de 1950 las válvulas de vacío fueron suplantadas por los transistores, consiguiendo de este modo elementos lógicos mucho más pequeños, así como los espacios entre ellos, por lo que la fabricación de la máquinas resultaba más barata. Pensad que una válvula de vacío podía tener el tamaño de un cartucho de escopeta aproximadamente, mientras un transistor podía equipararse en volumen con una lenteja. Además el consumo de energía de un transistor era considerablemente menor, unos 10 voltios por los 300 de una válvula de vacío. Los transistores son normalmente de silicio, por lo que tienen una vida útil prácticamente ilimitada.
En definitiva el desarrollo de los transistores propició la aparición de máquinas cada día más perfeccionadas.

Circuitos integrados

A finales de la década de 1960 apareció el circuito integrado, que posibilitó la fabricación de varios transistores en un único sustrato de silicio en el que los cables de interconexión iban soldados. El circuito integrado permitió una posterior reducción del precio, el tamaño y los porcentajes de error. 

El microprocesador se convirtió en una realidad a mediados de la década de 1970, con la introducción del circuito de integración a gran escala y, más tarde, con el circuito de integración a mayor escala , con varios miles de transistores interconectados soldados sobre un único sustrato de silicios

El futuro está cerca

Gracias al uso de microcircuitos con inteligencia, en futuras generaciones las computadoras tendrán la capacidad de aprender, asociar, deducir y tomar decisiones para resolver problemas gracias al uso de microcircuitos con inteligencia. Esta será la generación de la inteligencia artificial.

Realidad o ficción?

En la universidad de Surey, Inglaterra, creen que en el futuro la clave será la LUZ. Según su equipo de investigadores, será posible crear un dispositivo óptico de computación que se aproveche de la velocidad de la luz y de su gran capacidad para transportar información... En la película K-Pax el protagonista viajaba a través de los rayos de luz.

Por otra parte, en el instituto de bioquímica Maxplanck, cerca de Munich, han conseguido hacer que el silicio interactúe con tejidos vivos. La tecnología neuroelectrónica abre una via de comunicaciones entre computadoras y células. El primer "neurochip" ha consistido en fusionar y hacer que trabajen juntos un microchip y las neuronas de un caracol... Podría ser esto una avance en la cura de enfermedades neuronales en humanos?

ARTÍCULO - ¿Por qué elegir Game Maker ?

Existen muchos programas que nos facilitan la ardua tarea de de programar Videojuegos. Últimamente, con el auge de nuevo del 2d, gracias a las nuevas plataformas de destino como son smartphones, tablets, etc.. Han surgido o resurgido muchos motores para videojuegos en dos dimensiones, con la clara misión de convertirse en multiplataforma. Algunos de estos motores nos permiten crear videojuegos sin picar absolutamente ni una linea de código, y permiten exportarlos a Android, iOS, Mac, Html5 y o Flash.

"Game Maker es la suite de desarrollo de videojuegos 2d más usada por la comunidad Indie"







Escrito por:  Asensio López Fernández



    Yo, como tantos otros, he tenido que decidirme por un software para la creación de algunos de mis proyectos en 2d, y no eran pocas las alternativas:
GameMaker
Multimedia Fusión
Construct 2
Stencyl
GameSalad
Otros...

Mi elegido ha sido GameMaker, y voy a tratar de razonar dicha elección.
Es el más veterano de todos y la experiencia siempre es un grado. Tiene varias comunidades en español como son: comunidadGM y GameMaker Pro. Hay gran cantidad de tutoriales por la red y de videotutoriales en youtube; sin duda de los mencionados anteriormente es el que más tiene, con diferencia, en el idioma de Cervantes.
Tiene un poderoso lenguaje interno que nos permite programar cualquier cosa, por si se nos queda corto el sistema de eventos y acciones del programa.
Además GameMaker soporta 3d, si bien no lo hace de un modo muy potente, nos puede permitir darle algunos detalles interesantes a nuestro proyecto, aunque para videojuegos 3d, lo mejor es ir a lo seguro, y potente: unity3d.
Puede ejecutarse desde Windows o Macintosh y permite crear aplicaciones para PC, Mac, Android, iOS, Html5 y Windows 8.

La versión máxima del programa vale sobre 450 euros, un precio que me parece irrisorio para lo que ofrece, así que id ahorrando el dinero que os da mamá para el fin de semana.
De cualquier modo tiene versiones más baratas, si solo queremos exportar a Android, Html5 o iOS exclusivamente. Incluso tiene una versión solo para Pc y Mac por menos de 50 euros. Mi recomendación es que bajes la versión libre, y pruebes el programa para compararlo con el resto de tocayos suyos.

No digo que los descartados sean malos, nada más lejos de la realidad.

GameSalad por ejemplo, es una buena elección. Fue creado originalmente como un GameMaker para Macintosh, pero desde hace poco existe una versión para Windows. La versión de Mac tiene varias plantillas de proyectos de diferentes estilos que pueden ayudarte a empezar, pero por desgracia en la versión windows no están disponibles. Como ventaja, al menos para los menos dados a la programación, en GameSalad todo puede hacerse mediante reglas, por lo que no hay que picar ni una sola linea de código. Y como desventaja clara, no se puede crear la aplicación para Windows 7, si para el resto de las plataformas que soporta también GameMaker.

Si tienes Linux tu elección deberá ser Stencyl, ya que a parte de poder ejecutarse en Windows y Mac, también puede usarse desde Ubuntu, Linux Mint, etc...

Tanto Construct2, como Multimedia Fusión, al igual que Game Maker, se pueden ejecutar solo desde Windows.
Multimedia Fusión lo descarté porque para juegos web exporta en formato flash, esto tiene sus ventajas ya que nos da como resultado un solo archivo y no varios como Html5, pero el inconveniente es que se debe tener instalado flash player en el navegador para poder jugar a los juegos creados con él.
Construct2 no recuerdo bien por qué lo descarte, creo que no me gustaba el logotipo.

ARTÍCULO - Videojuegos. Aplicación de la teoría del puzzle

Cuando pensamos en aventura gráfica, lo primero que se nos viene a la cabeza es la palabra Puzzle, pero un buen juego de aventuras no consta tan solo de buenos puzzles. Esencialmente, todo se basa en consistencia de guión, personalidades de personajes bien desarrolladas, y en algunos casos (como el de Lucas Art), mucho humor.
"La diferencia principal que existe entre la mayoría de aventuras gráficas y el resto de videojuegos, es que en este género, el jugador suele trata de resolver las situaciones por medio de la lógica, y no con la fuerza bruta"








Escrito por: Scarpia, 2003.
Traducido por: McCoy, para LAELA, 2006.


   Los puzzles de los juegos de aventura han sido una gran pasión para mí desde mis “primeros encuentros” con ellos en Beneath A Steel Sky, allá por 1994. Tras un tiempo investigando por la comunidad aventurera, quedé sorprendido por lo poco que se discute sobre el tema de los puzzles. Tras una ardua búsqueda de información el único archivo que encontré fue un documento de Bob Bates titulado "Desingning the puzzle" y obviamente en inglés.
Bueno, esto no es completamente verdad. También encontré un artículo corto por Johnathan Partington por ahí, y otro de Pascal Luban en GamaSutra.com, y algunos más; pero estos no son determinantes desde el punto de vista de un diseñador de videojuegos.

Ahora, aunque hay literalmente docenas de juegos de aventuras amateur funcionando, usando motores como AGS, VISIONAIRE, WME o SLUDGE, la única cosa que los diseñadores amateur todavía no están discutiendo, es cómo hacer buenos puzzles… lo que, bajo mi punto de vista, es una pena.

Teoría vs. Práctica

No estoy aquí para reinventar la rueda. Lee el artículo de Bob Bates sobre la teoría del puzzle si no lo has hecho todavía. Venga, léelo. ¡Léelo! ¡Ahora!

Bien. Todo desarrollador de juegos de aventuras debería conocer las bases de la teoría del puzzle. De cualquier manera, mi intención es otra. Quiero cavar un poco más profundo, en la práctica y la aplicación de la teoría del puzzle. Para mí, al menos, esto se tiene que afrontar desde un ángulo diferente. Cuando diseño puzzles, tengo que distinguir entre diferentes tipos (o implementaciones) de “puzzles de secuencias”, por ejemplo, donde no tiene sentido considerar un “uso ordinario de un objeto de la forma para la que fue obviamente diseñado” un puzzle, al menos no en sí mismo.

Desde una perspectiva práctica, debemos categorizar los puzzles no por la similitud en sus objetivos, sino por los tipos de acciones que el jugador debe realizar para resolverlos. Para ser más claros: Quería que mi clasificación de tipos de puzzles reflejara que dos puzzles subsecuentes del mismo tipo harían al jugador sentir que está haciendo lo mismo una y otra vez, solo que en otro contexto. Con dos puzzles subsecuentes de diferente tipo, el jugador obtendrá una experiencia más gratificante y diversa.

Tipos de puzzles aplicados

Quid Pro Quo / Puzzles de intercambio.
Inventario / Puzzles de combinación.
Puzzles basados en el tiempo.
Puzzles de distraer y arrebatar.
Puzzles de Laberintos.
Puzzles de huída.
Puzzles de disfraces.
Puzzles de criptogramas.
Puzzles de memorización y repetición de secuencias.
Puzzles de secuencias lógicas / Puzzles de aparatos.
Puzzles de repetición de acciones.
Puzzles de conversación.
Puzzles de conversación forzados.
Puzzles de adivinanzas y lógica.
Puzzles de tablero / interfaz.
Finales sin salida, arenques ahumados y puzzles falsos.

Quid Pro Quo / Puzzles de intercambio

El tipo de puzzle más básico, desde el punto de vista de su implementación. El objetivo del jugador es conseguir un objeto en cuestión, y para lograrlo, tendrá que dar otra cosa, ya sea de su inventario, o algo que deberá recoger antes.
A veces, el objeto que necesita el jugador pertenece a un NPC (non player character), en español significa "cualquier personaje que no puede usar el jugador". El NPC dará una pista sobre por qué desearía cambiarlo. Todo lo que queda hacer es encontrar ese objeto y dárselo, y el a cambio nos dará el objeto que necesitamos.

Otro tipo de puzzle QPQ típico es el de empujar estilo Indiana Jones, en el que debes usar un objeto con el objeto que necesitas, empujando los dos, para conseguir el objeto que necesitas. Hablando estrictamente, el objeto no siempre “empuja”, pero después de conseguir el objeto B, no tendrás más el objeto A en tu inventario.

Se consciente de que los puzzles QPQ mal diseñados se hacen aburridos en poco tempo, y que muchos (si no la mayoría) de los juegos de aventuras amateur sufren un uso excesivo de ellos. Si la mitad (o incluso menos) de tus puzzles son QPQ, el estilo de juego seguramente aburrirá a los jugadores. Para hacer un puzzle QPQ más interesante, un diseñador puede usar las siguientes técnicas:

Hacer las pistas del NPC lo más vagas posibles sin revelar el puzzle completamente. “OH, no, mi vestido está destrozado…” es vago, y abre las puestas a una gran variedad de soluciones. Si en lugar de ello, dijera “Mi vestido necesita un arreglo. ¿Puedes encontrarme un par de dijeras de sastre?” no solo revelaría completamente el obstáculo, sino que también mostraría al jugador cómo completar el puzzle. El “cómo” se debe dejar siempre al jugador, y esto se consigue siendo poco conciso. Por otra parte, no hagas tus pistas demasiado ambiguas, o podrías llevar al jugador completamente fuera del camino. Deja siempre buenas pistas.

Cuando se trata de los objetos en sí mismos, tampoco seas muy obvio. Si el NPC pide una naranja (vagamente), no dejes una naranja en el suelo en la habitación de al lado. Podrías, sin embargo (y estoy fantaseando), tener un NPC barman sarcástico, quien, anteriormente en el juego, ha estado negándose a servir otra cosa que no fuera zumo de naranja a un personaje de aspecto raro en la esquina del bar, y consigue (mediante sutiles pistas) que el jugador recuerde este incidente, vuelva al bar, consiga el vaso de zumo de naranja, y complete el intercambio.

Usar un puzzle QPQ en combinación con otros tipos de puzzles consigue estructuras de puzzles más originales y únicas. No has que sea tan fácil para el jugador el conseguir el objeto que necesita intercambiar, introduce un puzzle adicional en el proceso, o dos, o cinco, o los que sean, mientras recuerdes cambiar de tipo de puzzle cada vez.

Inventario / Puzzles de combinación
"Combinando Garfio con palo en Monkey Island 3"
Pocas veces un puzzle en sí mismo, pero de todas maneras merece la pena mencionarlo. No es fácil para un diseñador de juegos el idear un buen puzzle de inventario, ya que la combinación de objetos tiene que ser lógica de alguna manera, sin llegar a ser demasiado obvia (del tipo “bala-con-pistola” o “pilas-con-linterna”) o demasiado arbitraria, lo que empujaría al jugador a un invierno de usa-todo-con-todo. Como mejor se consigue el equilibrio, en mi opinión, es a través de un buen trabajo de beta testing . Siempre que un beta tester intenta una determinada combinación de objetos, debe significar que existe algún tipo de conexión lógica entre estos, incluso si el diseñador no pensó en ello.

Si sabes con antelación que el jugador intentará con mucha probabilidad una cierta combinación, que no es la correcta, lo mínimo que deberías hacer es recompensarle con algún tipo de comentario divertido cuando lo haga. Después de todo, llegar a la combinación “usar-violín-con-Biblia” lleva mucha imaginación… Vale, puede que sea absoluta y completamente incorrecto, pero al menos hazle saber que vas MUY por delante de él…
La mejor manera de equilibrar los puzzles de inventario es usar las descripciones de los objetos para dejar pistas sobre su futuro uso. Hazlo siempre.

Recompensa siempre al jugador
Resolver un puzzle, especialmente uno difícil, ¡¡debería ser siempre recompensado!!! ¿Pero qué le puedes dar? Qué tal esto:

- Un diálogo sorprendente o divertido (recompensa muy pequeña)
- Una animación especial y única del personaje (recompensa pequeña)
- Acceso a un nuevo escenario (recompensa pequeña/mediana)
- Acceso a una nueva zona de escenarios (recompensa mediana/grande)
- Una escena cinemática (recompensa mediana/grande)
- Acceso a un nuevo personaje jugable (recompensa grande)

Ver esto es emocionante para el jugador, y cada vez que le recompenses con algo de esto por resolver un puzzle, querrá resolver el siguiente para conseguir más.

Dave GilBert indicó que un diálogo divertido o sorprendente también puede usarse como recompensa, y estoy de acuerdo completamente. Pero a no ser que el diálogo sea parte de una escena cinemática, es una recompensa muy pequeña comparada con las otras, incluso si el comentario es verdaderamente gracioso. Cuando juego un nuevo juego amateur, espero humor, pero rezo por animaciones. He dicho.

Puzzles basados en el tiempo

"Day of Tentacle en su versión clásica"
Posiblemente el tipo de puzzle mas infravalorado de todos. Casi no se ve en aventuras amateur, sobre todo porque requiere una programación algo más complicada. Para mí, los puzzles basados en el tiempo muchas veces hacen que los juegos de aventuras cobren vida.

Mi definición de un puzzle basado en el tiempo difiere de la dada por Bob Bates: “una acción que no derivará en un efecto instantáneo, sino que causará que algo ocurra en un momento concreto en el futuro.” Si quieres mi opinión, esa definición valdría para la mitad de los puzzles de Beneath a Steel SkyDay of The Tentacle. Un puzzle bien integrado en el guión, invariablemente causará algún efecto más adelante en el juego, sin importar qué tipo de puzzle es. En su lugar, yo defino un puzzle basado en el tiempo como un puzzle que tiene un temporizador, como un cronómetro invisible, y en el que el jugador debe realizar una acción específica entre el tiempo A y el tiempo B para que ésta acción sea un éxito.

Ejemplo: [spoiler]: Monkey Island 1 y 2 tenían unos puzzles basados en el tiempo maravillosos: Arrebatar el monóculo del cartógrafo en el momento preciso, entrar en la cocina del Bar Scumm cuando el cocinero no estuviera, el concurso de escupitajos (mi puzzle de aventura gráfica favorito) tenía al menos dos magníficos puzzles basados en el tiempo, etc. [/spoiler]

Podría continuar así, pero lo especial de los puzzles basados en el tiempo es que pueden ser sorprendentemente simples y lógicos, y aún así ser sorprendentemente gratificantes de resolver. Tira a la cuneta media docena de puzzles QPQ por uno o dos puzzles basados en el tiempo, y mira como el juego cobra vida ante tus ojos.

Puzzles de distraer y arrebatar

(A partir de ahora, puzzles DyA). Otro verdadero clásico, pero éste es mucho más gratificante que el viejo y simple puzzle QPQ. A veces, la parte de distracción incluye algún elemento basado en el tiempo de algún tipo (mejorándolos bastante), pero la mayoría de los puzzles DyA mantienen al NPC ocupado hasta que el jugador ha cogido lo que necesita.
Demasiados puzzles DyA en un juego puede parecer inadecuado, pero también lo parecerá un juego amateur sin ellos ;).

Ejemplos: [spoiler]: El infame truco del “mono de tres cabezas”; deshacerse de “Woodchuck” en Monkey Island II, el General y su secretaria, en Broken Sword II, o el mecánico al principio de Beneath a Steel Sky.[/spoiler]

Puzzles de laberintos
"Laberinto de Igor, Objetivo Uikokahonia"
Los laberintos también son un cliché. Afortunadamente, no es terriblemente fácil hacer un puzzle de laberinto, o estoy seguro de que habría uno en cada juego amateur que anda suelto, uno más odioso que otro. Laberintos pobremente diseñados son auténticos mata-juegos, y laberintos realmente buenos son simplemente un poco fastidiosos. Bueno, estoy seguro de que hay un montón de gente a quien le gusta vérselas con laberintos,pero a menos que tu diseño del laberinto sea realmente bueno,incluso éstos se frustrarán mucho antes de terminarlo.

La mayoría de los laberintos en los juegos de aventuras comerciales contienen buenas sugerencias en el juego, como pistas, mapas, loros, prospectos de clases de baile, maneras de dejar un rastro, etc. ¿Por qué? Porque andar a ciegas por un laberinto está condenado a que acabes bloqueado. Esa es la idea original de un laberinto, por supuesto: ¡El quedarte bloqueado para que no encuentres el secreto del otro lado! “Pero mi laberinto no es TAN difícil”, te oigo decir. Pero si es verdaderamente tan fácil, ¿Por qué, en primer lugar, tiene que estar ahí? ¿Pensaron los villanos de tu historia que solo gente verdaderamente tonta entraría en su laberinto? ¿O simplemente estás haciendo perder el tiempo al jugador? ¿Es realmente necesario un laberinto? ¿Tiene siquiera sentido tener un laberinto en el contexto del guión de tu juego? Piénsalo durante un rato, antes de decidirte a programar un laberinto.
Resumiendo: Si quieres incluir un laberinto, vale. Solo recuerda esto: ¡Sugerencias! ¡Pistas! ¡AYUDAS!

Intenta integrar puzzles e historia

Siempre que el jugador actúa en tu mundo, el mundo debería reaccionar al cambio. Evita tener demasiados puzzles que no afecten a otra cosa que no sea el estado inmediato de un objeto/localización. En su lugar, haz que la solución del jugador afecte a otro personaje, al escenario, o (mi favorita) a la historia principal. Esto ayuda a hacer que el juego parezca mucho menos lineal.

Imagina que la solución a un puzzle más tarde se convierta en un obstáculo para el jugador, esto es, otro puzzle. Por ejemplo, el jugador tiene que atravesar un camino bloqueado por una gran piedra, así que lo empuja hacia el fondo de la colina. Finalmente, llega a la cueva que guarda el gran tesoro, para encontrar que el pedrusco que empujó antes aterrizó justo ahí, bloqueando la entrada… Te haces la imagen.

Buen ejemplo: Beneath a Steel Sky hace esto mucho.

Puzzles de huída

OH, no, nuestro héroe está encadenado al suelo de una pequeña celda, y la prisión está ardiendo. Todo lo que le queda es un hueso seco, una rata hambrienta y cinco mil cintas de goma. ¿Y ahora qué?

Los puzzles de huída son divertidos porque sabemos que la respuesta está ante nuestras narices, pero el problema es que no la vemos. No hay peligro de frustración debido a tener que andar entre localizaciones, hablar a los mismos personajes una y otra vez, etc., dado que obviamente tenemos la solución en un solo lugar. Esto básicamente permite puzzles más difíciles, por ejemplo, en forma de un intrincado puzzle de secuencia lógica o aparato. Pero no te pases: pasar demasiado tiempo en la misma habitación, atrancarse en un puzzle de huída en la misma habitación, diferentes enfoques e intentos en la misma habitación,¡¡¡escuchar la misma música una y otra vez, en la misma habitación!!! Se volverá tedioso, o incluso peor.

De nuevo, todo se basa en ser poco convencional al proveer al jugador de los objetos de inventario. Y recuerda: incluso las celdas tiene más de una salida. Haz que el jugador se pregunte si tiene que cavar, doblar los barrotes de la ventana, o coger las llaves de la mesa del guardia durmiente. Los guardias en las películas y en los juegos de aventuras duermen mucho en el trabajo, ¿no? ;).

Puzzles de disfraces
"La fiesta de disfraces en Monkey Island 2 Special Edition"
Algunas veces, necesitas parecer diferente para acceder a un lugar concreto, y necesitarás un disfraz. Algunos juegos toma el camino fácil colocando una tienda de disfraces en alguna parte, incluyendo un tendero estrafalario y todo eso, mientras que otros te obligan a hacer tu propia nariz, pata de palo o parche para el ojo con lo puedas encontrar. Las dos aproximaciones pueden ser hilarantes.

Este tipo de puzzles son muy raros en los juegos de aventuras amateur, en parte debido probablemente a que requieren gráficos adicionales de personaje, a veces incluso animaciones extra. Pero las animaciones no son meros adornos superfluos en los que se desperdicia el tiempo. Estoy seguro de que a muchos diseñadores de juegos amateurs les gustaría que fuese así. Creo que muchas animaciones son necesarias para que un juego de aventuras sea bueno. Los gráficos no tienen por qué ser magníficos, pero si no hay animaciones extra, el juego siempre tendrá esa apariencia “estática” que la mayoría de los juegos amateur tienen.

Puzzles de criptogramas

A estos los odio. En la vida real, me divierte un criptograma desafiante tanto como a otro, pero en los juegos de aventura, los criptogramas siempre han sido patéticos, dolorosos, monumentalmente pésimos. Probablemente porque cualquier criptograma medio decente habría derribado al 60% de los jugadores, y pocos diseñadores están predispuestos a asumir ese riesgo. Al menos yo no.

Desbarrado esto de mi cuerpo, puedo continuar con la descripción. Los puzzles de criptogramas son básicamente textos codificados escritos con letras o símbolos / números que representan letras. Ahora, para descifrar el criptograma (para hacerlo legible), uno necesita algún tipo de “clave”. La mayoría de los juegos de aventuras usan cifrados triviales como el ROT13 (que “rota” cada letra alfabéticamente 13 puestos) para mantener el nivel de dificultad bajo, y, encima, añaden pistas en el juego para asegurarse de que el 15% restante descifrará el criptograma si demasiada frustración. Te sugiero que hagas lo mismo si tienes pensado incluir un puzzle de criptograma en tu juego.

Estructura de historia épica

Los guiones de los juegos deben seguir las mismas reglas básicas de narración que usan las películas y los libros. Estos principios épicos han sido refinados durante siglos, y solo los tontos no se someten a ellos:

- Usa los primeros puzzles sobre todo para introducir y establecer personajes, lugares y el marco de la historia.
- Invierte mucho esfuerzo desarrollando los personajes centrales, y asegúrate de que el jugador simpatiza y se preocupa por el protagonista.
- Ves creando tensión durante el juego, alcanzando el clímax en el puzzle final.
- Si estás haciendo un juego largo, intenta dividir la historia en un puñado de “capítulos” lógicos, siguiendo en cada uno estos principios épicos.

Puzzles de memorización y repetición de secuencias

La mayoría de los puzzles consisten en una secuencia de eventos que lleva a la solución de una manera o de otra. Lo que distingue a esta categoría, es que este tipo de puzzle se basa en que el jugador debe recordar y recrear una secuencia de movimientos o acciones. [spoiler] Como la combinación de la caja fuerte en Monkey Island: En un momento, observas al dueño de la tienda cómo abre la caja fuerte con una combinación de empujar/tirar, y cuando se va, tienes que imitar la misma secuencia para abrir la caja fuerte. [/spoiler]

Los puzzles de memorización y repetición de secuencias son bastante satisfactorios, porque están divididos de forma natural en cuatro partes separadas y consistentes:

- Observar la secuencia (a veces esto es un pequeño puzzle en sí mismo).
- Suponer que debes necesitar la información, posiblemente observando la secuencia de nuevo.
- Memorizar la secuencia (o escribirla).
- Intentar recrear la secuencia mediante lo que se recuerde de ella.

Puzzles de secuencias lógicas / Puzzles de aparatos

Estos son puzzles que constituyen algún tipo de relación mecánica-casual entre eventos llevando a la solución final. Hay muchos tipos clásicos de puzzles de secuencias lógicas o de aparatos. Como el puzzle de construye una trampa, o el de preparando el camino (excluded-middle / preparing-the-way) como explica Bob Bates, o el puzzle de máquina, en el que el jugador debe imaginarse como utilizar una máquina para completar el puzzle.
Los puzzles de secuencias lógicas deben ser lógicos; cuantos más pasos añadas a la secuencia, más difícil se hace; y esto hace crucial el que cada paso sea lo menos ambiguo posible para el jugador.

Como nota al margen, ¿Alguna vez has completado un puzzle de secuencia lógica en un juego de aventuras comercial, sin obtener una pequeña animación cuando finalmente funcionó, o incluso cuando falló? Creo que no. Recompensa siempre al jugador con algo después de resolver un puzzle difícil, y que no sea con “dinero” o “puntos”. Los jugadores no se preocupan por los puntos. No juegan el juego por los puntos. Juegan para ver las cosas divertidas. Así que asegúrate de que les das algunas.

Pistas activas

Leí sobre esto en algún sitio, y creo que verdaderamente merece la pena echarle un vistazo. Algunos juegos tienen “pistas activas”, esto es, pistas que aparecen automáticamente si y cuando el jugador las necesita. Imagina un puzzle que sabes que es difícil, y para el que has dejado 4 sugerencias diferentes cerca del lugar del puzzle, de las cuales una es especialmente poco ambigua acerca de la solución. Sabes del beta testing que 6 de cada 10 jugadores lo resolverán sin la pista final (y que generalmente te dirán que la cuarta pista lo hace demasiado obvio). El resto, 4 de cada 10, no resolverán el puzzle sin ella.

Para hacer a esta pista “activa”, añade al código unas instrucciones que verifiquen las acciones del jugador en esta parte del juego: si ha encontrado las tres sugerencias (más vagas), y todavía no ha resuelto el puzzle en un tiempo determinado, la pista extra se colocará donde el jugador seguramente la encuentre.
Eso es una pista activa.

Puzzles de repetición de acciones

Un puzzle simple pero muy adaptable es el puzzle de repetición de acciones. El juego realista Purity of the Surf los usa de manera muy humorística: [spoiler] el personaje principal es un surfero, que anda siempre descalzo. Cuando entra al restaurante italiano, el Chef Lucca sale de la cocina, gritándole que salga. Si se entra otra vez, el Chef vuelve a salir y viene corriendo, esta vez gritando incluso más (presenta otro diálogo esta vez, pista, pista…). Tras volver unas pocas veces más, finalmente enfadas tanto al Chef que te lanza un pescado, el cual, convenientemente, necesitas para otro puzzle. [/spoiler]

Ah, y como me recordó amablemente Essen, los puzzles de repetición de acciones harán que los jugadores se queden atascados con facilidad, a no ser que al jugador le dé por repetir la acción otra vez. Utilizar la acción de entrar a una localización está bien, porque siempre andas a todos los sitios cuando te quedas atascado, pero interactuar con una ardilla difícilmente es algo que volverás a probar si falló la primera vez.

Puzzles de conversación
"Touche, el quinto mosquetero"
Con los puzzles de conversación, intentas escoger el camino correcto a través de ésta, diciendo las respuestas correctas o formulando las preguntas correctas, con el objetivo de conseguir algo, una pista, información, etc. Si eliges el camino incorrecto, siempre puedes probar de nuevo, pero llevará un rato.
Si el puzzle es demasiado complejo, o el diálogo no es gracioso, el jugador dejará pronto de leer las preguntas y simplemente hará clic metódicamente a través de las opciones hasta que haya explorado todas las combinaciones posibles del árbol de diálogo. Este tipo de “puzzle” debería ser evitado a no ser que se tenga una buena razón para usarlo (supongo que cierto tipo de historias de detectives los usarán, para los interrogatorios, etc.)

Como muestran los siguientes ejemplos, un puzzle de conversación puede ser bastante divertido, asumiendo que: 1) no debería ser muy complejo; 2) debería ser obvio que es un puzzle; y 3) no debería de haber muchos puzzles de este tipo en un juego. Indicados por Creed Malay, aquí hay algunos buenos puzzles de conversación:

- Manny intentado persuadir a la guarda de seguridad para que le dé el detector de metales en Grim Fandango.
- Guybrush convenciendo a Elaine de que está enamorado de él en Monkey Island II.
- El test V.K. en Blade Runner.
- Y seguramente el mejor puzzle de conversación de todos: La lucha a espada con insultos, también en Monkey Island II.

Puzzles de conversación forzados

Muchos desarrolladores de juegos evitan usarlos, porque tienden a convertirse en una molestia para el jugador (Malas estrategias de Marketing, artículo 101). La idea básica es la siguiente: para conseguir la respuesta que necesitas (y resolver el puzzle), debes escoger el camino correcto a través de la conversación con uno o más NPCs. Si no lo consigues, tendrás que cargar un juego salvado o estarás atascado.

Naturalmente, puedes ofrecer un puzzle de conversación forzado como una mera alternativa, dejando que el puzzle pueda ser resuelto de una manera diferente incluso si se falla el puzzle de conversación. En mi opinión, la mejor manera de evitar frustrar al jugador innecesariamente forzándole a ir a través del purgatorio del cargar-juego cada vez que elige una opción incorrecta. Algunos juegos tienen una función de auto-carga que te permite volver automáticamente al momento en que escogiste la opción incorrecta, pero normalmente se utilizan para eventos raros, como muertes. Con eventos frecuentes como estos, la auto-carga también se volverá molesta.

Repetición de puzzles

Todos sabemos que no deberíamos usar el mismo puzzle dos veces en el juego. El jugador podría encontrar tedioso una segunda vuelta. Sin embargo, en Monkey Island II, eso es exactamente lo que hicieron los diseñadores con el puzzle del “Muñeco Vudú”. [spoiler] La pitonisa te daba la receta para el primer muñeco, y más adelante en el juego, recibías sutiles sugerencias de que deberías hacer otro muñeco vudú. Entonces tenías que recordar qué objetos necesitabas para hacer el muñeco y encontrarlos, solo que esta vez, algunos objetos de antes no estaban disponibles, así que tenías que improvisar, lo que hacía que se convierta en un puzzle muy entretenido. [/spoiler]
Esto me lo dijo Cerulean.

Puzzles de adivinanzas y lógica

Bob Bates afirma que estos son unos de los puzzles menos satisfactorios, ya que “si el jugador no lo pilla, simplemente no lo pilla”. Esto puede tener parte de verdad, pero a la vez se puede decir fácilmente de muchos otros tipos de puzzle. Creo que las adivinanzas, usadas con cautela, pueden añadir una magnífica atmósfera a un juego de aventuras, y también a la personalidad del personaje que presenta la adivinaza. Lo mismo se aplica a los puzzles de lógica.

Un ejemplo de un buen juego de lógica es el código de “cuantos dedos” en la isla Phatt en Monkey Island II. Si no lo pillas, puedes seguir probando hasta que aciertes, o imaginarte la solución tú mismo. Creo que había una pista sobre ello en alguna parte del juego, pero no puedo recordar exactamente dónde.
Tanto con los puzzles de adivinanzas como con los de lógica, siempre deja pistas o una solución alternativa.De esta manera, hay posibilidades de que el jugador -eventualmente- “lo pille”.

Puzzles de tablero / interfaz
"Broken Sword, la leyenda de los Templarios"
Probablemente los puzzles más difíciles de programar, y a veces no merece la pena el esfuerzo. Hay miles de juegos de tablero clásicos, desde el ajedrez a las tres en raya, los cuales pueden ser adaptados como puzzles a un juego de aventuras. Aunque esto no es siempre trivial, ya que seguramente deberás crear una nueva interfaz para el juego, así como un poco de programación para que el “juego” tenga un aspecto realista.

Algunos puzzles, como ciertos puzzles de máquinas, de criptogramas, y otros, a veces también usan interfaces independientes, que justifican su uso, pero los juegos de mesa son difíciles de adaptar a la historia de manera razonable, y deben de ser usados sólo cuando existe una estrecha relación entre el juego específico y el personaje principal de tu historia.

Dicho esto, interfaces alternantes pueden hacer que un juego se vea mucho más profesional, haciendo que su uso esté justificado. Un buen ejemplo de esto se encuentra en Pleurghburh: Dark Ages, en el que bastantes interfaces adicionales estaban bien integradas en la historia: un interfaz de ordenador, una vista superior de un edificio, un panel de ascensor montado en una pared, etc. Claro, ninguno se usaba como puzzle, pero estaban añadidos al juego de manera que no parecían estar fuera de lugar, eso es lo que debes de hacer también con tus puzzles de interfaz.

Finales sin salida, arenques ahumados y puzzles falsos

Finales sin salida son inevitables en los juegos de aventuras, no importa si el diseñador quería hacerlos o no. A no ser que tus puzzles sean ridículamente fáciles, el jugador se quedará bloqueado en uno o más de ellos. A veces, especialmente con puzzles pobremente diseñados, el jugador estará sin pistas al enfrentarse a un obstáculo, pero la mayoría del tiempo, tendrá bastantes soluciones lógicas y/o obvias que probar; después probará un puñado de soluciones más imaginativas, antes de quedar atrancado probando combinaciones irracionales, más o menos aleatorias.

Cuando esto ocurre, los buenos juegos de aventuras no abandonan por completo al jugador. Le proveen de puzzles paralelos para resolver. Mientras está atrancado en un puzzle, el jugador puede ir a otro puzzle en otro lugar, en lugar de frustrarse por el hecho de quedarse atrancado. La mayoría de los juegos amateur de aventuras son muy lineales, dejando al jugador con un solo puzzle que resolver cada vez, por lo que están más inclinados a frustrar al jugador.

Cuando los puzzles no lineales (paralelos) están hechos de manera elegante, el jugador ni siquiera se percatará de que estaba trancado; después de todo, “podía ser parte de la historia que tuviera que terminar ESTOS dos puzzles antes de poder seguir con el tercero.” Mientras consigas mantener esta ilusión, al jugador no le importará quedarse atrancado al principio.

Recuerda, sin embargo, no crear historias secundarias que se separen de la historia principal, o tu juego de desintegrará. Dos, o incluso tres puzzles o objetivos simultáneos está bien, pero si dos son obstáculos en tu camino para rescatar a una princesa, y el tercero es robar un huevo del nido de un pájaro, entonces mejor que te aseguras de que el jugador sabe exactamente por qué demonios necesitará ese huevo más adelanto, o si no simplemente no se preocupará de él. (Bueno, la mayoría de los jugadores se preocuparán por él, pero solo porque ven el nido del pájaro y piensan “Probablemente esto sea un puzzle. Debo resolverlo y ver qué consigo”.-Lo que es idiota si me preguntas).

El “puzzle falso” ocurre cuando intencionadamente diseñas un final sin salida, para hacer saber a los jugadores que están en el camino equivocado (o solo para jugar con ellos un poco…). A veces querrás crear uno tras una fase de beta-testing en la que varios de los testadores quedaron completamente atrancados al intentar resolver un puzzle de la misma -incorrecta- manera. Y otras veces, simplemente querrás ser perverso colocando un martillo en un sitio en el que el jugador no pueda alcanzarlo, precisamente cuando el puzzle actual cosiste en romper algo. OH, no lo hagas; es cruel. Heh.

En realidad, añadir un puzzle falso puede dar un giro interesante a un puzzle de otra manera anodino. En el ejemplo del martillo de antes, deja que el jugador alcance al martillo (con un poco de suerte o simplemente con una combinación en el inventario), pero después haz que el martillo sea un inútil martillo de goma, o que se rompa o algo así, mostrando que el puzzle debe ser resuelto de otra manera.

Clásicos e Inspiración

- Múltiples soluciones para un puzzle incrementa el realismo, Como, por ejemplo, cortar una cuerda puede ser conseguido usando una espada oxidada, un trozo de cristal o unas tijeras.
- Puzzles “en la oscuridad”, donde te encuentras en un lugar oscuro y debes encontrar una manera de conseguir alguna fuente de luz. Llevan muy poco trabajo de dibujo/animación, y son un buen aliciente en cualquier juego. Aunque no debes poner demasiados.
- NPCs medio sordos. Si quieres que un personaje sea verdaderamente molesto y estereotipado, hazle parcialmente sordo.
- ¿Quién decide que un jugador solo puede Usar, Coger, Hablar a, etc.? ¿Por qué no tener un perro como protagonista: Comer, Oler, Ladrar A, Cagar, Mear… o un rudo motero: Romper, Golpear, Patear, Gritar a…?

Recuerdas el cuerno del barco en Monkey Island II? Soplando por él al lado del vigía ciego hacía que el sujeto de la competición de escupitajos cercana viniera corriendo y hablara al viejo vigía, lo que ya era bastante divertido en sí mismo. [spoiler] Más adelante, puedes usar este conocimiento en el puzzle de la “Competición de escupitajos” [/spoiler] Introducir una secuencia de dialogo divertida hará que el jugador recuerde este efecto.

Ejemplo de una estructura del puzzle aplicada

Echemos un visitado al puzzle con el que he estado jugando hasta ahora, basado en un entorno realista. Siendo los personajes principales dos traviesos niños llamados Moe, y su nervioso colega, Wilbur. El objetivo del puzzle es entrar en la cocina del restaurante italiano del Chef Lucca (para robar la tarta de cumpleaños que está haciendo Lucca a su simplón hermano Guido), y un objetivo adicional de conseguir entrar a la morgue del hospital. Aquí va:

Cuando los niños entran al restaurante, ven al Chef Lucca andando por ahí y entrando ocasionalmente a la cocina. Está ocupado decorando el restaurante y sirviendo a un solo cliente que está comiendo algún tipo de pasta y quejándose de que no tiene queso parmesano. Al hablar con Lucca, los chicos se enteran de que está haciendo una deliciosa tarta de cumpleaños en la cocina. Si intentan entrar en la cocina mientras Lucca está en el restaurante, les gritará para mantenerles alejados. Si entran mientras está en la cocina, les empujará afuera (pero conseguirán echar una ojeada rápida a la tarta de la mesa).

Si entran a la cocina de esa manera algunas veces más (acción repetida), el chef cada vez se enfadará más y más, hasta que finalmente lanza un mortero -no una bomba; el que se usa en cocina- (recompensa pequeña: animación), el cual cogen.

Mientras Lucca está en la cocina, los chicos pueden robar un martillo y unas tijeras que está usando para poner la decoración. (Puzzle basado en el tiempo).

No lejos del restaurante está el hospital. Si los chicos entran y preguntan si pueden entrar en la morgue, un guardia les dirá que se vallan. Si entran otra vez, se enfadará con ellos, balanceará su pistola (está bajo mucha presión) y les dirá que si alguno entra por la puerta en los próximos dos minutos, verá la morgue antes de los que piensan – pista, pista… (Recompensa pequeña: animación) Si finalmente entran otra vez en menos de dos minutos sin tomar en serio la advertencia del guardia, les disparará hasta que mueran. Si entrar después de que pasen dos minutos, simplemente les empujará fuera y repetirá su amenaza. (Acción repetida y Puzzle basado en el tiempo).

De vuelta a la plaza del pueblo, hay un local de comida rápida llamado Dominatrix’ Pizza (o al menos creemos que es un local de comida rápida, nadie lo sabe con seguridad), que está cerrado. Tras la ventana hay un bote de pastillas (referencia al Larry I, jejeje…). Los chicos deben usar el martillo para romper la ventana (¡los muy gamberros!) y coger el bote de pastillas (recompensa pequeña: animación), pero para huir con ellas, tiene que distraer al personaje que está quieto cerca. (Distraer y arrebatar).

El bote de pastillas tiene una etiqueta que indica peligro. Si Moe se come las pastillas, caerá muerto (Mato a mis personajes mucho, sé que es malo, pero no puedo evitarlo). Si hace que Wilbur se coma un puñado (Lo que es bastante probable porque Moe es un verdadero pelmazo), el pobre Wilbur empezará a vomitar y se quedará muy pálido el resto del juego. Se tiene que usar el mortero con el bote para moler las pastillas en una especie de polvo. (Inventario / puzzle de combinación).

En el restaurante, los niños ahora pueden usar el polvo con el plato de pasta (recompensa pequeña: animación). El cliente pensará que lo que están esparciendo sobre su comida es parmesano, por lo que lo agradece y empieza a comer. (Podía haber hecho un puzzle Quid Pro Quo aquí, pero preferí no hacerlo)

Cuando los niños dejan el restaurante, hay una cinemática (recompensa mediana) con una llamada al 112 del restaurante.

Los niños deben ahora volver al hospital, molestar al guardia, y después salir y esperar fuera. En unos segundos (esto es, menos de dos minutos), Lucca llega, cargando con el cliente inconsciente (recompensa pequeña: animación), y entra por las puertas del hospital. Dos sonoros disparos se escuchan, y un montón de maldiciones. (La secuencia divertida de antes hace al jugador recordar el efecto de entrar al hospital)

Otra cinemática con una llamada al 112 (recompensa mediana), y esta vez la policía ha sido avisada. Los niños deciden poner pies en polvorosa antes de que la policía llegue.

Tras esto, los niños pueden volver al restaurante, entrar en la cocinan y poner sus manos en la tarta. ¡No!, las puertas del restaurante están cerradas. Cuando la policía haya precintado el hospital y llevado al guardia de nuevo al cuartel general, los niños pueden entrar de nuevo al hospital (usando las tijeras para cortar la cinta de “Zona policial no cruzar”) y entrar en la morgue (recompensa final: nueva localización). También encontrarán el delantal ensangrentado del chef en el suelo, con las llaves del restaurante en su bolsillo. Viola.

Seguramente te has dado cuenta de que he incluido bastantes animaciones en puzzles menores. Esta es la clave, en mi opinión, si quieres mantener a tus jugadores interesados. También, intenta usar diferentes tipos de puzzles para que el jugador no se aburra haciendo lo mismo una y otra vez. Y finalmente, el jugador puede entrar al hospital en cualquier momento para descubrir el mal genio del guardia, lo que hace el puzzle algo menos lineal (y por supuesto, hay otros puzzles que resolver al mismo tiempo: algo que tiene que ver con el alcalde, sobornos y una gran empresa de investigación genética. Eh, los clichés son buenos).