Humor Gamer: Um.. The Pin is… Never Mind

Parodia del videojuego Counter Strike.

Um.. La Clavija es… No Importa

Hey! Alguien arrojo esto?!?

Recomendación: Mantente alejado de los Noobs.

Fuente: http://www.vgcats.com/comics/?strip_id=6

Blogalaxia Tags: Parodia VideoJuego Counter Strike Noobs

Análisis y diseño (Parte 1): La metodología

El paradigma orientado a objetos es una nueva forma de pensar sobre programación y mucha gente tiene problemas la primera vez que escucha cómo se aborda un proyecto POO. Una vez que se sabe que, supuestamente, todo es un objeto, y cómo aprender a pensar al estilo orientado a objetos, puede empezar a crear “buenos” diseños que aprovechen las ventajas de todos los beneficios que ofrece la POO.

Un método (llamado a menudo metodología) es un conjunto de procesos y heurísticas usados para tratar la complejidad de un problema de programación. Desde el comienzo de la programación orientada a objetos se han formulado muchos métodos. Esta sección le dará una idea de cuál es el objetivo que se intenta conseguir cuando se usa una metodología.

Especialmente en POO, la metodología es un campo de muchos experimentos, así que antes de elegir un método, es importante que comprenda cuál es el problema que resuelve. Eso es particularmente cierto con C++, en el que el lenguaje de programación pretende reducir la complejidad (comparado con C) que implica expresar un programa. De hecho, puede aliviar la necesidad de metodologías aún más complejas. En cambio, otras más simples podrían ser suficientes en C++ para muchos tipos de problemas grandes que podría manejar usando metodologías simples con lenguajes procedurales.

También es importante darse cuenta de que el término “metodología” a menudo es demasiado grande y prometedor. A partir de ahora, cuando diseñe y escriba un programa estará usando una metodología. Puede ser su propia metodología, y puede no ser consciente, pero es un proceso por el que pasa cuando crea un programa. Si es un proceso efectivo, puede que sólo necesite un pequeño ajuste para que funcione con C++. Si no está satisfecho con su productividad y con el camino que sus programas han tomado, puede considerar adoptar un método formal, o elegir trozos de entre muchos métodos formales.

Mientras pasa por el proceso de desarrollo, el uso más importante es éste: no perderse. Eso es fácil de hacer. La mayoría de los análisis y métodos de diseño pretenden resolver los problemas más grandes. Recuerde que la mayoría de los proyectos no encajan en esta categoría, normalmente puede tener un análisis y diseño exitoso con un subconjunto relativamente pequeño de lo que recomienda el método. Pero muchos tipos de procesos, sin importar lo limitados que sean, generalmente le ofrecerán un camino mucho mejor que simplemente empezar a codificar.

También es fácil quedarse estancado, caer en análisis-parálisis, donde sentirá que no puede avanzar porque en la plataforma que está usando no está especificado cada pequeño detalle. Recuerde, no importa cuánto análisis haga, hay algunas cosas sobre el sistema que no se revelan hasta el momento del diseño, y más cosas que no se revelarán hasta que esté codificando, o incluso hasta que el programa esté funcionando. Por eso, es crucial moverse bastante rápido durante del análisis y diseño, e implementar un test del sistema propuesto.

Fuente: Thinking in C++ (Volumen 1) por Bruce Eckel.

Blogalaxia Tags: metodología POO lenguajes procedurales proceso de desarrollo análisis parálisis productividad codificar programación

Conceptos de Desarrollo (Parte 7): Conclusiones

Desarrollos como Commandos 2, Blade, Torrente el Juego, o toda la saga de juegos que desarrolló Dinamic Multimedia (que lamentablemente cerro sus puertas) demuestran que en España la formación no es un handicap, ni mucho menos. La creatividad y calidad de los juegos españoles es en muchos casos de admiración en el resto de Europa, Estados Unidos y Japón. Como siempre, el problema es de tipo económico.

