Me extraña que nadie todavía haya escrito algo sobre esto:

http://www.pixfans.com/los-20-mejores-juegos-arcade-gratuitos-del-2007/

Personalmente creo que es obligado echarles un vistazo: Como resultado te acabas dando cuenta de que cosas sencillísimas pueden ser hechas y tener un acabado bastante bueno.

En concreto, el juego del gusano, que es el que he probado, es la caña. Idea original, sencillo y adictivo.

[/url]

Vi esta oferta de trabajo casi de casualidad, y, como reza el título, ¿para qué trabajar en la industria del videojuego, pudiendo ser megamillonario con tan solo rascarte los huevos? xDDDD.

http://www.informaticos.com/ofertas-empleo/se-gente-quiera-ser-rica-millonaria-162474o.html

Y no, no es una estafa piramidal de esas tan conocidas. En este caso, es trapezoidal (como dirían en los Simpsons).

Quería recompilar un antiguo proyecto en Allegro del que tengo las fuentes, pero me faltan algunas bibliotecas.  Después de un formateo de los que hacen historia he podido recuperar al menos lo importante.

En concreto, usa Alogg para reproducir OGG's. El problema es que parece que su página web está más que muerta. Y buscando el .a/.lib de turno por Google, no puedo encontrar nada de interés. Y en SourceForge no está alojada.

¿Alguien sabe de alguna ubicación alternativa donde esté almacenada la biblioteca (preferiblemente, ya compilada y lista para usar)? ¿O alguien la tiene, o sabe que le ha pasado?

Gracias :).

Bueno, en vez de estar poniendo 500 posts sobre que días podemos unos y otros y dificultar la elección, lo mejor sería una encuesta con la que se escoja el día que más gente vote. Ya se ha hecho otras veces así, y creo que es la mejor opción en vista de que ninguno nos aclaramos.

He puesto los sábados, pero si preferís un viernes o un domingo, marcar la opción relativa al sábado e indicadlo en un post.

Bueno, estoy en la típica época de la vida en la que hay que plantearse la planificación sobre que caminos tomar en el futuro, y no quiero descartar demasiadas opciones.

Tengo la IT en Informática de Gestión, y, en un 95% de probabilidades, voy a hacer el 2º ciclo en la UNED con tranquilidad. Me atrae la idea de un futuro doctorado orientado al campo de los gráficos.

He oido opiniones muy agrias sobre como tienen montado el tinglado con las ingenierías técnicas y los tres primeros años de la superior, pero parece que, para las asignaturas del 2º ciclo, la cosa no está tan mal, pero hay menos opiniones circulando para poder saber mejor donde me meto. Hace unos años vi una página con la visión de un alumno sobre las asignaturas y su dificultad, pero vete tú a saber ahora donde estaba esa página (Google no ha podido ayudarme :P).

¿Alguno ha hecho el 2º ciclo en la UNED?

Otra cosa, ¿convalidan las asignaturas de libre elección? Con algo más de 225 créditos de la UCA, y contando con que piden un mínimo de 172 (creo recordar) para poder ingresar (en el caso de que estuvieras cursando el 1º ciclo de la ingeniería). Sería una pena que parte de esos 225 se vayan al garete.

Venga, gracias :).

Es una pena que el género de las aventuras gráficas haya perdido tanto terreno de aquí a hace unos años, siendo uno que ha tenido siempre bastante aceptación, a mi parecer (sin contar con salidas como el Runaway 2). Por suerte, parece que en la escena indie no es así; ni hace falta que comente cual fue el ganador del ArtFutura del año pasado :P.

Desde hace cierto tiempo me ha picado el gusanillo de hacer algún sistema tipo SCUMM como humilde granito de arena. Y que mejor que aprovechar el tirón de los lenguajes de script actuales para ello.

Tengo dos proyectos comenzados al respecto, uno bastante adelantado y otro parado a la espera de retomarlo. Los dos son motores de lógica para hacer aventuras gráficas que tengan una estructura casi similar (sin llegar a tener porque ser mutuamente compatibles, ya que espero que quede algo más refinado el último que el primero, sin contar con la diferencia de la naturaleza de los tipos de aventura hacia los que los motores están orientados).

