Crear un videojuego

[cobito]

Si mal no recuerdo, half life 2 que es un titulo relativamente reciente fue programado en c++. Pero en estos temas, como bien ha dicho, kynes tiene la última palabra.

[pedro181990]

La verdad es que sí quizás no consigas hacer un juegazo, pero pasar un buen ratillo seguro que lo consigues ¿no creeis? Yo empecé a hacer uno pero lo dejé por falta de tiempo, pero me gustaría reiniciarlo ahora. Bueno pero para eso tengo que aprender muchas cosas… xD. Saludos!!!!

[GaS]

eso esta bien para cuando te aburres mucho i no tienes nada qe hacer.., xD

;D

[NaSeR]

@pedro181990:

También hay gente que siempre le habría gustado hacer un juego, y esta es su ocasión además con todo un verano por delante. Saludos

Un verano dice xDD

Es una pérdida inútil de tiempo. Si quieres hacer algo decente haz un mod del Half Life 2. Pero ten en cuenta que ya será un mod y no a toda la gente le gusta tener que instalarse un juego para poder jugar a otro, ya puede ser bueno…
Todos tenemos ideas impresionantes para hacer juegos, pero los juegos no se hacen con ideas impresionantes, sino con dinero o bien con años de vida y esfuerzo.

Si como digo te quieres hacer tú tu propio mod, ten en cuenta de que la inmensa mayoría de los mods que se inician o bien no acaban o si lo hacen nunca lo dejan como planearon, así que tienes muchas papeletas para estar en ese grupo. Sólo unos pocos llegan a conseguir exactamente la meta que se propusieron y eso después de varios años perdiendo tiempo que podrías dedicar a otra cosa, saliendo a mal con mucha gente y con el estrés que supone coordinar a un equipo… en el supuesto caso de que lo consigas. Para empezar tienes que tener las ideas muy claras, si no las tienes tú no pienses que las va a tener tu equipo. Luego tienes que saber muchísimo inglés puesto que gente que pueda hacer esos trabajos de forma desinteresada hay muy poca y menos que hable español. Después necesitas gente que maneje el 3ds para hacer los modelos, animaciones, otros con el photoshop que se dediquen a las texturas, otros para sonidos y voces, coders, mappers etc
Los pocos que hay están muy solicitados, y para atraerlos a tu mod tienes que haber hecho ya alguno famoso o bien presentar algo de trabajo ya hecho y que vean que tiene futuro, y aún así...

Tampoco te quiero desilusionar eh?, pero todos hemos tenido alguna vez esa idea en la vida y después de ver el panorama eso es lo que te puedo decir.
No obstante siempre puedes recurrir a esos métodos para hacerte una chapucilla (hay unos cuantos más) o si te gustan las novelas visuales ahí sí que influye la imaginación y la dificultad baja muchos enteros, claro que seguro que no es el caso.

[albertpg]

Toma ya! Seguro que al colega le siguen quedando ganas de hacer algo.. ;D

[pedro181990]

Yo sólo digo una cosa ¿Es acaso el comecocos un juego sin éxito? Yo creo que es uno de los juegos mas famosos que existen, y yo creo que para hacer un juego así no se necesita mucho actualmente… Y yo no digo que yo vaya a hacer un juego así ni siquiera creo que vaya a hacer un juego... pero pienso que entretenerse haciendo un pequeño jueguecillo no es mala idea, y si para vosotros es una pérdida de vuestro tiempo pos no lo hagáis pero seguro qu hay mucha gente cuyo tiempo si permita hacer un jueguecillo, bueno pos un saludo.

[amd125]

PAZ HERMANOS!!!!!

Que cada uno haga lo que quiera con su tiempo libre :sisi:

[kynes]

@Raesan:

… que queda de ensamblador o C++ programando GPU´s

Hmmm programando GPU's… Depende. Hoy en día hay lenguajes de alto nivel (equivalentes al C++) para programar shaders, como el HLSL, pero lo "normal" es usar HLSL para los shaders que no sean críticos en rendimiento, y ensamblador para los pocos shaders que si lo sean, debido a que aparecen en un gran porcentaje del tiempo del juego (ejemplo, los de iluminación con la linterna en juegos como el Doom3 o el HL2) Lo ideal es que de estos últimos se hagan varias versiones, para cada arquitectura de tarjetas, y así evitar fallos de diseño en la arquitectura buscando la forma más eficiente de realizar el efecto. Por esto se hacen algunos shaders a mano, porque los compiladores de lenguaje de alto nivel todavía no son del todo eficientes, sino que nos dan un código que sea válido según el estándar, pero sin centrarse en conseguir un rendimiento magnífico.

