Programando videojuegos con SL

Comencemos

tecnologías libres (cómo no)

Siempre es mejor desarrollar con tecnologías libres. A la larga te das cuenta.

1. A nivel casero (uséase, sin ser una gran compañía), pueden ejecutarse juegos programados por nosotros en consolas como PS2, xbox, etc? ¿Qué hay de las de nueva generación (PS3, xbox360, PSP...)?

Podemos desarrollar para consolas comerciales con kits amateurs creados por la scene de cada una de estas. La parte negativa es que hay que "crackear" la máquina para que acepte código no firmado, lo cual puede perder la garantía o incluso puede dar problemas a la larga (no por el software, sino por el crack). La PS3 dispondrá de una interfaz OpenGL ES, por lo que será relativamente sencillo crear una implementación libre que la utilice. XBOX360 utiliza D3D, pero no creo que cueste mucho hacer lo mismo que con la PS3, ya que en esta, si hay problemas a la hora de usar la ATI, se puede tirar del procesador de tropocientos cores PPC. La PSP ya es una realidad, pero Sony hace todo lo posible por tapar los agujeros.

De todas formas RECOMIENDO encarecidamente programar para máquinas libres como la GP32 o su sucesora GP2X. Paso de dar motivos a la gente haciendo programas para una máquina de una compañía que se niega a dar recursos para programar libremente o incluso dificultarlo. Ok, tienen todo el derecho de hacer lo que quieran para que no usen copias piratas... pero a estas alturas molesta ver como las compañías se esfuerzan de dejar de lado a la scene.