El último es , básicamente, una biblioteca hecha en C++ para Python, usando Irrlicht de fondo (para aventuras en 3D).  Está parado desde que me encontré ciertas dificultades para exportar a B3D con herramientas que no son de pago (sí, soy un matao para estas cosas, y más últimamente :P) para empezar a probar el añadido de objetos interactivos en los escenarios.

El primero es para aventuras en 2D, y es una biblioteca en Python para Python. Creo que está bastante avanzado, quedando por hacer:

-Dibujado por capas espaciales estableciendo un orden Z.
-Salvaguardado de partidas (por serialización no debería reportar mayores problemas para implementar).
-Embellecimiento de la interfaz, cuyos elementos son visualmente bastante feos (las acciones aplicables a un objeto se muestran en un menú desplegable gris con texto color negro y fuente tipo sans-serif).
-Factoría de interfaces, para poder programar nuevas y acoplarlas al sistema según se desee (esto, en cierta medida, englobaría el TODO-entry anterior).
-Refinamiento de las funciones aplicables al mundo (según demanda).

La idea para las dos es bastante fácil. Una aventura se compone de, básicamente:

-Un diccionario de variables de estado (por ejemplo, del tipo

caer_bien_a_tendero = "true", numero_repeticiones_conversacion_guarda = "5").
-Una lista de escenarios.
-Una lista de objetos, con un diccionario cuya clave sea el texto de la función a ejecutar tras pulsarla  (y el texto de una frase en una conversación) y una función a ejecutar, con la lista de acciones a realizar dado el evento. Esto incluye también a los objetos del inventario (la única diferencia, obviamente, residirá en que no pertenecen a un escenario).
[/list]

Un grupo de acciones se inserta en una cola. Hasta que la última acción del grupo termine de ejecutarse o pase un tiempo especificado, no se ejecutará el siguiente grupo. Esto es lo que hacen los eventos asociados a las acciones, añadir a la cola grupos de acciones.

No pongo ningún pantallazo porque los gráficos de la prueba son, como mínimo, horribles. Como pequeña descripción: Un bicho rosa dentro de un quiosco de información turística en un vertedero, y una máquina detrás que parece sacada del cerebro de Gaudí. Todo con dibujos renderizados con cel-shading  (hale, ya está xD).

Las diferencias del motor 3D, sin contar con las de programación (otro lenguaje y biblioteca gráfica), estriban en la naturaleza tridimensional del asunto. Hay que añadir movimientos de cámara, y esto escribirlo en un script es difícil, por lo que habría que meter como complemento un editor de escenarios (cosa que, claro está, tampoco vendría mal al motor 2D, o como mínimo un editor de grafos para los caminos del objeto protagonista u otros objetos).

Es un lenguaje que, francamente, me encanta. Las razones están más que escuchadas y solo repetiría algo que se ha dicho 500 veces. Además, cuando se va a programar cualquier cosa que necesite una lógica programable,  como motor de scripts viene bien.

Con la versión 2.4, todo era perfecto. Incluso romántico, diría yo. Pero el cambio a 2.5 me está trayendo curiosos quebraderos de cabeza.

Un proyecto que dejé aparcado y que estoy retomando (adivinad con que lenguaje) funciona bajo 2.5 sin ningún problema. La retrocompatibilidad está más que garantizada, por lo que los tiros no van por ahí. El problema viene a la hora de extender el código. No solo con la modificación de los ficheros .py, sino creando nuevos también.

Bajo Windows, he instalado tropecientosmil IDEs. Todos, absolutamente todos, daban problemas cuando añadía una nueva línea de código. Identar con la tabulación correspondiente (paso olímpicamente de los cuatro espacios de Guido), escribir la línea de código de turno, ejecutar el proyecto y, ¡voilá!, "La identación no se corresponde".
Cambiando la tabulación por los cuatro espacios, y el mismo error. ¿Solución? Copypastear las tabulaciones de las líneas antiguas (de la parte del código testeada con Python 2.4).

