Si te interesa escuchar más opiniones y sugerencias al respecto te
recomiendo la lista de discisión que hay en:

http://vjuegos.cem.itesm.mx

la mayoría programa en C/C++ usando DirectX u OpenGL, pero seguro
escucharás buenas propuestas e ideas para manejo de scripts en tu
juego, hechale un ojo.


--- todoslosnombresestancogidos <soyunemail@...> escribió: > > >
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
>
>
> _______________________________________________
> Para cancelar su subscripción envíe un email a:
> allegro-espanol-unsubscribe@egroups.com
>
>
> La utilización de Yahoo! Grupos está sujeta a su aceptación de las
> Condiciones del servicio (http://es.docs.yahoo.com/info/utos.html)
> así
> como de la Política de privacidad (http://privacy.yahoo.com/es/).
>
>
>

=====
"Ser mejor es esforzarse más que los demás
hasta lograr lo que nadie ha hecho"

_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx