Mojang sigue enfrascada en el perpetuo desarrollo y mejora de su máquina de imprimir dinero, Minecraft, y el próximo gran añadido será una función que vienen pidiendo los jugadores desde el mismísimo primer día. Se trata de la posibilidad de generar un mundo decidiendo sobre algunas de las variables concretas que lo componen.
El añadido viene con la actualización 1.8 (sin fecha de publicación todavía) y nos permitirá manipular cuestiones relacionadas con la escala o la profundidad a través de 16 reguladores, además de otras opciones donde podremos marcar o desmarcar si queremos que se generen estructuras típicas de Minecraft como sistemas de cuevas, templos, aldeas o fortalezas y decidir cosas como la cantidad de mazmorras que queremos o la altura del nivel del mar.
Solo los usuarios registrados pueden comentar - Inicia sesión con tu perfil.
Ya podrían molestarse en portar el juego de java…
No es algo que no requiera mucho trabajo (Salvo el tema de la UI) pero se agradece tenerlo a mano para hacer las tipicas virguerías de ponerlo todo al máximo, mínimo, etc….
El problema es que entonces se encontrarían con otros problemas. No soy partidario de Java pero sí que es verdad que creo que quedarse en java sería lo mejor porque si lo cambiasen a otro sistema mas eficiente (C/C++) entonces tendrían otros problemas como portabilidad (Java funciona en casi todos los sistemas operativos), reconstruir una gran parte del juego, etc.
@ciberjm
Pero el port que hicieron para consolas no usa java, o eso tengo entendido. Vamos, que si ya lo han hecho para consolas no veo por qué no podrían hacerlo para pc. Mantener un juego en java es un atraso en mi opinión.
Si, pero no es un minecraft puro, aparte de Minecraft para PC, están Minecraft Pocket Edition (Móviles) y Minecraft Console Edition (Xbox, Playstation) y aunque Minecraft es de Mojang, están hechas por otro estudio. Y creo que la de Xbox estará hecha en C#, que no es lo mismo que Java, pero no llega al nivel puñetero de programación de C++.
Cierto que Java es una basura pa juegos, pero tambien hay que pensar que Notch no era ningún crack de la programación y que usar Java para hacer prototipos no está mal porque te da muchas cosas ya hechas. El problema es que ahora cualquiera porta todo el motor del juego, técnicamente sería horrible y lo que necesita Minecraft es contenido a saco.
Jeb debería torcer la mano e incorporar Biomes O’ Plenty, la verdad.
Qué bonico es Minecraft.
Y desde cuando nos preocupamos en el lenguaje que esta hecho un juego si lo que queremos es jugar???
No es lo mismo portar una versión de Windows a Mac/Linux que de Java/C# a C++. Incluso no es lo mismo mantener el juego en Java que mantenerlo en C++. C++ da mucha libertad, tanto para crear como para equivocarse y liarla parda.
PD: Pongo C++ como lenguaje porque es el que conozco. Quizás haya otras alternativas pero ahora mismo no se me ocurre ninguna mejor.
@petete_torete
😐
La filosofía de Minecraft no sería la misma si no se encontrara programado en java. Aún sin una API oficial, no son pocos los zagales que han sacado todo tipo de mods para el juego. Que no dudo que los hubieran sacado igualmente aunque estuviera programado en cualquier otro lenguaje, pero la accesibilidad que posee minecraft a la hora de modificar elementos de su core no la tiene cualquier otro juego.
Ojo, que soy el primero que opina que java es un pozo de recursos insaciable, pero posee características que lo hacen el más adecuado para un desarrollo como lo es Minecraft, tan cambiante y modificable.
Yo creo que si nunca se hubiera hecho público que el lenguaje de programación de este juego es Java,a nadie le importaría.
Pero Java es la fea de la familia, y todos a pegarle 🙁
@ciberjm
@end
A ver chavalada, uno de los mitos de la programación más extendidos es que Java es el lenguaje más portable del mundo. Eso no es así, C es mucho más portable que Java. Programas en C compilan y corren incluso en microcontroladores cuyo tamaño de memoria es un cuarto de lo que ocupa una máquina virtual de Java lo más optimizada posible.
El runtime C++ es algo más grande que el de C, así que no es tan potable pero aun así es mucho más portable que Java también. Tíos, la mayoría de máquinas virtuales de Java están programadas en C o C++.
Lo que quizás os confunde es que en Java no tienes que compilar el programa para cada plataforma ya que lo ejecuta la maquina virtual. Y también quizas os hayais creido una de las mayores mentiras de la historia de la programación, el famoso «write once, run everywhere» (escribe el código una vez y ejecutalo en todas partes) con el que Sun introdujo el lenguaje al mundo.
Esto no es así, hay incompatibilidades entre distintas máquinas virtuales e incluso ¡¡¡entre distintas versiones de la misma maquina virtual!! Esto significa que si escribes un programa en Java, lo testeas y todo funciona tal y como debe en tu máquina y lo publicas, otra gente corriendo Java en otra VM puede encontrarse con bugs que en tu VM no pasaban. También puede pasar que cuando la VM saca una nueva versión tu progarma deja de funcionar! JA!
De hecho gente con experiencia en Java dice en plan coña…»write once, debug everywhere».
Lo que hace que un porgrama en C o C++ no sea portable es usar librerias que no lo son. Por ejemplo, si hago un juego en C++ que usa Directx solo va a correr en Windows y punto.
Supongo que Notch usa Java porqué era el lenguaje con el que se sentía más a gusto y nunca pensó que se iba a convertir en el pedazo de monstruo que es ahora.
Lo que dice @petete_torete tiene sentido, pero lo malo es que el comite de W3C no ofrece una implementación de referencia, por lo que cada navegador lo implementa sin tener nada con lo que comparar. Por eso siempre ha habido discrepancias entre navegadores. Cualquiera que haya hecho una página web, incluso una simple, sabe bien de lo que hablo.
Y bueno, los navegadores son monstruos devoradores de recursos (y llenos de bugs) y no quiero que mi juego se ejecute en uno de esos xD
La portabilidad no es sólo que la plataforma lo soporte, sino la facilidad de pasar el código de un sitio a otro. En Java tienes las máquinas virtuales (Sí, cada una hace lo que le dá la gana, pero por algo hay una especificación base que todas deben de seguir) que ya se encargan ellas del código dependiente de la plataforma y también tiene una especificación base mucho mas amplia que la de C y C++. Tú mismo lo dices en que la portabilidad depende de las librerías, y con C/C++ necesitas tirar de librerías para hacer cualquier cosa útil con hebras/redes/GUI cuando Java ya te lo da en la especificación base (Aunque luego puedas añadir más librerías extra)
Pero bueno, estoy totalmente de acuerdo contigo en que lo hizo porque era lo más fácil para él
@ciberjm
Por eso si haces un proyecto en C++ que debe de ser multiplataforma vas a usar GCC + librerias multiplataforma. Claro que no es tan fácil o directo como en Java pero a la larga sale mucho más rentable.
La ventaja de esto es que una vez tienes todo funcionando solo dependes de ti, no de que VM el usuario tiene instalado en el sistema que cambia cada dos por tres y sin previo aviso.
Lo que da miedo de hacer un juego complejo en Java, es que pequeñas decisiones tomadas por el programador de la VM pueden afectar dramáticamente al juego. Por ejemplo, basta que una VM redondee las operaciones en coma flotante de una manera diferente y ya la hemos liado. Debugar cosas así no son nada divertidas. En C también tienes este problema pero solo con las distintas arquitecturas de CPU, que son muy pocas y es muy fácil de testear, basta que tengas un ARM, un Intel y un AMD y cubres el 99% del mercado xD
Ah! Y se me olvidaba, luego está el asunto de si quieres un lenguaje con «Garbage Colector» o no, pero eso da para otro debate mucho más peliagudo xDDD
@tocapelotas
Si, es la guarrada, si cambian el VM, tienes que cambiar tu el código. Ambos tienen sus ventajas e inconvenientes, te quitan la mayoría de problemas con memoria a cambio de otros problemas.
Y en efecto, el tema de Garbage Colector es un caos, por eso siempre digo que como no se aprenda C o C++ como primer lenguaje… xD
@tocapelotas
@ciberjm
Al final siempre tienes que delegar. Sino delegas responsabilidad en la VM, la delegas en el desarrollado de las librerías cross platform, que al igual que la VM, pueden hacer lo que les de la gana. Yo personalmente no me pondría a hacer un videojuego en Java. Para un prototipo pues bien, pero a la que le proyecto crece, creo que implica mas contras que inconvenientes, no de cara al usuario, que puede que ni se entere, sino de cara al mantenimiento y amplicación.
No, no es lo mismo. Eso es lo que estoy intentado decir xD Si yo uso Bullet 2.83 para las físicas de mi juego, por ejemplo, me da igual que el equipo de Bullet continue sacando versiones o que cambien la API al completo, porqué yo siempre voy a usar la 2.83 y mi juego se va a publicar con la 2.83. Lo importante aquí es que estoy desarrollando con las mismas librerías que el usuario va a tener en su sistema, porqué soy yo quien se las va a dar, él no puede hacer nada al respecto.
Esto no es así para las VM, ya que el usuario puede decidir actualizar la VM o instalar una nueva sin previo aviso. Esto no debería ser un problema en teoría, pero en la práctica si que lo es. Por eso siempre digo que lo de la multiplataformidad de Java hay que cogerla con pinzas. Si, es multiplataforma, pero preparate para depurar bugs super retorcidos.
Tienes razón en lo que dices al final, todo esto que menciono es el mayor inconveniente (no el único), y va a afectar el mantenimiento de un proyecto grande a niveles que son muy difíciles de imaginar cuando empiezas a crear un par de clases.
@tocapelotas
Mira, tienes razón. No habia pensando en que distribuir una VM con tu app es mas complicado que distribuir una versión concreta de unas librerias. En cualquier caso, con los entornos de desarrollo que hay hoy en dia, que prácticamente te permiten cambiar el target de compilación sin demasiado esfuerzo, no tiene sentido usar Java.