Texto original e tradução licenciados sob CC-BY.
No momento, Battle for Wesnoth tem 109 artistas diferentes , então Jetrel sabe do que está falando.

Fonte .
Além da tese principal, o artigo também abordará os seguintes assuntos:
- O que nos atrai para a programação?
- Qual é o perigo dos editores gráficos para mods?
- Quanto tempo os criadores esperam?
- Um artista precisa saber programação?
- De quantos artistas de arte conceitual você precisa?
- Como encontrar esse?
- O que fazer com as estrelas?
É improvável que o autor se registre no Habré de forma independente. Mas se você tiver dúvidas, posso encaminhá-las. Eu mesmo consegui o consentimento para a tradução através do canal Frogatto na discórdia .
O seguinte será apresentado na primeira pessoa.
Fui questionado várias vezes no IRC para este artigo e finalmente consegui escrevê-lo. Pode haver alguns erros de digitação nele. Sinta-se à vontade para adicioná-los aos favoritos e discutir coisas que você acha que deveriam ser adicionadas a este artigo. Muito provavelmente, não é abrangente o suficiente.
No momento em que este artigo foi escrito (2009), os projetos de jogos de código aberto estereotipadamente tinham um excesso de programadores e uma dolorosa falta de artistas. Consequentemente, isso afetou negativamente a comunidade. Muitos de nossos jogos têm vergonha de serem mostrados ao público. Eles são atraentes apenas para um punhado de jogadores que não se importam com a aparência.
O código aberto e a comunidade indie estão na posição das uvas verdes. Em outras palavras, a boa aparência é considerada a marca registrada dos jogos comerciais ruins. Às vezes, tudo se resume a uma ligeira hostilidade aos bons gráficos. Este artigo não defende a importância dos gráficos. Está cientificamente comprovado que a maioria das pessoas são visuais, o que significa que apreciam uma bela imagem em jogos. Se você não está pronto para aceitar isso, você está deliberadamente se dirigindo a um pequeno gueto. Não posso ajudá-lo com isso - este artigo presume que você deseja fazer um jogo que agrade ao maior público possível.
É difícil argumentar que em muitos jogos comerciais, bons gráficos encobrem a jogabilidade ruim, mas a razão para isso são prazos apertados, orçamentos apertados e uma falta de "seleção natural" para filtrar jogos que não são divertidos de jogar. Muitas empresas inundam os jogos com dinheiro e gráficos e, então, acham difícil apreciá-los. Essa constatação vem depois que enormes recursos foram gastos. Normalmente, eles ficam inacabados porque os executivos não podem se dar ao luxo de redesenhar ou têm medo de perder obras de arte caras que não serão mais usadas após grandes mudanças.
A boa notícia é que o Open Source é imune a esses tipos de problemas por padrão.
A própria essência do código aberto significa que um jogo de código aberto só se tornará popular se for divertido de jogar. É por isso que as pessoas gastam tempo com arte para jogos interessantes. Além disso, o código-fonte aberto não tem prazos ou orçamento restritos, então eles podem refazer tudo o que precisam para tornar o jogo interessante em seu lazer. Para agradar os artistas e obter uma nova arte, você deve valorizar a arte existente até concluir a refatoração e formar uma base de mecânicas de jogo interessantes.
A chave para atrair criadores é atrair uma multidão de jogadores e comunicar a eles que você está pronto para aceitar suas opiniões. Estatisticamente, uma certa porcentagem de jogadores serão criadores. Se você visar uma subcultura específica, haverá um número desproporcional de pessoas interessadas nas artes visuais (como fantasia ou ficção científica). Para reter criadores, você precisa mantê-los motivados. Você não paga seus criadores, então a motivação é a única maneira de mantê-los em seu projeto. Assim que eles pararem de receber prazer ou reconhecimento, eles sairão pela porta.
Faça um jogo interessante
Para conseguir muitos jogadores e, portanto, criadores, faça um jogo realmente interessante. É difícil. Muitos livros podem ser escritos sobre este assunto, mas este é o principal motivo.
Use formatos de arquivo comuns
Outro fator importante é usar os formatos mais abertos. Por abertura, não quero dizer os termos open-source, mas sim “os formatos com os quais as pessoas normalmente trabalham”. Muitas vezes são a mesma coisa, mas nem sempre. É muito importante que as pessoas possam preparar completamente a arte para o jogo sem ferramentas especiais e, ao mesmo tempo, possam entrar no jogo e ver imediatamente o resultado em ação, sem ajuda adicional. Normalmente, isso significa usar formatos como OGG ou PNG, em vez de formatos criados por você mesmo, como em muitos jogos dos anos 90. Se você escreve seu próprio formato de música como MOD ou sua própria maneira de armazenar bitmasks, ninguém terá as ferramentas para criar arte em seu jogo. Eles terão que vasculhar sua caixa de ferramentas. Isso afastará uma grande porcentagem de possíveis participantes,porque a maioria das pessoas "prova a água" ao criar arte simplesmente mexendo em sua cópia do jogo.
Além do acima exposto, a maioria dos criadores interessados em desenvolver um jogo na verdade tem habilidades de modding. Seu motor deve suportar mods. Eles devem ser capazes de criar seus próprios níveis, criaturas e personagens. Os criadores são muito atraídos pela parte do jogo que lhes permite contar sua própria história. Você pode conseguir isso com um ótimo editor ou um formato de armazenamento de texto acessível para tudo. A maioria dos criadores no desenvolvimento de jogos são bons o suficiente com um computador para editar arquivos de dados de texto. O editor do jogo ficará ainda melhor porque pode ser usado por quase todos, mas leva muito tempo para implementar. Especialmente para conteúdo que raramente muda. Os perigos do Santo Graal de fazer uma GUI "para tudo" éque algumas partes do jogo ainda exigirão programação, não importa como você as represente. Portanto, é melhor programá-los da maneira tradicional. Se você tentar fazer gui para eles, acabará com uma linguagem de programação gráfica, mas muito provavelmente trará um desastre.
Reduzir o limite de entrada para participar de um projeto é muito importante. Primeiro, uma pessoa precisa tentar fazer arte para você, e só então ela poderá entender que gosta. Na vida cotidiana, ninguém decide fazer algo seriamente e só então se apaixona por isso. Na maioria dos casos, as pessoas não investem seriamente em uma atividade e decidem se gostam ou não. A princípio, a pessoa vai conhecer a lição de maneira superficial e só se gostar, vai se aprofundar e continuar a fazê-la. Se ele não tiver a chance de mimar casualmente com ele, ele não vai começar. Foi assim que a maioria dos modders começou sua jornada - a princípio, mimos frívolos com o editor embutido, ele despertou o interesse deles, e então os eventos cresceram como uma bola de neve. Pela mesma razão,a maioria dos leitores começou sua jornada na programação - você escreveu algo trivial em um ambiente amigável, funcionou, e a alegria da criatividade acenou para mais. A gratificação instantânea é realmente importante - ela cria impulso e motivação.
A gratificação instantânea é essencial para manter os criadores motivados. Se o criador começa a preparar uma obra-prima para você, é muito importante que o resultado do trabalho chegue ao mestre o mais rápido possível. É emocionante ver seu trabalho reconhecido e incluído na compilação oficial do jogo. Da mesma forma, e vice-versa, é matador saber que seu trabalho não é necessário a ninguém. Os criadores raramente entendem como a programação é difícil, o que significa que eles vão pensar que você não está usando o trabalho deles porque você não está feliz com isso. É o mesmo para arte e código, os criadores não podem ler sua mente. Se você planejou assistir isso em algumas semanas, ninguém saberá sobre isso. Se você não começar a trabalhar imediatamente com o código, arte ou música proposto, eles não farão mais nada por você. Isso não é um problema para uma correção de bug única. Mas isso é um mau sinal para aquelesquem lhe envia a primeira amostra e está pronto para preencher seu jogo com modelos e gráficos. Você precisa segui-los, trabalhar com eles e mantê-los interessados. Quase todos os participantes que podem preencher seu jogo serão perdidos se você não voltar a eles em uma semana ou alguns dias. Este é um dos argumentos a favor da política RERO (liberar antecipadamente, liberar com frequência).
Pode não ser óbvio, mas os artistas não podem compilar seu jogo. Se os lançamentos oficiais ocorrerem em menos de uma vez por mês ou dois, você deve fornecer os lançamentos. Eles não devem ficar presos no gueto de versões desatualizadas, porque sairão do fluxo de inovações em seu jogo. Eles também fazem parte da equipe e é importante para eles ver como seu trabalho se combina com as novas mudanças. Também é muito importante lançar lançamentos para sua plataforma. Eu sei que os programadores de Linux nem sempre têm a capacidade de compilar para Mac (por exemplo). Mas se alguém oferece uma obra-prima, você precisa fornecer um lançamento. Porque se eles não podem jogar seu jogo, então eles não estão interessados em ajudá-lo. Na prática, você precisa de uma versão pré-construída disponível publicamente para Mac e Windows. Ponto. Se você não tiver um, 99% dos usuários de computador não jogarão seu jogo,o que significa que eles não estarão interessados em criar obras-primas para ela. O Mac é especialmente importante para artistas e músicos porque há uma quantidade desproporcionalmente grande deles.
Prove que o jogo foi bem sucedido
Os criadores desaprovam categoricamente os planos no espírito de “o infinito não é o limite”. Existem dezenas de projetos desse tipo. A maioria dos videogames (de código aberto e comercial) são azarões, e a maioria dos criadores interessados em criar arte para um videogame já tentou participar de pelo menos um projeto e teve muita dificuldade em passar por sua queda. Todo o seu trabalho acabou. O problema é que os criadores não têm a capacidade de medir as habilidades do desenvolvedor. Outros desenvolvedores podem olhar de soslaio para o código e decidir se ele é confiável ou péssimo, mas a maioria dos criadores fala apenas no boca a boca. Eles não têm ideia se você tem o que é preciso. Para mostrar que você está falando sério, você precisa completar o jogo básico. Como no Retorno do Jedi, a Estrela da Morte não precisa ser completada, mas deve estar "totalmente funcional".
Em geral, essa é uma boa prática de design de jogos. Primeiro, você faz um protótipo rápido e constrói os principais elementos funcionais do jogo o mais rápido possível. Vale ressaltar que tenho visto inúmeros projetos de jogos que são posicionados como uma plataforma de lançamento para os astronautas arquitetônicos. Se você quer se concentrar apenas no desenvolvimento de IA e não se importa em completar o jogo, não atraia participantes em potencial com suas afirmações de "desenvolvimento de jogo". Não pode responder por suas palavras, na esperança de que tudo dê certo? Queime no inferno. As pessoas que criam obras-primas são realmente sérias, caso contrário, estariam perdendo tempo em seus portfólios em galerias como DeviantArt. Apenas declare que você está fazendo um jogo se seu objetivo principal for concluir um jogo de qualidade e sem falhas.
Não deixe que os astronautas da arquitetura assustem você
[aprox. Este link estava no original, deixo como está]
Artistas precisam de autoridade gráfica
Talvez você ache que sabe melhor como seu jogo deve ser. Se você não fizer toda a arte sozinho, desista de suas intenções. Seus artistas geralmente gostam de um pouco de seu estilo visual. Lembre-se de que eles não trabalham por dinheiro, mas por prazer. Ou você concorda com eles ou fica sem arte. Isso é totalmente diferente dos jogos comerciais. Você não é o chefe, você não pode dizer a eles o que fazer. Os artistas precisam de carta branca completa em relação à arte. Assim como os programadores são autorizados a escolher a linguagem de programação e o padrão de codificação. Você certamente ficaria indignado se os artistas lhe dissessem o que mudar. Em qualquer caso, pedidos para refazer um trabalho por causa de uma incompatibilidade de estilo destruirão a magia e arruinarão o prazer do trabalho. Sem prazer, sem artista.
Encontrar um artista para um projeto de jogo é como encontrar uma noiva. Como na vida familiar, você deseja evitar se casar (ou se casar) com um artista que faz algo que você odeia. Se você está criando um videogame e um artista veio até você e oferece um trabalho em um estilo que você absolutamente não gosta (por exemplo, anime), talvez seja necessário recusar. É melhor fazer isso de antemão. A última coisa de que você precisa é uma bomba-relógio. É uma escolha difícil. Você pode não ter arte se recusar essa pessoa, mas é melhor ser verdadeiro consigo mesmo e resolver esse problema. Talvez você deva aceitar um estilo que o irrite um pouco.
Você precisa de um artista principal
Um dos problemas óbvios pode surgir quando vários artistas em uma equipe puxam um carrinho em direções diferentes. O que fazer neste caso? Exatamente igual ao código. Escolha aquele que faz o melhor trabalho (e leva a sério a realização do projeto) e deixe-o ser o ditador. Se ele realmente faz a maior parte do trabalho, você não tem medo de assustar as pessoas que discordam dele. Assim, todos os que quiserem participar irão trazer para você obras-primas do mesmo estilo e qualidade. Em outras palavras, você precisa fingir ser um jogo comercial. Confiar em alguém com autoridade e autoridade também influencia positivamente a motivação desse criador. Eles geralmente trabalharão mais e viverão de acordo com sua confiança em termos de gráficos.
A melhor opção é fisgar o mesmo maníaco entusiasta como você, mas que quer fazer gráficos, não código. Ele poderá chamar seu jogo de seu.
É importante que essa pessoa tenha autoridade para remover fragmentos infelizes que estão fora do estilo geral. Sim, parece um desperdício, mas as empresas comerciais fazem isso o tempo todo. Portanto, seus jogos são feitos em um único estilo integral. Pelo mesmo motivo, os programadores jogam fora a casca durante a refatoração. Você só precisa se preocupar para que a quantidade total de conteúdo removido não exceda a quantidade de conteúdo criado. O mesmo princípio funciona com código. Você não segue o conselho da primeira pessoa que entra em seu projeto e declara a refatoração de tudo. Deixe-o primeiro provar que sabe o que está fazendo.
Você pode ter mais de um artista principal. Onde a arte se enquadra em categorias óbvias que exigem um conjunto de habilidades diferente, os artistas naturalmente se enquadram em grupos de habilidades. Muitos ilustradores qualificados são completamente incompetentes em modelagem 3D (e vice-versa).
Você não precisa de artistas conceituais
Pelo menos na forma de uma especialização separada e independente. O artista conceitual existe na cultura das empresas comerciais, que podem inundar de dinheiro a questão da "criatividade". Esta é a forma mais elevada de liderança. Eles criam conceitos, e outros artistas precisam digeri-los e criar peças úteis do próprio jogo. Esse nível de especialização geralmente é um desperdício. Além disso, priva os "seguidores" do direito à sua própria criatividade, que é agradável e é a razão da sua livre participação. Eles toleram isso em projetos comerciais porque são pagos, mas geralmente não gostam - são forçados a fazer exatamente o que o artista conceitual fez e não têm a oportunidade de mostrar seu próprio talento para o design.
Você precisa de artistas que criem imagens que possam ser usadas no jogo. Sem eles, você não terá um jogo. Você não poderá aplicar o trabalho dos artistas conceituais ao jogo. As imagens por si mesmas são inúteis. Curiosamente, os criadores que podem criar imagens úteis também podem criar arte conceitual. Levará mais tempo deles, mas esta é a parte mais divertida de se tornar um artista. Quase todo mundo um dia será assim. Além disso, a equipe de arte geralmente será criativa o suficiente para que a necessidade de um artista conceitual separado simplesmente não surja. Isso é definitivamente o suficiente para você garantir uma aparência decente.
Os artistas se desenvolvem em uma atmosfera de crítica técnica
Há uma notável multidão de criadores de celebridades que consideram seu trabalho "acima" de qualquer crítica. Seria sensato da sua parte reconhecê-los e apontá-los para a porta o mais rápido possível. Mesmo se forem bons, farão mais mal do que bem. Lembre-se que a busca por um artista é casamento / casamento, o que significa networking mútuo. Inclusive do lado do artista. Apesar do fato de que nas artes visuais, muito depende da visão e opinião subjetiva, muitas coisas podem ser avaliadas usando métricas de qualidade objetivas. É preciso habilidade para criar uma boa arte, e algumas pessoas são péssimas.
Como a arte pode ser boa
[aprox. Este link estava no original, deixo como está]
Até o melhor dos artistas pode cometer erros técnicos em seu trabalho. Por exemplo, membros de lugares inesperados; posições estranhas e não naturais (porque na realidade seriam impossíveis ou cansativas); perspectiva a partir da qual Eschergiraria em um caixão. Esses momentos não dependem do estilo visual ou "pensamentos profundos" do artista. As falhas acontecem porque o artista estragou tudo. Uma imagem com erros como esse parece estúpida até para o autor assim que ele percebe seu erro. As pessoas devem guardar suas opiniões sobre estilo para si mesmas, mas uma crítica saudável de erros reais beneficiará a todos. Esta atmosfera fará com que sua arte pareça melhor. Isso permitirá que seus artistas cresçam. Os criadores terão a impressão de que estão sendo tratados com justiça. Isso encoraja um diálogo saudável sobre a criação de arte para o seu projeto e é muito melhor do que comentários de "ótimo trabalho" de uma linha e não naturais ao discutir novas propostas.
Em resumo, trate os criadores (artistas e compositores) como seus parceiros iguais no desenvolvimento de jogos e um dia você encontrará um maníaco como você. Para encontrá-lo com sucesso, você precisa entender de onde ele pode vir e se esforçar para fornecer um ambiente acessível. Lembre-se, se uma pessoa ofereceu ao seu jogo alguns anos-homem de trabalho, ele será tão "dele" quanto "seu".
Q&A
Por que não tornar os gráficos comutáveis? Então ele não verá um estilo de que não goste.
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:
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:
Em geral, ao desenvolver Battle for Wesnoth, aderimos ao princípio de "a escolha é má". Cada opção do programa é um ramo adicional de código que você precisa manter. O número total de ramificações do código cresce de acordo com as leis da combinatória. Como resultado, a complexidade dos testes e o "custo invisível" do desenvolvimento aumentam.
Então, você realmente não quer seguir muitas instruções de arte e ter um sinalizador de desativação para cada uma nas opções.
A escolha é má não apenas porque aumenta o custo de manutenção do software. A escolha o impedirá de alcançar um estilo de arte consistente e consistente em seu projeto, porque sua mensagem para novos colaboradores será "barulhenta".
Em última análise, se o seu jogo tiver apenas uma parte da arte pronta, então sua própria existência transmitirá melhor a ideia "Preciso de ajuda" para obter arte adicional. Mas a parte importante de pedir ajuda é detalhar exatamente o que você precisa para combinar com seu estilo de jogo geral.
A questão é que só a existência é suficiente. "Uma foto vale mais que mil palavras." Se você tiver muitos exemplos, não precisará perder muito tempo explicando sua visão com texto. Mas se esses exemplos se contradizerem, você sofrerá. A existência de dois estilos de arte radicalmente diferentes o impedirá de explicar qual estilo você gostaria de usar.
Normalmente, você não precisa interferir no desenvolvimento do estilo visual. A arte falará por si mesma. Mas dada a escolha, você de repente tem que microgerenciar e guiar a todos por conta própria.
Outra interpretação. Talvez você proponha um cenário quando você tem um participante que pode assumir todo o trabalho com a arte, mas ao mesmo tempo, você, como autor, irá esconder essa arte de si mesmo.
Posso parecer indelicado, mas isso é loucura.
E de fato, isso é quase impossível - você fará um enorme esforço para garantir a exibição correta dessa mesma arte tanto no início quanto ao longo da vida do projeto.
Isso já aconteceu na fortaleza dos anões e vários outros projetos. Em última análise, os "artistas externos" tiveram que investir muito esforço na programação para que seu trabalho pudesse ser visto.
Os mods Dwarf fortress funcionam com acesso direto à RAM do processo em execução. Não há API direta para modding ou algo parecido. Mas mesmo se houvesse uma, alguém ainda teria que escrever o código para fazer a camada de exibição gráfica funcionar. A complexidade desta tarefa é comparável ao desenvolvimento de seu próprio jogo.
... Quer dizer, você não precisa olhar para jogos em que essa abordagem de "ganhar na loteria". Este é um exemplo muito perigoso porque não tem sucesso por meio de "boas práticas de desenvolvimento", mas por uma sorte incrível.
Geralmente é uma má ideia observar a prática de desenvolver jogos populares e de sucesso. Existe até um termo - “erro do sobrevivente”. Em vez de dizer "uau, eles conseguiram sobreviver apesar das más decisões" - as pessoas dizem "eles conseguiram PORQUE tomaram essas decisões".
Bem, por exemplo, dwarf fortress não usa controle de versão. Nem git, nem svn, nem mesmo cvs. Eles apenas copiam uma pasta em um diretório.
Seja o que for, eu pessoalmente acho que trabalhar com um artista cujo estilo você não gosta é um desrespeito antinatural por si mesmo. Você pode fingir, ser educado e aceitar a arte mesmo que não goste, mas será muito mais fácil recusar e ser honesto consigo mesmo.
Isso é muito semelhante ao casamento / casamento.
PS Se você encontrar erros de digitação ou erros no texto, por favor me avise. Isso pode ser feito selecionando parte do texto e pressionando "Ctrl / ⌘ + Enter", se você tiver Ctrl / ⌘, ou através de mensagens privadas . Se ambas as opções não estiverem disponíveis, escreva sobre os erros nos comentários. Obrigado!