Dudas acerca de la programación de videojuegos

Buenas a todos;.

Desde hace varias semanas llevo ojeando este apartado del foro (videojuegos) y con la curiosidad me he estado documentando sobre el tema. Dado que tengo una base de programación en javascript, me he estado peleando unas semanas en realizar unas imitaciones cutres de algunos juegos a los que jugaba de pequeño (el Pacman, Snake, Pong), todos realizados con C++ (sintaxis que me pareció similar con el javascript).

Me ha costado la vida, pero me lo he pasado teta (más con los resultados que con el proceso, para qué mentirnos) y ahora estoy con ganas de más, por lo que me he propuesto aprender programación de videojuegos, dado que es dónde podría sacar más partido a lo que sé acerca del desarrollo de videojuegos.

El objetivo es que, con el tiempo, pudiera realizar algún que otro proyecto pequeño, donde pudiera realizarlo todo o casi todo el trabajo. Luego usarlo como CV y que me ayude encontrar curre dentro del sector.

Y ahora las dudas:
Exactamente no sé por dónde tirar, me explico. El planteamiento inicial es empaparme todo lo que pueda sobre C++ (teoría, ejercicios prácticos) y, conforme vaya cogiendo la base, ir metiéndome en algún motor con el que ir trabajando. Había pensado en UDK (tendría qué aprender también Unrealscript), pero no sé si debería iniciarme de primeras con el GameMaker que, aunque creo que es más limitado, supongo que, para iniciarse no debe estar mal.
¿Cómo lo veis? ¿Debería enfocarme antes en otra cosa o quizás plantearlo de otro modo?
Un saludo y gracias.

También podrías estudiar un CFGS de Desarrollo de aplicaciones Web o Desarrollo de aplicaciones multimedia.

Casi todos los que acaban alguno tienen trabajo actualmente, y un experto en este sector comentó que lo ideal es hacer los dos.

Hombre yo te recomendaría alguna carrera, no sé si ahora continua llamándose ingeniería informática, necesitas la base, tanto para videojuegos como para aplicaciones bancarias, si pasas de carreras cosa que no veo mal, ya sabes Internet a muerte, y C++ es lo que por ahora se usa en videojuegos, pasa de cursos de esos de, programación para videojuegos, cada estudio es un mundo, cada uno usa su propio motor, esos cursos son genéricos, puedes aprender algo, pero tendrás más oportunidades con una carrera (en programación sí la piden) y con 4 o 5 cosas curradas por ti en casa.

Respeto a UnrrealScript lo siento casi ya no existe, la versión 4 del Unreal no usa UScript, lo cambiaron por algo parecido a C# con entorno gráfico por anidados, algo muy chulo, pero que nos tiene hasta los mismísimos a los atristas técnicos, antes era programación el que hacia ciertas cosas ahora no. Saludos.

Weje. Cierto, el UE4 ya no usa uscript y se han pasado del todo a C++, usando el Visual Studio para programar, o una aplicación interna llamada Blueprint para hace scripting visual. Yo hace unos meses (sin tener mucha idea de programación) me puse con el Game Maker a saco a aprender GML y la verdad es que me divertí como un niño haciendo experimentos y aprendiendo. Creo que el Game Maker está muy bien para aprender cosas fundamentales sobre la programación de videojuegos, porque es muy sencillo y asequible de comprender, y te centras en el diseño del código y del propio juego. Aunque si te metes directamente al C++ creo que es mejor. Podrías aprovecharte ahora qué el UE4 esta tan barato, y la documentación que están sacando está muy bien estructurada y es muy buena (no he mirado documentación de programación, solo de la parte artística).

Hay mucha información, pero la qué sale del UDN hay que pillarla con pinzas, hay muchas cosas que salen ahí que son de la versión 3 y que no están implementadas en la 4, o que directamente está mal, pero bueno desde que es gratis pagando 20 euros la cosa ha mejorado, hay unos videos que para principiantes son lo mejor.

Puede que sea buena idea aprender algo más simple, pero depende de lo que quieras hacer, si es por curre, actualmente el Unity es el más demandado, te recomendaría C# al 100% que ya sabes que es parecido al JS, no creo que el Unreal4 sea tan usando como lo fue el UDK, pero bueno, cosas de Epic y del cambio de directiva, desde luego si no currase con ue4, me iría de cabeza a aprender Unity.

Otra cosa es que seas neurocirujano y que esto lo tengas como hobbie, entonces aprende lo que más te guste, la cosa es que el UE4 con los blueprint, es una herramienta muy potente, pero no sabes hasta cuando, se puede hacer más con ella qué con uscript de antes, eso sí, como te dije a los artistas técnicos nos trae locos. Saludos.

