ACERCA DE VIDEOJUEGOS

TIPOS DE JUEGOS

El género de disparos (o ‘Shooter’) engloba un amplio número de subgéneros que tienen la característica común de permitir controlar un personaje que, por norma general, dispone de un arma (mayoritariamente de fuego) que puede ser disparada a voluntad.
Características de los shooters
Hay varios criterios para determinar el tipo de un Shooter. A continuación se listan las principales características. En base a ellas, es posible clasificar prácticamente todos los shooters desarrollados hasta la fecha:
Perspectiva
El jugador puede ver acción en primera persona (First Person Shooter) o desde una cámara que sigue al personaje por la espalda desde una cierta distancia y elevación (Third Person Shooter). También es possible (aunque poco frecuente en el género) encontrar juegos que disponen de una cámara fija.
Realismo
Los juegos que hacen uso de elementos “realistas”, como pueden ser armas que existen en la realidad, o la simulación del daño del personaje, se suelen llamar shooters tácticos. Aquellos que permiten más libertad respecto a escenarios, objetos, o la física del juego son conocidos como shooters arcade. No hay una clara distinción entre ambos tipos, estando la mayoría de los shooters en un abanico entre ambos.
Número de personajes
Mientras que la mayoría de los shooters se juegan con un solo personaje, algunos ofrecen la oportunidad de controlar un grupo de personajes; generalmente manejando a uno y dando órdenes a los demás. Los juegos en los que aparece un grupo de personajes ayudando al principal, pero que no son manejables, no se consideran juegos en grupo.
Multjugador
Si el shooter se hace uso de internet, se puede catalogar en una serie de divisiones: Los juegos en equipo son aquellos en los que cada jugador es asignado a un equipo entre varios (2 o más) para conseguir un objetivo. Para ello, los jugadores deberán colaborar entre sí para ganar. Los juegos cooperativos tienen a numerosos jugadores jugando o bien en solitario o bien en compañía. En los juegos individuales todos los jugadores compiten contra todos. Algunos juegos permiten elegir el modo de juego al que se desea jugar entre estos tres tipos.
Temática
Es una manera opcional de clasificar un shooter, pero en ocasiones es necesaria para distinguirlo. Un shooter puede estar enfocado a la infiltración en lugar de la acción. Otros pueden tener elementos de terror.
First-person shooters
Los First-person shooter (también conocidos como FPS)se caracterizan por una vista en pantalla que simula el punto de vista del personaje. Es uno de los subgéneros más populares, perteneciendo a él juegos de gran éxito como Doom, Quake, Half-Life, GoldenEye 007, F.E.A.R., Halo, y Pre.

TIPOS DE VIDEOJUEGOS: ESTRATEGIAS, DEPORTES, ETC.

• Aventura: Juegos en los que el protagonista debe avanzar en la trama interactuando con diversos personajes y objetos. Según su temática y desarrollo pueden clasificarse en diferentes subgéneros como la aventura de acción, la aventura gráfica, las videoaventuras (hoy día más conocidas como survival horror) o las aventuras conversacionales, hoy día mucho menos frecuentes que antaño. También suelen ser incluidos en esta sección los videojuegos conocidos como Simuladores de Mafioso ó Aventuras de Mafioso (como Grand Theft Auto). Ejemplos respectivos a cada uno de estos subgéneros podrían ser Tomb Raider, Metal Gear ó Soul Reaver, como aventuras de acción; Maniac Mansion, Broken Swo ó Monkey Island, como aventuras gráficas; La Abadía del Crimen, Little Big Adventure (LBA), Resident Evil ó Silent Hill, como videoaventuras, (de las cuales las dos últimas serían consideradas por su temática y estilo como Survival Horrors, subgénero del que se considera como el iniciador al clásico y archiconocido Alone in the Dark); en las aventuras conversacionales, tendríamos clásicos de los microordenadores como Chichen Itzá o La Aventura Espacial; y como estilos más inclasificables Pocahontas (videojuego), Shadow of the Colossus ó Grand Theft auto.

Si bien es cierto que en el pasado el género Aventura comprendía una gama de subgéneros y estilos más amplia aún si cabe que la que con el paso del tiempo y hasta la actualidad se ha ido consolidando, en la que se podían incluir juegos de lo más variados, muchos de los cuales hoy día consideraríamos pertenecientes a otros estilos como Plataformas, Rompecabezas e incluso Acción, sirviendo en cierto modo como género abanico, para una época en la que apenas si se habían empezado a desarrollar ciertas fórmulas, sin que estas estuvieran aún lo suficientemente desarrolladas como para reclamar nuevos géneros a los que pertenecer por derecho.

