Presentacion

[hylian]

 Hola llevo tiempo entrando en el foro y por fin me he decidido a registrarme, para daros un poco la vara :D

Desde siempre he querido hacer un videojuego, de hecho soy bastante aficionado a ellos desde pequeñito, siempre he estado "al otro lado" jugando y jugando sin parar, desde el spectrum hasta la xbox pasando por toda la generacion de consolas y pc que ha salido entre medias :)

Ahora estoy decidido a hacer un jueguecillo, espero que al final lleve a buen puerto la idea, desde luego la cosa es empezar por algo sencillo, como bien he leido embarcarse en algo mayor es tarea imposible sobre todo con mis conocimientos de programacion y diseño de juegos.

Realmente un mar de dudas me asaltan, no tanto del aspecto de programacion ( aunq c++ siempre me parecio demoniaco en parte por las famosas practicas de la carrera :D ) si no mas bien por el aspecto de COMO se hace un juego. Evidentemente las cosas se pueden hacer por el camino de "enmedio" pero creo que desde el principio conviene hacer las cosas bien y de una forma ordenada :)

Yo curro en el dia a dia desarrollando en Java webs y aplicaciones para la empresa, y si algo me ha dicho la experiencia es que las cosas que se hacen sin pensarlas el suficiente tiempo antes y dejando bien claro el principio y el fin ( aunque luego este fin se sobrepase una y otra vez... ) no llegan a buen puerto, o si llegan al final son una cosa intratable que acaba por desecharse.

De momento estoy mirando cosas en opengl, no creo que sea una buena opcion para empezar el desarrollo de un juego pero bueno el libro estaba libre en la biblioteca, mas que nada lo estoy leyendo para coger conceptos y llevarlos a la practica en forma de pelotitas rebotando y cosas asi :)

Bueno seguiremos mirando cosas y ya os dare la brasa con preguntitas :D

De momento estoy intentando desempolvar mis conocimientos de C++ que de tanto programar en Java uno se olvida de lo que era el arduo dia a dia con C++ :)

Saludos!

[Snakers]

 Salu2 hylian y Bienvenido..
Nunca e programado con OpenGl pero no creo que sea la
mejor opcion para empezar..
Yo uso la biblioteca Allegro,que es muy facil para
programar videojuegos,pero tambien existe SDL que tambien
dicen que esta muy bien,yo me decanto mas por Allegro.
Suerte y haber si vemos un juego tuyo pronto!! (ole)  

[hylian]

Salu2 hylian y Bienvenido..
Nunca e programado con OpenGl pero no creo que sea la
mejor opcion para empezar..
Yo uso la biblioteca Allegro,que es muy facil para
programar videojuegos,pero tambien existe SDL que tambien
dicen que esta muy bien,yo me decanto mas por Allegro.
Suerte y haber si vemos un juego tuyo pronto!! (ole)

Ahora que mencionas allegro me acuerdo de haberlo usado cuando aun no era GLP, lo usaba en win98 con el rhide y el djgpp ( o algo asi se llamaba ), tambien he trasteado algo con SDL :)

Realmente otra duda de las que me asalta, es q narices hacen las plataformas de desarrollo de juegos ( game engines ), estilo Irrlitch y tal. Que son como el extinto Div games studio?.

Saludos! :)

[CoLSoN2]

 Si tu problema es sobre cómo estructurar el código de un juego en CódigoVerde tienes una serie de tutoriales paso a paso sobre cómo crear un juego sencillo.

Hay mil y una formas de diseñar el código de algo tan complejo como un juego y normalmente es cuestión de gustos. Lo que es seguro es que cada juego que diseñes te saldrá mejor que el anterior, pues habrás aprendido de tus errores. Y ningún tutorial te va a ser nunca más útil que la experiencia.

[CoLSoN2]

Realmente otra duda de las que me asalta, es q narices hacen las plataformas de desarrollo de juegos ( game engines ), estilo Irrlitch y tal. Que son como el extinto Div games studio?.

Depende de a lo que te refieras con "plataforma de desarrollo de juegos". Bajo ese nombre podrías encontrar cosas como Blitz3D/BlitzMax, que efectiva trabajan de una forma similar a DIV, como motores (o engines) propiamente dichos, como Irrlicht.

En el caso de Irrlicht y similares, son simplemente librerías (en este caso escrita en C++) que te proporcionan una capa extra de abstracción a la hora de trabajar. Es decir, en vez de tener que leer tú mismo el fichero de un modelo 3D, parsearlo, cargar las texturas que use, dibujar luego vértice a vértice y textura a textura..  con un engine harías algo así:

Modelo3D miModelo;
miModelo.Cargar("miModelo.3ds");

.. luego ..

miModelo.Dibujar();

Es decir: te ahorran trabajo.

[hylian]

 

Si tu problema es sobre cómo estructurar el código de un juego en CódigoVerde tienes una serie de tutoriales paso a paso sobre cómo crear un juego sencillo.

Parece que esta caida la web :mellow:

He podido ver el capitulo 3 por el cache de google pero tiene muy buena pinta :D

Espero que se arregle pronto

[Snakers]

 xDD...Div...que recuerdos....aunque hice muy poco...
lo unico que logre terminar fue un Matamarcianos pero..
Yo tambien e usado Ogre3D,se hacen las cosas muy faciles,
como bien ha dicho CoLSoN2 te ahorran trabajo!!

[Douch]

 

Si tu problema es sobre cómo estructurar el código de un juego en CódigoVerde tienes una serie de tutoriales paso a paso sobre cómo crear un juego sencillo.

Parece que esta caida la web :mellow:

Es el efecto Stratos :D

[Ray]

 hylian:

Yo curro en el dia a dia desarrollando en Java webs y aplicaciones para la empresa, y si algo me ha dicho la experiencia es que las cosas que se hacen sin pensarlas el suficiente tiempo antes y dejando bien claro el principio y el fin ( aunque luego este fin se sobrepase una y otra vez... ) no llegan a buen puerto, o si llegan al final son una cosa intratable que acaba por desecharse.

Lo único que se me ocurre para que un programa de videojuego no acabe por ser intratable es separarlo todo bien y aislar todo de todo, y comunicarlo entre sí por medio de funciones o métodos que se limiten a recibir o a obtener datos de una manera coherente y lógica. y este punto es donde creo que se debería prestar atención y preparar todo bien antes de empezar a programar. Saber que va a hacer cada cosa y que información deberá recibir o devolver.

De esta forma al menos una serie de errores en diversos puntos no echará abajo todo el proyecto. y por supuesto hay que pensar y preveer al hacerlo que cualquier modificación que hagamos en cualquier parte en el futuro, no debería afectar lo más mínimo al resto del programa.

Aunque como ha dicho Colson2 al final lo que cuenta es la experiencia para no cometer los mismos errores. Por eso tampoco creo que importe mucho embarcarnos en cualquier proyecto personal si se hace simplemente para aprender, se espabila bastante metiendo la pata una y otra vez, y siempre piensas... la próxima vez no me volvera a pasar esto.  (grrr) .......  :D  

[hylian]

 

Lo único que se me ocurre para que un programa de videojuego no acabe por ser intratable es separarlo todo bien y aislar todo de todo, y comunicarlo entre sí por medio de funciones o métodos que se limiten a recibir o a obtener datos de una manera coherente y lógica. y este punto es donde creo que se debería prestar atención y preparar todo bien antes de empezar a programar. Saber que va a hacer cada cosa y que información deberá recibir o devolver.

De esta forma al menos una serie de errores en diversos puntos no echará abajo todo el proyecto. y por supuesto hay que pensar y preveer al hacerlo que cualquier modificación que hagamos en cualquier parte en el futuro, no debería afectar lo más mínimo al resto del programa.

Aunque como ha dicho Colson2 al final lo que cuenta es la experiencia para no cometer los mismos errores. Por eso tampoco creo que importe mucho embarcarnos en cualquier proyecto personal si se hace simplemente para aprender, se espabila bastante metiendo la pata una y otra vez, y siempre piensas... la próxima vez no me volvera a pasar esto.  (grrr) .......  :D

Siempre lo mejor es aprender de tus propios errores, pero la verdad que en estos momentos me siento incapaz incluso de hechar a andar. Si por algun lado empezaria seria siguiendo un plan de "repetir (capturar_entrada, procesar, dibujar)", sin embargo esto me hace sospechar que la captura de la entrada no sera muy buena si se ralentiza el proceso con el proceso y el dibujo. Ya la sola captura de entrada me hace pensar si es eficiente el estar comprobando si una tecla ha sido pulsada en cada momento.

Una vez en el diseño del juego, siempre me entra la duda si cada "objeto" del juego deberia tener su clase, y si el codigo de pintar dicho "objeto" del juego deberia ser un metodo de dicha clase.

Bueno etc etc... supongo que todo esto se despejara cuando me ponga a picar como dios manda, la cosa es tener un poco pensado el tema para no sentarme delante del DevC++ o del VSC++ y no saber que hacer :)