Actualmente, se ha demostrado que con o sin dinero y muchas ganas, se pueden crear joyas de gran calidad. Lejos de creer que la programación es un misterio insondable, la verdad es que es un reto tan complejo como cualquier otro; no se requieren dotes especiales, ni se ha de ser un genio para poder llevar a cabo un proyecto. Eso sí: el trabajo, y sobre todo la constancia, son la clave del éxito. Por no mencionar que no se debe rendir nadie ante el primer fracaso, que a buen seguro llegará si se persevera.

De este modo, podrán crearse equipos de trabajo que permitan desarrollos en videojuegos que compitan de tú a tú con cualquier empresa. A veces, se tiene la impresión de una inferioridad totalmente injustificada. Es probable que los edificios de desarrollo no tengan el aspecto de palacios, como ocurre con algunos lugares de desarrollo americanos (véase el edificio de EA Sports en Canadá por ejemplo). Esto no debe importar nada en absoluto. Un garaje puede bastar. Lo importante es saber usar los medios de forma correcta, con ambición, y sabiendo administrar de forma correcta los recursos de los que se dispongan. Añádase un duro trabajo y una cantidad de tiempo razonable, y se obtendrán resultados que harán palidecer a equipos diez veces más grandes.

Conceptos del Motor Gráfico (Parte 4): Gráficos 3D en tiempo real

El modelado de gráficos en tiempo real es un proceso muy delicado. Hay que saber cuál va a ser exactamente el resultado final que se va a obtener después de exportar el objeto modelado al motor de tiempo real. Cuantas más cosas se conozcan acerca de cómo “piensa” un motor en tiempo real típico, mejores serán los resultados del trabajo inicial y se ahorrará mucho tiempo y frustraciones.

Los gráficos 3D en tiempo real y los gráficos 3D prerrepresentados de alta gama tienen muchos elementos en común. Sin embargo, para conseguir la velocidad necesaria para un juego, los gráficos en tiempo real deben usar únicamente los elementos indispensables; es decir, la geometría, las transformaciones y las propiedades de superficie de la malla. La mayoría de las veces, el que crea estos elementos es el programa de exportación (es decir, la aplicación de una tercera empresa que traduce el modelo original a un lenguaje que pueda comprender el motor de juegos). Luego, estos elementos se colocan en algún tipo de archivo de texto (o en un archivo en lenguaje C, antes de compilarlo para generar código binario), para que puedan ser editados manualmente, si es preciso. En ocasiones, estos elementos se pueden dividir en varios archivos independientes (uno para la geometría, uno para las propiedades de superficie y uno para las transformaciones), que se combinan cuando se compila el archivo para el motor de juegos.

Actualmente existen varios plug-ins que permiten al usuario exportar los elementos directamente desde un programa de modelado 3D (Maya, 3D Studio Max, Lightwave 3D, etc.) a los formatos de diferentes consolas de videojuegos y a formato DirectDraw. Los desarrolladores de las empresas de juegos para PC, como Sierra Studios e ID, han creado herramientas de exportación que permiten diseñar mapas 3D en programas de modelado 3D y luego exportarlos a sus propios formatos de juego, como el Quake o Half-life. Se están creando continuamente plug-ins para admitir toda la infinidad de formatos gráficos en tiempo real que se usan en los juegos. La mayoría de las interfaces de programación de aplicaciones (API, Application Programming Interface) para gráficos 3D en tiempo real proporcionan un convertidor propio que funciona con formatos conocidos, como 3DS o DXF. En muchos sitios web de Internet hay disponibles convertidores de distribución gratuita para exportar archivos OBJ o VRML.

La API de un motor en tiempo real suele constar de un conjunto de herramientas, comandos, o ambas cosas, para que los desarrolladores independientes puedan trabajar con el producto de una determinada empresa. En los juegos en tiempo real, la API permite a los desarrolladores de juegos emplear el motor de juegos 3D como base sobre la que crear sus programas usando sus propios comandos personalizados, que se comunican con el hardware a través de la API.

