Hace 8 años | Por add_ex a omicrono.com
Publicado hace 8 años por add_ex a omicrono.com

Estos trucos de programadores de videojuegos te sorprenderán por lo enrevesados y curiosos que pueden llegar a ser.

Comentarios

Rorschach_

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!

D

#2 flipante

R

#1 No, depende del juego. También se mueve el personaje.

G

#3 Si, no me digas, cuéntame más.

R

#4 Quiero decir, que muchas veces en el mismo tipo de juego puedes elegir entre hacer mover el personaje o el mundo.

y

#7 entiendo por lo q dice q es la camara q se mueve

D

#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

G

#25 Me refería a los juegos 3D.

G

#35 Aunque muchos con 2d/scroll es lo mismo mueves el mundo.

Willou

#35 ¿En el FIFA no mueves los personajes?

G

#51 Básicamente estas dibujando y moviendo el mundo y sus objetos delante de la camara. Esa así como funciona DirectX,

D

#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.

D

#25 Se mueve la pantalla muchas veces.

D

#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.

magarzon

#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

i

#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.

fernandojim

#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.

o

#1 En OpenGL prehistorico quizá, hoy en día se mueve la cámara, osea tú.

G

#21 Exacto, escalas y mueves el mundo

Sr.Azul

#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.

G

#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.

fernandojim

#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.

vaiano

#1 me da a mi que muchos no has hecho.

D

#27 ¿qué motor gráfico usais? just curious

D

#34 Unity3D tiene un potencial demoledor. Muy buena elección.

sdsoldi

#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.

sotanez

#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.

D

#37 Mejor explícaselo a #1 lol

sotanez

#42 Nah, que estoy planteándome el negocio de "Youtuber cabreado con los bugs", mejor que sigan programando mal.

G

#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.

D

#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

G

#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'

D

#52 Con el debido respeto, ¿qué narices sabrás tú lo que hago o dejo de hacer? lol

G

#53 Cuéntame más.

D

#54 Abusas de esa frase. La escribes cada vez que quedas en evidencia.

G

#57 Si lo que tu quieras, pero no me has contado más. ¿que haces tu profesionalmente dentro la empresa de videojuegos?

G

#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.

G

#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.

D

#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í.

G

#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.

MazarD

#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?

G

#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

MazarD

#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. lol

G

#99 Vaya que decepción, vivo para engañar a paletos como tu.

D

#85 lol

SWEVEN

#62 Hasta dónde te lleva tu falta de humildad a la hora de debatir...

G

#66

G

#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.

s

#52 y si no programas en ensablador eres una nenazas 😑 Lo que hay que oir!

Cabre13

#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.

s

#27 amén

T

#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.

i

#1 Mover el mundo?Creo que eso es delos tiempos de Doom.

D

#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.

D

#47 Para nada, se hace en multitud de juegos, tanto 2D como 3D pero tampoco es verdad que se haga en todos.

D

#1 Depende del juego que estés desarrollando, más bien de cámara + personaje.

Arcueid

#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...

G

#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.

Arcueid

#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.

r

#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.

Zorlek

#1 Y cuando juegas online? no puedes mover el mundo y otra persona también lol

G

#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.

D

#1 No se llaman trucos, se llaman métodos heurísticos.

D

#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.

S

#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 lol

D

#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.

D

#88 Y en el primero con el motor de Unreal sí podían.

G

#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.

Boleteria

#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.

crycom

#29 Eso pasaba en varios mapas.

voromir

#11 carmack, que puto amo

Boleteria

#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."

voromir

#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

D

#11 threehalfs

Mis hogos!!!

l

#68 Tu havre el cantar de mio zid y criticalo por la horzogracia.

Ese código es historia.

D

#70 Este vídeo también

Shinu

#11 Pura magia.

D

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.

f

#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

D

#63 Eso, bytes. Era tarde y estaba sopa.

Zeioth

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.

D

#13 También estaba el truco de jugar mínimo a 125 fps, que te permitía saltar un poco más alto.

Aokromes
Nitros

¿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.

prejudice

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.

Boleteria

#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".

prejudice

#93 miedo me da que hagan algo similar al construir edificios o vehículos

Mister_Lala

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.

D

#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 lol

Mister_Lala

#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.

D

#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.

D

EL del Half life 2 me ha encantado.

C

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"

D

#5 Y no te extrañe que eso pueda pasar.
Actualmente parece que es más importante ahorrar costes que la seguridad.

D

#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.

S

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

EGraf

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"

G

#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.

o

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.

CountVonCount

El del Wing Commander me ha matado. Encajaría a la perfección en la saga del Monkey Island.

D

En el dia a dia todos usamos "trucos" para q funcione nuestro monton de codigo lol. Y no digo na de la peña q este usando frameworks o apis con nula documentacion.

e

Genial articulo

G

editado.

Minéame

Por fin una lista original desde un punto de vista diferente. Muy bueno!

Nova6K0

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

crycom

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/

1 2