Apricot the open game project

[SamCameron]

Klopes, lo que tú dices de mandarle posiciones mediante script ya lo había pensado, y no necesitas necesariamente un script, puedes meterle datos mediante properties, además vosotros habláis de emplear este actuador en multitud de objetos y todo eso, pero yo las veces que lo he necesitado han sido para unos pocos objetos concretos o para movimiento pre-calculados, pero necesario es casi siempre, luego veo más rápido seleccionar el actuador y conectarlo que tener que ponerme a escribir código, podéis decir que os gusta más escribir código o que pierde la gracia o que el sol brilla en california, pero no podéis decir que sin este actuador podéis hacer lo mismo de forma tan rápido como serían un par de clicks, sobre todo para una tarea tan repetida y necesaria en cualquier desarrollo de un juego.

Posdata: no tengo miedo al código ya que he utilziado antes Darkbasic y Blitz como mencionaba, pero cuando descubrí Blender pensé que ya no necesitaría escribir código casi, parece que me equivocaba si la gente sigue pensando así.

[Caronte]

Sobre todo para una tarea tan repetida y necesaria en cualquier desarrollo de un juego.

¿puedes poner ejemplos? Es que no lo veo como algo muy usado.

[Klópes]

A ver. ¿me quieres decir de verdad que usando un actuador te va a salir más sencillo que esto?

-- IMÁGENES ADJUNTAS --

[SamCameron]

Si Klópes.

[Klópes]

Vaya, bueno, no sé qué decir. Quizá tengas razón y cuando lo implementen puedas decirnos cómo.

[Caronte]

Lo que el quiere decir, es que con su método tardaría 15 segundos y con el tuyo, tardas 30, lo cual es una barbaridad.

[Pepius]

Vale, es lícito admitir que eso sería mínimamente más rápido. Si aun así, admitiéramos que ese lapso de tiempo influiría en algo, aún esta la cuestión de que hay 1.000 cosas más importantes por hacer antes que eso. Un saludo.

[SamCameron]

No solo sería más rápido sino que para los no iniciados en programación también sería más amigable y a veces olvidas lo que tienes que poner, luego tienes que dedicar un tiempo a buscar los comandos, esto lo hace más sencillo si tenemos un actuador al alcance de la mano siempre que lo necesitemos para una tarea tan común como la que realiza, al fin y al cabo, no hablamos de un actuador tipo crear Tomb Raider o crear Doom 3 sino que es una herramienta muy ultilizada, por lo que cuanto más a mano mejor. Algo así seria.

-- IMÁGENES ADJUNTAS --

[Klópes]

Bien, pero haces algo de trampa. El uso de propiedades a ese nivel implicaría utilizarlas al completo en todo el engine. O sea, ¿ponemos un campo prop debajo de cada entrada numérica? No es descabellado, desde luego, pero habría que ver hasta qué punto es amigable un entorno así.

El ge está orientado a otra forma de trabajo, una mezcla entre ambos sistemas: bloques y código. Y tender a sustituir el código por logic bricks hace que un proyecto se complique innecesariamente. Digamos que en algún punto hay que cortar. Y creo que donde hoy se corta es el punto correcto. De hecho, la experiencia de Apricot es invalorable para esto.

Por último, un comentario sobre el método tuyo: para hacer lo que quieres has utilizado 3 propiedades. Sólo hay dos formas de modificarlas: por código y con el disparador property, que, por sí solo no puede hacer grandes cosas. Para algo tan sencillo como lo que dice Pepius (sacar el valor medio) necesitas código.

Creo que no te he convencido mucho, es un tema muy general y tendríamos que tirarnos ejemplos a la cabeza, pero yo lo tengo bastante claro: en su día también llegué a pensar que ese disparador debía existir, pero al ver lo sencillo que era hacerlo con líneas, y que para hacer un juego mínimamente serio hace falta programar mucho, vi que cuantos menos bloques, mejor. Un saludo.

[SamCameron]

Según la última entrada en el blog de Apricot, se han echado atrás y no van a ser lo que dijeron sino algo mucho más sencillo y limitado, vaya que lástima, ojalá alguien retome su trabajo.

[Mataii]

Según la última entrada en el blog de Apricot, se han echado atrás y no van a ser lo que dijeron sino algo mucho más sencillo y limitado, vaya que lástima, ojalá alguien retome su trabajo.

Creo que una cosa es echarse para atrás, y otra es ser claro y decir como están las cosas.

Tu mismo puedes retomar la parte que quieras, hacer un nuevo nivel, lo que se te antoje, ahí tienes todos los recursos que necesitas, contando con el más valioso y que hizo falta para el proyecto Apricot (tiempo).

[Klópes]

Últimamente he probado unas escenas en el ge y me quito el sombrero con las optimizaciones que ha hecho esta gente. Primero, una escena con algo menos de 200.000 polígonos, al pulsar p en la versión oficial, se quedaba extasiado durante aproximadamente, medio minuto (no recuerdo cuanto) antes de ejecutar el juego. En la compilación Apricot comenzaba al instante.

Ahora estoy con una escena donde hay unos árboles con hojas y sus clipmaps, al estilo del juego. Bien: en la versión oficial me da un rate máximo de 3 fps. En la compañero de Apricot (y también en la SVN) alcanza los 60 fps.

Realmente, parece que no le influyan los canales alfa.

Bravo.

[lordloki]

Están haciendo pruebas de rendimiento con distintas tarjetas. Si podéis poner vuestros resultados seguro que os lo agradecerán.

[Klópes]

Y documentación del GLSL. blender.org - Realtime GLSL materiales.

[Bluder]

Vaya funciona que da gusto, para pintar sobre el modelo te ahorra muchas pruebas.