Busco información sobre cual es la mejor manera para desarrollar una aplicación en la que los usuarios puedan programarse funciones que controlen el comportamiento de elementos del entorno pero de manera que el sistema pueda tener un control sobre ese codigo.

Basicamente es un sistema de scripts, para que los usuarios puedan programar el comportamiento de sus personajes. Interesa que sea potente y que la sintaxis sea lo más parecida a C++ posible.

Obviamente tiene que estar supervisado por el sistema para que mi aplicación pueda controlar que los programas no excedan determinada cantidad de memoria, para que no llamen a funciones externas a la aplicación pero sobretodo para controlar la cantidad de instrucciones que ejecuten y el tiempo que inviertan.

Así se podría crear un juego de lucha entre bots con igualdad de condiciones (no sería valido haciendo que cada uno aportase su DLL ya que no se podría controlar lo que sucede dentro).

He pensando en programar un lenguaje de scripts propio, o tal vez usar LUA o python, que me decis? Permite alguno de esos lenguajes el control de la ejecución?                                

                                Pues porque la luz difusa y la especular tienes propiedades distintas a la hora de mostrarse, no hablamos de un parametro generico, hablamos de iluminacion, y como sabreis la iluminacion se ve afectada por por la inclinación de un plano (su normal en cada vertice).

La diferencia entre luz difusa y especular es la siguiente.

La luz difusa es aquella luz que se ve afectada por la dirección en que la luz incide sobre el poligono con respecto a su normal. Por ejemplo, supongamos que tenemos un cuarto oscuro con un unico foco de luz en el techo y ponemos un libro plano sobre una mesa en mitad de ese cuarto. La cara superior del libro quedara totalmente iluminada, sin embargo si vamos inclinando poco a poco esa tapa del libro veremos como poco a poco se va oscurenciendo, y una vez la tenemos perpendicular a la mesa deberia estar oscura (sin contar radiosidad).
Eso en infografia se hace mediante la normal en cada vertice de un poligono, para asi obtener esos efectos de sombreado en las caras en las que la luz no incide.

La luz especular ademas de tener en cuenta la inclinacion del plano tambien tiene en cuenta la posicion del espectador con respecto al poligono. Sirve para dar la sensacion de que una superficie es reflectante, como metalica. Para ello cuando iluminas el vertice miras si la camara se encuentra en la recta reflejada en el punto de contacto con el poligono del vector de la luz.

Algo semejante a esta imagen:


Si la luz parte del principio del vector amarillo y el ojo está en alguna posicion del vector azul pues se ilumina con luz especular, sino no.

Creo que deberiais mirarte mejor el tema de la iluminacion, vectores, materiales y propiedades para así poder comprender mejor como modelan los sistemas de render el efecto de la iluminación.

Espero que esa fuera tu duda.                                

                                Aprovechando este post me gustaria plantear una duda.

Hace poco pensaba en un juego en el que pilotases una nave con una vista desde dentro, mi idea era renderizar el terreno con unos near/far adecuados y despues hacer un borrado del zbuffer para despues renderizar la cabina, de este modo la cabina puede tener más precision.
Sin embargo hace poco vi que las nuevas tarjetas incorporan una opcion de Fast Depthbuffer Clean, lo cual me hace pensar que borrar el zbuffer tiene que ser lento de por sí. Alguien sabe si se nota?                                

                                Si por selección de elementos te refieres a detectar que objeto se encuentra en una determinada coordenada de la pantalla hace tiempo leí una manera que me pareció muy inteligente aunque solo es aconsejable si dicha selección se produce pocas veces (como cuando clickas con el raton) y no constantemente (encuadrar un objeto de la pantalla).

El sistema consistia en asignar a cada objeto un color diferente, y cuando quieres saber que objeto hay en una coordenada de la pantalla simplemente renderizas la escena sin iluminacion ni texturas ni efectos, solo renderizando los objetos con su color asignado, vas a la posicion que te interesa del colorbuffer y pillas el color de ese pixel, y finalmente haces un clear del buffer (no un swapbuffers o te mostraria por pantalla un frame basura).

Despues con el codigo de color del pixel te vas al lugar donde tengas indexados todos los objetos y miras a cual corresponde. Parece un poco costoso pero no lo es tanto si tenemos en cuenta que hablamos de perder un unico frame y lo mejor es que al estar renderizado sin luz ni texturas consume una cuarta parte del tiempo de un frame corriente, algo despreciable.

Yo lo tengo pensado implementar para el control de la cabina de una nave para que puedas pulsar sobre los diferentes botones.

Por otra parte si lo que quieres es marcar la posicion en pantalla de un objeto constantemente no te quedará más remedio que proyectar el punto en 2D mediante las matrices de proyección, yo lo usaba para hacer lens flares, pero dado que no podras proyectar todos los vertices pues no sirve para tener precision al pixel de un objeto.

Siempre puedes optar por usar el primer sistema renderizando cada X frames uno planoy usandolo. O incluso se podría hacer un hibrido, quien sabe...                                

                                Pues a mi me parece un patron bastante interesante, vale que a nivel de funcionalidad sigue siendo lo mismo que un singleton pero te ahorra la parte de GetInstance(), eso si, tienes que declarar uno a uno todos los atributos como staticos.                                

                                Era solo proponer la creación de un foro destinado a la programación de la parte destinada al movimiento de los elementos en el entorno de juego, eso incluiria fisica, dinamica del solido rigido, colisiones, bounding boxes, elasticidad, etc.

Creo que es algo muy complejo de lo que todos tenemos mucho que aprender o enseñar y que mejor que un foro propio.                                

                                Sobre el tema de usar IRC como protocolo base, me parece un tanto salvajada, primero porque estas sujero a las especificaciones de un protocolo no ideado para el transito de datos complejos, un texto bien puede llegar con un segundo de retraso y no suponer un problema pero cuando hablamos de combates en tiempo real la cosa cambia.

No olvidemos que un MMORPG ademas de enviar texto debe enviar la posicion de los personaes y si quieres que sea medianamente seguro debes hacer que los datos del entorno (edificaciones, items) no esten en el cliente sino que se envien conforme el usuario los tiene en su linea de vision, esto eleva el trafico una barbaridad pero garantiza que el usuario no tenga acceso a informacion restringida.

Sobre lo de que tienes servers gratis, sips, los tienes pero ten en cuenta que esos servers no toleraran más de X mensajes por cliente a la vez, de lo contrairo lo considerarian flood, lo mismo sucederá con splits y demás.

Si tu idea es la de ahorrarte la parte de programar un servidor utilizando uno de IRC creo que lo que te ahorres de trabajo por un lado lo tendras que invertir por otro en adaptarte.

Mi sugerencia es que aisles la parte de conexion lo suficiente para que por ahora lo puedas implementar sobre TCP y si mas adelante te apetece optimizarlo optes por implementar tu propio protocolo con conexion sobre IP o UDP.                                

                                Yo soy muy reasonero y creo que es la mejor opcion para las composiciones tanto electronicas como instrumentales, la gente se asusta por su interfaz pero creo que es la mejor baza ya que se trata de un programa que no te oculta nada, lo que ves es lo que hay, lo cual aligera mucho el aprendizaje y el uso. Un ejemplo de ello es el sistema de conexion por cables lo que ademas de ser muy vistoso es muy transparente.

No se trata de un tracker, es un secuenciador que permite importar MIDIs. No permite trabajar con tracks de audio como Logic o Cubase aunque puedes lanzar samples del tamaño que quieras.

No permite importar VSTs ni ningun tipo de plugin pero con lo que trae de serie tienes más que suficiente (filtros, sintes, samplers, cajas de ritmos...).

Personalmente creo que los trackers estan muy desfasados, vale que en buenas manos siempre daran buenos resultados pero creo que todo compositor debe dar el salto de la composicion por patrones a la composicion por pistas.