#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
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.
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.
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: 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.)
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.
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.
#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.
#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
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.
#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.
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.
#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 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.
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 ( es.wikipedia.org/wiki/Deuda_técnica ), 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.
#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.
#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.
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"
#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.
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.
#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.
#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
#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.
¿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.
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.
#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.
#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
#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.
#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.
#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.
#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í.
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
#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.
#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.
#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.
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.
#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
#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.
#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.
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".
#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.
#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.
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."
#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.
#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.
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
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
#1 ¡Spoiler!
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"
4KB de ROM para juegos.
128k de RAM. Teóricamente sin scrolling y mucho menos parallax scrolling.
Pues consiguieron hacer esto.
www.youtube.com/watch?v=R1G_si-9fgE
en.wikipedia.org/wiki/Fast_inverse_square_root
(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.)
www.wowhead.com/npc=18955/camera-shaker-30-90-seconds
o infernales:
www.wowhead.com/npc=28351/flame-breath-trigger-skadi
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.
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.
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.
Actualmente parece que es más importante ahorrar costes que la seguridad.
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.
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.
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.
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.
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.
Y si os interesa coger cualquier libro de programación con DirectX que os muestra/enseña todo eso.
Y saber arrancar Unity y poner objetos en un mapa no te hace programador de videojuegos, como mucho 'diseñador de escenarios'
Brutal.
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.
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.
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
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.
Mis hogos!!!
Ese código es historia.
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.
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.
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.
www.youtube.com/watch?v=1N5n9zbgY_s
www.niubie.com/2014/07/asi-se-ve-el-protagonista-de-crysis-2-en-tercer
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.
i.imgur.com/FxTIV4r.gif
El de Half-Life 2 cuanto menos es curioso.
Salu2
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
Me encanta el truco del personaje que habla desde otro lado de la pantalla para simular el vídeo...
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.
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".
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.
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."
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.