La geometría es exactamente lo que cabría esperar: una lista de posiciones numeradas de vértices en el espacio 3D, seguida de una lista de las maneras de conectar esos vértices para formar polígonos triangulares coherente. El lado de la normal (o lado visible) del polígono se determina de dos maneras: por el orden en el que se eligen los vértices de los que está compuesto el polígono, o bien por una lista independiente de normales de vértices, que se adjunta a la lista de construcción de polígonos.

La mayoría de los motores en tiempo real usan caras triangulares. Algunos sistemas usan polígonos cuadriláteros para el modelado. Otros sistemas permiten definir polígonos cuadriláteros o de cualquier otro tipo, pero los dividen en triángulos en tiempo de representación. Aunque estos métodos existen, los mejores resultados se obtienen por medio de caras triangulares predefinidas. Este tipo de caras requiere más espacio de almacenamiento que los polígonos cuadriláteros o de otro tipo, pero las caras triangulares suelen representarse más rápidamente y siempre se visualizan correctamente.

La operación de exportación del modelo original al motor de juegos suele ser siempre un poco complicada y requiere una gran cantidad de ajustes. Los programas de modelado más potentes suelen añadir información no utilizable por el motor en tiempo real, a través de sus formatos propietarios. La mayor parte de esta información es invisible. Ésta información puede tener efectos drásticos en el modelo en tiempo real exportado, provocando que se dibuje en la orientación o posición erróneas, o bien que no se comporte correctamente cuando se anima en el motor de juegos. Generalmente, las áreas más problemáticas de la exportación suelen ser las propiedades de superficie y las transformaciones. Sin embargo, este tipo de obstáculos se pueden evitar si un desarrollador crea una herramienta de exportación personalizada que funcione directamente desde el programa de modelado 3D.

Un poco de historia: SEGA (Parte 2)

Historia

SEGA nace en 1940 de la unión de las compañías: Service Games y Rosen Enterprises, Ltd. De la primera, se tomaría el nombre. Esta se dedicaba a la venta de gramolas para las bases militares americanas, mientras que la segunda era una empresa de importación de arte y otros productos fundada en Japón por Dave Rosen durante 1953. Rosen llevaba desde 1956 importando juegos recreativos y llegó a colocar 5.000 de ellos por todo el Japón, pero cada vez estaba más desencantado con las máquinas traídas desde Estados Unidos así que decidió fabricar sus propios juegos fusionándose con Service Games, de donde surgió SEGA Enterprises, Ltd.

SEGA debutó con Rifleman, un juego mecánico que simulaba tiroteos en el lejano oeste, y para 1967 ya exportaba juegos a los Estados Unidos. El primer éxito de la compañía fue Periscope (1968), un simulador de submarinos, y su último juego mecánico fue Jet Rocket (1970). A partir de ahí SEGA se dedicó a los juegos electrónicos y a las recreativas, produciendo de 1967 a 1979 un total de 140 juegos diferentes. En 1980 SEGA compró a Gremlin, un fabricante de máquinas recreativas, y se metió en el mundo de los videojuegos domésticos licenciando algunos de sus juegos. En esa época Gulf & Western’s Paramount adquirió la compañía pero la vendió durante la crisis del videojuego, oportunidad que aprovechó Rosen junto con unos inversores japoneses para recuperar el mando.

Humor Gamer: Even MORE Filler?!

Parodia de Kratos del videojuego God of War.

¿El evento más completo?

Si lo hice, entonces aquí tienes cómo pasó.

por Kratos

Design Patterns: El patrón estado (State), cambiar el comportamiento del objeto

El patrón de diseño State se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo. Por ejemplo: una alarma puede tener diferentes estados, como desactivada, activada, en configuración. Definimos una interface Estado_Alarma, y luego definimos los diferentes estados.

En determinadas ocasiones, cuando el contexto en el que se está desarrollando requiere que un objeto tenga diferentes comportamientos según el estado en que se encuentra, resulta complicado poder manejar el cambio de comportamientos y los estados de dicho objeto, todos dentro del mismo bloque de código. El patrón State propone una solución a esta complicación, creando básicamente, un objeto por cada estado posible del objeto que lo llama.

Propósito

Permite a un objeto cambiar su comportamiento cuando cambia su estado. El objeto parece cambiar de clase.