Qué tal gente;.

Lo primero de todo, quiero daros las gracias por echarme un cable y aconsejarme:

También podrías estudiar un CFGS de Desarrollo de aplicaciones Web o Desarrollo de aplicaciones multimedia.

Gracias Nugu por el consejo. Me apuntaré esos cursos y les echaré un vistazo, aunque no tengo planteamiento de hacer un curso a corto plazo, a no ser que merezca muchísimo la pena.

Creo que el Game Maker está muy bien para aprender cosas fundamentales sobre la programación de videojuegos. Aunque si te metes directamente al C++ creo que es mejor. Podrías aprovecharte ahora qué el UE4 esta tan barato.

Pues he estado barajando esa posibilidad, SerKBer. Estaba pensando en empezar con GameMaker y luego pasarme directamente al UE4, que ese precio me llama poderosamente la atención.

si pasas de carreras cosa que no veo mal, ya sabes Internet a muerte, y C++ es lo que por ahora se usa en videojuegos, pasa de cursos de esos de, programación para videojuegos, cada estudio es un mundo, cada uno usa su propio motor, esos cursos son genéricos, puedes aprender algo, pero tendrás más oportunidades con una carrera (en programación sí la piden) y con 4 o 5 cosas curradas por ti en casa.

Esa es la idea Fiz3d, estudiar una carrera no está dentro de mis posibilidades, al menos por ahora, de modo que tengo que trabajármelo todo desde casa. Creo que no me he enterado bien, ¿exigen que tenga la carrera para poder trabajar como programador en videojuegos? Aunque una titulación oficial nunca viene mal, pensaba qué no era requisito indispensable para entrar a trabajar dentro del sector. Ya me has dejado con la duda.

actualmente el Unity es el más demandado, te recomendaría C# al 100% que ya sabes que es parecido al JS, no creo que el Unreal4 sea tan usado como lo fue el UDK.desde luego si no currase con ue4, me iría de cabeza a aprender Unity.

Otra cosa es que seas neurocirujano y que esto lo tengas como hobbie, entonces aprende lo que más te guste.

Encontrar curre en este sector es el objetivo Fiz3d. Empecé a aprender desarrollo web e hice algunos trabajos. Aunque no me disgustó, empecé a indagar sobre el desarrollo de videojuegos y decidí iniciarme por la programación, ya qué pienso que, por ahora, es donde mejor puedo desenvolverme. He estado ojeando la página de Stratos y bueno, ya entiendo por qué mencionas el Unity, casi la mayoría de las ofertas son de Unity. También he estado ojeando su web y, si no me equivoco, son unos 75 EUR mensuales por la versión pro, sin limitaciones.

Unas dudas Fiz3d:
-¿Recomendarías Unity solamente por la oferta de trabajo que hay, o hay alguna razón más?
-¿Por qué te decantas por el Unity3d antes que el UE4?
-¿Qué debería hacer ahora? ¿Termino de aprender las bases con C++ y luego irme a por C#, o quizás empezar directamente con C# y en vez de usar el UE4, usar el Unity?
Aunque como bien dices, los requisitos de cada estudio varían según sus necesidades, imagino que tarde o temprano acabaré aprendiendo a manejar distintos lenguajes, así como los motores. No obstante, si crees que debería iniciarme antes con C# que con C++, o al contrario, estaría bien saberlo.

De nuevo quiero daros las gracias por orientarme en este tema, que la verdad estoy más que verde en este aspecto. Bueno, verde es decir poco. Un saludo y gracias.

Posdata: Por cierto, he empezado esta mañana a con lo básico de C++. No me está costando tanto coger la dinámica, esperemos que siga más o menos así.

Sobre la carrera, yo he trabajado en varias empresas de videojuegos, cuando estaba en Tragnarion sí pedían la carrera, aunque podías entrar si la estabas cursando y sobre todo si pasabas la prueba, en Tequila no tengo ni idea de cómo va, pero casi seguro que la piden, en otras empresas depende, pero bueno, muchas te hacen una prueba si la pasas pues genial.

Es un requisito indispensable, no, te explico, si ahora mismo controlases al 100% los Blueprints de Unreal4, tendrías curre fijo, y me atrevería a decir que podrías incluso elegir donde, pero esto de digo de hoy mismo, igual dentro de un mes pues ya no, la industria cambia mucho hoy se pide A y mañana B, lo que si es casi indiscutible es aprender C++, desde luego tener carrera te abre más puertas, pero tener un juego creado por ti en casa también, sobre todo fuera de España.

