Making a Mod
You can help by adding links to this article from other relevant articles.
January 2024
Este artigo foi desenvolvido para ajudá-lo a fazer uma modificação no Source Engine, ou mod. Primeiro, ele traz alguns conselhos sobre como iniciar um mod e montar uma equipe. A seguir, há uma coleção de dicas úteis sobre como descobrir o design do jogo para o seu mod. Por fim, ele contém um guia passo a passo sobre como amarrar as pontas soltas e finalizar seu mod, que na verdade é a parte mais difícil da criação de mods.
!
Começando
Vamos começar analisando como montar uma equipe. A regra orientadora aqui é manter a equipe pequena. Gerenciar uma equipe de pessoas é um trabalho em tempo integral, mesmo quando toda a equipe está no mesmo prédio. Se você está lidando com uma equipe online, pode facilmente gastar todo o seu tempo gerenciando-a, e isso significa que você não estará gastando tempo no desenvolvimento do seu mod. Adicionar mais pessoas à equipe não significa que mais trabalho será realizado. Quanto mais pessoas você tiver, mais tempo será gasto gerenciando-as. A equipe principal do Team Fortress tinha 3 pessoas. A equipe principal do Counter-Strike tinha uma pessoa.
Ao procurar membros para a equipe, tente contratar apenas pessoas das quais você realmente não pode prescindir. Seu primeiro instinto pode ser contratar qualquer pessoa que saiba programar, modelar, criar mapas, etc. Mas, para a sua primeira versão, provavelmente não precisará de mais de uma pessoa para cada área do seu mod (código, som, modelos, mapas). Você pode nem precisar de novos modelos, sons ou mapas. Não contrate ninguém até ter visto exemplos do trabalho deles. Certifique-se de que eles tenham realmente concluído projetos. Se eles são modeladores que fizeram 20 modelos, mas todos estão pela metade, você não os quer.
Design do Mod
Como autor de um mod, a pergunta mais útil que você pode fazer a si mesmo é "Por que alguém deveria jogar meu mod?" É uma pergunta difícil de responder honestamente, mas se você conseguir respondê-la bem, está no caminho certo. Pense em outros mods disponíveis e no que eles oferecem. Seu mod oferece algo novo aos jogadores? O que você oferece é suficiente para atrair jogadores ocupados jogando outros mods? Mesmo que você não consiga responder a esta pergunta, apenas pensar nela provavelmente ajudará seu mod.
Competir com Jogabilidade
Você possui uma vantagem que os desenvolvedores comerciais não têm: você não precisa se preocupar com a viabilidade comercial de novos estilos de jogabilidade. Desenvolvedores comerciais precisam se preocupar em atrair o varejo, equilibrar custos e outras coisas desagradáveis, razão pela qual a maioria dos jogos é uma modificação leve de estilos de jogabilidade já comprovados. Mas você não precisa fazer isso. Você pode experimentar ideias de jogabilidade totalmente novas que podem se tornar a Próxima Grande Coisa. Esta é a sua vantagem sobre os desenvolvedores comerciais. Facilite seu trabalho concentrando-se nessa vantagem e não gaste seu tempo tentando competir nas áreas em que os produtos comerciais são fortes. A maioria dos mods não pode competir no nível de conteúdo (mapas, modelos, sons, etc.) com produtos comerciais. Eles têm equipes de artistas com anos de experiência. Supere-os com sua jogabilidade. Jogadores jogarão um mod que tem muito pouco conteúdo novo, mas tem uma jogabilidade realmente divertida. Algo que muitas pessoas não percebem é que o Team Fortress 1 tinha quase nenhum novo design artístico por um ano após seu lançamento inicial.
Lançar cedo, lançar frequentemente
Você possui outra vantagem sobre os desenvolvedores comerciais. Você pode lançar muito, muito mais rápido e com mais frequência do que eles. Resumimos esta filosofia de desenvolvimento de mod com a frase "Lançar cedo, lançar frequentemente". Desenvolvedores comerciais trabalham por 2-3 anos, lançam seu jogo e esperam que as pessoas gostem. Você não precisa dar esse salto de fé. Você pode projetar todo o seu mod, escrever 25% dele e polir para um estado jogável, lançá-lo e começar a receber feedback imediatamente. Então você pode começar a adicionar o resto do seu design aos poucos, ao mesmo tempo incorporando o feedback do jogador na primeira versão, e continuar lançando a cada mês ou dois. Você está em contato com seus jogadores o tempo todo, então nunca estará na situação em que gastou muito tempo em algo do qual não tem certeza se os jogadores vão gostar. O truque é dividir seu mod em partes. A versão inicial precisa ser divertida e jogável, mas não precisa de todos os recursos legais que você pensou.
Tenha cuidado. "Lançar cedo" não significa lançar coisas de má qualidade, significa apenas fazer seu mod em incrementos pequenos e polidos. A primeira versão do Counter-Strike não tinha metade dos recursos que tem agora. A equipe do CS lançou um mod de alta qualidade, mas não muito grande. No último ano, eles têm regularmente adicionado mais e mais recursos e, como resposta, sua base de jogadores continuou a crescer cada vez mais.
Diferente nem sempre é melhor
Ao pensar no design do seu jogo, não caia na armadilha de acreditar que "Diferente é Melhor". Não há razão para reescrever o código de uma espingarda e ter um novo modelo de espingarda se isso não impactar seu jogo de maneira interessante. Lembre-se da primeira pergunta, "Por que alguém deveria jogar meu mod?" A resposta "Meu mod tem um novo sistema de combate e um novo sistema de movimento" não é necessariamente uma boa resposta. Então, seu sistema de combate é diferente do Half-Life. Ok... mas é melhor? Isso torna o seu mod mais divertido de jogar? Um novo sistema de movimento torna o jogo mais divertido? Os jogadores estão acostumados aos sistemas existentes, e fazê-los aprender outro precisa valer a pena para eles. Então, antes de pensar em mudar algo, certifique-se de saber que está mudando para melhor e que tornará seu mod mais divertido. Não tenha medo de deixar algo igual ao que era no Half-Life.
Metas Realistas
Crie metas realistas para si mesmo. Pense em quanto tempo um desenvolvedor comercial leva
para criar um jogo de tiro em primeira pessoa (FPS) com 10 armas. Se o seu mod vai ter 40 armas, você está tornando sua vida muito difícil. A coisa a ter em mente aqui é "Qualidade sobre Quantidade". Os jogadores prefeririam ter 10 armas únicas, bem equilibradas e divertidas de usar do que 40 armas desequilibradas, algumas das quais são versões ligeiramente modificadas de outras.
Não tenha medo de cortar conteúdo e recursos. Se o mod parecer que nunca será concluído, ou se houver algum conteúdo que você não acha que atende à qualidade do restante do mod, comece a cortar. Durante o desenvolvimento do Half-Life, pelo menos 30% dos recursos originais no design foram cortados porque ficou claro que eram inatingíveis em nosso cronograma, ou porque decidimos que não valiam o tempo de desenvolvimento. Como mencionamos acima, "Qualidade sobre Quantidade". Os jogadores prefeririam ter 3 mapas realmente bons e bem testados do que 10 não testados, e isso dará ao seu mod uma reputação de conteúdo de qualidade. Não deixe o mundo ver suas piores coisas.
Entenda o Motor do Jogo
Você realmente deve ler a documentação incluída no SDK. A coisa que você aprenderá mais ao fazer isso não é se você pode fazer X com o motor, mas sim como X deve ser feito para funcionar bem. Você pode criar uma arma que dispara 50 foguetes, mas se você não entender como o motor funciona, você pode fazer isso de uma maneira que aumenta significativamente o tráfego de rede usado pelo seu mod. Isso é importante para todos em seu mod. Se seus criadores de mapas não entendem o motor, eles farão mapas enormes sem pensar em quanto dados de rede serão enviados aos jogadores neles, e todos culparão seu código por ser muito intensivo em rede. Se você é um programador, é uma boa ideia se juntar à lista de discussão HL Coders, onde você poderá conversar com muitos outros programadores de mods e alguns funcionários da Valve também. A lista de discussão tem arquivos que remontam a muito tempo, contendo soluções úteis para problemas comuns de mods.
Finalizando
Vemos muitos mods que começam bem, produzem muito conteúdo excelente e nunca dão o último passo para colocá-lo nas mãos dos jogadores. Esta seção o ajudará a entrar em um modo de lançamento em que você está trabalhando para produzir uma versão lançável do seu mod.
Escolhemos cinco semanas como uma estimativa inicial do tempo necessário para passar do modo de desenvolvimento normal para uma versão enviável. É provável que você melhore, e, portanto, seja mais rápido, com lançamentos sucessivos. Se o seu mod for de maior escopo ou sua equipe for substancialmente internacional, é provável que leve mais de cinco semanas, embora os passos sejam semelhantes aos seguintes. Se possível, tente conseguir que a equipe dedique algumas horas todos os dias ao mod durante esse período. Se alguns membros da equipe não puderem fazer isso, você provavelmente estará melhor removendo-os do processo de envio. Peça a eles que entreguem sua parte a outra pessoa na equipe que possa dedicar o esforço necessário. Lançar um produto, mesmo um pequeno, é difícil e requer um compromisso substancial.
Há muitas coisas nesta seção que podem parecer rígidas ou rígidas. Isso é lamentável, mas um reflexo de como esse processo é difícil. Os conselhos aqui são um resumo das lições aprendidas no envio de muitos produtos e a maioria deles é resultado de erros dolorosos que atrasaram nossas datas de lançamento. Quando você se pergunta se um conselho específico aqui é necessário, é possível que tenhamos adicionado semanas à nossa data de lançamento porque não o seguimos.
Isso também é algo que os futuros empregadores estão extremamente interessados. É uma coisa ver que um criador de mods produziu coisas legais, é outra coisa ver que ele produziu coisas legais e realmente as lançou para as pessoas jogarem. O mapa/modelo/código/som/etc. mais legal do mundo é inútil se você não conseguir o último trecho e lançá-lo.
Não se preocupe, isso fica muito mais fácil depois de passar por isso algumas vezes. Na terceira ou quarta versão do seu mod, você será um especialista!
Cinco semanas antes
Centralizar a Propriedade
Você deve designar um único membro da sua equipe de mod como o Líder de Envio (LE). Essa pessoa conduzirá o progresso do mod nas próximas cinco semanas. Todas as alterações feitas no mod a partir de agora devem ocorrer apenas a pedido do LE, e todas as solicitações de alterações devem ser encaminhadas por meio dessa pessoa. Nenhum membro da equipe deve fazer alterações, por menores que sejam, no mod, a menos que o LE tenha solicitado uma alteração específica. Isso não significa que o restante da equipe está perdendo o controle do mod; o LE ainda faz parte da equipe e estará ouvindo todos os feedbacks. O objetivo do LE é garantir que todas as alterações no mod estejam passando por uma única pessoa. Isso evita problemas, como um criador de mapas que quebra o jogo fazendo uma mudança de última hora porque não percebeu que algo mais havia mudado no código do jogo. O LE conhecerá o estado de cada componente no jogo (código, mapas, modelos, texturas, etc.) o tempo todo ao longo das próximas 5 semanas para garantir que isso nunca aconteça.
Escolher o LE não é fácil. Aqui estão algumas dicas:
Não assuma imediatamente que a pessoa que está atualmente gerenciando o mod é a melhor escolha para o LE, especialmente se o mod estiver sendo trabalhado por meses e não estiver mais perto de ser lançado. Os programadores de jogos provavelmente são a melhor escol ha. À medida que o processo de envio se aproxima do fim, a maioria das correções será feita no código do jogo.
O LE deve ser altamente motivado, disciplinado, organizado e o mais desprovido de ego possível. O LE precisará poder dedicar cinco semanas de sua vida a esse processo. O LE deve ser capaz de tomar decisões globais para o mod. O LE deve entender que isso muitas vezes requer cortar recursos e conteúdo para envio.
Estabelecer um Processo de Compilação
Você precisa criar um processo pelo qual compila seu mod. A compilação é o processo de pegar todo o seu trabalho e produzir uma versão instalável e funcional do mod (geralmente na forma de um arquivo de instalação). Isso deve ser feito exclusivamente pelo LE pelas próximas cinco semanas, e o LE deve ter um processo estrito que sempre é seguido. Criar um processo estrito para isso garantirá que você não desperdice horas rastreando bugs que são simplesmente resultado de alguém compilando de maneira diferente do que a pessoa anterior.
O LE deve manter a versão final/candidata ao lançamento do mod a partir de agora. Todas as alterações devem ser enviadas para ele, e ele deve incorporá-las em sua cópia do mod uma a uma e com total compreensão do impacto das alterações em todas as partes do mod. Não se esqueça de fazer backup do seu código e conteúdo regularmente!
O LE deve compilar o mod todos os dias para os playtests. Mais sobre isso depois.
Bloqueio de Recursos
O envio é o processo de bloquear porções do seu mod. "Bloqueado" significa que a porção não deve ser tocada a partir de então. Bugs encontrados em porções bloqueadas do seu mod devem ser pensados cuidadosamente. A menos que o bug seja realmente importante (impedimento), apenas anote-o e corrija na próxima atualização do seu mod. Independentemente da tentação de fazer aquela "correção fácil", evitar desbloquear porções do seu mod deve ser evitado o máximo possível.
Neste ponto do processo de envio, cinco semanas antes, você também deve ter o bloqueio de recursos. Isso significa que você não deve estar adicionando novos recursos ao seu mod de forma alguma. Se parte de sua equipe não estiver envolvida no envio, mas quiser continuar trabalhando no desenvolvimento do mod, ela deve estar trabalhando em um banco de dados separado de conteúdo e código. A maioria dos pacotes de controle de código-fonte permite o ramificação de código dessa maneira. (Sim, recomendamos fortemente que você use alguma forma de controle de código-fonte). Toda alteração feita no mod a partir de agora deve ser uma correção de bug. O LE deve garantir isso. Mesmo que um programador pense em outro recurso legal que diz que levará apenas 10 minutos para codificar, não deixe ele adicionar. Mesmo que o programador envie o código, finalizado e sem bugs, para o LE, não o adicione ao mod. Guarde-o para a próxima versão.
Uma atitude saudável para o LE ter é que cada alteração no mod a partir de agora adicionará dois dias à data de lançamento.
Playtesting
A partir de agora, você deve estar realizando playtests todos os dias, ou a cada dois dias, se isso for muito. Os playtests devem ser baseados em versões instaláveis do jogo, compiladas pelo LE. Não permita que membros da equipe joguem de suas versões pessoais do jogo. Todos devem estar executando uma versão do mod instalada a partir de uma compilação enviada pelo LE (isso é o que seu público verá e usará, é isso que você deve estar testando). Você perderá muitas horas encontrando bugs causados por versões incompatíveis se não fizer isso.
Para facilitar isso, o mod deve ser mantido em um estado jogável o tempo todo. Fique muito preocupado se o mod não estiver jogável por um dia. Se um programador ou criador de mapas fizer uma alteração que quebrar o mod, pense cuidadosamente antes de incorporá-la à compilação do LE. Quanto tempo o jogo permanecerá inutilizável? Quantos playtests você perderá? Quantos membros da equipe não poderão trabalhar porque o mod não está funcionando? Não quebrar o mod deve ser uma religião para a equipe.
Quando você realizar playtests, certifique-se de que o máximo possível de membros da sua equipe está jogando. Todos que trabalham no jogo devem jogá-lo regularmente. Certifique-se de ter alguns jogadores externos também. Ative o log de console do servidor (defina "log" para "on" no arquivo server.cfg). Isso despejará todas as saídas do servidor em um arquivo no diretório gamedir/logs (o nome do arquivo corresponderá à data). Sempre que qualquer jogador no jogo encontrar um bug, faça com que eles usem a tecla "say" para dizer "BUG: descrição do bug". Em seguida, quando o jogo terminar, você pode abrir o arquivo de log e extrair todos os bugs dele pesquisando a palavra "BUG."
Bugs e Alterações
O LE deve manter uma lista completa de todos os bugs e alterações, e seu status atual. Preferencialmente, isso deve ser feito usando algum tipo de banco de dados verdadeiro. O e-mail é totalmente insuficiente para rastrear bugs; é muito fácil para os itens caírem na primeira página da caixa de correio de um usuário, etc. Após cada playtest, os bugs e as alterações necessárias do arquivo de log devem ser adicionados à lista pelo LE e atribuídos aos membros da equipe. Quando um membro da equipe corrigir um bug ou uma alteração, ele deve enviar o novo conteúdo ao LE, que deve verificar se está corrigido e, em seguida, atualizar o status na lista de bugs.
A lista de bugs é uma ferramenta fantástica para avaliar o progresso do seu projeto. Pode ser usada para descobrir quem está sobrecarregado de trabalho, quem está com pouco trabalho, quem não está corrigindo seus bugs, qual área do seu mod está mais distante da conclusão, entre outras coisas. Não remova nada da lista de bugs, mesmo quando tiver sido corrigido (embora deva marcá-lo como corrigido de alguma forma, é claro). É muito útil ver quais bugs foram corrigidos ao longo da história do projeto. Algo pode regredir, recriando um bug, e saber quem o corrigiu da última vez facilita perguntar o que causou isso. No final do projeto, você deve ser capaz de ver cada bug corrigido e cada mudança feita no seu mod durante todo o processo de envio. O SL não deve permitir que qualquer correção de bug ou alteração entre na cópia principal do jogo, a menos que a correção/alteração tenha sido detalhada na lista de bugs.
Existem softwares que ajudarão você a criar e manter uma lista de bugs. Alternativamente, uma planilha funcionará muito bem. Novamente, o e-mail não é uma boa escolha.
Cortar ou adiar recursos quebrados
A parte mais difícil, desagradável e, infelizmente, mais necessária do envio é o ato de ser realista e cortar recursos. Temos um ditado na Valve que diz que todos terão seu recurso favorito cortado do jogo. Embora não seja verdade, isso ajuda todos a se prepararem para o fato de que terão recursos de que gostam - ou em que gastaram muito tempo - cortados. Seu jogo simplesmente não pode ter todos os recursos legais e ainda ser lançado em um prazo razoável. O SL deve tomar decisões sobre o que concluir e o que cortar, com base em quão longe você está no processo de lançamento.
Quanto mais perto você estiver do lançamento, mais você deve pensar em cada bug conforme o encontra. O bug está em um recurso que absolutamente deve estar nesta versão? Quantos dias levará para corrigir esse recurso? Esse recurso pode ser cortado ou adiado para uma versão posterior?
Trabalhe com inteligência, não com esforço
Como dissemos várias vezes, o processo de envio é difícil, e é ainda mais difícil se você não pensar cuidadosamente no que trabalhar. Trabalhar muito não substitui a escolha cuidadosa do que corrigir, o que adiar e o que cortar completamente. O SL deve ter extrema cautela sobre quais bugs/mudanças devem ser trabalhados e por quem. Não gaste uma semana corrigindo um problema pequeno em um recurso apenas porque o recurso é legal. Corrija bugs de travamento (impeditivos). Corrija bugs que impedem totalmente o envio do jogo. Corrija bugs que estão impedindo outros membros da equipe de corrigirem seus bugs. O SL deve desenvolver categorias para bugs para ajudar nas decisões corretas. Um bom nível de granularidade é Deve Corrigir, Grave, Médio, Menor, Zero, Adiado.
À medida que o projeto se aproxima do envio, o SL deve avaliar cuidadosamente cada bug que aparece. Lembre-se, cada bug corrigido cria mais testes e geralmente mais bugs. Se você estiver a duas semanas da data de lançamento e tiver um bug que levará a alguém três dias e 500 linhas de código para corrigir, você não conseguirá cumprir essa data de lançamento, a menos que corte ou adie essa parte do jogo.
Três semanas para o fim
Conteúdo Bloqueado
Neste ponto, você deve almejar estar completo em conteúdo. Isso significa que todo o conteúdo no jogo está em um estado bloqueado, exceto pelo código do jogo em si. Todos os mapas, modelos, texturas, sons, arte do HUD, arte do lançador e assim por diante devem estar concluídos e na cópia principal do SL.
Desligando
Isso foi mencionado na marca de cinco semanas, mas agora é ainda mais importante. O SL é a única pessoa que deve mexer na cópia principal do jogo, e ele deve simplesmente incorporar as correções de bugs dos programadores, que devem corrigir apenas os bugs que o SL entrega a eles.
Testes
O mod deve ser testado todos os dias, por pelo menos duas horas. De agora até o lançamento, você quer que o maior número possível de pessoas martele o seu mod. Agora é tarde demais para fazer grandes mudanças no design do jogo - nem mesmo se sinta tentado.
Uma semana para o fim
Sem mudanças de última hora
O SL deve avaliar cada alteração que precisa ser feita e decidir se elas devem ser adiadas para a próxima versão. Novamente, uma maneira saudável de pensar é que cada alteração, mesmo que seja uma única linha de código, adicionará dois dias à data de lançamento.
Período seguro de dois dias
Depois que todos os bugs que serão corrigidos foram corrigidos e tudo o mais foi adiado, você não está pronto. Agora, espere pelo menos 48 horas, durante as quais você deve testar intensamente. Tente fazer com que todos joguem o jogo pelo maior tempo possível. Se encontrar mais bugs que precisam ser corrigidos, corrija-os e reinicie as 48 horas.
Se o seu mod passar 48 horas de intensos testes sem encontrar nenhum problema novo, você está pronto para lançar!
Pós-lançamento
Então, você lançou, os jogadores adoraram, e páginas da web em todos os lugares estão falando sobre o quanto seu mod é divertido. Se você terminou agora, depende de você. De nossas experiências no campo multiplayer online, um mod só permanece popular enquanto é suportado. Não importa quão incrível seja o seu mod, ele não vai atrair um número significativo de jogadores com sua primeira versão. Os números de jogadores crescem ao longo do tempo por meio de lançamentos repetidos de novo conteúdo, correções de bugs e, é claro, suporte da comunidade. Tanto o Counter-Strike quanto o Team Fortress começaram pequenos e cresceram ao longo do tempo. Cada vez que lançaram uma nova
versão, mais jogadores os experimentaram e começaram a jogá-los.
Saber o que corrigir, o que mudar e como ouvir a sua comunidade é um processo contínuo de aprendizado.
Boa sorte!
Veja tambem
January 2024
