Ir al contenido

publicidad

Foto

Miniguia: Quiero programar videojuegos. ¿Por dónde empiezo?


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
31 respuestas en este tema

#16

Escrito 13 febrero 2006 - 16:39

Al margen de cómo se quiera introducir cada uno a realizar juegos (y las dos posiciones me parecen respetables, tanto de los que quieren empezar desde el principio con algún lenguaje de programación tipo C++ o Java, como de los que prefieren empezar con una herramienta de creación de juegos para no chocarse contra problemas ajenos a la voluntad de crear un juego), voy a hablar de lo que yo conozco, y en lo que yo estoy metido: creación de juegos con Java.

Para crear juegos en java tienes dos opciones, por así decirlo:
- Crear juegos en 2D
- Crear juegos en 3D

Si escoges el camino del 2D, tienes algunas librerías:
- Java2D: No es una librería de juegos propiamente dicha, pues es la que se utiliza para dibujar interfaces gráficas de usuario y tratamiento de imágenes. Pero está plenamente capacitada para realizar juegos 2D con ella. Sobre todo en la versión 1.5 de Java, en la que hicieron que Java2D estuviera basada en OpenGL, con lo que puedes obtener acceleración de la tarjeta gráfica para el dibujo. Como la mayoría de lo que trae la distribución oficial de java, esto maneja abstracciones y alto nivel para el dibujado en pantalla, tratamiento de teclado, ratón, colisiones, hilos, etc...no es meternos en el bajo nivel del OpenGL ni similares. Evidentemente, Java2D es sobre todo el dibujo, y me suena que el tratamiento de colisiones; el resto de cosas (sonido, hilos, entrada de usuario, gestión de ventanas, etc) viene dado por el resto de librerías de java. La ventaja de tenerlo integrado en el propio sistema de librerías de java oficial, es que es una de las herramientas oficiales igualmente para juegos en J2ME (es decir, java para dispositivos pequeños como agendas, móviles, etc), o incluso en Applets (remplazando así, la creación de juegos en Flash o algún otro derivado de Macromedia)...aunque por supuesto, no la única. De hecho, Java2D puede ser demasiado generalista si lo que queremos es una librería que nos ayude de forma fácil a crear juegos.

- Otra librería para crear juegos en 2D, es MIDP (2.0 en su versión actual creo), que se centra exclusivamente en la creación de juegos. Maneja términos más sencillos, y su api es más directa, aunque sin llegar, por supuesto, al bajo nivel de librerías puramente gráficas como DirectDraw (si es que todavía se llama así) u OpenGL. Esta parece ser bastante popular.

Aparte de esto, para 2D no conozco más cosas, salvo que utilices librerías de 3D para diseñar juegos en 2D, que también es posible, aunque más complicado.

- Juegos en 3D.
Para juegos en 3D tienes dos subramas:

- utilización directa o más o menos directa de librerías opengl adaptadas para Java, como JOGL o su "competidor" más directo LWJGL. La diferencia entre Jogl y LWJGL es que Jogl se basa más en librerías gráficas awt o swing para la gestión de ventanas, mientras que LWJGL tiene su propio código para eso. Según los creadoers del LWJGL, se podrían iniciar juegos desde, por ejemplo, la consola en linux, a través del framebuffer, en vez de tener que iniciar el servidor X. En cualquier caso, en ambas vas a trabajar con órdenes OpenGL directas, por lo que el trabajo es mayor, por lo menos hasta que te crees tú una biblioteca de clases para gestionarte el asunto de forma más fácil y sencilla.

