juegos de plataformas [Archivo] - ZonaDeVicio - Tu comunidad de videojuegos online

efegea

27/02/2006, 06:52

Conoceis de alguna web donde se traten conceptos de programación de juegos de plataformas. Me refiero a cosas como los mapas de durezas, scrolls, gravedad, etc..No se, algun tutorial o algo me vendría bien pero por mas que busco no encuentro nada interesante :(

BuD

27/02/2006, 20:34

Juraria que en uno de los tutoriales que hay en el wiki de GP32spain explica lo que tu necesitas, los tutoriales los encontraras aqui:
http://wiki.gp32spain.com/index.php/Tutoriales_de_programaci%C3%B3n
[wei] [wei] [wei]

Drumpi

27/02/2006, 23:19

Yo me pille un libro-resumen de "programacion avanzada para div2" y me vino muy bien, porque te explica esos conceptos (no todos, porque como div ya tiene su scroll automático...), quizas te sirva... si lo encuentras :(

akram

27/02/2006, 23:29

No se si esto t sera util porque es para la nds con las pa_libs pero para hacerte una idea m supongo k si.

El link (http://www.palib.info/wiki/doku.php?id=day13)

efegea

27/02/2006, 23:36

¡Muchas gracias a todos por los enlaces! me vienen muy bien :)

Coelophysis

28/02/2006, 00:27

A mí también me vienen de perlas; creo que me voy a animar a crear un plataformas con Fénix, ahora que Puck2099 ha sacado la beta 3 para la GP2X.

A ver si mi juguecillo ve por fin la luz en una portátil :brindis: .

efegea

28/02/2006, 00:51

Vaya graficos :asomb: ¿lo has dibujado tu? Impresionante. Para mi juego quiero hacerme yo mismo mis graficos pero ni de coña quedaran a ese nivel. Aunque primero a ver si me aclaro en el tema de programacion que es lo mas importante y ando un poco espeso.. :(

Zenzuke

28/02/2006, 01:35

Puess... efegea, estos tutoriales que te pongo no son específicamente para FENIX ni nada de eso, son de flash, pero los conceptos generales son los mismos, realmente, asi que puede que te vengan muy bien.

http://www.tonypa.pri.ee/tbw/index.html <- Este es genial y muy completo

http://www.strille.net/tutorials/part1_scrolling.php <- Este solo explica el scrolling, pero es más avanzado que el anterior.

Espero que te sirvan de algo. A mi con flash me sirvieron, eso fijo :D

gade

28/02/2006, 05:49

Aqui algunas ideas basicas de los juegos jump and run sacadas del SuperTux: http://supertux.berlios.de/wiki/index.php/Game_engine , explica como funciona pero no muestra codigo, aunque siempre puedes bajartelo y leer codigo a pelo.

Ozius

28/02/2006, 06:02

yo tenia por algun lado un link de un pedazo de "tutorial" donde se creaba un juego completo, con su codigo fuente y todo, de ahí entendi yo muchisimas cosas. Lo malo es que he estado buscandolo y no se donde lo he metido, espero que no lo haya borrado en el ultimo formateo.
si lo encuentro lo posteo y sino ya intentare ayudar en lo que pueda

saludos

Drumpi

28/02/2006, 23:56

Coelophysis

01/03/2006, 00:36

Jo, y yo no paso de los graficos que use en FenixLand (tampoco les dedique tiempo, pues tenia 24 horas para hacerlos y terminar de programar lo que puediera)
Y mira por donde, es un plataformas (spameando un poco, lo teneis en fenixworld.se32.com, entre los juegos del concurso de minijuegos 2005), mas adelante lo sacare para gp2x (si soluciono los problemas que tengo con el otro port)

Y no me pidais el codigo porque uso tiles y el codigo esta un poco guarro, aun tiene algunos fallos. :D

Jo, pues a mí me vendría de perlas el código de un plataformas en Fénix que use tiles... :( (o un tutorial). Ahora mismo solo puedo plantearme programarlo usando los gráficos "a lo bruto", ya sabes, con los mapas enteros en una imagen y otra para las durezas... es que es lo único que sé manejar.

efegea

01/03/2006, 00:59

Tengo ahora mismo un cacao en la cabeza de clases y clases y clases y mas clases...[Ahhh]

Este va a ser mi primer juego en C++, siempre que he programado algo ha sido en C y cambiar la forma de pensar para usar la programacion orientada a objetos es complicado :( tengo varios folios llenos de clases y clases y mas clases. Espero no cansarme y que salga algo decente. Al menos poco a poco voy aclarandome las ideas. Ya tengo claro muchos conceptos del juego. Esto marcha :)

Jan_Europa

01/03/2006, 06:04

cacao en la cabeza de clases y clases y clases y mas clases...

no me extraña, te lo digo por experiencia...

tranqui, que con tiempo... todo llega

efegea

01/03/2006, 08:11

Uncanny

01/03/2006, 08:53

Soy feliz :)

Sin mirar ningun tutorial aun, he hecho un pequeño programita que hace uso de clases (¡mi primer programa c++!) y de los mapa de durezas, y encima he conseguido hacer algo que pensaba que iba a resultarme dificil: que el personaje suba rampas, y ha sido facilisimos :) esto aunque parezca una tonteria da muchos animos a un principiante como yo :=)De tontería nada, da gusto ver cuando algo funciona, da lo mismo el tiempo que lleves programando :D

Aunque hablando de C++, personalmente al paradigma de POO le tengo el aprecio justo, no me importa usar C++ mientras el programa o juego sea pequeño pues resulta facil de seguir (vamos, que es lo que hace y para que sirve cada parte del programa) pero cuando crece demasiado (y me refiero también a usar muchos archivos) y uses muchas de las características que hacen de C++ un lenguaje OO (ya sabes, a parte de las clases y sus instancias, clases derivadas, amigas, sobrecarga de operadores, herencia simple y múltiple...) entonces ya me empiezo a preguntar "¿porque no lo escribí en C?" xDDD

P.D: Te recomiendo que, si aun no lo has hecho, uses algún documentador de código como Doxygen, que añadiendole unos comentarios de un tipo determinado te ayudará a generar la documentación del programa mientras lo escribes sobre la marcha, sobre todo cuando se trata de las clases, con sus métodos y demás contenido.

efegea

02/03/2006, 07:33

arggg estoy [Ahhh] con un **** codigo que ha dejado de funcionar por las buenas

resulta que lo escribi, funciono, modifique con el gimp las imagenes y ha dejado de funcionar :loco:

Tengo una surface temporal, creada con SDL_CreateRGBSurface, en la que bliteo el fondo y los sprites, y luego esa surface temporal la bliteo a la pantalla. Pero ha dejado de funcionar por las buenas, no escupe ningun error y por mas que miro el codigo esta todo bien. Si bliteo directamente el fondo a la pantalla funciona, es como si la surface temporal se quedara en blanco (mas bien en negro). Me esta volviendo loco :mad:

< - >
UEEEEEEE yaa

Resulta que el codigo de ejemplo en la documentacion de SDL, el ejemplo de SDL_CreateRGBSurface, declaraba un canal alpha, y supongo que estaba haciendo que la surface fuese transparente. He cambiado amask por 0 y ahora funciona el codigo de vicio! uee :)

