Lo bueno de usar matrices es que engloban las tres transformaciones básicas que puede recibir un objeto, que son rotacion, traslacion y escalado.

Y no nos olvidemos de lo ULTRA caras que son las operaciones trigonométricas (cos, sin, tan) en lo que a tiempo de procesador se refiere ;)

No entiendo tu puntualización. Para construir las matrices de rotación a partir de un angulo (Euler) hay que realizar las mismas operaciones trigonométricas (sin y cos).

Si lo que quieres es velocidad mi recomendación es que decidas cuantas particiones (secciones) de la circunferencia quieres crear (por ejemplo 360 como los grados), luego creas dos arrays con el tamaño de esas particones y precalculas senos y cosenos. Para acceder solo tienes que buscar en la posición del array los valores que quieres.

Por otra parte, puedes ahorrarte espacio y ver las relaciones entre senos y cosenos y los grados o radianes. Quiero decir que da lo mismo seno de 0 que cos de pi, etc. Puedes un solo array con pocos valores y hacer una funcion para cada "funcion trigonometrica" que busque el valor adecuado en el array. Esto se llaman tablas precalculadas.

Un saludo.

No sé si te he entendido bien, porque mi respuesta sigue siendo la misma: estados.

Cuando la CPU tenga que mover pasarás al estado E_MUEVE_CPU (por ejemplo) y pones un contador de enemigos actualizados a 0 (una variable). En tu trozo de código de lógica (en el procedimiento o donde lo tengas hecho) actualizas la acción de un enemigo, incrementas la variable de contador y continuas (ejecutas la parte de dibujado y das otra vuelta al bucle principal).
Asegurate de que a la salida de tu bucle se compruebe si has actualizado todos los enemigos, si es asi cambia de nuevo de estado al correspondiente.
En caso de que el cambio de estado provocara (eso es como tu te organices el código, pero por si acaso) que la animación del ultimo enemigo actualizado no se realizara, tendrias que hacer la comprobación antes del procedimiento de lógica, asi evitarias este problema, pero no tiene porque ser un problema si controlas correctamente los estado en todas las partes del código (logica, input y render) que lo necesiten.

Si este no es el problema, por favor, intenta explicarte un poco mejor, ya que no lo pillo.

Un saludo.

Hola, me parece que lo que tu necesitas es una maquina de estados.
No he entenido muy bien tu problema, pero creo que el problema es que no separas la lógica por estados. La forma más fácil (rápida de programarlo) es con una variable, no recuerdo muchas cosas de BASIC asi que lo escribiré en una especie pseudo-código:

Código [Seleccionar] Expand


definir { E_SALIR = 0, E_MUEVE_PLAYER = 1, E_ANIMACION = 2, E_COMBATE = 3, ...}
declarar varible estado = E_MUEVE_PLAYER // por ejemplo
// Bucle principal
mientras(estado <> E_SALIR) {
 // Input
 si estado == E_MUEVE_PLAYER entonces
   // Procesar código de entrada
   ....
 final si

 // Logica
 si estado == E_ANIMACION entonces
   // Ejecuta el código de animacion
   ...
   si animacion concluye entonces
     estado = E_... // el estado al que quieras cambiar
   final si
   ...
 sino si estado == E_MUEVE_PLAYER entonces
 ...
 sino si estado == E_COMBATE entonces
 ...
 final si
 // Comprobar final del juego
 si juego acaba entonces
   estado = E_SALIR
 final si

 // Dibujar
 ...
}


En el trozo de dibujar tambien puedes poner sentencias condicionales para seleccionar que dibujar en cada estado del juego.

Espero que esa sea tu pregunta y que hayas entendido el concepto.
Sino he sabido contestarte bien o no te queda algo claro dimelo e intentaré echarte una mano.

Un saludo

Gracias por todas las respuestas  :twisted:

El caluroso debate provocado por mi pregunta no debe quitaros mas horas.
Asi que os comunico mi decisión, utilizaré Newton de momento (gracias a Hans por el material proporcionado y por su ayuda). Y aunque sé que no os interesa postearé que tal me funciona el tema.

Lo dicho, salu2 a todas.  8)

Hola, estoy con un nuevo proyecto (nuevo porque todavia no hemos empezado en serio, pero llevamos tiempo planeando el tema) en 3D. Para la parte gráfica utilizaremos Ogre, y los dos SDKs de fisicas más conocidos que tienen integración con este motor gráfico son el ODE y el Newton.

He recibido referencias de ambos, pero todavia no tengo claro cual es mejor. Supongo que cada uno tendrá su pros y sus contras pero las cosas a evaluar, pienso yo, son las siguientes:

- Necesitamos fisica de solido-rigido.
- Necesitamo aplicar IK a alguna cadena de bones (no muy larga espero).
- Queremos (claramente) velocidad.
- Queremos sencillez de uso (ya sé que todo no puede ser ^^).

Bueno, espero que podais aportar experiencias o referencias.
Gracias por adelantado y un saludo.

Yo tb creo que deberias probar con luces antes de meter la "mascara".
Si tienes miedo de iluminar el GUI o otras cosas acuerdate de dibujarlas despues de desactivar las luces, esto seria:

Código [Seleccionar] Expand

glEnable(GL_LIGHTING);
... // dibujar los tiles
glDisable(GL_LIGHTING);
... // dibujar la GUI

Creo que GL_LIGHTING està bien escrito, sino pegale un ojo a la documentación del OpenGl.

Un saludo

PS: mi recomendación seria que aun con un fondo formado por tiles los personajes deberian estar en 3dimensiones, ya que quedaria mejor la iluminación. Pero no me hagas demasiado caso ;P es solo una opinión.

Bueno, la verdad es que estoy perdido ya, pero en cuanto a la semi-transparencia Hans tiene razón.

La semitransparencia se puede activar en un material scripteando esto dentro del mismo:

Código [Seleccionar] Expand

scene_blend addTe propongo que pruebes a copiar y modificar tu material (cambiandole el nombre por supuestisisisimo) y luego cambies el material de tu entidad (yo intentaria controlar que nodos pueden entrar en conflicto y asegurarme de tratarlos como entidades).
Para cambiar el material de tu entidad solo haz

Código [Seleccionar] Expand

entity->setMaterialName("mimaterial");¿Esa era la pregunta no?

Conseguir que un cámara en 3rd person no entre dentro de la geometria de tu escenario y muestre lo que no debe, o se interpongan objetos no deseados a veces resulta extremadamente complicado, y quizás un par de restricciones en tu nivel ayudarian a buscar una fácil solución. Aun así, yo creo que la mejor opción (o quizás a la que más acostumbrado estoy a ver) es realizar una interpolación desde la posición "natural de la cámara" hasta (como bien ha dicho Jove) los "ojos" del personaje, o sea pasar de 3rd a 1st person, donde el "factor" de acercamiento viene dado por las restricciones de colisión. No sé si me explico, pero la forma de hacerlo viene dada, en gran parte, por la implementación que hayas hecho del comportamiento de tu cámara: las coordenadas (globales, locales, etc), el tipo de representación utilizada (euler, quaternions, matrix, dist., etc), el algoritmo, etc.

Yo cambiaria de material (al transparente) el player (entidad seguro) en el mismo momento en que notes que tienes que comenzar a acercar la cámara tu personaje, y obtendria la pos de la cámara como el punto de colisión con la geometria de tu escenario, que se obtinene al lanzar un rayo desde tu jugador hasta la posición que debiera tener la cámara. Puedes adaptar la posición, con algunas restricciones sobre esta "regla básica", es cuestión de probar nuevas ideas, y mantener el código ordenado para no acabar echo un lio. De todas formas creo que es la idea (más o menos) que viene expresando alguna gente en este tema.

Bueno, espero ser de ayuda.
Un saludo.

PS: por cierto Hans, si tienes un ratito este finde, echale un ojo al mail, y me cuentas.

Me da igual que videojuegos. Un Tetris, un comecocos, uno de naves. Si tenéis algún link bueno os lo agradeceré en el alma.

No es lo mismo un tetris que un comecocos o una de naves. En un tetris tendrias que tener una clase para tus piezas, una para el tablero, y alguna cosa específica más. En el comecocos, tablero(diferente claro sta al del Tetris), fantasmas, jugador y poca cosa mas. El de naves enemigos, jugador (puede que desciendan del mismo), disparos (balas, misiles, etc), una para el escenario/nivel (fondos, efectos, la lista de enemigos que te aparecen, bosses, etc).

En cuanto a las clases genéricas para la aplicación en si tendrias patrones Singleton, Maquinas de estados, incluso un StateManager (te hace el control de estados mucho más facil y estructurado), y el "marco" de tu aplicación que te controle:
1.- Entradas (teclado/ratón/joys/etc)
2.- Video (2d,3d,blit,sprites,oloquesea)
3.- Actualización(tu trozo de código que se ejecutará cada frame).

Yo creo que poco más te haria falta saber. Pero te recomiendo:
http://gamedev.net
(tutoriales, recursos, foros, etc)

Salu2

Hola, estaba pensando en comenzar a utilizar un control de versiones para un proyecto que estoy iniciando con unos amigos.