Sobre Unity o Unreal, te lo digo porque ahora mismo se hacen más proyectos en Unity que en unreal, con lo que tendrás más posibilidades de encontrar trabajo si tiras hacia Unity, pero pasa como todo, mañana cambian las cosas y todo dios a usar Unreal, por otro lado, los proyectos creados en Unreal son más grandes, suelen ser tripleA, Unity, aunque es muy potente tiende más al mercado Smartphone o juegos pequeños, aún no ha salido un tripleA en Unity. Eso sí, tanto en uno como en el otro conocimientos de C# son necesarios.

Qué tendrías que hacer ahora, lo que más te guste, necesitas una base, necesitas saber cómo se trabaja en videojuegos, el C++ es necesario yo me pondría con el a saco y después C# y mientras miras como es el Unreal y el Unity.

Lo malo de esto es que hoy te puedo dar el mejor consejo del siglo y mañana ser el peor, las cosas cambian mucho, seguro que dentro de un año cuando salgan las oculus todo el mundo a crear contenido para ellas. Saludos.

[QUOTE=uno+;904595].
-¿Qué debería hacer ahora? ¿Termino de aprender las bases con C++ y luego irme a por C#, o quizás empezar directamente con C# y en vez de usar el UE4, usar el Unity?[/QUOTE]Personalmente, cuando aprendes a programar aprendes conceptos y formas, que son comunes en todos los lenguajes que comentas, serían los idiomas de esos conceptos. Saludos.

La mejor forma de aprender a programar videojuegos es, en mi opinión, programar un Game Engine sencillo, por ejemplo, en 2D.

Esto te forzaría a investigar como funcionan muchas cosas de bajo nivel que, aunque seguramente no las uses nunca más, te sirven para adquirir una buena base sobre la dinámica. Si entiendes cómo funciona un Game Engine por dentro, después aprender a usar un Game Engine no es tan difícil, pues todas las cosas las entiendes, al final solo cambia la forma de hacer lo mismo, las posibilidades que ofrecen.

Si yo fuera tu, cogería una librería gráfica como SFML, o si quieres algo más complejo DirectX u openGL (que son las 2 más usadas en los videojuegos), y con C++ intentaba crear algo sencillo. Las comillas son porque no es sencillo, y te veras obligado a investigar cómo funciona el flujo de un juego, que hacer con los datos (sonido, imágenes, etc), a lo mejor te apetece meterle un sencillo simulador de física, un sistema de partículas con 2 o tres parámetros.

Yo, por ejemplo, hice un sencillo Game Engine para hacer juegos en la terminal de Ubuntu, con la librería ncurses de base. Me cree estructuras de datos que emulaban los sprites de los juegos 2D, un sistema de render, de tilemaps, colisiones, todo usando caracteres ASCII como output. Pero al final la base es la misma.

Si aprendes c++, ficheros, y te pegas un curre pare hacer un Game Engine (esto igual te podría llevar un mes), programable a través de ficheros, obtendrás la base que necesitas y que te dará soltura con la programación (no solo con c++, porque si aprendes a programar en c/c++, pasar a cualquier otro lenguaje es pan comido) y concretamente con la programación de videojuegos.

Y te pongo mi ejemplo, después de implementar este GE de terminal, diseñe uno con SFML, usando gráficos 2D, pero este ya no suponía tanto reto como el otro, porque solo era coger la teoría del otro y usar una librería gráfica, básicamente. Y ahora toqueteo cosas en varios games engines por aprender y me resulta muy fácil e intuitivo (udk, Unity, Blender, y algunos sin interfaz gráfica como darkGDK).

Solo es una propuesta, pero me parece la mejor forma de conseguir la base.

Posdata: Hay dos libros; Desarrollo y programación de Videojuegos: Curso de iniciación y Curso avanzado, que básicamente te enseñan a programar juegos en C++ usando directamente la API de Windows, creando un Game Engine y modificando. Si te les y eres capaz de entender e imitar los ejercicios de ese libro conseguirás sin duda la base que necesitas.