- Utilización de lo que se conoce como "escenógrafos" (o algo así, je, no tengo ni papa del nombre que eso tiene en Español), que te permiten trabajar en vez de con órdenes de opengl, con "escenas". Es decir, describes lo que hay en tu escena, y la librería se encarga de presentar lo que hay en la escena a la pantalla. Este concepto también existe fuera de java. Se trata pues, de una opción que nos permite trabajar de forma más cómoda y abstracta, pero a costa de la eficiencia probablemente, y del mayor consumo de recursos. Mayor consumo que se añade al mayor consumo de recursos que de por sí Java impone.
En Java tenemos el "escenógrafo" oficial, que es Java3D, que se basa tanto en OpenGL como en DirectX. Evidentemente, sólo utilizará DirectX si estamos en Windows. Java3D es una librería para realizar aplicaciones generalistas en 3D, no exclusivamente juegos, como ya ocurría en Java2D.
Otra librería que se inspira bastante en Java3D, aunque más centrada a la creación de juegos, es Xith3D. No hay mucho que comentar. Al contrario que Java3D, Xith3D permite hacer uso de las funciones opengl, a través de JOGL, aunque estaba planeado dar soporte a LWJGL en un futuro cercano.
Otra más, JMonkeyEngine o JME (a no confundir con J2ME, que es la API que tiene java para programar para dispositivos móviles). Este me suena que directamente basado en LWJGL, en vez de en JoGL. Es más o menos igual de popular que Xith3D.


Luego, por otro lado, al margen de los gráficos, tenemos también en java librerías especializadas para tratar los recursos de la entrada de usuario (teclado, ratón, joysticks, etc) con JInput, y también para el sonido con Joal ( basado en la librería OpenAL para C/C++, y que permite sonido con posicionamiento 3D entre otras cosas).



Como nota final, por supuesto, de nada sirve tener todas estas librerías si no tenemos gráficos, música e ideas. De la misma forma que se ha dicho que si no tenemos la parte técnica, da igual que tengamos buenas ideas, se puede decir exactamente lo contrario.

Un saludo, y no dudeis en preguntar. Aunque no soy ningún experto (bien lejos de ello, precisamente) intentaré responder lo mejor que pueda.

  • Sante05

  • Methuselah

  • vida restante: 100%
  • Registrado: 21 jul 2001
  • Mensajes: 182
#17

Escrito 13 febrero 2006 - 19:35

Vuelves a hablar de conceptos como luces dinámicas y entrar en la 3ª dimensión, diseñar IAs y físicas reales. Muy complejo lo veo para el 99% de los mortales.


No he mencionado para nada la 3ª dimensión, ni diseñar IAs ni físicas reales. Y con "añadir luces" me refería a esto:

Imagen Enviada

Algo que yo no considero para nada fuera del alcance del 99% de los mortales. Aunque puede que el problema es que tengamos escalas de valores muy distintas.

Es que a la postre prácticamente cualquier juego que puedas afrontar como amateur podrás hacerlo con esas herramientas.


Te vuelvo a repetir, un juego amateur puede ser tan complejo como quieras. Cometes un error común, y es asumir que amateur = simple, y no tiene porqué.

Yo puedo ser un desarrollador amateur, pero programar un MMORPG (uno de los tipos de juegos más complejos, te suena Tibia?)

Puede que eso no te interese el primer año, ni el segundo, ni el tercero. Pero de repente te apetece crear algo "mas", y te encuentras con que las herramientas te están limitando.


Muy al contrario, seguro que aprenderás muchas cosas y de la forma más simple [...] Pasados esos 2 años y con un dominio respetable en cómo hacer juegos y cómo traspasar tu idea al Blitz Basic te das cuenta que quieres escalar. AHORA es el momento de hacer el cambio [...] Quizás ya si te planteas qué es un blitter, pero no antes donde tu interés se centra en hacer primero un Space Invaders y acabar en un R-Type.


Aprenderás muchas cosas en BlitzBasic, no te lo niego, pero lo que aprenderás serán algoritmos, tipos de datos, estructuras, pilas, colas, árboles, etc.... Es decir, el conjunto de conocimientos que es necesario SIEMPRE, y que da exactamente igual el lenguaje en el que se usen.

Pero hacer un juego no se reduce a esos algoritmos. Para programar un juego tienes que tener conocimientos de cómo funciona la memoria, de qué cosas son eficientes y qué no, de qué coño es un blitter, de como se guarda un pixel. Esos son los conocimientos que son DIFERENTES en programación de juegos que en cualquier otra rama de informática, y son precisamente los que te niegan estas herramientas.


Y ojo, que TODO lo que estoy diciendo son conceptos de programación 2D básica (las cosas que usas en SDL), si me meto en 3D ya no acabo nunca.

