Hash?, hilos? creo que me equivoque de foro... Ah no si es este. Creo que os estais pasando un poco
Lo de la matriz que comentas, es como lo tenemos pensado, solo que en lugar de tener una lista con las unidades, cada vez que una unidad se mueva actualiza en matriz[x][y] un "contenedor" (matrix[x][y].updateContainer o algo así.) De esa forma, usando matriz[x][y].getEntity().getProperty("health") podemos acceder a la propiedad "health" de la entidad de la posicion (x, y)
Acceder por hashing a las propiedades ya lo he planteado, pero creo que con la cantidad de accesos a las propiedades que hay, es perder un monton de ciclos. En lugar de con strings, con ids debería ir mil veces más rápido y es mucho menos problema.
Lo de relacionar sonidos con acciones lo he pensado de otra forma que creo que añade más flexibilidad. Simplemente desde el script, cada vez que se quiera llamar a un sonido se hace sound.play("/sounds/sonido.mp3") y punto. No es tanto trabajo, al contrario, y es mucho más flexible que hacerlo por XML (Aquí el sonido suena cuando quieras exactamente.) El problema es que aún no he explicado muy bien cómo tengo pensado el sistema de eventos del motor y tal, mañana lo explico mejor (O subo una conversación que he tenido con Juanaka.)
Y lo de los hilos... no hace falta para los sockets (Conviene tener un hilo por ejemplo del sonido) porque se pueden hacer conexiones no-blocantes (Al menos en UNIX, no sé en Win32.)
La SDL ya se encarga de gestionar el sonido adecuadamente. Y tb tiene soporte para red. Seria conveniente echarle 1 vistazo
No sé si SDLNet tiene sockets no-blocantes, por eso no comenté nada.
Sonido: http://kekkai.org/roger/sdl/mixer/index.html
http://kekkai.org/roger/sdl/rwops/rwops.html <- Justo esto estaba buscando, cargar archivos de memoria. ¡Buenísimo!
http://gpwiki.org/index.php/Category:All_SDL_articles <- Como Enginuity, hay que leerlo, simplemente. Sobre todo por este magnífico tutorial sobre el framework de un motor. Además, este tutorial creo que es básicamente lo que nosotros vamos a hacer, sin scripting.
Por cierto Juanaka, http://aedgui.sourceforge.net/ y http://libagar.org/. Efectivamente, ya estaba hecho xD
¡Seguimos necesitando ayuda con el análisis del diseño!
para lo de que nos admitan como developers en sourceForge.net y osoy blzkz y no se como hacerlo xD
Por cierto no me puedo pasar por el irc hasta el lunes que viene sorry 
pero sí me gustaria ir informandome, si podeis subir los logs seria de gran ayuda xD
En cuanto a sockets yo tengo escrito en C una casa de apuestas cliente - servidor, multiusuario, orientado a conexion(TCP). Sin forks(). Solo que eso en windows no va, solo va en unix.
En windows debo tener por ahi otro cliente-servidor pero mucho mas sencillo, no era multiusuario.
En cuanto a lo del patron observer, no creo que haga falta, ya que no Todo el mundo escucha un evento sino que solo 1 objeto es quien ha de recibir dicho evento. Lo que yo he pensado es , en tener en la clase Contenedor (yo la llame posicion antes) un par de atributos que son 2 funciones del script : void (* RightClick_ActionListener() ) y void (* LeftClick_ActionListener() ). Para que una vez detectado un evento, se obtenga el contenedor ( ingame ) , boton ( en gui ) para llamar a su correspondiente ActionListener.
Esto lo tengo que desarrollar un poco y comentarlo con los demas a ver... en cuanto a lo que puse antes pues... he cambiado bastante casi todo ya que ayer por la noche a eso de las 2 comprendi como funcionaban mejor el script con el motor. ^^
El Mapa al final habiamos quedado en que seria una matriz de contenedores, y el contenedor tendria informacion de las 3 capas : Terreno / Unidades Estaticas(No colisionadoras) y Unidades Movibles.
Lo que habra que hacer eficiente sera, la busqueda del contenedor/boton que ha sido pulsado, que por hash tendra su miga y por otro tipo de busquedas mezcladas con ordenaciones seria muy parecido.
Ya que tenemos una "x" y una "y" pulsadas, y cada contenedor tiene su "x inicial" "xfinal" "yinicial" "yfinal", tenerlo ordenado es una tonteria, de arriba a abajo y de izquierda a derecha seria lo logico ya que es mas ancho que alto.
Bueno en cuanto a la GUI , lo que he pensado es tener 2 clases, la clase GUI y la clase elemento, la GUI tendra una lista de elementos, y como metodos el constructor GUI() , addElement(elemento e ) y el "buscador" del que he hablado antes, lookForElement(x,y);
Elemento tendra muchas cosas,
int x,y; // posicion
void (* RightClick_ActionListener()); // si null -> no accion
void (* LeftClick_ActionListener()); // si null -> no accion
char url[max_long_url]; // url de la imagen si se desea.
int bgcolor; // por si no hay imagen
char nombre[max_long_nombre]; // not null
y metodos pues el constructor que inicializara y los get/set.
Weno espero q no salga muy tocho esto..
EDIT : Mierda #94 y yo matandome a pensar ! xD, de todas formas esas librerias son muy muy completas para lo que queremos hacer nosotros.
Me he perdido xDDD.
Te refieres a q como son cuadrados, todo elemento va a tener una X,Y de esquina superior izq y una Xfinal,Yfinal de esquina inferior derecha?
Si entras en el IRC mejor 
La clase de juanaka es muy buena, falta añadir un metodo iniciar para que la gui se dibuje en la pantalla y otro metodo para procesar los eventos del jugador (ejemplo: al pulsar un boton que aparezcan otros). Ah y tambien un metodo para hacer aparecer o desaparecer las imagenes de la pantalla, en este caso en la clase elemento.
Hasta ahora he leido poco pero ya me ire poniendo al dia.
Tambien he pensado que la clase mapa podria tener un metodo llamado MoverEntidad y que cuando se usara verificara si la entidad es movible y en caso de serlo actualizara la posicion de la entidad (posicion seria un atributo de la clase entidad) y mapa seria una matriz de los cuadrados del juego. O tambien podria cambiar los valores de la propia matriz en vez de tener que guardar la posicion de la entidad.
Sobre las cordenadas yo propongo transformar las cordenadas de pantalla en cordenadas sencillas (es decir, el numero de la columna y de la fila) con un bucle como 'si (5contador=<x) y (5(contador+1)=>x) entonces cordenada_simple_x = contador'. Me explico, el 5 es el multiplo que se podria usar para los cuadrados pero tambien se puede usar otro, y contador como ya sabeis aumentaria hasta que la condicion se cumpliera, la utilidad seria basicamente buscar un maximo y minimo que rodeara a las cordenadas de entrada. Lo mismo podria usarse para saber la fila.
#98 te refieres a la formula de conversión matriz-vector verdad? Pero de esta manera tienes que recorrer posiciones, lo suyo seria acceder con coste constante.
Edit: ya tenemos proyecto en sourceforge.
Project Descriptive Name: mediavida project
Project Unix Name: mv-project
CVS Server: mv-project.cvs.sourceforge.net
Shell Server: shell.sourceforge.net
Web Server: mv-project.sourceforge.net
Crearos las cuentas en sourceforge y postead vuestro UNIX name para que os vaya añadiendo.
Ya que estais decidme qué es lo que quereis aportar al proyecto para daros unos privilegios u otros, si todo el mundo somos project managers vamos a tener un lio del copón.
Quizas con [x-(x%5)]/5 se podria resolver facilmente. Lo unico que hace es restar el resto para que de un numero multiplo de 5 pero menor al inicial (x) y despues divide de 5 para saber el factor (la cantidad de celdas).
Ejemplo, [11-(11%5)]/5 = (11-1)/5 = 2.
Se ha hablado de que IDE usar. Yo uso Code::Blocks, y lo recomiendo, pero con usar cualquiera que soporte makefiles y tire de GCC (Aunque sea con MinGW) vale.
#98 La clase de juanaka es muy buena, falta añadir un metodo iniciar para que la gui se dibuje en la pantalla y otro metodo para procesar los eventos del jugador (ejemplo: al pulsar un boton que aparezcan otros). Ah y tambien un metodo para hacer aparecer o desaparecer las imagenes de la pantalla, en este caso en la clase elemento.
El metodo para que la gui se dibuje en la pantalla bien, el de procesar los eventos no, eso estaria en el script ( Funcion RigthClick_ActionListener y LeftClick.. ) . Aparecer y desaparecer son con addElement() y removeElement(), el de borrar me falto, que lo borras del objeto GUI y luego haces un refresh() , el refresh() vale como el metodo de dibujar, asique tampoco faltaria nada mas.
PD: Ayer hable con Soltrac y salio una idea de la que ya no me acuerdo para solucionar algo de lo que tampoco me acuerdo. Sube la conversacion si la tienes por ahi ! Que me fui al examen y claro.. ajajja se me olvido por completo todo lo que hable.
He pensado que la clase Mapa se llame Escenario, es un mejor nombre.
Hara falta pensar en el metodo de sincronizacion y protocolo de comunicacion.
La idea es la siguiente XDDD
15? 12 02Juanaka 12 Š lo de que estarian las propiedades duplicadas lo entiendes no ?
15? 12 02Juanaka 12 Š yo eso lo veo un problema porq ocupariamos mucha memoria
Soltrac 12 Š bueno duplicadas...te refieres a q se repetirian
Soltrac 12 Š un monton
15? 12 02Juanaka 12 Š sip
15? 12 02Juanaka 12 Š por eso casi es mejor, tener la clase propiedad
15? 12 02Juanaka 12 Š y que un mismo objeto propiedad
15? 12 02Juanaka 12 Š afecte a muchas entidades juntas
Soltrac 12 Š vamos a pensar
15? 12 02Juanaka 12 Š mira q solucion me ha salido ahora mismo xD
Es decir....q cada elemento no tenga las propiedades implícitas sino q sean relaciones con propiedades
Lo de #103 no lo veo bien (O lo he entendido mal.) Cada unidad debería tener sus propiedades. En el momento de la creación, leería los valores por defecto de la unidad de un XML (O de un script de AS, aunque el XML lo veo mejor) y pondría los valores en las propiedades. De esta forma, si una unidad coge un powerup, sólo ESA unidad tendría sus propiedades cambiadas. Lo mismo pasa con la vida. Es una propiedad de la unidad, pero cada unidad tiene su propia vida.
La cosa sería así:
- XML con las propiedades que existen (Para crear la clase.)
- XML con los valores de las propiedades de cada tipo de unidad.
- Se crea la unidad, se leen los valores del segundo XML.
- ????
- PROFIT!
El gasto de memoria no es tanto... y si lo es, mala suerte, es un juego, gasta memoria xD
Lo de los listeners, no sé si lo estoy entiendo mal, pero es que hay que tener en cuenta que se pueden definir más eventos que el click en el mapa (Click en botones, cosas como unidad-está-siendo-atacada, unidad-se-mueve, etc.) Creo que los eventos deberían definirse de antemano en una lista (Y a los clicks asignarles un "mapa" de click, como en HTML con los mapas en las imágenes.) Luego es sólo iterar por cada elemento y comprobar si el click está en el rango de click de ese elemento. (Eso sólo para los controles... para las unidades es sólo hacer una división por segmentos del mapa.) Si se superponen, pues debería mandarse el evento click a todo, aunque debería poder definirse una propiedad que sea blockClick o algo así, que haga que si se pulsa ese elemento sólo ese elemento reciba el click. Por ejemplo, para tener un botón arriba a la derecha de la pantalla que por ejemplo, pase el turno. De esta forma si debajo del botón hay una unidad, al pinchar el botón sólo realiza ese evento, y no llama al evento unit_click y tal.
SDLNet por lo que es visto es muy simplita de usar, y siendo multiplataforma viene de lujísimo. Las clases de GUI esas que puse antes pueden estar muy avanzadas, pero siendo opensource se pueden adaptar perfectamente.
Si la he cagado en algo, me acabo de levantar así que no razono bien xD
Supongo que si al verificar un click se da prioridad a la gui no pasara lo que dijiste kaod ya que solamente puede ocurrir el caso de que la gui este encima de una unidad y no al reves.
Los atributos los habra invariables y variables, es logico que solo los ultimos tengan que guardarse como variables miembro de la clase.
Sobre las clases de entidades he pensando que quizas podriamos crear una derivacion de una clase generica como por ejemplo Entidades. Si no me equivoco en el trozo de codigo que hice implementarlo de esta forma seria mas practico. Mi idea es que haya unas cuantas clases derivadas de Entidades como por ejemplo Edificios y Unidades, con metodos diferentes que puedan ser llamados desde los Listeners como por ejemplo la compra de una unidad, un powerup o cualquier cosa que podamos relacionar un boton de la gui con una funcion de la entidad (Asi queda mejor explicado).
Por otra parte tambien puede ser que la clase Entidades tenga metodos propios y compartidos por ambas clases derivadas (Edificios y Unidades), un ejemplo seria un metodo encargado de averiguar si hay unidades enemigas al alcance de su vision.
si he entendido lo que ha dicho #104, basicamente es una lista con propiedades, y cada una claroestá tiene un valor asignado. Entonces cada objeto solo tiene que tener valores que corresponden con la lista. Yo cuando iba leyendo el hilo pensé exactamente eso luego lei a #104 y dije joer como yo habia pensado. No creo que de esa manera se consuma mucha memoria o no tendria por qué :S
Lo he estado pensando y al final creo que no sera necesario derivar clases. En cuanto a las cordenadas me parece que habria que guardarlas en la clase Entidades ya que de no ser asi la entidad no podria determinar su campo de vision, y esa informacion es necesaria.
Me parece que los elementos (imagenes de la gui) al igual que los atributos de las unidades podrian reunirse en un xml, en el script o en un simple fichero de cabecera, eso como vosotros querais. Ademas habria elementos que se crearian mientras se juega, las unidades son un ejemplo. En tal caso al crear un elemento deberia indicarse el tipo y buscar ese tipo en el xml.
Otro caso es el que ocurre cuando al hacer click en la opcion de un menu debe aparecer otro, en tal caso propongo que en la clase GUI haya metodos para esas acciones (Menu(), Opciones() y mas) y entonces cada elemento tendria asignado un apuntador a ese metodo, asi seria mas facil manejar la interfaz.
Como no me aclaro con los programa de diagramas y no tengo mucha paciencia he hecho un pequeño resumen de lo que podria ser la base del diseño.
ERROR: No leer el primer parrafo, ninja edit de por medio.
#104 si basicamente es eso, solo que claro esta, si cada unidad tiene su propia lista de unidades, si hay muchas unidades habra un porron de propiedades.
Lo que yo digo en #103, es basicamente, poder asignar a cada unidad unas propiedades, cada unidad puede tener distintas, pero tambien pueden tener muchas unidades la misma propiedad. ¿ entiendes ?
De la otra forma, aunque muchas unidades tengan las mismas propiedades, estas estarian duplicadas, es decir tendrias 2 veces la misma lista de propiedades y las tratarias como si fueran distintas.
No se si me explico..., funcionalmente es lo mismo, solo que en vez de ser un struct, "propiedades" es una clase, entonces un objeto entidad tendra una referencia a un objeto propiedad, y varias unidades pueden compartir propiedades.
Ninja Edit ! : Ahora, mierda he visto un problema en esto conforme lo escribia, y es que al modificar el Valor de una propiedad cambiarias a muchas unidades y eso no es lo que se desea. Asi que mejor, se queda como bien dice #104
#109 la clase GUI no ha de tener un metodo que te muestre el Menu, tiene que tener metodos para poder diseñar una pantalla y enseñarla. Asi puedes inventarte tu menu y inventarte con los mismos metodos el menu de opciones, controles o lo que quieras. Explique en #96 una clase GUI pensada de esa forma.
En la clase Entidades, si solo pones el metodo de Accion la dejas un poco coja ( No puede hacer mas de lo que el motor diga), sin embargo, si haces que la clase entidad pueda llamar a metodos del script para realizar la accion que el script desee programar, puede realizar cualquier accion. Con eso y poder modificar las propiedades de la entidad que previamente el script haya definido, ya puedes manejarla.
Posteo sólo para avisar de que no se ha dejado de trabajar en el proyecto ni nada, sólo es un parón. Algunos de vacaciones, otros empezando el curso y otros preparándose, pero vamos, que volvemos (O eso espero xD)
Si, de hecho yo he estado un poco desconectado estos días porque son las fiestas de Oviedo. El domingo terminan y ya me pondré al día.
10 días después
Seria bueno que la gui se organizara en elementos y listas de elementos porque los menus son basicamente listas de botones y aparecen todos a la vez.
Hay otros casos en los que al aparecer un menu nuevo desaparece el anterior, por ejemplo cuando te mueves por los menus de una unidad.
Tambien hay otros menus que solo aparecen despues de haber pasado un tiempo como por ejemplo cuando estas esperando a que un edificio termine una actualizacion.
Ademas hay menus que desaparecen al deseleccionar un menu, sin ir mas lejos el menu de una unidad pero en cambio hay otros que no, un ejemplo seria cualquier menu de opciones o principal que estubiera superpuesto a la partida.
Para solucionar estos inconvenientes yo añadiria las variables Desaparecer y DesaparecerAlMostrar, la primera seria para que una lista de elementos desapareciera cuando se hiciera click fuera de ella (y a la vez todos sus submenus que esten en la pantalla) y la segunda para saber si hay que hacer desaparecer el menu cuando alguno de sus botones ha sido activado.
Ademas de todo esto cada elemento deberia incorporar un puntero hacia la lista de elementos que hay que mostrar.
Si más adelante tenga algo de tiempo quizás me meta a echar una mano y, principalmente, aprender.
Pero, leyendo el hilo y demás me ha dado un poco la sensación de que estáis empezando a construir la casa por el tejado. Estáis definiendo un huevo de cosas y todavía no tenéis ni un diseño del juego.
Lo primero es lo primero: saber lo que se quiere hacer.
Después ya habrá tiempo de decidir cómo se hace y hacerlo.
(A lo mejor me equivoco y ya tenéis todo el diseño definido, pero no es lo que he visto por el hilo. :\ )