Novedades Campus Party Valencia 2011

[Mars Attacks]

Bueno, como ya os comenté, vamos a ir empezando con el show.

Cosas que le he ido comentando a Ender3 (es un copipasteo de varios mails retocado para encajar en un solo post coherente, por si se me cuela algo raro):

Mi enfoque para este año iba a consistir en pedir aquí el feedback necesario para afinar los procesos, no los contenidos. Me explico: todos los años hay un "voto del público" que acaba siendo distorsionado porque siempre hay alguien que se mueve más que otros en el último momento. A mí me gustaría que este año, en la medida de lo posible, todos los campuseros estuvieran realmente implicados en la prueba de todos los juegos, pero aún no tengo del todo perfilado cómo. Probablemente, con incorporarles a la primera etapa de sugerencia de temas ya obtuviéramos una primera implicación. La parte complicada de esto es la logística de avisar a los campuseros de que se pasen por el foro (que no por el forro) de la campus a un hilo en particular a proponer su aportación, desde el comienzo.

Por otro lado, quería potenciar en simbiosis con lo anterior el apartado de difusión del juego una vez acabado. Actualmente siempre se terminan los juegos el viernes a última hora, y el sábado por la noche se hace el pase de proyectos para explicarlos. Yo propondría comenzarlo todo un día antes, para cerrar los proyectos el jueves, y que los concursantes dediquen los siguientes dos días a descansar (porque es una competición maratoniana durísima) y a hacer algo de marketing viral por la propia campus.

Además, también quería estandarizar un poco más los procesos de entrega, ya que todos los años hay alguien que no se acaba de enterar de los horarios de entrega y el contenido de los adelantos parciales (siempre hemos sido muy flexibles en este punto porque sólo se trata de poder comprobar si el día 1 no tenían nada pero el 2 tenían el Starcraft). El año pasado propuse una entrada obligatoria en un blog para cada una de las dos entregas obligatorias diarias (una actualización a las 12 del mediodía y otra a las 10 de la noche, por ejemplo, para cubrir más o menos lo que son las jornadas de desarrollo de la campus (de mediodía a tarde y de noche a madrugada). El problema fue que mucha gente descuidaba el tema de la entrada en el blog y había que estar recordándoselo continuamente (es un punto importante porque se pide una pequeña memoria del desarrollo en la documentación final, y esto les puede ayudar muchísimo).

Sobre la organización de los días, me gustaría que este año se dedicara todo el primer día a la planificación del juego (preparación de un documento de diseño con escala de prioridades y un pequeño roadmap de separación de tareas y tiempos, que redundaría en una mejor calidad de su producto final, además de planificar las "acciones de marketing viral") hasta el lunes. Quiero decir: las listas de items posibles para incorporar al desarrollo y su selección final estarían listas el domingo de antes de la Campus por la noche en los foros. Como la gente suele venir con los grupos ya hechos de casa, ya pueden ir haciendo sus brainstormings y planificaciones, autogestionándose en los foros, y la entrega de ese primer documento sería el martes por la mañana (con la flexibilidad de entregarlo más adelante si algún grupo no llega hasta tal otro día, pero siendo obligatoria su entrega como primer milestone del desarrollo).

Así pues, con martes, miércoles y jueves a media tarde para desarrollar y la otra media tarde para la confección de la documentación y por la noche para la entrega del proyecto, quedaría viernes noche para presentaciones, (y viernes y sábado para márketing).

La programación se plantea libre en principio, mientras sea en plataformas que el jurado pueda probar. Parte de la entrega consistiría en que tengan sus proyectos colgados en sus blogs de desarrollo cuando terminen para que la gente pudiera descargarlos, pero por ejemplo alguno podría necesitar de una Xbox o iPhone para funcionar, además de unos cuantos PC con los juegos preparados para que, durante todo el periodo post-desarrollo, la gente se pudiera acercar libremente al área y probarlos sin tener que molestar al autor para que le deje su Xbox.

Lo de anunciar procesos y demás, obviamente hay que hacerlo en el foro de Campus Party, pero llevo como tres o cuatro o cinco años pidiendo si de alguna manera se puede enviar SMS a la gente desde la propia organización de campus (tanto para avisar de eventos varios a los que se hayan registrado como para este tipo de cosas). El año pasado me encargué de enviar SMS y llamar personalmente a los cabecillas de los grupos para recordarles cada uno de los milestones (al principio nos quedamos con la información de cada grupo con sus componentes, nombre del grupo, un par de mails de contacto, dirección del blog donde pondrán el desarrollo, un par de teléfonos de contacto...). Con el estrés que hay en esos días de programación, no puedes esperar que todos estén al tanto de un foro una vez empieza la fiesta. Si hubiera podido asistir personalmente este año, me habría encargado de ir grupo a grupo con todo esto, pero desgraciadamente mi disponibilidad estuvo complicada (y puede que lo vuelva a estar).

En resumen, que básicamente está todo controlado (igual que el año pasado estuvo todo controlado desde que me asignaron esa organización), pero con este tiempo suficiente lo ideal sería tenerlo pulido y automatizado en la medida de lo posible.

Y éste es un BREVE resumen de cómo lo veo para este año :)