• Deportivo: Son los videojuegos basados en deportes, ya sean reales o ficticios, y se pueden subdividir en simuladores (juegos realistas) o los llamados "arcade" (más fantasiosos). Ejemplos: Fifa series, NBA Live, NFL Street, Pro Evolution Soccer, Pc Fútbol, Tony Hawks.
• Disparo: También conocidos como "Shooters" o "Shoot'em up" (en inglés, dispárales). En estos juegos el protagonista ha de abrirse camino a base de disparos. Según su temática y desarrollo pueden clasificarse en diferentes sub-géneros como la acción en primera persona o "FPS", los matamarcianos o los juegos de pistola. Ejemplos respectivos: Doom, Quake, Hexen, TimeSplitters ó Counter Strike como FPS; Galaxian, 1942 (videojuego), R-Type, Thunderforce ó Super Thunderblade como matamarcianos; y House of Dead ó Virtua Cop como juegos de tiro o de pistola.
• Educativo. Juegos cuyo objetivo es transmitir al jugador algún tipo de conocimiento. Su mecánica puede abarcar cualquiera de los otros géneros.
• Estrategia. Se caracterizan por la necesidad de manipular a un numeroso grupo de personajes, objetos o datos para lograr objetivos varios. Según su temática los hay de gestión (ya sea esta económica o social) y bélicos, mientras que por su mecánica pueden ser en tiempo real, también llamados "RTS" (Real Time Strategy), o por turnos. Ejemplos: Stratego, Dune 2, Starcraft, Age of Empires, Civilizati, Empire Earth, Advance Wars, Europa Universalis, Sim City, Zoo Tycoon y la saga Worms.
• Lucha: Juegos basados en el combate físico. Se dividen en juegos de 1 contra 1 o "versus" y juegos de avanzar y pegar o "beat'em up". Ejemplos: Tekken, Street Fighter, Fatal Fury, King of Fighters, Killer Instinct, Soul Calibur; y Golden Axe, Final Fight, Bouncer ó Streets of Rage.
• Plataformas: Juegos en los que el protagonista ha de avanzar a través de un mapeado con múltiples alturas. Ejemplo: Sonic the Hedgehog, Super Mario Bro., Alex Kidd,Megaman,Crash Bandicoot, Jak and Daxter.
• Rompecabezas: Juegos basados en los reflejos y diferentes formas de la inteligencia formal. Es un género muy amplio, abarcando juegos con concepciones y funcionamientos muy diferenciados. Ejemplo: Tetris, Column, Bubble Bobble,Lemmings,Snow Bros.
• Rol: También llamados RPG (Role Playing Games), se basan en los juegos de rol clásicos, donde el protagonista interpreta un papel y ha de mejorar sus habilidades, mientras interactúa con el entorno, objetos y otros personajes. Entre ellos encontramos los roguelike, los MMORPG como World of Warcraft o los MUD. Una nueva evolución son los Tácticos, a medio camino entre el género de estrategia y el rol, en los que controlamos a los personajes en un mapeado: se les conoce como Strategic RolePlaying Games. Ejemplos: Final Fantasy, Dragon Quest, Legend of Zelda, The Elder Scrolls, Chrono Trigger, Legend of Mana, Suikoden.
• Musicales: Su desarrollo gira en torno a la música ya sean de tipo "karaoke" como Singstar Party o en los que se debe bailar, en la línea del pionero DDR Dance Dance Revolution Ejemplo: Pump It Up, Electroplankton, Rhythm Tengoku, Sound Voyager, Space Channel. No obstante, es un género con un catálogo poco extenso, por lo que se suele incluir en el recientemente llamado género de 'party games', o juegos creados para su uso multijugador. Ejemplos: Bust a Groove, Mario Party, Fuzion Frenzy.
• Simulación: Juegos basados en la reproducción, generalmente de forma realista, del funcionamiento de alguna actividad. Diferentes subgéneros son los simuladores de vuelo, de conducción o de carros de combate. A dia de hoy fue inventado la "simulación social". Ejemplos: Ace Combat, Silent Hunter, IL2 Sturmovi, Microsoft Flight Simulator, Ship Simulator, Trainz Simulator Los Sims.
• Carreras ó Velocidad: Son juegos en los que se pilotan diferentes vehículos, ya sean reales o ficticios, para ganar en diferentes carreras, dentro de este apartado se pueden distinguir dos variantes, arc como Crash Team Racing y simuladores como Gran Turismo. Otros ejemplos: Mario Kart, Wipeout, Top Gear, TrackMania.
• Acción: Son juegos en los que se mezclan el shooter o (juego de disparos), simuladores y carreras. Están ambientados en la guerra, son juegos en los que se tiene que hacer un objetivo, pudiendo ser desde capturar una bandera (o base), hasta disparar a un determinado personaje del videojuego. En este tipo de videojuego suelen haber tanques, barcos, aviones, coches, etc..., suelen ser de mapas (o ambientación) muy grandes. Según su mecánica y/o linealidad de desarrollo pueden subclasificarse como Acción ó Acción 3D. Ejemplos respectivos: Ghosts'n Goblins, Metal Slug, Battlefield 1942; MDK, Battlefield Vietnam, Operation Flashpoint, Gold Eye, Devil May Cry.
• video juegos de arcade: son juegos de video que se usan para montar un negocio muy rentable. Algunos juegos marvel vs capcom 1 y 2, tecmo w.c. 98
  

