Atraer y retener artistas en juegos de código abierto

El autor del artículo original es Jetrel. Artista que participa activamente en proyectos de juegos de código abierto. Hace varios años fue el "director de arte" de Battle for Wesnoth . También hizo la mayor parte del arte para Frogatto y sus amigos y continúa trabajando en este juego.



Texto original y traducción con licencia CC-BY.



Por el momento, Battle for Wesnoth tiene 109 artistas diferentes , por lo que Jetrel sabe de lo que está hablando.



imagen

Fuente .



Además de la tesis principal, el artículo también abordará los siguientes temas:



  • ¿Qué nos atrae de la programación?
  • ¿Cuál es el peligro de los editores gráficos para los mods?
  • ¿Cuánto tiempo esperan los creadores?
  • ¿Necesita un artista saber programación?
  • ¿Cuántos artistas de arte conceptual necesitas?
  • ¿Cómo encontrar ese?
  • ¿Qué hacer con las estrellas?


Es poco probable que el autor se registre en Habré de forma independiente. Pero si tiene preguntas, puedo remitirlas. Yo mismo recibí el consentimiento para la traducción a través del canal Frogatto en la discordia .



Lo siguiente se presentará en primera persona.



Me han pedido muchas veces en IRC este artículo, y finalmente comencé a escribirlo. Puede que haya algunos errores tipográficos. Siéntase libre de marcarlos como favoritos y discutir cosas que crea que deberían agregarse a este artículo. Lo más probable es que no sea lo suficientemente completo.



En el momento de escribir este artículo (2009), los proyectos de juegos de código abierto tenían, de forma estereotípica, un excedente de programadores y una dolorosa falta de artistas. En consecuencia, esto afectó negativamente a la comunidad. Muchos de nuestros juegos se avergüenzan de mostrarse al público. Solo son atractivos para un puñado de jugadores a los que no les importa la apariencia.



El código abierto y la comunidad indie están en la posición de las uvas verdes. En otras palabras, la buena apariencia se considera el sello distintivo de los malos juegos comerciales. A veces se reduce a una ligera hostilidad hacia los buenos gráficos. Este artículo no defenderá la importancia de los gráficos. Está científicamente probado que la mayoría de las personas son visuales, lo que significa que aprecian una imagen hermosa en los juegos. Si no está listo para aceptar esto, se está conduciendo deliberadamente hacia un pequeño gueto. No puedo ayudarte con eso: este artículo asume que quieres hacer un juego que la mayor audiencia posible disfrutará.



Es difícil argumentar que en muchos juegos comerciales, los buenos gráficos ocultan un juego deficiente, pero la razón de esto son los plazos ajustados, los presupuestos ajustados y la falta de "selección natural" para filtrar los juegos que no son divertidos de jugar. Muchas empresas inundan los juegos con dinero y gráficos, y luego les resulta difícil disfrutarlos. Esta comprensión se produce después de que se hayan gastado enormes recursos. Por lo general, se dejan sin terminar porque los ejecutivos no pueden permitirse el lujo de rediseñar o tienen miedo de perder arte costoso que ya no se utilizará después de cambios importantes.



La buena noticia es que el código abierto es inmune a este tipo de problemas de forma predeterminada.



La esencia misma del código abierto significa que un juego de código abierto solo se volverá popular si es divertido de jugar. Es por eso que la gente dedicará tiempo al arte para juegos interesantes. Además, el código abierto no tiene plazos ni presupuestos estrictos, por lo que pueden permitirse rehacer todo lo que necesitan para que el juego sea interesante en su tiempo libre. Para complacer a los artistas y obtener arte nuevo, debes apreciar el arte existente hasta que completes la refactorización y formes una base de mecánicas de juego interesantes.



La clave para atraer creadores es atraer a una multitud de jugadores y comunicarles que estás listo para aceptar sus aportes. Estadísticamente, un cierto porcentaje de jugadores serán creadores. Si se dirige a una subcultura específica, habrá un número desproporcionado de personas interesadas en las artes visuales (como fantasía o ciencia ficción). Para retener a los creadores, debes mantenerlos motivados. No le pagas a tus creadores, por lo que la motivación es la única forma de mantenerlos en tu proyecto. Tan pronto como dejen de recibir placer o reconocimiento, saldrán por la puerta.