Pensé en que sería problema de la codificación (inicialmente lo estaba haciendo bajo Linux con UTF-8, y que estos IDEs estarían tratando el fichero como ), así que me decido por seguir programándolo desde este SO. Pero ocurre exactamente lo mismo. Es más, creando nuevas clases en nuevos ficheros, me ha dado problemas los métodos __init__, diciendo que el nombre "self" no existe. La solución es exactamente la misma, copypastear de los otros ficheros la tabulación.

El único editor que me funciona bien bajo los dos entornos es el IDLE, pero para un proyecto de bastantes ficheros es muy incómodo. Y el emacs no lo he probado en estas circunstancias, pero pasará lo mismo que con el IDLE, no es la opción más cómoda.

Las guías de estilo de Python, por lo que veo, es más una declaración de mobbing que otra cosa :P.

La próxima vez me hago un parser con flex/bison de un minilenguaje, y listos. Reinventar la rueda, pues sí, pero la sensación de alivio al codear compensa.

Se llama Rage y, por lo que he leido, han sacado un trailer:

http://www.gametrailers.com/game/5315.html

Junto con lo del Quake Wars y esto, son tiempos interesantes para los carmackoides :P.

http://dwave.wordpress.com/2007/01/

Creo que, si realmente esta máquina sale realmente, las discusiones Linux/Windows perderían fuelle :).

El caso es que parece que han anunciado que van a presentar el primer ordenador cuántico: http://ciencia.barrapunto.com/ciencia/07/02/09/139212.shtml.

Pues aprovechando mi estancia madrileña y que es fin de semana, he salido por ahi y he aprovechado para ir con un amigo a hacer una pequeña visita a la Fnac.

Yo creía que esta gente vendía esto, y de hecho me acerqué a un dependiente para preguntárselo, pero me dijo que habían cancelado la distribución en Europa, y que como no la adquiriera por importación...

El caso es que me he metido en una de las páginas online que la vende (hard-core gamer) y no dice nada de que hayan cancelado nada :S.

Alguien sabe algo? O me han dado la respuesta rápida para librarse de este tío que pregunta por cosas heréticamente raras? xD