Isabel comentó:

Si queréis enviar a la gente al foro, vamos a hacer uso también de los canales que tenemos, es decir, metámoslo en twitter, facebook, en la web y en el blog. De esta forma, que nadie pueda decir que no se había enterado de cómo dar su opinión sobre la competición.

El tema de tener iphones/ipad para probarlos lo comentaré con la gente de Telefónica. A ver si también nos dan algún premio como el año pasado. Voy a ver también el número de ordenadores que tendremos disponibles por si alguno se puede destinar a este tema.

Por cierto, este año las competiciones se abren el día 1 de abril, así que tenemos mes y medio para elaborar tranquilamente unas bases que cuenten con el consenso de todos. Nosotros vamos a intentar ir cerrando buenos premios, pero se aceptan sugerencias.

Pues ya sabéis. Todo feedback es bienvenido.

[SiPoX]

Hum... pues todo ok, con feedback... :P

- Empezar el lunes no me convence mucho, sobre todo porque la gente suele llegar ese día a horas dispares y no todo el mundo está "operativo" para el comienzo. No obstante, es cierto que tener viernes y sábado de descanso es muy valorable. Otros años se hizo así, y el anuncio de los temas / restricciones se hacía como a las 19:00 horas del lunes. Y la inscripción de los grupos y el comienzo oficial, sobre unas 22:00 ó 24:00 de ese lunes si no recuerdo mal. Con ello se tienen varias horas para refinar los grupos, pensar en las primeras ideas iniciales... pero sí que es cierto que ese tiempo puede quedarse corto (por ejemplo si hay que buscar un grafista por ahí xD!) Pero bueno, si lo veo muy  aceptable, a pesar de ser algo precipitado. ;)

- Sobre el doc de diseño, documentación, seguimiento.... yo creo que con una entrada diaria en el blog y la subida de lo que se lleve en ese momento, sería suficiente, sin tener más milestones marcados que la entrega final. Más que nada porque cada grupo lleva su ritmo, y eso depende de cada uno como decida organizarse, siempre cumpliendo con esas entregas de control, claro. ;)

- Los dos últimos años sobre todo, si eché de menos tener a alguien por ahí... no sé... que en esas entregas pues una visita xD! o tener a alguien a quién dirigirse en persona, más localizable que subir el .zip y ya está. Aunque imagino que eso ciertamente depende de la dispo ;)

- Suena muy interesante lo de facilitar hardware donde poner los juegos para que se puedan probar, o incluso para desarrollo.. sobre todo en dispositivos móviles o consolas ;) :P Desde luego sería todo un puntazo! :P

- Algo que es muy interesante es mantener la idea de mecánicas / temas, y que haya que combinarlas, así como algunas restricciones o especificaciones extra obligatorias o voluntarias. :D

pd.- seguiremos pensando... ;) :P

[fjfnaranjo]

Wep, otro que se apunta a que el lunes es apurao y ofrece una idea.

