#30 la programación es mi punto débil... y el pilar de la industria, pero no lo soporto más de 15 minutos, sin embargo tengo un proyecto a medio diseñar y esta noche me pondré a estudiar estructura urbana para terminarlo y que mi mente no lo tenga en asuntos pendientes.
#22 joder yo me apunto sí o sí. Una idea genial, y no sabía que se hubiera hecho algo así en mv.
Qué os parece si vamos haciendo un guión entre todos, como el del hilo que mencionáis? Lo hacemos un poco más concreto y menos genérico quizá, o lo dejaríais como está? Qué opináis? Podríamos ir haciendo alguna lista de juegos también, la idea de jugar a los de +80 me mola, y podríamos puntuarlos rollo review, por apartados, siendo un poco objetivos claro está, y ver cuán realistas son las críticas (xD), o metacritic en general.
Lluvia de ideas!
De momento pongo el hilo a favs, esto pinta guay 
O podemos poner juegos en desarrollo de gente de MV para analizarlos antes de que salgan con pifias enormes! : DDD
Yo me apunto a hacerlo, pero con un pequeño cambio:
Eligir un género.
Comenzar por el juego que lo inicio.
Ir al siguiente juego que expandió las mecánicas del género.
pues yo creo que un buen game designer no se ve en la idea general del juego sino en los detalles, en como están ajustados todos los pequeños parámetros que te van a dar el "game feel". No creo que sea particularmente necesario ser el más jugón del barrio, si tener una base y haber jugado un mínimo, pero no creo que por jugar más vayas a ser mejor diseñador, es más, creo que un diseñador necesita salir al mundo real y sacar su inspiración de ahí.
Por otra parte un buen diseñador sabe algo de programación o al menos scripting, y es capaz de buscarse la vida y no depender ni de programadores ni de artistas, sabe hacer un poco de todo. Tampoco creo mucho en la importancia de los GDD como punto de partida, creo que son una cosa del pasado. Los documentos de diseño son más para documentar lo que se ha ido probando en el motor y el estado actual del juego, especificaciones técnicas, etc, más que para implementación de nuevas features, para eso con una explicación breve de lo que se pretende conseguir y las herramientas que necesita el diseñador para ajustarlo después, basta. Pero no creo en la utilidad de un documento que explique el juego a nivel teórico con mucho detalle, eso solo vale para vender el proyecto a un publisher.
#35 Pero no creo en la utilidad de un documento que explique el juego a nivel teórico con mucho detalle, eso solo vale para vender el proyecto a un publisher
Fíjate que eso lo creo yo también. Al menos nosotros que en la oficina somos 4 hacemos que el proyecto fluya en el día a día y convivimos con él, no nos hace falta un docu de 30 páginas.
Cierto es que para el tramo final del juego hice un pdf bastante visual con lo que le falta al juego, pero el GDD aburrido lo hicimos para publishers efectivamente.
#36 al final el mejor gdd posible casi te diría que es hacer mockups del juego y unirlos con flechitas xD
Aunque por supuesto hay que documentar lo que se ha ido haciendo y ya está metido en el juego, y lo que se ha hablado en reuniones y demás. Pero el Game Design sobre el papel es algo en lo que cada vez creo menos.
#37 200% de acuerdo con el mockup. Nosotros tenemos un par de proyectos que con Mockup + música ya estamos enamoraos, no creo que haya mejor manera. Bueno sí, un pequeño prototipo xD
Además tenemos músico en la ofi y funcionamos de forma muy dinámica. Uno de los proyectos al que más ganas le tenemos salió de una canción que hizo imaginando un samurai. Hice un gif de 2 frames + la música y ya estamos deseando hacer un prototipo para explorar gamefeel y EXTRA DE GORE.
Pero tenemos que acabar el señorín con el cerdo volador antes xD
#6 #9 #15 Muchas gracias por vuestros aportes, despues de leer y releer vuestros comentarios y estudiar y ver la informacion que dais, he vuelto a darle caña a esto de diseñar videojuegos, mi experiencia en empresas del sector es nula pero siento que tengo un gran potencial para este mundillo.
es complicado salir adelante de forma autodidacta, hay que darle muchisima caña en solitario y no siempre se tienen soluciones a los problemas pero, es importante luchar por lo que se quiere y darles un valor muy grande a los proyectos para poder sacarlos adelante.
ahora mismo estoy volviendo a trabajar en un proyecto que voy aparcando cada 2 x 3 y tengo la convicción de que tiene un gran potencial que me gustaria explotar, pero hacerlo en solitario es muy complicado y mas con un proyecto en 3D como es mi caso, tengo vagos conocimientos de programación y soy diseñador, pero creo que seguire trabajando en solitario hasta encontras programador y animador que creo es lo que mas me hace falta.
El nivel alto de ingles es imprescindible y es algo que tambien estoy trabajando.
de momento y despues de ver la informacion que nos dais (MUCHAS GRACIAS) estoy ganando fuerzas para trabajar a fondo en mis proyectos y espero dentro de poco volver aqui buscando compis, con un proyecto muy solido y con muchas ganas de sacarlo adelante.
Aqui algo mas de mi proyecto en solitario:
#40 Habría que hablar algo más sobre qué exactamente hacer, por que había un chico que proponía hacer análisis de los juegos que crearon géneros y seguir hacía arriba; y me parece algo muy interesante también.
De cualquier forma yo estoy en la facultad hasta las nmil y no puedo aclarar nada, pero lo suyo sería hablarlo con Jastro que es el admin guapetón que nos haría un post muy chulo y apetecible.
Por mi, tienen permiso para hacer lo que quieran, todo lo que sea que los usuarios hagan algo por cuenta propia me hace feliz. Generad el post y si hace falta ayuda con algo hecho una mano, pero prefiero que el nuevo post lo genere otra persona.
#42 lo que dice #34 te refieres? Y claro, lo vemos entre los que nos interese organizarlo un poco y tal, que nos eche un cable Jastro si eso (si no puede tampoco pasa nada, no es muy dificil maquetar el hilo para que quede bonito xD). Todo esto sin prisas.
De momento si eso vamos viendo a quién le interesa colaborar en generar el esquema y sobre qué vamos a hacerlo, y lo hablamos entre todos (por irc por ejemplo o algo? Para no andar ensuciando el hilo xD).
edit: pues mira #43, ahí lo tenemos, nosotros nos lo guisamos y nosotros nos lo comemos. Si necesitamos un cable te avisamos, pero lo suyo creo yo es que lo montemos nosotros
A mi me parece super chachi pistachi, pero solo podre dar mi soporte como fan del grupo, no tengo tiempo para nada 
#35 #36 Por un lado dices que el Game Designer se ve en los detalles y por otro que el GDD no sirve, que es precisamente lo que te da TODOS los detalles XD.
Yo creo que lo estais viendo desde la perspectiva indie con proyectos pequeños, rápidos o por diversión (JAMS por ej.). Pero si se quiere hacer algo grande y muy currado el GDD es casi imprescindible (u otros documentos similares), es lo que te da las bases y la organización en el equipo, si no sería un caos o una puede salir una chapuza. Al igual que se necesita un control de versiones, un gestor del planning, etc...
#46 Creo que Rubenum ha dado en el clavo. Hay determinados tipos de juego que no necesitan ese documento, ni nada al detalle, porque todo va surgiendo durante el desarrollo, se improvisa, se imagina y se desarrolla.
Ahora.. ponte a hacer una aventura gráfica larga sin documento de diseño, guión y mecánicas, puzzles, etc.. como lo lleves todo de cabeza o no esté bien pensado todo.. agüita xDDD
Sobre todo es importante un documento de Q&A (soy un pesado), donde de verdad se trabaje a nivel conceptual qué es el juego y se tengan en cuenta todas las posibilidades, en un posible betatest. Sino se hace bien.. el alphatesting puede acabar siendo un auténtico desastre: Desde jugadores que putean el diseño del juego todo lo que pueden y más, bucando como hacer que se joda, se cuelgue, bugs, exploits, cosas que el programador o game designer no esperaba que nadie en su sano juicio hiciera, etc...
#46 pero si los detalles JAMÁS se ven escribiendo un GDD, se ven probando el juego y ajustando parámetros y viendo la sensación que da todo. Del GDD que se hace antes de empezar nunca queda al final más de un 5% con suerte. Yo te lo digo porque es lo que he visto en todos los sitios en los que he trabajado, desde equipos de 40 personas hasta juegos hechos por 2 personas.
#47 lo del documento para QA es esencial pero sobre todo para el tema técnico, que la gente de QA sepa como debe funcionar el juego, pero es que eso se escribe después de implementarlo xD. El juego se trabaja jugándolo, metiéndote en el juego y ajustando cosas, y luego con el playtesting que vayas haciendo y los datos recogidos.
A lo que yo me refiero es al clásico GDD de "escribo el juego en el papel, y son las instrucciones para hacerlo". Eso vale para perder bastante el tiempo, la verdad. Otra cosa es el trabajo del productor, la planificación y demás. Pero hacer de antemano un gran GDD que explique el juego de la A a la Z es una pérdida de tiempo.
Hoy en día, el GDD es algo que se va haciendo DESPUÉS de implementar las cosas para documentar lo que se ha hecho, eso sí que es importantísimo. Para todo lo demás, notas de lo que se haya hablado en reuniones o de las ideas que haya sobre la mesa.
#46 Más que dependiendo del proyecto diría que del estudio. Nosotros siendo 4, si bien es cierto que tenemos un pseudo GDD, el a donde y cómo queremos llegar con el juego lo llevamos día a día.
#47 También depende del juego también claro está. Qué coño, al final es como todo. Depende de las personas. Yo voy fluyendo de una tarea a otra por ejemplo, no puedo ser metódico y 100% planificado.
Con respecto al testing mira: estuvimos 2 semanas testeando con chavales de universidad, devs, prensa, youtubers...y ahí si que tenemos hojas y hojas de sugerencias y quejas xD
Por ciero, si volví a este hilo es porque buscaba seguir viendo más vídeos de Dayoscript, al cual encontré gracias a #6. Me parece un tío mu competente.
#48 Precisamente la biblia de la historia es solo escribir XD. Creo que entendeis mal el concepto de GDD, este no es un documento fijo, no son las instrucciones obligatorias de la A ala Z. Es un documento vivo, que marca las bases, y que como dices luego haces pruebas, testeas, te metes en el juego y después reflejas los cambios actualizando el GDD, y así te organizas con todo el equipo.
Pero ponerte a lo loco, y decirle por ejemplo al de arte: Oye modela un personaje!. Te respondera: Pero como es? que personalidad tiene? de que ciudad viene? cultura?........
O que cada 5 minutos el programador le pregunte al game designer: y este bicho saltaba para arriba? pero cuanto era? y si se moria que deicas que hacia??
Eso en mi opinión si es perder el tiempo XDD.
#49 Eso es lo que yo entiendo por un GDD XD (o game concept dependiendo del proyecto), llevar el juego día a día con esas bases, darle forma e ir actualizandolo.
#52 La GDD yo la entiendo para estudios medianos / grandes, sinceramente no creo que un grupo de 3-4 personas necesiten una GDD supercompleta y mas si trabajan dia a dia viendose,
Si en un grupo de 3 el artista tiene que ver en la gdd como es un personaje creo que hay un problema grave de comunicación. Se supone que en grupo tan pequeños todos conocen el juego que están haciendo a la perfección.
No digo que no haya documentación, pero tampoco algo al detalle.
#53 Yo tampoco creo que sea necesario un GDD en muchos casos, ni tampoco al detalle, más bien con los detalles, que no es lo mismo XD. Pero por ejemplo en el caso de la Narrativa, para mi que vengo de la animación, me parece ultra importantisimo que se quede escrito algo cuidado y estudiado porque marca todo el proyecto. No es lo mismo que el mundo este inspirado en el Art Nouveau, o que sea postapocaliptico, o que su hermana este enferma.....porque el personaje tendra una personalidad, estetica, etc, distintos. Cada pequeño detalle lo marca todo, los colores, los movimientos, el guión....
Por muy pequeño que sea el equipo y mucha comunicación que haya, al final cada uno lleva su bola en la cabeza (No hablo para una jam o un juego casual de dos dias), y si hay uno que se encarge del Game Design y debe dirigirlo, lo mejor es a través de un GDD (más pequeño, o más grande, mas detallado o menos, lo que queraís XDD).
A ver... yo no se lo bien que vivís vosotros entre grupos de desarrollo más o menos localizados y bien avenidos, pero al menos cuando está colaborando con gente a la que no ves cara a cara, un GDD (o un sucedáneo de éste) es imprescindible.
Yo (que me apunto a cualquier proyecto que me ofrezcan, sin demasiado filtro) he tenido ya un par de chascos con este tema, si no hay un documento de diseño más o menos fijo y compartido y solo hablas con los compañeros una vez por semana, os podéis hacer una idea...
Te puede pasar (ha pasado) que cada uno vaya en una dirección... que a un diseñador le parezca buena idea hacer 4 animaciones más, y dejar de hacer un par de las que se habían programado en un primer momento, que dos programadores hablen con el Game Designer y les diga cosas ligeramente distintas y acaben trabajando sobre los mismos módulos de formas opuestas, que se vayan probando nuevas mecánicas sobre la marcha sin avisar... y mil mierdas más... y al final, obviamente, el proyecto se va al garete...
Supongo que con un poco de seriedad o una persona a la que consultar en vivo y en directo, esas cosas se evitarían solas, pero cuando vas a incorporar a alguien nuevo a un equipo, por ejemplo, cuanta más documentación haya, mucho mejor... Y no hablo de cosas detalladas, pero si siempre que se decide algo se va añadiendo a un documento revisable, te aseguras de evitar ciertas "prácticas negativas"
Pero es que una cosa es coordinar la producción del juego y documentar técnicamente lo que se ha hecho y el estado actual del juego, y otra muy distinta el típico GDD clásico en el que se escribe el juego en un papel antes de tocar una línea de código. Lo que yo digo es que esto último es una total y absoluta pérdida de tiempo más alla de las 2000 palabras, por poner una cifra.
Lo digo porque ni en Virtual Toys, ni trabajando como freelance para clientes, ni en mis propios proyectos con otra gente me he encontrado ni una sola vez con este tipo de GDD salvo para presentárselo al que va a poner el dinero.
El reparto de tareas y el planning diario o semanal del desarrollo no tiene nada que ver con el GDD
#56 y por supuesto lo de ir documentado lo que ya esta hecho está claro, pero a veces es imposible mantenerlo muy actualizado, porque no es práctico. Lo principal es documentar los procesos (por ejemplo como se hace una animación: requisitos, convenciones de nombres de archivos, forma de exportar-importar, etc) y el estado actual del proyecto. A lo que voy es a que el GDD escrito por el Game Designer como biblia del diseño realizado previamente, eso es una cosa del pasado porque no pasa de ejercicio teórico.
12 días después
#58 estamos esperando a acabar exámenes para montar el thread, lo hemos hablado por privado NoGoonie y yo, así que para la semana que viene a finales deberíamos tener algo (al menos yo, si no suspendo nada, habré acabado xD).
#59 #58 Hoy he presentado mi proyecto, mañana tengo entregas, pasado exámenes y el lunes mi último exámen. Y luego libre para quemar bolis y papel. Por mí esto va para adelante cuando solo tenga que preocuparme por hacer las prácticas. ¡Becario doble titulado y parado! ¡Vamos game dev!
EDIT:
BTW yo soy de Barcelona (Mentira en verdad soy de Castellón) por si alguno de los presentes en el proyecto lo es también, un intercambio de ideas delante de unas cervezas en Casa Lopez no es mala idea.