Buenas gente;.
[QUOTE=Fiz3d;904612]desde luego tener carrera te abre más puertas, pero tener un juego creado por ti en casa también, sobre todo fuera de España.[/QUOTE]Ea, entonces lo entendí mal. Me alegra leer eso.[QUOTE=Fiz3d;904612]ahora mismo se hacen más proyectos en Unity que en unreal, con lo que tendrás más posibilidades de encontrar trabajo si tiras hacia Unity, pero pasa como todo, mañana cambian las cosas y todo dios a usar Unreal. Eso sí, tanto en uno como en el otro conocimientos de C# son necesarios.[/QUOTE]Me lo imaginaba, Stratos no engaña. Al final acabaré aprendiendo de todo, seguro, pero eso está bien de cara al futuro.[QUOTE=Fiz3d;904612]necesitas una base, necesitas saber cómo se trabaja en videojuegos, el C++ es necesario yo me pondría con él a saco y después C# y mientras miras como es el Unreal y el Unity.[/QUOTE]Ahora mismo estoy a saco con el C++ y en cuanto pueda empiezo con C#, complementandolo también con el uso de alguno de los engines.[QUOTE=Fiz3d;904612]Lo malo de esto es que hoy te puedo dar el mejor consejo del siglo y mañana ser el peor, las cosas cambian mucho, seguro que dentro de un año cuando salgan las oculus todo el mundo a crear contenido para ellas.[/QUOTE]Aun así, como bien has dicho, sin una base previa no conseguiré nada. Ya tengo material con el que ir empezando y bien. Te agradezco que te pases por aquí a echarme un cable, de verdad.

El tema de Oculus, tiene que ser una pasada poder crear contenido para ellas, vi algunos videos de juegos adaptados y dios, como engancha la cosa.[QUOTE=ciberspace;904623]Personalmente, cuando aprendes a programar aprendes conceptos y formas, que son comunes en todos los lenguajes que comentas, serían los idiomas de esos conceptos.[/QUOTE]Yo estoy empezando a pensar de la misma forma, ciberspace. Cuando empecé con el C++, vi que tenía ciertas similitudes con el javascript. Eso me alivió bastante y ahora que lo estoy estudiando no me resulta tan complejo como creía en un principio. Si, por ejemplo, C# también comparte esas similitudes, será más sencillo que me haga con él. Gracias por el consejo tío.[QUOTE=Sadyk;904634] La mejor forma de aprender a programar videojuegos es, en mi opinión, programar un Game Engine sencillo, por ejemplo, en 2D.

Si aprendes c++, ficheros, y te pegas un curre pare hacer un Game Engine programable a través de ficheros, obtendrás la base que necesitas y que te dará soltura con la programación (no solo con c++, porque si aprendes a programar en c/c++, pasar a cualquier otro lenguaje es pan comido) y concretamente con la programación de videojuegos.

Solo es una propuesta, pero me parece la mejor forma de conseguir la base.[/QUOTE]Me lo a punto a la lista de tareas, Sadyk. Imagino que para hacerlo deberé tener una mínima base con C++, así que, me pondré con ello cuanto antes.[QUOTE=Sadyk;904634]Posdata: Hay dos libros; Desarrollo y programación de Videojuegos: Curso de iniciación y Curso avanzado, que básicamente te enseñan a programar juegos en C++ usando directamente la API de Windows, creando un Game Engine y modificando. Si te les y eres capaz de entender e imitar los ejercicios de ese libro conseguirás sin duda la base que necesitas.[/QUOTE]Gracias, en serio, mil gracias tío. Los he ojeado en la web y me van a venir de perlas para mejorar; según he leído, el de iniciación no hace falta un nivel tan bueno en el manejo de C++ para seguirlo, pues todo viene bien explicado (o al menos eso dice el libro).

He visto más libros de este autor y creo que me haré también con el de C++ para iniciación (link). Lo complemento con lo que estoy aprendiendo ahora aquí y, en cuanto los digiera, me pondré con los de Desarrollo y Programación de Juegos.

De nuevo os quiero dar las gracias, a todos. Me estáis ayudando muchísimo para qué pueda orientarme y empezar en esto; al principio me encontraba bastante perdido con el tema y con vosotros estoy empezando a trazarme una ruta qué de seguro va a ser muy provechosa. Espero que con algo de tiempo pudiera ir enseñando cosas, para qué se vayan viendo por aquí los avances y comentarlos. Un saludo y gracias.

Buenas gente, que tal va eso;.

Ya por fin me han llegado los libros, unas 1600 páginas que me van a tener entretenido bastante, la verdad.

Ahora mismo me estoy viendo las estructuras, y dentro de muy poco espero poder empezar a tocar los punteros (que ya he visto un adelante y los ojos se me salen de las órbitas). A ver si no me estánco mucho y puedo empezar pronto los libros de programación de videojuegos, que estoy ansioso la verdad.