Aplicabilidad

Use el patrón State cuando el comportamiento del objeto depende de su estado, y debe cambiar su comportamiento en tiempo de ejecución dependiendo de su estado, cuando las operaciones tienen grandes estructuras switch que dependen del estado del objeto, que es representado por uno o más constantes de tipo enumerado.

Participantes

El patrón State necesita de los siguientes elementos:

• Context (Contexto): Este integrante define la interfaz con el cliente. Mantiene una instancia de ConcreteState (Estado Concreto) que define su estado actual.
• State (Estado): Define una interfaz para el encapsulamiento de la responsabilidades asociadas con un estado particular de Context.
• ConcreteState (Estado Concreto): clases para cada uno de los estados en que puede estar, es una clase derivada de State y gestiona el comportamiento de la máquina para cada uno de los estados.

Implementación

Utilizar una clase abstracta que represente al objeto y su interfaz, implementar una subclase para cada uno de los estados y métodos para cada una de las transiciones posibles. Todas estas clases mantendrán una referencia al objeto que encapsule el estado o devolverán la instancia de la clase que representa el estado actual.

Esto permite añadir nuevos estados simplemente incorporando nuevas subclases.

La siguiente estructura de código muestra el patrón State (Estado) que permite a un objeto comportarse diferente dependiendo de su estado interno. La diferencia en el comportamiento es delegada a objetos que representan este estado.

Ejemplo

// Illustrates the State design pattern.
#include <iostream.h>

using namespace std;

class Machine
{

class State *current;

public:

Machine();
void setCurrent(State *s) { current = s; }
void on();
void off();

};

class State
{

public:

virtual void on(Machine *m) { cout << “   already ON\n”; }
virtual void off(Machine *m) { cout << “   already OFF\n”; }

};

void Machine::on() { current -> on(this); }

void Machine::off() { current -> off(this); }

class ON: public State
{

public:

ON() { cout << “   ON-ctor “; };
~ON() { cout << “   dtor-ON\n”; };
void off(Machine *m);

};

class OFF: public State
{

public:

OFF() { cout << “   OFF-ctor “; };
~OFF() { cout << “   dtor-OFF\n”; };
void on(Machine *m)
{

cout << “   going from OFF to ON”;
m -> setCurrent(new ON());
delete this;

}

};

void ON::off(Machine *m)
{

cout << “   going from ON to OFF”;
m -> setCurrent(new OFF());
delete this;

}

Machine::Machine()
{

current = new OFF();
cout << ‘\n’;

}

int main()
{

void(Machine:: *ptrs[])() =  { Machine::off, Machine::on };
Machine fsm;
int num;

while (1)
{

cout << “Enter 0/1: “;
cin >> num;
(fsm. *ptrs[num])();

}

}

Output:

OFF-ctor

Enter 0/1: 0

already OFF

Enter 0/1: 1

going from OFF to ON ON-ctor dtor-OFF

Enter 0/1: 1

already ON

Enter 0/1: 0

going from ON to OFF OFF-ctor dtor-ON

Enter 0/1: 1

going from OFF to ON ON-ctor dtor-OFF

Enter 0/1: 0

going from ON to OFF OFF-ctor dtor-ON

Enter 0/1: 0

already OFF

Enter 0/1:

Conceptos de Desarrollo (Parte 6): Fases de diseño en un videojuego

Cuando se acomete la realización de un videojuego, se requiere seguir unos pasos muy concretos, dentro de un plan maestro. Para ello, se han diseñado un conjunto de normas, conocidas como metodologías. Estas metodologías son de muy diversa índole, y cada una de ellas adecuada a un tipo de aplicación concreta. Aunque es un tema que podría llenar cientos de páginas, vamos a ver un resumen de los elementos necesarios y el orden a establecer para la exitosa conclusión del proyecto. Téngase en cuenta que muchos equipos no establecen estas metodologías como principio del trabajo, por lo que se ven abocados a proyectos caóticos, donde no se conoce el estado actual del proyecto, ni cuándo acabará. De forma muy general, cualquier proyecto debe acometer estas etapas:

1. Diseño del proyecto: en muchas ocasiones, los equipos de desarrollo no se preguntan de forma totalmente absoluta qué quieren hacer. Por ejemplo, se desea crear una aventura gráfica. Sí, pero esto es tan ambiguo como si un arquitecto se propusiera diseñar un bloque de apartamentos. Existen multitud de opciones, variantes, que deben ser tenidas en cuenta. Es por ello importante definir el proyecto, sobre todo el concepto de “alcance” es decir, hasta dónde se desea llegar. Esto es fundamental, ya que de lo contrario, la ambición desmedida puede hacer fracasar un proyecto, como ocurre a menudo. Téngase en cuenta que estudios actuales estiman que el 80 por ciento de los proyectos que se acometen acaban en sonados fracasos debido a una mala planificación inicial.

2. Diseño de los aspectos generales del proyecto: una vez el proyecto está definido, éste se descompondrá en elementos, llegando hasta un punto en el que se pueda concretar cada aspecto del juego. Los diferentes elementos que lo conforman tendrán una respuesta en un responsable, que se encargará de dirigir ese aspecto concreto. Así, elementos comunes suelen ser: la música, los gráficos, la inteligencia artificial, el diseño del storyboard, diseño de puzzles, diseño del interface, diseño de pruebas para betatesters, calidad del producto, versiones para cada plataforma donde se lance, y otros. En equipos grandes, una persona se encarga de cada uno de estos aspectos, en otros más reducidos pueden llevarse a cabo diferentes tareas por la misma persona. Se nombra entonces un director del proyecto, que a su vez nombrará a los responsables de cada área del producto.

3. Diseño de los aspectos técnicos: una vez se ha hecho un estudio general del proyecto, respondiendo a la pregunta “qué se desea”, se debe llevar a cabo la resolución de otra pregunta: “cómo se va a llevar a cabo”. Para ello, se han de responder a preguntas del tipo: plataformas en las que aparecerá, lenguaje de programación a ser usado, herramientas de diseño a ser usadas, motor gráfico que se empleará, y otros. También es importante en este momento que una persona actúe como coordinador del proyecto. Puede ser el mismo director del proyecto u otra persona. Su función es fundamental, ya que coordina que todos los aspectos del videojuego se conjuguen de forma correcta, antes de descubrir que el trabajo de un equipo es incompatible con el trabajo de otro equipo.

4. Pruebas unitarias y conjuntas: este punto está estrechamente relacionado con el anterior. Se requieren un conjunto de pruebas de stress, que permitan al equipo desarrollador conocer y comprobar los bugs que pueda tener el programa, para que éste no falle en ningún momento. Por otro lado, también en este momento se depuran las rutinas críticas del programa, las cuales permiten una ejecución a la máxima velocidad y de forma segura de los puntos clave de la aplicación. El objetivo final debe ser un producto totalmente estable y perfectamente diseñado. Téngase en cuenta que esta fase de pruebas puede llegar a consumir una gran parte del desarrollo de una aplicación.

5. Rediseño de elementos: además de localizar errores y perfeccionar aspectos del programa, es probable que en los puntos 3 y 4 se descubran que existen ciertos elementos que deben ser incluidos, bien porque no los fueron en la parte de diseño, bien porque se desean añadir nuevas funcionalidades, es decir, mejoras. En este momento se pueden llevar a cabo estas mejoras, pero ha de tenerse en cuenta que existe un presupuesto que debe ser mantenido, y estas mejoras provocarán que el ciclo se reinicie de nuevo, desde el punto 2, con lo que se pueden derivar costes que impidan su puesta a punto. Hoy en día, muchos de estos aspectos se dejan aparcados hasta la comercialización del producto, y si éste tiene éxito se añaden posteriormente en un parche. También puede ocurrir que ciertos elementos (como un modo multijugador por ejemplo) no fueran dimensionados de forma correcta, de manera que deban eliminarse del proyecto original, para poder mantener el presupuesto del proyecto, por lo cual, si los ingresos del producto lo permiten, se puedan añadir posteriormente.