[unresolved external symbol "private: static class hlgl::cPointer<class hlgl::Core> hlgl::Core::core]

Tengo un pequeño problema que parece va a traerme (y me está trayendo) algunos quebraderos de cabeza:

El caso es que he creado una DLL y un proyecto paralelo para testearla. La biblioteca de la DLL tiene clases con miembros estáticos. Y he aquí el problema: Durante el enlazado, salta un error de que el miembro estático que se usa en el test no se encuentra:

Creating library C:\Documents and Settings\LC0\Mis documentos\hlgltest\Debug\hlgltest.lib and object C:\Documents and Settings\LC0\Mis documentos\hlgltest\Debug\hlgltest.exp
main.obj : error LNK2019: unresolved external symbol "private: static class hlgl::cPointer<class hlgl::Core> hlgl::Core::core" (?core@Core@hlgl@@0V?$cPointer@VCore@hlgl@@@2@A) referenced in function "public: static class hlgl::cPointer<class hlgl::Core> __cdecl hlgl::Core::getSingleton(void)" (?getSingleton@Core@hlgl@@SA?AV?$cPointer@VCore@hlgl@@@2@XZ)

Insertando el __declspec(dllexport) no sirve, el error sigue.

¿Alguna idea? (Que conste que es la primera vez que trato de compilar una DLL).

Esta es la declaración de la clase Core:

Código [Seleccionar] Expand


class Core
{
private:
DLLEXPORT Core(); //DLLEXPORT = __declspec(dllesxport)

DLLEXPORT static cPointer<Core> core; //<-El miembro estático problemático

//...
public:

DLLEXPORT void init(/*...*/);
DLLEXPORT void stop(/*...*/);
//...
}



De antemano, muchísimas gracias.

Llevaba bastante tiempo pensando en hacer un motorcillo 3D, aunque siempre me echaba algo para atrás el peso que conlleva mantenerlo, actualizarlo, añadirle nuevas features... Sobre todo si se encarga de él una sola persona.

Así que, pensando en algo que podría realizar en relativamente poco tiempo, he realizado una bibliotequilla para gráficos en 2D con aceleración gráfica.

Las siglas vienen a significar "High Level Graphics Library" (si se os ocurre algo mejor, estoy abierto a sugerencias :P).

Básicamente, es un abstract factory en el  que se puede elegir la API gráfica que se desea usar de fondo (D3D u OpenGL, aunque yo solo he implementado OGL, ya que no me manejo con D3D).

Con esto, el usuario puede crear una serie de sprites que podrá mover, rotar, escalar, cambiar el alpha y demás pamplinas. Un ejemplo de código de uso muy básico:

#include "core.h"
using namespace hlgl;
int main()
{
   Core::getSingleton()->setRenderer(Core::SDL_GL);
   Core::getSingleton()->init(800, 600, CD_32, false);
   
     cPointer<Sprite> sprite = Core::getSingleton()->getRenderer()->createSprite();
     cPointer<Sprite> bg = Core::getSingleton()->getRenderer()->createSprite();

   sprite->loadFrame("logo.png");
   bg->loadFrame("background.jpg");
   bg->unsetColorKey();
   bg->setZ(0.0);
   sprite->setZ(1.0);
   
   while(1)
   {
      sprite->setX(sprite->getY() + 0.01);
      sprite->setY(sprite->getY() + 0.01);
      Core::getSingleton()->render();
   }
   return 0;
}

No pongo ningún screenshot porque es una tontería, solo se vería un sprite con el "logo" (bastante cutre, todo hay que decirlo :)) y otro con un paisaje.

Aparte de la implementación para D3D, falta la implementación de sistemas de partículas y, lo más importante, convertirlo a DLL (el proyecto por ahora es un ejecutable). Ah! Y la documentación, que es prácticamente lo más importante.

Imagino que cuando tenga algo decente liberaré el código, ya que supongo que, si todo me va bien, pronto encontraré curro y no podré dedicarle mucho tiempo a esto (aunque siempre se podrá encontrar algún ratejo infinitesimal).


Hasta otra.

Leyendo linuxjuegos me he encontrado que van a organizar otra edición del Pyweek para septiembre.

La verdad es que esta gente no para, el último Pyweek fué a finales de Marzo, y entre esta edición y la anterior organizaron una compo rápida.

Ya que una modalidad de la competición es de equipos, he pensado que una buena idea sería organizar uno con gente de por aquí, con unos cuantos coders y grafos. Podría quedar algo gracioso.

Va a ser entre el 3 de Septiembre y el 10 (incluidos).

Por mi parte, creo que podré participar, pero no es seguro. Depende si en esa justa fecha encuentro curro o no.

¿Cómo lo veis?

Hasta otra.

Me llama mucho la atención que cada vez que me meto en el foro haya un nuevo usuario registrado, y que todos tengan una página web con nombres bastante extraños (ni me he molestado en pincharlas :)). ¿Es una oleada de spam bots, o tal vez estoy en panic mode?

Es lo malo del phpbb2, es un sistema demasiado popular, y esta gente siempre intenta atacar a o sitios con este sistema de foros.

http://barrapunto.com/article.pl?sid=06/08/02/0642204&mode=thread&threshold=-1

Por lo menos, el asunto se mueve.
¿Qué opinais?

Hola a todos,

A ver que os parece esta aberración de la naturaleza: Yo y un amigo hemos desarrollado el juego de la escoba para móviles, y una primera demo está lista.
La idea sería testearla y, los que podais meter el jar en el móvil, decir como os funciona en vuestros modelos. Sobre todo sobre todo, agradecería bastante que alguien que tuviera uno de estos modelos lo probara.