Géneros mixtos
Pese a los géneros ya enumerados, más consolidados y más claramente discernibles, existe además todo un conglomerado de nuevas fórmulas que, como en todo gran género en constante movimiento y cambio, no dejan de ir surgiendo y haciendo entrada en la escena, unas veces combinando elementos diversos de géneros ya existentes y perfectamente definidos, y otras introduciendo nuevos conceptos y planteamientos novedosos que, a medida que van siendo seguidos, imitados o desarrollados, pueden terminar dando lugar a todo un nuevo género, de pleno derecho, dentro del extenso sector. Así, a lo largo de la historia del videojuego podemos encontrarnos con un sinfín de títulos a menudo problemáticos a la hora de establecer clasificaciones cerradas, puesto que sus características los sitúan en puntos intermedios, haciendo de las fronteras entre géneros habitualmente asumidas algo un tanto difuso. Ejemplos de ello podrían ser: Tomb Raider (Saga) (plataformas/Shoot'em up/Aventura de acción), Half Life (Shoot'em up/Aventura de acción), Koudelka (video-RPG), Flashback: The Quest for Identy (videoplataformas/aventura de acción), Bishi-Bashi (habilidad), Dragon's Lair (aventura animada), Pacman (rompeabezas), etc.

Ejemplos del surgimiento de nuevos géneros a partir de experimentos iniciales podrían ser los Videojuegos Musicales, como Bust a Groove/Bust a Move o Parapa the Rapper, o a comienzos/mediados de los ochenta el género Plataformas, por fases avanzables, que posteriormente hemos conocido, respecto del plataformas primigéneo de pantalla fija (tipo Donkey Kong o Mario Bros.), que pasaría poco a poco a ser englobado dentro del género, más amplio, Rompecabezas, siendo a su vez muchos de estos incluidos junto con otros, al principio, dentro del género entonces muy diverso y heterogéneo de Aventura. La especialización que hoy conocemos, la cual convierte a muchas de las clasificaciones originales en poco menos que arbitrarias o inviables, no ha sido sino fruto de una paulatina profundización y desarrollo, acorde con los adelantos tecnológicos, de las distintas fórmulas iniciales que con el tiempo se fueron dando.

TIPOS DE VISTA EN LOS VIDEOJUEGOS

PRIMERA PERSONA. Los juegos de acción en primera persona, también llamados First Person Shooters (FPS) en inglés, son un género de videojuegos popularizado masivamente en años recientes. los jugadores y entusiastas sean capaces de crear sus propios niveles [1] Dos de los componentes de los ordenadores que son más fueron increíblemente aclamados por la crítica mundial, por su modalidad de juego extremadamente simple, pero increíblemente entretenida, que, después de todo, es el objetivo principal de todo este mercado.

Counter-strike, una modificación del ya comentado Half-Life, hizo que se popularizara un nuevo subgénero, los juegos en primera persona multijugadores por equipos.

El 2000 fue el año de lanzamiento de Deus Ex, un juego en primera persona para un solo jugador que mezclaba elementos de los juegos de rol y los juegos de aventura. Incluía muchas misiones que no formaban parte de la trama principal y existían múltiples maneras de completar cada misión. El juego también poseía un sistema de construcción de personajes similar al de un juego de rol donde ganabas puntos de experiencia por completar varios objetivos que podían ser gastados en mejoras para tu personaje.

En 2001 destaca Aliens vs. Predator lanzado por Foxinteractive. El jugador puede elegir ponerse en la piel de un marine estadounidense, un alien o un predator. El juego está caracterizado por su ambiente oscuro y terrorífico.

En 2002 fue lanzado Battlefield 1942, que supuso la consagración de los juegos en primera persona multijugador masivos, como World War II Online, y hizo que los vehículos controlados por el jugador se convirtiran en una característica estándar en los juegos en primera persona.

También en 2002 el juego Metroid Prime fue lanzado. Era un juego en primera persona para Nintendo Gamecube con un gran mundo que se centraba más en la exploración que en el combate. Fue denominado juego de Aventura en primera persona por los expertos debido a su enfoque en la exploración. El juego poseía unos gráficos de última generación y un sistema de elección de objetivos similar al utilizado en The Legend of Zelda: Ocarina of Time.

En 2004, Doom 3 (¡anunciado desde hacia cuatro años!) apareció. Hacia uso de complejas iluminaciones y efectos de sombras para crear una atmosfera lo más tensa y terrorífica posible al jugador. Otros proyectos ya han hecho uso de estas características que permiten explotar al máximo el potencial del hardware moderno. Un ejemplo de esto es el proyecto Tenebrae, una modificación del motor de Quake que implementa sombras y luces realistas y texturas con relieve.

Existen muchos intentos de combinar los géneros de acción en primera persona con los juegos de rol o la estrategia en tiempo real. La modificación Natural Selection unía un juego en primera persona multijugador con elementos de la estrategia en tiempo real. Wolfenstein: Enemy Terrytory también contenía algunos elementos de los juegos de rol, con un sistema de experiencia y habilidades que funcionaba incluso a lo largo de varios enfrentamientos.