Si tu llegas después de dos años de usar GameMaker XL (volviendo al ejemplo hipotético), y te pones a hacer un juego en SDL, te darás una hostia de cuidado. No por que sea C/C++, no, sino porque no vas a tener la más mínima idea de los conceptos básicos de la programación de juegos 2D.
Cuando tengas que crear una superficie, y decidir si meterla en memoria de hardware o de software, no vas a saber. Precisamente porque de esa parte se encargaba GameMaker XL sin que tu te dieses cuenta.


En resumen, no consiste en aprender a programar, sino en aprender a resolver problemas, que eso es hacer un juego (y hacer cualquier cosa en la vida).


Te equivocas. Yo puedo ser un programador de redes, que se como resolver cualquier problema que surja mientras programo una aplicación P2P (por ejemplo), y me saco de la manga algoritmos de gestión de descargas y colas de prioridad que son impresionantes.

Pero eso no me convierte en un buen programador de juegos.

Igualmente, un buen programador de juegos no es automáticamente un buen programador de aplicaciones p2p, por muy bien que se le de resolver problemas.

En realidad, cosas como la capacidad de resolver problemas, o los conocimientos de tipos de datos, algoritmos, etc... son conocimientos comunes a TODAS las ramas de la informática.

Pero luego, en cada una de las ramas, hay una serie de conocimientos específicos, que son distintos de los de las demás.

En programación de redes, son TCP/IP, protocolos, y datagramas
En programación de juegos 2D, son blitters, formatos de pixels, y gestión de superficies gráficas.


Igual que no es posible concebir un programador de redes que no sepa lo que es "eso de TECEPE IP", tampoco es posible concebir un programador de juegos 2D que le suene a chino lo de los "formatos de pixel", o el "blit".


Y te aseguro que no estoy PARA NADA entrando en conceptos avanzados.

  • Sante05

  • Methuselah

  • vida restante: 100%
  • Registrado: 21 jul 2001
  • Mensajes: 182
#18

Escrito 13 febrero 2006 - 19:43

Otra librería para crear juegos en 2D, es MIDP (2.0 en su versión actual creo), que se centra exclusivamente en la creación de juegos.


Corrígeme si me equivoco, pero MIDP no era un protocolo / interfaz / comoquierasllamarlo de J2ME?

Vamos, que se usa para programar juegos para móviles, no?

Repito que no estoy seguro, pero a mi me suena lo de MIDP de cuando estuve trasteando con eso xD

  • Jerk2

  • TERRESTRIS VERITAS

  • vida restante: 100%
  • Registrado: 31 jul 2002
  • Mensajes: 1.121
#19

Escrito 13 febrero 2006 - 21:09

Yo soy de la opinion de sante05.

Hablais de meterse a bajo nivel con DirectX y tal, pero cuando yo hacia programacion grafica para hacer un buen juego no bastaba con saber programar en C. O sabias ensamblador o la habias cagado. Es mas, o sabias programar el hardware directamente en ensambaldor o mejor que te dedicaras a otra cosa.

A mi me costo mucho tiempo hasta llegar a tal nivel. Empezando por QBasic, pasando por Pascal y C para pasar a ensamblador, empollarme libros y documentacin tecnica del hardware del PC y finalmente poder desarrollar rutinas de programacion hardware, algoritmos en ensamblador de dibujado de lineas, movimiento de sprites en pantalla, gestion del raton, etc... Tengo publicasas esas librerias que desarrolle en una web de programacion para que todo el mundo pueda ver como se programaban graficos en DOS hace unos cuantos años.

En esos momento saber como realizar un juego pasaba por conocer todo esto. Si utilizabas cosas como el DivGames Studio, que salio en poco tiempo, en mi opinion no podia decirse que supieras desarrollar juegos. Ni siquiera servia para aprender porque, como dice sante05, toda la complejidad de programacion del hardware de la VGA, del raton, de gestion de graficos, etc... te la ocultaba.



Ahora, supongo, sucedera algo parecido. Ya no se programa el hardware directamente porque para eso tienes librerias como DirectX, pero en cambio tienes que aprender a utilizar estas librerias, y, como la potencia es muyo mayor ahora, pueden hacerse cosas mucho mas complicadas que te obligan a saber muchas matematicas si quieres realizar algo decente.