En la versión completa el juego se podrá terminar por completo, o sea, que cada vez que se termine una baraja, se elimina al jugador que menos puntuación ha obtenido, y de esta forma hacer una criba hasta que quede el vencedor absoluto.

También nos hemos propuesto como meta hacer un modo multijugador vía bluetooth.

Y bueno, he aquí los pantallazos reglamentarios:




Como siempre, muchas gracias de antemano por vuestra(s) ayuda/sugerencias/insert-here-what-you-feel.

Pues resulta que un amigo y yo estamos intentando hacer nuestros pinitos en el mundo share, y que mejor que un juego para móviles para ello (aparte de otros proyectos que ya he comentado, claro xD).

El tema es que ya tenemos lista una demo. Para desarrollarlo, hemos estado ejecutándolo siempre con el emulador del Wireless Toolkit y con la configuración "Media Control Skin", que es la que ofrece la pantalla más pequeña de todas del emulador.

Hemos tenido mucho cuidado en hacer que las cosas encajen en la mayoría de pantallas, posicionando los elementos del juego en posiciones relativas según el ancho y el alto de la pantalla y cosas por el estilo.

En el Media Control Skin el juego entraba en pantalla a la perfección. Sin embargo, a la hora de pasarlo a mi móvil, la pantalla se ve que queda chica para el juego.

Mi pregunta es si debería fiarme de los resultados en el emulador, o en el de mi móvil. Es decir, ¿suelen ser las pantallas para móviles tan tan pequeñas? Mi teléfono es un Sony-Ericsson K300i.

Muchas gracias de antemano.

http://barrapunto.com/ocio/06/06/20/2326235.shtml

Suena interesante, no?

Bueno, me he decidido a retomar y presentar por aquí un viejo proyecto (en realidad, la continuación de un viejo proyecto), con pantallazo incluído. La idea es recabar vuestras opiniones sobre la mecánica de este y de las cosillas que se pueden ver en la captura.

Si se le trata de buscar una historia, va de una pelea de pollos mutantes creados como arma barata por los humanos, a fin de reducir costes y bajas humanas en las guerras. Evidentemente y como se puede suponer, la cosa acaba desmadrada y una rebelión de estos bichos casi extingue a la raza humana :lol:, y como lo único que saben hacer es pelear y procrear, pues...

La mecánica de juego es muy parecida a las melées del Star Control 2: Los jugadores se hacen un equipo de diferentes pollos, cada uno con sus habilidades/torpezas y con sus dos respectivas armas. Hay en el escenario un pollo por equipo, y gana quien consiga eliminar a todos los pollos del resto de equipos en la partida.

El movimiento de la cámara, por el contrario, es parecido al del onslaught en el UT-2004: El jugador puede girarla alrededor de su actual pollo con el ratón, pudiendo contemplar el panorama de la zona donde este.

Lo bueno que tiene este planteamiento es que el juego puede ser tan grande como se quiera. Es decir, una vez esté implementado el sistema de juego, el GUI de los menús, y el resto de cosas que engloban el "universo Pollotron", solo se trataría de añadir nuevos pollos y nuevos escenarios (los nuevos pollos, heredando de su respectiva clase padre, pues va que chuta). Sería bonito colgarlo en sf una vez esté la cosa algo decente. Obviamente, yo lo que me voy a limitar de momento es hacer el sistema de juego y añadir un par de pollos.

El desarrollo está muy en pañales: Está hecho el marco de trabajo (las clases y sus relaciones, vamos) con el que se va a programar el juego. Está hecho con C++, Ogre y, para temas de física, acabaré por meterle ODE (si no cambian los planes o la idea por lo que sea, claro :)).

El pantallazo está tomado "in-game", pero no el HUD, que se lo he añadido con el típico programa de dibujo que todos conocemos :D (por eso digo que la foto es casi un concept-art). Reconozco que la textura de este es un poco fea (no me acaba de convencer, pero es la que más me gusta del resto de intentos que he hecho), pero lo único que importa es hacerse a la idea de lo que tiene el HUD y como lo muestra.