Haz un juego interesante



Para conseguir muchos jugadores, y por tanto creadores, haz un juego realmente interesante. Es difícil. Se pueden escribir muchos libros sobre este tema, pero esta es la razón principal.



Utilice formatos de archivo comunes



Otro factor importante es utilizar los formatos más abiertos. Por apertura, no me refiero a los términos de código abierto, sino a “los formatos con los que la gente suele trabajar”. A menudo son lo mismo, pero no siempre. Es muy importante que las personas puedan preparar completamente el arte para el juego sin herramientas especiales y, al mismo tiempo, puedan ingresar al juego y ver inmediatamente el resultado en acción, sin ayuda adicional. Por lo general, esto significa usar formatos como OGG o PNG, en lugar de formatos hechos por uno mismo como en muchos juegos de los 90. Si escribes tu propio formato de música como MOD o tu propia forma de almacenar máscaras de bits, nadie tendrá las herramientas para crear arte en tu juego. Tendrán que abrirse paso a través de su caja de herramientas. Esto alejará a un gran porcentaje de posibles participantes,porque la mayoría de la gente "prueba el agua" al crear arte simplemente jugando con su copia del juego.



Además de lo anterior, la mayoría de los creadores interesados ​​en desarrollar un juego tienen habilidades de modding. Su motor debe admitir modificaciones. Deberían poder crear sus propios niveles, criaturas y personajes. Los creadores se sienten muy atraídos por la parte del juego que les permite contar su propia historia. Puede lograr esto con un gran editor o un formato de almacenamiento de texto asequible para todo. La mayoría de los creadores en el desarrollo de juegos tienen un dominio suficiente de una computadora para editar archivos de datos de texto. El editor del juego será aún mejor porque puede ser utilizado por casi todos, pero su implementación lleva mucho tiempo. Especialmente para contenido que rara vez cambia. El peligro del santo grial de hacer una GUI "para todo" esque algunas partes del juego aún requerirán programación, sin importar cómo las represente. Por tanto, es mejor programarlos de forma tradicional. Si intentas hacer una interfaz gráfica de usuario para ellos, terminarás con un lenguaje de programación gráfico, pero lo más probable es que solo traigas un desastre.





Reducir el umbral de entrada para participar en un proyecto es realmente importante. Primero, una persona debe intentar hacer arte para ti, y solo entonces podrá entender que le gusta. En la vida cotidiana, nadie decide hacer algo en serio y solo entonces se enamora de ello. En la mayoría de los casos, las personas no invierten seriamente en una actividad y luego deciden si les gusta o no. Al principio, una persona llegará a conocer la lección de manera superficial y solo si le gusta, la profundizará y continuará haciéndola. Si no tiene la oportunidad de mimarlo casualmente, no empezará. Así es como la mayoría de los modders comenzaron su viaje: al principio, mimos frívolos con el editor incorporado, despertó su interés y luego los eventos crecieron como una bola de nieve. Por la misma razón,la mayoría de los lectores comenzaron su viaje en la programación: escribiste algo trivial en un ambiente amigable, funcionó y la alegría de la creatividad te atrajo a más. La gratificación instantánea es realmente importante: crea impulso y motivación.



La gratificación instantánea es esencial para mantener motivados a los creadores. Si el creador comienza a preparar una obra maestra para usted, es muy importante que el resultado del trabajo llegue al maestro lo antes posible. Es emocionante ver tu trabajo reconocido e incluido en la versión oficial del juego. Asimismo, y viceversa, es increíble saber que nadie necesita tu trabajo. Los creadores rara vez entienden lo difícil que es la programación, lo que significa que pensarán que no estás usando su trabajo porque no estás contento con él. Lo mismo ocurre con el arte y el código, los creadores no pueden leer tu mente. Si planeaba ver esto en unas pocas semanas, nadie lo sabrá. Si no empiezas a trabajar inmediatamente con el código, el arte o la música propuestos, ya no te harán nada. Esto no es un problema para una corrección de errores de una sola vez. Pero esta es una mala señal para aquellosquien te envía la primera muestra y está listo para llenar tu juego con modelos y gráficos. Debes seguirlos, debes trabajar con ellos y mantenerlos interesados. Casi todos los participantes que puedan llenar su juego se perderán si no regresa a ellos en una semana o un par de días. Este es uno de los argumentos a favor de la política RERO (lanzamiento temprano, lanzamiento frecuente).