Luego en octubre del 2005 salió Quake 4 que esta basado en el motor de Doom3 con muchas actualizaciones y optimizaciones, permitiendo escenarios tanto abiertos como cerrados (Doom 3 sólo tenia ambientes cerrados).

El futuro de este genero se verá Unreal Tournament 2007 que saldra en el segundo trimestre del 2007.

TERCERA PERSONA.

La tercera persona es una de las vistas más frecuentes de los videojuegos de estilo aventura gráfica, rpg, etc. Esta vista tiene como característica que el personaje que manejamos se ve de cuerpo entero y generalmente de espaldas. En juegos como Silent Hill, Resident Evil o casi cualquier Survival Horror se utiliza con frecuencia esta vista pues da más sensación de inmersión en el juego. Es ideal para juegos en los que la acción se basa más en la búsqueda de objetos o indicios para descubrir la trama del juego.

DESARROLLO DE HISTORIAS/ ANTECEDENTES

El desarrollo de videojuegos es la actividad por la cual se diseña y produce un videojuego, desde el concepto inicial hasta el juego en su versión final, el producto terminado.

Ésta es una actividad multidisciplinaria, que involucra profesionales de la informática, el diseño, el sonido, la actuación, etcétera.

El desarrollo de un videojuego generalmente sigue el siguiente proceso:

Concepción de la idea del juego

• Diseño
• Planificación
• Producción
• Pruebas
• Mantenimiento

El proceso es similar a la creación de software en general, aunque difiere en la gran cantidad de aportes creativos (música, historia, diseño de personajes, niveles, etc) necesarios. El desarrollo también varía en función de la plataforma objetivo (PC, celulares, consolas), el género (estrategia en tiempo real, rpg, aventura gráfica, plataformas, etc) y la forma de visualización (2d, 2.5d y 3d).

Concepción
En esta etapa es necesario definir los aspectos fundamentales que conformarán el videojuego, entre los que se encuentran:

• Género: Dentro de que género o géneros se va a desarrollar el juego. De no corresponder a un género conocido, se deben especificar las características
• Jugabilidad: Lo que generará diversión a la hora de jugarlo.
• Bocetos : Algunas ideas sueltas acerca de como debe lucir el juego en cuanto a personajes, ambientación, música, etc.

Diseño
En esta fase se detallan todos los elementos que compondrán el juego, dando una idea clara a todos los miembros del grupo desarrollador acerca de como son. Entre estos elementos tenemos:
Diseño de Arte
Abarca los elementos de:

• Historia: Forma en que se desenvolverán los personajes del juego y la historia del mundo representado avanza. No todos los juegos tienen historia.
• Sonido: Detallada descripción de todos los elementos sonoros que el juego necesita para su realización. Voces, sonidos ambientales, efectos sonoros y música.
• Interfaz: Es la forma en que se verán los elementos GUI y HUD, mediante los cuales el usuario interacturá con el juego.
• Graficos: Dependiendo de si el juego es 2d, 2.5d o 3d, en este apartado se deben especificar los sprites, tiles y modelos 3d a utilizar. Generalmente esta fase incluye un desarrollo conceptual y una especificación de las características de los modelos.
  

Diseño de mecánicas
Es la especificación del funcionamiento general del juego. Es dependiente del género y señala la forma en que los diferentes entes virtuales interactuarán dentro del juego, es decir, las reglas que rigen éste.
Diseño de programación
Describe la manera en que el videojuego será implementado en una máquina real (un PC, consola, celular, etc) mediante un cierto lenguaje de programación y siguiendo una determinada metodología. Generalmente en esta fase se generan diagramas de UML que describen el funcionamiento estático y dinámico, la interacción con los usuarios y los diferentes estados que atravezará el videojuego como software.

De toda la fase de diseño es necesario generar un documento llamado Documento de Diseño, que contiene todas las especificaciones de arte, mecánicas y programación.

Planificación
En esta fase se identifican las tareas necesarias para la ejecución del videojuego y se reparten entre los distintos componentes del equipo desarrollador. También se fijan plazos para la ejecución de dichas tareas y reuniones clave, con la ayuda de herramientas de diagramación de actividades como GANTT y PERT.

Producción
Aquí se llevan a cabo todas las tareas especificadas en la fase de planificación, teniendo como guia fundamental el documento de diseño. Esto incluye entre otras cosas la codificación del programa, la creación de sprites, tiles y modelos 3d, la grabación de sonidos, voces y música, la creación de herramientas para acelerar el proceso de desarrollo, entre otras.

Pruebas
Al igual que el software convencional, los videojuegos deben pasar por una etapa donde se corrigen los errores inherentes al proceso de programación y a diferencia de este, los videojuegos requieren un refinamiento de su característica fundamental, la de producir diversión de manera interactiva (jugabilidad). Generalmente esta etapa se lleva a cabo en dos fases:

• Pruebas Alpha: Se llevan a cabo por un pequeño grupo de personas, que con anterioridad estén involucradas en el desarrollo, lo que puede incluir artistas, programadores, coodinadores, etc. El propósito es corregír los defectos más graves y mejorar características de jugabilidad no contempladas en el documento de diseño.
• Pruebas Beta: Esta pruebas se llevan a cabo por un equipo externo de jugadores, bien sea que sean contratados para la ocasión o que sean un grupo componente del proyecto (grupo QA). De estas pruebas el videojuego debe salir con la menor cantidad posible de defectos menores y ningún defecto medio o crítico.

GENEROS DE JUEGOS
Un género de videojuego designa un conjunto de videojuegos que poseen una serie de elementos comunes. A lo largo de la historia de los videojuegos aquellos elementos que han compartido varios juegos han servido para clasificar como un género aquellos que les han seguido, de la misma manera que ha pasado con la música o el cine.

Los videojuegos se pueden clasificar como un género u otro dependiendo de su representación gráfica, el tipo de interacción entre el jugador y la máquina, la ambientación y su sistema de juego, siendo este último el criterio más habitual a tener en cuenta.

La siguiente lista de géneros de videojuegos va acompañada de una breve descripción y varios ejemplos de cada uno. Hay que decir que cada vez es más es habitual que un juego contenga elementos de diversos géneros, cosa que hace difícil su clasificación. Uno de los mejores ejemplos de este fenómeno son los juegos de la série Legend of Zelda, que contienen a la vez elementos de acción, de aventure y de juego de rol. Esta fusión de géneros crea a su vez nuevos géneros, como es el caso de lo survival horror como Resident Evil, que mezclan elementos de aventura gráfica con otros de shoot'em up.

CONCEPTOS

USABILIDAD

La usabilidad universal (del inglés usability) es la característica de un sistema que pretende ser utilizado por:

• el tipo o tipos específicos de usuario/s,
• la tarea o tareas que para las cuales el sistema se ha hecho, y
• el contexto en el que se da la interacción.

El "grado de usabilidad" de un sistema es, por su parte, una medida empírica y relativa de la usabilidad del mismo.

• Empírica porque no se basa en opiniones o sensaciones sino en pruebas (del inglés tests) de usabilidad, realizadas en laboratorio u observadas mediante trabajo de campo.
• Relativa porque el resultado no es ni bueno ni malo, sino que depende de las metas planteadas (por lo menos el 80% de los usuarios de un determinado grupo o tipo definido deben poder instalar con éxito el producto X en N minutos sin más ayuda que la guía rápida) o de una comparación con otros sistemas similares.

El concepto de usabilidad se refiere a una aplicación (informática) de (software) o un aparato (hardware), aunque también puede aplicarse a cualquier sistema hecho con algún objetivo particular.

El modelo conceptual de la usabilidad, proveniente del diseño centrado en el usuario, no está completo sin la idea utilidad. En inglés, utilidad + usabilidad es lo que se conoce como usefulness.

Actualmente la usabilidad está reconocida como un importante atributo de calidad del software, habiéndose ganado un puesto entre atributos más tradicionales como el rendimiento y la fiabilidad. Incluso diversos programas de estudios se centran en ella. También han surgido diversas empresas de consultoría de usabilidad, y las firmas tradicionales de consultoría y diseño están ofreciendo servicios similares. Entre los principales beneficios encontramos:

• Reducción de los costes de aprendizaje.
• Disminución de los costes de asistencia y ayuda al usuario.
• Optimización de los costes de diseño, rediseño y mantenimiento.
• Aumento de la tasa de conversión de visitantes a clientes de un sitio web.
• Mejora la imagen y el prestigio.
• Mejora la calidad de vida de los usuarios, ya que reduce su estrés, incrementa la satisfacción y la productividad.

Todos estos beneficios implican una reducción y optimización general de los costes de producción, así como un aumento en la productividad. La usabilidad permite mayor rapidez en la realización de tareas y reduce las pérdidas de tiempo.

Un caso real, después de ser rediseñado prestándose especial atención a la usabilidad, el sitio web de IBM incrementó sus ventas en un 400% (InfoWorld, 1999).

JUGABILIDAD

Jugabilidad es un adjetivo calificativo que es usado en la valoración de un videojuego. Se refiere a todas las experiencias de un jugador durante la interacción con sistemas de juegos.

Surgiendo junto con el desarrollo de diseñadores de juegos en los años 1980, la jugabilidad era usada solamente en el contexto de los videojuegos, aunque ahora por su popularidad ha comenzado a verse el uso en la descripción de otras formas de juegos más tradicionales.

Los problemas que influyen en decir que la jugabilidad es mala, son:

• Retraso (LAG) entre lo que el jugador ordena hacer y lo que se vé en el juego.
• Que la animación (no la calidad gráfica) del personaje no sea buena (generalmente porque usa pocos cuadros consecutivos para mostrar cada acción), es decir en un momento dado no se pueda observar perfectamente que está haciendo el personaje como para mantener fluidamente el feedback en la interacción entre el jugador y el juego.
• Limitaciones del tipo: Si estoy haciendo el movimiento "A" NO pueda pasar rápidamente al movimiento "B" salvo que primero pase por el movimiento "C" y siendo este último movimiento una acción tal que no concuerde con la normal dinámica que se desarrolla en el juego (por ejemplo cuando el paso por el movimiento "C" es obligatorio debido a un olvido del programador del juego de prever la situación de pasar del movimiento "A" al "B" directamente).