Quería haceros una pregunta. En los ratos libres me estoy viendo tutoriales del manejo del UE4 y he estado ojeando los Blueprint. Si no me equivoco, sustituye al UnrealScript y favorece (aunque según Fiz3d no tanto) a los artistas técnicos para programar eventos (perdonadme si me equivocó con los tecnicismos). Yo quería preguntar:
- ¿Los programadores que sepan manejarse con un lenguaje como C++ O C#, deberían hacer su trabajo con los Blueprint o también podrían trabajar con puro código?
- ¿Hasta dónde podría llegar el potencial de los Blueprintú Quiero decir si se podrían conseguir los mismos resultados, independientemente de si trabajas con código o con los Blueprint.

Creo que esas son todas las dudas, por ahora. La cuestión es que viendo uno de los tutoriales de introducción, aclaran que para programar pequeños eventos está muy bien, pero a ver si los que conocen más el tema podrían aclararme hasta qué punto es útil el uso de los blueprint. Gracias por vuestra ayuda y consejos. Un saludo.

A ver a mi los Blueprint me vienen bien porque antes tenías que estar más pendiente del equipo de programación para un montón de cosas, ahora bueno, si te lo curras lo puedes hacer tú, solo que siempre tendrás un programador que te lo modifique te lo mejore y te toque un poco los cuernos con ciertas historias, pero esto suele ser lo de menos, por otro lado, es muy potente, puedes hacer un montón de cosas sin tocar casi C++.

En que me perjudica, primero hay que saber usarlo, y ya tienes que tener conocimientos de programación por encima de lo que se requería antes, esto nos trae un problema, antes del artista técnico hacía FX, shaders, los llamados Basic shaders, que eran shaders parametrizados para qué los artistas solo tengan que meter las texturas jugar con 4 parámetros y ya, temas de dinámicas, algunas cinemáticas etc los programadores se encargaban de cosas como, pinchar un efecto, quiero que este FX se plante en el suelo justo donde aparece el personaje al recibir un impacto de granada verde, y que salga el sonido y que etc, de eso se encargaba programación, pues ahora no, que pasa con esto, los artistas técnicos nos estamos metiendo en el campo programación, o sea, más curre mismo sueldo, y por otro lado, un artista técnico nunca podrá suplantar a un programador, pero eso se lo cuentas a la dirección de la empresa, también hay detalles tipo, si se me ocurre algo para mejorar el juego, FX, lo que sea, antes lo contaba y programación valoraba si hacerlo o no, ahora mejor me lo callo porque si no lo sé hacer pues mala cosa.

Por otro lado, cosas que antes eran muy fáciles con kismet, o sin él, ahora se han vuelto muy jodidas, antes crear un dinamic instance Shader era botón derecho create dinamic instance Shader y ya está, y ahora es crear un blueprints con el modelo que lleva ese Shader dinámico, hacer cast al modelo, traer el Shader convertirlo a dinámico y aplicarlo al objeto, todo dentro del BP, bien, no es complejo si lo sabes hacer si no te las ves esclavas, por otro lado, si le tienes que, aplicar ese Shader a 200 objetos vas muy de culo por que la cosa se complica, entramos en el maravilloso mundo de los arrai, tenemos 200 blueprint, lo que mola qué una vez lo hagas tienes una variable que identifica a ese shader, con lo que puedes acceder a el desde dónde te salga de ahí.

Ates era muy fácil trabajar con matine, ahora buf, hay que darle muchas vueltas para llegar a lo mismo, y se terminaron los trucos guarros, como pillar el kismet, seleccionarlo todo copiarlo al portapapeles pastearlo en el Skype y pasarle todo el level a un compañero, hay mil cosas que ya no se pueden hacer, que seguro que se pueden hacer de otra forma, pero bueno, el kismet estaba bien.

En resumidas cuentas, para él programador mejor, se despeja de curre y tiene un sistema de programación gráfico muy mono, para él Artista técnico depende del balance entre artista y técnico, pero suele dar mucho por ahí, para él proyecto, bueno el kismet iba bien se han hecho buenos juegos con él, podrían haberlo dejado, para salvar han puesto el script level que según ellos es el kismet, y no, son como los caramelos sin azúcar, son caramelos sí, pero es lo mismo, no.

Eso sí a potencia no hay quien le gane.

¿Los programadores que sepan manejarse con un lenguaje como C++ O C#, deberían hacer su trabajo con los Blueprint o también podrían trabajar con puro código?