Ademas aunque se me ocurra algo, siempre tengo la virtud o el defecto de pensar que como yo lo hago no es la forma mas optima y me fastidia por que si realmente existe una forma aceptada globalmente de hacer ese algo me gustaria conocerla y usarla. Por poner un ejemplo: crear una estructura de clases que se adapte a una base de datos, y que permita abstraer la etapa de la consulta del usuario final. A mi se me podria ocurrir de una forma, pero sabiendo que existe el patrón DAO ( por ejemplo ), pues se usa que al fin y al cabo esta diseñado por mucha gente que lo ha probado y se ha demostrado que es valido. En mi sector, se buscar lo que quiero, el problema es que en este mundo, no se ni que buscar  :blink:

Saludos y gracias a todos por los mensajes :)

[CoLSoN2]

Ademas aunque se me ocurra algo, siempre tengo la virtud o el defecto de pensar que como yo lo hago no es la forma mas optima y me fastidia por que si realmente existe una forma aceptada globalmente de hacer ese algo me gustaria conocerla y usarla.

Aunque también se usan patrones de diseño en programación de juegos, la verdad es que en la práctica, y habiendo tantos módulos distintos con sus distintos requisitos (motor de render, IA, físicas, scripting..) en la práctica la verdad es que encuentras motores bien diseñados pero que no tienen nada que ver unos con otros.

Por ejemplo, tanto OGRE como Nebula2 tienen un diseño cojonudo y sin embargo no se parece en absoluto. Cuestión de gustos, vaya.

[Ray]

 Esta claro que un programa de un videojuego no es igual que una aplicación típica de entrada->proceso->salida, porque aquí casi todo interactúa con todo y lo que es peor, ha de ser mostrado en tiempo real y ha de ser jugable, por lo tanto en cada fotograma habrá diferentes entradas, procesos y salidas dependiendo de las situaciones del juego, que pueden llegar a ser muy numerosas por no decir infinitas (más difícil imposible).

hylian:

Siempre lo mejor es aprender de tus propios errores, pero la verdad que en estos momentos me siento incapaz incluso de echar a andar. Si por algún lado empezaría seria siguiendo un plan de "repetir (capturar_entrada, procesar, dibujar)", sin embargo esto me hace sospechar que la captura de la entrada no sera muy buena si se ralentiza el proceso con el proceso y el dibujo. Ya la sola captura de entrada me hace pensar si es eficiente el estar comprobando si una tecla ha sido pulsada en cada momento.

Una vez en el diseño del juego, siempre me entra la duda si cada "objeto" del juego debería tener su clase, y si el código de pintar dicho "objeto" del juego debería ser un método de dicha clase.

Supongo que el diseño dependerá de cada uno, como lo sepa o pueda hacer mejor y de todo lo que haya aprendido a lo largo de su experiencia, no creo que exista el código de videojuego perfecto, y si existe va a ser difícil que alguien te explique como lo hizo.

El ideal sería uno que uno mismo u otra persona pueda modificar o actualizar fácil y rápidamente. Yo pienso que  lo ideal es hacer código versátil, claro, genérico, que se pueda reutilizar y ampliar en el futuro sin tener que poner todo patas arriba, es decir, sin atajos y sin trucos para optimizar que puedan hacer difícil el seguimiento o una futura actualización. Hoy por hoy ya no es necesario salvo en funciones muy puntuales y en todo caso la optimización se debería hacer al final y solo donde es absolutamente necesario.

Otra cosa importante a la hora de programar es pensar no en el juego concretamente si no en cualquier juego que pudieras hacer en el futuro con ese código que estás escribiendo,  es decir... si por ejemplo vas a hacer un juego con scroll tipo Super Mario Bross(desplazamiento de pantalla), lo ideal es hacer una clase "personaje" y una clase "scroll" que se encargue de situar, dibujar, y controlar los limites, la velocidad etc... y que sepas que podrás usar en cualquier juego, de manera que al hacerlo te quede así:

Código [Seleccionar] Expand


// Al inicio o en cada fase:
Scroll.Actualizar(FotoCiudad);

// Durante el proceso:
if (Input.GetTeclaPulsada==KEY_RIGHT)
    SuperMario.DesplazarXY( 4, 0);

Scroll.Desplazar( SuperMario.ObtenerPosicionX(), 0);

// Al dibujar
Scroll.Dibujar();
SuperMario.Dibujar();

Si te das cuenta el programa del juego queda como un seudo-código que puede leer cualquiera fácilmente, porque el meollo de la cuestión está en sus clases, ahora quiero hacer otro juego de aviones.

Código [Seleccionar] Expand


//Al inicio o en cada fase:
Scroll.Actualizar(FotoPaisaje);