Puede que no sea obvio, pero los artistas no pueden compilar tu juego. Si los lanzamientos oficiales son menos de una vez al mes o dos, debe proporcionarles lanzamientos. No deberían quedarse atrapados en el gueto de las versiones obsoletas, porque se saldrán del flujo de innovaciones en tu juego. También forman parte del equipo y es importante para ellos ver cómo se combina su trabajo con los nuevos cambios. También es muy importante lanzar lanzamientos para su plataforma. Sé que los programadores de Linux no siempre tienen la capacidad de compilar para Mac (por ejemplo). Pero si alguien ofrece una obra maestra, debe proporcionarle una liberación. Porque si no pueden jugar tu juego, entonces no están interesados ​​en ayudarte. En la práctica, necesita una compilación prediseñada disponible públicamente para Mac y Windows. Punto. Si no tiene uno, el 99% de los usuarios de computadoras no jugarán su juego,lo que significa que no estarán interesados ​​en crear obras maestras para ella. Mac es especialmente importante para artistas y músicos porque hay desproporcionadamente muchos de ellos.



Demuestra que el juego tiene éxito



Los creadores desaprueban categóricamente los planes en el espíritu de que "el infinito no es el límite". Hay muchos proyectos similares. La mayoría de los videojuegos (tanto de código abierto como comerciales) no son los favoritos, y la mayoría de los creadores interesados ​​en crear arte para un videojuego ya han intentado participar en al menos un proyecto y han tenido dificultades para superar su caída. Todo su trabajo se ha ido. El problema es que los creadores no tienen la capacidad de medir las habilidades de los desarrolladores. Otros desarrolladores pueden mirar de reojo el código y decidir si es confiable o terrible, pero la mayoría de los creadores solo tienen el boca a boca. No tienen idea de si tienes lo que se necesita. Para demostrar que hablas en serio, debes completar el juego básico. Como en Return of the Jedi, la Estrella de la Muerte no necesita ser completada, pero debe ser "completamente funcional".



En general, esta es una buena práctica de diseño de juegos. Primero, haces un prototipo rápido y construyes los principales elementos funcionales del juego lo antes posible. Vale la pena mencionar que he visto innumerables proyectos de juegos que se posicionan como una plataforma de lanzamiento para los astronautas arquitectónicos. Si solo desea centrarse en el desarrollo de la IA y no le importa completar el juego, no atraiga a los posibles participantes con sus afirmaciones de "desarrollo de juegos". ¿No puede responder por sus palabras, con la esperanza de que todo salga bien? Arder en el infierno. Las personas que crean obras maestras son realmente serias, de lo contrario estarían perdiendo el tiempo en sus portafolios en galerías como DeviantArt. Solo declara que estás creando un juego si tu objetivo principal es completar un juego impecable y de calidad.

No dejes que los astronautas de la arquitectura te asusten

[aprox. Este enlace estaba en el original, lo dejo como está]



Los artistas necesitan autoridad gráfica



Quizás creas que sabes mejor cómo debería ser tu juego. Si no haces todo el arte tú mismo, renuncia a tus intenciones. Tus artistas suelen disfrutar de su estilo visual. Recuerda que no trabajan por dinero, sino por placer. O estás de acuerdo con ellos o te quedas sin arte en absoluto. Esto es totalmente diferente a los juegos comerciales. No eres el jefe, no puedes decirles qué hacer. Los artistas necesitan una carta blanca completa con respecto al arte. Al igual que los programadores tienen la facultad de elegir el lenguaje de programación y el estándar de codificación. Con razón te indignarías si los artistas te dijeran qué cambiar. En cualquier caso, las solicitudes para rehacer un trabajo debido a un desajuste de estilo destruirán la magia y arruinarán el disfrute del trabajo. Sin placer, sin artista.