Un saludo.

#20

Escrito 13 febrero 2006 - 21:33

Corrígeme si me equivoco, pero MIDP no era un protocolo / interfaz / comoquierasllamarlo de J2ME?

Vamos, que se usa para programar juegos para móviles, no?

Tienes toda la razón. Yo pensaba que era una api más para crear juegos de terceros, pero investigando ahora un poco veo que es efectivamente parte de la especificación J2ME oficial de Sun. De hecho, no he mirado mucho, pero por lo que entiendo ahora mismo Java2D como tal no estaría disponible en J2ME?
La verdad es que nunca me he metido con la programación en java para pequeños dispositivos, aunque seguro que es muy interesante. En un futuro cercano, era mi intención meterme en ello. Pero bueno, como siempre, proyectos y proyectos empezados y sin acabar nunca...

  • Sante05

  • Methuselah

  • vida restante: 100%
  • Registrado: 21 jul 2001
  • Mensajes: 182
#21

Escrito 13 febrero 2006 - 23:21

La verdad es que nunca me he metido con la programación en java para pequeños dispositivos, aunque seguro que es muy interesante.


Sobre J2ME, hay un libro en español que probablemente no sea el mejor de todos, pero lo suple siendo completamente gratuito.

Se puede descargar desde la página del autor: http://www.agserrano.com/publi.html

Eso si, el libro parte de que ya se conoce el lenguaje Java.


(El otro de SDL ya no lo recomiendo tanto, en mi opinión es mejor aprender algo de inglés y leerse los tutoriales de calidad que hay en Internet, pero bueno)

#22

Escrito 14 febrero 2006 - 11:41

Gracias por el enlace, un libro completo sobre un tema es muy de agradecer.

  • nahiko

  • GRANDIS SUPERNUS

  • vida restante: 100%
  • Registrado: 14 sep 2001
  • Mensajes: 7.375
#23

Escrito 16 febrero 2006 - 00:50

Soy de la opinión de Sante05, al igual que Jerk2

S2!!

  • _pako_

  • HARENA TIGRIS

  • vida restante: 100%
  • Registrado: 03 mar 2001
  • Mensajes: 891
#24

Escrito 06 marzo 2006 - 18:33

Tu guía es muy interesante aunque personalmente opino como Sante05.

Dependiendo de hacia donde quieras enfocar el trabajo y esfuerzo que vas a invertir son más recomendables unas opciones que otras. Si alguien tiene en perspectiva dedicarse a programar juegos a nivel profesional, lo que no implica que se gane la vida con ello, es mejor currárselo desde el principio y empezar por lo básico (esto incluye lo ya mencionado respecto a programación y fundamentos para juegos).

Con esto no digo que quien siga ese camino acabe programando profesionalmente juegos, pero el camino es más sólido que empezar por herramientas con cosas pre-hechas que te "facilitan la vida", muchas de ellas no tendrás más remedio que aprenderlas y aunque, como bien dices, también se aprende mucho, no es lo mismo y así no pierdes el tiempo. Desde luego no es tan divertido (al menos al principio) porque tardas más en ver resultados, pero hay que dejar claro que no es un camino de rosas.

El que solo quiere hacer cosas para fardar con los amigos o divertirse puede seguir el "camino fácil" y no complicarse la vida.

Saludos...

  • darksch

  • HARENA TIGRIS

  • vida restante: 100%
  • Registrado: 04 dic 2001
  • Mensajes: 2.730
#25

Escrito 06 marzo 2006 - 20:00

Muchos de esos juegos 'amateur' que pones se podrían vender como profesionales, pero ¿a qué no se sabe a simple vista la herramienta usada?, te pongo ejemplos de que el tipo RPG de combates y el de aviones podrían estar hechos con Dark Basic ó Blitz3D y ni te enteras, de hecho es bastante posible que lo usen.

Cuando ejecutas algo juegas al resultado, no a si está hecho en C++ ó OpenGL.