Es lo mismo que pasa con la programación del resto del juego, la gran mayoría se programa en lenguajes de alto nivel como C++, pero hay funciones que incluyen partes de ensamblador como forma de acelerar en gran medida el rendimiento de una parte crítica del juego. Ejemplo: Una fórmula para calcular 1/sqrt (x) que se utiliza en el Quake 3:

float InvSqrt (float x){
float xhalf = 0.5fx;
int i = (int)&x;
i = 0x5f3759df - (i>>1);
x = (float)&i;
x = x(1.5f - xhalfxx);
return x;
}

El truco está en esta línea: i = 0x5f3759df - (i>>1); que mediante un "número mágico" nos proporciona un valor inicial bastante aproximado a la raíz de la función, y con este valor inicial alimentar el método numérico de Newton (la línea x = x*(1.5f - xhalfxx); ) que se basa en iteración en vez de cálculo puro y duro, y encima mediante enteros. Es duro de comprender el algoritmo pero funciona, y de una forma muchísimo más eficiente que pidiendo el cálculo de la manera tradicional, al menos en los procesadores de la época. Una explicación detallada de la función y del origen de ella se puede encontrar en http://www.beyond3d.com/content/articles/8/ y en http://www.beyond3d.com/content/articles/15/

Una explicación mucho más detallada, en http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf

PD: No lo comenté antes, pero la gracia es que al pasar de flotantes a enteros, y realizar esta operación mediante enteros, en los procesadores antiguos, que eran mucho más poderosos en enteros que en flotantes, se aceleraba de una forma brutal el rendimiento. Si se hubiera hecho mediante un lenguaje de alto nivel como el C++ en vez de en ensamblador, esta operación hubiera consumido muchísima potencia de cálculo de flotantes, ya que se hubiera realizado mediante la operación sqrt del procesador, que es en coma flotante, por lo que el quake 3 hubiera tenido un requisito de procesador mucho mayor. Al ser utilizada esta función para normalización vectorial, imaginaros la cantidad de veces que puede ser llamada a lo largo de la generación de una sola imagen.

PD2: Ya que estamos, el motivo por el que se busca realizar de forma muy rápida 1/sqrt(x) es para normalizar vectores 3D de forma muy eficiente, cosa que se realiza MUCHÍSIMO en aplicaciones 3D.

Tienes una forma lenta:
const float length = sqrt( v.xv.x + v.yv.y + v.z*v.z );
v.x /= length;
v.y /= length;
v.z /= length;

Y una forma rápida:
const float recip_length = InvSqrt( v.xv.x + v.yv.y + v.z*v.z );
v.x *= recip_length;
v.y *= recip_length;
v.z *= recip_length;

La segunda versión no tiene divisiones, ni llamadas a la función sqrt, por lo que es bastante más rápida.

Siento haber desviado el hilo, pero este tipo de temas me resultan tan curiosos que no podía evitarlo ;D

[Forenaits]

Ahora entendéis porque nos dan tanto por saco con las matemáticas en la carrera de informática.

[kynes]

En el fondo la programación es matemática y lógica, poco más…

[cobito]

Pero cuando el ordenador calcula la raíz cuadrada también se usa un método iterativo ¿no? Usar el método de Newton para que es ¿para quitarle precisión al cálculo y darle velocidad?

[kynes]

Si, utiliza un método iterativo pero no un método numérico, no se si me explico La función esa tiene lógica en procesadores con mucha potencia de enteros y poca de coma flotante, ya que hace una conversión a entero y trabaja con enteros. Este tipo de funciones funciona muy bien en procesadores como el P4, que tenían mucha potencia de enteros pero de flotante eran terriblemente flojos, y por eso el quake 3 era de los pocos juegos donde arrasaba a los athlon.

Detalle que es ejemplo típico, utiliza un desplazamiento a la derecha sin retroalimentación, operación muy fácil de hacer para un procesador (simplemente un desplazamiento en los flip-flop en vez de todo el cálculo de la división-> p.ej. pasar de 01000010=66 a 00100001=33) y que equivale a una división entera por dos (al trabajar con enteros nos comemos el decimal, pero al ser aproximaciones se supone que la variación es despreciable para el resultado final) pero con mucha menor carga computacional. Ejemplo de libro en programación con ensamblador.