Encontrar un artista para un proyecto de juego es como encontrar una novia. Al igual que en la vida familiar, debes evitar casarte (o casarte) con un artista que hace algo que odias. Si estás creando un videojuego y se te ha acercado un artista que te ofrece un trabajo en un estilo que no te gusta en absoluto (por ejemplo, anime), es posible que debas rechazarlo. Es mejor hacer esto de antemano. Lo último que necesitas es una bomba de tiempo. Es una decisión difícil. Puede que no tengas arte si rechazas a esta persona, pero es mejor ser sincero contigo mismo y resolver este problema. Quizás deberías soportar un estilo que te cabree un poco.



Necesitas un artista principal



Uno de los problemas obvios puede surgir cuando varios artistas en un equipo tiran de un carro en diferentes direcciones. ¿Qué hacer en este caso? Exactamente lo mismo que con el código. Elija al que hace el mejor trabajo (y se toma en serio la realización del proyecto) y déjelo ser el dictador. Si realmente hace la mayor parte del trabajo, entonces no tienes miedo de asustar a las personas que no están de acuerdo con él. Por lo tanto, todos los que quieran participar te traerán obras maestras del mismo estilo y calidad. En otras palabras, debes pretender ser un juego comercial. Confiar en alguien con autoridad y autoridad también influye positivamente en la motivación de ese creador. Por lo general, trabajarán más duro y estarán a la altura de su confianza en términos de gráficos.



La mejor opción es enganchar al mismo loco entusiasta como tú, pero que quiere hacer gráficos, no código. Él podrá llamar suyo a su juego.



Es importante que dicha persona tenga la autoridad para eliminar fragmentos desafortunados que están fuera del estilo general. Sí, suena un despilfarro, pero las empresas comerciales lo hacen todo el tiempo. Por tanto, sus juegos se realizan en un solo estilo integral. Por la misma razón, los codificadores desechan la cáscara durante la refactorización. Solo debe preocuparse de que la cantidad total de contenido eliminado no exceda la cantidad de contenido creado. El mismo principio funciona con el código. No sigues los consejos de la primera persona que entra en tu proyecto y declara la refactorización de todo. Primero déjele demostrar que sabe lo que está haciendo.



Puede tener más de un artista principal. Donde el arte cae en categorías obvias que requieren un conjunto de habilidades diferente, entonces los artistas naturalmente caerán en grupos de habilidades. Muchos ilustradores expertos son completamente incompetentes en el modelado 3D (y viceversa).



No necesitas artistas conceptuales



Al menos en forma de especialización independiente y separada. El artista conceptual existe en la cultura de las empresas comerciales, lo que puede inundar el tema de la "creatividad" con dinero. Ésta es la forma más elevada de liderazgo. Crean conceptos y otros artistas tienen que digerirlos y crear piezas útiles del juego en sí. Este nivel de especialización suele ser bastante inútil. Además, priva a los "seguidores" del derecho a la propia creatividad, que es agradable y es el motivo de su libre participación. Lo toleran en proyectos comerciales porque les pagan, pero por lo general no les gusta: se ven obligados a hacer exactamente lo que ha hecho el artista conceptual y no se les da la oportunidad de mostrar su propio talento para el diseño.



Necesitas artistas que creen imágenes que puedan usarse en el juego. Sin estos, no tendrás un juego. No podrás aplicar el trabajo de los artistas conceptuales al juego. Las imágenes por sí solas son inútiles. Curiosamente, los creadores que pueden crear imágenes útiles también pueden crear arte conceptual. Les llevará más tiempo, pero esta es la parte más agradable de convertirse en artista. Casi todo el mundo algún día será así. Además, el equipo de arte será lo suficientemente creativo como para que no surja la necesidad de un artista conceptual independiente. Definitivamente, esto es suficiente para garantizar una apariencia decente.



Los artistas se desarrollan en un ambiente de crítica técnica.



Hay una notable multitud de creadores famosos que consideran su trabajo "por encima" de cualquier crítica. Es prudente de su parte reconocerlos y señalarlos hacia la puerta lo antes posible. Incluso si son buenos, harán más daño que bien. Recuerde que la búsqueda de un artista es matrimonio / matrimonio, lo que significa networking mutuo. Incluso desde el lado del artista. A pesar de que en las artes visuales mucho depende del punto de vista y la opinión subjetiva, mucho se puede medir utilizando métricas de calidad objetivas. Se necesita habilidad para crear un buen arte, y algunas personas apestan.



Cómo el arte puede ser bueno

[aprox. Este enlace estaba en el original, lo dejo como está]