Uncanny

02/03/2006, 07:47

Puede ser una chorrada, pero ¿puede ser que los bpp de la imagen que has modificado no coincida con los bpp especificados en la paleta para la superficie en la función SDL_CreateRGBSurface? ¿Tu imagen tiene transparencias y haces uso de su canal alpha?

No si lo has escrito, pero podrías ver que ocurre en la salida de errores con:

if(superficie == NULL) {
fprintf(stderr, "La funcion SDL_CreateRGBSurface ha fallado al crear la superficie, codigo de error: %s\n", SDL_GetError());
exit(1);
}

EDITO:

Al final era lo del canal alpha, pues nada, asunto solucionado por ti mismo :)

miq01

02/03/2006, 15:02

Efegea, una duda: ¿por qué pintas todo en una superficie temporal y después la mandas a pintar? ¿Es para hacer algún efecto? ¿No se puede hacer directamente?

lemon

02/03/2006, 17:20

Efegea, una duda: ¿por qué pintas todo en una superficie temporal y después la mandas a pintar? ¿Es para hacer algún efecto? ¿No se puede hacer directamente?

Si la superficie de pantalla es una HWSurface es recomendable hacerlo todo a una superficie temporal (SWSurface) y después mandarlo de golpe a la pantallaa, pues la escritura a una HWSurface es mucho mas lenta que a una SWSurface.

miq01

02/03/2006, 21:22

Si la superficie de pantalla es una HWSurface es recomendable hacerlo todo a una superficie temporal (SWSurface) y después mandarlo de golpe a la pantallaa, pues la escritura a una HWSurface es mucho mas lenta que a una SWSurface.
Gracias, Lemon. Pero... ¿por qué es más lenta la escritura directa en hardware que en software?

efegea

02/03/2006, 23:41

Efegea, una duda: ¿por qué pintas todo en una superficie temporal y después la mandas a pintar? ¿Es para hacer algún efecto? ¿No se puede hacer directamente?

En la superficie temporal pinto el fondo y luego los sprites, y luego pinto la region visible de esa superficie a pantalla. No pinto los sprites directamente en pantalla porque las coordenadas x,y dependen del fondo. Si los pintase directamente en pantalla no tendrian en cuenta el scroll, ni funcionaria bien el mapa de durezas.

Se que me he explicado muy mal pero es que me acabo de levantar [Ahhh]

miq01

03/03/2006, 01:26

O sea que en realidad pintas el nivel entero en la temporal, y luego coges un trozo (en función de dónde esté la acción en ese frame) y lo vuelcas en pantalla, ¿no? Si es así, ¿no es muy costoso? Porque supongo que en cada frame rehaces toda la imagen temporal, ¿no? Cuantas preguntas... :)

Que conste que es curiosidad, porque no tengo mucha idea de cómo implementar un juego de plataformas, pero hace unos meses probé a hacer algo parecido a un juego de coches tipo Road Fighter (mira la imagen) con scroll vertical y lo que hacía era tener una matriz normal de C donde tenía el mapa de tiles entero correspondiente al nivel, y luego en función de la velocidad y la posición del coche esgogía una ventana (o sea, calculaba la y de la matriz que debía corresponderse con la posición y=0 de pantalla) y sólo pintaba ese trozo.

La verdad, no tengo comprobado que tenga que ser más óptima mi manera, pero entiendo que pintar todo el escenario en la superficie temporal ha de ser más costoso.

http://images.webmagic.com/klov.com/screens/R/wRoad_Fighter.png

chipan

03/03/2006, 02:24