Lo que se puede hacer, es presentar las restricciones el lunes por la tarde, realizar las inscripciones de los grupos el martes a la misma hora (aquí se pondrían a programar) y la entrega el viernes por la tarde. Se quedan en medio dos "milestones" a la hora de la tarde.

Se puede pedir a los grupos que cuando se inscriban, declaren que pretenden terminar para cada milestone, y en cada uno, hacer una entrada en el blog y subir un zip. Así tendríamos:

L 16h -> Difusión de restricciones
M 16h -> Inscripción de los grupos y post en el blog explicando el diseño, los miembros y tareas que realizan, y un detalle de que se espera en cada milestone.
X 16h -> Post en el blog con un zip y un resumen del milestone.
J 16h -> Post en el blog con un zip y un resumen del milestone.
V 16h -> Post en el blog con memoria y zip final.

El organizador, a.k.a. Mars, sólo interviene de forma directa en la inscripción y recoge los zips y docs del blog conforme los grupos los publican (y da collejas si alguien se retrasa). De esta forma, es la idea original que creo que Mars pretendía transmitir pero sin el adelanto del concurso. Si se da importancia a la publicación del blog y se hace incapié en que Mars no va detrás de los demás con el pendrive si no que recoje en silencio los proyectos en el blog, yo creo que ya habremos mejorado bastante, sobre todo por la introducción de las milestones fijas en el blog.

Otra cosa, sería que cada grupo hiciera una fast charla (60-90 seg.) al principio y en los milestones de como va el equipo, presentando algo de gameplay o assests graficos. Así el control del avance no es sólo por parte de Mars y se implica más a los campuseros porque les interesa ver como van los demás.

[[EX3]]

Se puede pedir a los grupos que cuando se inscriban, declaren que pretenden terminar para cada milestone

Esto no lo veo. Exigir de primeras que declaren que van a presentar en cada milestone es pillarte los dedos con total seguridad. Recordemos que esto es un fastcompo y por mucho que se planifiquen las cosas siempre surgen imprevistos. Nosotros mismos, SiPoX, Josepzin y yo, nos hubiera sido imposible acatar esto el año pasado ya que ninguno sabiamos de antemano los problemas que surgirian.

Otra cosa, sería que cada grupo hiciera una fast charla (60-90 seg.) al principio y en los milestones de como va el equipo, presentando algo de gameplay o assests graficos. Así el control del avance no es sólo por parte de Mars y se implica más a los campuseros porque les interesa ver como van los demás.

Esto si me ha gustado :) pero lo dejaria como opcional, esto es, si por ejemplo a la primera milestone un grupo llega sin material visible que presentar (digamos que solo tienen partes de codigo y ningun asset grafico definido) les seria imposible mostrar avance alguno en publico, lo unico mostrar "las servilletas" donde se ha planteado el juego (en plan las pizarras con las ideas del juego a como se hizo en las presentaciones de la GameJam).

Salu2...

[Mars Attacks]

Bueno, mientras vais divagando, lo que quiero decir con lo del lunes es lo siguiente.
Este año, las competiciones van a empezar el 1 de abril, como comentaba Isabel. A partir de ese día, llevaríamos a cabo la recopilación de temas y restricciones en los foros. Podemos cerrar esa recopilación y dar los temas definitivos el domingo por la noche.
La campus como tal empieza el martes 12 de julio por la mañana (con el lunes como primer día de llegada, montaje y demás, no está muy en funcionamiento). Por tanto, del 1 de abril al 11 de julio no me parece precisamente precipitado que los grupos se vayan juntando y preparando.

Luego tendrían todo el lunes (o hasta que fueran a empezar, pero es por no quitar ese tiempo al tiempo de desarrollo) para hacer las servilletas y todo lo que cuento (que no es más que una planificación básica y que se vayan pensando cómo conseguir que cuanta más gente de la campus juegue a su juego y lo vote).

Todo eso lo pediría como primer milestone el martes por la mañana, y a partir de ahí, dos días y medio de programación intensiva.