Por ejemplo con buenos grafista se pueden hacer 'beat'em up' de los de antes en 2D (Streets of Rage, D&D, etc.) que le dan 1000 millones de vueltas a todas las mierdas 3D de ahora, y podrías hacerlo con Blitz Basic simple (el 2D) a base de sprites y backgrounds.

Para mí una buena forma de hacer uso de las 3D es hacer juegos 2D pero con 3D, como ejemplo el reciente Yume, haces colisiones y movimientos en 2D (facilito) y usas gráficos 3D (aprovechando el hardware, transparencias, zooms, etc.), como buena referencia tenemos a Ikaruga de DC y GC de Treasure.

#26

Escrito 19 enero 2008 - 23:59

mmm.... pues yo no creo eso de q se "tiene" que empezar desde bien abajo... o abajo, como quieran decirle... pues yo he comenzado a programar directamente sobre Blitz3D... y la verdad me va de mil maravillas... ;) ningun problema con nada... :gafas:

lo que no puedo hacer es aprender C++.... porque no hay nadie que me enseñe... ni tampoco dispongo de tiempo para ello... (para blitz3d aprendi solo!!)

si hay alguien que sepa C++ y me pueda dar algo como para empezar a "entenderme" con el programa , y explicarme bien, por supuesto, se lo agradeceria.... , porfavor mandenme un e-mail a spyro_drag@hotmail.com.

OK. Soñar no cuesta nada........ realizar el sueño....... es el verdadero dolor de cabeza!.

#27

Escrito 20 enero 2008 - 01:02

Hola.
Pues hombre..., no es necesario empezar desde abajo para poder programar, pero si es muy recomendable. Creo que en los anteriores mensajes ha quedado bastante explicado que, sin una base firme, llegará un momento en que te resulte casi imposible entender los conceptos y te verás muy limitado para avanzar.
Puedes ponerte a programar directamente en un lenguaje de alto nivel si quieres, pero hay que entender las estructuras de datos elementales y tener nociones de algorítmica. Por supuesto, todo esto si quieres crear cosas medianamente decentes (y no me refiero sólo a juegos).

...
lo que no puedo hacer es aprender C++.... porque no hay nadie que me enseñe... ni tampoco dispongo de tiempo para ello... (para blitz3d aprendi solo!!)

si hay alguien que sepa C++ y me pueda dar algo como para empezar a "entenderme" con el programa , y explicarme bien, por supuesto, se lo agradeceria.... , porfavor mandenme un e-mail a spyro_drag@hotmail.com.

OK. Soñar no cuesta nada........ realizar el sueño....... es el verdadero dolor de cabeza!.

Desde luego con esa frase ya empiezas mal. Si dices que aprendiste tu solito con el Blitz, no cuesta nada coger un buen libro y pegarse un poco con la POO. Puedes ir calentando motores con esto.

Por cierto, ¡vaya reflote te has marcado!.

  • anonim

  • Anima

  • vida restante: 100%
  • Registrado: 09 dic 2007
  • Mensajes: 906
#28

Escrito 20 enero 2008 - 23:28

Yo pienso que la diferencia entre unas herramientas u otras es el conocimiento del usuario. Si uno no sabe nada de programación pero le apetece hacer un videojuego utilizará un maker, pero alguien que sepa programar o que haya pasado por la universidad se irá directamente a C++ (+) OpenGL, que lo dará mucha más flexibiilidad y control del codigo que escriba y no se verá reducido a lo que el programa maker le deje hacer.

  • anonim

  • Anima

  • vida restante: 100%
  • Registrado: 09 dic 2007
  • Mensajes: 906
#29

Escrito 23 enero 2008 - 01:04

Hola,
He abierto un hilo en Comunicados y Sugerencias sobre la necesidad de abrir un subforo de programacion. A ver si os pasais votais en la enquesta. 8D
http://zonaforo.meri...ic.php?t=975084

Saludos.

  • sora97

  • Humano

  • vida restante: 100%
  • Registrado: 17 nov 2007
  • Mensajes: 19
#30

Escrito 21 mayo 2008 - 15:33

¿como hago un punto de partida en rpg maker 2003?lo busco y nada. :o O:)


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
publicidad