CAAD

Abro este hilo para exponer distintas ideas de organización de grupos creativos. En breve pondré un artículo sobre como lo haría yo, pero me gustaría saber también como lo veis vosotros. Esto no es un hilo para debatir si hacerlos o no hacerlos, es para saber como organizarlos.

_________________
https://asvelin.itch.io/

Me resisto a escribir en el foro mientras esté activada la limitación de corrección en el tiempo, pero este hilo lo merece.

¿Cómo veo yo la creación de grupos creativos? Básicamente veo dos posibles aproximaciones no incompatibles entre sí:

• Creación de una aventura: dedicación a un proyecto, como se ha hecho 'Transilvania' o como se ha intentado con 'La Isla' recientemente. En este tipo de grupos lo importante es el proyecto en sí y de hecho los miembros del equipo pueden entrar y salir de él según sus disponibilidades. Sería bueno disponer de una herramienta en cloud de gestión (scrum como se ha dicho, por ejemplo, pero no hace falta un director ni mucho menos, sólo un coordinador o scrum master que se encarge simplemente de hacer una reunión periódica para ver cómo va la cosa y que no se estanquen los problemas y demás). Esta clase de grupo son los que con más probabilidad darían como resultado obras terminadas y completas, pero es necesario que haya un proyecto claro e interesante (y consenso sobre la herramienta a usar) para que la gente se una a él y eso es complicado... pero puede surgir del otro tipo de grupos.
  
• El club de poetas interactivos: otra forma más abierta de grupo creativo es aquel en la que los creadores se exponen ideas unos a otros, se enseñan prototipos y así exploran posibilidades novedosas. Este intercambio creativo podría intentarse hacerse en público a través del foro, pero por lo general muchas ideas serán demasiado locas o controvertidas para exponerlas al fuego cruzado del foro, por lo que en general suele funcionar mejor intercambio de correos mediante una lista de 'grupo' o similar. Lo importante en esta clase de grupos es no hacer críticas feroces, ya que lo que se intercambian son simplemente ideas, no se estarían negociando proyectos. Si el grupo da con alguna idea interesante se podría transformar en un proyecto real de relato (un grupo del primer tipo) de forma 'natural', pero no es ese el objetivo, el objetivo debería ser el intercambio de prototipos que ilustren las teorías de cada uno. Nada como intentar forjar lo que tienes en la mente para verificar si las cosas que piensas posibles son o no posibles, y ver la reacción de los otros creadores.

Personalmente puedo estar interesado en colaborar (prometo no hacer mucho ruido) en ambas clases de grupos dando lo mejor que pueda, lamentablemente en el primer grupo sólo podría colaborar si las herramientas son Inform 7 o Superglus, que son las herramientas con las que me manejaría con soltura en la actualidad.

Johan rescato de lo que has dicho esto como sagrado:

- Los miembros del equipo pueden entrar y salir de él según sus disponibilidades.
- Es necesario que haya un proyecto claro e interesante.
- Lo importante en esta clase de grupos es no hacer críticas feroces, ya que lo que se intercambian son simplemente ideas, no se estarían negociando proyectos.

Y añado

- Crear LUMA.

En los siguientes posts me explico, aunque igual ya existe algo parecido.

En cuanto al grave problema de "Es necesario consenso sobre la herramienta a usar, para que la gente se una a él y eso es complicado...", yo diría lo siguiente:

No hay muchos autores y hay muchas herramientas para los autores que hay, por lo que hay pocos autores que dominen una misma herramienta a un nivel parecido. Ponerse de acuerdo en cuál escoger para trabajar siempre será un caos y siempre limitará la escasa y volátil fuerza programadora (volátil por la coordinación y tiempos de disponibilidad). Además es un poco caótico tener muchos programadores sobre el mismo juego en una herramienta de autoría que por lo que sabemos, podría ser monousuario, recordemos que el principio de la modularidad en programación, no es necesariamente fácil de aplicar en un párser arbitrario, que puede tener partes cerradas a la división entre autores, como formularios fijos, encriptación automática de resultados, falta de módulos naturales en su código interno, etc... No todos los párseres son igual de susceptibles a la explotación dividida.

Demasiados problemas...

Propongo crear un sencillo estándar de descripción de aventuras, similar a un pseudocódigo con el menor número de palabras reservadas y estructuras sintácticas posible, que permita plasmar sin ambiguedad la lógica interna de la misma, su funcionamiento. Debe permitir la modularidad. Todo el mundo se lo aprende y así todo el mundo puede colaborar en la programación virtual del juego.

Así el problema inicial irresoluble se reduce a uno consistente en coger la aventura en ese formato y traducirla a cualquier parser, por cualquier grupo de personas, en cualquier momento, incluso para párseres y personas que no existen aún lo cual ofrece todas las oportunidades de éxito "implementatorio"... pasamos de ser difícil tener una sola implementación, al potencial de tener varias simultáneamente.

