#1:
Lo que más me llamo la atención cuando empece a programar videojuegos es que los juegos funcionan mayormente a base de trucos. Recuerdo de buscar como hacer cosas y me parecían algunas cosas cómicas ¿como se va a hacer esto así? tiene que haber algún método PRO o de hacer las cosas bien... pero no
Lo bueno es que una vez que aprendes que la cosa es hacer que funcione algo el como es indiferente, las cosas van sobre ruedas, y si le tienes que poner un sombrero tipo tren a un NPC/humanoide para usarlo de tren y ahorrarte trabajo de hacer un tren, su IA, ,etc hazlo.
¿sabias que los personajes no se mueven con las teclas? realmente lo que haces es mover el mundo
#27:
#1 Mmmm... me dedico profesionalmente a la programación de videojuegos. Eso que dices de que "el cómo funcionan las cosas es indiferente" es el camino directo a que tu proyecto fracase.
En una fase temprana, se suelen intentar definir todas las características que debe abarcar la arquitectura del juego. Cuando más adelante, los diseñadores quieren que se implemente algo que no había sido contemplado desde el principio suelen aparecer el tipo de "ñapas" de las que habla el artículo.
Por cierto, en la mayoría de mis juegos se mueve el personaje, no el mundo.
#9:
El "truco" del hL2 no es un truco es algo que siempre se hace, un vídeo ocupa memoria, algo muy escaso en las consolas, reproducir lo que ve otra cámara, todo super limitado y controlado será siempre más barato...y más rápido de hacer, hoy en día hay juegos que lo hacen sin problema... a ver, si en el vídeo se tienen que ver 500 personajes y un escenario de la leche pues ya no, pero bueno, se pueden usar modelos de baja y la resolución de render de ese vídeo es muy baja...
Echo en falta el truco de la reflexión, hoy en día continua siendo cara, pero antes, para simular un espejo o un suelo brillante lo que hacíamos era copiar todo el escenario e invertirlo, en algunos casos incluso había dos personajes uno normal y otro invertido... era más barato que calcular reflejos en tiempo real y sobre todo daba más calidad...
Otro truco, que bueno no lo es tanto, y supongo que todo el mundo se da cuenta, es, en los tiempos de carga de niveles, en algunos juegos entras en una habitación cerrada, no puedes salir ni avanzar, para avanzar tienes que hacer algo, normalmente algo que puede llevar mucho tiempo o nada, por ejemplo un "jaqueo automático" de un ordenador dando solo a un botón, o forzar una cerradura, o esperar a que llegue un compañero (IA)el tiempo que tarda el personaje en "jaquear" nunca es el mismo, depende del tiempo de descarga del nivel y el tiempo que tarde en cargar el próximo ntivel.
Después otras pijadas como, en una explosión, vemos un montón de trozos volando, cientos, y estos rebotan contra otros objetos, en realidad, de 100 trozos solo rebotan 10 ó 5 esos 10 son un poco más grandes un poco más brillantes en definitiva más cantosos que el resto para que te fijes más en esos y no en los otros que lo atraviesan todo...las colisiones son muy caras...
Saludos.
#29:
En el Age of Empires II, en la campaña de William Wallace había una misión en la que el bando de Wallace (amarillo) te entregaba todas sus tropas, que se convertían a tu bando (azul) y podían ser manejadas por el jugador.
Para que no saliera el mensaje "El bando de Wallace ha sido derrotado", ya que se quedaba sin tropas y se ve que era un mensaje automático del motor de partidas del juego, dejaron un soldado del bando de Wallace en mitad de un frondoso bosque en una esquina del mapa. Puedes llegar a él y matarlo si desarrollas los onagros para que puedan arrasar árboles.
#16:
O el Duke Nukem, donde los espejos en realidad son cristales transparentes por los que miras a habitaciones invertidas donde se genera un clon de tu personaje que se mueve como tú. Esto ocasionaba el problema de que allá donde hubiera un espejo, luego había un espacio sospechosamente amplio sin entradas, porque si no podrías entrar en la habitación invertida.
#11:
Se comió la mejor. La inversa rápida de la raíz cuadrada. Pedazo truco.
#116:
#95 Pues depende de cuales sean tu background y nivel actual de programación.
Lo primero que necesitas es una muy buena base de programación orientada a objetos.
También te vendrá bien repasar las matemáticas y física del instituto: tratamiento de ángulos, operaciones vectoriales, matrices y trigonometría general.
Por lo demás, aunque los títulos ayudan (ingeniería informática, másters especializados, etc.), para acceder a puestos de trabajo en este sector lo que realmente se valora es la experiencia en proyectos completos y publicados, independientemente de su envergadura.
Entonces, de una forma u otra, tu objetivo debería ser aprender los fundamentos de la programación de videojuegos mientras completas algunos proyectos que más tarde te permitan acceder a la industria.
Por último, probablemente sea una buena práctica empezar con algún motor de 'bajo nivel' (Cocos2D, Ogre3D), ya que te ayudarán a comprender mejor el funcionamiento de cualquier engine, y más tarde dar el salto a Unity, Unreal, etc. En mi caso concreto, lo primero que hice fue crear un sencillo motor 2D utilizando OpenGL y C++, y programé algunas pequeñas demos con él.
La verdad es que el tema da para escribir bastante, así que si tienes alguna duda concreta o quieres profundizar en el tema, mándame un mensaje privado y ya vemos como lo hacemos.
#6:
#5 No hace mucho se estrelló un avión en España cargado de pasajeros en el que habían empleado un truco en un sensor de temperatura con una bolsa de hielo. Es imposible trabajar con una alarma zumbando todo el rato, y si no, que se lo digan a Homer Simpson.
#21:
#14 Es un poco absurdo el debate que estais teniendo. Para generar cada frame hay que poner el mundo delante de la camara, lo que implica mover/rotar/scalar el mundo o un subconjunto del mundo, es decir aplicar una transformacion que todo el mundo habra estudiado alguna vez en algebra lineal/matrices de bachillerato, eso tan aburrido de las propiedades de las matrices y de cambiar de base, al final resulta que si tenia alguna utilidad.
Otras cosas que se comentan yo no las llamaria trucos, porque es solo la forma mas obvia o simplemente no hay otra forma de hacerlo.
Es como si alguien sale diciendo: Ves ese dinosaurio grande y ese pequeño ? Te voy a contar un "truco" en "realidad" son el mismo dinosaurio puesto en dos sitios y a escalas diferentes.
#79:
#74#75 Me dedico a la programación y aunque no tengo la más remota idea de desarrollo de videojuegos tu ejemplo es absurdo, no se trata de sacarse nada de la manga, se tratará simplemente de reutilizar código, si solo necesito dos ropas, voy a crear dos modelos de jugador, si tiene que ser altamente personalizable, bajaré al nivel de un modelo por cada parte del jugador... llamar a eso "truco" está muy lejos de un overflow en un eula o de meter como cabeza del jugador un tren por no poder desacoplar la cámara.
Y si decir que estas ñapas son la mayoría de los casos en el desarrollo de videojuegos te parece lógico...
En fin, de vuestra conversación parece evidente para cualquiera que sepa lo mínimo del mundo de la programación quien es aquí el programador de videojuegos y quien es simplemente un gamer haciéndose notar. Lo siento, pero tenía que decirlo.
#34:
#32 En el estudio en el que trabajo, como en la mayoría de pequeños y medianos estudios españoles, estamos usando Unity3D, aunque otros prefieren Unreal.
Para juegos en 2D todavía se usa bastante Cocos2D, y algunos de los estudios más grandes del país desarrollaron motores propios, como por ejemplo Digital Legends, que utiliza Karisma.
#45:
Yo utilicé un truco para crear enemigos en un juego de naves en la plataforma antigua de MS-DOS Div Games.
El truco era que para no crear los movimientos mediante programación creé un programilla que regsitraba los movimientos del ratón, y los metía en un array.
Con un botón bloqueaba un eje, así que por ejemplo solo lo movía horizontalmente, si liberaba ese botón y pulsaba el otro se movía verticalmente, y si los dejaba sin pulsar ambos botones, era el movimiento libre.
Luego si pulsaba la barra espaciadora tres veces, se creaba un array dinámicamente y era el movimiento de otra nave.
Total que hice los movimientos de un montón de naves en apenas una tarde. Luego solo era asignarle el gráfico, el sonido al explotar, y listo.
Ahorré tardes y tardes de trabajo.
#65:
#62 No niego en absoluto que se utilicen trucos como los del artículo. Pero su uso, en el 99.9% de los casos, es consecuencía de presiones externas al desarrollo (deadlines, cambios solicitados por el publisher...) o de una pésima planificación del proyecto.
Por la forma en la que te has expresado en tu primer comentario, dabas a entender a los ajenos al mundillo que desarrollar un videojuego consistía exclusivamente en la utilzación de estas triquiñuelas, y eso no es así. La mayor parte de lo que el jugador ve ocurre como parece que ocurre.
#61:
#c-58" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/58">#58 Soy programador de Gameplay/IA. Aunque ahora trabaje con Unity mi background es de C++, y aunque pasar a C# no supuso ningún trauma, por desgracia se me sigue dando mejor picar código que apañarme con herramientas gráficas.
En los estudios pequeños, el trabajo tiene que salir con la gente que se tiene, pero he tenido la suerte de trabajar con diseñadores de niveles en uno de mis proyectos, y no me parece un trabajo para nada despreciable.
Lo que más me llamo la atención cuando empece a programar videojuegos es que los juegos funcionan mayormente a base de trucos. Recuerdo de buscar como hacer cosas y me parecían algunas cosas cómicas ¿como se va a hacer esto así? tiene que haber algún método PRO o de hacer las cosas bien... pero no
Lo bueno es que una vez que aprendes que la cosa es hacer que funcione algo el como es indiferente, las cosas van sobre ruedas, y si le tienes que poner un sombrero tipo tren a un NPC/humanoide para usarlo de tren y ahorrarte trabajo de hacer un tren, su IA, ,etc hazlo.
¿sabias que los personajes no se mueven con las teclas? realmente lo que haces es mover el mundo
No soy programador pero entiendo lo suficiente como para apreciar el ingenio para subsanar errores humanos inherentes a la creación de un juego. El segundo es brillante.
#8#4#7 En los juegos 2d basados en sprites el sprite se mueve por la pantalla, pero es cierto que sin el scroll, el sprite chocaria con los bordes de la misma(si lo has delimitado) o se saldria de los limites, por lo que el personaje(sprites) se mueve pero tambien el mundo
#55 Pero también estás moviendo el personaje que controlas, en cuanto que cambias la posición en la que se dibuja. Entiendo que lo que dices de mover principalmente el mundo es sobre todo en juegos 3D en primera persona o incluso en tercera persona con cámara centrada en el personaje (también algunos juegos 2D, como algunos de naves que he mencionado antes), pero en el FIFA eso no aplicaría de la misma forma.
#1#3#25 Yo hice el típico de naves (2d, evidentemente) donde se movía tanto la nave como el mundo. Claro que la nave iba más rápida que el mundo por lo que acababa saliéndose por la pantalla (y apareciendo por debajo otra vez) cual misil loco. Lo bueno es que esta estrategia servía para despistar a los aliens, que observaban estupefactos cual calamares ensiestados lo que hacía la extravagante nave.
#7 Actualmente mueves la cámara que se coloca en el jugador, en algunas escena s cinemá ticas a tiempo real puedes cambiar la cámara al techo para mostrar una acción "no jugable". Mover el mundo se dejó en el 95, salvo que quieras replicar un retrogame.
#3 Por lo general lo que mueves es la cámara que no hace sino mover el mundo o rotarlo, según lo que se quiera hacer. Los que si se mueven a través del él son los otros personajes o bots.
#14 Es un poco absurdo el debate que estais teniendo. Para generar cada frame hay que poner el mundo delante de la camara, lo que implica mover/rotar/scalar el mundo o un subconjunto del mundo, es decir aplicar una transformacion que todo el mundo habra estudiado alguna vez en algebra lineal/matrices de bachillerato, eso tan aburrido de las propiedades de las matrices y de cambiar de base, al final resulta que si tenia alguna utilidad.
Otras cosas que se comentan yo no las llamaria trucos, porque es solo la forma mas obvia o simplemente no hay otra forma de hacerlo.
Es como si alguien sale diciendo: Ves ese dinosaurio grande y ese pequeño ? Te voy a contar un "truco" en "realidad" son el mismo dinosaurio puesto en dos sitios y a escalas diferentes.
#36 Pero eso es simplemente un cambio del marco de referencia, no significa que se trabaje "moviendo" el mundo en lugar del personaje a la hora de programar la logica del juego.
Es como decir que cuando camino, no soy yo el que me muevo, sino que yo estoy quieto y es el universo el que se mueve alrededor mía. Es cierto si me tomas a mi como marco de referencia, pero en la vida diaria nunca hacemos eso, porque es complicar las cosas innecesariamente. El marco de referencia que usamos es un punto fijo del mundo.
Igualmente, a la hora de programar cámaras y personajes, se usa como marco de referencia el mundo, y no la propia cámara. Cuando el personaje avanza por el eje X, el programador simplemente incrementa la coordenada .x del objeto que le representa, y nunca "mueve" el mundo en -x.
#14 Lo que tienes es un árbol de objetos donde la cámara suele estar arriba del todo ( o ser el primer nodo, o simplemente su movimiento afecta al primer nodo que suele ser el terreno), por lo que cualquier movimiento en esta, afecta a todo el árbol de objetos.
#1 Mmmm... me dedico profesionalmente a la programación de videojuegos. Eso que dices de que "el cómo funcionan las cosas es indiferente" es el camino directo a que tu proyecto fracase.
En una fase temprana, se suelen intentar definir todas las características que debe abarcar la arquitectura del juego. Cuando más adelante, los diseñadores quieren que se implemente algo que no había sido contemplado desde el principio suelen aparecer el tipo de "ñapas" de las que habla el artículo.
Por cierto, en la mayoría de mis juegos se mueve el personaje, no el mundo.
#32 En el estudio en el que trabajo, como en la mayoría de pequeños y medianos estudios españoles, estamos usando Unity3D, aunque otros prefieren Unreal.
Para juegos en 2D todavía se usa bastante Cocos2D, y algunos de los estudios más grandes del país desarrollaron motores propios, como por ejemplo Digital Legends, que utiliza Karisma.
#34 Me encanta programar y quiero meterme en el mundo de los juegos para android. Alguna recomendación? Con que empezarías? Quisiera empezar con juegos 2D.
#95 Pues depende de cuales sean tu background y nivel actual de programación.
Lo primero que necesitas es una muy buena base de programación orientada a objetos.
También te vendrá bien repasar las matemáticas y física del instituto: tratamiento de ángulos, operaciones vectoriales, matrices y trigonometría general.
Por lo demás, aunque los títulos ayudan (ingeniería informática, másters especializados, etc.), para acceder a puestos de trabajo en este sector lo que realmente se valora es la experiencia en proyectos completos y publicados, independientemente de su envergadura.
Entonces, de una forma u otra, tu objetivo debería ser aprender los fundamentos de la programación de videojuegos mientras completas algunos proyectos que más tarde te permitan acceder a la industria.
Por último, probablemente sea una buena práctica empezar con algún motor de 'bajo nivel' (Cocos2D, Ogre3D), ya que te ayudarán a comprender mejor el funcionamiento de cualquier engine, y más tarde dar el salto a Unity, Unreal, etc. En mi caso concreto, lo primero que hice fue crear un sencillo motor 2D utilizando OpenGL y C++, y programé algunas pequeñas demos con él.
La verdad es que el tema da para escribir bastante, así que si tienes alguna duda concreta o quieres profundizar en el tema, mándame un mensaje privado y ya vemos como lo hacemos.
#27 Eso es sentido común en todo. Las ñapas mientras menos y más tarde mejor, y si se pueden arreglar se arreglan. Estas anécdotas son muy graciosas, pero en realidad muestran fracasos en el desarrollo del software.
#42 No hace falta que me explique nada. No son ñapas son formas (bueno en articulo hay alguna ñapa), y e visto muchas con trucos, y como dije si algo hay en la industria del juego son trucos. Ahora puedes decir mierda "por que trabajas profesionalmente" que me la suda.
Te podría contar 1001 trucos que se utilizan comúnmente para hacer videojuegos o para hacer que funcione algo, o ciertas mecánicas, pero bueno como eres "profesional" esta por encima de ti esto.
#44 Perdona que insista, pero tener que cambiar la geometría de la cabeza del personaje por la de un tren indica un problema en la arquitectura: que no te permite desacoplar el componente cámara del resto del personaje. Y que no te siente mal lo de "profesionalmente", no soy yo el primero que ha venido a este hilo a tirarse el pisto
#c-58" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2452888/order/58">#58 Soy programador de Gameplay/IA. Aunque ahora trabaje con Unity mi background es de C++, y aunque pasar a C# no supuso ningún trauma, por desgracia se me sigue dando mejor picar código que apañarme con herramientas gráficas.
En los estudios pequeños, el trabajo tiene que salir con la gente que se tiene, pero he tenido la suerte de trabajar con diseñadores de niveles en uno de mis proyectos, y no me parece un trabajo para nada despreciable.
#61 Me cuesta creerte que te dedicas al gameplay y que por otro estés negando que se utilicen trucos "diariamente" en todos los juegos para hacer funcionar ciertas cosas. Pero bueno que no voy a seguir discutiendo...
El diseñador de niveles es pieza clave no los desprecio, todos los son, desde el concept art hasta el animador pasando por todos, cada cual tiene su tarea y es determinante, muchos juegos han triunfado mayormente por el diseño de sus niveles, sobretodo los shooters online, simplemente digo que no es programador de videojuegos, es diseñador de niveles, como el animador es animador no programador. Y no con animo de despreciar su trabajo.
#62 No niego en absoluto que se utilicen trucos como los del artículo. Pero su uso, en el 99.9% de los casos, es consecuencía de presiones externas al desarrollo (deadlines, cambios solicitados por el publisher...) o de una pésima planificación del proyecto.
Por la forma en la que te has expresado en tu primer comentario, dabas a entender a los ajenos al mundillo que desarrollar un videojuego consistía exclusivamente en la utilzación de estas triquiñuelas, y eso no es así. La mayor parte de lo que el jugador ve ocurre como parece que ocurre.
#65 Digo que seguramente todos juego hace uso de ellos y posiblemente más de una vez. Y no siempre es por presiones o mal planificación si no por que es la forma más fácil de hacerlo o por ahorrar tiempo, en vez de implementar algo que a lo mejor llevaría semanas y seria absurdo se puede hacer dando el pego de alguna forma ingeniosa utilizando algo hecho. Simple y llanamente eso.
Y esto que cuenta el articulo no es nuevo es de siempre, si buscas un poco encontraras mil ejemplos de dev tricks de estos en todos los juegos.
#71 Ésto ya es una cosa. Una cosa es decir que en función de las necesidades del proyecto, puede llegar a moverse el entorno dejando fijo al personaje, y otra muy diferente escribir que eso se hace siempre así.
#74#75 Me dedico a la programación y aunque no tengo la más remota idea de desarrollo de videojuegos tu ejemplo es absurdo, no se trata de sacarse nada de la manga, se tratará simplemente de reutilizar código, si solo necesito dos ropas, voy a crear dos modelos de jugador, si tiene que ser altamente personalizable, bajaré al nivel de un modelo por cada parte del jugador... llamar a eso "truco" está muy lejos de un overflow en un eula o de meter como cabeza del jugador un tren por no poder desacoplar la cámara.
Y si decir que estas ñapas son la mayoría de los casos en el desarrollo de videojuegos te parece lógico...
En fin, de vuestra conversación parece evidente para cualquiera que sepa lo mínimo del mundo de la programación quien es aquí el programador de videojuegos y quien es simplemente un gamer haciéndose notar. Lo siento, pero tenía que decirlo.
#79 Aparte de que veo que te cuesta escribir por que la mitad no te lo entiendo, veo que tampoco sabes leer por que dije que no es truco/ñapa, es la forma de hacerlo, pero que realmente estas haciendo lo que estas haciendo, intercambiando personajes, que se puede considerar un truco para simular el cambio de ropa.
#82 Sabes que más es un truco? No te lo vas a creer. Cuando un personaje conduce un coche, se programa el movimiento del coche, no se mueve los brazos del jugador cambiando las marchas y pisando el acelerador, ni se programa un coche que puedan conducir los personajes. Que fuerte verdad?
#85 Depende, de alguien que implemento leap motion en un par de proyectos te puedo asegurar hasta que hice una que una pistola funciona apretando un gatillo y que podría hacer si es necesario un cambio de marchas funcional en el que el coche cambiara de marcha o moviera el volante interactuando con ellos. Sin utilizar ningún truco de esos para simular el cambio de marchas.
Y sin leap motion se podría hacer también, pero lo más cómodo/fácil y dado que no hay necesidad en un caso normal es utiliza el truco del personaje animado cambiando de marchas y que realmente no es su mano lo que cambia de marchas.
#86 Mi punto era añadir obviedades a las tuyas, que no son ningún workaround a diferencia de lo del artículo. Te lo explico porque veo que no llegas, pero tranquilo que aquí no engañas a nadie.
#61 Por cierto hasta por ejemplo el hecho de cambiar un personaje de ropa, eso no se considera un truco hoy en día, es una forma de hacerlo, pero realmente ¿no lo es? realmente no cambias la ropa del personaje lo que cambias es el personaje.
Luego en su momento no se quien se saco de la manga lo de los personajes modulares, para no hacer mil personajes con diferentes ropas los troceamos y los unimos al gusto depende la ropa que quieres llevar, ya sabes GTA, skyrim.
A eso también me refería con que los juegos son todo trucos y el arte del engaño, donde el gamer cree que el personaje cambia de ropa pero realmente lo que haces es cambiar el personaje.
#27Eso que dices de que "el cómo funcionan las cosas es indiferente" es el camino directo a que tu proyecto fracase.
No pudes oirlo pero estoy aplaudiendo en casa.
En serio, se lo he dicho a la gente mil veces en temas de creación de vídeo y nunca me hacen caso y al final consiguen que todo parezca un batiburrillo de efectos mal hechos, planos improvisados y frases encajadas a lo loco.
#27 lo que #1 creo que se refiere, es que muchas soluciones, al igual que en las películas consiste en engañar al espectador/jugador; no a errores de diseño, quicir, ahora hay mucha más potencia, pero cuando había mucha menos: spectrum, etc... las soluciones eran más 'ingeniosas'.
El del Half-Life 2 del artículo es una de ellas, otras que se indican no.
#47 Se sigue haciendo. En algunos juegos el personaje se mantiene siempre en el centro de la pantalla. En ese caso puede desplazarse el resto del "mundo" manteniendo estáticos la cámara y el personaje. Pero donde realmente se sigue haciendo bastante es en los juegos de gestión en perspectiva isométrica, en los que el jugador simplemente se desplaza por un entorno. En este último caso, si dejamos la cámara fija y desplazamos el entorno, el jugador seguira percibiendo que lo que hace es desplazar la cámara.
#1 Son hacks inteligentes, desde luego. No trabajo en ese sector, pero allá por los tiempos del RPGMaker, para simular el uso de vehículos cambiaba el sprite del personaje por uno de un tren, coche o barco; aunque el que se movía era realmente el personaje.
Me encanta el truco del personaje que habla desde otro lado de la pantalla para simular el vídeo...
#90 Exacto, si te vale ¿para que complicarse? hoy en día lo de los coches en algo 3d requiere más trabajo, físicas y un largo etc, pero si es una escena determinada y te vale por que no vas a hacerlo? cambias el modelo, deshabilitas el salto y a tomar por saco. Otra cosa que se base en vehiculos y necesites todo, como en un GTA.
Por eso no coincido con muchos comentarios que hablan de ñapas o soluciones cutres a problemas, simplemente me parece que si te vale y más fácil no te compliques implementando mil cosas nuevas.
A mi lo del espejos del Duke nuken que mencionaba otro meneante, no lo conocía, y de alguien que vio muy por encima como hacer un espejo y vio que le sobrepasaba y paso de espejos... (había que calcular fov depende de la distancia, perspectiva y en definitiva un coñazo que no sabría ni como empezar, además de tragar consumo) es un arreglo curioso.
#91 Como mencionaron posteriormente, para sectores no críticos, como el de entretenimiento, productos en fase de pruebas y similares; esto se puede tolerar. En todos estos casos no se pone en peligro la vida, los datos o la economía de alguien; aunque igualmente hay que ser un poco crítico y solidario y buscar un equilibrio entre calidad, sostenibilidad (que ya sabemos que el código luego se reaprovecha casi siempre, y si se pensó mal y se parchea en cada iteración es un horror para el que viene detrás) y los límites de tiempo que haya. En algunos casos son las limitaciones de hardware las que obligan a jugar creativamente con los recursos; y no hay nada de malo en meter alguna "ñapa", siempre y cuando se respeten los requisitos básicos del producto.
#1 Y yo me sentía sucio cuando hacia mis juegos. Al acabarlos pensaba justamente lo que dices, debía existir alguna forma de hacer un código limpio, que no las chapuzas para que el juego funcionara.
#96 No te entiendo bien lo que quieres decir. Online es lo mismo, si otro jugador esta en las coordenadas al alcance de la vista lo renderizas en la camara si no no. Si el jugador se mueve 1 metro a tu derecha de un frame a otro (Exagerando), lo que haces en cambiar la posición de renderizado del jugador a tu derecha 1 metro.
#1 El mundo no se mueve, o expresado de una manera más técnica, a no ser que sea una especificación ultra marciana del diseño las coordenadas del origen del mundo no sufren transformaciones. Se mueven los objetos y se mueve la cámara, pero no se mueve el mundo.
El "truco" del hL2 no es un truco es algo que siempre se hace, un vídeo ocupa memoria, algo muy escaso en las consolas, reproducir lo que ve otra cámara, todo super limitado y controlado será siempre más barato...y más rápido de hacer, hoy en día hay juegos que lo hacen sin problema... a ver, si en el vídeo se tienen que ver 500 personajes y un escenario de la leche pues ya no, pero bueno, se pueden usar modelos de baja y la resolución de render de ese vídeo es muy baja...
Echo en falta el truco de la reflexión, hoy en día continua siendo cara, pero antes, para simular un espejo o un suelo brillante lo que hacíamos era copiar todo el escenario e invertirlo, en algunos casos incluso había dos personajes uno normal y otro invertido... era más barato que calcular reflejos en tiempo real y sobre todo daba más calidad...
Otro truco, que bueno no lo es tanto, y supongo que todo el mundo se da cuenta, es, en los tiempos de carga de niveles, en algunos juegos entras en una habitación cerrada, no puedes salir ni avanzar, para avanzar tienes que hacer algo, normalmente algo que puede llevar mucho tiempo o nada, por ejemplo un "jaqueo automático" de un ordenador dando solo a un botón, o forzar una cerradura, o esperar a que llegue un compañero (IA)el tiempo que tarda el personaje en "jaquear" nunca es el mismo, depende del tiempo de descarga del nivel y el tiempo que tarde en cargar el próximo ntivel.
Después otras pijadas como, en una explosión, vemos un montón de trozos volando, cientos, y estos rebotan contra otros objetos, en realidad, de 100 trozos solo rebotan 10 ó 5 esos 10 son un poco más grandes un poco más brillantes en definitiva más cantosos que el resto para que te fijes más en esos y no en los otros que lo atraviesan todo...las colisiones son muy caras...
Saludos.
#9 para los espejos siempre se ha utilizado una camara que renderiza sobre un textura.
Y por cierto hablando sobre espejos me acuerdo de deus ex HR, en el que no podian permitirse espejos por limitaciones del motor (comentarios del director) y su solucion fue hacer que todos los espejos que aparecen en el juego estuviesen rotos
#88 Eso es ahora, en superficies muy pequeñas y que no sean un espejo pulido, aún así da muchos problemas, principalmente de sincronismo y calidad, el render to texture no va a la misma velocidad y si lo pones a la misma velocidad por ejemplo 30FPS es caro de narices, después, imagina una superficie como un lago, para que un render to texture cubra toda la superficie tendría que tener una resolución enorme, imagina un render de 512*512 renderizandose 30 veces por segundo en una superficie que ocupa 3 km cuadrados, como un lago, qué calidad tendría eso, pues a un textel cada metro, y el coste es insufrible...hay sistemas que automatizan todo eso, pero no deja de ser un truco y se suele notar.
Si se quiere dar un toque de reflejo, en una superficie pulida se usan cube maps precalculados de la escena,o varios cubes calculados en ciertas zonas de la escena, hay motores que tienen un cube global o que ellos solos se encargan de calcular uno para cada "zona"pero es un solo render de 1024*1024, modificando su mapeado para que coincida con la cámara, de forma simple sería, producto escalar entre el vector de cámara y el vector de reflexión, y transformando de local a mundo y normalizando (te lo digo de cabeza seguro que falta algo)...
Por otro lado, en casos como el agua, la cosa se complica ya que esta suele ser translucida, el cálculo de la translucencia es muy caro..si a eso le añadimos el calculo de una textura enorme 30 veces por segundo se nos muere,y si es dinámica ni te cuento...
Lo que se suele hacer en estos casos es hacer todo esto a lo bruto, pasando del motor y programando directamente en la gráfica, en mi ultimo proyecto el agua se hizo así.
Lo de los espejos rotos es una idea muy buena...XDD
Saludos.
#88 Realmente un espejo es bastante más complejo, la cámara si es fija te da una imagen fija, no cambia dependiendo de tu perspectiva, si quieres hacer un espejo tienes que dinamicamente rotar la cámara dependiendo del punto de vista, cambiar el fov estés más cerca o más lejos, etc.
Aparte pruebas ese método de hacerlo en algunos engines populares y traga bastante.
O sea salvo que hagas todo eso realmente no tienes un espejo. Si no una un televisor que emite tu imagen y lo que hay delante de la cámara en directo.
#9 A mi me ha sorprendido que en HL2, toda la parte del video que supuestamente se debería renderizar en un FrameBuffer para luego pasarlo a una textura y pegarla en la TV, se esté renderizando en el mismo contexto de la imagen final del juego.
A mi me huele a limitación del motor (aunque me parece raro que no permita render to texture) que solucionaron reutilizando algún efecto creado para hacer efectos de CCTV en tiempo real.
En el Age of Empires II, en la campaña de William Wallace había una misión en la que el bando de Wallace (amarillo) te entregaba todas sus tropas, que se convertían a tu bando (azul) y podían ser manejadas por el jugador.
Para que no saliera el mensaje "El bando de Wallace ha sido derrotado", ya que se quedaba sin tropas y se ve que era un mensaje automático del motor de partidas del juego, dejaron un soldado del bando de Wallace en mitad de un frondoso bosque en una esquina del mapa. Puedes llegar a él y matarlo si desarrollas los onagros para que puedan arrasar árboles.
Del propio artículo compartido por el usuario anterior:
"The algorithm was originally attributed to John Carmack, but an investigation showed that the code had deeper roots in both the hardware and software side of computer graphics. Adjustments and alterations passed through both Silicon Graphics and 3dfx Interactive, with Gary Tarolli's implementation for the SGI Indigo as the earliest known use. It is not known how the constant was originally derived, though investigation has shed some light on possible methods."
O el Duke Nukem, donde los espejos en realidad son cristales transparentes por los que miras a habitaciones invertidas donde se genera un clon de tu personaje que se mueve como tú. Esto ocasionaba el problema de que allá donde hubiera un espejo, luego había un espacio sospechosamente amplio sin entradas, porque si no podrías entrar en la habitación invertida.
#10 El precio de 128KB de RAM en 1977 era aún prohibitivo. No sé si ha sido una errata al escribir o si realmente pensabas que tenía 128KB de RAM. Si es lo segundo y ya estabas flipando, cuando te enteres de que sólo tenía 128 bytes te va a dar algo
Yo utilicé un truco para crear enemigos en un juego de naves en la plataforma antigua de MS-DOS Div Games.
El truco era que para no crear los movimientos mediante programación creé un programilla que regsitraba los movimientos del ratón, y los metía en un array.
Con un botón bloqueaba un eje, así que por ejemplo solo lo movía horizontalmente, si liberaba ese botón y pulsaba el otro se movía verticalmente, y si los dejaba sin pulsar ambos botones, era el movimiento libre.
Luego si pulsaba la barra espaciadora tres veces, se creaba un array dinámicamente y era el movimiento de otra nave.
Total que hice los movimientos de un montón de naves en apenas una tarde. Luego solo era asignarle el gráfico, el sonido al explotar, y listo.
Me extraña que no salga el "Strafe Jump" del quake 3, que empezó siendo un bug y terminó como una de las mayores señas de identidad de la saga: https://en.wikipedia.org/wiki/Strafe-jumping
(Pulsando las teclas de dirección durante un salto, la velocidad de el jugador aumenta. Si se encadenan strafe jumps sucesivos se pueden alcanzar velocidades estratosfericas.)
¿La solución? Aprovechar los términos de uso, o EULA, que eran descargados cada vez que el juego se conectaba a Internet; al final de esta muralla de texto que nadie lee, se incluyó una cadena tan larga que provocaba un desbordamiento de buffer, lo que permitió ejecutar código en memoria, que descargaba e instalaba el parche.
Estoy en contra de los trucos chapuceros en el software, excepto en este caso concreto del desarrollo de videojuegos, al fin y al cabo solo es entretenimiento, si la ñapa deja de funcionar en el futuro, pues se saca un parche y tirando. Pero cuando se desarrolla software que será explotado en un entorno empresarial, no es permisible todo este tipo de trucos que al final acaban creando deuda técnica ( https://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica ), y hacen que el sofware sea frágil y sea mas difícil de mantener y modificar en el futuro.
Me consta que en muchos bancos, el software funciona a golpe de parches y chapucillas que hacen que todo mas o menos funciones al día, pero internamente está todo cogido con alfileres.
Te sorprenderías amigo mío... en informática, sobretodo cuando la aplicación viene de una cárnica, es el pan de cada día. Y mas que trucos diría autenticas chapuzas con miles de parches por encima para que todo acabe funcionando con pinzas.
Y en otras areas de la ingenería, según mi experiencia, aunque no tan exagerado como en informática también puedes encontrarte muchos "trucos".
En cuanto trabajas en un proyecto grande que aglomera distintas tecnologías, tienes que valerte de mil trucos para que se comuniquen unas partes con otras, y más con tareas asíncronas, que son a donde la informática ha evolucionado.
Recuerdo una vez que desde la aplicación cliente se pedía un informe al servidor. Ese informe tardaba varios minutos en generarse, por lo que no era factible quedarse esperando a que acabara. Había que pedirlo, y seguir en la aplicación cliente haciendo otras cosas. A su vez, el servidor no podía acaparar el thread principal con esa tarea, por lo que había que crear un hilo adicional que tratase esa tarea.
La forma de saber si había acabado, era llamando cada 10 segundos al servidor para preguntarle, a través de una función que lo que hacía era mirar un fichero de log donde el proceso que generaba el informe iba indicando su progreso.
El truco era ese: para sincronizar dos procesos, usábamos un fichero de texto donde uno escribía y otro leía.
#26 A mi me tocó modernizar una aplicación que hacía algo parecido a eso.
Estaba en Visual Basic (padre de grandes horrores) y para sincronizar 2 procesos ambos escribían y leían de un cuadro de texto en un formulario oculto donde iban leyendo y escribiendo parámetros.
#26 Hum... estoy un poco oxidado con la programación, pero eso que dices no creo que se pueda considerar un truco. Será más o menos chapucero hacerlo con un archivo de texto, pero utilizar un recurso común bloqueable para sincronizar dos procesos creo que es una práctica estándar en programación concurrente.
Yo espero que no hayan trucos así en una central nuclear o un avión de última tecnología.
Alguien: "Oye, tío el control de temperatura del reactor peta con error de falta de memoria, ¿que hacemos?"
Otro: "ah.... desinstala el antivirus y pon un post-it que no ejecuten muchas aplicaciones allí"...
tiempo después...
Auditor: "Por seguridad, se debe instalar esta megasuperchachi Suite de seguridad pro ultra max con todo este montón de módulos útiles"
instantes después
CNN: "Hoy abrimos con una terrible noticia... o depende si tiene la extraña esperanza de convertirse en un superhéroe radioactivo"
#5 No hace mucho se estrelló un avión en España cargado de pasajeros en el que habían empleado un truco en un sensor de temperatura con una bolsa de hielo. Es imposible trabajar con una alarma zumbando todo el rato, y si no, que se lo digan a Homer Simpson.
#5 No quiero que te conviertas en un paranoico, pero en programas como megaconstrucciones, y otros dedicados a máquinas a veces si se desvelan "chapuzas" problemas que hay que apañar por algo que no estaba planeado.
En el fondo aunque no se "noten", no hay tanta diferencia de hacer los apaños que se ven en internet, por ejemplo arreglar algo con una percha que hacerlo con una pieza NS543, sea lo que sea que signifique eso.
Una que recuerdo era un avión, su estructura no estaba pensada para ser taladrada, pero al final lo hicieron y no pasó nada... todavía.
En lo del Fallout me imagino que habrían un par de discusiones entre el que tuvo la idea del recorrido en tren y los programadores ¿Pero no se puede solucionar con enseñar que entras al tren, fundido en negro, y mostrar que sales en el punto de llegada? No me jodas...xd
En Skyrim el contenido del inventario de los negocios está contenido en un cofre escondido por debajo del nivel del suelo. Ahora, si realmente quieren ver trucos ingenioso deben de darle unas mirada a los mods, hay algunos que han logrado hacer cosas increíbles a base de "trucos"
#40 Mi primer inventario para un juego cuando cogías un objeto realmente lo teletransportaba a un socket en el cuerpo y lo hacia invisible y anulaba la física, cuando lo sacabas lo teletransportabas a la mano y lo hacías visible, podías ponerlo en el mapa donde quisieras claro pero yo se lo enchufaba al personaje.
Por no decir del Doom, que es un juego en 2D en el que las aristas del mapa 2D se proyectan verticalmente y es espacio resultante entre aristas se pinta del color que sea.
En el dia a dia todos usamos "trucos" para q funcione nuestro monton de codigo . Y no digo na de la peña q este usando frameworks o apis con nula documentacion.
Una cosa es que sea un truco, pero es una chapuza. El de Fallout 3 pega un cantazo, porque el movimiento es antinatural. Es decir, así no se mueve un tren, sólo hace falta ver el movimiento al hacer una curva, no es un movimiento homogéneo.
Comentarios
Lo que más me llamo la atención cuando empece a programar videojuegos es que los juegos funcionan mayormente a base de trucos. Recuerdo de buscar como hacer cosas y me parecían algunas cosas cómicas ¿como se va a hacer esto así? tiene que haber algún método PRO o de hacer las cosas bien... pero no
Lo bueno es que una vez que aprendes que la cosa es hacer que funcione algo el como es indiferente, las cosas van sobre ruedas, y si le tienes que poner un sombrero tipo tren a un NPC/humanoide para usarlo de tren y ahorrarte trabajo de hacer un tren, su IA, ,etc hazlo.
¿sabias que los personajes no se mueven con las teclas? realmente lo que haces es mover el mundo
No soy programador pero entiendo lo suficiente como para apreciar el ingenio para subsanar errores humanos inherentes a la creación de un juego. El segundo es brillante.
#1 ¡Spoiler!
#2 flipante
#1 No, depende del juego. También se mueve el personaje.
#3 Si, no me digas, cuéntame más.
#4 Quiero decir, que muchas veces en el mismo tipo de juego puedes elegir entre hacer mover el personaje o el mundo.
#7 entiendo por lo q dice q es la camara q se mueve
#8 #4 #7 En los juegos 2d basados en sprites el sprite se mueve por la pantalla, pero es cierto que sin el scroll, el sprite chocaria con los bordes de la misma(si lo has delimitado) o se saldria de los limites, por lo que el personaje(sprites) se mueve pero tambien el mundo
#25 Me refería a los juegos 3D.
#35 Aunque muchos con 2d/scroll es lo mismo mueves el mundo.
#35 ¿En el FIFA no mueves los personajes?
#51 Básicamente estas dibujando y moviendo el mundo y sus objetos delante de la camara. Esa así como funciona DirectX,
#55 Pero también estás moviendo el personaje que controlas, en cuanto que cambias la posición en la que se dibuja. Entiendo que lo que dices de mover principalmente el mundo es sobre todo en juegos 3D en primera persona o incluso en tercera persona con cámara centrada en el personaje (también algunos juegos 2D, como algunos de naves que he mencionado antes), pero en el FIFA eso no aplicaría de la misma forma.
#25 Se mueve la pantalla muchas veces.
#1 #3 #25 Yo hice el típico de naves (2d, evidentemente) donde se movía tanto la nave como el mundo. Claro que la nave iba más rápida que el mundo por lo que acababa saliéndose por la pantalla (y apareciendo por debajo otra vez) cual misil loco. Lo bueno es que esta estrategia servía para despistar a los aliens, que observaban estupefactos cual calamares ensiestados lo que hacía la extravagante nave.
#4 #7 sí, claro, en el Space Invaders no mueves las naves, mueves el mundo, lo que pasa que como es negro, no se nota, no te jode
#7 Actualmente mueves la cámara que se coloca en el jugador, en algunas escena s cinemá ticas a tiempo real puedes cambiar la cámara al techo para mostrar una acción "no jugable". Mover el mundo se dejó en el 95, salvo que quieras replicar un retrogame.
#3 Por lo general lo que mueves es la cámara que no hace sino mover el mundo o rotarlo, según lo que se quiera hacer. Los que si se mueven a través del él son los otros personajes o bots.
#1 En OpenGL prehistorico quizá, hoy en día se mueve la cámara, osea tú.
#14 Es un poco absurdo el debate que estais teniendo. Para generar cada frame hay que poner el mundo delante de la camara, lo que implica mover/rotar/scalar el mundo o un subconjunto del mundo, es decir aplicar una transformacion que todo el mundo habra estudiado alguna vez en algebra lineal/matrices de bachillerato, eso tan aburrido de las propiedades de las matrices y de cambiar de base, al final resulta que si tenia alguna utilidad.
Otras cosas que se comentan yo no las llamaria trucos, porque es solo la forma mas obvia o simplemente no hay otra forma de hacerlo.
Es como si alguien sale diciendo: Ves ese dinosaurio grande y ese pequeño ? Te voy a contar un "truco" en "realidad" son el mismo dinosaurio puesto en dos sitios y a escalas diferentes.
#21 Exacto, escalas y mueves el mundo
#36 Pero eso es simplemente un cambio del marco de referencia, no significa que se trabaje "moviendo" el mundo en lugar del personaje a la hora de programar la logica del juego.
Es como decir que cuando camino, no soy yo el que me muevo, sino que yo estoy quieto y es el universo el que se mueve alrededor mía. Es cierto si me tomas a mi como marco de referencia, pero en la vida diaria nunca hacemos eso, porque es complicar las cosas innecesariamente. El marco de referencia que usamos es un punto fijo del mundo.
Igualmente, a la hora de programar cámaras y personajes, se usa como marco de referencia el mundo, y no la propia cámara. Cuando el personaje avanza por el eje X, el programador simplemente incrementa la coordenada .x del objeto que le representa, y nunca "mueve" el mundo en -x.
#47 ya lo explicaron no me voy a repetir goto #21
Y si os interesa coger cualquier libro de programación con DirectX que os muestra/enseña todo eso.
#14 Lo que tienes es un árbol de objetos donde la cámara suele estar arriba del todo ( o ser el primer nodo, o simplemente su movimiento afecta al primer nodo que suele ser el terreno), por lo que cualquier movimiento en esta, afecta a todo el árbol de objetos.
#1 me da a mi que muchos no has hecho.
#1 Mmmm... me dedico profesionalmente a la programación de videojuegos. Eso que dices de que "el cómo funcionan las cosas es indiferente" es el camino directo a que tu proyecto fracase.
En una fase temprana, se suelen intentar definir todas las características que debe abarcar la arquitectura del juego. Cuando más adelante, los diseñadores quieren que se implemente algo que no había sido contemplado desde el principio suelen aparecer el tipo de "ñapas" de las que habla el artículo.
Por cierto, en la mayoría de mis juegos se mueve el personaje, no el mundo.
#27 ¿qué motor gráfico usais? just curious
#32 En el estudio en el que trabajo, como en la mayoría de pequeños y medianos estudios españoles, estamos usando Unity3D, aunque otros prefieren Unreal.
Para juegos en 2D todavía se usa bastante Cocos2D, y algunos de los estudios más grandes del país desarrollaron motores propios, como por ejemplo Digital Legends, que utiliza Karisma.
#34 Unity3D tiene un potencial demoledor. Muy buena elección.
#34 Me encanta programar y quiero meterme en el mundo de los juegos para android. Alguna recomendación? Con que empezarías? Quisiera empezar con juegos 2D.
#95 Pues depende de cuales sean tu background y nivel actual de programación.
Lo primero que necesitas es una muy buena base de programación orientada a objetos.
También te vendrá bien repasar las matemáticas y física del instituto: tratamiento de ángulos, operaciones vectoriales, matrices y trigonometría general.
Por lo demás, aunque los títulos ayudan (ingeniería informática, másters especializados, etc.), para acceder a puestos de trabajo en este sector lo que realmente se valora es la experiencia en proyectos completos y publicados, independientemente de su envergadura.
Entonces, de una forma u otra, tu objetivo debería ser aprender los fundamentos de la programación de videojuegos mientras completas algunos proyectos que más tarde te permitan acceder a la industria.
Por último, probablemente sea una buena práctica empezar con algún motor de 'bajo nivel' (Cocos2D, Ogre3D), ya que te ayudarán a comprender mejor el funcionamiento de cualquier engine, y más tarde dar el salto a Unity, Unreal, etc. En mi caso concreto, lo primero que hice fue crear un sencillo motor 2D utilizando OpenGL y C++, y programé algunas pequeñas demos con él.
La verdad es que el tema da para escribir bastante, así que si tienes alguna duda concreta o quieres profundizar en el tema, mándame un mensaje privado y ya vemos como lo hacemos.
#27 Eso es sentido común en todo. Las ñapas mientras menos y más tarde mejor, y si se pueden arreglar se arreglan. Estas anécdotas son muy graciosas, pero en realidad muestran fracasos en el desarrollo del software.
#37 Mejor explícaselo a #1
#42 Nah, que estoy planteándome el negocio de "Youtuber cabreado con los bugs", mejor que sigan programando mal.
#42 No hace falta que me explique nada. No son ñapas son formas (bueno en articulo hay alguna ñapa), y e visto muchas con trucos, y como dije si algo hay en la industria del juego son trucos. Ahora puedes decir mierda "por que trabajas profesionalmente" que me la suda.
Te podría contar 1001 trucos que se utilizan comúnmente para hacer videojuegos o para hacer que funcione algo, o ciertas mecánicas, pero bueno como eres "profesional" esta por encima de ti esto.
#44 Perdona que insista, pero tener que cambiar la geometría de la cabeza del personaje por la de un tren indica un problema en la arquitectura: que no te permite desacoplar el componente cámara del resto del personaje. Y que no te siente mal lo de "profesionalmente", no soy yo el primero que ha venido a este hilo a tirarse el pisto
#50 Es una solución a un problema, o hacerlo de la forma más facil si da el pego, hay a patadas en cada juego de estos trucos.
Y saber arrancar Unity y poner objetos en un mapa no te hace programador de videojuegos, como mucho 'diseñador de escenarios'
#52 Con el debido respeto, ¿qué narices sabrás tú lo que hago o dejo de hacer?
#53 Cuéntame más.
#54 Abusas de esa frase. La escribes cada vez que quedas en evidencia.
#57 Si lo que tu quieras, pero no me has contado más. ¿que haces tu profesionalmente dentro la empresa de videojuegos?
#c-58" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2452888/order/58">#58 Soy programador de Gameplay/IA. Aunque ahora trabaje con Unity mi background es de C++, y aunque pasar a C# no supuso ningún trauma, por desgracia se me sigue dando mejor picar código que apañarme con herramientas gráficas.
En los estudios pequeños, el trabajo tiene que salir con la gente que se tiene, pero he tenido la suerte de trabajar con diseñadores de niveles en uno de mis proyectos, y no me parece un trabajo para nada despreciable.
#61 Me cuesta creerte que te dedicas al gameplay y que por otro estés negando que se utilicen trucos "diariamente" en todos los juegos para hacer funcionar ciertas cosas. Pero bueno que no voy a seguir discutiendo...
El diseñador de niveles es pieza clave no los desprecio, todos los son, desde el concept art hasta el animador pasando por todos, cada cual tiene su tarea y es determinante, muchos juegos han triunfado mayormente por el diseño de sus niveles, sobretodo los shooters online, simplemente digo que no es programador de videojuegos, es diseñador de niveles, como el animador es animador no programador. Y no con animo de despreciar su trabajo.
#62 No niego en absoluto que se utilicen trucos como los del artículo. Pero su uso, en el 99.9% de los casos, es consecuencía de presiones externas al desarrollo (deadlines, cambios solicitados por el publisher...) o de una pésima planificación del proyecto.
Por la forma en la que te has expresado en tu primer comentario, dabas a entender a los ajenos al mundillo que desarrollar un videojuego consistía exclusivamente en la utilzación de estas triquiñuelas, y eso no es así. La mayor parte de lo que el jugador ve ocurre como parece que ocurre.
#65 Digo que seguramente todos juego hace uso de ellos y posiblemente más de una vez. Y no siempre es por presiones o mal planificación si no por que es la forma más fácil de hacerlo o por ahorrar tiempo, en vez de implementar algo que a lo mejor llevaría semanas y seria absurdo se puede hacer dando el pego de alguna forma ingeniosa utilizando algo hecho. Simple y llanamente eso.
Y esto que cuenta el articulo no es nuevo es de siempre, si buscas un poco encontraras mil ejemplos de dev tricks de estos en todos los juegos.
#71 Ésto ya es una cosa. Una cosa es decir que en función de las necesidades del proyecto, puede llegar a moverse el entorno dejando fijo al personaje, y otra muy diferente escribir que eso se hace siempre así.
#74 #75 Me dedico a la programación y aunque no tengo la más remota idea de desarrollo de videojuegos tu ejemplo es absurdo, no se trata de sacarse nada de la manga, se tratará simplemente de reutilizar código, si solo necesito dos ropas, voy a crear dos modelos de jugador, si tiene que ser altamente personalizable, bajaré al nivel de un modelo por cada parte del jugador... llamar a eso "truco" está muy lejos de un overflow en un eula o de meter como cabeza del jugador un tren por no poder desacoplar la cámara.
Y si decir que estas ñapas son la mayoría de los casos en el desarrollo de videojuegos te parece lógico...
En fin, de vuestra conversación parece evidente para cualquiera que sepa lo mínimo del mundo de la programación quien es aquí el programador de videojuegos y quien es simplemente un gamer haciéndose notar. Lo siento, pero tenía que decirlo.
#79 Aparte de que veo que te cuesta escribir por que la mitad no te lo entiendo, veo que tampoco sabes leer por que dije que no es truco/ñapa, es la forma de hacerlo, pero que realmente estas haciendo lo que estas haciendo, intercambiando personajes, que se puede considerar un truco para simular el cambio de ropa.
#82 Sabes que más es un truco? No te lo vas a creer. Cuando un personaje conduce un coche, se programa el movimiento del coche, no se mueve los brazos del jugador cambiando las marchas y pisando el acelerador, ni se programa un coche que puedan conducir los personajes. Que fuerte verdad?
#85 Depende, de alguien que implemento leap motion en un par de proyectos te puedo asegurar hasta que hice una que una pistola funciona apretando un gatillo y que podría hacer si es necesario un cambio de marchas funcional en el que el coche cambiara de marcha o moviera el volante interactuando con ellos. Sin utilizar ningún truco de esos para simular el cambio de marchas.
Y sin leap motion se podría hacer también, pero lo más cómodo/fácil y dado que no hay necesidad en un caso normal es utiliza el truco del personaje animado cambiando de marchas y que realmente no es su mano lo que cambia de marchas.
http://i.imgur.com/FxTIV4r.gif
#86 Mi punto era añadir obviedades a las tuyas, que no son ningún workaround a diferencia de lo del artículo. Te lo explico porque veo que no llegas, pero tranquilo que aquí no engañas a nadie.
#99 Vaya que decepción, vivo para engañar a paletos como tu.
#85
#62 Hasta dónde te lleva tu falta de humildad a la hora de debatir...
#66
#61 Por cierto hasta por ejemplo el hecho de cambiar un personaje de ropa, eso no se considera un truco hoy en día, es una forma de hacerlo, pero realmente ¿no lo es? realmente no cambias la ropa del personaje lo que cambias es el personaje.
Luego en su momento no se quien se saco de la manga lo de los personajes modulares, para no hacer mil personajes con diferentes ropas los troceamos y los unimos al gusto depende la ropa que quieres llevar, ya sabes GTA, skyrim.
A eso también me refería con que los juegos son todo trucos y el arte del engaño, donde el gamer cree que el personaje cambia de ropa pero realmente lo que haces es cambiar el personaje.
#52 y si no programas en ensablador eres una nenazas 😑 Lo que hay que oir!
#27 Eso que dices de que "el cómo funcionan las cosas es indiferente" es el camino directo a que tu proyecto fracase.
No pudes oirlo pero estoy aplaudiendo en casa.
En serio, se lo he dicho a la gente mil veces en temas de creación de vídeo y nunca me hacen caso y al final consiguen que todo parezca un batiburrillo de efectos mal hechos, planos improvisados y frases encajadas a lo loco.
#27 amén
#27 lo que #1 creo que se refiere, es que muchas soluciones, al igual que en las películas consiste en engañar al espectador/jugador; no a errores de diseño, quicir, ahora hay mucha más potencia, pero cuando había mucha menos: spectrum, etc... las soluciones eran más 'ingeniosas'.
El del Half-Life 2 del artículo es una de ellas, otras que se indican no.
#1 Mover el mundo?Creo que eso es delos tiempos de Doom.
#47 Se sigue haciendo. En algunos juegos el personaje se mantiene siempre en el centro de la pantalla. En ese caso puede desplazarse el resto del "mundo" manteniendo estáticos la cámara y el personaje. Pero donde realmente se sigue haciendo bastante es en los juegos de gestión en perspectiva isométrica, en los que el jugador simplemente se desplaza por un entorno. En este último caso, si dejamos la cámara fija y desplazamos el entorno, el jugador seguira percibiendo que lo que hace es desplazar la cámara.
#47 Para nada, se hace en multitud de juegos, tanto 2D como 3D pero tampoco es verdad que se haga en todos.
#1 Depende del juego que estés desarrollando, más bien de cámara + personaje.
#1 Son hacks inteligentes, desde luego. No trabajo en ese sector, pero allá por los tiempos del RPGMaker, para simular el uso de vehículos cambiaba el sprite del personaje por uno de un tren, coche o barco; aunque el que se movía era realmente el personaje.
Me encanta el truco del personaje que habla desde otro lado de la pantalla para simular el vídeo...
#90 Exacto, si te vale ¿para que complicarse? hoy en día lo de los coches en algo 3d requiere más trabajo, físicas y un largo etc, pero si es una escena determinada y te vale por que no vas a hacerlo? cambias el modelo, deshabilitas el salto y a tomar por saco. Otra cosa que se base en vehiculos y necesites todo, como en un GTA.
Por eso no coincido con muchos comentarios que hablan de ñapas o soluciones cutres a problemas, simplemente me parece que si te vale y más fácil no te compliques implementando mil cosas nuevas.
A mi lo del espejos del Duke nuken que mencionaba otro meneante, no lo conocía, y de alguien que vio muy por encima como hacer un espejo y vio que le sobrepasaba y paso de espejos... (había que calcular fov depende de la distancia, perspectiva y en definitiva un coñazo que no sabría ni como empezar, además de tragar consumo) es un arreglo curioso.
#91 Como mencionaron posteriormente, para sectores no críticos, como el de entretenimiento, productos en fase de pruebas y similares; esto se puede tolerar. En todos estos casos no se pone en peligro la vida, los datos o la economía de alguien; aunque igualmente hay que ser un poco crítico y solidario y buscar un equilibrio entre calidad, sostenibilidad (que ya sabemos que el código luego se reaprovecha casi siempre, y si se pensó mal y se parchea en cada iteración es un horror para el que viene detrás) y los límites de tiempo que haya. En algunos casos son las limitaciones de hardware las que obligan a jugar creativamente con los recursos; y no hay nada de malo en meter alguna "ñapa", siempre y cuando se respeten los requisitos básicos del producto.
#1 Y yo me sentía sucio cuando hacia mis juegos. Al acabarlos pensaba justamente lo que dices, debía existir alguna forma de hacer un código limpio, que no las chapuzas para que el juego funcionara.
#1 Y cuando juegas online? no puedes mover el mundo y otra persona también
#96 No te entiendo bien lo que quieres decir. Online es lo mismo, si otro jugador esta en las coordenadas al alcance de la vista lo renderizas en la camara si no no. Si el jugador se mueve 1 metro a tu derecha de un frame a otro (Exagerando), lo que haces en cambiar la posición de renderizado del jugador a tu derecha 1 metro.
#1 No se llaman trucos, se llaman métodos heurísticos.
#1 El mundo no se mueve, o expresado de una manera más técnica, a no ser que sea una especificación ultra marciana del diseño las coordenadas del origen del mundo no sufren transformaciones. Se mueven los objetos y se mueve la cámara, pero no se mueve el mundo.
El "truco" del hL2 no es un truco es algo que siempre se hace, un vídeo ocupa memoria, algo muy escaso en las consolas, reproducir lo que ve otra cámara, todo super limitado y controlado será siempre más barato...y más rápido de hacer, hoy en día hay juegos que lo hacen sin problema... a ver, si en el vídeo se tienen que ver 500 personajes y un escenario de la leche pues ya no, pero bueno, se pueden usar modelos de baja y la resolución de render de ese vídeo es muy baja...
Echo en falta el truco de la reflexión, hoy en día continua siendo cara, pero antes, para simular un espejo o un suelo brillante lo que hacíamos era copiar todo el escenario e invertirlo, en algunos casos incluso había dos personajes uno normal y otro invertido... era más barato que calcular reflejos en tiempo real y sobre todo daba más calidad...
Otro truco, que bueno no lo es tanto, y supongo que todo el mundo se da cuenta, es, en los tiempos de carga de niveles, en algunos juegos entras en una habitación cerrada, no puedes salir ni avanzar, para avanzar tienes que hacer algo, normalmente algo que puede llevar mucho tiempo o nada, por ejemplo un "jaqueo automático" de un ordenador dando solo a un botón, o forzar una cerradura, o esperar a que llegue un compañero (IA)el tiempo que tarda el personaje en "jaquear" nunca es el mismo, depende del tiempo de descarga del nivel y el tiempo que tarde en cargar el próximo ntivel.
Después otras pijadas como, en una explosión, vemos un montón de trozos volando, cientos, y estos rebotan contra otros objetos, en realidad, de 100 trozos solo rebotan 10 ó 5 esos 10 son un poco más grandes un poco más brillantes en definitiva más cantosos que el resto para que te fijes más en esos y no en los otros que lo atraviesan todo...las colisiones son muy caras...
Saludos.
#9 para los espejos siempre se ha utilizado una camara que renderiza sobre un textura.
Y por cierto hablando sobre espejos me acuerdo de deus ex HR, en el que no podian permitirse espejos por limitaciones del motor (comentarios del director) y su solucion fue hacer que todos los espejos que aparecen en el juego estuviesen rotos
#88 Eso es ahora, en superficies muy pequeñas y que no sean un espejo pulido, aún así da muchos problemas, principalmente de sincronismo y calidad, el render to texture no va a la misma velocidad y si lo pones a la misma velocidad por ejemplo 30FPS es caro de narices, después, imagina una superficie como un lago, para que un render to texture cubra toda la superficie tendría que tener una resolución enorme, imagina un render de 512*512 renderizandose 30 veces por segundo en una superficie que ocupa 3 km cuadrados, como un lago, qué calidad tendría eso, pues a un textel cada metro, y el coste es insufrible...hay sistemas que automatizan todo eso, pero no deja de ser un truco y se suele notar.
Si se quiere dar un toque de reflejo, en una superficie pulida se usan cube maps precalculados de la escena,o varios cubes calculados en ciertas zonas de la escena, hay motores que tienen un cube global o que ellos solos se encargan de calcular uno para cada "zona"pero es un solo render de 1024*1024, modificando su mapeado para que coincida con la cámara, de forma simple sería, producto escalar entre el vector de cámara y el vector de reflexión, y transformando de local a mundo y normalizando (te lo digo de cabeza seguro que falta algo)...
Por otro lado, en casos como el agua, la cosa se complica ya que esta suele ser translucida, el cálculo de la translucencia es muy caro..si a eso le añadimos el calculo de una textura enorme 30 veces por segundo se nos muere,y si es dinámica ni te cuento...
Lo que se suele hacer en estos casos es hacer todo esto a lo bruto, pasando del motor y programando directamente en la gráfica, en mi ultimo proyecto el agua se hizo así.
Lo de los espejos rotos es una idea muy buena...XDD
Saludos.
#88 Y en el primero con el motor de Unreal sí podían.
#88 Realmente un espejo es bastante más complejo, la cámara si es fija te da una imagen fija, no cambia dependiendo de tu perspectiva, si quieres hacer un espejo tienes que dinamicamente rotar la cámara dependiendo del punto de vista, cambiar el fov estés más cerca o más lejos, etc.
Aparte pruebas ese método de hacerlo en algunos engines populares y traga bastante.
O sea salvo que hagas todo eso realmente no tienes un espejo. Si no una un televisor que emite tu imagen y lo que hay delante de la cámara en directo.
#9 A mi me ha sorprendido que en HL2, toda la parte del video que supuestamente se debería renderizar en un FrameBuffer para luego pasarlo a una textura y pegarla en la TV, se esté renderizando en el mismo contexto de la imagen final del juego.
A mi me huele a limitación del motor (aunque me parece raro que no permita render to texture) que solucionaron reutilizando algún efecto creado para hacer efectos de CCTV en tiempo real.
En el Age of Empires II, en la campaña de William Wallace había una misión en la que el bando de Wallace (amarillo) te entregaba todas sus tropas, que se convertían a tu bando (azul) y podían ser manejadas por el jugador.
Para que no saliera el mensaje "El bando de Wallace ha sido derrotado", ya que se quedaba sin tropas y se ve que era un mensaje automático del motor de partidas del juego, dejaron un soldado del bando de Wallace en mitad de un frondoso bosque en una esquina del mapa. Puedes llegar a él y matarlo si desarrollas los onagros para que puedan arrasar árboles.
#29 Eso pasaba en varios mapas.
Se comió la mejor. La inversa rápida de la raíz cuadrada. Pedazo truco.
https://en.wikipedia.org/wiki/Fast_inverse_square_root
#11 carmack, que puto amo
#24 No lo inventó Carmack:
Del propio artículo compartido por el usuario anterior:
"The algorithm was originally attributed to John Carmack, but an investigation showed that the code had deeper roots in both the hardware and software side of computer graphics. Adjustments and alterations passed through both Silicon Graphics and 3dfx Interactive, with Gary Tarolli's implementation for the SGI Indigo as the earliest known use. It is not known how the constant was originally derived, though investigation has shed some light on possible methods."
#97 no leí el enlace, hace un montón de tiempo que lo vi en software escrito por carmack y creía que era suyo
#11 threehalfs
Mis hogos!!!
#68 Tu havre el cantar de mio zid y criticalo por la horzogracia.
Ese código es historia.
#70 Este vídeo también
#11 Pura magia.
O el Duke Nukem, donde los espejos en realidad son cristales transparentes por los que miras a habitaciones invertidas donde se genera un clon de tu personaje que se mueve como tú. Esto ocasionaba el problema de que allá donde hubiera un espejo, luego había un espacio sospechosamente amplio sin entradas, porque si no podrías entrar en la habitación invertida.
Buscad sobre los trucos de programación de la Atari 2600.
4KB de ROM para juegos.
128k de RAM. Teóricamente sin scrolling y mucho menos parallax scrolling.
Pues consiguieron hacer esto.
#10 El precio de 128KB de RAM en 1977 era aún prohibitivo. No sé si ha sido una errata al escribir o si realmente pensabas que tenía 128KB de RAM. Si es lo segundo y ya estabas flipando, cuando te enteres de que sólo tenía 128 bytes te va a dar algo
#63 Eso, bytes. Era tarde y estaba sopa.
Yo utilicé un truco para crear enemigos en un juego de naves en la plataforma antigua de MS-DOS Div Games.
El truco era que para no crear los movimientos mediante programación creé un programilla que regsitraba los movimientos del ratón, y los metía en un array.
Con un botón bloqueaba un eje, así que por ejemplo solo lo movía horizontalmente, si liberaba ese botón y pulsaba el otro se movía verticalmente, y si los dejaba sin pulsar ambos botones, era el movimiento libre.
Luego si pulsaba la barra espaciadora tres veces, se creaba un array dinámicamente y era el movimiento de otra nave.
Total que hice los movimientos de un montón de naves en apenas una tarde. Luego solo era asignarle el gráfico, el sonido al explotar, y listo.
Ahorré tardes y tardes de trabajo.
Me extraña que no salga el "Strafe Jump" del quake 3, que empezó siendo un bug y terminó como una de las mayores señas de identidad de la saga: https://en.wikipedia.org/wiki/Strafe-jumping
(Pulsando las teclas de dirección durante un salto, la velocidad de el jugador aumenta. Si se encadenan strafe jumps sucesivos se pueden alcanzar velocidades estratosfericas.)
#13 Que no te extrañe: no tiene nada que ver con este tema.
#13 También estaba el truco de jugar mínimo a 125 fps, que te permitía saltar un poco más alto.
En el wow no usan solo conejos, tambien usan diablillos:
http://www.wowhead.com/npc=18955/camera-shaker-30-90-seconds
o infernales:
http://www.wowhead.com/npc=28351/flame-breath-trigger-skadi
¿La solución? Aprovechar los términos de uso, o EULA, que eran descargados cada vez que el juego se conectaba a Internet; al final de esta muralla de texto que nadie lee, se incluyó una cadena tan larga que provocaba un desbordamiento de buffer, lo que permitió ejecutar código en memoria, que descargaba e instalaba el parche.
Brutal.
Estoy en contra de los trucos chapuceros en el software, excepto en este caso concreto del desarrollo de videojuegos, al fin y al cabo solo es entretenimiento, si la ñapa deja de funcionar en el futuro, pues se saca un parche y tirando. Pero cuando se desarrolla software que será explotado en un entorno empresarial, no es permisible todo este tipo de trucos que al final acaban creando deuda técnica ( https://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica ), y hacen que el sofware sea frágil y sea mas difícil de mantener y modificar en el futuro.
Me consta que en muchos bancos, el software funciona a golpe de parches y chapucillas que hacen que todo mas o menos funciones al día, pero internamente está todo cogido con alfileres.
#5 GOTO #33
Te sorprenderías amigo mío... en informática, sobretodo cuando la aplicación viene de una cárnica, es el pan de cada día. Y mas que trucos diría autenticas chapuzas con miles de parches por encima para que todo acabe funcionando con pinzas.
Y en otras areas de la ingenería, según mi experiencia, aunque no tan exagerado como en informática también puedes encontrarte muchos "trucos".
#93 miedo me da que hagan algo similar al construir edificios o vehículos
En cuanto trabajas en un proyecto grande que aglomera distintas tecnologías, tienes que valerte de mil trucos para que se comuniquen unas partes con otras, y más con tareas asíncronas, que son a donde la informática ha evolucionado.
Recuerdo una vez que desde la aplicación cliente se pedía un informe al servidor. Ese informe tardaba varios minutos en generarse, por lo que no era factible quedarse esperando a que acabara. Había que pedirlo, y seguir en la aplicación cliente haciendo otras cosas. A su vez, el servidor no podía acaparar el thread principal con esa tarea, por lo que había que crear un hilo adicional que tratase esa tarea.
La forma de saber si había acabado, era llamando cada 10 segundos al servidor para preguntarle, a través de una función que lo que hacía era mirar un fichero de log donde el proceso que generaba el informe iba indicando su progreso.
El truco era ese: para sincronizar dos procesos, usábamos un fichero de texto donde uno escribía y otro leía.
#26 A mi me tocó modernizar una aplicación que hacía algo parecido a eso.
Estaba en Visual Basic (padre de grandes horrores) y para sincronizar 2 procesos ambos escribían y leían de un cuadro de texto en un formulario oculto donde iban leyendo y escribiendo parámetros.
Lo dicho, HORRIBLE
#64 Lo de tener en los formularios campos ocultos con valores que se necesitan para hacer cálculos, es otro truco que es el pan nuestro de cada día.
#26 Hum... estoy un poco oxidado con la programación, pero eso que dices no creo que se pueda considerar un truco. Será más o menos chapucero hacerlo con un archivo de texto, pero utilizar un recurso común bloqueable para sincronizar dos procesos creo que es una práctica estándar en programación concurrente.
EL del Half life 2 me ha encantado.
Yo espero que no hayan trucos así en una central nuclear o un avión de última tecnología.
Alguien: "Oye, tío el control de temperatura del reactor peta con error de falta de memoria, ¿que hacemos?"
Otro: "ah.... desinstala el antivirus y pon un post-it que no ejecuten muchas aplicaciones allí"...
tiempo después...
Auditor: "Por seguridad, se debe instalar esta megasuperchachi Suite de seguridad pro ultra max con todo este montón de módulos útiles"
instantes después
CNN: "Hoy abrimos con una terrible noticia... o depende si tiene la extraña esperanza de convertirse en un superhéroe radioactivo"
#5 No hace mucho se estrelló un avión en España cargado de pasajeros en el que habían empleado un truco en un sensor de temperatura con una bolsa de hielo. Es imposible trabajar con una alarma zumbando todo el rato, y si no, que se lo digan a Homer Simpson.
#5 Y no te extrañe que eso pueda pasar.
Actualmente parece que es más importante ahorrar costes que la seguridad.
#5 No quiero que te conviertas en un paranoico, pero en programas como megaconstrucciones, y otros dedicados a máquinas a veces si se desvelan "chapuzas" problemas que hay que apañar por algo que no estaba planeado.
En el fondo aunque no se "noten", no hay tanta diferencia de hacer los apaños que se ven en internet, por ejemplo arreglar algo con una percha que hacerlo con una pieza NS543, sea lo que sea que signifique eso.
Una que recuerdo era un avión, su estructura no estaba pensada para ser taladrada, pero al final lo hicieron y no pasó nada... todavía.
En lo del Fallout me imagino que habrían un par de discusiones entre el que tuvo la idea del recorrido en tren y los programadores ¿Pero no se puede solucionar con enseñar que entras al tren, fundido en negro, y mostrar que sales en el punto de llegada? No me jodas...xd
En Skyrim el contenido del inventario de los negocios está contenido en un cofre escondido por debajo del nivel del suelo. Ahora, si realmente quieren ver trucos ingenioso deben de darle unas mirada a los mods, hay algunos que han logrado hacer cosas increíbles a base de "trucos"
#40 Mi primer inventario para un juego cuando cogías un objeto realmente lo teletransportaba a un socket en el cuerpo y lo hacia invisible y anulaba la física, cuando lo sacabas lo teletransportabas a la mano y lo hacías visible, podías ponerlo en el mapa donde quisieras claro pero yo se lo enchufaba al personaje.
Por no decir del Doom, que es un juego en 2D en el que las aristas del mapa 2D se proyectan verticalmente y es espacio resultante entre aristas se pinta del color que sea.
El del Wing Commander me ha matado. Encajaría a la perfección en la saga del Monkey Island.
En el dia a dia todos usamos "trucos" para q funcione nuestro monton de codigo . Y no digo na de la peña q este usando frameworks o apis con nula documentacion.
Genial articulo
editado.
Por fin una lista original desde un punto de vista diferente. Muy bueno!
Una cosa es que sea un truco, pero es una chapuza. El de Fallout 3 pega un cantazo, porque el movimiento es antinatural. Es decir, así no se mueve un tren, sólo hace falta ver el movimiento al hacer una curva, no es un movimiento homogéneo.
El de Half-Life 2 cuanto menos es curioso.
Salu2
Otro más, así era el crysis si viésemos al personaje:
https://www.niubie.com/2014/07/asi-se-ve-el-protagonista-de-crysis-2-en-tercera-persona/