Incluso los mejores artistas pueden cometer errores técnicos en su trabajo. Por ejemplo, extremidades de lugares inesperados; posiciones extrañas y antinaturales (porque en realidad serían imposibles o fatigosas); perspectiva desde la que Eschergiraría en un ataúd. Estos momentos no dependen del estilo visual o "pensamientos profundos" del artista. Los fallos ocurren porque el artista se equivocó. Una imagen con errores como esta parece estúpida incluso para el autor tan pronto como se da cuenta de su error. Las personas deben guardar sus opiniones sobre el estilo para sí mismas, pero la crítica sana de errores reales beneficiará a todos. Esta atmósfera hará que tu arte se vea mejor. Esto permitirá que tus artistas crezcan. Los creadores tendrán la impresión de que se les trata de forma justa. Esto fomenta un diálogo saludable sobre la creación de arte para su proyecto y es mucho mejor que los comentarios de una línea y poco naturales de "gran trabajo" cuando se discuten propuestas nuevas.



En resumen, trate a los creadores (tanto artistas como compositores) como sus socios iguales en el desarrollo de juegos y un día encontrará un maníaco como usted. Para encontrarlo con éxito, debe comprender de dónde podría provenir y esforzarse por proporcionarle un entorno accesible. Recuerde, si una persona le ofreció a su juego algunos años-hombre de trabajo, entonces será tan "suyo" como "suyo".



Preguntas y respuestas



¿Por qué no hacer que los gráficos sean intercambiables? Entonces no verá un estilo que no le guste.


Texto original
In general, a major software-development principle we held when working on Wesnoth (and which I think is generally pretty smart) was: «options are bad».

Every option in a software program is another code path you have to support, and the combinatorial complexity of multiple code paths, when it comes to testing and all sorts of similar «hidden costs» of doing development, really adds up.

So you don't want to accept multiple kinds of art, and gate each kind of art behind an option flag which users (or the author) can turn off.

It's bad because not only does it increase the support costs of the software, but it also makes it harder to achieve the goal of having a single, coherent art set for the project you're on, because it severely «confuses» your messaging to new contributors.

Ultimately if you've got a game that only has a portion of the art done, your game's mere existence is the best «help wanted» ad for getting additional art. But a critical part of asking for this additional art is a detailed description of what you need to do to match the game's current style.



The thing is — just existing is usually enough. «A picture is worth a thousand words». You don't need to waste a huge amount of time explaining what you want if you've got a large body of examples.

But — if these examples severely contradict themselves, then you're in for a lot of pain. If you've got two radically different visual styles, it's very difficult to explain to new contributors «which style» you'd like the game to actually be in.

All of a sudden you go from a hands-off, «no work for the project lead» matter of just letting the art speak for itself, to having to be deeply, personally involved in steering people.

— Alternate interpretation: It's possible you're suggesting a scenario in which someone's offering to make art for the game in a single, coherent style, and this is a situation where the entire game would get art, but you, the developer, would hide the art from yourself.

At the risk of being impolite, this is absolutely insane.

Which is to say it's «impossible» — there's an enormous time-cost and ongoing maintenance cost of time you'll have to spend getting the graphics to display correctly, and making sure they continue to display correctly as development continues and features get added and removed.

In almost all cases where this has happened (dwarf fortress being a key example), these external «artists» essentially did an enormous amount of programming to make their work viable.

Dwarf fortress mods operate by literally doing direct memory access and looking at the RAM state of the app as it runs, since there's no mod API or anything, but even if you did have a mod API — somebody has to pay the enormous cost of writing the code to get the entire graphics-drawing layer working correctly, and the complexity of doing this is usually equivalent to writing an entire game of its own.

… I mean — any game where this succeeds has essentially «won the lottery», and is an extremely dangerous target to imitate the habits of, because it succeeded not due to «good developer practices» but because it got insanely lucky.



A dangerous thing when looking at the dev practices of other games, especially «popular, successful» games, is a phenomenon called «survivor bias».

Survivor bias is when someone looks at the behavior of a very successful thing, and instead of thinking «oh, they were really successful, so they were able to survive even though they made a bad choice» — instead, one assumes «oh, they succeeded BECAUSE they made this choice».

For example — dwarf fortress doesn't use source control. :ohno:

Not git, not svn, not cvs. They just have old copies of the code in folders.



Anyways, when it comes to art — I honestly personally believe you're going to be entering a really toxic/awkward relationship if you're working with an artist who's producing a style you really don't like.



You can try to «fake» it by being nice, and accepting the art even though you don't like it, but you're far better off just living without and being honest.

It's a lot like getting married. :neutral_face:





En general, al desarrollar Battle for Wesnoth, nos adherimos al principio de que "la elección es mala". Cada opción del programa es una rama adicional de código que debe mantener. El número total de ramas de código crece según las leyes de la combinatoria. Como consecuencia, aumenta la complejidad de las pruebas y el "costo invisible" del desarrollo.

Por lo tanto, realmente no desea tomar muchas instrucciones artísticas y tener una bandera de desactivación para cada una de las opciones.

La elección es mala no solo porque aumenta el costo de mantenimiento del software. La elección evitará que logre un estilo de arte consistente y consistente en su proyecto, porque su mensaje a los nuevos contribuyentes será "ruidoso".

En última instancia, si tu juego solo tiene una parte del arte lista, entonces su propia existencia transmitirá mejor la idea "Necesito ayuda" para obtener arte adicional. Pero la parte importante de pedir ayuda es detallar exactamente lo que necesitas para que coincida con tu estilo de juego general.



La cuestión es que la existencia por sí sola es suficiente. "Una imagen vale mil palabras." Si tiene muchos ejemplos, entonces no tiene que dedicar mucho tiempo a explicar su visión con texto. Pero si estos ejemplos se contradicen, sufrirás. La existencia de dos estilos de arte radicalmente diferentes le impedirá explicar con qué estilo le gustaría terminar.

Normalmente, no es necesario que interfiera con el desarrollo del estilo visual. Art hablará por sí mismo. Pero si tienes la opción, de repente tienes que microgestionar y guiar a todos por tu cuenta.



Otra interpretación. Quizás propongas un escenario en el que tengas un participante que sea capaz de hacerse cargo de todo el trabajo con el arte, pero al mismo tiempo tú, como autor, te esconderás este arte.

Puede que suene descortés, pero esto es una locura.

Y, de hecho, esto es casi imposible: hará un gran esfuerzo para garantizar la correcta exhibición de este mismo arte tanto al principio como a lo largo de la vida del proyecto.

Esto ya ha ocurrido en Dwarf Fortress y en varios otros proyectos. En última instancia, los "artistas externos" tuvieron que invertir mucho esfuerzo en la programación para que su trabajo fuera visto.

Los mods de Dwarf Fortress funcionan con acceso directo a la RAM del proceso en ejecución. No hay una API directa para modificar ni nada de eso, pero incluso si hubiera una, alguien tendría que escribir código para que la capa de visualización de gráficos funcione. La complejidad de esta tarea es comparable a desarrollar su propio juego.

... Quiero decir, no tienes que buscar juegos en los que este enfoque de "ganó la lotería". Este es un ejemplo muy peligroso porque tiene éxito no a través de "buenas prácticas de desarrollo" sino a través de una suerte increíble.

Generalmente es una mala idea considerar la práctica de desarrollar juegos populares y exitosos. Incluso hay un término: "error del sobreviviente". En lugar de decir "guau, pudieron sobrevivir a pesar de las malas decisiones", la gente dice "lo lograron PORQUE tomaron esas decisiones".

Bueno, por ejemplo, Dwarf Fortress no usa el control de versiones. Ni git, ni svn, ni siquiera cvs. Simplemente copian una carpeta en un directorio.



Sea lo que sea, personalmente siento que trabajar con un artista cuyo estilo no te gusta es una falta de respeto antinatural hacia ti mismo. Puedes fingir, ser educado y aceptar el arte incluso si no te gusta, pero te resultará mucho más fácil negarte y ser honesto contigo mismo.

Esto es muy similar al matrimonio / matrimonio.



PD Si encuentra errores tipográficos o errores en el texto, hágamelo saber. Esto se puede hacer seleccionando parte del texto y presionando "Ctrl / ⌘ + Enter", si tiene Ctrl / ⌘, o mediante mensajes privados . Si ambas opciones no están disponibles, escriba sobre los errores en los comentarios. ¡Gracias!



All Articles