En fin, hay un montón de pequeños detalles que hacen a una buena o mala jugabilidad. Cabe destacar que la misma no es afectada por la generación a la que pertenezca el juego, sino por la calidad y empeño que los programadores hayan puesto en el código del gameplay del juego.

MÁQUINA DE JUEGO

Las maquinas de juego son conocidas bajo diferentes nombres - slot, slot machine, poker machine o fruit machine, pero también „el bandido de una mano“. Slot machine se utiliza en el inglés americano, poker machine en el inglés australiano y fruit machine en el inglés británico. En general esto es un equipo que trabaja con monedas. El jugador echa una moneda, ala la palanca y los cilindros giran.

La maquina tiene un mecanismo llamado detector de moneda, es decir que el jugador tiene que echar una moneda real de lo contrario no funciona. La maquina se llama también „bandido de una mano“ debido a la palanca que tiene.

Los cilindros se alinean después de que la palanca sea halada y muestran símbolos, figuras o colores en la parte de alante donde está el jugador. Si los símbolos, figuras o colores se alinean en cierto orden, el jugador gana en dependencia de lo que apostó. Con el desarrollo de la tecnología cambiaron también las maquinas de juego. Aceptaban monedas y billetes, utilizaban botones para empezar el juego, si el jugador no quería tirar la palanca.

HISTORIA DE LAS MAQUINAS DE JUEGO

Ya que las maquinas son principiantes en el escenario de juego, hay ciertas dudas en cuanto a su historia y desarrollo. Las primeras maquinas surgieron alrededor del 1870. Aunque Charles Fey desarrollo la primera maquina alrededor del 1894 y esta no fue la primera maquina de juego, se considera el padre de las maquinas de juego.

Fey era de origen de Baviera en Alemania y en su vida hubo unos cuantos cambios felices que al final lo llevaron a emigrar a América. Primero se asentó en New Jersey y luego se mudó a California. A los 20 anos de su vida se enfermó de tuberculosis. Los médicos le daban un año de vida pero él logró mentirle a la muerte y cambiar el desarrollo de la historia del juego.

En el año 1895 creó la primera maquina de juego. Sus primeros descubrimientos los podemos ver hasta hoy en algunos equipos modernos. Durante su actuación en Munich en la fabrica de herramientas de agricultura descubrió un gran entusiasmo en si mismo por cualquier mecanismo y así nació el mecánico – entusiasta.

La historia de las maquinas de juego se puede dividir en tres épocas significantes de las cuales cada una dejó huellas en la industria actual:

• Era mecánica.
• Era electromecánica.
• Era de informática

El prototipo del equipo mecánico de Fey utilizaba cartas y no frutas como lo vemos hoy. Pero utilizaba sonidos de campana siempre que el jugador ganaba – y esto se ha quedado hasta el día de hoy.

Fey es conocido más por su maquina de juego La campana de la libertad de hierro fundido. Cada uno de los tres cilindros tenía diez figuras. Tres símbolos iguales en un nivel significaban ganar el jackpot. El chance de ganar el jackpot era 1:1000.

MOD O MODDING

En el mundo de los videojuegos un mod (del inglés modification) es una extensión que modifica un juego original proporcionando nuevas posibilidades, ambientaciones, personajes, diálogos, objetos, etc.

Prácticamente todos los juegos modernos incorporan herramientas y manuales para que exista la posibilidad de modificarlos y así crear el mod.

Aunque anteriormente las comunidades de modders (creadores de mods) eran no oficiales y no pasaban de más de un grupillo de gente, actualmente se ve el interés de las compañías en tener una base de fans que no sólo juegue, si no que además cree estos contenidos no oficiales para extender la vida de los juegos durante, en algunos casos, muchos años más. Actualmente se puede ver a las compañías dando el primer empujón a las comunidades de modders, dándoles las herramientas, los tutoriales y el soporte necesario para que los fans se involucren más en los juegos.

DIAGRAMA DE FLUJO DE DATOS

Modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software. Los rectángulos representan entidades externas, los rectángulos abiertos almacenes (archivos), los círculos procesos y la flechas un flujo de datos desde (o hacia) cualquier elemento a (o desde) un proceso.

Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Los procesos se etiquetan con un número y un verbo en infinitivo (con complemento). Un diagrama de flujo de datos (DFD) puede ser expandido dividiendo (expandiendo) algunos de sus procesos en subprocesos, en este caso la etiqueta tendrá un número adicional. No hay un límite para el número de procesos.

UML

¿Qué es UML?

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real.

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir

Objetivos de UML

• UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores. No tiene propietario y está basado en el común acuerdo de gran parte de la comunidad informática.
• UML no pretende ser un método de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una sólida arquitectura para resolver requisitos dirigidos por casos de uso.
• Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo suficientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribución, así como también los mecanismos de la ingeniería de software, como son la encapsulación y componentes.
• Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
• Imponer un estándar mundial.