2. Si la pregunta anterior es correcta... ¿En qué lenguaje/s debería estar programado el juego? Supongo que con C y C++ no habrá problema, pero ¿y con otros lenguajes más nuevos ó menos comunes en estos menesteres (C#, Python, Java...)?

Puedes programar en C, C++, Pascal, Basic... todo para lo que hayan creado un compilador. GCC es el más portado (gracias a su gran poder de portabilidad y a que está divido en 2 partes). El tema de C#/Python/JAVA es algo más peliagudo: dependen de un intérprete o máquina virtual. Estos consumen recursos y no todas las máquinas lo soportan. Sin embargo las generaciones futuras de consolas no tendrán problema... C# y Python podrán ser portados (tienen Interpretes/máquinas virtuales libres). JAVA, aunque tiene implementaciones libres... la gente que se dedica a ellas no está por la labor y no la portarán a algo que no sea "empresarialmente" necesario.

3. En éste hilo se comentaba que uno de los puntos fuertes para la portabilidad era el degradado. A groso modo, el mejorar ó quitar calidad a las imágenes y mapas según la potencia de la máquina. ¿Eso depende también de la programación del motor del juego exclusivamente ó también de la forma en que se hagan los gráficos?

Sobre todo depende del motor del juego. Me explico: el motor debe saber cuando mostrar/calcular según que zonas o partes. No es lo mismo renderizar a una distancia de unas 10Km que 10m... no es lo mismo renderizar 50 personajes que 10. De la misma forma se comprueba con la práctica que no es lo mismo renderizar 5 personajes de 1000 polígonos que 10 de 500 (los números salen igual en cuanto a polígonos... pero cada uno tiene su propias funciones...). El engine ha de saber que sacrificar en cada momento: desde el número de polígonos, pasando por el número de normales de cada uno (para todo lo relacionado con efectos de mapeado y luces) a la lejanía de la cámara. Lo mismo pasa con los FPS... el juego debe reaccionar igual a 100fps que a 15. Los 60fps típicos mínimos son porque la interacción hombre-máquina se ve muy afectada si baja de esa cifra. Aunque todos hayamos jugado a 10fps a veces.

También es muy importante COMO se modela. Se debe saber modelar triangulando bien según que zonas... ya que si por software en algún momento se decide bajar el poligonaje, puede deformarse totalmente la maya. Aunque la gente no lo tiene en cuenta y utiliza otras técnicas como bajar la resolución de texturas o utilizando MipMapping.

4. Al desarrollar juegos con Mono vemos que ya hay disponibles versiones para Mono de SDL (SDL#) y OpenGL (OpenGL.NET). Deduzco que con éstos, la velocidad de ejecución de esas tareas concretas que dependan de ellos, se harán a una velocidad parecida a como lo hacen en sus versiones de C/C++. Pero, ¿sabe alguien qué rendimiento puede dar un juego hecho con Mono respecto a otro hecho de la forma tradicional? ¿Sería mucho más lento?

De esto podríamos estar hablando días... pero te lo resumo: Mono hace muy buen trabajo. Podría decirte que al final no notarías diferencia... pero no es verdad. La verdad es que con el tiempo podrás hacer muchas virguerias y te dará igual el lenguaje, ya que las máquinas suben de potencia. Con los procesadores de múltiple core los lenguajes que dependen de una MV se ven beneficiados inmediatamente (no hace falta necesariamente que pienses en hilos). Con C/C++ si no programas multihilo no notarás diferencia y no supondrá ningún avance. C# es muy bueno, pero para programar de fondo prefiero C++.

DarkPython (el motor que estoy preparando para BG) está escrito en C++... pero el scripting de usuario irá con Python. Veremos como rinde (Civilitzation IV está hecho utilizando las mismas técnicas).

En el anterior hilo decías que querías hacer un "PCFurgo"... DarkPython es ideal para tí... o al menos el concepto que yo tengo de lo que estoy haciendo que por ahora no es nada (no hay nada chachi que ver). Pero bueno... ya abriré un hilo sobre el tema.

Lo principal es dibujarte en un papel o sobre un lienzo de Gimp/DIA la estructura de todo lo que necesitas y como lo divides... y luego empezar a implementar.

Bueno, no tengo más tiempo ahora... nos vemos más tarde!

FuckingFreaky escribió:Siempre es mejor desarrollar con tecnologías libres. A la larga te das cuenta.

Jamás lo dudé! Soy fan de las tecnologías, formatos, y estándares abiertos, más que del propio software abierto.

Rurouni escribió:De todas formas RECOMIENDO encarecidamente programar para máquinas libres como la GP32 o su sucesora GP2X. Paso de dar motivos a la gente haciendo programas para una máquina de una compañía que se niega a dar recursos para programar libremente o incluso dificultarlo. Ok, tienen todo el derecho de hacer lo que quieran para que no usen copias piratas... pero a estas alturas molesta ver como las compañías se esfuerzan de dejar de lado a la scene.

Realmente yo me quedé en la PSX.... Pero sí, realmente me jode que si te compras una máquina, no puedas hacer con ella lo que te salga de las narices... joé! la has pagado! ¿por qué no vas a poder ejecutar tranquilamente tu software? Entiendo que no te den soporte para problemas relacionados con tu software, pero no todo esto.
Estuve mirando lo de la GP2X a través de otro de los mensajes de BomberGUM! Tiene buena pinta, pero aún así creo que todos sabemos que se va a quedar con una cuota de mercado reducidísima... . Ojalá hubiera más proyectos así.

C# y Python podrán ser portados (tienen Interpretes/máquinas virtuales libres). JAVA, aunque tiene implementaciones libres... la gente que se dedica a ellas no está por la labor y no la portarán a algo que no sea "empresarialmente" necesario.

Sólo como curiosidad... La máquina de Mono también corre Java, por lo que si se porta Mono a alguna plataforma, también se podrá correr Java en ella. No sé si lo sabías, pero puntualizo.
También, en un futuro, prentenden integrarse los ocmpiladores de Mono en GCC, al menos crear una extensión, por lo que supongo que también facilitará la tarea tanto para las distribuciones como para este tipo de menesteres.

Rurouni escribió:Sobre todo depende del motor del juego. Me explico: el motor debe saber cuando mostrar/calcular según que zonas o partes. No es lo mismo renderizar a una distancia de unas 10Km que 10m... no es lo mismo renderizar 50 personajes que 10. De la misma forma se comprueba con la práctica que no es lo mismo renderizar 5 personajes de 1000 polígonos que 10 de 500 (los números salen igual en cuanto a polígonos... pero cada uno tiene su propias funciones...). El engine ha de saber que sacrificar en cada momento: desde el número de polígonos, pasando por el número de normales de cada uno (para todo lo relacionado con efectos de mapeado y luces) a la lejanía de la cámara. Lo mismo pasa con los FPS... el juego debe reaccionar igual a 100fps que a 15. Los 60fps típicos mínimos son porque la interacción hombre-máquina se ve muy afectada si baja de esa cifra. Aunque todos hayamos jugado a 10fps a veces.

Jodé, realmente suena complicadísimo, pero claro, es lo que diferencia lo bueno de lo excelente... Hasta donde más he visto yo es la técnica de crear distintas texturas a distintas resoluciones y cargar según convenga. Como parece que dices, hay técnicas mucho más eficientes.

Rurouni escribió:Con los procesadores de múltiple core los lenguajes que dependen de una MV se ven beneficiados inmediatamente (no hace falta necesariamente que pienses en hilos). Con C/C++ si no programas multihilo no notarás diferencia y no supondrá ningún avance. C# es muy bueno, pero para programar de fondo prefiero C++.

De esto no ando mu puesto... ¿cómo es eso de que con las MV no se necesita programar en hilos?
Por otra parte... ¿a qué te refieres con "programar de fondo" y por qué prefieres C++?

Rurouni escribió:En el anterior hilo decías que querías hacer un "PCFurgo"... DarkPython es ideal para tí... o al menos el concepto que yo tengo de lo que estoy haciendo que por ahora no es nada (no hay nada chachi que ver). Pero bueno... ya abriré un hilo sobre el tema.

Sabes que te leeré atentamente cuando hagas una mínima "release".
Sobre el motor que dices que me puede servir... te refieres para le juego en general, ó para la idea de poder jugar interactivamente los partidos? ¿Tan complejo lo estáis haciendo?

Rurouni escribió:Lo principal es dibujarte en un papel o sobre un lienzo de Gimp/DIA la estructura de todo lo que necesitas y como lo divides... y luego empezar a implementar.

Con estructura te refieres al tema módulos, clases, etc... ó a la estructura gráfica del programa? Si es lo primero, ¿no es más válido UML? Es que siempre me hace gracia que en casi ningún proyecto libre hecho en C++ se utiliza UML para nada... A veces siento que he perdido el tiempo aprendiéndolo (mínimamente, de todas formas).
Aún así, como te digo, primero tendría que decidir con qué lenguaje hacerlo y aprender un montóóóóóóóóóóón de cosas...
¿Cuánto crees que podría tardar en aprender lo básico sobre OpenGL como para colaborar algo en BomberGUM!? Supongo que si pudiera colaborar en mínimas cosas, al menos podría ir cogiendo la idea de cómo programar un juego, y además teniéndote a ti de maestro...
De C++ tendría que desempolvar un poco los conocimientos, pero bueno, no creo que me llevara mucho (sería sobre todo la parte de plantillas y tal...).

Rurouni escribió:Bueno, no tengo más tiempo ahora... nos vemos más tarde!

Buf! Mucho has dedicado ya, ¿qué más quieres? Aunque no sea quizá un alivio, que sepas que leo detenidamente todo para intentar pillarlo bien... jeje!
Sé que soy muy pesado con estas cosas también, así que tú tranquilo... Si un día me puedes responder algo lo haces, si te da pereza pues pasa, y si quieres mandarme a la mierda lo entiendo .

Muchas gracias por todo, en serio .

Salu2!

Ruro, te lo digo enserio, ¿no te has planteado escribir un libro? Fijo que te forrabas, por que entre lo que sabes y la paciencia que tienes con nosotros...

Mil gracias por estas infos tan valiosas

Salu2!

Rurouni escribió: Ruro, te lo digo enserio, ¿no te has planteado escribir un libro? Fijo que te forrabas, por que entre lo que sabes y la paciencia que tienes con nosotros..

Síp! es cierto... además eres un tío ameno, que dejas las cosas bastante claras... me parece una buena idea la de \-\adEs. Hala, que ya como te metas en el proyecto de escribir un libro no sé de dónde vas a sacar tiempo ni para dormir 4horas...

Salu2!

Esto... FF, que yo no es por joder... pero la cita es mia, no de ruro , que si, que no te discuto que me encantaria saber lo que el , pero me parece que te has pasado llamandole yo

Salu2!

FF y \-\adEs, !habéis conseguido ponerme colorao! ¡Gracias por vuestros alagos!

Sobre lo del libro: estoy escribiendo uno pero sobre accesibilidad multimedia... pero la editorial me ha dicho que me espere que estan echando cuentas a ver si pueden publicarlo. Solo llevo un 15%, así que si me dicen que no se publica iré a otra... y si al final no se acaba editando, no me moriré. Crear libros sobre desarrollo de juegos está difícil ya que se deben tocar muchos muchos temas que más que un libro necesitaría ser una colección completa de Stephen King después de una noche de depresión y drogas... Pero bueno, si sale bien DP me lo plantearé muy en serio. ¡gracias por vuestro apoyo!

Siempre que tenga tiempo contestaré lo mejor que pueda. Además... me he decido a no entrar en "discusiones de portada" que se pierde mucho tiempo, aunque hoy se están rifando tortas y me estoy aguantando (yo ya me entiendo).

Bueno, os contesto:

Estuve mirando lo de la GP2X a través de otro de los mensajes de BomberGUM! Tiene buena pinta, pero aún así creo que todos sabemos que se va a quedar con una cuota de mercado reducidísima... . Ojalá hubiera más proyectos así.

El éxito de una máquina lo decide su comunidad, no los que no a tienen. La GP32 ha sido un éxito rotundo. Se han vendido prácticamente todas las que se fabricaron. No hay nadie que se haya desilusionado, cada vez hay más gente que desarrolla juegos nuevos y originales, o portando software ya existente. Es la consola del Software Libre e Indy. Para mí la mejor portatil con diferencia, sin entrar en aspectos técnicos ni de cantidad de juegos comerciales. Si quieres scene... creo que es un poco chorra dar soporte a empresas que hacen todo lo posible por quitarte el derecho a hacer lo que quieras con un cacho de silicio que has comprado. Aunque, ellos lo han fabricado, ellos están en su derecho.

La máquina de Mono también corre Java, por lo que si se porta Mono a alguna plataforma, también se podrá correr Java en ella. No sé si lo sabías, pero puntualizo.
También, en un futuro, prentenden integrarse los ocmpiladores de Mono en GCC, al menos crear una extensión, por lo que supongo que también facilitará la tarea tanto para las distribuciones como para este tipo de menesteres.

Uhmm... puedes programar en JAVA utilizano el lenguaje, pero me parece que las librerías de estas (SWIG o AWT por ejemplo) no están disponibles. Es decir: no puedes desarrollar un applet que funcione en el JDK de sun no tiene que funcionar en Mono. O al menos eso era hasta ahora. Sobre lo de mono GCC, más bien harán la interfaz C# que falta para GCC, como se ha hecho con todos los lenguajes que soporta. C# es un gran paso, pero pierdes mucho control sobre la aplicación. Un juego lo que pide es control en muchos aspectos... no se hasta que punto estará optimizado. Se ha de comprobar. Luego te pondré enlaces de engines en .NET/Mono.

¿cómo es eso de que con las MV no se necesita programar en hilos?

Si. Si que se necesita programar utilizando hilos o threads para sacarle partido a las MV... lo que pasa que la MV en sí está optimizada para sacarle todo el jugo a los multiprocesador/core. Si no utilizas hilos, la mejora no será espectacular (o si, no lo he probado en la práctica), pero será mejora. En C++ o cualquier lenguaje compilado, en los cuales lo que has "compilado" (vaaalgame! la redundaaancia) un codigo concreto y así se queda hasta el fin de sus días (hasta que lo borras ), si no utilizas hilos no mejora nada, ya que la gestión de hilos la has hecho tu, y si no utilizas estos... solo utilizará 1 procesador. A ver... aquí entra todo el tema del S.O., si influye o no, si gestiona así o asá... pero no me voy a meter. Hablo de los programas que hacemos nosotros.

¿a qué te refieres con "programar de fondo" y por qué prefieres C++?

Con C++ o C o cualquier lenguaje compilado de bajo nivel tienes gran control sobre lo que haces. Hablas más directamente con la máquina. No hay intermediarios. La gente odia los punteros, por ejemplo, pero yo los empiezo a adorar. Que haya un Garbage Collector en los lenguajes basados en MV está muy bien para aplicaciones de escritorio y tal, pero no creo que sea lo más óptimo para sistemas en las que el tiempo real y la optimización de los recursos sea la principal premisa. Es una opinión personal.

Con estructura te refieres al tema módulos, clases, etc... ó a la estructura gráfica del programa? Si es lo primero, ¿no es más válido UML? Es que siempre me hace gracia que en casi ningún proyecto libre hecho en C++ se utiliza UML para nada... A veces siento que he perdido el tiempo aprendiéndolo (mínimamente, de todas formas).

Yo me refería a UML sip. Sobre lo de si los proyectos libres se utiliza UML o no es simplemente cuestión de organización. Por lo general, la gran mayoría de programas que siguen la filosofía del SL o del OpenSource siguen la filosofía UNIX: un programa que hace un trabajo, pero que lo hace bien. Generalmente, si haces un solo trabajo (o dos o tres) no necesitas mucha planificación, sólo tener las ideas claras y saber programar bien.

En el caso en el que nos encontramos es algo diferente. Tienes muchísimas partes: gráficos, red, sonido, periféricos... dentro de gráficos tienes OGL 2D y 3D, cargar mayas, reprensentar escenarios, representar objetos y personajes... dentro de cargar mayas tienes X3D y Cal3D... dentro de representar escenarios tienes BSPs, Octrees, Quadtrees... (saltamos todo lo que hay dentro de gráficos, y seguimos con el siguiente punto... a esto se le llama BackTracking xD); en red tememos TCP/IP, Jabber, http, el nuestro propio... y así con todos. O te organizas muy bien, o te puedes perder. Que mejor que seguir los estándares! UML es una técnica "estándard" y tenemos herramientas como DIA que nos ayudan en la creación de organigramas. Dejan claro la estructura de nuestros programas, asenta las bases y ayuda a saber donde están los límites de nuestro trabajo y el de los demás.

Utilizarlos o no, es cosa de los desarrolladores... nadie obliga. Mi opinón es que para un juego mínimamente complejo se deben realizar. Empezando desde más arriba (estructura básica) y luego ir bajando en cada nodo o punto hasta llegar al momento de especificar funciones e implementar.

Aún así, como te digo, primero tendría que decidir con qué lenguaje hacerlo y aprender un montóóóóóóóóóóón de cosas...

Los desarrollos no suelen ser así... primero se ve el problema (un juego de fúrgo), se secciona en subproblemas (gráficos, IA...) y luego se decide el lenguaje. Aunque cuando se está empezando suele ser al revés: quieres aprender un lenguaje, así que piensas algo que hacer

¿Por qué he comentado anteriormente que DP podría serte muy útil? para programar juegos no tienes porqué saber programar necesariamente en OpenGL o música o red... puedes especializarte en IA o cualquier cosa. DP es un entorno y un engine... en el que se intentará que el usuario se despreocupe de si se tiene que optimizar tal o cual rutina gráfica o de audio... se darán unas implementaciones (lo más óptimas posibles) y se simplificarán procesos. Así que lo único que se tendrá que hacer es pensar en lo que quiere que haga su programa y dedicarse a eso. Da igual si estás en un SO o en otro. Da igual OpenGL o SDLSurfaces... el usuario solo programará lo que tenga que programar. Y modelará lo que tenga que modelar. Python es un lenguaje muy claro y potente, unido a un engine de fondo bien optimizado, será muy práctico para crear sin tener que "implicarse" con cosas que no interesan y hacen aburrido un desarrollo.

¿Cuánto crees que podría tardar en aprender lo básico sobre OpenGL como para colaborar algo en BomberGUM!? Supongo que si pudiera colaborar en mínimas cosas, al menos podría ir cogiendo la idea de cómo programar un juego, y además teniéndote a ti de maestro...
De C++ tendría que desempolvar un poco los conocimientos, pero bueno, no creo que me llevara mucho (sería sobre todo la parte de plantillas y tal...).

OpenGL es complejo... yo siempre digo: ¿realmente necesitas aprender a programar OGL o D3D? Puedes colaborar en el sistema gráfico sin necesidad de tener idea de OGL. ¿Cómo? Implementando rutinas de optimización espacial por ejemplo (BSPs, Octrees...). Obviamente, no estoy diciendo que no aprengas OGL es muy interesante y gratificante... pero quiero que entendais que los juegos no son únicamente entornos gráficos (a todos los que teneis PlayStation 2: Buscar por internet "Katamari Damacy" y sabreis de lo que hablo, im-presionante).

En DP hay muchas partes y subpartes... puedes escoger una.

Por cierto, hago un anuncio aquí: voy a dejar mi trabajo para dedicarme a mis proyectos tanto comerciales como no... ya que he logrado un volumen tal que puedo vivir como autónomo. Tengo muchas esperanzas en DP como proyecto libre.

Bueno... vuelvo a daros las gracias por los alagos y el apoyo. Nos vemos más tarde!!!

Si haces el favor Ruro, cuando salga (si sale, que esperemos que si) ¿puedes avisar? Por que seguro que es un libro bastante bueno y que merezca la pena tener a mano

Salu2!

Rurouni escribió:Esto... FF, que yo no es por joder... pero la cita es mia, no de ruro , que si, que no te discuto que me encantaria saber lo que el , pero me parece que te has pasado llamandole yo

Wops! Es que se me quedó en los dedos después de tanto poner citas de Ruro... ups!XD.

Rurouni escribió:FF y \-\adEs, !habéis conseguido ponerme colorao! ¡Gracias por vuestros alagos!

Sobre lo del libro: estoy escribiendo uno pero sobre accesibilidad multimedia... pero la editorial me ha dicho que me espere que estan echando cuentas a ver si pueden publicarlo. Solo llevo un 15%, así que si me dicen que no se publica iré a otra... y si al final no se acaba editando, no me moriré. Crear libros sobre desarrollo de juegos está difícil ya que se deben tocar muchos muchos temas que más que un libro necesitaría ser una colección completa de Stephen King después de una noche de depresión y drogas... Pero bueno, si sale bien DP me lo plantearé muy en serio. ¡gracias por vuestro apoyo!

No, en seiro, siempre lo he pensado. Estoy harto de libros coñazo que te cuesta dios y ayuda metértelos para aprender algo... Conociéndote, seguro que lo hacías ameno, creando ansias de aprender en el lector pero sin ningún esfuerzo. Lo que pasa que con todo en lo que andas metido... Suerte con el que estás haciendo ahora! Y sí, ya nos avisarás si sale. Si no te sale editorial siempre puedes hacer como Bruce Eckel. No parece que le haya ido mal publicando libre.

Rurouni escribió:Siempre que tenga tiempo contestaré lo mejor que pueda. Además... me he decido a no entrar en "discusiones de portada" que se pierde mucho tiempo, aunque hoy se están rifando tortas y me estoy aguantando (yo ya me entiendo).

Creo que sé por donde vas... . De todas forams es admirable la paciencia que tienes con gente como por ejemplo... yo!

Rurouni escribió:El éxito de una máquina lo decide su comunidad, no los que no a tienen. La GP32 ha sido un éxito rotundo. Se han vendido prácticamente todas las que se fabricaron. No hay nadie que se haya desilusionado, cada vez hay más gente que desarrolla juegos nuevos y originales, o portando software ya existente. Es la consola del Software Libre e Indy. Para mí la mejor portatil con diferencia, sin entrar en aspectos técnicos ni de cantidad de juegos comerciales. Si quieres scene... creo que es un poco chorra dar soporte a empresas que hacen todo lo posible por quitarte el derecho a hacer lo que quieras con un cacho de silicio que has comprado. Aunque, ellos lo han fabricado, ellos están en su derecho.

Como tú bien dices, depende de si te importa tanto la scene ó no... Porque por número de unidades vendidas no creo ni que se acerquen, aunque igual me equivoco. Aún así yo soy poco de consolas portátiles... así que es un mundo que, egoístamente, me importa menos.

Rurouni escribió:Uhmm... puedes programar en JAVA utilizano el lenguaje, pero me parece que las librerías de estas (SWIG o AWT por ejemplo) no están disponibles. Es decir: no puedes desarrollar un applet que funcione en el JDK de sun no tiene que funcionar en Mono. O al menos eso era hasta ahora.

Realmente... no llego a tanto. Seguramente sea así, porque implementarse todas esas librerías debe ser... puf! Sinceramente, no creo que lo hagan... Aunque ay digo que ni idea.

Rurouni escribió:Sobre lo de mono GCC, más bien harán la interfaz C# que falta para GCC, como se ha hecho con todos los lenguajes que soporta.

Bueno, así quedará todo más integrado... .

Rurouni escribió:C# es un gran paso, pero pierdes mucho control sobre la aplicación. Un juego lo que pide es control en muchos aspectos... no se hasta que punto estará optimizado. Se ha de comprobar. Luego te pondré enlaces de engines en .NET/Mono.

¿Podrías describir brevemente qué tipo de control necesitas en un juego que no te de C#?
Por otra parte, he estado mirando cosillas de desarrollo de juegos con .Net/Mono y ya van saliedo cosillas. Hay algún que otro motor en desarrollo. Efectivamente la crítica que se le hace a eso es la falta de control y optimizaicón. Sus defensores, asímismo, predican que con las incoporaciones hechas a C# (y que serán presentes en .Net/Mono 2.0) la optimización alcanza cuotas bastante mayores. Habrá que verlo. Intentaré buscar más información sobre esto. A ver si no acabo escribiendo al mismísimo de Icaza .

Rurouni escribió:Si. Si que se necesita programar utilizando hilos o threads para sacarle partido a las MV... lo que pasa que la MV en sí está optimizada para sacarle todo el jugo a los multiprocesador/core. Si no utilizas hilos, la mejora no será espectacular (o si, no lo he probado en la práctica), pero será mejora. En C++ o cualquier lenguaje compilado, en los cuales lo que has "compilado" (vaaalgame! la redundaaancia) un codigo concreto y así se queda hasta el fin de sus días (hasta que lo borras ), si no utilizas hilos no mejora nada, ya que la gestión de hilos la has hecho tu, y si no utilizas estos... solo utilizará 1 procesador. A ver... aquí entra todo el tema del S.O., si influye o no, si gestiona así o asá... pero no me voy a meter. Hablo de los programas que hacemos nosotros.

Por esa parte sería un punto a favor de C#, pero es como siempre, habrá que ver si compensa.
En el caso de C/C++ ... habría que reprogramar para 1procesador, 2 procesadores... etc? Cómo de complejo es ó sobre todo, cuánto tiempo adicional puede suponer eso en un juego profesional?

Rurouni escribió:Con C++ o C o cualquier lenguaje compilado de bajo nivel tienes gran control sobre lo que haces. Hablas más directamente con la máquina. No hay intermediarios. La gente odia los punteros, por ejemplo, pero yo los empiezo a adorar. Que haya un Garbage Collector en los lenguajes basados en MV está muy bien para aplicaciones de escritorio y tal, pero no creo que sea lo más óptimo para sistemas en las que el tiempo real y la optimización de los recursos sea la principal premisa. Es una opinión personal.

Igual que antes (y que n es por ponerlo en duda sino por saber el qué), si me puedes describir brevemente cosas sobre las que no puedas tener el control con C#...
Yo, hasta el momento, y será por lo poco que he programado, no tengo problemas con los punteros, no me disgustan.
El Garbage Collector, si no recuerdo mal (miraré enlaces a ver) se puede desactivar si no quieres quitar esa parte de rendimiento. Aún así, parece que por lo menos en Mono, es bastante eficiente. Pero claro, menos rápido que sin colector de basura seguro que es. Pero ya digo... por una parte creo que se están preocupando de dar bastante libertad al programador en esas cuestiones: posibilidad de quitar el colector, posibilidad de compilar a nativo el código, posibilidad de usar C/C++ directamente, lenguajes con punteros ó sin ellos... Dentro de las limitaciones de los lenguajes basados en una MV, pienso desde mi perspectiva que van a hacer un buen trabajo en cuanto a optimización.

Rurouni escribió:Yo me refería a UML sip. Sobre lo de si los proyectos libres se utiliza UML o no es simplemente cuestión de organización. Por lo general, la gran mayoría de programas que siguen la filosofía del SL o del OpenSource siguen la filosofía UNIX: un programa que hace un trabajo, pero que lo hace bien. Generalmente, si haces un solo trabajo (o dos o tres) no necesitas mucha planificación, sólo tener las ideas claras y saber programar bien.

Me alegra saber que lo poco de UML que aprendí, quizá sirva para algo... . Tampoco entiendo que no se utilice más si con las modernas herramientas de UML, te generan código a partir de los esquemas, que da gusto.

Rurouni escribió:(saltamos todo lo que hay dentro de gráficos, y seguimos con el siguiente punto... a esto se le llama BackTracking xD)

XDXD Cuabronsete... .

Rurouni escribió:¿Por qué he comentado anteriormente que DP podría serte muy útil? para programar juegos no tienes porqué saber programar necesariamente en OpenGL o música o red... puedes especializarte en IA o cualquier cosa. DP es un entorno y un engine... en el que se intentará que el usuario se despreocupe de si se tiene que optimizar tal o cual rutina gráfica o de audio... se darán unas implementaciones (lo más óptimas posibles) y se simplificarán procesos. Así que lo único que se tendrá que hacer es pensar en lo que quiere que haga su programa y dedicarse a eso. Da igual si estás en un SO o en otro. Da igual OpenGL o SDLSurfaces... el usuario solo programará lo que tenga que programar. Y modelará lo que tenga que modelar. Python es un lenguaje muy claro y potente, unido a un engine de fondo bien optimizado, será muy práctico para crear sin tener que "implicarse" con cosas que no interesan y hacen aburrido un desarrollo.

Llámame masoca, pero a mí, tranquilamente, me gustaría ir aprendiendo sobre "las tripas" de un juego. El tener un motor así disponible es la leche, pero con el tiempo (y me refiero a muuucho tiempo) me gustaría ir más allá.
Sobre DP... va a servir lo mismo para hacer un partido de fútbol interactivo, que un shoot'em up, que una aventura gráfica? Por lo que he leído eso es poco menos que una utopía... por eso te preguntaba si para mi propósito valía ó si va dedicado a otros menesteres dentro de los juegos.
Python no es interpretado? ¿Por qué no hacer la interfaz en C/C++?

Una última pregunta sobre estas cosas... ¿a largo plazo no sería mejor/más práctico unificar OpenGL,SDL y OpenAL en una sóla API? Lo digo porque creo que así sería más fácil competir con DirectX, al estar todo unificado.

Rurouni escribió:Por cierto, hago un anuncio aquí: voy a dejar mi trabajo para dedicarme a mis proyectos tanto comerciales como no... ya que he logrado un volumen tal que puedo vivir como autónomo. Tengo muchas esperanzas en DP como proyecto libre.

¿Dejas las clases en la universidad? Mierda... al final no tuve tiempo de pasarme por allí y colarme en alguna . Bueno, sea como sea, me alegro de uqe las cosas parezcan irte tan bien. Eres un tío cualificado y que llevas bastante curro a tus espaldas; sin duda un seguro de calidad (quieres contratarme de RRPP?XD). Bueno, ya sabes que desde aquí seguiremos tus proyectos libres (y los no libres si nos los quieres mostrar también, por supuesto). Suerte, que la vida de autónomo puede ser muy gratificante pero también un poco puñetera.

Mil cenkius por tó!
Salu2!

FF escribió:cita de Rurouni:
Esto... FF, que yo no es por joder... pero la cita es mia, no de ruro , que si, que no te discuto que me encantaria saber lo que el , pero me parece que te has pasado llamandole yo
Wops! Es que se me quedó en los dedos después de tanto poner citas de Ruro... ups!.

Espera.... esto va enserio? Tio haces pleno!!!! 2 de 2

Salu2!

No tonto, ésta ya era coooñaaa!!!XD. Pensé que lo pillarías !

Eso te pasa... por vacilar! ja! .

Saludines!

FuckingFreaky escribió:No tonto, ésta ya era coooñaaa!!!XD. Pensé que lo pillarías !

Eso te pasa... por vacilar! ja! .

Saludines!

Que cabr... Esque me has pillado espeso, mañana examen de tecnologia (putos motores y la madre que los pario ) asique imaginate. Si hubiese sido suerte, tio, hechabamos la quiniela que contigo nos tocaba fijo

Salu2!