//Durante el proceso:
if (Input.GetTeclaPulsada==KEY_UP)
    Avion.DesplazarXY( 0, 10 );

Scroll.Desplazar( Avion.ObtenerPosicionX(), Avion.ObtenerPosicionY() );

Al dibujar
Scroll.Dibujar();
Avion.Dibujar();


Y hacemos un juego diferente con el mínimo esfuerzo, entonces por esto te propongo que cuando lo hagas no pienses en un solo juego si no en muchos, porque aunque es más tedioso y menos gratificante luego lo agradecerás muchísimo despues, a veces algunas clases no te servirían porque no son suficientes, entonces tendrás que actualizarlas o hacer clases derivadas específicas. Y esto no hará otra cosa más que enriquecer tu sistema de clases. En definitiva esto es como hacer tu propio motor, que yo creo que es lo ideal. y así queda separado lo que es el juego (seudo-código) de las clases, que cada una tendrá sus problemas y sus historias particulares e independientes de las demás.

así debería quedar el método dibujar de la clase personaje.

Código [Seleccionar] Expand


void classPersonaje::Dibujar()
{
Graficos->DibujarSprite( PosX, PosY, AnchoSprite, LargoSprite, Bitmap);
}


Los parámetros son propiedades de la clase personaje que deberán ser debidamente actualizados al comienzo o durante el transcurso del juego, y "Gráficos" es un puntero a la clase gráficos que bien podría ser estático y común para todos los objetos de la clase,  aquí tengo mis dudas de si no sería mejor hacer estáticos los métodos de "Gráficos" puesto que solo va a haber un objeto de esa clase, y llamarlos con el operador de alcance ::

y más o menos así debería quedar el método de la clase Gráficos

Código [Seleccionar] Expand


void classGraficos::Dibujar(int PosX, int PosY, int TamSpriteX, int TamSpriteY, classBitmap *Bitmap)
{
// y aqui ya tenemos lo necesario para dibujar en pantalla, dado que el objeto //  Bitmap del personaje contendra la información del dibujo
}


Bueno, yo creo que más o menos se entiende por donde quiero ir, lo que te puesto es un poco a modo de ejemplo, luego es un poco más complejo el asunto, aunque claro, cada cual tiene su metodo y bien podría salir alguien y decir.. pues yo lo hago asi y asi, y es mejor, y quizá sea mejor (o peor), pero tambien tiene que hacer cada cual lo que mejor pueda, le guste y se apañe, aunque realmente lo ideal es que el código que hagas, le guste a todo el que lo vea.

y ya sabes mucha, mucha práctica.

un saludo.

[Ray]

 

Una vez en el diseño del juego, siempre me entra la duda si cada "objeto" del juego debería tener su clase, y si el código de pintar dicho "objeto" del juego debería ser un método de dicha clase.

Al final me he enrollado tanto que no te he contestado.

bueno, lo ideal sería crear una clase común llamada por ejemplo "objeto" con propiedades comunes, después puedes hacer dos clases derivadas "dinámicos" y  "estáticos" ,  después con los dinámicos puedes hacer humanos, gatos, o monstruos con sus propias propiedades. Entre las clases de humanos puedes hacer más clases entre buenos, malos, o el propio personaje del jugador, eso ya como te lo montes tú deberás hacer las que creas necesarias,

Si no quieres hacer demasiadas pues no hace falta que hagas perros, gatos y ratones, puedes meterlo todo en la clase animales y diferenciar a unos de otros en el propio código, si es para poner a cuatro animales de adorno pues mejor en una solo pero si vas a hacer un juego de animales mejor en clases diferentes.

Y el código de pintar mejor sepáralo en otra clase, y que cada objeto que quiera pintar ya sabe lo que tiene que hacer  Gráficos->Dibujar(parámetros y mapa de bits, o modelo si es 3d). Si algún día tus gráficos se quedan obsoletos solo tendrás que actualizar la clase gráficos, a las demás clases no les afectará para nada el cambio.

[hylian]

 Muchas gracias Ray :D

Esto es precisamente lo que necesito para empezar con exito en este mundillo. Los conceptos tecnologicos ( lenguaje, OO, ... ) no me faltan, pero siempre he considerado que hacer un juego ( como tu dices ) no se parece en nada a un programa tipico informatico ( ya sea un programa de control de ventas o un driver de una impresora en linux... )

Lo dicho muchas gracias :D

[Gunmaster]

 No es lo mismo programar software para ps2 (lo que hago habitualmente) que programar un juego, aunque sea el mismo lenguaje (C++), me tendré que leer alguna Api "standard" para los juegos...