SoloCodigo

Hola,
bueno la cosa es simple:
de poder hacer uin jegto en java lo puedes hacver.. y muy buenos tambienm..
pero el mismo en juego en otro lenguaje como c++ seria muho mejor,

por que?
porque no estaras tan pendiente del rendimiento , como si lo estaras si lo haces en java, es decir si el puinto critico es el rendimiento, de seguro deberas bajar la calidad de las imagenes , la musica, los modelos 3D, la extension de las escenas, la inclusion de efectos.. etc etc...

Yo que tu aprovecharia para aprender otro lenguaje, pero si quieres hacer el juego.. existen librerias 3d en java(aunque hay que pagar por ellas) tambien puedes arrancar trabajando con java 2d

El problema que veo de programar con JAVA es que tienes que olvidarte de usar ASM. En Delphi y en C++ puedes usar ASM donde te de la gana y optimizar puntos claves de tu código.

No te preocupes que tu juego vaya lento o no por hacerlo en JAVA, en ese caso pesa mucho más la eficiencia de las APIs 3D que consigas para JAVA. Recuerda que el trabajo pesado lo hace el procesador de la tarjeta de video y las librerías para controlarla.

No estoy de acuerdo con Juank respecto a que por el solo hecho de trabajar con JAVA tengas que bajar la calidad de texturas efectos y música, pero si afectará el conteo de polígonos si la API 3D no tiene bibliotecas que eviten usar codigo JAVA para trabajar con los polígonos. Eso si: olvídate de incluir tus propios "efectos", tendrás que conformarte con los que incluya la API 3D y posiblemente restringirte a los que "soporte" la tarjeta de video.

Flaco sos un valiente....
Te haremos un muy bonito funeral luego de suicidarte por ver que tu super juego en JAva en Millones de lineas de codigo anda a "los saltos".

Hola.

Quería aportar mi opinión también a esta discusión. A parte de lo ya dicho en los posts anteriores quería comentar algunos detalles.

"la lentitud" de java (cosa que en mi opinión se puede solucionar con threads)

No veo cómo los threads van a incrementar la velocidad de ejecución de un programa en una máquina monoprocesador. Es más, si no se tiene cuidado, la sincronización de variables compartidas puede formar un cuello de botella en el pipeline de tu motor 3d por excesivas dependencias.

aparte del cobol y el fortran de la universidad, es el único lenguaje que conozco y me gustaría tratar de programar un videojuego en java

A mi me han enseñado Pascal, Caml, Java, C orientado a la programación de comunicaciones en Linux, Lisp y Prolog. Menudo cuadro para hacer videojuegos   . Eso no quita que yo por mi cuenta haya profundizado en C y estudiado C++ para aprovechar todas las características de este lenguaje.

Un detalle importante con respecto a Java nadie lo ha mencionado: El lenguaje es polimórfico. En C++ ésto es una opción: se puede declarar explícitamente un método como virtual o no, dependiendo de si se quiere polimorfismo o no. El polimorfismo simplifica el código, pero también añade sobrecarga en la ejecución por tener que estar buscando el la VTABLE de la clase al hacer una llamada a un método. Una alternativa son las templates de C++, que no añaden sobrecarga (la STL está implementada de esta manera).

Por último, decir que no es imposible la creación de un motor 3d en Java. Un ejemplo de esto es Java is Doomed (http://sourceforge.net/projects/javaisdoomed/), que usa OpenGL y carga modelos md2.

Un saludo.

Ruben3d

Bueno no es por ofender pero.

¡Zapatero a tus zapatos!

Java a la web y C++ A TODO LO DEMAS.

Salu2.

En realidad la tendencia es a la inversa...

Notarás que actualmente los tiempos destinados al desarrollo de software son cada vez más cortos, a tal punto que perder el tiempo en detalles de manipulación de memoria que si bien optimizan el programa hacen más lento y caro el proceso de producción de software al punto que pueden afectar la viabilidad de todo un proyecto.

C++ es un gran criadero de bugs (lo digo por los programadores inexpertos). Necesitas tener un equipo de programadores bastante experimentados en C++ para evitar que tu proyecto sea devorado por los bugs y eso cuesta dinero y los buenos programadores en C++ escacean. ¿Realmente crees que en estos tiempos a alguien le importa que tu programa vaya 3% más rápido (sólo si tienes excelentes programadores o de lo contrario no te servirá de NADA usar C++), o que sea un producto más barato que haga lo mismo y que no tenga los detestables bugs?

C es ideal para programar librerías, específicamente para optimizarlas, pero poco a poco es menos viable para emprender proyectos COMPLETOS: Micro$oft lo sabe muy bien y por eso existe C# : Un copy/paste de Java (forma, sintaxis, apariencia externa) fusionado con object pascal (escencia, mecanismos internos, lenguaje con tipos de datos fuertes, orden) y potencia para trabajar "cómodamente" (según el evangelio de micro$oft) con tecnologías de Internet.

SALUDOS,
Estoy de acuerdo con amilus
aunque c++ es un lenguaje por excelencia, el desarrollo rapido es una necesidad imperante.

Pero el desarrollo en C++ no es rapido por la gran flojera en general de un buen diseño y una buena estructura de reutilizacion, mas de una vez se reinventa la rueda en desarrollo dentro de una empresa y ahí es donde empiezan los bugs.

Si no crea una paleta de componentes con una buena estructura interna, y los mantiene actualizados, los bugs se reducen a aparecer en los primeros meses o el primer añño, luego ya son casi inexistentes.

Pero pocos reutilizan, porq ue las empresas no fomentan la reutilizacion... premian al que escribe mas lineas de codigo o pagan por hora de trabajo, y mas de un pillo las justifica rehaciendo cosas.

La innovacion esta poco fundada en las empresas en general, tal vez no tanto en las de desarrollo puro pero si en las empresas que tienen un departamento de desarrollo se ve claramente que no tienen mucha nocion de como manejar las cosas en la mayoria de los casos, aplican tacticas de RRHH de gestion comercial al desarrollo, cosas completamente incompatibles en la forma de manejar el material humano.

En casi ninguna universidad se da una materia uqe sea "programacion segura" o sobre normas de seguridad que se deben tener en el desarrollo del software, asi como  tampoco se da en general en el aspecto de seguridad a ningun nivel, sea en desarrollo, administracion, etc, porlo que los bugs son comunes que salgan.

Aparte de que no son muchos los que le dedican tiempo y dan pelota al tema de la seguridad en una aplicacion, y mas de una vez no piensan en las implicaciones y riesgos de seguridad que se tienen en una aplicacion, eso es de terror.

Conozco mas de un sistema en el que las passwords estan metidos en uan base de datos en texto plano, y con una seguridad minima (si existe en algunos casos) para el acceso a la base de datos.

Muchas aplicaciones trasladan datos confidenciales a travez de la red sin siquiera cifrarlos de alguna manera, pocos saben todas las formas de Buffer overflow (por dar un ejemplo puntual) que existen en las aplicaciones.

Creo qeu el problema se sienta en las bases.

Y ni hablar del hecho de que cualquier idiota se sienta adelante de VB y hace una "maravillosa" aplicacion llena de agujeros de seguridad y con una mantenibilidad proyectada dos segundos mas alla de la instalacion inicial = 0

puff... Sorry... me cope con la "verba".

slds.