Os recuerdo que las presentaciones serán el viernes por la noche, con la entrega de premios el sábado, si no lo entendí mal. Así que esta planificación, además de dejaros descansar como personas un poco más al final y disfrutar de algo más de la campus, os da la oportunidad de preparar mejor vuestras presentaciones (que, repito, quiero intentar que la mayor parte de la campus posible le esté prestando atención), y de la que espero que dependa el tan siempre distorsionado voto del público :)

[Makaimura]

Otros años ya lo dije creo que un metodo mas acertado aunque no 100 por 100 seguro es votar segun numero de projectos, si hay 10
Juegos votas del 1 al 10 así aunque le des 10 puntos a tu colega has de dar 9 a otro juego, 8 a otro etc

Porque no con el tiempo que tenemos hacemos un video con si no todos los juegos de todas las ediciones con los ganadores y todos los que podamos mostrar y pasar el video un poco antes de la inaguracion oficial en el wall? Animando a la gente si es que hasta los moders tienen mas publico.

[SiPoX]

Se puede pedir a los grupos que cuando se inscriban, declaren que pretenden terminar para cada milestone

Esto no lo veo. Exigir de primeras que declaren que van a presentar en cada milestone es pillarte los dedos con total seguridad.

La verdad es que yo tampoco lo veo. No sé, yo prefiero dejar libertad a que cada grupo se organice como quiera o como sean ellos más eficientes. Tener el control diario de lo que se ha hecho mediante el reporte a la organización, me parece correcto y necesario, pero sin especificar previamente qué vamos a ir entregando cada día. Incluso en el primer milestone que comenta Mars yo no especificaría las N cosas a incluir de forma muy "tipada", aunque pueda ser a modo de recomendación. Quiero decir, a lo mejor yo tengo planificado todo en mis primeras horas de producción porque tengo muy claro el juego que quiero hacer, pero a lo mejor otro grupo está la noche del lunes haciendo pruebas / prototipando, y deja el doc de diseño + features iterativas para más adelante... O puede que otro grupo ni si quiera tenga planificación al ser un concepto muy sencillo y que vayan decidiendo sobre la marcha por ser muy escalable. O como nos pasó el año pasado, que a día y medio cambiamos de plataforma porque no nos funcionaba el motor... No sé... cada grupo puede ser un mundo, por el tipo de juego, por la gente... así que yo intentaría dejar libertad absoluta en el contenido de lo entregable / planificación interna.

La fast charla me parece muy interesante, pero implicaría que todos los grupos estuviesen a una hora determinada, y suele no resultar operativo, pues cada uno tiene sus horarios y demás. Y es difícil hacer coincidir a la gente. :( Aunque siempre podría ser algo voluntario, fijar una hora cada día y poner las cosas en común, como las quedadas de después de cenar de lo de campuseros presentan. ;)

Hum... asaltaremos a los grafos vía foro entonces xDD! :P Hum.. se comenzaría la compo entonces el lunes por la tarde? :P Si es así, el horario que comentaba antes me parece el más propicio... aunque los temas puedan anunciarse algo antes ;) :P

[Mars Attacks]

Tened en cuenta muy mucho que la razón principal de gran parte de lo que preveo para el concurso es de cara a que el resto de campuseros reciban cierto hype que les impulse a seguir el desarrollo. De ahí que crea que es importante que al principio puedan echarle un ojo tanto a la propuesta que vais a hacer (con lo que os gustaría meter en orden de importancia si os da tiempo), como los planes de "marketing" que tenéis para ello (tenéis un buen ejemplo en el recortable-cubedroid de los amigos Devilish, aunque allí no hay impresoras ;)) para que cuantos más campuseros os voten, mejor.

Y, de paso, os puede ayudar realmente con el desarrollo haber pensado bien las ideas al principio, aunque luego obviamente haya dispersiones sobre el guión original.

Algo que se me acaba de ocurrir para añadir un poco de miga de los demás campuseros sería ver la posibilidad de disponer desde organización de las fotos que suban para las acreditaciones, de forma que parte de la gracia del juego sea que aparezcan sus caretos en los personajes. Éste es el tipo de asuntos para el que me encantaría recibir ideas: ¿cómo implicaríais a cuantos más campuseros mejor?

[fjfnaranjo]

¿cómo implicaríais a cuantos más campuseros mejor?