Así, se podría organizar un proyecto en el que la última fase es la fase de traducción a un párser, donde ahora con más libertad, se puede ofrecer quien quiera para ella proponiéndose junto con su sistema preferido, aunque esta persona o grupo, debería participar activamente en las fases creativas para sentir suyo el proyecto y no limitarse a traducir.

Yo creo que esto ofrece posibilidades, pero habría que diseñar bien ese lenguaje... sería lo primero a resolver, ya que tiene que ser muy expresivo, funcional y fácil de aprender para que todo el mundo lo entienda, y recordad que a pesar de que exprese sin ambiguedad funcionamientos internos, (seguramente tendrá variables y Si()Entonces() como mínimo), debe estar orientado al humano, no a la máquina (no pretendemos acabar programando una máquina virtual intérprete de ese lenguaje y crear así el PAPAITO), simplemente algo que se abstraiga de las máquinas, sin abandonar el sustento que todo programador necesita para programarlo en cualquier sistema.

¿Qué opinais?, os animáis con LUMA (Lenguaje Unificado de Modelado de Aventuras)?

Mi grupo creativo sería el siguiente:
1. Tres o cuatro aventureros se organizan en un grupo virtual con la intención de realizar al menos una aventura durante el año.
2. Se plantean los temas que interesan al grupo y se piensan algunos puzzles. El equivalente al brainstorming empresarial. Con todo lo dicho, se empieza a escribir un primer esbozo de aventura.
3. Se realizan reuniones virtuales, una a la semana por ejemplo, en el chat de Facebook o de Google Docs (la herramienta es indiferente, lo principal es el intercambio de ideas).
4. Se establece un primer guión del juego. A final de mes se cuelga la primera versión del guión en Dropbox o SugarSync (la herramienta es indiferente, lo principal es tener algo en común para consultar tanto el guionista como el programador).
5. Se realizan reuniones virtuales de desarrollo, a razón de una por semana por ejemplo, para ver como va el proyecto. Si la cosa va tomando forma, se empiezan a poner los avances del juego en el foro a modo de promoción. Se va perfilando el guión y la programación hasta terminar una versión alfa del juego.
6. Se acaba la aventura. Se corrigen los errores de las versiones alfa y beta. Finalmente se publica en el CAAD.

Funcionamiento del grupo y roles
El funcionamiento del grupo debe ser horizontal, todo el mundo puede participar en la toma de decisiones. Todos los documentos deben estar al alcance de los miembros. Los roles pueden ser intercambiables y lo ideal es que todos sepan un poco de todo, pero en principio en mi grupo ideal estarían los siguientes roles:
Guionista -> responsable último de los textos que verá el jugador
Programador -> responsable último de la programación
Grafista -> responsable último de los aspectos estéticos del juego, con estrecha colaboración con el guionista y programador
Betatester -> responsable último de la detección de errores en el juego, errores ortográficos e inconsistencias en la trama del juego.

En mi caso particular, yo podría realizar labores de guionista y grafista, y ayudar al programador si éste programara en Inform, y por supuesto colaborar en el testeo. El leit motiv es realizar trabajos con mayor calidad, que normalmente una persona sola no puede hacer.

_________________
https://asvelin.itch.io/

Realmente eso no es un gran problema mientras varios programadores no quieran trabajar exactamente a la vez. Se puede utilizar un sistema de control de versiones, o bien Dropbox (que entre otras funciones también hace de sistema de control de versiones básico) para que cada programador pueda continuar donde el anterior lo ha dejado.

Yo creo que los directorios compartidos de Dropbox son una gran herramienta para que pueda trabajar en el mismo proyecto gente sin muchos conocimientos de informática (ya que los sistemas de control de versiones "de verdad" no suelen ser sencillos de configurar).

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Yo, Grendel, es que creo que la estructura misma del relato es dependiente del tema. Por ejemplo, en la organización que has propuesto, me resulta raro lo de unirse con la intención de hacer 'una aventura' primero y pensar 'la aventura' después. Y lo mismo me pasa con lo 'pensar algunos puzzles'. Para mí los puzzles tienen que estar perfectamente entrelazados con la historia o si no sobran. Organizar la trama de la aventrua a partir de un brainstorm de puzzles, tiene un riesgo muy elevado de generar puzzles que molen pero que mirados desde lejos sean un sinsentido.

En cuanto a los roles, creo que es mejor hablar de 'escritor' y de 'guionista', por separado, y es importante separar varias fases y tareas:

• Decidir el 'tema' de la obra. Esto debería hacerse mediante reuniones virtuales y con brainstorming. El resultado debe ser un consenso global de todos los participantes, aunque normalmente habrá alguien que haya propuesto el 'tema' originalmente.
• Mediante iteraciones establecer el guión o 'trama' de la obra. Esta es la secuencia de escenas así como las transiciones entre ellas. Esto hay que hacerlo de forma iterativa a partir del 'tema' y liderado preferiblemente por alguien del equipo, mejor si es el que propuso el tema originalmente. Esto yo lo he hecho mediante intercambio de secuencia de correos con varios autores, en un grupo se puede hacer mediante intercambios de correos en una lista, pero mejor con reuniones presenciales y una herramienta de escritura colaborativa (wiki, gdocs o lo que sea).
• Una vez establecida la trama hay que enriquecerla con el 'mapa de puzzles', de nuevo de forma iterativa.
• Hasta este punto no se ha tenido porqué escribir ni una línea de texto real, aunque algunos fragmentos pueden existir para fijar el tono de la historia. Entonces es el momento en el que entran a funcionar los programadores y el escritor o escritores. Los programadores van creando las escenas con el texto que buenamente quieran o puedan, y cuando la escena está completa, se la pasan a los escritores que reescriben todo, desde las descripciones a las respuestas a las acciones.

Pues sí, también me gusta tu forma de organizarse, Johan. Yo en esencia propongo cosas sencillas, que no asusten a los que no somos programadores y a la gente nueva que entra en el CAAD y quiere hacer su primera aventura (y a la gente vieja que no tiene tiempo para hacer una aventura pero tiene buenas ideas). Tal vez los chicos de Alpha aventuras o de Aliensuavito puedan ofrecernos a grandes rasgos su método de trabajo.

_________________
https://asvelin.itch.io/

Ya, lo pensé, pero aún así me pareció que se iba a currar simultaneo, igual no es necesario.

Por cierto, leyéndoos me doy cuenta de que LUMA es exagerado jejeje, probablemente es fliparse demasiado, con el guión o mapa de puzzles debería bastar. No quita que de estar hecho sería útil, pero si no está hecho es mejor usar mapas de puzzles supongo.

En SPAC hay una no muy lejana entrevista de jenesis en la que, si no recuerdo mal, se hablaba algo sobre su método de trabajo

"Un viaje con Alien Soft a Transilvania"

En enlace actualmente es http://spac.caad.es/2/spip.php%3Farticle249 pero sé que hay ciertos cambios técnicos pendientes que pueden hacer que no sea válido dentro de un tiempo...

También se migró al nuevo spac del portal:
http://www.caad.es/node/31/spac/un-viaj ... vania.html

_________________
El humor existe para recordarnos que por muy alto que sea el trono en el que uno se siente, todo el mundo usa su culo para sentarse.

Nuestra forma de trabajar es más o menos la siguiente:

* Entre correos o alguna vez que nos vemos alguien propone una idea para un juego. Si cae bien suele haber un intercambio de correos, enlaces, libros, películas entre nosotros para evolucionar la idea y que eche raíces. Se toman notas, dibujos, etc. De aquí surge una auténtica pila de cuadernos con juegos pendientes, hicimos una lista recientemente y salían más de 20 en distintos estados de desarrollo.
* Tenemos siempre un responsable/pedigueño que se encarga de centralizar y ordenar la información y ponerla en un documento de diseño. El documento nunca está grabado en piedra pero sirve para que todos sepamos lo que se va a hacer.
* Se discuten las ideas, cada uno se asigna una tarea que le guste y hacemos una demo.
* Si la demo nos gusta, se sigue adelante sino se abandona. El pedigueño se encarga de perseguir al resto de miembros e ir pidiendo sus tareas según se necesiten. También le toca 'captar' generalmente a conocidos para que aporten pequeñas colaboraciones: música, voces, gráficos, fondos, correcciones, testeo, etc

El principal problema que hemos tenido siempre es conseguir un grupo estable durante la vida de un proyecto, siempre hay gente con la que puedes contar pero todos tenemos obligaciones ineludibles y es deseable tener sangre nueva con la que aprender. Lo típico es que se interesen y luego abandonen, pero es normal pues se trata de una actividad sin ánimo de lucro/poca proyección y es imposible exigir nada a nadie si no tiene auténtico interés.

Un saludo

_________________
---
KMBR! http://www.aliensuavito.org @lecambre

De las formas propuestas para organizar equipos creativos es ésta la que más me ha gustado. Y en cuanto al equipo que recientemente realizó TC, yo en su momeno leí la entrevista (recuerdo que entuciasmadísimo) y pensé que una gran ventaja es que algunos (si no todos) de vosotros os conocéis en persona y os veis con cierta frecuencia. Ésto lo deduje creo recordar por una parte que comentaba cuando se reunían a comer pollo

Es un punto a favor quedar en persona, pero lamentablemente no podemos hacer eso en el CAAD, aquí hay gente de Barcelona, Madrid, Cadrete... pero siempre se pueden hacer quedadas virtuales.

_________________
https://asvelin.itch.io/