> > Aun me dejas en la duda de si Python es en realidad mejor, ¿tu
> > crees que un proyecto grande, por ejemplo el quake3 hubiese sido
> > mejor y mas rapido de desarrollar en Python que en C? y si dices
> > que si, porque los quakes, doom(3), unreal tournament, etc no se
> > hacen con phyton?
>
> Porque son muy chulos y desarrollan su propio lenguaje de scripting,
> Carmack inventó el Quake-C, y no sé cómo se llama el del Unreal, pero
> por ejemplo toda la inteligencia artificial del juego va por scripts.
>
> La razón de que estos dos gigantes no hayan usado Python es porque
> no "nacieron ayer". La historia de los creadores del Quake es
> impresionante, y aunque reescriban el motor de una versión a otra,
> todo lo demás (sobre todo la lógica) no tiene que ser reescrito.
> Lo que ves hoy en día es seguramente el trabajo de casi una década.
>
> Además, como es específico del juego es siempre más óptimo que
> un lenguaje de propósito general, pero claro, hacerse su propio
> lenguaje puede suponer días o años, según tu ambición.

Ok, creo que mirare mas a fondo Python para ver si aprendo el lenguage
ya que seguro que se programa más rápido que C, y tambien miraré Lua
para ver si me cubre todas mis necesidades.
Total, solo quiero un juego que almenos sea construido de la forma más
profesional que pueda, haber como queda.

> > Aunque usan algun lenguaje de script seguro, no se cual, supongo
> > que desarrollados por ellos, no creo que incluso el motor lo hagan
> > en este lenguaje de script, lo hacen en C (motor de quake1/2/3:
> > C, half life:C++, unreal tournament ? , doom3 C (creo)) por lo
> > que en el fondo debe de conseguirse algun tipo de ganancia en
> > control/velocidad/calidad.
>
> Claro, yo no había sugerido lo contrario: al fin y al cabo Python
> no tiene acceso directo al hardware, y por debajo siempre vas a tener
> un directX o similar programado en C, que llamas desde python, y éste
> a su vez tendrá una capa de abstracción que tratará con ensamblador,
> y finalmente esta con el microcódigo de los drivers de la tarjeta.

Ya, pero a veces sacrificar claridad por velocidad no lleva a mejores
programas, prefiero un código legible y fácil de entender en Python
que una patraña en ensamblador que es 2 veces más rápido.
Seguro que en Python el código queda más legible que en C, pero tengo
que aprender y eso me hecha atrás, por ahora continuaré con mi C, SDL
y Lua haber como queda, más adelante haré el siguiente paso.

Y gracias por la información Lua/Phyton.

Carlos Rodríguez Caminero