Jo, pues a mí me vendría de perlas el código de un plataformas en Fénix que use tiles... :( (o un tutorial). Ahora mismo solo puedo plantearme programarlo usando los gráficos "a lo bruto", ya sabes, con los mapas enteros en una imagen y otra para las durezas... es que es lo único que sé manejar.
http://www.inicia.es/de/tifa/venturer.zip
no esta muy optimizado pero te haces una idea XDDD
¡anda!, si le falta el código fuente y no es el dcb bueno XDDDD
edit:
http://www.inicia.es/de/tifa/venturer.rar
en este está el prg y los ficheros actualizados; ya es "jugable"

efegea

03/03/2006, 22:00

miq01, supongo que podria hacer el metodo que se usaba de antaño, que es coger el trozo de fondo donde vas a pintar el sprite, guardarlo, pintar el sprite, y al siguiente frame volver a pintar ese trozo que has guardado. Consume mucho menos recursos, porque la imagen a blitear es mucho mas pequeña, pero es más dificil de implementar (aunque ahora que lo pienso no parece tan dificil)

< - >
Esto del C++ me esta dando muchos quebraderos de cabeza :( :(

No se porque, cuando hago "delete sprite" me elimina correctamente el objeto sprite, pero ¡crea uno nuevo! en las coordenadas 0,0 :confused:

Y la verdad que esto de las clases me esta trayendo mas problemas de los que me esperaba, sobre todo por cosas como por ejemplo, si declaro dos instancias de dos clases distintas, esas clases entre si no pueden comunicarse, y me tengo que marear la cabeza para ver como hacerlo.

Bueno, soy novato en esto, supongo que sera normal...:(

miq01

03/03/2006, 23:02

No se porque, cuando hago "delete sprite" me elimina correctamente el objeto sprite, pero ¡crea uno nuevo! en las coordenadas 0,0 :confused:
O bien lo creas tú en algú sitio sin querer, o bien liberas memoria pero luego accedes a él y por lo que sea te dice que las coordenadas son (0,0). Aunque esto último lo dudo mucho, porque lo que debería hacer es petar, porque intenta acceder a una zona de memoria no reservada. Lo que seguro que no pasa es que se cree una instancia de tu clase sprite mágicamente. :)

si declaro dos instancias de dos clases distintas, esas clases entre si no pueden comunicarse, y me tengo que marear la cabeza para ver como hacerlo.
Dos instancias de dos clases distintas no tienen el gusto de conocerse entre ellas si tu no haces las presentaciones. :) En otras palabras, si quieres que la clase A pueda acceder a métodos (funciones) de la clase B, en algún momento (en la constructora por ejemplo, aunque no necesariamente) le has de pasar a A un puntero a B.

Algo así:

B* b = new B(...);
A* a = new A(..., b);

Bueno, soy novato en esto, supongo que sera normal...:(
Hombre, si acabas de ponerte con C++ es normalísimo. ¿Te has mirado algún documento que explique la OO sin entrar en un lenguaje concreto? Es un rollo, pero para mí es recomendable.

Coelophysis

04/03/2006, 00:38

http://www.inicia.es/de/tifa/venturer.zip
no esta muy optimizado pero te haces una idea XDDD
¡anda!, si le falta el código fuente y no es el dcb bueno XDDDD
edit:
http://www.inicia.es/de/tifa/venturer.rar
en este está el prg y los ficheros actualizados; ya es "jugable"

¡Muchísimas gracias :brindis: ! Ahora a ver si entiendo algo...[Ahhh] .

efegea

04/03/2006, 06:53

Dos instancias de dos clases distintas no tienen el gusto de conocerse entre ellas si tu no haces las presentaciones. :) En otras palabras, si quieres que la clase A pueda acceder a métodos (funciones) de la clase B, en algún momento (en la constructora por ejemplo, aunque no necesariamente) le has de pasar a A un puntero a B.

Algo así:

B* b = new B(...);
A* a = new A(..., b);

hmmm..pero en ese caso que tendría que poner en las cabeceras del constructor de A, para que aceptara "b" como parametro? ¿que tipo deberia ser b? Seguro que algo como "Cstatemgr* statemgr" no es, porque me da error (Error: Cstatemgr no puede ser declarado,ISO C++ prohíbe la declaración de `statemgr' sin tipo)

Este C++ me esta volviendo loco [Ahhh]

En concreto lo que estoy intentando hacer es que en stateMenu::update() si se pulsa intro llame a un metodo de su padre (stateMgr) que cambia el estado. Se que puedo pasarle el puntero this, es decir que haga menu.update(this) pero no se que poner entre los parentesis de stateMenu::update()

miq01

04/03/2006, 09:10

hmmm..pero en ese caso que tendría que poner en las cabeceras del constructor de A, para que aceptara "b" como parametro? ¿que tipo deberia ser b?
La definición de tu clase A sería algo así:

#include "B.h"

class A
{
public:
A::A(..., B* b); <--- el constructor
A::UnMetodo();
private:
B* miB; <--- en miB te guardas el puntero que te llega en el constructor
};

Y A.cpp (o como lo quieras llamar) sería algo así:

A::A(..., B* b)
{
...
miB = b;
}

A::UnMetodo()
{
miB->HazEsto(...);
miB->HazLoOtro(...);
}

Así, desde "A::UnMetodo()" puedes llamar a métodos de miB, que es una instancia de B.