DIAGRAMAS Y VISTAS EN UML

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

• Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.
• Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.
• Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.
• Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.
• Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. Se dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica.
Los diagramas estáticos son:

• Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.
• Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.
• Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
• Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.
• Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

Los diagramas dinámicos son:

• Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.
• Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
• Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
  Se puede observar que el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos.
  

CICLO DE VIDA DEL SOFTWARE

Ciclo de vida del software

Es el proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea, hasta la entrega y el retiro del sistema.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.

Modelo de un ciclo de vida del software

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre dichas etapas.
Un modelo de ciclo de vida del software:

• Describe las fases principales de desarrollo de software,
• define las fases primarias esperadas de ser ejecutadas durante esas fases,
• ayuda a administrar el progreso del desarrollo y,
• provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Tipos de modelos de un ciclo de vida del software

Modelo Cascada

Este el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida.
Este modelo dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase.

Un modelo de ciclo de vida cascada, tiene algunos principios básicos:

• Planear un proyecto, antes de embarcarse en él.
• Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
• Documentar los resultados de cada actividad.
• Diseñar un sistema antes de codificarlo.
• Someter a un control o prueba un sistema después de construirlo.

Modelo de Desarrollo Incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

Algunos de los beneficios que proporciona el desarrollo incremental para los proyectos son:

• Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
• Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
• Si un error importante es realizado, solo la última iteración necesita ser descartada.
• Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
• Si un error importante es realizado, el incremento previo puede ser usado.
• Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo de Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

Modelo de Prototipado de Requerimientos

El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos).
En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.

Modelo Espiral

El modelo espiral de los procesos software es un modelo del ciclo de meta−vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, se pueden pueden seguir estos cuatros pasos:

• Determinar que se quiere lograr.
• Determinar las rutas alternativas que se pueden tomar para lograr esas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
• Seguir la alternativa seleccionada en el paso 2.
• Establecer que se tiene terminado.

El modelo espiral tiene algunos principios básicos:

• Decidir qué problema se quiere resolver antes de viajar a resolverlo.
• Examinar las múltiples alternativas de acción y elegir una de las más convenientes.
• Evaluar qué se tiene hecho y qué se tiene que haber aprendido después de hacer algo.
• No ser tan ingenuo para pensar que el sistema que se está construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que se tendran que tolerar.

Modelo Concurrente

Como el modelo espiral, el modelo concurrente provee una meta−descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.

LA CRISIS DEL SOFTWARE Y SUS POSIBLES SOLUCIONES

Crisis del Software

La expresión «crisis del software» es recurrente en mucha bibliografía técnica, tanto que ya suena a expresión vacía. El caso es que esta crisis existe y para ello basta comparar el desarrollo del hardware y su relación coste/potencia con el del software. En el hardware hay una reutilización sistemática y ahorros de coste continuos a merced de la reducción de materias primas en cada generación de productos, la reutilización de diseños previos, las economías de escala, etc. En el caso del software, donde todas las economías podrían ser de escala, al menos en teoría, no solo no ha ocurrido así sino que el coste no solo no se ha mantenido sino que ha aumentado. Y por otro lado la productividad que ofrece es muy limitada: hoy día el mundo del software ofrece aplicaciones, no soluciones, no se adapta a la forma natural de trabajar de los seres humanos y son sólo poderosas herramientas, a veces incluso sobredimensionadas, en lugar de adaptarse a las actividades del ser humano.

Un fenómeno muy importante es el del despilfarro económico que muchas sociedades realizan con la idea de avanzar en la inclusión digital. Es conocida la ley de Moore, que aún hoy marca la pauta del incremento regular de la relación potencia/coste del hardware. Menos conocida es la de Gilder aplicada de manera semejante a la conectividad. El resultado es que en tres años el hardware es obsoleto incluso a efectos contables. Eso no sería un problema si se hubiera podido amortizar tanta potencia con soluciones software. Pero esas soluciones no existen. Siguen siendo aplicaciones de «bajo nivel».

La crisis del software es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que además excede los presupuestos y los horarios de tiempos. La industria del software no ha podido satisfacer la demanda. La complejidad del software producido y demandado se incrementa constantemente. El software es solicitado para ejecutar las tareas demandantes de hoy y está presente en todos los sistemas que van desde los más se los más sencillos hasta los de misión crítica. Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos días, las aplicaciones típicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software.

El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN (Organización del Tratado del Atlántico Norte) sobre desarrollo de software; y con él se etiquetaron a los problemas que surgían en el desarrollo de sistemas de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software" para describir el conjunto de conocimientos que existían en aquel estado inicial. Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son:

• En 1962 se publicó el primer algoritmo para búsquedas binarias.
• C.Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de "GoTo" y la creación de la programación estructurada.
• En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful" en 1968.
• La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens.
• El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb.
• El primer libro sobre análisis de requisitos apareció en 1979.