En casa probé a instalar un CVS en linux, y funcionaba bien. Luego lo hice con WinXP, y también. Lo bueno es que NetBeans lo soporta de maravilla, y es el IDE con el que estamos trabajando.
Queria saber como de seguro seria tener un CVS fuera de una red local, quiero decir teniendo un ordenador conectado a internet que haga de servidor (en Windows en un principio).

Tambien he leído algo del SVN o algo asi, no sé en que difiere del CVS, ni cual de los dos serà mejor utilizar.

¿Alguien me puede orientar?

Muchas gracias por anticipado.  :D

Buenas a todos!!!

 Es la primera vez que creare un juego de este tipo y quisiera saber como hago para que la pelotita rebote como debe ser?, como indico esto?, es para un juego para celular hecho en Java con J2ME, algo al estilo Block Breaker Deluxe...alguna idea??????

Block Breaker Deluxe, IA, ... jajajajaja, es un chiste, ¿verdad?
Cualquier código que hagas será minimamente MEJOR que el código del Block, te lo aseguro xDDDDDD

Aunque la gente me crucifique por escribir sobre un tema que no deberia estar aqui:

Código [Seleccionar] Expand

public static int [] velxPelotas = new int [numeroDePelotasMaximo];
public static int [] velyPelotas = new int [numeroDePelotasMaximo];
public static int [] posxPelotas = new int [numeroDePelotasMaximo];
public static int [] posyPelotas = new int [numeroDePelotasMaximo];
...
if (posxPelotas[nPelota] > MURO_DERECHA || posxPelotas[nPelota] < MURO_IZQDA)
   velxPelotas[nPelota] = -velxPelotas[nPelota];
// Lo mismo para el MURO_SUPERIOR pero con la posy y la vely

// Choque con la PALA
if (collide( pelota, pala)) {
   velyPelotas[nPelota] = -velyPelotas[nPelota];
   dis = distancia_entre_centro_de_pala_y_centro_pelota;
   velX += dis*factor;
}

// Falta el choque con los bloques, pero es muy parecido.

// Falta el choque con los "Final Boss", pero es más de lo mismo.


Es fácil, ya comentarás que tal.

Si lo que quieres es que tu jugador (cpu) aprenda deberás aprender algo de redes neuronales y/o alg. genético y decidir que es lo que más te conviene. El tema es que le des unas condiciones iniciales y el mismo cpu vea como afectan sus decisiones (si ganan o pierde), de manera que al final (lo de siempre) acabe utilizando más los faroles/jugadas que le hagan ganar más veces. Por ello, tendrias que "entrenar" a tu cpu para que "aprendiera". Con las redes se le pasan patrones para que aprenda, y con los alg. gen. deberás poner un "código" para cada "partida", si ganas mucho guarda tu configuración para que se recombine con las ganadoras de otras partidas.

Mi opinión personal es que si vas a hacer un juego de poker para que sea entretenido y punto, haga caso de las recomendaciones que te han dado de "lógica difusa", sumando el valor de las cartas y la personalidad (prob. de tirarse un farol), todos estos parámetros (a mi entender) deberian de estar relacionados (un jugador MUY agresivo subirá la apuesta con una pareja de 2) .
De hecho necesitarás esto ultimo para evaluar el "código genético" (personaliad del jugador) de tus "alg. genéticos" en caso de que los quisieras utilizar.
Y tampoco armaria tanto escándalo con lo de la "ética del programador", un videojuego no pretende hacer algo real (cosa que es imposible con los sistemas discretos con los que tratamos), sino que realmente al jugador le parezca real.

Es mi opinión :D

Hola:

Estoy haciendo un estudio de la relacion entre el error de las funciones heuristicas admisibles y la complejidad temporal de la búsqueda.

Ya tengo todo el material teorico, pero me piden tb algún aporte de alguna investigacion sobre esto a lo largo del tiempo.

¿Alguien sabe de donde puedo sacar algo o controla algo de este tema?

Graciñas

¿Estás haciendo un proyecto de final de carrera?
¿Sabes realmente que te están pidiendo?

Creo que deberias conocer que tipo de problema vas a tratar, ya que las funciones heurísticas varian dependiendo del problema.
Si estamos hablando del típico problema de PathFinding creo que encontrarás bastante información en GameDev.net.
También pueces mirarte (si sabes donde encontrarlos, o estás dispuesto a gastarte la pasta) en los libros "AI Game Programming Wisdom", y la sección de IA de los "Game Programming Gems".

