Estructura de directorios

Actualmente tenemos:

¿Dónde colocamos otros recursos como imagenes, videos, texturas, sonidos, etc?

Propongo data, quedando:	- data
-------	- sounds
-------	-----------	- Music
-------	-----------	- efects
-------

etc.

¿Qué estructura tendrá el código?

Por evitar que se convierta en un cajon de sastre hay que discutir una estructura de directorios (y tal vez de bibliotecas) a seguir. Me gustaría iniciar la discusión antes de empezar a pasar código para que no nos suceda como en la estructura anterior en la que acaba apareciendo una carpeta foo con basura "por si aca".

Además de separar en carpetas Archetype, behaviors que es bastante clara, hay que aclarar ciertas dudas:

¿los pintadores van en una carpeta de Drawers o en una especifica de tecnología?

Si hay una carpeta de drawers, es posible que dentro de ella se cree una especifica de tecnología (drawers/SDL, drawers/OGL, etc...) y se repita una estructura similar en los que ejecutan sonidos (sounders?, players?).

Otra alternativa es que dentro de la carpeta OGL esté todo lo relaccionado con esta tecnología, encontrandose dentro pintadores y demas( OGL/drawers, OGL/sounders, SDL/drawers, etc).

O ignorar por completo la tecnología, pero no se si esto es buena idea.

Ya que la idea es que el motor sea muy modular (en un muy amplio sentido), ¿tiene sentido un directorio Core con lo básico del sistema?

Estoy pensando en una estructura (tanto para directorios como para bibliotecas) similar a la de OpenCV, donde hay una parte core con los tipos de datos básicos como cv::Mat y luego muchas bibliotecas para procesamiento de imagenes, calibracion de cámaras, detección de objetos, etc.

Actualmente tenemos una carpeta tools donde metemos tanto estructuras de datos (containers) como objetos y operaciones matematicas (vectores, calculo de la normal, etc.) como el systema de errores, o lectura de ficheros de configuración.

Considero que parte de esa funcionalidad es basica (core). Mi propuesta es:

| - core: Estructuras de datos, systemas para el motor como el de errores o de logs. | - math: Todo lo relaccionado con matematicas que será mucho. | - tools: leer ficheros de configuración por ejemplo.

Problemas:

Core esta pobremente definido, ¿por qué la lectura de ficheros no es core y si una lista de borrado rápido? Dentro de math posiblemente esté la parte encargada de las físicas en una subcarpeta. Tools potencialmente se puede convertir en una carpeta foo pero con nombre.

Opiniones.

Según yo lo veo:

Me parece adecuada. Como comentario, considero adecuado poner la carpeta "bin" como ignore para que nunca se suba su contenido.

Supongo que la parte compleja es el contenido de "src"

Yo, de momento, estoy manejando varias opciones, que pongo a modo de brainstorming:

Opcion 1:

Src como "core" con las carpetas comunes (Archetypes, behaviors, tatata..) y despues carpetas para cada tecnología, que internamente reproducen la estructura anterior, con las herramientas que aporta: src| | - Archetypes | - behaviors | - tatata... | - SDL | - - | - Archetypes (esta probablemente no este) | - - | - behaviors (esta puede) | - - | - drawers (esta sí) | - - | - tatata... ( : D ) | - OGL | - - | - Archetypes (esta probablemente no este) | - - | - behaviors (esta puede) | - - | - drawers (esta sí) | - - | - tatata... ( : D )

Opcion 2:

Inlcuir todo el código base en una carpeta core dentro de src y acompañarla de carpetas por tecnología como en el anterior caso. src| | - Core | - - | - Archetypes | - - | - behaviors | - - | - tatata... | - SDL | - - | - Archetypes (esta probablemente no este) | - - | - behaviors (esta puede) | - - | - drawers (esta sí) | - - | - tatata... ( : D ) | - OGL | - - | - Archetypes (esta probablemente no este) | - - | - behaviors (esta puede) | - - | - drawers (esta sí) | - - | - tatata... ( : D )

Estoy pensando en pros y contras.

Respecto a la carpeta "data", yo tenia en mente el nombre "resources", pero ese es como más recogido.

Sigo dándole vueltas a lo de "core, math tools". Ya os diré si se me ocurre algo.