Pueden hacerlo con lo que quieran, eso es a elección del programador, pero estoy viendo que muchos se decantan por los BP, por ejemplo, en un proyecto hace falta qué el personaje detecte qué material esta pisando (arena, agua, barro, piedra etc) para saber qué efecto lanzar, que sonido, y las propiedades físicas, en el agua te mueves más lento que en la piedra, antes todo esto era código, a lo bruto supongo que, script o c++, ahora no, ahora todo van dentro del VIM que es como un blueprints orientado a personajes, o dentro del blueprints del personaje, esto está bien ya que los diseñadores acceden a parámetros del personaje como la velocidad, la vida, la recuperación, mil cosas que antes era ir a programación y probar, ahora ellos modifican esos parámetros sin problema, tanto en el player como en los NPC
Lo que aún no sé es la velocidad, el kismet era 800 veces más lento de ejecutar que C++ y no sé cuántas que script, pero ni idea del BP.

¿Hasta dónde podría llegar el potencial de los Blueprintú Quiero decir si se podrían conseguir los mismos resultados, independientemente de si trabajas con código o con los Blueprint.

No, hay cosas que solo se pueden hace en C++, muchas veces quieres tocar cosas como la iluminación o las sombras, o cómo actúan las dinámicas, incluir nuevos nodos en los shaders, o en el cascade, todo eso se tiene que hacer por código, el código siempre va a ser más potente que el BP. Por otro lado, pocas empresas son las que el meten mano al motor a ese nivel, quiero cambiar el sistema de iluminación, de hecho, ya hay varios plugins para hace esto.

Por otro lado, los plugin del U4 se tienen que hacer en C++ desde fuera. Saludos.

[QUOTE=Fiz3d;905819]Pueden hacerlo con lo que quieran, eso es a elección del programador, pero estoy viendo que muchos se decantan por los BP.

No, hay cosas que solo se pueden hace en C++, muchas veces quieres tocar cosas como la iluminación o las sombras, o cómo actúan las dinámicas, incluir nuevos nodos en los shaders, o en el cascade, todo eso se tiene que hacer por código, el código siempre va a ser más potente que el BP.[/QUOTE]Buenas, que tal;.

Ok, entonces, según lo que me cuentas creo que puedo sacar algunas cosas en claro (hablando del UE4, por supuesto):
- Mientras no se tenga qué tocar aspectos propios del Engine, todo (o casi todo) el trabajo de un programador podría hacerse desde los BP. Si ya empezamos a tocar cosas propias del engine, ya hay que ir a la propia fuente y toquetearla, o sea escribir con C++.
- La segunda cosa qué tengo más o menos clara es que ni a Fiz3d (ni a los artistas técnicos) le ha molado nada la actualización al UE4. Creo que empiezo a comprender algo mejor porqué te gustaría pasarte al Unity. Gracias por aclararme esas dudas Fiz3d, yo me pensaba qué las posibilidades de los BP no eran tan altas como en un principio pensé. Lo veía más para cosas de menos complejidad, pero está claro que habrá que empaparse bien el tema y sacarle todo el provecho posible. Otra cosita más para la lista de quehaceres. Un saludo y de nuevo gracias.

Posdata: si el mundo de los arrays te parece maravilloso, espero que no tengas que pasarte por el mundo de los punteros. Disneylandia para locos.

Fiz ¿porque no crees que ue4 sea tan usado como udk? Yo recién lo estoy empezando a mirar y se me cae la baba. No he profundizado mucho aún, pero parece tener mucha potencia y el acabado gráfico que se consigue es espectacular.

Es verdad que hace falta mucha máquina, que es el principal problema qué veo para usarlo en pequeños estudios, pero yo creo que en un año más o menos eso dejara de ser un problema. Y el precio que tiene es genial. No sé, yo tal como lo veo, creo que puede tener tanto éxito como udk. Pero claro, tu conoces tanto udk como ue4 mil veces más que yo, imagino que la complejidad de hacer ciertas cosas ahora también se debe a qué tienes más posibilidades por eso de tener que hacerlas en blueprint. Saludos.

[QUOTE=Nugu;904447]Desarrollo de aplicaciones multimedia.

Casi todos los que acaban alguno tienen trabajo actualmente.[/QUOTE]Es lo que estudio yo (aunque es multiplataforma, no multimedia) y eso de que casi todos encuentran trabajo lo dudo muchísimo.

La segunda cosa qué tengo más o menos clara es que ni a Fiz3d (ni a los artistas técnicos) le ha molado nada la actualización al UE4. Creo que empiezo a comprender algo mejor porqué te gustaría pasarte al Unity.

No es que me gustaría pasarme Unity el problema de Unity es que no tiene grandes proyectos como Unreal, me gustaría aprender a usarlo, de todos modos Unity a nivel programación no tiene nada como los BP o el Kismet, a nivel shaders tampoco, ahí sí que te hace falta sí o sí un programador.

Fiz ¿porque no crees que ue4 sea tan usado como udk? Yo recién lo estoy empezando a mirar y se me cae la baba. No he profundizado mucho aún, pero parece tener mucha potencia y el acabado gráfico que se consigue es espectacular.

Principalmente por Unity, este copa el mercado de las Apps, Unreal para smartphones mala cosa, después es mucho más complejo que el UDK, requiere mucha más máquina, un estudio indie de dónde bebía el UDK, no puede hacer un juego con target mínimo de una 660 (lo de 450 es cachondeo) el udk se movía en una 8800 hablamos de una gráfica de hace 7 o 8 años.

Antes no se sabía si iba a existir una versión barata del motor, ahora veremos cómo van las cosas, hay que esperar unos meses para ver si se empieza a sacar el jugo al motor y no me refiero a potencia ni nada, si no hacer cosas chulas para pequeñas máquinas, por otro lado, no hay mucha gente que controle de unreal4 y eso da algo de miedo a los estudios.

Eso sí, profundizando en temas de iluminación es la caña, te genera una atmósfera qué ni los rendes normales. Saludos.

[QUOTE=Fiz3d;906637]No es que me gustaría pasarme Unity el problema de Unity es que no tiene grandes proyectos como Unreal, me gustaría aprender a usarlo, de todos modos Unity a nivel programación no tiene nada como los BP o el Kismet, a nivel shaders tampoco, ahí sí que te hace falta sí o sí un programador.

Principalmente por Unity, este copa el mercado de las Apps, Unreal para smartphones mala cosa, después es mucho más complejo que el UDK, requiere mucha más máquina, un estudio indie de dónde bebía el UDK, no puede hacer un juego con target mínimo de una 660 (lo de 450 es cachondeo) el udk se movía en una 8800 hablamos de una gráfica de hace 7 o 8 años.

Antes no se sabía si iba a existir una versión barata del motor, ahora veremos cómo van las cosas, hay que esperar unos meses para ver si se empieza a sacar el jugo al motor y no me refiero a potencia ni nada, si no hacer cosas chulas para pequeñas máquinas, por otro lado, no hay mucha gente que controle de unreal4 y eso da algo de miedo a los estudios.

Eso sí, profundizando en temas de iluminación es la caña, te genera una atmósfera qué ni los rendes normales. Saludos.[/QUOTE]Hombre, pero que se moviera en una 8800 es lógico, esa gráfica era la gama alta de entonces y superaba a la xbox360 y ps3. Yo tengo un portátil con una 9600GT que, si no estoy equivocado es como una 8600GT y udk me va regular Yo pienso eso, que tiene que pasar un poco el tiempo para ver si tiene éxito ue4 Yo apostaría qué lo tendrá más adelante, ahora mismo está claramente la balanza inclinada a Unity en el tema indie.

Yo con la iluminación los efectos de mensaje process y todo eso estoy flipando, me sorprendió mucho lo del Indirect Lighting Cache, no sabía qué era capaz de simular la luz indirecta en los objetos dinámicos, mola mucho. Los reflejos también están muy bien conseguidos, pero me esperaba un poco más, se ven muy realistas, pero cuando te vas dando cómo funciona y eso empiezas a encontrarle limitaciones.

Perdón 6800, dije 8800 porque yo tenía un portátil con esa gráfica cuando pillé el unreal.

UDK también tiene algo parecido a indirect light cache, no es lo mismo, pero se parece, pero aun así hay cosas que, en Unreal 4 no puedes excluir de forma relativamente fácil objetos de la luz, no puedes decirle en qué capa se dibujan, y mil cosas que buf, lo imperdonable es que no tiene vectorlight en los shaders, y vamos eso lo usaba yo en casi todos.