Dinero.  :P

[Mars Attacks]

Eso se traduce a un sorteo entre los votantes de los juegos que hayan conseguido más de cierta puntuación en sus récords, por ejemplo.

[Mars Attacks]

Decíamos ayer... este viernes tenemos que pasarle las bases preliminares a Isabel para el concurso. En lo fundamental está claro que seguimos la tónica que ya hablábamos antes (temas a elegir sobre una lista dada y además alguno obligatorio, entregas, etc.), pero aún me gustaría recibir mucho más feedback sobre detalles como:

-¿cómo implicamos a los campuseros en esto desde el principio?

A mí se me ha ocurrido que se puedan usar sus fotos de CP. Isabel ha propuesto que es más fácil y mejor que suban fotos de sus caras a cierto tamaño prefijado para que se tengan que usar como avatares. Es cierto, pero a su vez también necesita de un comienzo activo por parte de los campuseros y no sé si conseguiremos el efecto bola de nieve necesario. Además, también ha sugerido dar un premio de entrada gratis para el año que viene a quien alcanzara el máximo récord en un juego (por mi parte, mejor si puede ser a todos los que consigan el hi-score en cualquiera de ellos).

-marketing de guerrilla

Aquí incluiría eventos que deberían llevar a cabo los participantes de cara a hacer más visible su juego para los campuseros (desde que acabáis el desarrollo hasta el momento de las presentaciones), y el número de ideas que tengo al respecto es 0, por lo que todas las sugerencias son vuestras.

-cerrar el calendario

Dado que el 1 de abril publican las bases, y a partir de ahí empezamos a montar el chiringuito, personalmente creo que la temporización que propuse es factible y viable, pero no os veo muy convencidos (tampoco había muchas opiniones). Lo único inamovible son las fechas de la exposición (viernes noche), el comienzo de picar código no antes del martes y que habrá entregas al menos diarias de código y entrada bloguera, así que... colaborad. Si queréis abro encuestas o algo.

[fjfnaranjo]

Con respecto a lo último que dices, yo aplicaría el milenario mecanismo qui tacet consentire videtur, o dicho de otra forma, el que calla otorga :P

A mi lo único que se me ocurre para forzar la implicación de los demás campuseros, es que esto sea además una restricción del juego, osea, hacerlo accesible/interesante para otros campuseros. He dicho que es lo único que se me ocurre, pero no pienso para nada que sea una buena idea.

Quizás se podría dar un premio aparte según el número de participantes de la campus "no desarrolladores" que hayan jugado al juego (no se me ocurre como controlar esto, quizás una hoja de firmas, pero por complejo quizás lo descartaría).

Si se me ocurre algo más adelante lo digo... sorry

[shephiroth]

Para controlar cuantos campuseros pruebas un juego se me ocurre una idea "sencilla y eficaz", aunque entraña introducir código al juego y que la campus establezca un "servidor". La idea es, que todos los juegos cuando ejecuten contacten con el servidor....el servidor lee la ip, guarda el registro del nuevo jugador, y "valida" el ejecutable del cliente. A partir de ese momento el jugador ya puede jugar "offline".

El unico problema sería el tener que "crear" el código para dicho procedimiento. La solución puede ser que sea un código ya creado con anterioridad, y que la organización pueda proveer en varios lenguajes de programacion. Esto eliminaría la pega de que los concursantes no tienen que crearlo, y como al final se entrega el codigo fuente no hay ningun problema al respecto.

Esto abriria la opcion al voto electrónico (los usuarios pueden votar el juego directamente desde el juego) y de high scores, pero volvemos al tema de antes, mas código a "crear" :)

Saludos.

[fjfnaranjo]

Uff, pero es que esto es cargar de trabajo a los participantes, y las compos ya son suficientemente jodidas como para además agregarles esto...

[Makaimura]

Contratad tres peponas una rubia una morena y una pelirroja con ropa askjeves trademark y que se vayan pasando por los sitios de la peña y los cojan del brazo y le digan al oido vente con nosotras que vas a vivir una experiencia interactiva de desarrollo y que lo sienten a probar los juegos.