Coooorrecto (me da lo mismo resources que data aunque quizá resources sea un poco más preciso... ¿o quizá media, o multimedia? cualquiera me vale).

Pintadores, sonadores (de mocos) etc.

Supongo que para mantener un poco ordenada la estructura es mejor crear una carpeta de Drawers, otra de Sounders (o quizá soundPlayers) y dentro las especificas de cada tecnología. Básicamente por que puede haber infinitas tecnologías, pero a parte de sonidos e imágenes ¿que más podríamos añadir en un futuro? ¿vídeos?... ¿olores? Además así se puede ver un paralelismo entre la estructura de src y la de data/resources/otros. Pero aquí hay más miga, porque puede haber arquetipos y behaviors relacionados con cada tecnología ¿no?. Supongo que en Archetypes, en Behaviors, etc. si es preciso habría que añadir también carpetas de cada tecnología.

tools, foo, math, core...

Esta es la parte difícil, sobre todo desde que cada uno habéis definido core de forma completamente diferente. Voy a divagar un poco:

Probablemente tengamos que hacer una carpeta, que posiblemente colgaría de SRC o de core, en la que se metería todo lo relacionado con lectura y escritura de ficheros, redes, cámaras, impresoras y demás hostias en vinegar. O quizá se podría hacer una separación, una para lo más básico (redes y disco) y otra para cámaras y cosas de esas que van con cables que se ven aunque tu torre no sea transparente. Sigo sin tenerlo muy claro por que ¿por que no iban a ir en esta carpeta también imagen y sonido?

Pero si creo que debería haber cierta relación entre las estructuras de datos y las matemáticas, aunque no estén "juntas", creo que cosas como el manejo de errores y logs deben estar "más lejos". Lo malo es que no se me ocurre un nombre para agrupar Math y containers...

Errores y logs si los metería en core, aunque por ejemplo logs hablaría continuamente con la parte de ficheros que estaría en El Otro Lado (chan chaaaan).

Por otro lado, yo la carpeta foo no la veo mal, si no me equivoco no es una carpeta donde metemos lo que no sabemos donde meter (que para eso ya estaba tools) si no más bien donde metemos cosas que ya no se usan... En lugar de foo podría llamarse Deprecated o algo por el estilo. O si no tiene utilidad alguna guardar todo eso, se elimina.

Por ejemplo:

SRC| | - Archetypes| | ------- | - SDL | ------- | - OGL | - Behaviors| | ------- | - SDL | ------- | - OGL | - Entities| | ------- | - SDL | ------- | - OGL | - Drawers| | ------- | - SDL | ------- | - OGL | - Sounders| | ------- | - SDL | ------- | - OGL | - Core| | ------- | - IO| | ------- | ------- | - Files | ------- | ------- | - Net | ------- | - System | ------- | ------- | - Error | ------- | ------- | - Log | ------- | - Math | ------- | - Containers | - Deprecated

O quizá:

SRC| | - Archetypes| | ------- | - SDL | ------- | - OGL | - Behaviors| | ------- | - SDL | ------- | - OGL | - Entities| | ------- | - SDL | ------- | - OGL | - IO| | ------- | - Drawers| | ------- | ------- | - SDL | ------- | ------- | - OGL | ------- | - Sounders| | ------- | ------- | - SDL | ------- | ------- | - OGL | ------- | - Files | ------- | - Net | - Core | ------- | - System| | ------- | ------- | - Error | ------- | ------- | - Log | ------- | - Math | ------- | - Containers | - Deprecated

En cualquier caso, creo que si no nos reunimos vía skype específicamente para esto, no lo solucionamos.

data, resources, multimedia

Ciertamente el nombre da igual, pero es buena idea esa de que se parezca en estructura a src.

El único nombre que descartaría sería "media" por que en linux la carpeta media es donde cargas los distintos "medios" como usb o discos.

Que uno de vosotros asigne números a cada nombre, tire un dado y nos diga cual ha salido.

Tecnología/Actuadores ó Actuadores/Tecnología

No creo que archetypes ni behaviors tengan relacción con la tecnología usada (en principio debería ser transparente a ellos). Creo que el problema se resume en lo siguiente:

Tecnología/Actuadores:

De un vistazo al primer nivel de directorios se ve que tecnología estamos usando. Sin embargo, para saber que opciones tengo para mostrar una imagen he de meterme en todas las tecnologías.

Actuadores/Tecnología:

Según voy escribiendo esto veo que esta es una forma más natural.

Al ver el arbol de directorios me da una idea de las capacidades del motor (si puedo pintar, reproducir sonido, etc.). Como pega, no sabre de un vistazo para que uso una tecnología, pero tal vez esa no sea la pregunta que me haré al utilizar el motor.

La pregunta que, se me ocurre, surge cuando utilizas una api es ¿cómo hago X?, en nuestro caso ¿cómo pinto una imagen, dibujo un volumen, aplico una luz, etc?. Creo que esta estructura responde mejor a esas preguntas.

Como única pega se me ocurre que puede ocurrir que se implemente una funcionalidad en una determinada tecnología y pase desapercibida. Para evitar esto, además de definir una estructura que facilite la busqueda, cuando se cree una nueva funcionalidad con una (o varias) tecnologías, crear un juego/aplicación de muestra que además nos servirá al resto de tutorial.

Math, IO, Deprecated

Math

Lo que apuntas de que math y container deberían ir juntos no lo veo.

Igual que Entities guarda informacíon que sirven para pintar y comportar la entidad, una entidad no es ni un pintador ni un comportamiento, y a su vez, un pintador no es un comportamiento (se que isra me discutirá esto lo que está muy feo por su parte).

De la misma manera, math y container tienen relación, pero no son lo mismo. Un matematico usará un conjunto pero le preocupa bien poco la eficiencia, si inserta muy rápido, no entiende el concepto de que se llene, etc, eso es tarea del informatico.

Pues aquí algo similar, en container definimos una serie de estructuras que son usadas en muchos sitios, y en math definimos muchas operaciones, también muy utilizadas, pero aunque algun container haga uso de math y math haga uso de algun container no son lo mismo. Su objetivo es bien distinto.

IO

Tienes razón en que un pintador y un sonador son, sin duda, Entrada/salida (salida en este caso). Pero meterlos dentro de IO, dificulta ver que puede hacer el motor (ver discusión del apartado anterior).

Mi idea es que vamos añadiendo funcionalidad al motor, algunas cosas son arquetipos, otras comportamientos, dibujadores, entidades, etc (si, no he dicho sonadores, no me gusta decir sonadores, suena raro sonadores, y es paradojico sonadores). Pero resulta que hay funcionalidad que necesitamos para que todo ese funcione pero no es ni un arquetipo ni una entidad ni na (ni sonador tampoco).

Puedo meterlo todo en tools y nuestros yoes del futuro se cabrean. Puedo crear una carpeta para ficheros, otra para redes, otra para math, otra para .... (sonadores ya no que ya tienen la suya), pero eso afea el arbol de directorios, los directorios interesantes y por los que más se va a preguntar mientras se desarrolla son arquetipos, entidades etc, (con etc no quiero decir solo sonadores sino el resto también). Pero como hay muchas carpetas, estas estan entre medias y es más dificil de verlo, así que agruparlo en Core me parece bién.

Para que Core no se combierta en un cajon de sastre como tools, cuando se identifique alguna similitud pues se agrupa (como IO para files y net).

Deprecated

No tengo una aversión especial por una carpeta con código viejo, ya sea foo, deprecated, legacy etc (sin embargo con sonadores si lo tengo). Lo que quiero evitar es que aparezca. Se que es inevitable que lo haga, pero cuanto más tarde en aparecer y mejor lo controlemos, mejor para todos.

Por eso todo el lio de la estructura de directorios, no que cada uno tenga su idea y despues haya que pasarse una tarde moviendo ficheros para dejarlo como dicte el consenso. Establecer ese consenso ahora y respetarlo hasta que aparezca una buena razón para cambiar.

Tarea terminada hace eones. (En escala informática). Quien quiera saber como quedó la estructura de directorios, que se lo baje. Ya seremos formales con lo siguientes issues.

Pues parece que de terminada nada. Se reabre mientras se reorganizan las carpetas del proyecto. Para que, finalmente, gana la opción "actuadores/tecnologías"

Se re-ordenan las carpetas para que sigan el formato "actuadores/tecnologías".

Degryll / ZBE