El término fue usado para referirse a los rápidos incrementos de la tecnología en la computación y la complejidad de los problemas a los cuales pudieran enfrentarse. En efecto, se refiere a la dificultad de escribir correcta, entendible y verificablemente los lenguajes de programación. Las raíces de la crisis del software son complejas y variables.

"Síntomas"

Uno de los principales problemas en el desarrollo de software de hoy en día es que muchos proyectos empiezan la programación tan pronto se definen y concentran mucho de su esfuerzo en la escritura de código. Últimamente el desarrollo de software se ha relentizado. El estudio de este fenómeno es importante porque la existencia de software científico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo.

Algunos “síntomas” que indican que el software se encuentra en un periodo de crisis son:

• Baja Calidad del Software.
• Tiempo y Presupuesto Excedido.
• Confiabilidad Cuestionable.
• Altos Requerimientos de Personal para desarrollo y mantenimiento.

Factores de Influencia

Para poder llevar el estado del proceso de software como un estado de crisis, los críticos han destacado ciertas características que han permitido esta postura del software respecto a otras etapas de su corta historia. Algunos de esos factores son:

• Aumento del poder computacional.
• Reducción del costo del hardware.
• Rápida obsolescencia de hardware y software.
• Aceptación de la computarización en las empresas.
• Incremento en el número de usuarios de los sistemas de software.
• Tipo de usuario no homogéneo aun en sistemas hechos a la medida.
• Personal de desarrollado y mantenimiento diferente.
• La magnitud del proyecto impacta en:
• Tiempo costo y número de desarrolladores,
• Control administrativo y detalles técnicos
• Aumento en el conocimiento del problema.
• Cambios en el entorno:
• Tecnológicos (Internet, redes, ERP, CRM, SCM).
• Económicos (crisis económicas, globalización, etcétera).
• Sociales (nuevas necesidades, costumbres nuevas, etcétera).

Posibles causas de la crisis del software

Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en común que son causadas por el método de valorar los avances científicos y el mecanismo actual de financiación de la actividad científica. Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa madurez de la ingeniería de software como una profesión. La crisis se manifestó a sí misma en varias maneras:

• Proyectos gestionados con un sobre-presupuesto.
• Proyectos gestionados con sobre tiempo.
• Software de baja calidad.
• El software a menudo no satisfacía los requerimientos deseados.
• Los proyectos fueron inmanejables, con un código difícil de mantener.

La crisis del software fue dirigida por la implementación de varios procesos y metodologías, siendo la más notable el modelo de cascada de Royce.

Posibles soluciones al problema del software científico

La primera solución puede ser la existencia de una licencia libre, mas que recoja las singularidades del software científico. Esta licencia debería compartir el espíritu de la GPL (General Public License es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios) y gran parte de su letra; y debería asegurar la preservación de las libertades propuestas por RMS. Por otro lado, también debería incluir algunas restricciones, fáciles de cumplir y que no limitan la libertad final del código según los criterios expuestos por RMS (Richard Matthew Stallman), como son:

• Si se usa el programa para realizar una investigación, y esa investigación termina en uno o varios artículos publicados, los artículos de dicha investigación deben reconocer qué programas fueron usados, así como citar los artículos en los que fueron descritos. Esta restricción no impide la libertad de libre uso, y, de hecho, la totalidad de los programas libres científicos la incluyen; este sistema hasta ahora parece funcionar. La principal objeción a esta restricción es similar a la crítica que RMS hizo a la licencia BSD ; sin embargo, en este caso no se produce el exceso de verborrea en las citaciones; ya que, en caso de que alguien pueda publicar un artículo en una revista indexada, por la naturaleza de revisadas por asesores externos de estas revistas, ha de ser cierta importancia la aportación al código.
• Si se modifica el código, se ha de identificar adecuadamente la parte modificada como tal. Esto no impide la libertad de modificación, mas permite que, en caso de que la modificación suponga una mejora en el rendimiento o la calidad de los resultados, el autor de la modificación tenga el debido reconocimiento; y, en caso de que la modificación introduzca errores, evita manchar el nombre del programa y del grupo que lo desarrolló.
• Por último, sería interesante abrir un debate en el seno de la comunidad del software libre sobre hasta qué punto es ético usar software libre para desarrollar ciencia no libre.

La segunda solución que puede tener el problema del software científico libre es la creación de una revista indexada destinada específicamente a productos cuya licencia sea libre.

La tercera solución es el apoyo de las instituciones gubernamentales. En una primera solución, financiando proyectos libres, como ya hace el gobierno alemán, solo que en el área de software científico libre. Otra posibilidad es abrir grandes proyectos temáticos de software libre científico.

La última solución, es que aquellos proyectos financiados con dinero del estado deben ser libres.

La última corresponde a la universidad: liberando los resultados de proyectos fin de carrera, de resultados de investigación y de tesis de doctorado bajo GPL de documentación, y el código desarrollado bajo una hipotética GPL científica con las características anteriormente comentadas, ganamos todos. La comunidad porque cuenta con más código libre para compartir, y el investigador porque ve compensado su trabajo con el reconocimiento, los artículos y las citaciones que necesitará para conseguir becas y fondos para seguir investigando.