De todas formas, y si es un proyecto de final de carrera o algo parecido, puede que sea interesante (o que de hecho sea una de las partes que te están pidiendo) que te hagas un programita que te haga de "benchmarck" para saber cual es el coste temporal (tiempo y/o nodos explorados) y espacial (memoria que necesita el algoritmo) de cada una de las heurísticas que quieras probar.
Yo hicé uno para una práctica hace algún tiempo con un problema de puzzle-slide (típico de mover el hueco) en el que calculaba los costes para "X" problemas aleatorios, y/o para una lista de problemas defindos por el usuario. Yo, personalmente, resolvia cada problema con todas las heurísticas que queria probar y guardaba sus costes. Puedes hacer estudios, más tarde, con el "gnuplot", por ejemplo, si guardas correctamente los datos en un archivo de texto.

Lo que estaría bien es, hacer la lista de los 1001 trucos y advertencias de J2ME :twisted:

Yo haria la lista de los 1001 problemas y trucos de los móviles.
Comienzo con unos apuntes:

1- En principio s60 de Nokia no descargan bien los objetos Image. Dependiendo del dispositivo convine: igualar todas las refs a null, hacer un gc(), un sleep() de pocos milisegundos, y otro gc() ... a veces funciona.

2- TSM7 i G402i (DoJa no MIDP), fabricados por VitelCom, Murcia, tienen un error en el driver de "video". Pueden aparecer puntos blancos en el extremo inferior dererecho de las imagenes que tengan transparencia, dependiendo del numero de colores que tenga su paleta y el la imagen a la que están solapando.

3- [trick] Si quieres visualizar la memoria libre restante recuerda utilizar arrays de char "reservados previamente" y no objetos String, sino verás tu contador de memoria libre decreciendo en cada frame (por la memoria que se consume crear los String cada frame).

4- [trick] No confies nunca en j2me!!!!!!!! Es como la Ley de Murphy: si algo va bien, irá mal.

5- [trick] Busca la mayor compatibilidad posible!!!!! Utiliza solo MIDP1 siempre que puedas. Con directivas como las del tutorial puedes tener los trozos de código específico para cada plataforma. (FullCanvas, vibracion, ...)

6- [trick] Usa imagenes separadas para las animaciones de los sprites (te ahorraràs problemas con el clipping de MIDP1), incluso puedes probar a partir el sprite en trozos reutilizables en varios frames. Si lo que te preocupa es el tamaño la cabecera de los PNGs puedes crearte un archivo que contenga la paleta y la información común de las cabeceras de cada png de la animación, el resto lo construyes en tiempo de ejecución, lo metes en un array de bytes, lo creas como un stream (con "Image.CreateImage")  y a correr.

7- [ultra trick] AHORRO de epacio Jar: Resulta que existe la manera de crear un png con el maximo numero de Rows (es decir, cual pixmap o raw normal y corriente de 8 bits, un array de bytes con el numero de color de la paleta). De manera que si construyes bien la cabecera puedes cargar directamente una imagen en raw, lo que te permite tb crearla invirtiendo las filas y/o las columnas (bienvenidos a los flips/rots en MIDP1). Puedes creer que una imagen en raw ocupa más que un PNG ... pues haz la prueba, y metelo todo en un Jar ... resulta que, a veces, incluso se gana espacio respecto al png. Otras dos ventajas de esto son que te evitas cabeceras innecesarias (el punto 6), y que puedes tener varias paletas por imagen/sprite, solo mete en la cabecera los colores que quieres y listo.

8- El tamaño del código también suele ser problemático (sobretodo en DoJa donde su máximo tamaño es 20kB).
Recuerda comentar todos los xivatos (println) cuando no los necesites.
ProGuard suele hacer un buen trabajo por nosotros, pero debemos facilitarle la tarea. Cualquier clase que solo contenga variable del tipo " final public static ... " (siempre que no sea un array) será eliminada del código ofuscado y los valores de estas variables "inlineados". Así que (por comodidad y legibilidad de código) puedes crearte tus clases (DEF.java, por ejemplo) con tus constantes definidas, sin miedo a que ello implique mayor tamaño de código.
Otro truco es no utilizar bloques "if / else if" para asignaciones sencillas:
Esto:

Código [Seleccionar] Expand

if ( x > 30 ) {
   y = 30;
} else {
   y = x;
}
equivale a esto:

Código [Seleccionar] Expand

y = (x>30)?(30):(x);
[/list]
Bueno son solo algunas sugerencias que he podido aprender por ahi. Pero la más importante es que si haces un juego de móvil, intenta NO HACER nada más de los imprescindible, perderás tiempo que luego no cobrarás. A no ser que quieras hacerte tus herramientas y tenerlas "pa siempre" o venderlas, etc.

Por cierto, muy bueno el código, gracias por compartir :D

Un saludo!