¿Cómo debe escribirse un documento de diseño?
En una industria tan joven como la del videojuego, donde aún estamos aprendiendo todo lo que estos pueden dar de sí y el lenguaje con el que se escriben, es normal que estemos cometiendo errores en su proceso de creación. Uno de los puntos clave de este proceso es la elaboración del documento donde se va a definir en qué consiste el juego que se pretende crear: el documento de diseño.Cómo deben escribirse estos documentos sigue siendo aún un laberinto del que no hemos conseguido salir. Sin la experiencia de medios más asentados como el cine, donde más de un siglo de rodajes han permitido que sus metodologías hayan podido consolidarse, ésta es sin duda una discusión sin una solución clara, cuando hablamos de la industria del videojuego.
El siguiente artículo me parece un perfecto punto de partida para afrontar esta discusión. Quizás no nos sirva para encontrar la salida del laberinto, pero debería ayudarnos a acercarnos a ella, o al menos, divertirnos mientras nos chocamos contra sus paredes. ¿Entramos?
El autor del artículo, Tadhg Kelly, muestra su desacuerdo con el modo en qué industria y diseñadores están afrontando esta tarea. Las siguientes ideas son las que me han parecido más significativas e interesantes de comentar, aunque recomiendo leer el artículo entero.
Una de las ideas clave que se comunican es que el documento de diseño no tiene que ser concebido como un documento técnico. Del mismo modo que un guión cinematográfico se centra en explicar cómo transcurre la historia y no en definir de cuantos vatios tienen que ser las bombillas de las luces de relleno o qué lente debe utilizarse para la cámara, el documento de diseño debe transmitir la visión del diseñador, o dicho de otro modo, la experiencia de juego que se pretende conseguir con cada elemento del juego.
Por ejemplo, un programador de IA no necesita que un diseñador le explique cómo crear una arquitectura de comportamientos y objetivos. El programador ya sabe, y mucho mejor que el diseñador, cómo construirla. Lo que necesita el programador es que el diseñador le detalle qué necesita que la IA le proporcione de acuerdo con la experiencia de juego que se ha marcado como objetivo.
Veamos otro ejemplo, otra vez de la industria del cine. Como explica Robert McKee en El guión, los buenos actores no van a querer trabajar en un guión donde se les diga qué cara deben poner en una cierta escena. Un buen guión contiene los elementos dramáticos, muchas veces implícitos, y es el actor el que interpreta cómo plasmarlos en cada momento con su actuación, teniendo en cuenta la construcción de la escena y de los propios personajes. Dicho de otro modo, el actor, al menos el que es bueno, no es una marioneta manejada con unos hilos, sino un profesional que sabe hacer su trabajo específico mejor que el guionista, el director o el técnico de iluminación.
¿Cuales son las razones por las que la mayoría de los documentos de diseño pecan de ser demasiado técnicos? Tadhg Kelly comenta que uno de los motivos principales es la paranoia que sufre el diseñador, que siente no disponer de suficiente poder de decisión dentro del equipo de desarrollo.
Eso le hace dudar de si su trabajo será respetado por los profesionales que se encargan de la implementación técnica. Cómo medida de defensa, el diseñador supone que si especifica absolutamente todos los detalles técnicos que afectan a su diseño, está reduciendo la probabilidad de que el resto de profesionales puedan interpretar cómo implementar la feature, poniendo en riesgo que la feature acabe funcionando como el diseñador quería.
En la práctica, esto supondrá que el diseñador acabe metiéndose a menudo en berenjenales técnicos de donde no sabrá salir, y en los que sus lógicos errores harán desconfiar al programador que esté leyendo el documento de la validez del propio diseño. Y lo peor no es que la percepción que tiene el programador del diseñador empeora, sino que los propósitos de juego que el documento pretendía plasmar pasarán probablemente inadvertidos debajo de una fallida exhibición de conocimientos técnicos.
Para solucionar el problema anterior, Tadhg Kelly comenta que el arma principal con la que debe contar un diseñador es la comunicación. Con ella debe transmitir de modo claro y detallado al resto del equipo cuál es el propósito de cada feature y cómo va afectar a la experiencia de juego.
En mi opinión, esto es bastante más importante que el conocimiento técnico que tenga; y lo es simplemente porque la especialización del diseñador en este tipo de conocimiento es lo que le va a permitir ser más eficaz en lo que realmente debería saber hacer mejor que cualquier otra persona del equipo de desarrollo.
Una de las citas más significativas en relación a este tema, creo que la leí en el libro Game Architecture and Design, es la que dice algo como que “el programador no puede ver el bosque por culpa de los árboles, mientras que el diseñador no puede ver los árboles por culpa del bosque”. Si metemos al diseñador a buscarse la vida en medio de la maleza técnica, en la que además siempre estará en inferioridad respecto a los nativos (los programadores), será más difícil que pueda concentrarse en conseguir que el juego mantenga la visión con la que fue concebido, lo que debería ser su principal objetivo.
Ojo, esto no significa que el diseñador se convierte en visionario soñador que se dedica a lanzar conceptos inaplicables y a esperar a que las primeras versiones jugables del juego le muestren el camino que no ha sabido anticipar. Lo que significa es que el diseñador centra toda su capacidad intelectual en detallar el funcionamiento que tendrá el elemento cuando el jugador esté interactuando con él, no cuando el programador empiece a programar la feature.
Esta tarea incluye lógicamente detallar tanto como sea posible cuales son los elementos que definen el funcionamiento de estas mecánicas de juego (sistemas de reglas, parámetros que deben controlarse...), pero no hacer un intento de tutorial que el programador acabará ignorando por sus lagunas técnicas.
No voy a alargarme tratando de encontrarle puntos negativos a esta concepción del documento de diseño (de esto ya os encargaréis vosotros :P). Por el momento, sigo pensando que deberíamos replantearnos qué es lo que necesitamos de los diseñadores y de sus documentos.
Mostrar/ocultar resto...
creado por Cesc Vilanova
15 comentarios
15 Comments:
Como me suele ocurrir con este hombre, estoy solamente medio de acuerdo. La labor del equipo de diseño no solamente consiste en pensar las ideas, features, etc. y definirlas, sino también implementar o producir ese diseño. Alguien tiene que poner los bichos en sus posiciones del escenario, alguien tiene que poner las rutas, triggers y encadenar las reacciones y scripts adecuados, alguien tiene que dar los valores adecuados de vida, daño, peso, etc a cada bicho. Esa producción del diseño normalmente corre a cargo de los diseñadores.
¿Cómo se hará este trabajo? Usando herramientas, parámetros y tablas. ¿Quién debe decidir y definir cómo se serán esas piezas del juego y del proceso de producción? Pues... los diseñadores, claro.
Son esos temas en los que muchas veces se pide a un diseñador que añada mucho más detalle. Puede que haya diseñadores especializados en la parte creativa y narrativa, pero también tendrá que haberlos en la producción de ese diseño. Alguien tiene que hacerlo.
Otro elemento importante es que, a diferencia del cine, el juego es un producto no cerrado, sino también un "sistema" que se pone en manos del jugador para que, con su presencia e interacción, el juego responda adecuadamente. En el cine, los actores (y también los diseñadores de producción, decorados, etc) son personas que pueden improvisar y completar detalles en el momento de rodar la escena. En el juego hay muchas partes que deben funcionar no como productos finales, sino como sistemas, y el diseñador debe definirlos como tales, entrando en detalles y definiendo con mucha más precisión qué es lo que quiere que ocurra en cada situación o como respuesta a cada posibilidad del jugador. Los programadores improvisarán y completarán detalles, pero es demasiado frecuente que esos "detalles" conforman una gran parte de la experiencia deseada, y acaban siendo rellenados por gente que no sabe hacerlo, o que tiene otras tareas diferentes que realizar.
O sea, que "si, pero..."
Otro articulo sobre la problemática de los documentos de diseño lo podeis encontrar en Rampant Coyote. Creo que el hombre se saca de donde le da la gana frases como "I noticed with amusement that there was often an inverse relationship between the size of the design document and the success of the final game", y que se centra más en las comparaciones con proyectos pequeños, pero también contiene unas cuantas verdades.
Pues como hoy es tarde y estoy algo cansado, voy a echar un poco de leña, no, gasolina, al fuego. Pedirle a un diseñador que escriba un diseño tecnico o defina el funcionamiento de las herramientas es como pedirle a un paciente que diagnostique su enfermedad y recomiende un tratamiento. Sin duda sera de gran ayuda si el paciente conoce la jerga medica y es capaz de entender lo que le sucede, pero para algo tenemos medicos.
Y despues de tan alarmante afirmacion, y espero que antes de ser lapidado, vienen varios parrafos de aclaraciones. La division que tenemos aqui en el equipo de diseño, y la que muchas veces se da de facto en otros equipos, es entre "diseñadores" y "scripters". Los diseñadores viven en el mundo de los documentos, definiendo mecanicas, escribiendo la historia e inventando misiones. Los scripters viven en el mundo de las herramientas y las pipelines, peleando con el editor, colocando enemigos y props en el mundo y escribiendo codigo en Lua para hacer que las misiones funcionen. En palabras de un scripter de aqui, "mi trabajo es hacer realidad lo que el documento de diseño define".
Los disclaimers tipicos se aplican. Si tienes un equipo muy pequeño, tal vez no puedas justificar la division. Si tienes una persona capaz de ejercer los dos roles, esplendido, puede hacer ambas cosas si tiene suficiente tiempo. Aunque no necesiten un conocimiento profundo de la tecnologia, los diseñadores todavia tienen que entender sus limitaciones de manera general. Y si tienen ese conocimiento profundo, pues mejor.
Pero la idea es la misma. Definir el juego y montarlo son dos cosas distintas. Y cuando generalizamos hablando de diseñadores, mezclando las dos labores, quizás asumiendo que habrá pocos diseñadores en el equipo, nos autolimitamos. Nos autolimitamos en nuestro intento de comprender que clase de trabajo hace falta para hacer un juego, y podemos acabar confundiendo los dos roles. Podemos acabar pensando que la especificacion de un juego es un documento describiendo como funciona el editor, o la arquitectura de la IA de los enemigos. Podemos acabar pensando que una vez tengamos las herramientas definidas, el juego aparecera magicamente ante nosotros. No es asi.
Especificar un juego es como ir identificando sintomas en nuestro polemico paciente. Dices que te duele, como te sientes, que tal te sento la medicina que te dieron o la cena de ayer, pero no dices tengo que tomar dos pastillas de Pontebientil cada 8 horas. No hace falta saber curar un brazo roto, o especificar el procedimiento en caso de bajada de la presion sanguinea para ser un paciente; solo hace falta estar enfermo. Del mismo modo, el diseñador "creativo" explica lo que espera, lo que imagina. Y a mi al menos me sirve con que lo explique describiendolo por fuera, como si fuera una caja negra. Describiendo lo que hace, no como funciona. Yo ya me pondre mi gorro de medico, reunire todos los sintomas y tratare de definir que esta sucediendo realmente dentro de esa caja negra. Y luego quizas venga un scripter a inyectarle al paciente la medicacion que yo he recetado.
Explicar los sintomas correctamente es importante. No basta con decir "estoy malo", o "me duele la cabeza". Con eso, cualquier buen medico recetara un antibiotico general, o cualquier otra cosa del estilo, y luego ira a quejarse al mejor estilo House sobre lo bien que estaria en casa haciendo calceta. El paciente tendra que hacer un buen analisis y tratar de no olvidar ningun sintoma importante, y luego responder correcta y extensamente a las preguntas que el medico pueda tener.
Supongo que, despues de todo este rollo, la conclusion es que sigo siendo un romantico. Me emociona la idea de tener diseñadores jugando con la version periodicamente, viendo posibles puntos de mejora y experimentando junto al programador (o el scripter), que se encarga de explicarle a la maquina lo que el diseñador le explica a el. En mi mente, son dos personas distintas pero trabajan juntas. Puede que sea mi frustracion de no ser capaz de hacer el trabajo de un diseñador como el lo haria lo que me lleva a proteger mi aportacion, o puede que simplemente no este de acuerdo con esa posible sensacion que puede tener el diseñador de que si no especifica todo al detalle voy a venir yo a cambiarle su juego. Pero el caso es que sigo valorando un diseñador que es capaz de explicarme lo que necesita, y me deja darselo. Un buen paciente.
Interesante blog, lo veo completo y me gusta mucho la imagen superior.
Llevo tiempo intentando colocar una en mi blog y no puedo...¿me podrías ayudar?.
m_bego@ono.com
A lo mejor alguien se anima a hacer una taxonomía de los tipos de diseñador en función de los tipos de tareas a realizar: creativo, de definición, scripter, diseñador de niveles, tableitor...
Coincido con Saül en que cada proyecto requiere una documentación u otra. Y me gustaría rescatar el post de la variante médica que ha tomado Sergio :) mencionando que el artículo del amigo Kelly es más tramposo que el bigote de Groucho Marx.
Desde mi experiencia en televisión y en rodajes, les puedo afirmar que tanto en cine como en televisión no hay solo un guión: Hay también un guión técnico, una escaleta, guión para cámaras, desgloses de producción para cada departamento, etc. Vamos, que en cada rodaje se devasta el Amazonas bastante más que en un proyecto de videojuego.
Desde luego, todos ellos parten del guión literario que hace el guionista, pero el hecho de que este solo contenga diálogos y anotaciones de situación no se debe a que lo demás no es necesario. De hecho es una auténtica hemorroide extraer de ese documento lo que el equipo técnico necesita (y hablo por propia experiencia), de modo que tienes que ir persiguiendo al guionista para que te vaya aclarando qué coño quería decir con 'ambiente industrial'.
Y por último, y no menos importante, en cine el guionista no tiene esa 'paranoia' a la que se alude. La vive DE VERDAD. No sé si conocen el chiste de la actriz tan tonta tan tonta que para conseguir un papel se acostó con el guionista. Los guionistas son literalmente NADIE, unos desconocidos absolutos en la industria (salvo honrosas excepciones). Comparados con ellos, los diseñadores estamos en un pedestal. El hecho de que no se detalle gran cosa en los guiones se debe a que solo sirven como punto de partida. Los que deciden de verdad son el director, el productor e incluso los actores.
Por todo ello, creo que hacer comparaciones con el cine, en general, es pernicioso para la industria del videojuego, y pido públicamente que le pongamos precio a la cabeza del Kelly este. Por listo.
Amén Truman ;)
"pido públicamente que le pongamos precio a la cabeza del Kelly este"
Ernest Adams ya le sacudió bastante hace poco. :)
Si, pero Ernest también recibió lo suyo: http://www.gamasutra.com/php-bin/letter_display.php?letter_id=1255
^^
El problema es que ahora cualquiera se considera "game developer".
Claro que para escribir código se requieren unos mínimos conocimientos técnicos (fácilmente evaluables). Para trabajar en el departamento de arte, cierta técnica y una mínima estética (también evaluables).
Sinembargo, parece que en el departamento de diseño puede entrar cualquiera con un mínimo de atrevimiento para escribir cualquier cosa aunque no tenga ni pies ni cabeza. Y el resto debemos tragar con todo tipo de divagaciones. PROFESIONALIDAD AMIGOS!!! Si quieres ser diseñador de juegos, adquiere unos minimos conocimientos técnicos de diseño estructurado y de programación de scripts.... Sino... dedicate a las chapas...
Jare comenta:
"Esa producción del diseño normalmente corre a cargo de los diseñadores. ¿Cómo se hará este trabajo? Usando herramientas, parámetros y tablas. ¿Quién debe decidir y definir cómo se serán esas piezas del juego y del proceso de producción? Pues... los diseñadores, claro."
Yo no lo veo tan claro. El echo de utilizar a los diseñadores para todo lo relacionado con la "producción del diseño" me parece peligroso. Quizás el problema está en interpretar qué significa exactamente la "producción del diseño", pero en ocasiones tengo la sensación que esto acaba significando que toda tarea de la que nadie quiere encargarse acaba considerándose "producción del diseño" :)
En relación a este tema, me parece muy interesante la propuesta que haces de crear una taxonomía de diseñadores según el tipo de tareas a realizar. Quizás un primer paso sería diferenciar el departamento de producción del de diseño, y entrar entonces en los distintos roles dentro de cada uno. Pero sin duda es un ejercicio que podría ser útil para empezar a evaluar la verdadera efectividad del "diseñador orquestra", que es el que resuelve muchos tipos de problemas distintos pero no se especializa en una faceta del diseño concreta.
En cuanto a lo que dice Saül:
"Estoy de acuerdo con el apunte de jare con que la parte de implementación del diseño es tan o más importante que la de "idear" o "pajearse" ( como algunos compañeros programadores lo llaman :D ) o al menos así lo es en Novarama, donde los diseñadores tenemos que participar en todos los procesos de diseño. Es por eso que cuando diseñamos ya pensamos en cómo querremos poder implementarlo y cuánta flexibilidad necesitaremos (tipos de misiones, valores configurables de estas, etc.)..."
Cuando hablo de escribir documentos no técnicos no me refiero a escribir documentos no concretos. Puedo diseñar "pajeándome" y ser técnico a la vez. Por ejemplo, mientras diseño un sistema de destrucción para vehículos puedo empezar a hablar de una utilización maravillosa de las mallas físicas, de los distintos estados de destrucción de cada pieza del vehículo, de la organización de las jerarquías de sub-objetos visuales en el archivo rid... todo ello sin concretar la lógica funcional del sistema que propongo y olvidándome de lo que realmente necesita el juego.
En cambio, y siguiendo las directrices que marca el artículo, lo que me parece más interesante, por efectivo, es que el diseñador se centre en concretar tanto como sea posible qué es lo que necesita el juego del sistema de destrucción para funcionar coherentemente con el resto de elementos del juego que interaccionan con esta feature. Esto serían cosas cómo:
- ¿Qué partes del vehículo tienen que poder destruirse?
- ¿Qué repercusiones tienen en el comportamiento del vehículo y de la IA del conductor cuando se destruyen?
- ¿Cómo funciona el sistema de salud del vehículo?
- ¿En qué circunstancias puede explotar el vehículo? ¿Cuanto timepo tarda en explotar?
- ¿Cómo afectan los daños recibidos por el vehículo a los NPC que están en su interior? ¿Y al PLAYER?
- ¿Cuanto daño causan las explosiones?
- ...
Todo ello poniendo especial atención, como dice Saül, en los parámetros sobre los que preveemos necesitaremos tener control durante la implementación
del gameplay.
Hacer que el diseñador se adentre en la implementación técnica del sistema supondrá que deje de utilizar su energía en los otros elementos de juego donde su participación es quizás más necesaria. En su lugar, realizará un trabajo (con suerte útil) pero normalmente menos adaptado a su perfil. Supongo que es simplemente cuestión de encontrar dónde es más efectivo utilizar los diseñadores como recurso, o como decíamos antes, encontrar el tipo de diseñador más adecuado a este tipo de tareas.
Respecto a lo que comenta Sergio (sgarces), completamente de acuerdo. Quizás esta visión romántica de la que él habla, y que yo comparto, no sea efectiva en los entornos de desarrollo actuales, en los que probablemente no existan demasiados diseñadores que realmente marquen la diferencia en su parcela creativa de "definición de gameplay". Aún así, eso no significa que debamos renunciar a diseñadores más especializados en definir el juego que en implementarlo. De echo, a mí me parece uno de los pasos más inteligentes que podría hacer la industria para mejorar la calidad de los productos.
Por último, en cuanto a lo que el usuario anónimo comenta:
"Sin embargo, parece que en el departamento de diseño puede entrar cualquiera con un mínimo de atrevimiento para escribir cualquier cosa aunque no tenga ni pies ni cabeza. Y el resto debemos tragar con todo tipo de divagaciones. PROFESIONALIDAD AMIGOS!!! Si quieres ser diseñador de juegos, adquiere unos minimos conocimientos técnicos de diseño estructurado y de programación de scripts.... Sino... dedicate a las chapas..."
Este tipo de afirmaciones despreciando de modo generalizado a los diseñadores son muy habituales, y aunque probablemente se fundamentan en lo que la experiencia te ha enseñado usuario anónimo, parten de la presunción que todos los diseñadores son unos vagos sin sentido común, que es como decir que todos los programadores son unos freaks de Star Wars.
Ya se ha hablado en este blog algunas veces de cómo podría evaluarse la calidad de un diseñador o cómo podría formarse, sabiendo que es todavía difícil que éstos puedan formarse fuera del ámbito laboral con garantías. En cualquier caso, cargar sistemáticamente contra ellos no me parece algo especialmente provechoso. No es cuestión de empezar otra guerra de programadores contra diseñadores, pero este tipo de comentarios me parecen un poco injustos.
Hola a todos! Me parece un tema muy interesante dado el punto de trabajo en el que algunos nos encontramos en estos momentos, :) y que sin duda, es uno de los puntos oscuros a la hora de enfrentarse a un nuevo proyecto. Mi experiencia me dice que si haces un documento de diseño de los tochos, malo; y si lo haces breve, también malo. Evidentemente todo depende de la naturaleza del proyecto, pues no es lo mismo diseñar un RPG que un juego de mesa.
Personalmente, una de las cosas con las que más tiendo a liarme es con el paso del alto al bajo nivel. ¿Cuándo es realmente necesario especificar el bajo nivel, en el documento de diseño? Pues sencillamente opino que cuando el programador lo requiere. ¿De qué sirve especificar en el documento de diseño mil y un parámetros, que sólo han sido probados sobre el papel? El documento de diseño, es un documento abierto y modificable a lo largo del proyecto, que debe partir de unos parámetros básicos que luego, en caso necesario, serán ampliados. Pero serán ampliados cuando así nos lo exijan los programadores o grafistas, no por iniciativa propia.
Otro aspecto importante es destacar cuáles son las features que afectarán al juego, a nivel de GAMEPLAY. Especificar por ejemplo una feature en plan "luces y sombras", sólo será algo eficaz en un juego de stealth, pero dudo mucho que sea algo en lo que un diseñador debe meterse, si el juego a diseñar es un simulador de coches.
Y algo importante: El documento de diseño se escribe para que la gente lo lea. Con documentos de diseño gigantescos, lo único que logramos es desanimar al personal. Porque señores, pese a quien pese, la gente no suele leerse los documentos de diseño. Y si no lo hacen con documentos de veinte páginas, no quiero pensar lo que ocurre con documentos que superan las doscientas.
Estoy con Beru en esta. Los diseñadores no tienen que hacer un documento de bajo nivel para todas las features, pero mas bien, hacer un alto nivel y discutirlo y explicarlo al programador (si hace falta, sentados en un bar o en una reunion) para que el programador entienda cual es el resultado final a alcanzar.
Muy pocos programadores le ponen algo de interes a querer conocer el concepto / idea en si. Simplemente se limitan muchas veces a pensar en la parte tecnica, si se puede o no hacer una cosa, etc... olvidandose del concepto.
Creo que los programadores deberian de ponerle mas ganas a intentar comprender el diseño porque si te olvidas de lo fundamental y pasas al bajo nivel y a discutir parametros y chorradas acabas, como dice alguien en otro comentario, olvidandote de tu objetivo final.
Cesc dijo,
"en ocasiones tengo la sensación que esto acaba significando que toda tarea de la que nadie quiere encargarse acaba considerándose "producción del diseño" :)"
Y muchos de los que llevamos bastante tiempo en esto, tenemos la sensación de que muchos diseñadores buscan excusas para no abordar aquellas tareas que no les apetece o que "no son creativas". No pretendo abrir una discusión dialéctica, simplemente apuntar la otra cara de la moneda.
"En relación a este tema, me parece muy interesante la propuesta que haces de crear una taxonomía de diseñadores según el tipo de tareas a realizar."
Esa taxonomía DE ROLES, NO DE CARGOS, sería una buena base para poder discutir esto en más detalle... pero me temo que se tendría que debatir en un foro distinto a éste, con una dinámica más "dialogable", tipo Wiki o una sala con una pizarra tocha. :)
"Quizás un primer paso sería diferenciar el departamento de producción del de diseño, y entrar entonces en los distintos roles dentro de cada uno."
En Commandos 2 ya se formalizó el equipo de "producción" separado del equipo de "diseño". Para aclarar más las cosas, el equipo de producción tambien se llamaba "brown department". :) No es que la división fuera precisa e inflexible, pero existía.
La forma clásica que usaba para describir lo que hacía ese equipo era: "todo lo que no sea programar C++, hacer gráficos que se vayan a ver, o escribir documentación y material de diseño". No es muy precisa, pero da una idea.
Otro tema aparte es que en general creo que un tío que no se ha "manchado" las manos en producción de diseño, le falta la formación imprescindible para ostentar responsabilidades en diseño, pero las cualificaciones, experiencia y en genera la trayectoria profesional de los "diseñadores de videojuegos" es otro tema más complicado de resolver sin esa taxonomia...
miley cyrus nude [url=http://www.ipetitions.com/petition/mileycyrus]miley cyrus nude[/url] paris hilton nude [url=http://www.ipetitions.com/petition/parishilt]paris hilton nude[/url] kim kardashian nude [url=http://www.ipetitions.com/petition/kimkardashian45]kim kardashian nude[/url] kim kardashian nude [url=http://www.ipetitions.com/petition/celebst]kim kardashian nude[/url]
Publicar un comentario
<< Home