Estos pasos, seguidos de forma estrecha, pueden ayudar a llevar a cabo un proyecto de desarrollo. Desde luego, estas metodologías no son la panacea ni garantía de éxito seguro, pero es evidente que no usarlas llevan a un estado de caos que puede hacer fracasar el proyecto, o alargarlo hasta que incida en unos costes prohibitivos.

Conceptos del Motor Gráfico (Parte 3): Gráficos 2D vs gráficos 3D en tiempo real

Para poder apreciar por completo la dificultad que supone la velocidad, hay que comprender primero cuál es la diferencia entre una animación 2D y una animación 3D en términos de computación.

La animación bidimensional se basa en los principios de la animación de viñetas tradicional. Es decir, se crea una inmensa cantidad de imágenes y luego se capturan secuencialmente para reproducirlas en el medio elegido que, en este caso, sería una computadora de cualquier tipo (incluyendo computadoras, consolas de juegos, sistemas de galerías hechos a medida, etc.). La computadora extrae las imágenes de la memoria y las presenta en la pantalla a la velocidad que sea necesaria para crear la ilusión del movimiento. Los factores esenciales de una animación bidimensional son el espacio de almacenamiento de datos (que justifico el CD-ROM como medio de juego preferido), la velocidad a la que se pueden leer los datos y la velocidad a la que se pueden presentar dichos datos. La computadora no tiene que procesar mucho para presentar una animación bidimensional.

A continuación se muestra una animación bidimensional de un logotipo girando de derecha a izquierda hecha a partir de una secuencia de 8 imágenes y compuestas mediante un programa de animación GIF. La velocidad ha sido ajustada de modo que el ojo humano no percibe el salto de una imagen a otra.

Los gráficos 3D requieren mucho menos espacio de almacenamiento que los gráficos 2D, porque no están dibujados previamente (a excepción de los mapas de texturas). La “receta” de la imagen 3D (las mallas y la animación) se guarda como una masa de fórmulas, a las que se invoca cuando se las necesita. Dado que el programa dibuja estas imágenes en la pantalla conforme se van viendo, y no antes, la computadora tiene que procesar mucho más y a mayor velocidad que con las imágenes 2D.

Veamos un ejemplo más concreto. Imaginémonos a una persona sacando tranquilamente una serie de imágenes ordenadas de un catálogo. Pues bien, ése sería el proceso que realiza la computadora con las imágenes 2D. Pero imaginemos ahora a otra persona intentando dibujar con exactitud, a la misma velocidad con la que la otra persona saca las imágenes, toda una colección de objetos que, además, otra persona está moviendo. Ése sería el PC cuando intenta dibujar imágenes 3D. Únicamente los procesadores rápidos son capaces de satisfacer estas necesidades tan extremas. Aún así, la geometría que se dibuja debe ser sencilla y debe tener un número reducido de polígonos para que el proceso sea lo suficientemente rápido como para obtener una velocidad de presentación aceptable.

Hoy en día, las tarjetas aceleradoras de juegos 3D son uno de los productos más populares entre los consumidores de PC. Estas tarjetas ayudan a reducir la carga que suponen los cálculos 3D para la CPU, haciendo que sea el propio procesador de la tarjeta el que asuma esa tarea. Gracias a esta tecnología, tanto los desarrolladores como los usuarios pueden disfrutar de entornos 3D más rápidos y más ricos, a un coste relativamente bajo.

Un poco de historia: SEGA (Parte 1)

Sega Corporation es una empresa japonesa desarrolladora de software y hardware en el campo del entretenimiento (videojuegos). Es una de las marcas de videojuegos más conocidas y respetadas del mundo. SEGA ha tenido una larga historia de éxitos tanto en el mercado de los arcades como en el de las consolas, pero desde el lanzamiento de Dreamcast, se encuentra fuera del mercado doméstico, para el que solamente se dedica a la programación de videojuegos y fabricación de algunos periféricos para máquinas de otras compañías. Sin embargo, continua el desarrollo de hardware para máquinas recreativas. Las oficinas centrales de SEGA se encuentran en Tokio, Japón.