Lo reflejos para ser tiempo real está muy bien, el tema de los shaders físicos reales, al principio costó, hasta epic pedía paciencia por las quejas que había, al final era cierto, cuando lo pillas son muy potentes, la luz se refleja en los objetos (los que no tienen reflexión, solo el rougdness por debajo de 1 de una manera casi real, es impresionante, notas la profundidad del specular, antes la verdad es que era todo una guarrada, la cosa es que, si el objeto no es rugoso es pulido y si es pulido refleja, punto pelota, los especulares en la vida real, no tienen color, son en escala de grises, pero antes podías meter especulares de colores, solo el metal tiene un especular de color que depende del base color, o si la luz que crea ese especular tiene color.

El cascade no lo han tocado mucho, pero las gPU particles están muy bien, que estas puedan emitir luz, se pueden meter objetos con animación de vértices como partículas.

Y toda la relación que hay con los bueprint, lo que no me gusta es la eliminación del kismet.

A ver es potente, pero creo que su complejidad ha subido mucho. Saludos.

Si, los reflejos están muy conseguidos la verdad y funcionan muy bien en la mayoría de materiales. Pero si miras un objeto muy pulido desde algunos puntos de vistas, lo que se refleja es lo capturado por el reelfection actor y si este no existe, no se verá nada. Aparte de que son reflejos estáticos, puede dar problemas a la hora de crear espejos. O puede verse dos veces un mismo punto de luz (el del reflection actor y el specular). O se crean distorsiónes. Cosas así:

https://www.youtube.com/watch?v=VeV-m92Ag9I.

También es que yo pido mucho, la verdad, para ser realtime es la leche.

No hace falta qué tengas un reflection actor, puedes poner un mapa dentro de un postprocces volumen, en reflectión map y también funciona, lo del actor es para hacer reflejos en tiempo real, imagina qué tenga qué calcular el reflejo por cada textel, se puede morir el motor.

Pero este tipo de reflejos del suelo molan mucho.

Unreal Engine 4 | Blueprints Office Demo | GTX 780 Ti. Saludos.

Y yo aquí con los dientes largos, menos mal que a partir de la semana que viene saco más tiempo libre y empezaré a juguetear con el Unreal.

Por cierto, ya me he tragado tanto el curso que estaba siguiendo sobre C++ como el libro que compré para complementarlo con lo que leía en Internet. No me arrepiento para nada de haber pillado ese libraco, gracias a él se me ha hecho mucho más sencillo entender las cosas, aunque sé que tendré que estar volviendo a él continuamente cuando surjan las dudas. Ahora, cuando leo los tutoriales que trabajan con archivos.cpp y.h en unreal, ya no parece que esté leyendo a matrix, gracias a dios.

A partir de la semana que viene también empezaré con los libros sobre programación de videojuegos, que he estado ojeando el temario por encima y promete bastante. Un saludo gente.

[QUOTE=Fiz3d;906727]No hace falta qué tengas un reflection actor, puedes poner un mapa dentro de un postprocces volumen, en reflection map y también funciona, lo del actor es para hacer reflejos en tiempo real, imagina qué tenga qué calcular el reflejo por cada textel, se puede morir el motor.

Pero este tipo de reflejos del suelo molan mucho. Saludos.[/QUOTE]Yo por lo que he visto los reflection actor no son en tiempo real. Lo bueno de los reflection actors que tienen es que se pueden poner en lugares estratégicos para corregir la reflexiones.

Yo por lo que he podido comprobar, las reflexiones se hacen usando dos técnicas; la del screen space reflections (creo que se llama así, en otros sitios si no recuerdo mal leí screen space raytrace), que, por las pruebas que he hecho lo que hace es reflejar en tiempo real solo que se ve en pantalla y por eso hace falta un mapa qué complemente estas reflexiones, que serían o los reflection actors o un ambient cubemap dentro del prostporcess. Y esta sería la segunda técnica.

Está bastante bien pensado, porque si no te pones a buscar cómo funciona parecen reflejos 100% en tiempo real. Que es lo que yo me pensaba antes de ponerme a curiosear. Saludos.

Yo por lo que he visto los reflection actor no son en tiempo real.

En el 3 lo eran, no sé si en el 4 lo han cambiado, estoy con un juego pre era de los metales y otro cartoon que no tiene reflejos, así que, no los he tocado, lo del cube map en el prostproceso es a lo que yo me refería. Saludos.

Ah vale, me parece que estamos hablando de actores diferentes.

Yo me refería a estos: [URL]https://docs.unrealengine.com/latest/INT/Resources/Showcases/Reflections/index.html[/URL].

Internamente deben funcionar parecido, eso sí. Saludos.

Algunos son como los del 3, en el 3 eran en tiempo real incluso le decías cuando FPS querías que capturase, pero lo podías seleccionar, podías decir esto me lo vuelcas a un este cubemap vacio en tiempo real, o esto me lo renderizas a un bitmap y ya. Saludos.