En el HUD, se ve la vida del personaje y las diferentes potencias para poder disparar cada arma. También está el nombre del equipo y una pantalla donde verse los diferentes bonus que vaya teniendo el jugador (modo Dios, gripe del pollo, etc. ).

Y bueno, este es el shot:


El escenario está hecho con el formato .scene (xml puro y duro) que viene en los ogreaddons, y se organiza a base de octree. Quería haberle puesto lightmapping y eso, pero he tenido mis dificultades para hacer eso con este formato y, aunque creo que ya se como arreglar el tema, lo veo una solución un poco burra y de momento, como que paso xD.

El pollo en concreto que se ve viene a ser como el Sarge del Q3, es el modelo por defecto. Se llama Clotilde (si se os ocurre un nombre mejor, estoy abierto a sugerencias :D).

Bueno, pues a ver que os parece la idea. Estoy abierto a críticas, insultos, palizas, etc...

 Hola a todos,

Pregunto esto en el foro de Ogre, pero se ve que no ha tenido mucho exito la pregunta :D, asi que a ver si alguien que se haya manejado con el motor podr�a echarme una manita, ya que es un problema ciertamente extragno y desconcertante:

Estoy trabajando en el framework del juego que estoy haciendo. Es una estrategia que he seguido en otros desarrollos que he hecho y que me resulta muy comoda (imagino que mas gente lo hara asi):

Código [Seleccionar] Expand


int main(int argc, char** argv)
{
   cMain main("titulo del juego");
   main.runApp();

   return 0;
}


cMain es la clase principal de la aplicacion; se encargara de iniciar el motor, SDL, y atesorar el tan preciado Ogre::Root. Al mismo tiempo, es el manejador de los multiples subsistemas de los que esta formado el juego (subsistema de menus iniciales, subsistema "ingame", etc.).

Lo primero a desarrollar es el sistema "ingame", y renderizar, renderiza. Pero solo si se llaman a las rutinas de render desde el constructor, una vez iniciados el resto de elementos que lo conforman. Y este es el problema: Obviamente, tengo que implementar un bucle principal de verdad (main.runApp()) , y este metodo parece que no se llama nunca.

Analizando un poco el comportamiento del engendro, primero pongo el constructor de la clase cMain:

Código [Seleccionar] Expand


cMain::cMain(const char* gt)
{
   //..Rutinas de inicio que no vienen al caso...

  //Try to create the game system setting one scene
  cPointer<cGameSystem> game_sys = new cGameSystem();
  game_sys->setScene("attempt");
  game_sys->setCurrent(); //Indicar al objeto main que este es el sistema actual a ejecutar
}


No pongo nada de setScene porque, depurando, parece que el problema no est� ah�.
setCurrent viene a ser:

Código [Seleccionar] Expand


void cGameSystem::setCurrent()
{
   root->getAutoCreatedWindow()->removeAllViewports(); //Solo se usa un viewport
   root->getAutoCreatedWindow()->addViewport(cam.getRaw(), 0);  //getRaw, simplemente, devuelve un Ogre::Camera*, ya que estoy usando smart pointers "caseros")
}


Y el main loop maldito, que nunca se ejecuta:

Código [Seleccionar] Expand


//Contenido de runApp()
bool q = false;
while(!q)
{
  //Esto es solo d prueba. La actualizaci�n de la l�gica del juego va a ir en un hilo SDL aparte.
  SDL_Event evt;
  while(SDL_PollEvent(&evt))
  {
     switch(evt.type)
     {
                    //...
     }
  }

  if(!root->_fireFrameStarted())
     break;
  root->_updateAllRenderTargets();
  if(!root->_fireFrameEnded())
     break;
}


Mirando el fichero Ogre.log que se genera tras cada ejecucion, este no indica nada erroneo. La aplicacion, sencillamente, inicializa las rutinas de video, se pone en pantalla completa, e inmediatamente se sale.

Muchisimas gracias de antemano y perdon por el tostonazo que he soltado :).